クラウドネイティブアーキテクチャの概要を理解していないと、

1. クラウド ネイティブとは何ですか?

1.1 CNCF組織

クラウドネイティブについて話す前に、まずは2015年にGoogleが設立したCloud Native Computing Foundation（CNCF）について学びましょう。この財団には現在、AmazonやMicrosoftを含む100を超える企業や機関が会員として参加しています。シスコのような大企業。

現在、CNCF によってホストされているアプリケーションは 14 個あります。下の図は、クラウド ネイティブ エコシステムのリファレンス システムを提供する CNCF が公開した Cloud Native Landscape を示しています。

クラウドネイティブ環境

1.2 クラウドネイティブ

CNCF は、クラウド ネイティブ アプリケーションの 3 つの主要な特性を提供します。

1. コンテナ化されたパッケージング: コンテナに基づいて、全体的な開発レベルが向上し、コードとコンポーネントの再利用が可能になり、クラウドネイティブ アプリケーションのメンテナンスが簡素化されます。アプリケーションとプロセスをアプリケーション展開の独立した単位としてコンテナ内で実行し、高いレベルのリソース分離を実現します。
2. 動的管理: 集中型のオーケストレーションおよびスケジューリング システムによる動的管理とスケジューリング。
3. マイクロサービス指向: サービス間の依存関係を明確にし、サービスを相互に分離します。

クラウド ネイティブには、企業がビジネス ソフトウェアを迅速かつ継続的に、確実に、大規模に提供できるようにする一連のアプリケーション パターンが含まれています。クラウド ネイティブは、マイクロサービス アーキテクチャ、DevOps、およびコンテナーによって表されるアジャイル インフラストラクチャで構成されます。

インターネットからのクラウドネイティブに必要な機能と特徴をまとめると、次の図のようになります。

クラウドネイティブに必要な機能と特徴

1.3 12の要素

12 ファクターは文字通り 12 の要素と翻訳されることが多く、12 の原則としても知られています。 12 の原則は、パブリック クラウド PaaS の先駆者である Heroku によって 2012 年に提案されました (https://12factor.net/)。目的は、クラウド プラットフォームが提供する利便性を活用して、信頼性が高く、スケーラブルで、保守が容易なクラウド ネイティブ アプリケーションを開発する方法を開発者に教えることです。詳細は以下の通りです。

• ベンチマークコード
• 依存関係を明示的に宣言する
• 環境への構成の保存
• バックエンドサービスを追加リソースとして扱う
• 構築、公開、運営の厳格な分離
• ステートレスプロセス
• ポートバインディングによるサービスの提供
• プロセスモデルによるスケーリング
• 高速起動とスムーズな終了
• 開発環境は本番環境と同等である
• イベントストリームとしてログを記録する
• 管理プロセス

追加のポイントは3つあります。

• API宣言管理
• 認証と承認
• 監視と警告

12の原則が提案されてから5年以上が経過しました。 12 の原則の一部の詳細は、もはや時代に合わなくなっている可能性があります。 12 の原則は当初から Heroku 独自の特性に依存しすぎていると批判する人もいます。しかし、いずれにせよ、12 の原則は、業界で最も体系的なクラウド ネイティブ アプリケーション開発ガイドであることに変わりはありません。

2. コンテナ化

Dockerコンテナ化技術は近年非常に人気があり、さまざまな場面でDockerという言葉を耳にすることが多くなりました。 Docker を使用すると、開発者はアプリケーションと依存関係をポータブル コンテナーにパッケージ化できます。 Docker の背後にある考え方は、基盤となるオペレーティング システムに関係なく、Docker がインストールされている任意のマシンで実行できる、ポータブルで軽量なソフトウェア プログラムのコンテナーを作成することです。

Docker は、仮想マシンが解決できる問題を解決できるだけでなく、リソース要件が高いために仮想マシンが解決できない問題も解決できます。その利点は次のとおりです。

• アプリケーションの依存関係を分離する
• アプリケーションイメージの作成とコピー
• 配布しやすい、すぐに使えるアプリケーションを作成する
• インスタンスを簡単かつ迅速に拡張できます
• アプリをテストして破棄する

自動化された運用・保守ツールは環境構築の複雑さを軽減できますが、環境問題を根本的に解決することはできません。一見安定して成熟したシナリオでは、Docker を使用する利点が増加しています。

3. サービスオーケストレーション

著者は、クラウド ネイティブ アーキテクチャにおけるサービス オーケストレーションの使用に関する Jimmy Song の要約を参照しました。

Kubernetes - コンテナ アプリケーションを大規模な工業生産に導入できるようにします。

この要約は実に適切です。オーケストレーションとスケジューリングのためのその他のオープンソース コンポーネントには、Kubernetes、Mesos、Docker Swarm などがあります。

Kubernetes は現在、世界で最も人気のあるオープンソース プロジェクトです。優れたコンテナ オーケストレーション システムです。 Kubernetes は、インターネット業界の巨人である Google から生まれました。これは、10 年以上にわたって何百人ものエンジニアによって作成されたボーグ システムのコンセプトに基づいています。非常に簡単なインストールと柔軟なネットワーク層ドッキングにより、ワンストップサービスを提供します。

Mesos は、Docker コンテナ、レガシー アプリケーション (Java など)、分散データ サービス (Spark、Kafka、Cassandra、Elastic など) を含む、マルチミッション クリティカルなワークロードを実行するための信頼性の高いプラットフォームの構築に優れています。 Mesos は 2 レベルのスケジューリング アーキテクチャを採用しており、開発者は企業のビジネス シナリオに基づいて Mesos Framework を簡単にカスタマイズできます。

これらは、クラウド ネイティブ アプリケーションに強力なオーケストレーションおよびスケジューリング機能を提供する、クラウド プラットフォーム上の分散オペレーティング システムです。コンテナを単一のマシンで実行しても、効率を最大化することはできません。クラスターを形成することによってのみ、コンテナの適切な分離、リソース割り当て、オーケストレーション管理の利点を最大限に活用できます。コンテナのオーケストレーション管理に関しては、Swarm、Mesos、Kubernetes 間の戦いは基本的に終了し、Kubernetes が文句なしの勝者となりました。

4. マイクロサービスアーキテクチャ

従来の Web 開発方法は、一般的にモノリシック アーキテクチャと呼ばれます。すべての関数は WAR パッケージにパッケージ化されており、基本的に外部依存関係はありません (コンテナーを除く)。これは、DO/DAO、サービス、UI などのすべてのロジックを含めて JEE コンテナ (Tomcat、JBoss、WebLogic) にデプロイされます。そのアーキテクチャを下図に示します。

モノリシック アーキテクチャが進化およびアップグレードされた後、SOA アーキテクチャ、つまりサービス指向アーキテクチャに移行します。近年、マイクロサービス アーキテクチャは、機能モジュールを独立したサブシステムに分解することで分離を実現することを目的とした、最も人気のあるアーキテクチャ スタイルです。決まったルールはなく、業務に合わせて設計する必要があります。マイクロサービス アーキテクチャは、SOA の継続であり、SOA の特定の実用的な方法です。マイクロサービスアーキテクチャでは、各マイクロサービスモジュールは単純で独立した明確なタスクのみを処理し、処理結果を REST API を通じて外部に返します。マイクロサービスの推進と実践の観点から見ると、マイクロサービスはシステム全体をより細かい粒度に分割し、これらのサービスを独立して実行し、コンテナ化技術を適用してコンテナ内でマイクロサービスを独立して実行します。以前は、アーキテクチャを設計する際に、粒度はメモリ内のパラメータまたはオブジェクトの形で実現されていました。マイクロサービスでは、バスの代わりに各サブサービス制御モジュールという考え方を採用します。さまざまなビジネス要件に応じて、サービス制御モジュールには少なくともサービス公開、登録、ルーティング、およびプロキシ機能が含まれます。

コンテナ化の出現により、マイクロサービス アーキテクチャがある程度推進されました。アーキテクチャはモノリシックアプリケーションから分散アプリケーションへ、そして分散アーキテクチャからクラウドネイティブアーキテクチャへと進化しており、その中でマイクロサービスが不可欠な役割を果たしています。マイクロサービスは、開発と展開において多くの柔軟性と技術的な多様性をもたらしますが、サービス呼び出し、分散システムトランザクション、デバッグ、サービスガバナンスの難しさなどのオーバーヘッドも増加させます。

上図の Spring Cloud コンポーネントのアーキテクチャから、サービス検出と登録、サーキットブレーカーメカニズム、ルーティング、グローバルロック、集中構成管理、制御バス、意思決定キャンペーン、分散セッションとクラスター状態管理などの基本コンポーネントを含む、マイクロサービス アーキテクチャに必要なコンポーネントを確認できます。

Spring Cloud と Kubernetes は非常に異なります。 Spring Cloud と Kubernetes は、さまざまな範囲のマイクロサービス アーキテクチャ テクノロジ ポイントを処理し、異なる方法を使用します。 Spring Cloud のアプローチは、JVM におけるマイクロサービス アーキテクチャの重要なポイントに対処する試みですが、Kubernetes のアプローチは、問題をなくし、プラットフォーム レベルで開発者のために解決する試みです。 Spring Cloud は JVM で非常に強力であり、Kubernetes はそれらの JVM の管理で非常に強力です。それぞれの利点を生かし、両方のメリットを最大限活用していくのが自然な流れのようです。

5. 結論

技術アーキテクチャは急速に進化しており、さまざまな新しい用語が次々と登場しています。この記事では主にクラウドネイティブの概要を説明します。クラウド ネイティブ アプリケーションの 3 つの主な機能は、コンテナ化されたパッケージング、動的管理、マイクロサービス指向です。まず、CNCF はクラウド ネイティブの概念を紹介し、次にこれら 3 つの特徴について詳しく説明しました。クラウド ネイティブ アーキテクチャは現在、話題になっています。それはさまざまなアイデアの集合であり、さまざまな一般的なテクノロジーの集大成です。