次の方法で共有

Azure Kubernetes Service 上のマイクロサービス アーキテクチャ

Microsoft Entra ID
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Load Balancer
Azure Pipelines
Azure Monitor

この参照アーキテクチャは、Azure Kubernetes Service (AKS) にデプロイされたマイクロサービス アプリケーションを示します。 ほとんどのデプロイの開始点として使用できる基本的な AKS 構成について説明します。 この記事では、Kubernetes に関する基本的な理解があることを前提としています。 この記事では主に、AKS でマイクロサービスを管理する方法のインフラストラクチャと DevOps の側面について説明します。 マイクロサービスを設計する方法の詳細については、「 マイクロサービス アーキテクチャの設計」を参照してください。

GitHub ロゴ。 このアーキテクチャのリファレンス実装は 、GitHub で入手できます。

アーキテクチャ

AKS 参照アーキテクチャ上のマイクロサービスを示す図。

Helm は、Cloud Native Computing Foundation (CNCF) の商標です。 このマークを使用することは、保証を意味するものではありません。

このアーキテクチャの Visio ファイルをダウンロードします。

AKS ベースライン アーキテクチャに基づいて構築されたより高度なマイクロサービスの例を確認する場合は、高度な AKS マイクロサービス アーキテクチャを参照してください。

Workflow

この要求フローは、 パブリッシャーサブスクライバー、 競合コンシューマー、 ゲートウェイ ルーティング クラウド設計パターンを実装します。

次のデータフローは、前の図に対応しています。

  1. クライアント アプリケーションは、HTTPS 経由で JSON ペイロードをロード バランサー (マネージド イングレス コントローラー) のパブリック完全修飾ドメイン名に送信して、ドローンピックアップをスケジュールします。

    • マネージド イングレス コントローラーは、要求をインジェスト マイクロサービスにルーティングします。

    • インジェスト マイクロサービスは要求を処理し、配信要求を Azure Service Bus キューにキューに入れます。

  2. ワークフロー マイクロサービス:

    • Service Bus メッセージ キューからメッセージ情報が使用されます。

    • HTTPS 要求を配信マイクロサービスに送信します。このマイクロサービスは、Azure Cache for Redis の外部データ ストレージにデータを渡します。

    • HTTPS 要求をドローン スケジューラ マイクロサービスに送信します。

    • パッケージ マイクロサービスに HTTPS 要求を送信し、MongoDB の外部データ ストレージにデータを渡します。

  3. HTTPS GET 要求は配信状態を返します。 この要求は、マネージド イングレス コントローラーを介して配信マイクロサービスに渡されます。 その後、配信マイクロサービスは Azure Cache for Redis からデータを読み取ります。

サンプル マイクロサービス アプリケーションの詳細については、「 マイクロサービスリファレンス実装サンプル」を参照してください。

コンポーネント

  • AKS は、Azure クラウドでホストされているマネージド Kubernetes クラスターです。 AKS では、責任の多くを Azure にオフロードすることで、Kubernetes の管理の複雑さと運用上のオーバーヘッドを軽減します。

  • イングレス サーバーは 、クラスター内のサービスに HTTP(S) ルートを公開します。 参照実装では、アプリケーション ルーティング アドオンを介して 、マネージド NGINX ベースのイングレス コントローラー を使用します。 イングレス コントローラーは、マイクロサービスの API ゲートウェイ パターンを実装します。

  • Azure SQL Database や Azure Cosmos DB などの外部データ ストアは、ステートレス マイクロサービスがデータやその他の状態情報を書き込むのに使用されます。 参照実装では、 Azure Cosmos DB、 Azure Cache for Redis、 MongoDB 用 Azure Cosmos DB 、 Service Bus をデータ ストアまたは状態を格納する場所として使用します。

  • AKS クラスターには Microsoft Entra ID が必要です。 Azure Container Registry にアクセスしたり、ロード バランサーやマネージド ディスクなどの Azure リソースにアクセスしてプロビジョニングしたりするために使用されるマネージド ID が 提供されます。 また、AKS クラスターにデプロイされたワークロードでは、Azure Key Vault や Microsoft Graph などの Microsoft Entra で保護されたリソースにアクセスするために、Microsoft Entra の ID も必要です。 この参照アーキテクチャでは、 Microsoft Entra Workload ID は Kubernetes と統合され、ID を使用してワークロードを提供します。 ワークロードごとにマネージド ID またはアプリケーション資格情報を使用することもできます。

  • Container Registry を使用して、クラスターにデプロイされるプライベート コンテナー イメージを格納できます。 AKS は、その Microsoft Entra ID を使用して Container Registry で認証できます。 参照実装では、マイクロサービス コンテナー イメージがビルドされ、Container Registry にプッシュされます。

  • Azure Pipelines は Azure DevOps スイートの一部であり、自動ビルド、テスト、デプロイを実行します。 マイクロサービス環境では 、継続的インテグレーションと継続的デプロイ (CI/CD) アプローチを強くお勧めします。 Azure Pipelines を使用して、さまざまなチームが個別にマイクロサービスを構築し、AKS にデプロイできます。

  • Helm は Kubernetes のパッケージ マネージャーであり、Kubernetes オブジェクトを 1 つのユニットにバンドルして標準化するメカニズムを提供します。これは、発行、デプロイ、バージョン管理、更新が可能です。

  • Azure Monitor は、Azure サービスのメトリックとログ、アプリケーション テレメトリ、プラットフォーム メトリックを収集して格納します。 Azure Monitor は、コントローラー、ノード、コンテナーからメトリックを収集するために AKS と統合します。

  • Application Insights は、 マイクロサービスとコンテナーを監視します。 これを使用すると、トラフィック フロー、エンドツーエンドの待機時間、エラーの割合など、マイクロサービスに可観測性を提供できます。 マイクロサービスの正常性とそれらの間のリレーションシップは、1 つのアプリケーション マップに表示できます。

選択肢

Azure Container Apps は、マネージド サーバーレス Kubernetes エクスペリエンスを提供します。 これは、Kubernetes またはその API に直接アクセスする必要がなく、クラスター インフラストラクチャを制御する必要がない場合に、マイクロサービスをホストするための AKS のより簡単な代替手段として機能します。

AKS のマネージド イングレス ゲートウェイの代わりに、Application Gateway for Containers、Istio イングレス ゲートウェイ、Microsoft 以外のソリューションなどの代替手段を使用できます。 詳細については、「 AKS のイングレス」を参照してください。

コンテナー イメージは、Docker Hub などの Microsoft 以外のコンテナー レジストリに格納できます。

状態情報を維持する必要があるマイクロサービスの場合、 Dapr はマイクロサービスの状態を管理するための抽象化レイヤーを提供します。

GitHub Actions を使用してマイクロサービスを構築してデプロイしたり、Jenkins などの Microsoft 以外の CI/CD ソリューションを選択したりできます。

マイクロサービスの可観測性は、 Kiali などの代替ツールを使用して実現できます。

シナリオの詳細

マイクロサービス参照実装の例では、この記事で説明するアーキテクチャ コンポーネントとプラクティスを実装します。 この例では、Fabrikam, Inc. という架空の会社がドローン航空機の艦隊を管理しています。 企業がサービスに登録すると、ユーザーは、ドローンで商品を集荷して配送するように依頼できます。 顧客が集荷をスケジュールすると、バックエンド システムはドローンを割り当て、推定配送時間をユーザーに通知します。 配送が進行中の場合、顧客は継続的に更新された推定配送時間でドローンの場所を追跡できます。

このシナリオでは、AKS のマイクロサービス アーキテクチャとデプロイのベスト プラクティスを示します。

考えられるユース ケース

AKS で複雑なマイクロサービス ベースのアプリケーションを設計するには、シナリオから次のベスト プラクティスを採用します。

  • 複雑な Web アプリケーション
  • マイクロサービス設計の原則を使用して開発されたビジネス ロジック

考慮事項

これらの考慮事項では、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、Microsoft Azure Well-Architected Frameworkの に関するページを参照してください。

デザイン

この参照アーキテクチャはマイクロサービスに焦点を当てていますが、推奨されるプラクティスの多くは、AKS で実行される他のワークロードに適用されます。

マイクロサービス

マイクロサービスは、コードの疎結合で、かつ独立にデプロイ可能な単位です。 マイクロサービスは通常、良定義された API 経由でやり取りされ、ある形式のサービス検出によって検出できます。 Kubernetes サービス オブジェクトは、Kubernetes でマイクロサービスをモデル化する一般的な方法です。

データ ストレージ

マイクロサービス アーキテクチャでは、サービスはデータ ストレージ ソリューションを共有しないでください。 各サービスは、サービス間の依存関係が隠されないように、独自のデータセットを管理する必要があります。 データの分離は、サービス間の意図しない結合を回避するのに役立ちます。 このプロセスは、サービスが同じ基になるデータ スキーマを共有する場合に発生する可能性があります。 サービスが独自のデータ ストアを管理する場合は、特定の要件に対して適切なデータ ストアを使用できます。 詳細については、「 マイクロサービスのデータに関する考慮事項」を参照してください。

このメソッドはデータをノードにバインドするため、永続的なデータをローカル クラスター ストレージに格納しないでください。 代わりに、SQL Database や Azure Cosmos DB などの外部サービスを使用してください。 もう 1 つのオプションは、Azure Disk Storage または Azure Files を使用してソリューションに永続的なデータ ボリュームをマウントすることです。 詳細については、AKS でのアプリケーションのストレージ オプションに関するページを参照してください。

API ゲートウェイ

API ゲートウェイは、一般的なマイクロサービスの設計パターンです。 API ゲートウェイは、外部クライアントとマイクロサービスの間に配置されます。 ゲートウェイはリバース プロキシとして機能し、クライアントからマイクロサービスに要求をルーティングします。 API ゲートウェイでは、認証、Secure Sockets Layer (SSL) 終端、レート制限など、さまざまな横断的なタスクを実行することもできます。 詳細については、次のリソースを参照してください。

Kubernetes では、イングレス コントローラーは主に API ゲートウェイの機能を処理します。 イングレス コントローラーとイングレス コントローラーは、次の機能を組み合わせて動作します。

  • クライアント要求を適切なバックエンド マイクロサービスにルーティングします。 このルーティングは、クライアントに単一のエンドポイントを提供し、クライアントをサービスから切り離すのに役立ちます。

  • クライアントとバックエンドの間のチャットを減らすために、複数の要求を 1 つの要求に集約します。

  • SSL 終了、認証、IP アドレス制限、クライアント レート制限 (調整と呼ばれます) など、バックエンド サービスから機能 をオフロードします。

リバース プロキシには、NGINX、HAProxy、Traefik、Azure Application Gateway などのイングレス コントローラーがあります。 AKS には、複数のマネージド イングレス オプションが用意されています。 マネージド NGINX ベースのイングレス コントローラーから、アプリケーション ルーティング アドオンである Application Gateway for Containers を使用して選択できます。 または、イングレス コントローラーとして Istio イングレス ゲートウェイを選択することもできます。 詳細については、「 AKS のイングレス」を参照してください。

イングレス リソース Kubernetes オブジェクトは、より高度で汎用性の高い Kubernetes Gateway API に置き換えられました。 イングレス コントローラーとゲートウェイ API はどちらも、トラフィック管理のルーティングと負荷分散に使用される Kubernetes オブジェクトです。 ゲートウェイ API は、汎用、表現力、拡張性、ロール指向で設計されており、Kubernetes で L4 および L7 ルーティング規則を定義するための最新の API セットです。

イングレス コントローラーは、エッジ ルーターまたはリバース プロキシとして動作します。 リバース プロキシ サーバーは潜在的なボトルネックまたは単一障害点であるため、高可用性を確保するために少なくとも 2 つのレプリカをデプロイすることをお勧めします。

イングレス コントローラーまたはゲートウェイ API を選択するタイミング

イングレス リソースは、次のユース ケースに適しています。

  • イングレス コントローラーは簡単に設定でき、簡単な構成を優先する小規模で複雑でない Kubernetes デプロイに適しています。

  • 現在、Kubernetes クラスターでイングレス コントローラーが構成されていて、要件を効果的に満たしている場合は、Kubernetes Gateway API にすぐに移行する必要がない可能性があります。

ゲートウェイ API を使用する必要があります。

  • 複雑なルーティング構成、トラフィックの分割、高度なトラフィック管理戦略に対処する場合。 Kubernetes Gateway API の Route リソースによって提供される柔軟性は不可欠です。

  • ネットワーク要件にカスタム ソリューションまたは Microsoft 以外のプラグインの統合が必要な場合。 Kubernetes Gateway API のアプローチは、カスタム リソース定義に基づいて拡張を提供できます。

信頼性

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。

マイクロサービスのパーティション分割

クラスター内のサービスを整理するには、名前空間を使用します。 Kubernetes クラスター内のオブジェクトはすべて、名前空間に属します。 名前空間を使用してクラスター内のリソースを整理することをお勧めします。

名前空間は、名前の競合を防ぐのに役立ちます。 複数のチームが (数百ある可能性がある) マイクロサービスを同じクラスターにデプロイするとき、それらがすべて同じ名前空間に移動すると管理が困難になります。 名前空間では、次のことも可能です。

  • 名前空間に割り当てられたポッドの合計セットが名前空間のリソース クォータを超えないように、名前空間にリソース制約を適用します。

  • 名前空間レベルでポリシーを適用します。これには、ロールベースのアクセス制御 (RBAC) とセキュリティ ポリシーが含まれます。

複数のチームがマイクロサービスを開発してデプロイするときに、各チームがデプロイできる領域を制御するための便利なメカニズムとして名前空間を使用できます。 たとえば、開発チーム A には名前空間 A へのアクセス権のみを付与でき、開発チーム B には Kubernetes RBAC ポリシーを使用して名前空間 B へのアクセスのみを許可できます。

マイクロサービス アーキテクチャの場合は、マイクロサービスを境界付きコンテキストに整理し、各境界コンテキストの名前空間を作成することを検討してください。 たとえば、"Order Fulfillment" の境界付けられたコンテキストに関連するすべてのマイクロサービスは、同じ名前空間に入ることができます。 あるいは、開発チームごとに名前空間を作成します。

ユーティリティ サービスをその独自の個別の名前空間に配置します。 たとえば、Elasticsearch や Prometheus などのクラスター監視ツールを監視名前空間にデプロイできます。

正常性プローブ

Kubernetes は、ポッドが公開できる 3 種類の正常性プローブを定義します。

  • 準備プローブ: ポッドが要求を受け入れる準備ができているかどうかを Kubernetes に通知します。

  • Liveness Probe: ポッドを削除して新しいインスタンスを開始するかどうかを Kubernetes に指示します。

  • スタートアップ プローブ: ポッドが起動されているかどうかを Kubernetes に通知します。

プローブについて考えるときは、Kubernetes でのサービスのしくみを覚えておく必要があります。 サービスには、0 個以上のポッドのセットに一致するラベル セレクターがあります。 Kubernetes は、そのセレクターに一致するポッドへのトラフィックを負荷分散します。 正常に開始され、正常なポッドのみがトラフィックを受信します。 コンテナーがクラッシュした場合、Kubernetes はポッドを終了し、置換をスケジュールします。

正常に開始された場合でも、ポッドがトラフィックを受信する準備ができていない場合があります。 たとえば、コンテナーで実行されているアプリケーションがメモリにデータを読み込んだり、構成ファイルを読み取ったりする場合など、初期化タスクが進行中である可能性があります。 これらの低速開始コンテナーにはスタートアップ プローブを使用できます。 この方法は、Kubernetes が完全に初期化される前に、それらを終了するのを防ぐのに役立ちます。

Liveness プローブは、ポッドが実行されているが正常に動作せず、再起動する必要があるかどうかを確認するために使用されます。 たとえば、コンテナーが HTTP 要求を処理しているが、クラッシュせずに突然応答を停止した場合、ライブネス プローブはこのイベントを検出し、ポッドの再起動をトリガーします。 ライブネス プローブを設定すると、コンテナーが応答していないときに通知され、コンテナーがプローブに繰り返し失敗した場合にポッドを再起動するように Kubernetes に求められます。

マイクロサービスのプローブを設計するときは、次の点を考慮してください。

  • コードの起動時間が長い場合は、起動が完了する前にライブネス プローブでエラーが報告される危険性があります。 ライブネス プローブの開始を遅らせるには、スタートアップ プローブを使用するか、ライブネス プローブで initialDelaySeconds 設定を使用します。

  • ライブネス プローブは、ポッドを再起動して正常な状態に復元する可能性がある場合にのみ役立ちます。 ライブネス プローブを使用してメモリ リークや予期しないデッドロックを軽減できますが、すぐに失敗するポッドを再起動する理由はありません。

  • 依存サービスをチェックするために準備プローブが使用される場合があります。 たとえば、ポッドにデータベースへの依存関係がある場合は、probe がデータベース接続をチェックすることがあります。 ただし、このアプローチにより、予期しない問題が発生する場合があります。 外部サービスが一時的に使用できない場合があります。 この使用不能により、サービス内のすべてのポッドの準備プローブが失敗し、負荷分散から削除されます。 この削除により、連鎖的な障害がアップストリームに作成されます。

    サービスが一時的な障害から正しく復旧できるように、サービス内に再試行処理を実装することをお勧めします。 別の方法として、再試行処理、エラー許容度、およびサーキット ブレーカーを Istio サービス メッシュ によって実装して、マイクロサービスの障害を処理できる回復性のあるアーキテクチャを作成できます。

リソース制約

リソースの競合がサービスの可用性に影響を与える場合があります。 1 つのコンテナーがメモリや CPU などのクラスター リソースに負荷をかけないように、コンテナーのリソース 制約 を定義します。 スレッドやネットワーク接続などのコンテナー以外のリソースの場合は、 Bulkhead パターン を使用してリソースを分離することを検討してください。

リソース クォータを使用して、名前空間に許可されるリソースの合計を制限します。 この制限により、フロントエンドがリソースのバックエンド サービスを使い切ったり、その逆を実行したりできなくなります。 リソース クォータは、同じクラスター内のリソースを複数のマイクロサービス開発チームに割り当てるのに役立ちます。

セキュリティ

セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。 詳細については、「セキュリティ設計レビューチェックリスト」を参照してください。

TLS と SSL 暗号化

多くの実装では、イングレス コントローラーが SSL 終了に使用されます。 イングレス コントローラーのデプロイの一環として、トランスポート層セキュリティ (TLS) 証明書を作成またはインポートする必要があります。 開発およびテスト目的でのみ自己署名証明書を使用します。 詳細については、「 アプリケーション ルーティング アドオンを使用してカスタム ドメイン名と SSL 証明書を設定する」を参照してください。

運用ワークロードの場合は、信頼された証明機関から署名された証明書を取得します。

また、組織のポリシーに応じて証明書のローテーションが必要になる場合もあります。 Key Vault を使用して、マイクロサービスが使用する証明書をローテーションできます。 詳細については、「 Key Vault での証明書の自動ローテーションの構成」を参照してください。

RBAC

複数のチームが同時にマイクロサービスを開発してデプロイする場合、AKS RBAC メカニズムでは、ユーザー アクションをきめ細かく制御およびフィルター処理できます。 Kubernetes RBAC または Azure RBAC と Microsoft Entra ID を使用して、クラスター リソースへのアクセスを制御できます。 詳細については、「AKS のアクセスと ID のオプション」をご覧ください。

認証と承認

マイクロサービスでは、証明書、資格情報、RBAC メカニズムを使用して、使用するサービスまたはユーザーがマイクロサービスへのアクセスを認証および承認する必要があります。 Microsoft Entra ID を使用して、 承認のために OAuth 2.0 トークンを実装できます。 Istio などのサービス メッシュでは、OAuth トークンの検証やトークンベースのルーティングなど、マイクロサービスの承認と認証のメカニズムも提供されます。 参照実装では、マイクロサービスの認証と承認のシナリオについては説明しません。

シークレットの管理とアプリケーションの資格情報

アプリケーションやサービスには、多くの場合、Azure Storage や SQL Database などの外部サービスに接続できるようにするための資格情報が必要です。 これらの資格情報を安全に保持し、漏洩させないことが課題になります。

Azure リソースの場合は、可能な場合はマネージド ID を使用します。 マネージド ID は、Microsoft Entra ID に格納されているアプリケーションまたはサービスの一意の ID のようなものです。 この ID を使用して、Azure サービスで認証します。 アプリケーションまたはサービスには、Microsoft Entra ID でサービス プリンシパルが作成され、OAuth 2.0 トークンを使用して認証されます。 プロセス内で実行されているコードは、トークンを透過的に取得できます。 この方法により、パスワードや接続文字列を格納する必要がなくなります。 マネージド ID を使用するには、Microsoft Entra ワークロード ID を使用して、AKS の個々のポッドに Microsoft Entra ID を割り当てることができます。

マネージド ID を使用する場合でも、資格情報やその他のアプリケーション シークレットを格納する必要がある場合があります。 このストレージは、マネージド ID、Microsoft 以外のサービス、または API キーをサポートしていない Azure サービスに必要です。 シークレットをより安全に格納するには、次のオプションを使用できます。

Key Vault のようなソリューションを使用すると、次のようないくつかの利点があります。

  • シークレットの集中制御。
  • すべてのシークレットが保存時に暗号化されるように支援します。
  • キーの集中管理。
  • シークレットのアクセス制御。
  • 主要なライフサイクル管理。
  • 聴講。

参照実装では、Azure Cosmos DB 接続文字列とその他のシークレットが Key Vault に格納されます。 参照実装では、マイクロサービスのマネージド ID を使用して Key Vault に対する認証とシークレットへのアクセスを行います。

コンテナーとオーケストレーターのセキュリティ

次の推奨プラクティスは、ポッドとコンテナーをセキュリティで保護するのに役立ちます。

  • 脅威を監視します。 Microsoft Defender for Containers または Microsoft 以外の機能を使用して脅威を監視します。 仮想マシン (VM) でコンテナーをホストする場合は、 Microsoft Defender for Servers または Microsoft 以外の機能を使用します。 さらに、 Azure Monitor のコンテナー監視ソリューション のログを Microsoft Sentinel または既存のセキュリティ情報イベント管理 (SIEM) ソリューションに統合できます。

  • 脆弱性を監視します。 Microsoft Defender for Cloud または Microsoft 以外のソリューションを使用して、既知の脆弱性のイメージと実行中のコンテナーを継続的に監視します。

  • イメージの修正プログラムの適用を自動化します。 イメージの修正プログラムの適用を自動化するには、Container Registry の機能である Azure Container Registry タスクを使用します。 コンテナー イメージは、レイヤーから構築されます。 基本レイヤーには、OS イメージとアプリケーション フレームワーク イメージ (ASP.NET Core や Node.js など) が含まれます。 基本イメージは通常、アプリケーション開発者から上流に作成され、他のプロジェクト 保守担当者がそれらを維持します。 これらのイメージにパッチが適用されている場合は、既知のセキュリティ脆弱性を残さないように、独自のイメージを更新、テスト、再デプロイすることが重要です。 Azure Container Registry タスクは、このプロセスの自動化に役立ちます。

  • 信頼されたプライベート レジストリにイメージを格納します。 イメージを格納するには、Container Registry や Docker Trusted Registry などの信頼されたプライベート レジストリを使用します。 Kubernetes で検証アドミッション Webhook を使用して、ポッドが信頼されたレジストリからのみイメージを取得できるようにします。

  • 最小特権の原則を適用する。 コンテナーを特権モードで実行しないでください。 特権モードは、ホスト上のすべてのデバイスにコンテナー アクセスを提供します。 可能な場合は、コンテナー内での root としてのプロセスの実行を回避してください。 コンテナーはセキュリティの観点から完全に分離されないため、非特権ユーザーとしてコンテナー プロセスを実行することをお勧めします。

デプロイ CI/CD に関する考慮事項

マイクロサービス アーキテクチャの堅牢な CI/CD プロセスの次の目標を検討してください。

  • 各チームは、他のチームに影響を与えたり妨害したりすることなく、独立に所有するサービスを構築およびデプロイできます。

  • 新しいバージョンのサービスが運用環境にデプロイされる前に、検証のために開発、テスト、および Q&A 環境にデプロイされます。 品質ゲートは、各段階で適用されます。

  • サービスの新しいバージョンは、以前のバージョンと並行してデプロイできます。

  • 十分なアクセス制御ポリシーが設定されています。

  • コンテナー化されたワークロードの場合、運用環境にデプロイされているコンテナー イメージを信頼できます。

問題の詳細については、「CI/CD for microservices architectures」 (マイクロサービス アーキテクチャ用の CI/CD) を参照してください。

Istio などのサービス メッシュを使用すると、カナリア デプロイ、マイクロサービスの A/B テスト、割合ベースのトラフィック分割による段階的ロールアウトなどの CI/CD プロセスに役立ちます。

具体的な推奨事項とベスト プラクティスの詳細については、「 Azure DevOps と Helm を使用して Kubernetes 上のマイクロサービス用の CI/CD パイプラインを構築する」を参照してください。

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コストの最適化設計レビューチェックリスト」を参照してください。

コストの見積もりには、Azure 料金計算ツールをご利用ください。 その他の考慮事項については、Microsoft Azure Well-Architected Framework のコストに関するセクションを参照してください。

このアーキテクチャで使用される一部のサービスについては、次の点を考慮してください。

AKS

  • Free レベルでは、Kubernetes クラスターのデプロイ、管理、および操作における AKS に関連するコストはありません。 Kubernetes クラスターが使用する VM インスタンス、ストレージ、およびネットワーク リソースに対してのみ課金されます。

  • 水平ポッド オートスケーラーを使用して、負荷に応じてマイクロサービスを自動的にスケールインまたはスケールアウトすることを検討してください。

  • 負荷に応じてノードをスケールインまたはスケールアウトするように クラスター オートスケーラー を構成します。

  • スポット ノードを使用して重要でないマイクロサービスをホストすることを検討してください。

  • AKS のコスト最適化のベスト プラクティスを確認します。

  • 必要なリソースのコストを見積もるために、 AKS 計算ツールを使用します。

Azure Load Balancer

構成された負荷分散およびアウトバウンド規則の数に対してのみ課金されます。 受信ネットワーク アドレス変換規則は無料です。 規則が構成されていない場合、Standard Load Balancer に対する時間あたりの料金は発生しません。 詳細については、 Azure Load Balancer の価格に関するページを参照してください。

Azure Pipelines

この参照アーキテクチャでは、Azure Pipelines のみが使用されます。 Azure は、個々のサービスとしてパイプラインを提供します。 CI/CD の場合は毎月 1,800 分、セルフホステッド ジョブは 1 か月ごとに無制限の分で、無料の Microsoft でホストされるジョブが許可されます。 追加のジョブでは、より多くのコストが発生します。 詳細については、 Azure DevOps サービスの価格に関するページを参照してください。

Azure Monitor

Azure Monitor Log Analytics では、データ インジェストとデータの保持について料金が発生します。 詳細については、「Azure Monitor の価格」を参照してください。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは、アプリケーションをデプロイし、運用環境で実行し続ける運用プロセスを対象としています。 詳細については、「オペレーショナル エクセレンス設計レビュー チェックリスト」を参照してください。

この参照アーキテクチャには、クラウド リソースとその依存関係をプロビジョニングするための Bicep ファイル が含まれています。 Azure Pipelines を使用して、これらの Bicep ファイルをデプロイし、運用環境のシナリオのレプリケートなど、さまざまな環境をすばやく設定できます。 この方法は、必要な場合にのみロード テスト環境をプロビジョニングすることでコストを節約するのに役立ちます。

ワークロードの分離基準に従って、Bicep ファイルを構成することを検討してください。 ワークロードは通常、任意の機能単位として定義されます。 たとえば、クラスター用の別の Bicep ファイルと、依存サービス用の別のファイルを作成できます。 各ワークロードは独自のチームによって関連付けおよび管理されるため、Azure DevOps を使用して、ワークロードの分離で CI/CD を実行できます。

このシナリオのデプロイ

このアーキテクチャの参照実装をデプロイするには、GitHub リポジトリの手順に従ってください。 詳細については、「 AKS マイクロサービスのリファレンス実装」を参照してください。

貢献者達

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

主要著者:

その他の共同作成者:

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ