クラウド内の分散リソースでアプリケーション スタックを実行する場合、ネットワーク トラフィックを複数のロケーションで利用可能なリソースに効率的にルーティングする必要があります。Google Cloud インフラストラクチャ信頼性ガイドのこのパートでは、クラウド ワークロードの信頼性の向上に役立つトラフィック管理と負荷管理の手法について説明します。
キャパシティ プランニング
Google Cloud にデプロイされたアプリケーションに十分なインフラストラクチャ リソースを確保するには、必要な容量を見積もり、デプロイされる容量を管理する必要があります。このセクションでは、容量の計画と管理に役立つガイドラインを示します。
アプリケーションの負荷を予測する
負荷を予測する場合は、ユーザーの数や、アプリケーションがリクエストを受信する割合などの要素を考慮してください。予測では、過去の負荷の傾向、季節による変動、特別なイベント中の負荷の急増、ビジネスの変化（新しい地域への拡大など）による増加を考慮します。
容量の要件を見積もる
デプロイ アーキテクチャに基づき、アプリケーションのパフォーマンスと信頼性の目標を考慮して、予想される負荷を処理するために必要な Google Cloud リソースの量を見積もります。たとえば、Compute Engine マネージド インスタンス グループ（MIG）を使用する場合は、各 MIG のサイズ、VM マシンタイプ、永続ディスクの数、タイプ、サイズを決定します。Google Cloud リソースの費用は、Google Cloud Pricing Calculator を使用して見積もることができます。
適切な冗長性を計画する
容量要件を見積もる際は、アプリケーション スタックのすべてのコンポーネントに適切な冗長性を確保してください。たとえば、N+1 の冗長性を実現するには、アプリケーション スタック内のすべてのコンポーネントに、予測負荷の処理に必要な最小数を超える冗長コンポーネントが 1 つ以上必要です。
アプリケーションのベンチマークを行う
負荷テストを実施して、アプリケーションのリソースの効率を判断します。リソース効率とは、アプリケーションの負荷と、アプリケーションが使用する CPU やメモリなどのリソースとの関係のことです。負荷が非常に高いとアプリケーションのリソース効率は低下する可能性があります。また、効率は時間の経過とともに変化する可能性があります。通常の負荷とピーク時の負荷の両方の条件で負荷テストを行い、ベンチマーク テストを定期的に繰り返します。
割り当てを管理する
Google Cloud サービスの割り当てはプロジェクトごとの上限で、クラウド リソースの使用量を制御できます。割り当てには 2 つのタイプがあります。リソースの割り当ては、リージョン内のリージョン Google Kubernetes Engine（GKE）クラスタの数など、作成できる最大リソースです。レート割り当ては、特定の期間にサービスに送信できる API リクエストの数を制限します。割り当ては、ゾーン、リージョン、グローバルのいずれかになります。プロジェクトで使用するサービスの現在のリソース割り当てと API レートの割り当てを確認します。必要な容量に対して十分な割り当てがあることを確認します。必要に応じて、割り当て量の増加をリクエストできます。
コンピューティング容量を予約する
必要に応じて Compute Engine リソースの容量を使用できるように、予約を作成できます。予約では、選択したマシンタイプの指定された数の VM に対して、特定のゾーンでの容量が保証されます。予約は、プロジェクトに固有のものにすることも、複数のプロジェクトで共有することもできます。課金に関する考慮事項など、予約の詳細については、Compute Engine ゾーンリソースの予約をご覧ください。
使用率をモニタリングし、定期的に要件を再評価する
必要なリソースをデプロイしたら、容量の使用率をモニタリングします。アイドル状態のリソースを削除することで、費用を最適化できる場合があります。容量要件を定期的に再評価し、アプリケーションの動作、パフォーマンスと信頼性の目標、ユーザー負荷、IT 予算の変更を検討してください。
自動スケーリング
複数のロケーションに分散しているリソースに対してアプリケーションを実行すると、いずれかのロケーションでサービスが停止している間も、アプリケーションを使用できます。また、冗長性により、一貫したアプリケーション動作を実現できます。たとえば、負荷が急増した場合、冗長リソースにより、アプリケーションは予測可能なレベルで継続的に実行されます。ただし、アプリケーションの負荷が低い場合は、冗長性により、クラウド リソースが非効率的に使用されることがあります。
たとえば、e コマース アプリケーションのショッピング カート コンポーネントでは、注文確認後 200 ミリ秒以内に注文の 99.9% の支払いを処理する必要があります。負荷が高くなっている期間にこの要件を満たすには、冗長なコンピューティング容量とストレージ容量をプロビジョニングします。ただし、アプリケーションの負荷が低い場合は、プロビジョニングされた容量の一部が未使用のままか、十分に活用されていない可能性があります。未使用のリソースを削除するには、使用率をモニタリングし、容量を調整する必要があります。自動スケーリングは、冗長リソースの管理に伴う運用上のオーバーヘッドを発生させることなく、クラウド容量を管理し、必要なレベルの可用性を維持するのに役立ちます。アプリケーションの負荷が増加すると、自動スケーリングによって追加のリソースが自動的にプロビジョニングされ、アプリケーションの可用性が向上します。負荷が低くなっている期間中は、自動スケーリングによって未使用のリソースが削除されるため、費用の削減に役立ちます。
Compute Engine などの特定の Google Cloud サービスでは、プロビジョニングするリソースの自動スケーリングを構成できます。Cloud Run などのマネージド サービスでは、何も構成しなくても容量は自動的にスケーリングされます。以下に、自動スケーリングをサポートする Google Cloud サービスの例を示します。このリストはすべてを網羅したものではありません。
- Compute Engine: MIG を使用すると、Compute Engine VM にデプロイされるステートレス アプリケーションを現在の負荷に容量が一致するように自動的にスケーリングできます。詳細については、インスタンスのグループの自動スケーリングをご覧ください。
- GKE: 現在の負荷に合わせてノードプールのサイズを自動的に変更するように、GKE クラスタを構成できます。詳細については、クラスタ オートスケーラーをご覧ください。Autopilot モードでプロビジョニングした GKE クラスタの場合、GKE はトラフィックに基づいてノードとワークロードを自動的にスケーリングします。
- Cloud Run: Cloud Run でプロビジョニングするサービスは、現在の負荷を処理するために必要なコンテナ インスタンスの数に自動的にスケールアウトします。アプリケーションに負荷がない場合、サービスはコンテナ インスタンスの数を自動的にゼロにスケールインします。詳細については、コンテナ インスタンスの自動スケーリングについてをご覧ください。
- Cloud Run functions: 関数に対する各リクエストは、関数のインスタンスに割り当てられます。インバウンド リクエストの数が既存の関数インスタンスの数を超えると、Cloud Run functions は自動的に関数の新しいインスタンスを開始します。詳細については、Cloud Run functions 実行環境をご覧ください。
- Bigtable: Bigtable インスタンスにクラスタを作成すると、クラスタが自動的にスケーリングするように構成できます。Bigtable は、CPU とストレージの負荷をモニタリングし、クラスタ内のノード数を調整して、指定したターゲット使用率を維持します。詳細については、Bigtable の自動スケーリングをご覧ください。
- Dataproc Serverless: Apache Spark のバッチ ワークロードを送信すると、Dataproc Serverless は、エグゼキュータの数などのワークロード リソースを動的にスケーリングして、ワークロードを効率的に実行します。詳細については、Dataproc Serverless for Spark の自動スケーリングをご覧ください。
ロード バランシング
ロード バランシングでは、使用可能なリソースにのみトラフィックをルーティングし、個々のリソースが過負荷状態にならないようにすることで、アプリケーションの信頼性を向上させることができます。
クラウド デプロイ用のロードバランサを選択して構成する場合は、信頼性に関連する次の設計上の推奨事項を考慮してください。
内部トラフィックのロード バランシング
外部クライアントとアプリケーション間のトラフィックだけでなく、アプリケーション スタックの階層間のトラフィックのロード バランシングも構成します。たとえば、3 層ウェブ アプリケーション スタックでは、内部ロードバランサを使用してウェブ層とアプリ層の間で信頼性の高い通信を行うことができます。
適切なロードバランサの種類を選択する
複数のリージョンに分散されたアプリケーションに外部トラフィックをロードバランスするには、グローバル ロードバランサまたは複数のリージョン ロードバランサを使用します。詳細については、マルチリージョン デプロイでのグローバル ロード バランシングの利点とリスクをご覧ください。
バックエンドが単一のリージョンにあり、グローバル ロード バランシングの機能が必要ない場合は、ゾーン停止に対する復元力のあるリージョン ロードバランサを使用できます。
ロードバランサの種類を選択する場合は、TLS 終端の地理的制御、パフォーマンス、費用、トラフィック タイプなど、可用性だけでなく他の要素も考慮してください。詳細については、ロードバランサを選択するをご覧ください。
ヘルスチェックを構成する
自動スケーリングにより、現在の負荷を処理するための適切なインフラストラクチャ リソースをアプリケーションに確保できます。ただし、十分なインフラストラクチャ リソースが存在しても、アプリケーションまたはその一部が応答しない場合があります。たとえば、アプリケーションをホストするすべての VM が RUNNING 状態になっている場合があります。ただし、一部の VM にデプロイされたアプリケーション ソフトウェアがクラッシュした可能性があります。ロード バランシングのヘルスチェックにより、ロードバランサがアプリケーション トラフィックを応答可能なバックエンドにのみルーティングします。バックエンドが MIG の場合は、ヘルスチェックの追加レイヤを構成して、利用できない VM を自動修復することを検討してください。MIG の自動修復が構成されると、利用できない VM が事前に削除され、新しい VM が作成されます。
レート制限
場合によっては、アプリケーションで負荷が急激に増加するか、持続的に増加することがあります。増加した負荷を処理するようにアプリケーションが設計されていない場合、アプリケーションまたはそのアプリケーションが使用するリソースで障害が発生し、アプリケーションを使用できなくなる可能性があります。負荷の増加は、ネットワークベースの分散型サービス拒否（DDoS）攻撃などの悪意のあるリクエストが原因で発生する可能性があります。また、その他の理由（クライアント ソフトウェアの構成エラーなど）で負荷が急増することがあります。アプリケーションで過剰な負荷を処理できるようにするには、適切なレート制限メカニズムの適用を検討してください。たとえば、Google Cloud サービスが受信できる API リクエストの数の割り当てを設定します。
レート制限の手法は、クラウド インフラストラクチャの費用を最適化することにも役立ちます。たとえば、特定のリソースに対してプロジェクト レベルの割り当てを設定すると、そのリソースに対してプロジェクトで発生する課金を制限できます。
ネットワーク サービス階層
Google Cloud Network Service Tiers を使用すると、インターネット上のシステムと Google Cloud ワークロード間の接続を最適化できます。アプリケーションがグローバルにユーザーにサービスを提供し、バックエンドが複数のリージョンに存在する場合は、プレミアム ティアを選択します。インターネットから受信したトラフィックは、送信元システムに最も近いポイント オブ プレゼンス（PoP）から高性能な Google ネットワークに入ります。Google ネットワーク内で、トラフィックはエントリ PoP から適切な Google Cloud リソース（Compute Engine VM など）にルーティングされます。アウトバウンド トラフィックは Google ネットワークを通り、宛先に最も近い PoP から出ていきます。このルーティング方法は、ユーザーとユーザーに最も近い PoP との間のネットワーク ホップ数を減らすことで、ユーザーの可用性の認識を改善するのに役立ちます。