概要: クラウドネイティブ アプリの設計
ヒント
このコンテンツは eBook の「Azure 向けクラウド ネイティブ .NET アプリケーションの設計」からの抜粋です。.NET Docs で閲覧できるほか、PDF として無料ダウンロードすると、オンラインで閲覧できます。
要約すると、このガイドの重要な結論は次のとおりです。
クラウドネイティブとは、パブリック、プライベート、ハイブリッド クラウドなどの最新の動的な環境内で、迅速な変更、大規模性、および回復性を活用する最新のアプリケーションの設計に関するものです。
Cloud Native Computing Foundation (CNCF) は、300 社を超える主要企業から構成される影響力のあるオープンソース コンソーシアムです。 これは、テクノロジとクラウド スタック全体でクラウドネイティブ コンピューティングの導入を推進する役割を担います。
CNCF ガイドラインでは、図 11-1 に示すように、クラウドネイティブ アプリケーションで 6 つの重要な柱を採用することが推奨されています。
図 11-1. クラウドネイティブの基本的な柱
次のようなクラウドネイティブの柱があります。
- クラウドおよびその基盤となるサービス モデル
- 最新の設計原則
- マイクロサービス
- コンテナ化とコンテナーのオーケストレーション
- データベースやメッセージ ブローカーなどのクラウドベースのバッキング サービス
- コードとしてのインフラストラクチャやコード デプロイを含む自動化
Kubernetes は、ほとんどのクラウドネイティブ アプリケーションに適したホスティング環境です。 小規模でシンプルなサービスは、Azure Functions などのサーバーレス プラットフォームにホストされることがあります。 多くの主要な自動化機能の中から、変動するワークロード ボリュームを処理するための自動スケーリングが両方の環境に用意されています。
サービス通信は、クラウドネイティブ アプリケーションを構築する場合の設計上の重要な決定事項になります。 通常は、アプリケーションによって、フロントエンド クライアントの通信を管理するための API ゲートウェイが公開されます。 その後、バックエンド マイクロサービスは、可能な場合に非同期通信パターンを実装して相互に通信するように努めます。
gRPC は、古いリモート プロシージャ コール (RPC) プロトコルを進化させる最新のハイパフォーマンス フレームワークです。 多くの場合、クラウドネイティブ アプリケーションでは、gRPC を利用してバックエンド サービス間のメッセージングが合理化されます。 gRPC では、トランスポート プロトコルとして HTTP/2 が使用されます。 メッセージ サイズが 60-80% 小さいので JSON シリアル化よりも最大 8 倍高速になる可能性があります。 gRPC はオープンソースであり、Cloud Native Computing Foundation (CNCF) によって管理されています。
分散データは、クラウドネイティブ アプリケーションによって実装されることが多いモデルです。 アプリケーションによって、ビジネス機能が独立した小規模なマイクロサービスに分離されます。 各マイクロサービスによって、独自の依存関係、データ、および状態がカプセル化されます。 従来の共有データベース モデルは、それぞれがマイクロサービスに合致する多数の小さなデータベースの 1 つに発展します。 結果が明らかになったら、新しい設計で
database-per-microserviceモデルを公開します。NoSQL データベースは、ハイパフォーマンスの非リレーショナル データ ストアを意味します。 これらは、使いやすさ、スケーラビリティ、回復性、可用性の特性に優れています。 1 秒未満の応答時間を必要とする高ボリューム サービスでは、NoSQL データストアが有利です。 分散型クラウドネイティブ システム用の NoSQL テクノロジが広まっていることは、どれだけ強調しても足りません。
NewSQL は、NoSQL の分散型スケーラビリティとリレーショナル データベースの ACID 保証を組み合わせた新しいデータベース テクノロジです。 NewSQL データベースは、完全なトランザクション/ACID コンプライアンスを備えた、分散環境全体で大量のデータを処理する必要があるビジネス システムを対象としています。 Cloud Native Computing Foundation (CNCF) には、いくつかの NewSQL データベース プロジェクトがあります。
回復性は、システムが障害に対処して機能を継続する能力です。 クラウドネイティブ システムには分散アーキテクチャが採用されているため、障害は避けられません。 アプリケーションは、障害に対して適切に対応し、完全に機能する状態にすばやく戻るように構築されている必要があります。
サービス メッシュは構成可能なインフラストラクチャ レイヤーであり、サービス通信やその他の横断的な課題に対応する機能が組み込まれています。 横断的な役割はビジネス コードから分離されます。 これらの役割は、サービス プロキシに移行されます。 ビジネス コードから分離するために
Sidecar patternと呼ばれるプロキシが別のプロセスにデプロイされます。監視は、クラウドネイティブ アプリケーションの設計上の重要な考慮事項です。 サービスはノードのクラスター全体に分散されるため、ログ記録、モニタリング、およびアラートの一元化が必須となります。 Azure Monitor は、システムの状態の可視性を提供するように設計されたクラウドベース ツールのコレクションです。
コードとしてのインフラストラクチャは、プラットフォームのプロビジョニングを自動化する、広く受け入れられたプラクティスです。 インフラストラクチャとデプロイは、自動化され、一貫した、反復可能なものになります。 Azure Resource Manager、Terraform、Azure CLI などのツールを使用すると、必要なクラウド インフラストラクチャを宣言によってスクリプト化できます。
コード オートメーションは、クラウドネイティブ アプリケーションの要件です。 最新の CI/CD システムは、この原則に従うのに役立ちます。 一貫性のある高品質なコードの実現に役立つ個別のビルドとデプロイの手順が用意されています。 ビルド ステージでは、コードがバイナリ成果物に変換されます。 リリース ステージでは、バイナリ成果物が取得され、外部環境構成が適用されて、指定した環境にデプロイされます。 Azure DevOps と GitHub は、フル機能の DevOps 環境です。
.NET