【ITニュース解説】Putting Your Site Behind G Cloud CDN, an unapologetically detailed, how-to
2025年09月05日に「Dev.to」が公開したITニュース「Putting Your Site Behind G Cloud CDN, an unapologetically detailed, how-to」について初心者にもわかりやすいように丁寧に解説しています。
ITニュース概要
外部GitLab環境をGoogle Cloud CDNで高速化する方法を紹介。HTTPSロードバランサーとCDNを導入し、キャッシュ、圧縮、エッジネットワークを活用してページロード時間を短縮。DNS設定、NEG作成、バックエンドサービス設定、HTTPSフロントエンド設定、キャッシュ設定、ヘルスチェックまで詳細手順を解説。設定ミスによるループや証明書エラー回避策も記載。
ITニュース解説
この記事は、外部にあるGitLabインスタンスのパフォーマンスを改善するために、Google Cloud CDN (コンテンツデリバリネットワーク) を導入する手順を解説している。CDNを導入することで、ページの読み込み時間を約50%短縮できる。特に、システムエンジニアを目指す初心者に向けて、各ステップの目的と注意点をわかりやすく説明している。
まず、CDN導入の全体像として、外部にあるGitLab VMの前に、グローバル外部HTTPSロードバランサ (GCLB) とCloud CDNを配置する。GCLBはクライアントとのTLS (Transport Layer Security) 通信を終端し、HTTPSでオリジンVMにトラフィックを転送する。この構成を実現するために、以下のステップを実行する。
ステップ1では、オリジンヘルパー名を作成する。これは、ロードバランサがオリジンVMにアクセスするための専用のDNSレコード (Aレコード) である。ロードバランサに設定するのと同じホスト名をNEGに設定すると、DNSループが発生するのを防ぐ。たとえば、gitlab.apps.dev.to をロードバランサに向け、 gl.apps.dev.to をオリジンVMのIPアドレスに向ける。
ステップ2では、インターネットNEG (Network Endpoint Group) を作成する。NEGは、ロードバランサがトラフィックを転送できるエンドポイントの集合である。外部オリジンの場合、インターネットNEGを使用する。これにより、GCLBが外部IPアドレスまたはFQDN (Fully Qualified Domain Name) をターゲットにできるようになる。
ステップ3では、バックエンドサービスを作成し、NEGを接続する。バックエンドサービスは、プロトコル、タイムアウト、負荷分散ポリシーなどを定義する。Cloud CDNを有効にすると、オリジンからの静的レスポンスがGoogleのエッジでキャッシュされる。オリジンが自己署名証明書を使用している場合は、バックエンドTLS検証を無効にすることで、証明書の問題を回避できる。
ステップ4では、グローバル外部HTTP(S)ロードバランサを作成する。これは、顧客が接続するエンドポイントであり、グローバルIPアドレス、HTTPSフロントエンド、およびバックエンドサービスにリクエストを転送するルーティングルールが含まれる。
ステップ4aでは、HTTPSフロントエンドを設定する。クライアントは、https://gitlab.apps.dev.to にアクセスした際に、Googleによって管理された有効な証明書を受け取る。ロードバランサはTLSを終端し、HTTP/2またはQUICを適用して、リクエストをバックエンドに転送する。
ステップ4bと4cでは、以前に作成したバックエンドサービスをロードバランサに接続し、ルーティングルールを設定する。ルーティングルールは、ホスト名とURLプレフィックスに基づいてトラフィックを異なるバックエンドにルーティングする。ここでは、gitlab.apps.dev.to へのすべてのトラフィックをNEGによってサポートされるサービス (オリジンVM) に送信する。
ステップ5では、証明書とHTTPSフロントエンドを設定する。ロードバランサでTLSを終端することで、クライアントは信頼できるGoogle管理の証明書を受け取る。ロードバランサからオリジンへのHTTPS接続を維持することで、エンドツーエンドの暗号化を確保する。
ステップ6では、DNSレコードを更新して、パブリックトラフィックをロードバランサに転送する。gitlab.apps.dev.to のAレコードをロードバランサのIPアドレスに向ける。オリジンヘルパーレコードは、NEGが実際のオリジンIPアドレスを解決するために保持する。
ステップ7では、キャッシュとCDNの設定を行う。GitLabは動的コンテンツとプライベートコンテンツを提供するため、「すべてのコンテンツを強制的にキャッシュする」ことは避ける。オリジンがCache-Controlヘッダーを通じて静的アセットのキャッシュを制御できるようにする。TTL (Time To Live) を1時間に設定することで、鮮度とエッジパフォーマンスのバランスを取る。
ステップ8では、キャッシュの無効化戦略を定義する。アップグレード後に古いアセットが提供されるのを防ぐために、パスまたはキャッシュタグに基づいてキャッシュを無効化する。
ステップ9では、ヘルスチェック、モニタリング、およびロギングを設定する。HTTPSヘルスチェックを設定して、ロードバランサがバックエンドの健全性を監視できるようにする。バックエンドロギングとロードバランサログを有効にして、キャッシュミスやリクエストの失敗をトラブルシューティングする。
ステップ10では、トラブルシューティングとロールバック計画を立てる。問題が発生した場合は、gitlab.apps.dev.to のAレコードをオリジンIPアドレスに戻して、トラフィックを直接GitLabに送信する。
最後に、オプションのクリーンアップ手順、Cloud Armorによる保護、オリジン証明書の検証、およびStackdriverロギングとモニタリングの有効化について説明する。
これらの手順に従うことで、外部GitLabインスタンスのパフォーマンスを改善し、ユーザーエクスペリエンスを向上させることができる。