2019 年はなぜクラウド ネイティブにとって重要な年なのでしょうか?

「将来のソフトウェアはクラウド上で成長する必要がある」というのが、クラウド ネイティブ コンセプトの中心的な前提です。いわゆる「クラウド ネイティブ」とは、実際には、アプリケーションがクラウドの機能を最大限に活用し、クラウドの価値を最大限に引き出すことができる最適なパスを定義することです。この道では、「アプリケーション」というキャリアがなければ、「クラウド ネイティブ」について語ることはできません。コンテナ テクノロジーは、この概念を実装し、ソフトウェア配信の革命を継続するための重要な手段の 1 つです。

[[278028]]

クラウドネイティブ技術開発の簡単な歴史

• Google は 2004 年から 2007 年にかけて、社内で Cgroups などのコンテナ テクノロジーを大規模に使用してきました。
• 2008 年に、Google は Cgroups を Linux カーネル トランクに統合しました。
• 2013 年に Docker プロジェクトが正式にリリースされました。
• 2014 年に Kubernetes プロジェクトが正式にリリースされました。その理由は簡単に理解できます。コンテナと Docker を使用する場合、誰もがこれらのコンテナを便利に、迅速に、そしてエレガントに管理できるようにする方法が必要です。これが Kubernetes プロジェクトの本来の意図です。 Google と Redhat が Kubernetes をリリースした後、プロジェクトは急速に成長しました。
• 2015 年、Google、Redhat、Microsoft などの大手クラウド コンピューティング ベンダーといくつかのオープン ソース企業が共同で Cloud Native Computing Foundation (CNCF) を設立しました。 CNCF が最初に設立されたとき、創設メンバーは 22 社あり、Kubernetes は CNCF がホストする最初のオープンソース プロジェクトとなりました。その後、CNCF は急速に成長しました。
• 2017 年、CNCF は 170 人の会員と 14 件の資金提供プロジェクトに到達しました。
• 2018年、CNCFは設立3周年を迎え、会員数は195名、設立プロジェクトは19件、インキュベーションプロジェクトは11件となりました。このような急速な開発速度は、クラウド コンピューティング分野全体でも非常に稀です。

クラウドネイティブテクノロジーエコシステムの現状

したがって、今日議論しているクラウド ネイティブ テクノロジーのエコシステムは、膨大なテクノロジーの集合体です。 CNCF にはクラウド ネイティブ ランドスケープ (https://github.com/cncf/landscape) があり、そこには CNCF の見解と一致する 200 を超えるプロジェクトと製品が含まれています。そこで、このパノラマ写真を背景として考えてみると、今日議論しているクラウド ネイティブは、実際には主に以下の点に関するものであることがわかります。

クラウド ネイティブ ファンデーション — CNCF;

CNCF などのクラウド ネイティブ テクノロジ コミュニティは現在、現代のクラウド コンピューティング エコシステムの基盤を形成する 20 を超えるプロジェクトを公式にホストしています。その中で、Kubernetes などのプロジェクトは、世界で 4 番目に活発なオープンソース プロジェクトとなっています。

前の 2 つのポイントに加えて、世界中のすべての主要なパブリック クラウド ベンダーが現在 Kubernetes をサポートしています。さらに、100社を超えるテクノロジー系スタートアップも投資を続けています。現在、アリババは全面的にクラウドに移行することを検討しており、クラウドに移行するにはクラウド ネイティブへの移行が必要です。これは、大手テクノロジー企業がクラウド ネイティブを採用している例でもあります。

私たちは時代の重大な岐路に立っている

2019 年はクラウドネイティブ時代の重要な節目です。なぜそう言うのでしょうか?簡単に整理してみましょう。

2013 年の Docker プロジェクトのリリース以降、Docker プロジェクトのリリースにより、完全なオペレーティング システム セマンティクスを備えたサンドボックス テクノロジが容易に利用できるようになり、ユーザーはアプリケーションをより適切かつ完全にパッケージ化できるようになり、開発者は PaaS 機能に依存せずにアプリケーションの最小実行単位を簡単に取得できるようになりました。これは実際には、従来の PaaS 業界に対する「次元削減攻撃」です。

2014 年に Kubernetes プロジェクトがリリースされました。その意義は、Google がオープンソース コミュニティの助けを借りて内部の Borg/Omega システムのアイデアを「生まれ変わらせ」、「コンテナ デザイン パターン」というアイデアを提案したことにあります。 Google が Borg プロジェクトを直接オープンソース化するのではなく、Kubernetes を間接的にオープンソース化することを選択した理由は、実のところ簡単に理解できます。Borg/Omega のようなシステムは Google 外部の人に提供するには複雑すぎるのですが、Kubernetes の助けを借りれば Borg/Omega の設計アイデアを誰でも利用できるようにすることができ、これも Kubernetes をオープンソース化する重要な背景です。

つまり、2015年から2016年にかけては、コンテナオーケストレーションにおける「三国競争」の時代だったのです。当時、コンテナ オーケストレーションの分野では、Docker、Swarm、Mesos、Kubernetes が競合していました。彼らが競争する理由は実は非常に簡単に理解できます。つまり、Docker やコンテナ自体に大きな価値があるものの、それらから商業的価値やクラウドへの価値を生み出したいのであれば、オーケストレーションにおいて有利な立場を占める必要があります。

Swarm と Mesos の特徴は、それぞれがエコロジーとテクノロジーに優れていることです。その中で、Swarm はエコロジーに傾倒しており、Mesos はテクノロジーに強いです。対照的に、Kubernetes は両方の利点を組み合わせ、最終的に 2017 年の「三国志大戦」で勝利し、それ以降現在に至るまでコンテナ オーケストレーションの標準となっています。このプロセスの代表的な出来事として、Docker が Kubernetes サービスをコア製品に組み込み、Swarm プロジェクトが段階的にメンテナンスを停止すると発表したことが挙げられます。

2018 年までに、クラウドネイティブ テクノロジーの概念が定着し始めました。これは、Kubernetesやコンテナがクラウドベンダーの標準規格として定着し、「クラウド」を中心としたソフトウェア開発の考え方が徐々に形成され始めたためだ。

そして2019年、状況は再び変化しつつあるようです。

「クラウドネイティブ」とは何ですか?クラウドネイティブを実装するには？

クラウドネイティブの定義

「クラウド ネイティブとは一体何ですか?」と多くの人が尋ねます。

実際、クラウド ネイティブは最適なパス、つまりベスト プラクティスです。より詳細には、クラウド ネイティブは、ユーザーがクラウドの機能を最大限に活用し、精神的負担が少なく、俊敏で、スケーラブルで、複製可能な方法でクラウドの価値を実現するための最適なパスを指定します。

したがって、クラウド ネイティブは、実際にはソフトウェア アーキテクチャ設計を導く一連のアイデアです。このアイデアに従って設計されたソフトウェアは、まず、自然に「クラウド上で生まれ、クラウド上で成長する」ものです。 2つ目は、クラウドの機能を最大限に活用できるため、私たちが開発するソフトウェアと「クラウド」が自然に統合され、「クラウド」の価値が最大化されることです。

したがって、クラウド ネイティブの最大の価値とビジョンは、将来のソフトウェアが誕生した瞬間からクラウド上で成長し、新しいソフトウェア開発、リリース、運用および保守モデルに従うことで、ソフトウェアがクラウドの機能を最大限に活用できるようになることです。この時点で、コンテナ テクノロジーがなぜ革命的なのか考えてみましょう。

実際、コンテナ テクノロジの革命的な性質は、コンテナ テクノロジの革命的な性質と非常に似ています。つまり、コンテナ テクノロジにより、アプリケーションを「自己完結型」で定義できるようになります。したがって、このようなアプリケーションは、俊敏性、拡張性、複製性に優れた方法でクラウド上に公開でき、クラウドの能力を最大限に活用できます。ここで、コンテナ テクノロジーがクラウドに革命的な影響を及ぼします。したがって、コンテナ テクノロジーはクラウド ネイティブ テクノロジーの中核となる基盤です。

クラウドネイティブテクノロジーの範囲

クラウド ネイティブの技術的範囲には、次の側面が含まれます。

最初の部分は、クラウド アプリケーションの定義と開発プロセスです。これには、アプリケーションの定義とイメージの作成、CI/CD 構成、メッセージングとストリーミング、データベースが含まれます。

2 番目の部分は、クラウド アプリケーションのオーケストレーションと管理のプロセスです。これは、アプリケーションのオーケストレーションとスケジューリング、サービス検出ガバナンス、リモート呼び出し、API ゲートウェイ、サービス メッシュなど、Kubernetes がより重視する部分でもあります。

3 番目の部分は監視と観測可能性です。このセクションでは、クラウド アプリケーションを監視、ログを収集、トレースする方法と、カオス エンジニアリングの概念であるクラウド上で破壊的テストを実装する方法に重点を置いています。

4 番目の部分は、コンテナ ランタイム、クラウド ネイティブ ストレージ テクノロジー、クラウド ネイティブ ネットワーク テクノロジーなどの基盤となるクラウド ネイティブ テクノロジーです。

5 番目の部分はクラウド ネイティブ ツールセットです。前述のコア技術ポイントに加えて、プロセスの自動化と構成管理、コンテナ イメージ リポジトリ、クラウド ネイティブ セキュリティ テクノロジー、クラウド パスワード管理など、使用する必要があるサポート エコシステムや周辺ツールが多数あります。

最後はサーバーレスです。サーバーレスは PaaS の特殊な形式であり、より「極めて抽象的な」アプリケーション記述方法を定義し、FaaS や BaaS などの概念が含まれます。 FaaS にしろ BaaS にしろ、最も典型的な特徴は実際の使用量に基づいた課金（従量課金）であるため、サーバーレス課金も重要な知識と概念です。

クラウドネイティブ思考の2つの理論

クラウド ネイティブの技術的な範囲を理解すると、多くの技術的な内容が含まれていることがわかりますが、これらの内容の技術的な本質は似ています。クラウド ネイティブ テクノロジーの本質は、2 つの理論的基礎です。

最初の理論的基礎は、不変のインフラストラクチャです。これは現在、コンテナ イメージを通じて実現されています。つまり、アプリケーション インフラストラクチャは不変、自己完結型、自己記述型であり、さまざまな環境間で完全に移植可能である必要があります。

2 番目の理論的基礎は、クラウド アプリケーション オーケストレーション理論です。現在の実装方法は、Google が提唱する「コンテナ デザイン パターン」であり、本講座シリーズの Kubernetes パートの主な内容でもあります。

インフラストラクチャのクラウドへの進化

まず、「不変インフラストラクチャ」の概念を紹介します。実際、アプリケーションが依存するインフラストラクチャもクラウドに向けて進化の過程にあります。たとえば、従来のアプリケーション インフラストラクチャは可変であることが多いです。

ソフトウェアのリリースやアップデートなど、このような操作は頻繁に行うことがあります。プロセスはおおよそ次のようになります。まず SSH 経由でサーバーに接続し、次にソフトウェア パッケージを手動でアップグレードまたはダウングレードし、サーバー上の構成ファイルを 1 つずつ調整し、新しいコードを既存のサーバーに直接展開します。したがって、このインフラストラクチャは継続的に調整および変更されます。

しかし、クラウド上では、クラウド対応のアプリケーション インフラストラクチャは不変です。

このシナリオにおける上記の更新プロセスでは、アプリケーションがデプロイされると、アプリケーション インフラストラクチャは変更されません。更新が必要な場合は、パブリック イメージを変更して新しいサービスを構築し、古いサービスを直接置き換える必要があります。直接的な置き換えを実現できる理由は、コンテナが自己完結型の環境（アプリケーションの実行に必要なすべての依存関係を含む）を提供するからです。したがって、アプリケーションの場合、コンテナの変更を心配する必要はありません。コンテナイメージ自体を変更するだけで済みます。そのため、クラウド対応のインフラストラクチャはいつでも交換・置き換えが可能です。これは、コンテナがクラウド時代のアプリケーション インフラストラクチャである俊敏性と一貫性の機能を備えているためです。

つまり、まとめると、クラウド時代のインフラストラクチャは、いつでも交換可能な「家畜」のようなものです。一方、従来のインフラストラクチャは、細心の注意を必要とする独特の「ペット」であり、これはクラウド時代の不変のインフラストラクチャの利点を反映しています。

クラウドへのインフラストラクチャの進化の重要性

したがって、このようにインフラストラクチャを不変性に向けて進化させるプロセスは、2 つの非常に重要な利点をもたらします。

インフラストラクチャの一貫性と信頼性。同じ鏡は、米国、中国、インドのどこで開いても同じです。また、OS 環境はアプリケーションに対して一貫しています。アプリケーションの場合、コンテナがどこで実行されるかを気にする必要はありません。これはインフラストラクチャの一貫性にとって非常に重要な機能です。

このようなイメージは自己完結型であり、アプリケーションの実行に必要なすべての依存関係が含まれているため、クラウド上の任意の場所に移動することもできます。

さらに、クラウドネイティブ インフラストラクチャは、シンプルで予測可能な展開および運用機能も提供します。画像が追加されたので、アプリケーションは自己記述型のままです。イメージを通じて実行されるコンテナ全体は、Kubernetes の Operator テクノロジーのように実際に自己運用および保守できるため、アプリケーション全体が自己完結型となり、クラウド上の任意の場所に移行できます。これにより、プロセス全体を自動化することも非常に簡単になります。

アプリケーション自体も、1 インスタンスから 100 インスタンス、さらに 10,000 インスタンスへと拡張できます。このプロセスは、コンテナ化されたアプリケーションにとって特別なものではありません。最後に、不変のインフラストラクチャを使用して、システムとサポートコンポーネントを迅速に管理および制御することもできます。これらのコンポーネント自体もコンテナ化されており、不変インフラストラクチャの理論に準拠しているためです。

上記は、不変インフラストラクチャがユーザーにもたらす最大の利点です。

2019年はクラウドネイティブ技術普及元年

2019 年が重要な節目となる可能性が高いのはなぜでしょうか? 2019年はクラウドネイティブ技術の普及元年になると考えています。

まず、ご覧のとおり、2019年にアリババは全面的にクラウドに移行すること、そして「クラウドへの移行はクラウドネイティブへの移行を意味する」と発表しました。また、「クラウド」を中心としたソフトウェア開発のコンセプトが、徐々にすべての開発者にとってのデフォルトの選択肢になりつつあることもわかります。 Kubernetesなどのクラウドネイティブ技術は技術者の必修科目となりつつあり、多くの求人が出ています。

このような状況では、「Kubernetes を知る」だけでは十分ではなく、「Kubernetes を理解する」ことと「クラウドネイティブ アーキテクチャを知る」ことの重要性がますます高まっています。 2019年からクラウドネイティブテクノロジーが広く普及するので、この時点で誰もがクラウドネイティブテクノロジーを学び、投資する必要があります。