クラウドネイティブとは何か、そしてクラウドネイティブアプリケーションの12の要素を理解する

クラウド ネイティブという言葉は誰もが知っていると思います。しかし、「クラウド ネイティブとは正確には何なのか」と尋ねられたら、どのように答えますか?

クラウドネイティブ

Cloud Native Computing Foundation (CNCF) は、公式 Web サイトで次のように説明しています。

クラウド ネイティブ テクノロジーにより、組織はパブリック クラウド、プライベート クラウド、ハイブリッド クラウドなどの新しい動的環境で、弾力的にスケーラブルなアプリケーションを構築および実行できるようになります。代表的なクラウドネイティブ テクノロジーには、コンテナー、サービス メッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API などがあります。

これらの技術により、フォールト トレラントで管理しやすく、監視しやすい疎結合システムの構築が可能になります。信頼性の高い自動化と組み合わせたクラウドネイティブ テクノロジーにより、エンジニアはシステムに頻繁かつ目に見える変更を簡単に加えることができます。

実際のところ、上記の定義はクラウド ネイティブが何であるかに関してまだ非常に曖昧です。ただし、上記の定義からいくつかの重要な情報を得ることができます。

1. クラウド ネイティブ アプリケーションはクラウド環境にデプロイする必要がありますが、クラウド環境にデプロイされたアプリケーションは必ずしもクラウド ネイティブ アプリケーションであるとは限りません。
2. クラウド ネイティブ アプリケーションには、一定のスケーラビリティ、フォールト トレランス、および可観測性が備わっています。
3. クラウド ネイティブはテクノロジーやフレームワークではなく、概念です。

これもわかりやすいですね。初期の頃は、企業がアプリケーションやサービスを立ち上げたい場合、マシンを購入してコンピュータ ルームを導入し、そのコンピュータ ルームのサーバーに独自のアプリケーションを導入する必要がありました。これは明らかにクラウド ネイティブではありません。結局のところ、クラウドはまだ開始されていません。

その後、多くのクラウドベンダーが登場し、クラウド環境を提供しました。現時点では、アプリケーションを展開する場合、独自のコンピューター ルームを構築する必要はなくなりました。クラウドベンダーから対応するデータセンター内のサーバーを購入するだけで、アプリケーションを展開できます。ただし、現時点では、アプリケーションはクラウド上にあるとしか言えず、アプリケーションはまだクラウド ネイティブ アプリケーションではありません。

これも上で述べた通りです。アプリケーションはクラウド環境にデプロイされますが、これはクラウド ネイティブ アプリケーションであることを意味するものではありません。現時点では、アプリケーションはクラウド ベンダーの機能を十分に活用しておらず、スケーラビリティ、フォールト トレランス、および可観測性も備えていないためです。

12要素の適用

以前、クラウドネイティブとは何かを紹介しました。それでは、12 要素アプリケーションとは何かについて説明しましょう。 12 ファクター アプリは、有名な PasS プラットフォーム Heroku の CTO である Adam Wiggins 氏によって提案されました。これはもともと、クラウド上で実行されるアプリケーションが従う必要がある 12 のベスト プラクティスを指していましたが、クラウド ネイティブ アプリケーションにも適用されます。

1. ベンチマークコード

ベンチマーク コードとは、日常の開発と展開において、開発、テスト、オンラインなど多くの環境が存在する可能性があり、同じベンチマーク コードが必要になることを意味します。ただし、ここで主に重点が置かれているのはオンラインです。クラウド ネイティブ アプリケーションのデプロイメントはいつでもどこでも動的に拡張できるため、オンライン環境がベースライン コードに基づいてデプロイされ、1 セットのコードに対して複数のデプロイメントを実装する必要があるためです。

これもわかりやすいですね。分散アーキテクチャと同様に、複数のインスタンスが同じコードでデプロイされます。

2. 宣言的依存関係

宣言的依存関係とは、依存関係を明示的に宣言する必要があることを意味します。現在、依存関係管理ツールは数多く存在します。たとえば、Java プロジェクトには Maven と Gradle が使用され、他の言語のプロジェクトにも他のパッケージ管理ツールが使用されます。

開発に必要なクラス ライブラリの明示的な依存関係に加えて、システム レベルのツールやライブラリにも依存する必要がある場合は、暗黙的な依存関係ではなく宣言的な依存関係も作成する必要があります。これは、クラウドネイティブ環境では、コンテナに基づいてアプリケーションをデプロイするためです。これらの依存関係を明示的に宣言しないと、同一のコンテナ イメージを作成できず、サービスが利用できなくなる可能性があります。

3. 構成管理

アプリケーションを正常に起動するには、正しいコードに加えて、正しい構成も必要です。クラウドネイティブアプリケーションでも同様です。環境に応じて異なる構成が必要です。環境が同じであれば、構成も同じである必要があります。また、構成をコードから分離する必要があり、これも理解しやすいです。結局のところ、アプリケーション コードを複数の環境にデプロイする必要があります。構成が同じであれば、展開する方法はありません。

構成管理は、Diamond やその他の構成センターなどのミドルウェアを使用して実行できます。構成センターでは、リアルタイムの変更と構成のプッシュを実現できるため、管理と変更が非常に便利になります。

4. バックエンドサービス

ここでのバックエンド サービスとは、メッセージ キュー、データベース、キャッシュ、スケジューリング プラットフォームなど、アプリケーションが依存するダウンストリーム サービス、コンポーネント サービス、ミドルウェア サービスを指します。クラウド ネイティブ アプリケーションでは、これらのバックエンド サービスをリソースとして呼び出す必要があり、これらのリソースもクラウド ネイティブ アプリケーションの仕様に準拠している必要があります。つまり、いつでも動的に拡張できる必要があります。

5. ビルド、リリース、実行

クラウドネイティブ アプリケーションでは、アプリケーションの構築、リリース、運用を厳密に分離する必要があります。これらのアプリケーション プロセスは、各要件の反復後にオンラインになるために必要であり、これらの手順がこの順序で実行されるため、ビルド前にリリースが存在しないことがわかりやすくなります。 Java アプリケーションの場合、ビルドとはソース コードをコンパイルしてパッケージ化することです。構築フェーズで失敗した場合、次のステップは実行されません。

アプリケーションをビルドするときに、依存関係が不足しているかコンパイル エラーがある場合は、ビルドが終了します。公開とは、コンパイルされた Jar パッケージまたはその他のフォームを構成ファイルとともに指定された環境のコンテナーにデプロイすることです。実行とは、公開するコンテンツを開始することです。現時点では、弊社の設定に問題がある場合、アプリケーションの起動に失敗する可能性があります。

6. プロセス

クラウドネイティブ アプリケーションでは、アプリケーションがステートレスである必要があります。これは理解しやすいですね。結局のところ、クラウドネイティブ アプリケーションはいつでもスケーラブルであるため、アプリケーションはステートレスである必要があります。このため、開発中にコード内で状態を必要とするロジックを使用しないように注意する必要があります。たとえば、スケジュールされたタスクにより各インスタンスがスケジュールに基づいて実行されるため、問題が発生する可能性があります。 XXL-JOB のような分散スケジューリング プラットフォームを使用できます。

7. ポートバインディング

アプリケーションはポートをバインドすることでサービスを提供します。ほとんどの場合、私たちはすでにこれを実行しているので、一部の友人はこれを理解できないかもしれません。その理由は、アプリケーション内でプロセス通信を使用しないようにするためです。

8. 同時実行性

高い同時実行性でのプロセス拡張をサポートする必要があるため、アプリケーションはステートレスである必要があり、より多くのプロセスを展開することで拡張できる必要があります。これも分かりやすく、先ほど述べた無国籍にも関係します。

9. 扱いやすい

いわゆる「扱いやすい」とは、クラウド ネイティブ アプリケーションがすばやく起動し、正常に終了できることを意味します。クラウドネイティブ環境では、容量を柔軟に拡張する機能が必要であるため、アプリケーションは迅速に起動および終了できる必要があります。

高速起動により、アプリケーションはより速くサービスを提供し、弾力的なスケーリング要件をより速く満たすことができます。また、正常な終了により、アプリケーションのシャットダウン時にタスクやトラフィックのアクセスを回避することもできます。

10. 開発環境はオンライン環境と同等

さらに、開発環境、プレリリース環境、オンライン クラウド ネイティブ環境を可能な限り同じ状態に保つ必要があります。もちろん、ここでの「同じ」とは、できるだけ同じに保つことを意味します。同じ環境であれば、実装した機能が環境の問題で利用できなくなることはありません。ただし、リソースの問題により、開発環境、プレリリース環境、オンライン環境がまったく同じにならないことに注意してください。

11. ログ

クラウド ネイティブでは、ログをイベント ストリームとして扱う必要があります。これは、クラウド ネイティブ アプリケーションのインスタンスの数は常に変化しており、各インスタンスが常にログを生成するためでもあります。各インスタンスのログを確認することはできないため、特定のログシステムにログを収集して収集する必要があります。これは実際には分散システムでも同じです。ログは通常、ELK テクノロジーを通じて保存および分析されます。

12. プロセスの管理

最後のポイントである「管理プロセス」は、バックグラウンド管理システムのタスクを 1 回限りのプロセスとして実行することを指します。実際、これは普遍的な要因ではなく、バックグラウンド システムの特定の機能に関連しています。ここでは議論しません。

要約する

上記では、クラウド ネイティブとは何か、そしてクラウド ネイティブ アプリケーションの 12 の要素について説明しました。それらの多くは分散システムの要件と一致していますが、クラウド ネイティブ アプリケーションの要件はより高く、より厳格で、より自動化されています。

全体的な観点から見ると、クラウド ネイティブ アプリケーションは現在、企業や個人にとって最善かつ最速で低コストの方法です。

多くの中小企業では、独自のインフラストラクチャを構築する必要はありません。クラウドベンダーが提供する機能を直接導入して、自社のビジネスを迅速に展開することができます。結局のところ、中小企業にとって最も重要なことは生き残ることであり、そのようなことに時間とエネルギーを浪費する必要はありません。

参照する

1. 入門からプロジェクト実践まで、Springを学ぶ
2. オンライン情報