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

この参照アーキテクチャは、Azure Kubernetes Service (AKS) にデプロイされたマイクロサービス アプリケーションを示します。 ここには、ほとんどのデプロイの出発点にすることができる基本的な AKS 構成が示されています。 この記事では、Kubernetes の基本的な知識を前提にしています。 この記事は主に、AKS 上でマイクロサービス アーキテクチャを実行するためのインフラストラクチャと DevOps に関する考慮事項に重点を置いています。 マイクロサービスを設計する方法については、「Azure でのマイクロサービスの構築」を参照してください。

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

アーキテクチャ

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

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

ワークフロー

アーキテクチャは、次のコンポーネントで構成されます。

Azure Kubernetes Service (AKS)。 AKS は、Azure クラウドでホストされているマネージド Kubernetes クラスターです。 Azure が Kubernetes API サービスを管理するため、エージェント ノードのみを管理するだけで済みます。

Virtual network。 既定では、AKS は、エージェント ノードが接続されている仮想ネットワークを作成します。 より高度なシナリオでは、ユーザーが最初に仮想ネットワークを作成できます。それにより、サブネットの構成、オンプレミスの接続、IP アドレスの指定などを制御できます。 詳細については、Azure Kubernetes Service (AKS) での高度なネットワークの構成に関するページを参照してください。

イングレス。 イングレス サーバーは、クラスター内のサービスに HTTP(S) ルートを公開します。 詳細については、後の「API ゲートウェイ」のセクションを参照してください。

Azure Load Balancer。 AKS クラスターの作成後、クラスターはロード バランサーを使用する準備ができます。 その後、NGINX サービスがデプロイされると、ロード バランサーはイングレス コントローラーを代表とする新しいパブリック IP を使用して構成されます。 このように、ロード バランサーは、インターネット トラフィックをイングレスにルーティングします。

外部データ ストア。 マイクロサービスは通常ステートレスで、Azure SQL Database や Azure Cosmos DB などの外部データ ストアに状態を書き込みます。

Microsoft Entra ID。 AKS では、Azure ロード バランサーなどの他の Azure リソースを作成および管理するために Microsoft Entra ID を使用します。 Microsoft Entra ID は、クライアント アプリケーションでのユーザー認証にも推奨されます。

Azure Container Registry。 Container Registry は、クラスターにデプロイされたプライベート Docker イメージを格納するために使用します。 AKS では、その Microsoft Entra ID を使用して Azure Container Registry で認証できます。 AKS に Azure Container Registry は必要ありません。 Docker Hub などの他のコンテナー レジストリを使用できます。 コンテナー レジストリがワークロードのサービス レベル アグリーメント (SLA) の条件と一致しているか、上回っていることを確認してください。

Azure Pipelines。 Azure Pipelines は Azure DevOps Services の一部であり、自動化されたビルド、テスト、およびデプロイを実行します。 Jenkins などのサードパーティ CI/CD ソリューションも使用できます。

Helm。 Helm は Kubernetes のパッケージ マネージャーであり、Kubernetes オブジェクトを発行、デプロイ、バージョン管理、および更新が可能な 1 つの単位にバンドルして一般化するための方法です。

Azure Monitor。 Azure Monitor では、Azure サービスのメトリックやログ、アプリケーション テレメトリ、プラットフォーム メトリックが収集されて格納されます。 このデータは、アプリケーションを監視したり、アラートやダッシュボードを設定したり、障害の根本原因分析を実行したりするために使用します。 Azure Monitor は、コントローラー、ノード、コンテナーからメトリックを収集するために AKS と統合します。

考慮事項

デザイン

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

マイクロサービス

マイクロサービスは、コードの疎結合で、かつ独立にデプロイ可能な単位です。 マイクロサービスは通常、良定義された API 経由でやり取りされ、ある形式のサービス検出によって検出できます。 ポッドが移動された場合でも、このサービスは、常に到達可能である必要があります。 Kubernetes でマイクロサービスをモデル化する自然な方法に、Kubernetes Service オブジェクトがあります。

API ゲートウェイ

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

• マイクロサービスでの API ゲートウェイの使用
• ゲートウェイ テクノロジの選択

Kubernetes での API ゲートウェイの機能は、主にイングレス コントローラーによって処理されます。 この点については、「イングレス」セクションを参照してください。

データ ストレージ

マイクロサービス アーキテクチャでは、サービスはデータ ストレージ ソリューションを共有すべきではありません。 各サービスは、サービス間の隠れた依存関係を回避するために、独自のデータ セットを管理する必要があります。 データの分離は、サービスが基礎となる同じデータ スキーマを共有している場合に発生することのある、サービス間の意図しない結合を回避するためです。 サービスはまた、独自のデータ ストアを管理する場合、特定の要件に適したデータ ストアを使用することもできます。

詳細については、「マイクロサービスの設計: データに関する考慮事項」を参照してください。

データがノードに結合されるため、永続データをローカルのクラスター ストレージに格納することは避けてください。 その代わりに Azure SQL Database や Azure Cosmos DB などの外部サービスを使用してください。 もう 1 つのオプションは、Azure ディスクまたは Azure Files を使用して、ソリューションに永続データ ボリュームをマウントすることです。

詳細については、「Azure Kubernetes Service でのアプリケーション用ストレージ オプション」を参照してください。

Service オブジェクト

Kubernetes Service オブジェクトには、マイクロサービスが必要とする、サービスを見つけやすくするための一連の機能があります。

• IP アドレス。 Service オブジェクトは、ポッドのグループ (ReplicaSet) に静的内部 IP アドレスを提供します。 ポッドが作成されたり移動されたりしても、常に、この内部 IP アドレスでサービスに到達できます。

• 負荷分散。 サービスの IP アドレスに送信されたトラフィックは、ポッドに対して負荷分散されます。

• サービス検出。 サービスには、Kubernetes DNS サービスによって内部の DNS エントリが割り当てられます。 つまり、API ゲートウェイは、DNS 名を使用してバックエンド サービスを呼び出すことができます。 サービス間の通信にも同じメカニズムを使用できます。 DNS エントリは名前空間ごとに整理されるため、名前空間が境界付けられたコンテキストに対応している場合は、サービスの DNS 名がアプリケーション ドメインに自然にマッピングされます。

次の図は、サービスとポッドの関係の概念を示しています。 エンドポイントの IP アドレスおよびポートへの実際のマッピングは、Kubernetes のネットワーク プロキシである kube-proxy によって実行されます。

イングレス

Kubernetes では、イングレス コントローラーによって API ゲートウェイのパターンが実装される場合があります。 この場合、イングレスとイングレス コントローラーが連動して動作して、次の機能が提供されます。

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

• クライアントとバックエンド間での頻繁な通信を減らすために、複数の要求を 1 つの要求に集約する。

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

イングレスは、プロキシ サーバーの構成設定を抽象化します。 イングレスの基礎となる実装を提供する、イングレス コントローラーも必要です。 イングレス コントローラーは、たとえば Nginx、HAProxy、Traefik、Azure Application Gateway 用に用意されています。

イングレス リソースは、さまざまなテクノロジによって実現されます。 これらが連動するには、これらがクラスター内にイングレス コントローラーとしてデプロイされる必要があります。 これは、エッジ ルーターまたはリバース プロキシとして動作します。 リバース プロキシ サーバーは潜在的なボトルネックまたは単一障害点であるため、高可用性のためには、常に少なくとも 2 つのレプリカをデプロイします。

プロキシ サーバーの構成には、専門家でなければ調整が難しい、複雑なファイルがしばしば必要になります。 つまり、イングレス コントローラーが優れた抽象化を提供します。 イングレス コントローラーは Kubernetes API にもアクセスできるため、ルーティングや負荷分散に関して賢い判断をすることができます。 たとえば、Nginx イングレス コントローラーは kube-proxy ネットワーク プロキシをバイパスします。

これに対して、設定に対する完全な制御が必要な場合は、この抽象化をバイパスしてプロキシ サーバーを手動で構成することもできます。 詳細については、「Nginx または HAProxy の Kubernetes へのデプロイ」を参照してください。

Azure でのサービスの負荷分散の詳細については、「Azure の負荷分散オプションの概要」をご覧ください。

TLS/SSL での暗号化

一般的な実装では、イングレス コントローラーは SSL 終了に使用されます。 そのため、イングレス コントローラーをデプロイする一環として、TLS 証明書を作成する必要があります。 開発やテスト目的には、自己署名証明書のみを使用します。 詳細については、「Azure Kubernetes Service (AKS) で HTTPS イングレス コントローラーを作成し、独自の TLS 証明書を使用する」を参照してください。

運用ワークロードには、信頼された証明機関 (CA) から署名入り証明書を取得する必要があります。 Let's Encrypt 証明書の生成および構成の詳細については、「Azure Kubernetes Service (AKS) の静的パブリック IP アドレスを使用してイングレス コントローラーを作成する」を参照してください。

お使いの証明書は、組織のポリシーに応じてローテーションする必要がある場合もあります。 詳細については、「Azure Kubernetes Service (AKS) での証明書のローテーション」を参照してください。

名前空間

クラスター内のサービスを整理するには、名前空間を使用します。 Kubernetes クラスター内のオブジェクトはすべて、名前空間に属します。 既定では、新しいオブジェクトを作成すると、そのオブジェクトは default 名前空間に移動します。 ただし、クラスター内のリソースを整理しやすくするために、わかりやすい名前空間を作成することをお勧めします。

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

• 名前空間に割り当てられたすべてのポッドが名前空間のリソースのクォータを超えることがないように、その名前空間にリソース制約を適用する。

• 名前空間レベルでポリシーを適用する (RBAC やセキュリティ ポリシーを含む)。

マイクロサービス アーキテクチャでは、マイクロサービスを境界付けられたコンテキストに整理し、境界付けられたコンテキストごとに名前空間を作成することを考慮してください。 たとえば、"受注処理" の境界付けられたコンテキストに関連したマイクロサービスはすべて、同じ名前空間に移動する可能性があります。 あるいは、開発チームごとに名前空間を作成します。

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

正常性プローブ

Kubernetes では、ポッドが公開できる次の 2 種類の正常性プローブが定義されます。

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

• liveness probe: ポッドが削除され、新しいインスタンスが起動されるかどうかを Kubernetes に通知します。

プローブについて考慮する場合は、Kubernetes でのサービスのしくみを思い出すことが有効です。 サービスには、一連の (0 個以上の) ポッドに一致するラベル セレクターがあります。 Kubernetes は、そのセレクターに一致するポッドへのトラフィックを負荷分散します。 正常に起動され、正常な状態にあるポッドのみがトラフィックを受信します。 コンテナーがクラッシュした場合、Kubernetes はポッドを強制終了し、置き換えをスケジュールします。

ポッドが正常に起動されたにもかかわらず、そのポッドがトラフィックを受信する準備ができていない場合があります。 たとえば、コンテナーで実行されているアプリケーションがメモリにデータを読み込んだり、構成データを読み取ったりする初期化タスクが存在する可能性があります。 ポッドが正常であるが、トラフィックを受信する準備ができていないことを示すには、準備プローブを定義します。

liveness probe は、ポッドが引き続き実行中だが、異常であるため、リサイクルする必要がある場合を処理します。 たとえば、コンテナーが HTTP 要求を処理しているが、何らかの理由でハングアップしたとします。 そのコンテナーはクラッシュしませんが、すべての要求の処理を停止しました。 HTTP liveness probe を定義した場合、このプローブは応答を停止し、ポッドを再起動するよう Kubernetes に通知します。

プローブを設計する場合の考慮事項のいくつかを次に示します。

• コードの起動時間が長い場合は、その起動が完了する前に liveness probe が障害を報告するおそれがあります。 このプローブの障害を防止するには、プローブの起動を遅延させる initialDelaySeconds 設定を使用します。

• ポッドが再起動によって正常な状態に復元される可能性がない限り、liveness probe は役立ちません。 メモリ リークや予期しないデッドロックに対する緩和のために liveness probe を使用できますが、またすぐに障害が発生するポッドを再起動しても意味がありません。

• 依存サービスをチェックするために準備プローブが使用される場合があります。 たとえば、ポッドにデータベースへの依存関係がある場合は、probe がデータベース接続をチェックすることがあります。 ただし、このアプローチにより、予期しない問題が発生する場合があります。 外部サービスが何らかの理由で一時的に使用できなくなることがあります。 それにより、サービス内のすべてのポッドで準備プローブが失敗し、それらがすべて負荷分散から削除されるため、連鎖的な障害の上流が生成されます。 より適切なアプローチとして、サービスが一時的な障害から正常に復旧できるように、サービス内に再試行処理を実装します。

リソース制約

リソースの競合がサービスの可用性に影響を与える場合があります。 1 つのコンテナーがクラスター リソース (メモリと CPU) を占有できなくなるように、コンテナーのリソース制約を定義します。 スレッドやネットワーク接続などのコンテナー以外のリソースの場合は、バルクヘッド パターンを使用してリソースを分離することを考慮してください。

名前空間に許可されるリソースの合計を制限するには、リソースのクォータを使用します。 それにより、フロント エンドがバックエンド サービスをリソース不足にすることはなくなり、その逆も同様です。

セキュリティ

ロール ベースのアクセス制御 (RBAC)

Kubernetes と Azure のどちらにも、ロールベースのアクセス制御 (RBAC) のメカニズムがあります。

• Azure RBAC は、Azure でのリソースへのアクセス (新しい Azure リソースを作成する機能を含む) を制御します。 アクセス許可は、ユーザー、グループ、またはサービス プリンシパルに割り当てることができます。 (サービス プリンシパルは、アプリケーションによって使用されるセキュリティ ID です。)

• Kubernetes RBAC は、Kubernetes API へのアクセス許可を制御します。 たとえば、ポッドの作成やポッドの一覧表示は、Kubernetes RBAC によってユーザーに許可 (または拒否) できるアクションです。 ユーザーに Kubernetes アクセス許可を割り当てるには、ロールとロール バインディングを作成します。

  • ロールは、名前空間内で適用される一連のアクセス許可です。 アクセス許可は、リソース (ポッドやデプロイなど) に対して動詞 (get、update、create、delete) として定義されます。

  • RoleBinding は、ロールにユーザーまたはグループを割り当てます。

  • すべての名前空間で ClusterRole オブジェクトも存在します。これはロールに似ていますが、クラスター全体に適用されます。 ClusterRole にユーザーまたはグループを割り当てるには、ClusterRoleBinding を作成します。

AKS では、これらの 2 つの RBAC メカニズムが統合されます。 AKS クラスターを作成するときに、そのクラスターを、ユーザー認証に Microsoft Entra ID を使用するように構成できます。 これを設定する方法の詳細については、Microsoft Entra ID と Azure Kubernetes Service の統合に関するページを参照してください。

これが構成された後、Kubernetes API に (たとえば、kubectl 経由で) アクセスしようとするユーザーは、自分の Microsoft Entra 資格情報を使用してサインインする必要があります。

既定では、Microsoft Entra ユーザーはクラスターにアクセスできません。 アクセス権を付与するには、クラスター管理者が、Microsoft Entra ユーザーまたはグループを参照する RoleBindings を作成します。 ユーザーに特定の操作のアクセス許可がない場合、これは失敗します。

ユーザーに既定でアクセス権がない場合、そもそも、クラスター管理者はロール バインディングを作成するためのアクセス許可をどのように取得するのでしょうか。 AKS クラスターには、実際には、Kubernetes API サーバーを呼び出すための資格情報としてクラスター ユーザーとクラスター管理者の 2 種類があります。クラスター管理者の資格情報は、クラスターへのフル アクセスを付与します。 Azure CLI コマンド az aks get-credentials --admin はクラスター管理者の資格情報をダウンロードし、それを kubeconfig ファイルに保存します。 クラスター管理者は、この kubeconfig を使用してロールとロール バインディングを作成できます。

Kubernetes クラスターの Role オブジェクトと RoleBinding オブジェクトを Kubernetes でネイティブに管理する代わりに、Kubernetes 承認に Azure RBAC を使用することをお勧めします。 これにより、Azure のリソース、AKS、Kubernetes のリソースで統一された管理とアクセス制御を実現できます。 これらの Azure RBAC によるロールの割り当てをクラスターまたはクラスター内の名前空間に適用することで、よりきめ細かなアクセス制御を行うことができます。 Azure RBAC では制限された既定のアクセス許可セットが可能で、Role と RoleBinding を管理するネイティブの Kubernetes メカニズムと組み合わせることで、高度なアクセス パターンやよりきめ細かなアクセス パターンを実現できます。 有効にすると、Microsoft Entra プリンシパルは Azure RBAC だけで検証されますが、通常の Kubernetes ユーザーとサービス アカウントは Kubernetes RBAC だけで検証されます。

クラスター管理者の資格情報は非常に強力であるため、Azure RBAC を使用して、それへのアクセスを制限します。

• "Azure Kubernetes Service クラスター管理者ロール" には、クラスター管理者の資格情報をダウンロードするためのアクセス許可があります。 このロールにはクラスター管理者のみを割り当てる必要があります。

• "Azure Kubernetes Service クラスター ユーザー ロール" には、クラスター ユーザーの資格情報をダウンロードするためのアクセス許可があります。 このロールには管理者以外のユーザーを割り当てることができます。 このロールは、クラスター内の Kubernetes リソースに対する特定のアクセス許可を提供しません。ユーザーが API サーバーに接続できるようにするだけです。

RBAC ポリシー (Kubernetes と Azure の両方) を定義する場合は、組織内のロールについて考慮してください。

• 誰が AKS クラスターを作成または削除したり、管理者の資格情報をダウンロードしたりできますか。
• 誰がクラスターを管理できますか。
• 誰が名前空間内のリソースを作成または更新できますか。

ClusterRoles と ClusterRoleBindings ではなく、Roles と RoleBindings を使用して、Kubernetes RBAC アクセス許可のスコープを名前空間ごとに設定することをお勧めします。

最後に、Azure リソース (ロード バランサー、ネットワーク、ストレージなど) を作成および管理するために AKS クラスターにはどのようなアクセス許可があるのかという問題があります。 Azure API で自身を認証するために、クラスターは Microsoft Entra サービス プリンシパルを使用します。 クラスターを作成するときにサービス プリンシパルを指定しない場合は、サービス プリンシパルが自動的に作成されます。 ただし、最初にサービス プリンシパルを作成し、それに最小限の RBAC アクセス許可を割り当てることが良いセキュリティ対策です。 詳細については、Azure Kubernetes Service でのサービス プリンシパルに関するページを参照してください。

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

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

Azure リソースの場合は、マネージド ID を使用するオプションがあります。 マネージド ID とは、アプリケーションまたはサービスに、Microsoft Entra ID に格納された ID があり、この ID を使用して Azure サービスで認証するという考え方です。 アプリケーションまたはサービスには、Microsoft Entra ID で自身のために作成されたサービス プリンシパルがあり、OAuth 2.0 トークンを使用して認証します。 実行中のプロセス コードは、使用するトークンを透過的に取得できます。 そのため、どのパスワードまたは接続文字列も格納する必要がありません。 AKS でマネージド ID を使用するには、Microsoft Entra ワークロード ID (プレビュー) を使用して個々のポッドに Microsoft Entra ID を割り当てます。

現在、マネージド ID を使用した認証をすべての Azure サービスがサポートしているわけではありません。 一覧については、Microsoft Entra 認証をサポートする Azure サービスに関するページを参照してください。

マネージド ID を使用した場合でも、マネージド ID をサポートしていない Azure サービス、サードパーティのサービス、API キーなどでは、何らかの資格情報やその他のアプリケーション シークレットの格納が必要になる可能性があります。 シークレットを安全に格納するためのオプションのいくつかを次に示します。

• Azure Key Vault。 AKS では、1 つ以上のシークレットを Key Vault からボリュームとしてマウントできます。 このボリュームは、Key Vault からシークレットを読み取ります。 ポッドはその後、これらのシークレットを通常のボリュームと同様に読み取ることができます。 詳しくは、「AKS クラスターでシークレット ストア CSI ドライバーのために Azure Key Vault プロバイダーを使用する」をご覧ください。

  ポッドはワークロード ID を使用するか、ユーザーまたはシステム割り当てマネージド ID を使用して、自分自身を認証します。 詳細については、「Azure Key Vault プロバイダーにアクセスするための ID をシークレット ストア CSI ドライバーに提供する」を参照してください。

• HashiCorp Vault。 Kubernetes アプリケーションでは、Microsoft Entra マネージド ID を使用して HashiCorp Vault で認証できます。 HashiCorp Vault と Microsoft Entra ID の統合に関するページを参照してください。 Vault 自体は Kubernetes にデプロイできますが、お使いのアプリケーション クラスターとは別の専用のクラスターで実行することをお勧めします。

• Kubernetes シークレット。 もう 1 つのオプションとして、単純に Kubernetes シークレットを使用します。 このオプションは構成するのが最も簡単ですが、課題もいくつかあります。 シークレットは、分散型キー値ストアである etcd に格納されます。 AKS は、保存時の etcd を暗号化します。 暗号化キーは Microsoft が管理します。

HashiCorp Vault や Azure Key Vault などのシステムの使用には、次のようないくつかの利点があります。

• シークレットの集中制御。
• すべてのシークレットが保存時に暗号化されることの保証。
• キーの集中管理。
• シークレットのアクセス制御。
• 監査

コンテナーと Orchestrator のセキュリティ

ポッドとコンテナーをセキュリティで保護するための推奨プラクティスを次に示します。

• 脅威の監視:Microsoft Defender for Containers (またはサードパーティの機能) を使って脅威を監視します。 VM でコンテナーをホストしている場合は、Microsoft Defender for servers やサード パーティの機能を使用します。 また、Azure Monitor のコンテナー監視ソリューションのログを、Microsoft Sentine または既存の SIEM ソリューションに統合することもできます。

• 脆弱性の監視:Microsoft Defender for Cloud または Azure Marketplace で入手できるサード パーティのソリューションを使用して、イメージおよび実行中のコンテナーで既知の脆弱性を継続的に監視します。

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

• 信頼できるプライベート レジストリへのイメージの格納 - Azure Container Registry や Docker Trusted Registry などを使用します。 Kubernetes のアドミッションの検証 webhook を使用して、ポッドが確実に、信頼できるレジストリからのみイメージをプルできるようにします。

• 最小特権の原則の適用

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

DevOps

このリファレンス アーキテクチャでは、クラウド リソースとその依存関係をプロビジョニングするための Azure Resource Manager テンプレートを提供します。 [Azure Resource Manager テンプレート][arm-template] を使用することで、Azure DevOps Services を使って (たとえば運用環境シナリオをレプリケートするために) 異なる環境を数分でプロビジョニングできます。 これによってコストを節約し、必要な場合にのみロード テスト環境をプロビジョニングすることができます。

ワークロードの分離基準に従って Resource Manager テンプレートを構成することを検討してください。ワークロードは通常、任意の機能単位として定義され、たとえば、クラスターには独立したテンプレート、依存サービスには別のテンプレートを用意できます。 ワークロードを分離すると、DevOps が継続的インテグレーションと継続的デリバリー (CI/CD) を実行できます。すべてのワークロードは、対応する DevOps チームによって関連付けられ、管理されるためです。

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

マイクロサービス アーキテクチャのための堅牢な CI/CD プロセスの目標のいくつかを次に示します。

• 各チームは、他のチームに影響を与えたり妨害したりすることなく、独立に所有するサービスを構築およびデプロイできます。
• サービスの新しいバージョンは、運用環境にデプロイされる前に、検証のために開発/テスト/QA 環境にデプロイされます。 品質ゲートは、各段階で適用されます。
• サービスの新しいバージョンは、以前のバージョンと並行してデプロイできます。
• 十分なアクセス制御ポリシーが設定されています。
• コンテナー化されたワークロードの場合、運用環境にデプロイされているコンテナー イメージを信頼できます。

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

具体的な推奨事項とベスト プラクティスについては、Kubernetes 上でのマイクロサービス用の CI/CDに関するページを参照してください。

コスト最適化

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

ここでは、このアーキテクチャで使用されるサービスの一部について考慮する点について説明します。

Azure Kubernetes Service (AKS)

Kubernetes クラスターのデプロイ、管理、操作には、AKS に関連するコストはありません。 ご自身の Kubernetes クラスターによって使用される仮想マシン インスタンス、ストレージ、ネットワーク リソースについてのみお支払いいただきます。

必要なリソースのコストを見積もるには、コンテナー サービスの計算ツールをご覧ください。

Azure Load balancer

構成された負荷分散およびアウトバウンド規則の数に対してのみ課金されます。 インバウンド NAT 規則は無料です。 規則が構成されていない場合、Standard Load Balancer に対する時間あたりの料金は発生しません。

詳細については、Azure Load Balancer の価格に関するページをご覧ください。

Azure Pipelines

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

Azure Monitor

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

このシナリオのデプロイ

このアーキテクチャの参照実装をデプロイするには、GitHub リポジトリの手順に従ってください。

次のステップ

• Azure Kubernetes Service でのサービス プリンシパル
• Microsoft Defender for Containers
• Microsoft Defender for servers
• Azure Monitor のコンテナー監視ソリューション
• Microsoft Sentinel または既存の SIEM ソリューション。
• Microsoft Defender for Cloud または Azure Marketplace で入手できるサード パーティのソリューション。
• ACR タスク

関連リソース

• より高度なマイクロサービスの例については、「高度な Azure Kubernetes Service (AKS) マイクロサービス アーキテクチャ」を参照してください。
• このアーキテクチャの監視の詳細については、「Azure Kubernetes Service (AKS) でマイクロサービス アーキテクチャを監視する」を参照してください。
• このアプリケーションのパフォーマンスを測定する方法については、「パフォーマンス チューニングのシナリオ: 分散ビジネス トランザクション」を参照してください。
• マイクロサービス アーキテクチャの CI/CD
• Kubernetes 上でのマイクロサービスの CI/CD