Terraform を使用したサーバーレス負荷分散: 地道な方法
Google Cloud Japan Team
※この投稿は米国時間 2020 年 11 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。
今年、Google Cloud は Cloud Run に対するクラウド ロードバランサのサポートを発表しました。Cloud Run サービスはすでに負荷分散されているのではないかと思われるかもしれません。たしかに、各 *.run.app エンドポイントは、コンテナの自動スケーリング セット間でトラフィックを負荷分散しています。しかし、今回はそれに加えて、サーバーレス プラットフォーム向けのクラウド バランシングの統合により、ネットワーク スタックの下位レベルを微調整できるようになりました。今回の記事では、このタイプのセットアップのユースケースを説明し、Terraform を使用して Cloud Run 用に HTTPS ロードバランサをゼロから構築します。
Cloud Run にロードバランサを使用する理由
すべての Cloud Run サービスには、HTTPS で保護され負荷分散された *.run.app エンドポイントがあります。さらに、Cloud Run では、サービスにカスタム ドメインをマッピングすることもできます。ただし、負荷分散の仕組みに関するその他の詳細をカスタマイズする場合は、Cloud HTTP ロードバランサを自分でプロビジョニングする必要があります。
クラウド ロードバランサの背後で Cloud Run サービスを実行する理由は次のとおりです。
Cloud CDN は Cloud Load Balancing と統合されているため、静的アセットを CDN で提供します。
Cloud Run はリージョン サービスであるため、複数のリージョンからのトラフィックを処理しますが、グローバル エニーキャスト IP を使用してロードバランサをプロビジョニングし、ユーザーを最も近い利用可能なリージョンにルーティングできます。
混合のバックエンドからコンテンツを提供します。たとえば、/static パスはストレージ バケットから提供でき、/api は Kubernetes クラスタに移動可能です。
購入したワイルドカード証明書など、自分の TLS 証明書を使用します。
サポートされている TLS バージョンや暗号などのネットワーク設定をカスタマイズします。
Cloud IAP を使用した特定のユーザーまたはグループの認証と認可の実施（これは Cloud Run ではまだ機能しません。しばらくお待ちください）。
Cloud Armor を使用して WAF または DDoS 保護を構成します。
このリストにはまだ続きがあります。クラウド HTTP 負荷分散には豊富な機能が揃っています。
Terraform を使用する理由
簡単に言えば、Cloud HTTP ロードバランサは、作成して相互に接続する必要がある多くのネットワーク リソースで構成されているためです。GCP API に「ロードバランサ」オブジェクトはありません。
今後のタスクを理解するために、以下の関連するリソースをご確認ください。
お使いのロードバランサの グローバル IP アドレス
Google が管理する SSL 証明書（または自分の証明書を使用）
IP アドレスをバックエンドに関連付ける転送ルール
HTTPS トラフィックを終端するためのターゲット HTTP プロキシ
HTTP トラフィックを受信し、HTTPS にリダイレクトするためのターゲット HTTP プロキシ
URL パスパターンのルーティング ルールを指定するための URL マップ
適格なバックエンドを追跡するためのバックエンド サービス
サーバーレス アプリをバックエンドとして登録できるようにするネットワーク エンドポイント グループ
ご想像のとおり、CDN を有効にするなどの単純なタスクを実行するためだけに、このようなリソースをプロビジョニングして接続するのは非常に面倒です。
このようなリソースは、gcloud コマンドライン ツールを使用して bash スクリプトを記述することでも作成できます。しかし、リソースがすでに存在するかどうか、または後で手動で変更するかどうかなどのケースを確認するのは面倒です。また、プロビジョニングしたものを削除するためのクリーンアップ スクリプトを作成する必要があります。
ここで Terraform が活躍します。いくつかのコマンドを使用するだけで、クラウド リソースを宣言的に構成し、さまざまな GCP プロジェクトでスタックを効率的に作成および破棄できます。
ロードバランサの構築: 地道な方法
この記事の目的は、Terraform 構成言語を使用したロードバランサの作成に関わる各リソースについて、地道な構成方法を意図的に示すことです。
まず、いくつかの Terraform 変数から見ていきます。
var.name: ロードバランサ リソースの命名に使用
var.project: GCP プロジェクト ID
var.region: Cloud Run サービスをデプロイするためのリージョン
var.domain: マネージド SSL 証明書のドメイン名
まず、次のように Terraform プロバイダを定義しましょう。
次に、サンプル イメージを使用して「hello」という名前の新しい Cloud Run サービスをデプロイし、未認証のアクセスを許可します。
Terraform の外部で Cloud Run のデプロイを管理する場合でも、まったく問題ありません。同等のデータソースをインポートして、構成ファイルでそのサービスを参照できます。
次に、グローバル ロードバランサ用にグローバル IPv4 アドレスを予約します。
次に、Google が発行および更新するマネージド SSL 証明書を作成しましょう。
独自の SSL 証明書を使用する場合は、独自の google_compute_ssl_certificate リソースを作成できます。
次に、サーバーレス サービスからネットワーク エンドポイント グループ（NEG）を作成します。
それでは、このネットワーク エンドポイントを追跡するバックエンド サービスを作成しましょう。
CDN、Cloud Armor、カスタム ヘッダーなどの負荷分散機能を構成する場合は、google_compute_backend_service リソースが適切な場所です。
次に、ルーティング ルールがない空の URL マップを作成し、前に作成したこのバックエンド サービスにトラフィックを送信します。
次に、HTTPS プロキシを構成して、Google が管理する証明書を使用してトラフィックを終了し、URL マップにルーティングします。
最後に、IP アドレスの HTTPS トラフィックをターゲット HTTP プロキシにルーティングするようにグローバル転送ルールを構成します。
このモジュールを作成したら、IP アドレスをリストする出力変数を作成します。
こうしたリソースを適用して、ドメインの DNS レコードがこの IP アドレスを指すように設定すると、巨大な機械が動き出すのです。
しばらくすると、Google Cloud はドメイン名の所有権を検証し、ドメインのマネージド TLS 証明書の発行を開始します。証明書が発行されると、ロードバランサの構成は世界中の Google のすべてのエッジ ロケーションに反映されます。これにはしばらく時間がかかる場合があります。
鋭い読者の方は、この設定のままでは、暗号化されていない HTTP トラフィックを処理できないことにお気付きでしょう。そのため、ポート 80 を経由するリクエストはすべてドロップされます。しかし、これは使い勝手としては優れていません。これを軽減するには、次の URL マップ、ターゲット HTTP プロキシ、転送ルールの新しいセットを作成する必要があります。
Terraform 構成も 150 行に近づいているので、おそらくここまででお気付きかと思いますが、これはサーバーレス アプリケーション用のロードバランサを取得する方法としては非常に地道なものです。
同例を試す場合は、こちらの gist からこの Terraform 構成ファイルのコピーを入手して、必要に応じて採用してください。
ロードバランサの構築: 簡単な方法
この複雑さに対処するために、Google では、クラウド HTTPS ロードバランサの背後にサーバーレス アプリケーションをデプロイするという難しい部分を省けるよう、新しい Terraform モジュールを設計しました。
次回の記事では、この新しい Terraform モジュールをさらに詳しく紹介し、これがいかに簡単になるかを解説しますので、楽しみにお待ちください。
-シニア デベロッパー アドボケイト Ahmet Alp Balkan
