マイクロサービス用の Azure コンピューティング オプションの選択

この記事は、マイクロサービス アーキテクチャに基づいて構築されたワークロード用の Azure コンピューティング プラットフォームを選択するのに役立ちます。 マイクロサービス アーキテクチャは、ネットワーク経由で通信する、独立してデプロイ可能な小規模なサービスで構成されます。 コンピューティング プラットフォームでは、独立したスケーリング、独立したデプロイ、および多くのサービス間の信頼性の高いサービス間通信をサポートする必要があります。

チーム スキル、ネットワーク、移植性など、ワークロードに適用される決定要因については、「 Azure コンピューティング サービスの選択」を参照してください。 この記事では、マイクロサービスに特に重要な要素について説明します。

マイクロサービス用の Azure コンピューティング プラットフォーム

次の Azure プラットフォームでは、マイクロサービス ワークロードがサポートされています。 提供されるオーケストレーション、サービス間通信、スケーリング動作の量が異なります。

Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) は、Kubernetes API とコントロール プレーンに直接アクセスできるマネージド Kubernetes サービスです。 AKS では、ノード管理、修正プログラムの適用、およびオプションの自動アップグレードが提供されます。 クラスター、ネットワーク、スケーリング のポリシーを構成します。

マイクロサービスの場合、AKS では、トラフィック管理と相互トランスポート層セキュリティ (mTLS) 用 の Istio などのサービス メッシュ、水平ポッド オートスケーラー (HPA) と Kubernetes イベントドリブン自動スケーリング (KEDA) によるデプロイごとのスケーリング、ローリング更新やカナリア リリースなどの Kubernetes ネイティブデプロイ戦略がサポートされています。

AKS Automatic は、AKS の適切に設計された推奨事項に基づいてノードの管理、スケーリング、セキュリティ、および可観測性を事前に構成する AKS のモードです。そのため、チームは機能ごとの構成なしで運用対応のクラスターを取得します。

Azure Container Apps

Azure Container Apps は、クラスター管理を抽象化する Kubernetes 上に構築されたマネージド サービスです。

Container Apps には、 サービス検出、mTLS を使用したサービス間呼び出しのための Dapr 統合 、パブリッシャー サブスクライバー メッセージング、状態管理など、マイクロサービス用の組み込み機能が用意されています。 KEDA ベースの自動スケール により、ゼロへのスケールを含むイベント ドリブンスケーリングが可能になります。 Container Apps では、リビジョン間でのトラフィック分割によるカナリアデプロイと、オンデマンド、スケジュール済み、またはイベント駆動によるジョブもサポートされています。

Container Apps では、Kubernetes API は公開されません。 デプロイ ツールまたはサービス メッシュの構成が Kubernetes プリミティブに依存している場合は、代わりに AKS を使用してください。

Azure Functions

Azure Functions は、HTTP 要求、キュー メッセージ、タイマーなどのトリガーに応答するマイクロサービスに適した、サーバーレスのイベントドリブン コンピューティング サービスです。 関数は、各関数アプリを個別にスケーリングし、ゼロにスケーリングできます。 マイクロサービスの場合は、各サービスを独自の関数アプリとしてデプロイします。

関数では、プラットフォーム レベルのサービス検出やサービス間通信は提供されません。 これらの機能をアプリケーション コードに実装するか、 Azure API Management などの外部サービスを使用して実装します。

関数は 複数のプログラミング言語をサポートしています。 また、Functions のトリガーとバインドを Container Apps のネットワーク機能とスケーリング機能と組み合わせた、Container Apps で Functions プログラミング モデルを実行することもできます。

Azure App Service

Azure App Service は、Web API などの HTTP ベースのマイクロサービスに適しています。 App Service では、コードまたは単一のコンテナーとしてのデプロイがサポートされています。 組み込みの自動スケーリング、ブルーグリーン デプロイとパーセンテージベースのトラフィック ルーティング用の デプロイ スロット 、継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインとの統合が提供されます。 App Service はサービス検出を提供しないため、プラットフォーム レベルのサービス間通信に依存するのではなく、外部メッセージングまたは API ゲートウェイを介して通信するマイクロサービスに適しています。

Azure Red Hat OpenShift

Azure Red Hat OpenShift は、完全に管理された OpenShift クラスターを提供し、意見に基づいた開発者体験を提供することで、Kubernetes を拡張します。 Red Hat と Microsoft は共同でサービスのエンジニアリング、運用、サポートを行います。 組織が OpenShift を標準化する場合は、Azure Red Hat OpenShift を使用します。

マイクロサービスのプラットフォームを比較する

次の表は、各プラットフォームがマイクロサービス アーキテクチャにとって重要な機能をどのようにサポートしているかを比較したものです。 Azure コンテナー ホスティング プラットフォームとその機能の詳細な比較については、「 Azure コンテナー サービスの選択」を参照してください。

機能 AKS Container Apps Functions App Service
サービスの検出 Kubernetes Domain Name System (DNS)、サービスメッシュ 内蔵、 Dapr なし (アプリ レベル) なし (アプリ レベル)
サービス間の通信 サービス メッシュ (Istio) Dapr、 環境レベル なし (アプリ レベル) なし (アプリ レベル)
パブリッシャーとサブスクライバーのメッセージング アプリ レベル (Azure Service Bus、Azure Event Hubs など) Dapr pub/sub バインディング アプリ レベル
独立したスケーリング デプロイごと (HPA、KEDA) アプリごと (KEDA) 関数ごとのアプリ (Flex の関数ごと) アプリごとのサービス プラン
ゼロにスケーリングする 一部 (ユーザーノードプールのみ) イエス はい (従量課金プランまたはフレックス従量課金プラン) いいえ
コールド スタートの軽減策 最小ノード数、最小ポッド レプリカ 最小レプリカ数 事前ウォーミングされたインスタンスまたは常時対応のインスタンス (Premium または Flex Consumption) 適用なし (Always On)
トラフィックの分割とカナリアデプロイ Kubernetesネイティブなサービスメッシュ リビジョンベース デプロイ スロット (Premium/専用) トラフィック ルーティングを含むデプロイ スロット
分散トレース OpenTelemetry、オープンソース ツール 組み込みの Dapr トレース Application Insights Application Insights
ステートフル サービス 永続ボリューム、StatefulSets ボリューム マウント、 Dapr ステート Durable Functions Azure Files のマウント
サービスごとの ID ワークロードアイデンティティ マネージド ID マネージド ID マネージド ID
Kubernetes API アクセス イエス いいえ いいえ いいえ
独立した展開可能性 はい (ポッドごとまたはデプロイごと) はい (コンテナーごとのアプリ) はい (機能別のアプリ) はい (アプリごとまたは デプロイ スロットごと)
コンテナーを実行する イエス イエス イエス イエス
コンテナーなしでコードを実行する いいえ いいえ イエス イエス

この表のアプリ レベルは、プラットフォームが組み込み機能として機能を提供していないことを意味します。 これを SDK または外部サービスを使用してアプリケーション コードに実装します。これにより、そのサービスへの依存関係が生まれます。

Note

この表には、Azure Red Hat OpenShift は含まれていません。 完全な Kubernetes API が提供されるため、デプロイごとのスケーリング、サービス検出、ローリング更新などのコア マイクロサービス機能は、AKS と同等です。

プラットフォームは、コア マイクロサービス機能ではなく、運用ツールによって異なります。 たとえば、AKS はマネージド アドオンとして Dapr と KEDA を提供しますが、OpenShift では自分でインストールして保守します。 詳細については、 Azure Red Hat OpenShift のドキュメントを参照してください。

プラットフォームを選択する

  • クラスター管理なしで、サービス検出、Dapr、アプリごとのスケーリングなど、スケールをゼロに含む組み込みのマイクロサービス プリミティブが必要な場合は、Container Apps から始めます。

  • Kubernetes API への直接アクセス、カスタム サービス メッシュ構成、またはノード プール、ネットワーク ポリシー、スケジュール制約などのクラスター インフラストラクチャをきめ細かく制御する必要がある場合は、AKS を選択します。

  • Functions を、断続的または急激なトラフィック増加パターンを持ち、ゼロにスケールする請求とトリガーによる実行が可能なイベント駆動型のマイクロサービスに使用します。

  • プラットフォーム レベルのサービス検出やサービス間通信機能を必要としない単純な HTTP ベースのサービスには、App Service を使用します。

マイクロサービス ワークロードを 1 つのプラットフォームで実行する必要はありません。 たとえば、Functions がイベントドリブン ワークロードを処理している間、AKS または Container Apps でコア サービスを実行できます。 構成内の各サービスを、独自のトラフィック パターン、スケーリング要件、および通信のニーズに照らして評価します。 プラットフォームに合わせてサービスを強制するのではなく、そのサービスに適合するプラットフォームを選択します。

主要な決定要因

比較表は、各プラットフォームでサポートされている内容を示しています。 次のセクションでは、ワークロードにとって最も重要なマイクロサービスの懸念事項に基づいて、これらの機能を検討する際に役立ちます。

サービス間の通信

マイクロサービスは、サービス検出、再試行、mTLS などの機能を備えた信頼性の高いサービス間通信に依存します。

アーキテクチャが多くのサービス間の同期サービス間呼び出しに依存している場合は、通信プリミティブが組み込まれているプラットフォームに優先順位を付けます。 Container Apps は、追加のインフラストラクチャなしで Dapr を介してこれらのプリミティブを提供します。 AKS は、Istio などのサービス メッシュを通じてそれらを提供します。これにより、トラフィック ポリシー、再試行、および回線の中断をメッシュ レベルで制御できます。 メッシュのライフ サイクル、構成、アップグレードを管理します。

サービスが主にキューやイベント ストリームなどの非同期メッセージングを介して通信する場合、SDK または抽象化を使用してこれらのサービスと対話する必要があるため、プラットフォームの組み込み通信機能は重要ではありません。 プラットフォームのタイムアウトが問題になる可能性があるため、実行時間の長い操作には 非同期 Request-Reply パターン を使用します。 たとえば、Functions と App Service では、Azure Load Balancer の制限により 、230 秒の HTTP 応答タイムアウト が適用されます。

独立したスケーリング

コンポジション内の各マイクロサービスには、異なる負荷特性があります。

サービスのトラフィックが非常に変動したり急激に急増したりする場合、Container Apps と Functions はサービスごとにスケーリングされ、アイドル状態のサービスをゼロにスケーリングできます。 この方法では、未使用の容量料金を回避できます。 Functions の場合、各関数アプリはスケーリング ユニットであるため、各マイクロサービスを独自の関数アプリとしてデプロイします。 AKS では、デプロイごとのスケーリングが提供されます。 プロビジョニングされたままの共有ノード プールを管理し、ユーザー ノード プールを 0 にスケーリングできます。

スケールからゼロへのプラットフォームでは、アイドル状態のサービスが最初の要求を受信すると、コールド スタート待機時間が発生します。 マイクロサービス アーキテクチャでは、1 人のユーザー要求が複数のサービスを走査できます。 呼び出しチェーン内の複数のサービスがコールドである場合は、待機時間が長くなります。 待機時間が短い同期サービス間呼び出しの場合は、プラットフォームのコールド スタート軽減機能を使用するか、コールド スタートを回避するために最小限のインスタンスをアクティブに保つためにコストを支払います。

サービスに安定した予測可能な負荷がある場合、使用量ベースの課金ではなく予約容量に対して支払うため、AKS または App Service でコストを削減できます。

独立した展開可能性

システムの残りの部分に影響を与えずに、個々のマイクロサービスをデプロイ、更新、ロールバックする必要があります。 4 つのプラットフォームはすべて独立したデプロイ可能性をサポートしていますが、変更の検証方法は異なります。 Container Apps と AKS は、段階的なロールアウトのためにトラフィックをネイティブに分割します。 App Service では、デプロイ スロット間の割合ベースのトラフィック ルーティングがサポートされています。 Functions では、Premium プランと Dedicated プランのデプロイ スロットがサポートされています。

分散可観測性

1 人のユーザー要求で、多くのサービスを走査できます。 完全な呼び出しチェーン全体で相関トレースが必要な場合は、プラットフォームの可観測性ツールがトレース戦略と統合されていることを確認します。 Container Apps は、Dapr トレースを使用した組み込みの可観測性を提供します。 AKS は OpenTelemetry およびオープンソースのトレース ツールと統合されています。これにより、トレース バックエンド (Jaeger、Zipkin、Azure Monitor など) を選択できますが、コレクション パイプラインをデプロイして構成する必要があります。 Functions と App Service は Application Insights と統合され、最小限の構成でエンドツーエンドのトランザクション トレースを行います。

コンポジション内の各サービスが、要求率、エラー率、待機時間などのサービスごとのメトリックを公開していることを確認します。 これらのメトリックは、完全な呼び出しチェーン間でログを関連付けることなく、どのサービスが低下するかを特定するのに役立ちます。

ステート管理

マイクロサービス アーキテクチャでは、通常、各サービスはデータを所有し、状態を専用のデータベースまたはキャッシュに外部化します。 このパターンは、サービスを個別にデプロイ可能に保ち、データ ストアが個別の Azure リソースであるため、4 つのプラットフォームすべてが同様にサービスをサポートします。

プラットフォームは、アクターベースのパターン、ワークフロー オーケストレーション、インスタンスごとの専用ストレージなど、サービスでプラットフォームで管理される状態の抽象化が必要な場合に異なります。

  • AKS は、永続ボリュームと StatefulSets を通じて最も柔軟性を提供します。これは、クラスター内データ ストアとインスタンスごとの安定した ID をサポートします。

  • Container Apps では、ボリューム マウントと Dapr 状態管理 (Dapr アクターを含む) がサポートされています。

  • Functions は、Durable Functions を使用してステートフル オーケストレーションとエンティティをサポートします。

  • App Service では、Azure Files マウントを介した共有ストレージがサポートされますが、インスタンスごとのストレージやプラットフォーム レベルの状態の抽象化は提供されません。

考慮事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「 Well-Architected Framework」を参照してください。

[信頼性]

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

マイクロサービス アーキテクチャでは、主な信頼性リスクは連鎖障害です。 1 つの異常なサービスにより、呼び出し元がタイムアウトを蓄積し、問題が呼び出しチェーンを介して外側に伝達されます。 プラットフォームの選択は、このリスクを軽減する方法に影響します。

  • AKS と Container Apps には、異常なインスタンスを検出し、ローテーションから自動的に削除するプラットフォーム レベルの正常性プローブが用意されています。

  • 関数は、トリガーの種類に基づいて失敗した実行を再試行します。

プラットフォームに関係なく、 サーキット ブレーカー、バックオフを使用した再試行ポリシー、およびサービス間通信のタイムアウトを実装して、1 つのサービス障害がシステム全体の停止にならないようにします。

データセンター レベルの障害から保護するために 、可用性ゾーン 間で各サービスをデプロイします。 混合プラットフォーム構成で、使用中のすべてのプラットフォームがデプロイ リージョンのゾーン冗長性をサポートしていることを確認します。

プラットフォーム固有の信頼性ガイダンスについては、 AKS、 Container Apps、 および Functions の Well-Architected Framework サービス ガイドの信頼性に関するセクションを参照してください。

セキュリティ

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

すべてのサービス間呼び出しがネットワーク境界を越えるため、マイクロサービスによって攻撃対象領域が増加します。 すべてのサービス間トラフィックを信頼されていないものとして扱い、mTLS を介して暗号化します。 AKS では、 Istio などのサービス メッシュを介して mTLS がサポートされます。 Container Apps は、 Dapr または 環境レベルの構成を通じて mTLS を提供します。 関数と App Service では、プラットフォーム レベルの mTLS は提供されません。 これらのプラットフォームが構成内でサービスをホストする場合は、アプリケーション層の HTTPS、API ゲートウェイ ポリシー、または仮想ネットワークの分離を通じてトランスポート セキュリティを適用します。

多くのサービスを構成する場合、各サービスは、必要なリソースのみに対して認証する必要があります。 ワークロード全体で 1 つの ID を共有するのではなく、サービスごとの ID を割り当てます。 プラットフォーム固有のメカニズムについては、比較表の サービスごとの ID 行を参照してください。

プラットフォーム固有のセキュリティ ガイダンスについては、 AKS、 Container Apps、 および Functions の Well-Architected Framework サービス ガイドのセキュリティ セクションを参照してください。

コストの最適化

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

マイクロサービス アーキテクチャには多数のサービスを含めることができます。各サービスは、異なるトラフィック ボリュームを処理します。 各サービスを、トラフィック パターンに適合する課金モデルと照合します。 Container Apps や Functions などの従量課金ベースのプラットフォームではアイドル 状態のサービスがゼロにスケーリングされますが、負荷が持続するサービスでは、AKS のような専用コンピューティングの方がコスト効率が高くなります。 混合プラットフォーム構成では、サービスごとの課金の柔軟性が主なコスト上の利点の 1 つです。 ただし、プラットフォーム間で個別のデプロイ パイプライン、監視構成、チームの専門知識を維持するオーバーヘッドが考慮されます。

プラットフォーム固有のコスト ガイダンスについては、 AKS、 Container Apps、 および Functions の Well-Architected Framework サービス ガイドのコスト最適化に関するセクションを参照してください。

参照アーキテクチャ

この記事の比較条件を適用して、オプションを 1 つまたは 2 つのプラットフォームに絞り込みます。 サービスの代表的なサブセットをデプロイし、要件に照らしてサービス間通信、スケーリング動作、デプロイ ワークフローをテストすることで、概念実証を実行します。 運用環境にコミットする前に、プラットフォームがチームの運用上の期待を満たしていることを確認します。 次のアーキテクチャは、運用環境に対応した開始点を提供します。

次のステップ

マイクロサービスのサービス間通信の設計

  • Last updated on