Google Cloud Armor、ロード バランシング、Cloud CDN を使用して、プログラム可能なグローバル フロントエンドをデプロイする

Last reviewed 2024-04-04 UTC

このドキュメントでは、Google Cloud でホストされるウェブ アプリケーションのリファレンス アーキテクチャについて説明します。このアーキテクチャでは、インターネットに接続されたアプリケーションのスケーリング、セキュリティ、配信の高速化を支援する Google Cloud のベスト プラクティスを組み込んだグローバル フロントエンドを使用します。このアーキテクチャには、Cloud Build のサポートに加えて、Jenkins や GitLab などのサードパーティの継続的インテグレーション(CI)ツールと継続的デリバリー(CD)ツールが含まれています。このアーキテクチャは、ロードバランサを使用してアプリケーションをスケーリングし、ウェブ アプリケーション ファイアウォール(WAF)を使用して分散型サービス拒否(DDoS)攻撃やウェブベースの攻撃からアプリケーションを保護することを必要とするデベロッパーとアプリ所有者を対象としています。

アーキテクチャ

次の図に、このドキュメントで説明するアーキテクチャを示します。

ウェブ アプリケーションのアーキテクチャ。

このアーキテクチャでは、アプリケーションはグローバル外部アプリケーション ロードバランサでロードバランスされます。このロードバランサは、HTTP トラフィックと HTTPS トラフィックを複数のリージョンにわたって複数のバックエンド インスタンスに分散します。Cloud CDN は、Google のエッジ拠点(PoP)を使用してインターネットに接続されたアプリケーションを高速化し、グローバル外部アプリケーション ロードバランサと連携してユーザーにコンテンツを配信します。バックエンドは、一般的なウェブ攻撃やその他のレイヤ 7 属性の受信リクエストをスクラブしてレイヤ 7 フィルタリングを行う Google Cloud Armor セキュリティ ポリシーによって保護されます。これにより、ロード バランシングされたバックエンド サービスに到達する前にトラフィックをブロックできます。ボリューム型 DDoS 攻撃に対する保護は、デフォルトで有効になっています。

ユーザーがサービスのコンテンツをリクエストすると、対象のリクエストは Cross-Cloud Network によって提供されるインターネットに接続されたアプリケーションのグローバル フロントエンドに送信されます。リクエストは、Google Cloud Armor エッジ セキュリティ ポリシーから始まる Google Cloud Armor セキュリティ ポリシーによって評価されます。リクエストが許可され、Cloud CDN で処理できる場合、コンテンツは Google Cloud Armor のキャッシュから取得され、ユーザーに返送されます。リクエストでキャッシュミスが発生した場合は、バックエンド ポリシーによって評価され、ポリシーのルールに従ってバックエンド サーバーによって拒否または処理されます。

アーキテクチャ コンポーネント

この図には、次のコンポーネントが含まれています。

  • グローバル外部アプリケーション ロードバランサ: このアプリケーション ロードバランサは、プロキシベースのレイヤ 7 ロードバランサであり、サービスを実行し、スケーリングできます。アプリケーション ロードバランサは、さまざまな Google Cloud プラットフォームでホストされているバックエンドに HTTP / HTTPS トラフィックを分散します。アプリケーション ロードバランサには次の機能があります。

    • 構成可能なバックエンド: このアーキテクチャでは、異なるリージョンの 2 つのマネージド インスタンス グループ(MIG)を使用しますが、グローバル外部アプリケーション ロードバランサがサポートするバックエンドを構成できます。GKE、Cloud Run、Cloud Functions、App Engine のアプリケーションに同じロードバランサを使用できます。また、オンプレミスや他のクラウドでホストされているアプリケーションには、異なるバックエンド構成を使用できます。詳細については、アプリケーション ロードバランサの概要をご覧ください。
    • トラフィック分割: アプリケーション ロードバランサはトラフィック管理に使用できます。たとえば、さまざまなユーザーをさまざまなバックエンド サーバーに送信してソフトウェア バージョンを管理できます。このドキュメントで説明するアーキテクチャでは、60 / 40 の単純なトラフィック分割が行われます。ただし、この分割を変更して、より複雑なトラフィック管理スキームを作成することもできます。その他の構成オプションについては、構成可能なタイムアウトと再試行を参照して目的のバランシング モードを判断してください。
  • Cloud CDN: Cloud CDN プラットフォームはキャッシュとして機能します。QUIC や HTTP/2 のほかにルーティングやキャッシュ制御などの Cloud CDN 機能のフルパッケージを提供するために、配信元サーバーによりデプロイされます。このアプローチにより、パフォーマンスを犠牲にすることなくアプリケーションをグローバルにスケーリングできるだけでなく、帯域幅とフロントエンド コンピューティングの費用も削減できます。グローバル フロントエンドで使用されるデフォルト構成は、Cloud CDN のコンテンツ配信のベスト プラクティスウェブ セキュリティのベスト プラクティスに基づいています。

  • Google Cloud Armor: このコンポーネントには、DDoS 保護と WAF ルールが含まれます。このアーキテクチャには、一般的な脅威ベクトルの軽減に有効な、次の基本的な Google Cloud Armor 構成が存在します。

使用するプロダクト

このリファレンス アーキテクチャでは、次の Google Cloud プロダクトを使用します。

設計上の考慮事項

このセクションには、このドキュメントを起点として、セキュリティ、信頼性、運用効率、費用、パフォーマンスに関する特定の要件を満たすアーキテクチャを開発する際に活用できるガイダンスを掲載しています。

セキュリティ、プライバシー、コンプライアンス

このセクションでは、このリファレンス アーキテクチャを使用してウェブ アプリケーションをデプロイする際に考慮すべきその他の要素について説明します。

セキュリティ ベースラインを確立する

セキュリティをさらに強化するために、このドキュメントで説明するアーキテクチャは、エンタープライズ基盤ブループリントとも互換性があります。このブループリントは、Google Cloud を使用している組織が、Identity and Access Management(IAM)Cloud Key Management ServiceSecurity Command Center の設定など、将来のすべてのワークロードの安全なベースラインを確立するのに活用できます。

Cloud CDN でユーザーデータを保護する

このアーキテクチャでは、ユーザー固有のコンテンツをキャッシュに保存しないことをおすすめします。HTML(text/html)と JSON(application/json)のコンテンツ タイプをキャッシュに保存するには、Cloud CDN レスポンスで明示的な cache-control ヘッダーを設定します。1 人のユーザーのデータをキャッシュに保存して、すべてのユーザーに配信しないようにしてください。

IAP を使用してアプリケーションへのアクセスを制御する

このアーキテクチャは、Identity-Aware Proxy(IAP)とも互換性があります。IAP は、ユーザーの ID を検証し、対象のユーザーにアプリケーションへのアクセスを許可するかどうかを決定します。グローバル外部モードと従来モードの両方のアプリケーション ロードバランサで IAP を有効にするには、ロードバランサのバックエンド サービスで IAP を有効にします。インバウンド HTTP / HTTPS リクエストは、アプリケーション ロードバランサによってロード バランシングのために送信される前に、Google Cloud Armor によって評価されます。Google Cloud Armor がリクエストをブロックした場合、IAP はリクエストを評価しません。Google Cloud Armor でリクエストが許可されている場合、IAP はリクエストを評価します。IAP がリクエストを認証しない場合、リクエストはブロックされます。詳細については、Google Cloud Armor と他の Google プロダクトの統合をご覧ください。

費用の最適化

一般的なガイドラインとして、Cloud CDN と Google Cloud Armor を併用すると、データ転送料金の影響を最小限に抑えることができます。

Cloud CDN

キャッシュからクライアントに提供される静的オブジェクトはロードバランサを経由しません。効果的なキャッシュ保存戦略により、ロードバランサで処理される送信データの量を減らし、費用を削減できます。

Google Cloud Armor

Google Cloud Armor を使用すると、不要なトラフィックに対するアカウントへの課金がなくなるため、コストを削減できます。Google Cloud Armor によってブロックされたリクエストについては、アプリからレスポンスが生成されないため、ロードバランサによって処理される送信データの量が効果的に削減されます。費用への影響は、実装する Google Cloud Armor セキュリティ ポリシーによってブロックされる不要なトラフィックの割合によって異なります。

最終的な費用は、保護するサービスやアプリケーションの数、設定されている Google Cloud Armor のポリシーとルールの数、キャッシュのフィルと下り(外向き)の量、データ量によっても異なります。詳細については、以下をご覧ください。

デプロイ

このリファレンス アーキテクチャをデプロイするには、Terraform の例を使用します。詳細については、README ファイルをご覧ください。web_app_protection_example フォルダには、main.tf ファイルが含まれています。このファイルのコードによって、このドキュメントで説明するアーキテクチャが作成され、自動デプロイの追加サポートが提供されます。

Terraform フォルダのフォルダ構造は次のとおりです。

パイプラインの基盤となるブランチへの変更を commit すると、変更によってパイプライン実行がトリガーされ、完了すると変更が新しいリリースに統合されます。ツールキットを初めて pull すると、選択した Google Cloud プロジェクトにソリューションが読み込まれます。

次のステップ

このリファレンス アーキテクチャで使用される Google Cloud プロダクトのベスト プラクティスの詳細を確認する。

寄稿者

作成者:

その他の寄稿者:

  • Alex Maclinovsky | エンタープライズ アーキテクト
  • Anderson Duboc | カスタマー エンジニア
  • Grant Sorbo | ソリューション アーキテクト
  • Michele Chubirka | クラウド セキュリティ アドボケイト
  • Rob Harman | テクニカル ソリューション エンジニア マネージャー
  • Susan Wu | アウトバウンド プロダクト マネージャー