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

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

クラウドネイティブ

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

クラウドネイティブテクノロジーにより、組織はパブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの新しい動的環境で、弾力的にスケーラブルなアプリケーションを構築および実行できるようになります。代表的なクラウドネイティブテクノロジーには、コンテナー、サービスメッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API などがあります。
これらの技術により、フォールトトレラントで管理しやすく、監視しやすい疎結合システムの構築が可能になります。信頼性の高い自動化と組み合わせたクラウドネイティブテクノロジーにより、エンジニアはシステムに頻繁かつ目に見える変更を簡単に加えることができます。

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

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

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

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

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

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 テクノロジーを通じて保存および分析されます。