インターネット アプリケーションでは、使用状況が極端に変動する可能性があります。ほとんどの企業向けアプリケーションでは、このような問題に直面することはありませんが、多くの企業がバッチジョブや CI / CD ジョブなど、バーストの原因となるさまざまなワークロードに対処する必要があります。
このアーキテクチャ パターンは、複数のコンピューティング環境にわたるアプリケーションの冗長デプロイに依存します。目標は、容量または復元力の増加、またはその両方です。
データセンター ベースのコンピューティング環境では、リソースを多めにプロビジョニングすることによって、バーストの原因となるワークロードに対応できますが、この方法は費用効率が優れない場合があります。バッチジョブについては、実行時間を引き延ばすことで使用率を最適化できますが、ジョブを遅延させるため時間が重視される場合には実用的でありません。
クラウド バースト パターンとは、プライベート コンピューティング環境をベースラインのワークロードに使用することにより、追加の容量が必要なときに一時的なバーストをクラウドに担わせることです。
上の図では、オンプレミスのプライベート環境でデータ容量が上限に達した場合は、必要に応じてGoogle Cloud 環境から追加の容量を取得できます。
このパターンの主な推進要因は、コストの削減と、スケール要件の変更に対応するために必要な時間と労力を削減できることです。このアプローチでは、追加の負荷を処理するときに使用されたリソースに対してのみ料金が発生します。つまり、インフラストラクチャを過剰にプロビジョニングする必要はありません。代わりに、オンデマンドのクラウド リソースを活用して、需要と事前定義された指標に合わせてスケーリングできます。その結果、需要がピーク時のサービスの中断を回避できます。
クラウド バースト シナリオに考えられる重要な要件は、ワークロードのポータビリティです。ワークロードを複数の環境にデプロイできるようにするには、環境間の違いを抽象化する必要があります。たとえば、Kubernetes を使用すると、異なるインフラストラクチャを使用するさまざまな環境でワークロード レベルの整合性を実現できます。詳細については、GKE Enterprise ハイブリッド環境のリファレンス アーキテクチャをご覧ください。
設計上の考慮事項
クラウド バースト パターンは、インタラクティブ型、バッチ型両方のワークロードに適用可能です。ただし、インタラクティブ型のワークロードを処理する場合は、環境間でリクエストを分散する方法を決定する必要があります。
受信したユーザー リクエストを既存のデータセンターで走行するロードバランサに転送し、ロードバランサでローカルおよびクラウドのリソース全体に分散させることができます。
このアプローチでは、クラウドに割り当てられているリソースのトラッキングも行うために、既存のデータセンターで稼働しているロードバランサまたは別のシステムが必要です。ロードバランサまたは別のシステムは、リソースの自動アップ スケーリングまたはダウン スケーリングも開始する必要があります。このアプローチを使用すると、アクティビティの低い時間帯にはすべてのクラウド リソースを廃止できます。一方、リソースを追跡するためのメカニズムを実装すると、ロードバランサ ソリューションのキャパシティを超え全体的な複雑さが増大する可能性があります。
リソースを追跡するためのメカニズムを実装する代わりに、ハイブリッド接続のネットワーク エンドポイント グループ（NEG）バックエンドを使用して Cloud Load Balancing を使用できます。このロードバランサを使用すると、内部クライアント リクエストまたは外部クライアント リクエストを、オンプレミスとGoogle Cloud の両方に配置され、重みベースのトラフィック分割などのさまざまな指標に基づくバックエンドに転送できます。また、 Google Cloudのワークロードのロード バランシング処理能力に基づいてバックエンドをスケーリングすることもできます。詳細については、グローバル外部アプリケーション ロードバランサのトラフィック管理の概要をご覧ください。
この方法には、Google Cloud Armor の DDoS 対策機能、WAF、Cloud CDN を使用したクラウドエッジでのコンテンツ キャッシュなど、その他にもいくつかの利点があります。ただし、追加のトラフィックを処理するには、ハイブリッド ネットワーク接続のサイズを調整する必要があります。
ワークロードのポータビリティで説明したように、ワークロードの整合性を実現するために、アプリケーションをほとんど変更せずに別の環境に移植できますが、アプリケーションが両方の環境で同じパフォーマンスを示すとは限りません。通常は基盤となるコンピューティング、インフラストラクチャのセキュリティ機能、またはネットワーキング インフラストラクチャの相違と、依存関係のあるサービスとの近接性によって、パフォーマンスが異なります。テストを行うことで、より正確な可視化が可能になり、パフォーマンスの予測を把握できます。
クラウド インフラストラクチャ サービスを使用して、ポータビリティのないアプリケーションをホストする環境を構築できます。需要のピーク時にトラフィックがリダイレクトされたときにクライアント リクエストを処理するには、次のアプローチを使用します。
- 一貫したツールを使用して、これらの 2 つの環境をモニタリングおよび管理します。
- ワークロードのバージョニングが一貫していることと、データソースが最新であることを確認します。
- 需要が増加し、クラウド ワークロードがアプリケーションのクライアント リクエストを受け入れることが予想される場合は、クラウド環境をプロビジョニングしてトラフィックを再ルーティングする自動化を追加することが必要になる可能性があります。
需要の少ない時間帯にすべての Google Cloud リソースをシャットダウンする場合、トラフィック ロード バランシングに主に DNS ルーティング ポリシーを使用することは、必ずしも最適とは限りません。これは主に次の理由によるものです。
- リソースを初期化してユーザーに提供できるようになるまでに時間を要する場合があります。
- DNS の更新は、インターネットを介して徐々に伝播する傾向があります。
結果として次のようになります。
- リクエストを処理するためのリソースがない時間帯であっても、ユーザーが Cloud 環境にルーティングされる可能性があります。
- DNS の更新がインターネットに伝播する間、ユーザーはオンプレミス環境にルーティングされ続けることがあります。
Cloud DNS では、ソリューションのアーキテクチャと動作（位置情報 DNS ルーティング ポリシーなど）に適した DNS ポリシーとルーティング ポリシーを選択できます。Cloud DNS は、内部パススルー ネットワーク ロードバランサと内部アプリケーション ロードバランサのヘルスチェックもサポートしています。その場合は、このパターンに基づく全体的なハイブリッド DNS 設定に組み込むことができます。
一部のシナリオでは、内部アプリケーション ロードバランサやクロスリージョン内部アプリケーション ロードバランサを使用する場合など、Cloud DNS を使用して Google Cloudでヘルスチェックによりクライアント リクエストを分散できます。このシナリオでは、Cloud DNS は内部アプリケーション ロードバランサの全体的な状態をチェックし、内部アプリケーション ロードバランサ自体がバックエンド インスタンスの状態を確認します。詳細については、DNS ルーティング ポリシーとヘルスチェックを管理するをご覧ください。
Cloud DNS スプリット ホライズンを使用することもできます。Cloud DNS スプリット ホライズンは、同じドメイン名の DNS クエリ発信元の特定のロケーションまたはネットワークに DNS レスポンスまたはレコードを設定するためのアプローチです。このアプローチは、アプリケーションがプライベートとパブリック両方のエクスペリエンスを提供するように設計されており、それぞれに独自の機能がある場合の要件に対応するために一般的に使用されます。このアプローチは、環境間でトラフィック負荷を分散する際にも有効です。
これらの検討事項を考慮すると、クラウド バースト機能は一般的に、インタラクティブ型のワークロードよりもバッチ型のワークロードに適しています。
利点
クラウド バースト アーキテクチャ パターンの主なメリットは次のとおりです。
- クラウド バースト機能は、データセンターやプライベート コンピューティング環境にある既存の資産の再利用を可能にします。この再利用は、永続的に行うことができます。または、既存の機器の交換期限が到来するまでの間行い、到来した時点で、クラウドの完全移行を検討することもできます。
- ピーク時の需要を満たすために過剰な容量を維持する必要がなくなり、限定公開のコンピューティング環境の使用率と費用効率を高めることができます。
- クラウド バースト機能により、コンピューティング リソースを過剰にプロビジョニングすることなく、バッチジョブを適切なタイミングで実行できます。
ベスト プラクティス
クラウド バースト機能を実装する際は、以下のベスト プラクティスを検討してください。
- クラウドで実行されるワークロードがオンプレミス環境で実行されるワークロードと同じ方法でリソースにアクセスできるようにするには、最小権限のセキュリティ アクセス原則でメッシュ型パターンを使用します。ワークロードの設計で認められている場合は、クラウドからオンプレミス コンピューティング環境へのアクセスのみを許可し、その逆の接続は許可しないようにできます。
- 環境間の通信のレイテンシを最小限に抑えるには、対象となるプライベート コンピューティング環境に地理的に近い Google Cloud のリージョンを選択します。詳細については、Compute Engine のリージョン選択に関するベスト プラクティスをご覧ください。
- バッチ型のワークロードにのみクラウド バースト機能を使用する場合は、すべての Google Cloud リソースを限定非公開にして、セキュリティ攻撃の対象領域を低減します。 Google Cloud 外部ロード バランシングを使用してワークロードへのエントリ ポイントを提供している場合でも、インターネットからこれらのリソースに直接アクセスできないようにします。
アーキテクチャ パターンとターゲット ソリューションの動作に合った DNS ポリシーとルーティング ポリシーを選択します。
- このパターンでは、DNS ポリシーの設計を恒久的に適用できます。また、需要のピーク時に別の環境を使用しており追加の容量が必要な場合にも適用できます。
- 位置情報 DNS ルーティング ポリシーを使用して、リージョン ロードバランサのグローバル DNS エンドポイントを設定できます。この方法には、 Google Cloud リージョンが存在するオンプレミス デプロイメントとともに Google Cloud を使用するハイブリッド アプリケーションなど、位置情報 DNS ルーティング ポリシーのユースケースが多数あります。
同じ DNS クエリに異なるレコードを提供する必要がある場合は、スプリット ホライズン DNS を使用できます（内部クライアントと外部クライアントからのクエリなど）。
詳細については、ハイブリッド DNS のリファレンス アーキテクチャをご覧ください。
DNS の変更が迅速に伝達されるように、DNS を適度に短い有効期間値で構成します。これにより、クラウド環境を使用しており追加の容量が必要な場合にユーザーをスタンバイ システムに再ルーティングできます。
緊急性がなく、ローカルにデータを保存しないジョブの場合は、通常の VM インスタンスよりも大幅に費用が抑えられる Spot VM インスタンスの使用を検討してください。ただし、前提条件として VM ジョブがプリエンプトされた場合、システムは自動的にジョブを再開できる必要があります。
必要に応じて、コンテナを使用してワークロードのポータビリティを実現します。また、GKE Enterprise は、この設計を実現するための重要な技術です。詳細については、GKE Enterprise ハイブリッド環境のリファレンス アーキテクチャをご覧ください。
Google Cloud から別のコンピューティング環境に送信されたトラフィックをモニタリングします。このトラフィックは、アウトバウンド データ転送料金の対象となります。
アウトバウンド データ転送量が多い状態でこのアーキテクチャを長期的に使用する場合は、Cloud Interconnect の使用を検討してください。Cloud Interconnect を使用すると、接続パフォーマンスを最適化し、特定の条件を満たすトラフィックのアウトバウンド データ転送料金を削減できます。詳しくは、Cloud Interconnect の料金をご覧ください。
Cloud Load Balancing を使用する場合は、必要に応じてアプリケーション容量の最適化機能を使用する必要があります。これにより、グローバルに分散されたアプリケーションで発生する可能性のある容量の問題の一部に対処できます。
システムが環境境界を越えて安全に認証できるように、環境間に共通の ID を確立して、システムを使用するユーザーを認証します。
機密情報を保護するため、転送中のすべての通信を暗号化することを強くおすすめします。接続レイヤで暗号化が必要な場合は、選択したハイブリッド接続ソリューションに基づいてさまざまなオプションを使用できます。これらのオプションには、VPN トンネル、Cloud Interconnect 経由の HA VPN、Cloud Interconnect 用の MACsec などがあります。