次の方法で共有

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

Microsoft Entra ID
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure マネージド再配布
Azure Pipelines
Azure Monitor

このアーキテクチャは、Azure Kubernetes Service (AKS) にデプロイされたマイクロサービス アプリケーションを示しています。 ほとんどのデプロイの開始点として使用できる基本的な AKS 構成について説明します。 この記事では、Kubernetes に関する基本的な理解があることを前提としています。 AKS でマイクロサービスを管理する方法のインフラストラクチャと開発者操作 (DevOps) の側面について説明します。 運用環境のデプロイでは、このアーキテクチャでは、Cilium を搭載した Azure CNI をネットワーク ソリューションとして使用することをお勧めします。 このサービスは、拡張されたカリフォルニア パケット フィルター (eBPF) ベースのデータ プレーンを使用して、パフォーマンスの向上、組み込みのネットワーク ポリシーの適用、および監視性の強化を提供します。 マイクロサービスを設計する方法の詳細については、「 マイクロサービス アーキテクチャの設計」を参照してください。

Architecture

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

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

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

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

データ フロー

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

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

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

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

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

  2. ワークフロー マイクロサービスは、次のアクションを実行します。

    • Service Bus メッセージ キューからメッセージ情報を使用します

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

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

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

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

Components

  • AKS は、マイクロサービス コンテナーをホストおよび調整するマネージド Kubernetes サービスです。 このアーキテクチャでは、AKS は、ドローン配送アプリケーションのマイクロサービスをデプロイ、スケーリング、および管理するためのランタイム プラットフォームを提供します。

  • Cilium を利用した Azure CNI は、Azure 仮想ネットワークに直接接続するための推奨ネットワーク ソリューションです。 このアーキテクチャでは、仮想ネットワークからポッドに IP アドレスを割り当て、組み込みのネットワーク ポリシー機能とトラフィックの可視性を提供します。

  • イングレス サーバーは、クラスター内のサービスに HTTP ルートと HTTPS ルートを公開します。 このアーキテクチャでは、 マネージド NGINX ベースのイングレス コントローラー がアプリケーション ルーティング アドオンを通じて使用されます。 イングレス コントローラーは、マイクロサービスの API ゲートウェイ パターンを実装します。

  • Azure SQL Database や Azure Cosmos DB などの外部データ ストアは、ステートレス マイクロサービスによってデータやその他の状態情報を書き込むのに使用されます。 このアーキテクチャでは、 Azure Cosmos DB、 Azure Managed Redis、 Azure DocumentDB 、 Service Bus がデータ ストアまたは状態を格納する場所として機能します。

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

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

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

  • Helm は Kubernetes のパッケージ マネージャーであり、Kubernetes オブジェクトを 1 つのユニットにバンドルして標準化するメカニズムを提供し、発行、デプロイ、バージョン管理、更新を行うことができます。 このアーキテクチャでは、Helm は AKS にデプロイするためにドローン配信マイクロサービスをパッケージ化します。

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

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

Alternatives

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

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

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

ネットワークの場合、このアーキテクチャでは Cilium を利用した Azure CNI のパフォーマンスと組み込みのポリシーの適用が推奨されますが、特定のシナリオでは Azure CNI オーバーレイなどの代替ネットワーク ソリューションを使用できます。

Important

マイクロサービス アーキテクチャで Windows ノードが必要な場合は、Cilium の現在の Linux のみの 制限事項を確認し、混合 OS プールに対して適切に計画します。 詳細については、 Cilium の制限を利用した Azure CNI に関するページを参照してください。

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

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

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

シナリオの詳細

Fabrikam, Inc.という架空の会社がドローン航空機の艦隊を管理しています。 企業がサービスに登録すると、ユーザーは、ドローンで商品を集荷して配送するように依頼できます。 顧客が集荷をスケジュールすると、バックエンド システムはドローンを割り当て、推定配送時間をユーザーに通知します。 配送が進行中の場合、顧客は継続的に更新された推定配送時間でドローンの場所を追跡できます。

考えられるユース ケース

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

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

Considerations

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

Design

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

Microservices

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

データ ストレージ

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

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

ネットワークとネットワーク ポリシー

AKS での運用マイクロサービスのデプロイでは、 Cilium を利用した Azure CNI をネットワーク ソリューションとして使用します。 この方法には、マイクロサービス アーキテクチャに関するいくつかの利点があります。

  • パフォーマンスとスケーラビリティ: eBPF ベースのデータ プレーンは、サービス ルーティングのパフォーマンスを向上させ、従来のネットワーク ソリューションと比較して待機時間が短い大規模なクラスターをサポートします。

  • ネットワーク ポリシーの適用: Cilium は、Azure Network Policy Manager や Calico などの別のネットワーク ポリシー エンジンを必要とせずに、Kubernetes NetworkPolicy リソースを適用します。 この統合により、クラスターの構成が簡略化され、運用オーバーヘッドが削減されます。

  • 可観測性: eBPF データ プレーンは、ドメイン ネーム システム (DNS) クエリ、ポッド間フロー、サービス間通信など、ネットワーク トラフィックを可視化します。 この可視性は、マイクロサービスの相互作用のトラブルシューティングとパフォーマンスのボトルネックの特定に役立ちます。

  • 柔軟な IP アドレス管理: Cilium を利用した Azure CNI では、ワークロードのネットワーク アーキテクチャ要件に基づいて、仮想ネットワーク ルーティングモデルとオーバーレイ ポッド IP アドレス割り当てモデルの両方がサポートされます。

マイクロサービスのネットワーク ポリシーを実装する場合は、相互に通信できるサービスを明示的に定義することで、ゼロ トラスト アーキテクチャの原則に従います。 すべて拒否ポリシーから開始し、マイクロサービス間で必要なトラフィックのみを選択的に許可します。 詳細については、「 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 は、イングレス リソースをより高度で汎用性の高いゲートウェイ API に置き換えています。 イングレス コントローラーとゲートウェイ API は、トラフィック ルーティングと負荷分散を管理する Kubernetes オブジェクトです。 ゲートウェイ API は、汎用、表現力、拡張性、ロール指向で設計されており、Kubernetes でレベル 4 とレベル 7 のルーティング規則を定義するための最新の API セットです。

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

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

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

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

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

次の要因が適用される場合は、ゲートウェイ API を使用します。

  • 複雑なルーティング構成、トラフィックの分割、高度なトラフィック管理戦略に対処する場合。 Kubernetes Gateway API Route リソースは、このような場合に必要な柔軟性を提供します。

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

Reliability

信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。

マイクロサービスの分割

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

名前空間は、名前の競合を防ぐのに役立ちます。 複数のチームがマイクロサービスを同じクラスターにデプロイし、場合によっては数百ものマイクロサービスを使用する場合、1 つの名前空間でマイクロサービスを管理することは困難になります。 名前空間では、次のアクションも実行できます。

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

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

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

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

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

ヘルスプローブ

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

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

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

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

プローブを理解するには、まず Kubernetes でのサービスの動作を確認します。 サービスには、0 個以上のポッドのセットに一致するラベル セレクターがあります。 Kubernetes は、そのセレクターに一致するポッドへのトラフィックを負荷分散します。 正常に開始され、正常なポッドのみがトラフィックを受信します。 コンテナーがクラッシュした場合、Kubernetes はポッドを終了し、置換をスケジュールします。

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

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

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

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

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

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

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

マイクロサービスの正常性に関する問題のトラブルシューティングを行うには、 Advanced Container Networking Services のネットワーク監視機能を使用します。 eBPF データ プレーンは、マイクロサービス間の詳細なネットワーク フロー情報をキャプチャします。これにより、接続の問題、DNS 解決の問題、またはサービスの正常性に影響を与える可能性があるネットワーク ポリシーの構成ミスを特定できます。

リソース制約

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

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

セキュリティ

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

TLS と SSL 暗号化

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

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

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

ネットワークのセグメント化とポリシー

Kubernetes NetworkPolicy リソースを使用して、マイクロサービス間のネットワーク セグメント化を実装します。 Cilium を利用する Azure CNI を使用すると、eBPF データ プレーンによってネットワーク ポリシーが適用されます。

マイクロサービス アーキテクチャのネットワーク ポリシーのベスト プラクティスに従います。

  • ゼロ トラスト原則を適用します。 まず、名前空間レベルですべてのネットワーク ポリシーを拒否し、マイクロサービス間で必要なトラフィックのみを明示的に許可します。

  • 境界付けられたコンテキストでセグメント化します。 マイクロサービス アーキテクチャで境界付けられた各コンテキストの名前空間を作成し、ネットワーク ポリシーを適用してこれらのコンテキスト間のトラフィックを制御します。

  • アウトバウンドトラフィックを制御します。 ネットワーク ポリシーを使用して、マイクロサービスからの送信トラフィックを承認済みの外部サービスとエンドポイントのみに制限します。

  • ポリシーの有効性を監視します。 Cilium eBPF データ プレーンの監視機能を使用して、ネットワーク ポリシーの適用を監視し、構成ミスやセキュリティの問題を示す可能性があるブロックされたトラフィックを特定します。

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 などのソリューションを使用して、次の利点を得ます。

  • シークレットの一元管理
  • 保存中のシークレットの暗号化
  • 一元化されたキー管理
  • シークレットのアクセス制御
  • 重要なライフサイクル管理
  • Auditing

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

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

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

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

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

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

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

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

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

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

課題の詳細については、 マイクロサービス アーキテクチャの CI/CD を参照してください。

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

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

コストの最適化

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

コストの見積もりには、Azure 料金計算ツールをご利用ください。

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

AKS

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

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

  • 負荷に応じてノードをスケールインまたはスケールアウトするように Cluster Austoscaler (CA) を構成します。

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

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

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

Azure Load Balancer

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

Azure Pipelines

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

Azure Monitor

Log Analytics の場合、データインジェストとリテンション期間に対して課金されます。 詳細については、「Azure Monitor の価格」を参照してください。

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

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

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

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

Contributors

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

主要著者:

その他の共同作成者:

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

次のステップ