マイクロサービス アーキテクチャに基づくウェブ アプリケーションを設計する場合は、アプリケーションの機能をマイクロサービスに分割する方法、それらのマイクロサービスをアプリケーションの一部として呼び出す方法を決定します。長時間実行されるサービスでは、非同期のサービス呼び出しを使用できます。このリファレンス アーキテクチャでは、長時間実行されるプロセスを非同期で呼び出すコンテナ化されたアプリケーションをデプロイする方法について説明します。
このリファレンス アーキテクチャのドキュメントは、Google Kubernetes Engine（GKE）や Pub/Sub などの最新のテクノロジーを使用して非同期でマイクロサービスを実装する開発者やアーキテクトを対象としています。このドキュメントは、マイクロサービス全般と、Google Cloud の Pub/Sub および GKE に精通していることを前提としています。
アーキテクチャ
次の図は、アプリケーションがサムネイル画像を生成するシナリオの例を示しています。サムネイル画像の生成はリソースを大量に消費するため、時間がかかることがあります。
図 1. VM を使用した元の画像処理アーキテクチャ。
上の図では、アプリケーションがクライアントから画像ファイルを受け取ってサムネイルを生成します。このアーキテクチャでは、Compute Engine の仮想マシン（VM）インスタンスと Cloud Storage のバックエンド ファイル ストレージを使用してアプリケーションが実装されます。このアプリケーションは、Cloud Storage を使用してメタデータを保存します。Cloud Load Balancing により、リクエストが複数の VM に分散されます。
VM の維持に必要な運用オーバーヘッドを減らすには、VM を使用しない新しいアーキテクチャにこのシステムを移行します。
次の図は、通知とマイクロサービスを使用するマネージド サービスを使用し、システムのコンポーネント間の非同期呼び出しを実装することで、このフローを実装する方法を示しています。
図 2. コンテナと非同期メッセージングを使用した新しい画像処理アーキテクチャ。
新しいアーキテクチャでは、クライアントがアプリケーションにイメージを送信し、アプリケーションがそれを Cloud Storage にアップロードします。その後、Pub/Sub 通知によりメッセージが Pub/Sub メッセージ キューに配置されます。メッセージは、GKE で実行されるマイクロサービスを呼び出します。マイクロサービスは Cloud Storage から画像を取得してサムネイルを生成し、それを Cloud Storage にアップロードします。
設計上の考慮事項
次のガイドラインは、業務の効率化およびパフォーマンスに関する組織の要件を満たすアーキテクチャを開発するために役立ちます。
業務の効率化
この新しいアーキテクチャには次のメリットがあります。
独立したスケーラビリティ: 元のアーキテクチャでは、Compute Engine で実行されるアプリケーションが 2 つのコアタスクを処理します。1 つのタスクはファイルの受信で、もう 1 つのタスクは元の画像からのサムネイルの生成です。アップロードされたファイルの受信はネットワーク帯域幅を消費する一方、サムネイルの生成は CPU 使用率が高いタスクです。Compute Engine インスタンスで、画像を生成する CPU リソースが使い果たされたものの、ファイルの受信に十分なネットワーク リソースがまだ残っていることがあります。新しいアーキテクチャでは、Cloud Storage と GKE がこれらのタスクを共有し、タスクの独立したスケーラビリティが確保されます。
新機能の追加が簡単: 元のアーキテクチャに機能を追加する場合、同じ Compute Engine インスタンスにデプロイする必要があります。新しいアーキテクチャでは、アプリケーションを開発して単独で追加できます。たとえば、新しいサムネイルが生成されたときに通知するメール送信アプリケーションを追加できます。GKE で実行される元のコードを変更することなく、Pub/Sub はサムネイル生成アプリケーションとメール送信アプリケーションに非同期で接続できます。
結合度の低減: 元のアーキテクチャでよく見られるのが、一時的結合の問題です。メールリレー サーバーが使用できない場合、アプリケーションが通知を送信しようとすると、通知は失敗します。これらのプロセスは密結合しており、クライアントはアプリケーションからレスポンスを正常に受信できない可能性があります。新しいアーキテクチャでは、サムネイルの生成と通知の送信が疎結合しているため、クライアントはレスポンスを正常に受信できます。
この新しいアーキテクチャには、次のデメリットがあります。
アプリケーションのモダナイゼーションに追加の作業が必要: アプリケーションのコンテナ化には、時間と労力がかかります。新しいアーキテクチャでは、使用されるサービスが増え、アプリケーション モニタリング、デプロイ プロセス、リソース管理の変更など、オブザーバビリティに対する異なるアプローチが必要になります。
アプリケーション側で重複を処理する要件: Pub/Sub は at-least-once メッセージ配信が保証されているため、メッセージが重複して送信される可能性があります。アプリケーションはこの可能性に対応する必要があります。
パフォーマンス
新しいアーキテクチャでは、リソースを効率的に使用できます。元のアーキテクチャでは、Compute Engine インスタンスをスケールアウトすると、オペレーティング システムを実行するためにより多くのリソースが消費されます。GKE では、わずか数台のサーバーで複数のコンテナを実行して、サーバー リソースを効率的に使用できます（ビンパッキング）。新しいアーキテクチャはコンテナを迅速にスケールアウトおよびスケールインできるため、短時間の負荷の急増に対応でき、タスクが完了するとすばやくスケールインできます。
デプロイ
このアーキテクチャを実装するサンプル アプリケーションをデプロイするには、Pub/Sub と GKE を使用するマイクロサービスをデプロイするをご覧ください。
次のステップ
- DevOps について読む。また、このリファレンス アーキテクチャに関連するアーキテクチャ機能の詳細を確認する。
- DevOps のクイック チェックを確認する。業界におけるご自身の立ち位置を把握できます。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。