次の方法で共有

概要: クラウドネイティブ アプリの設計

ヒント

このコンテンツは、Azure 用のクラウド ネイティブ .NET アプリケーションの設計に関する電子ブックからの抜粋であり、.NET Docs またはオフラインで読み取ることができる無料のダウンロード可能な PDF として入手できます。

PDF をダウンロードする

Azure eBook 用の Cloud Native .NET アプリの表紙サムネイル。

まとめると、このガイドの重要な結論を次に示します。

  • クラウドネイティブ とは、パブリック、プライベート、ハイブリッド クラウドなどの最新の動的な環境で、急速な変化、大規模、回復性を受け入れる最新のアプリケーションを設計することです。

  • 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 モデルを公開するデザインが現れます。

  • No-SQL データベース は、高パフォーマンスの非リレーショナル データ ストアを指します。 使いやすさ、スケーラビリティ、回復性、可用性の特性に優れています。 2 秒未満の応答時間を必要とする大量のサービスは、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 環境です。

前の