ネットワーキング

グローバル HTTP(S) 負荷分散と CDN がサーバーレス コンピューティングをサポート

Google_Networking_02.jpg

※この投稿は米国時間 2020 年 7 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

多くのユーザーは、基盤となるインフラストラクチャのプロビジョニングと管理について心配する必要がないように、Google Cloud でサーバーレス アプリケーションを開発することを選択しています。さらに、サーバーレス アプリケーションはオンデマンドで拡張できるため、使用分に対してのみ料金を支払うことができます。しかし、これまで App Engine などのサーバーレス プロダクトは、Compute Engine などの VM ベースのプロダクトとは異なる HTTP 負荷分散システムを使用していました。このたび、外部 HTTP(S) 負荷分散との新たな統合により、App Engine(標準とフレキシブル)、Cloud Functions、Cloud Run などのサーバーレス プロダクトは、他の Google Cloud のサービスと同様に多くの機能を備えたエンタープライズ クラスの HTTP(S) 負荷分散機能を使用できるようになりました。

External HTTP(S) LB with Serverless.jpg

この統合により、単一のグローバル エニーキャスト IP アドレスのサービスへの割り当て、その証明書と TLS 構成の管理、Cloud CDN との統合、そして Cloud Run と Functions ではリージョン間の負荷分散が行えるようになりました。今後数か月にわたって、Cloud Identity-Aware Proxy(IAP)や Cloud Armor のサポートなどの機能を追加していく予定です。

サーバーレス ネットワーク エンドポイント グループのご紹介

今回の新しい機能は、Google Cloud ネットワーキングと負荷分散の基本機能であるネットワーク エンドポイント グループ(NEG)によって実現しました。このネットワーク エンドポイントのコレクションは、一部のロードバランサのバックエンドとして使用され、一連のエンドポイントへの到達方法や到達可能性、その位置を定義します。Google Cloud HTTP(S) 負荷分散は、インターネット NEG や Compute Engine のゾーン NEG など、いくつかのタイプの NEG をすでにサポートしていますが、そこにこのたびサーバーレス NEG が追加されました。これにより、外部 HTTP(S) 負荷分散で App Engine、Cloud Functions、Cloud Run サービスをバックエンドとして使用できるようになります。
External HTTP(S) LB_.jpg
サーバーレス NEG

サーバーレス NEG を外部 HTTP(S) ロードバランサに追加すると、サーバーレス ワークロードに数多くのメリットをもたらします。それでは詳しく見ていきましょう。

他のサービスとのシームレスな統合

Google Cloud HTTP(S) 負荷分散の主要な機能の 1 つは、複数の異なるバックエンド タイプ間での負荷分散です。そして、サーバーレス NEG の統合により、ロードバランサの URL マップがより使いやすくなり、サーバーレス NEG を他のバックエンド タイプと混在させることができるようになります。たとえば、外部の IPv4、IPv6 クライアントは、/catalog、/queries、/video、/images というパスを持つ同じベース URL を使用して、動画、API、画像コンテンツをリクエストできます。ロードバランサの URL マップを介して、さまざまなパスへのリクエストが、それぞれ異なるバックエンドにルーティングされます。

  • /queries - > サーバーレス NEG バックエンドを持つバックエンド サービス
  • /catalog -> VM インスタンス グループまたはゾーン NEG バックエンドを持つバックエンド サービス
  • /images -> Cloud Storage バックエンドを含むバックエンド バケット
  • /video -> Google Cloud 外のオンプレミスにある外部エンドポイントを含むインターネット NEG を指すバックエンド サービス

cloud load balancing.jpg

Cloud Run と Cloud Functions をマルチリージョンで利用可能

サーバーレス サービスと HTTP(S) ロードバランサが統合されたことにより、Cloud Run サービスと Cloud Functions サービスを複数のリージョンにデプロイできるようになりました。Cloud Run を例にとると、プレミアム ネットワーク サービス階層と単一の転送ルールで構成されたロードバランサは、クライアントに最も近いバックエンドの Cloud Run サービスにリクエストを配信します。複数のリージョンからのリクエストを処理すると、サービスの可用性とクライアントへのレスポンスのレイテンシが改善します。リクエストはユーザーに最も近いリージョンに到達しますが、そのリージョンが利用できないか容量が不足している場合、リクエストは別のリージョンにルーティングされます。

この機能を有効にするのは簡単です。Cloud Run サービスを別のリージョンにデプロイし、複数のサーバーレス NEG を設定して、ロードバランサをグローバル バックエンド サービスに接続するだけです。

Cloud CDN によるパフォーマンスの向上

Cloud Run、Cloud Functions、App Engine では、Cloud Storage バケットや非 GCP バックエンド(カスタム オリジン)と同じように、Cloud CDN を有効にできます。

HTTP(S) ロードバランサを使用して、静的コンテンツへのトラフィックを Cloud Storage バケットにルーティングし、ウェブユーザーまたは API クライアントをサーバーレス バックエンドにルーティングできます。これにより CDN を最大限に活用できます。つまり、Google のグローバルに分散されたエッジを利用して、定期的にアクセスされるコンテンツをユーザーに近い場所で迅速に提供できるようになります。

または、すべてのトラフィックをサーバーレス サービス(Cloud Run など)にルーティングし、適切な「Cache-Control」ヘッダーを返すことで、レスポンスごとにキャッシュするコンテンツを決定できます。これが特に効果的なのは、Cloud Run からパブリック REST API を提供していて、最もよくアクセスされるエンドポイントを Cloud CDN にオフロードする場合です。

サーバーレス オリジンで Cloud CDN を使用するには、サーバーレス NEG を含むバックエンド サービスで Cloud CDN を有効にするだけです。

Serving cacheable content.jpg
HTTP(S) ロードバランサと App Engine でキャッシュ可能なコンテンツを提供

SSL 証明書と SSL ポリシー管理

SSL 証明書管理と SSL ポリシーの両方がサーバーレス アプリケーションで利用可能になりました。これにより、サーバーレス アプリケーションへのトラフィックの認証と暗号化を行うための、最小の TLS バージョンと暗号を指定することがこれまでになく簡単になりました。

また、HTTP(S) 負荷分散とサーバーレス プラットフォームの統合により、Compute Engine、Cloud Storage、Google Kubernetes Engine(GKE)のドメイン トラフィックに使用している SSL 証明書と秘密鍵を再利用することもできます。そのため、別個の証明書を管理する必要がなくなります。

次のステップ

サーバーレス NEG と HTTP(S) 負荷分散の追加と統合により、企業のお客様は、サーバーレス コンピューティング プラットフォームを活用し、Google Cloud 全体で既存のワークロードと統合できます。これは Cloud Run の可用性を高め、Cloud CDN でパフォーマンスを向上させ、Cloud Storage や他のサービスとシームレスに統合します。

しかしまだ終わりではありません。たとえば、Cloud Armor との統合では、サーバーレス アプリケーションは DDoS 軽減サービスとウェブ アプリケーション ファイアウォールを利用できるようになります。また、Cloud IAP を統合すれば、サーバーレス アプリケーションは、BeyondCorp とそのゼロトラスト アーキテクチャのメリットを享受できます。これには ID とコンテキストに基づく認証と認可が含まれ、豊富なポリシー設定が可能になります。さらに、Cloud Run と App Engine を改善し、直接のアクセスを制限できるようにすることで、クライアントが HTTP(S) ロードバランサ経由でのみサーバーレス バックエンドにアクセスできるようにしていきます。詳細を確認して利用を開始するには、次のドキュメントをご覧ください。新しい機能についてのフィードバックをお待ちしています。

-  負荷分散担当プロダクト マネージャー Babi Seal、プロダクト マネージャー Daniel Conde