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

  • [アーティクル]

"コンピューティング" という用語は、アプリケーションがそこで実行されるコンピューティング リソースのホスティング モデルを指します。 マイクロサービス アーキテクチャでは、2 つのアプローチが特によく使われます。

  • 専用のノード (VM) で実行されるサービスを管理するサービス オーケストレーター。
  • サービスとしての関数 (FaaS) を使うサーバーレス アーキテクチャ。

オプションはこれらだけではありませんが、どちらも実証済みのマイクロサービス構築方法です。 1 つのアプリケーションに両方のアプローチが含まれることもあります。

サービス オーケストレーター

オーケストレーターは、一連のサービスのデプロイと管理に関連するタスクを処理します。 ノードへのサービスの配置、サービスの正常性の監視、サービス インスタンス間へのネットワーク トラフィックの負荷分散、サービスの検出、サービスのインスタンスの数のスケーリング、構成の更新の適用などのタスクがあります。 よく使われるオーケストレーターとしては、Kubernetes、Service Fabric、DC/OS、Docker Swarm などがあります。

Azure プラットフォームでは、以下のオプションを検討してください。

  • Azure Kubernetes Service (AKS) は、マネージド Kubernetes サービスです。 AKS は、Kubernetes をプロビジョニングして Kubernetes API エンドポイントを公開しますが、Kubernetes 制御プレーンをホストして管理し、自動アップグレード、修正プログラムの自動適用、自動スケーリング、その他の管理タスクを実行します。 AKS は、"サービスとしての Kubernetes API" と考えることができます。

  • Azure Container Apps は、Kubernetes を基盤とし、コンテナー オーケストレーションや他の管理タスクの複雑さを抽象化するマネージド サービスです。 Container Apps は、Kubernetes の機能を提供しながら、サーバーレス環境内のコンテナ化されたアプリケーションやマイクロサービスのデプロイと管理を単純化します。

  • Service Fabric は、マイクロサービスのパッケージ化、デプロイ、管理を行うための分散システム プラットフォームです。 マイクロサービスは、コンテナー、バイナリ実行可能ファイル、または Reliable Services として Service Fabric にデプロイできます。 Reliable Services プログラミング モデルを使うと、サービスは Service Fabric プログラミング API を直接使って、システムのクエリ、正常性のレポート、構成とコードの変更に関する通知の受信、他のサービスの検出を行うことができます。 Service Fabric に関する重要な違いは、Service Fabric では Reliable Collection を使うステートフル サービスの構築が重視されていることです。

  • Docker Enterprise Edition など、その他のオプションは、Azure の IaaS 環境で実行できます。 Azure Marketplace でデプロイ テンプレートを見つけることができます。

Containers

コンテナーとマイクロサービスは同じものであるかのように言われることがあります。 それは正しくありませんが (マイクロサービスを構築するためにコンテナーは必要ありません)、コンテナーの次のような利点はマイクロサービスに特に関連があります。

  • 移植性。 コンテナー イメージは、ライブラリや他の依存関係をインストールする必要なしに実行するスタンドアロン パッケージです。 そのため簡単にデプロイできます。 コンテナーはすばやく開始および停止できるので、高い負荷の処理やノード障害からの復旧のために新しいインスタンスを開始できます。

  • 密度。 コンテナーは OS リソースを共有しているため、仮想マシンの実行と比較して軽量です。 そのため、複数のコンテナーを単一のノードに収めることができ、アプリケーションが多数の小さいサービスで構成される場合に特に便利です。

  • リソースの分離。 コンテナーで利用できるメモリと CPU の量を制限することができ、ランナウェイ プロセスによってホストのリソースがすべて使われないようにするのに役立ちます。 詳しくは、「Bulkhead pattern」 (バルクヘッド パターン) をご覧ください。

サーバーレス (サービスとしての関数)

サーバーレス アーキテクチャでは、ユーザーは VM や仮想ネットワーク インフラストラクチャを管理しません。 代わりに、ユーザーがコードをデプロイすると、ホスティング サービスがそのコードを VM 上に配置して実行します。 このアプローチには、イベント ベースのトリガーを使って調整される小さく細分化された関数が適しています。 たとえば、メッセージがキューに配置されると、メッセージをキューから読み取って処理する関数がトリガーされるような場合です。

Azure Functions はサーバーレスのコンピューティング サービスであり、HTTP 要求、Service Bus キュー、Event Hubs イベントなど、さまざまな関数トリガーをサポートします。 詳しくは、「Azure Functions でのトリガーとバインドの概念」をご覧ください。 また、Azure のマネージド イベント ルーティング サービスである Azure Event Grid も検討してください。

オーケストレーターかサーバーレスか

オーケストレーター アプローチとサーバーレス アプローチのどちらを選ぶかを検討するときの要因を次に示します。

管理の容易性。サーバーレス アプリケーションのコンピューティング リソースはすべてプラットフォーム側で管理されるため、管理が容易です。 オーケストレーターはクラスターの管理と構成の一部を抽象化しますが、基になる VM を完全には隠ぺいしません。 オーケストレーターでは、負荷分散、CPU とメモリの使用量、ネットワークなどの問題について、ユーザーが考える必要があります。

柔軟性と制御。 オーケストレーターでは、サービスおよびクラスターの構成と管理の広い範囲をユーザーが制御できます。 その代わり、複雑さは増します。 サーバーレス アーキテクチャでは、詳細が抽象化されているため、ユーザーが制御できない部分があります。

移植性。 ここで示したすべてのオーケストレーター (Kubernetes、DC/OS、Docker Swarm、Service Fabric) は、オンプレミスで、または複数のパブリック クラウドで実行できます。

アプリケーションの統合。 サーバーレス アーキテクチャを使って複雑なアプリケーションを構築することは、多くの小さい独立した機能を調整、デプロイ、管理する必要があるため、難しい場合があります。 Azure での 1 つのオプションは、Azure Logic Apps を使って Azure Functions のセットを調整することです。 このアプローチの例については、「Azure Logic Apps と統合される関数を作成する」をご覧ください。

コスト。 オーケストレーターでは、クラスターで実行している VM の料金がかかります。 サーバーレス アプリケーションでは、実際に消費したコンピューティング リソースについてだけ課金されます。 どちらの場合も、記憶域、データベース、メッセージング サービスなど、追加サービスのコストを考慮する必要があります。

スケーラビリティ。 Azure Functions は、受信イベントの数に基づき、需要に合わせて自動的にスケーリングします。 オーケストレーターでは、クラスターで実行するサービス インスタンスの数を増やすことによりスケールアウトできます。 また、クラスターに VM を追加してスケーリングすることもできます。

この参照実装では主に Kubernetes を使っていますが、配送履歴サービスに対しては Azure Functions を使いました。 この特定のサービスはイベント ドリブンのワークロードであるため、Azure Functions が適していました。 Event Hubs のトリガーを使って関数を呼び出すことにより、サービスで必要なコードは最小限の量で済みました。 また、配送履歴サービスはメイン ワークフローの一部ではないので、Kubernetes クラスターの外部で実行しても、ユーザー開始操作のエンド ツー エンドの待機時間には影響がありません。

次のステップ

サービス間の通信