【入門編】 GCP Cloud CDNの全体アーキテクチャとHTTP(S)ロードバランサーとの統合 – クラウドインフラと仮想化ネットワーク実践ガイド

こんにちは！日夜、世界中のパケットの交通整理に情熱を注いでいるSRE（サイト信頼性エンジニア）の執筆陣です。

突然ですが、みなさんはお気に入りのWebサイトやスマホアプリを開いたとき、「あれ、今日なんか表示が遅いな……」と感じてイライラしたことはありませんか？

インターネットの向こう側にあるサーバー（オリジンサーバー）がどれだけ高性能でも、物理的な距離が離れていたり、世界中から一斉にアクセスが集中したりすると、どうしてもネットワークの渋滞が発生してしまいます。

そんな「Webサイトの遅延」という強敵に立ち向かうための強力な武器が、Google Cloud（GCP）が提供する「Cloud CDN」と「外部HTTP(S)ロードバランサー」のコンビネーションです。

「インフラとかネットワークって、英語の専門用語ばかりで難しそう……」と身構えてしまう方も大丈夫です！今回は、難しい数式やパケットの細かいビット数はいっさい抜きにして、「郵便配達」や「身の回りのコンビニ」のような現実世界の仕組みに例えながら、その全体像を優しく、一歩ずつ紐解いていきましょう！

—

1. 現実世界で例える：Cloud CDNとロードバランサーの役割

まずは、登場人物たちの役割を現実世界の「お弁当屋さん」に例えて整理してみましょう。

[ お客さま（ユーザー） ]
       │  (お弁当が欲しい！)
       ▼
[ 注文受付窓口（ロードバランサー） ] ── (在庫がない？) ──＞ [ 本社工場（オリジン） ]
       │
   (在庫あり！)
       ▼
[ 街のコンビニ（Cloud CDN） ]  ★ここでお弁当をすぐにお渡し！
  • オリジンサーバー（本社工場）：

Webサイトのデータ（画像やHTMLなど）を一番最初につくって保管している大元のサーバーです。Google Cloudでいうと、仮想マシンの Compute Engine や、ファイル置き場である Cloud Storage がこれにあたります。

  • 外部HTTP(S)ロードバランサー（注文受付窓口）：

世界中から届く「このWebサイトを見せて！」という大量の注文（リクエスト）を、交通整理して適切な場所に振り分ける司令塔です。

  • Cloud CDN（街のコンビニ）：

本社工場（オリジン）で作られた人気の商品（画像などのデータ）を、あらかじめ仕入れて棚に並べておく「街のコンビニ（エッジサーバー）」です。

お客さま（ユーザー）が「お弁当（画像データ）が欲しい！」と言ったとき、わざわざ遠くの本社工場まで取りに行っていたら時間がかかりますよね。

そこで、街のコンビニ（Cloud CDN）に「お弁当のコピー（キャッシュ）」を置いておくのです。そうすれば、お客さまは一番近いコンビニで一瞬でお弁当を手に入れることができます。これがCDNの基本的なアイデアです。

—

2. Googleのネットワークはここがすごい！

Cloud CDNの凄さは、なんと言ってもGoogleが自社で保有する世界最大級のグローバルネットワークを使える点にあります。

一般的なインターネットは、色々な会社のネットワークを複雑に乗り継いで目的地に向かうため、途中で遅延が発生しやすい構造になっています。一般道で信号待ちを繰り返しながら進むようなイメージですね。

しかしGoogle Cloudの場合、ユーザーがブラウザでアクセスした瞬間、一番近くにあるGoogleの玄関口（これを PoP: Point of Presence と呼びます）に吸い込まれます。そこから先は、Googleが自社で敷設した超高速な専用の高速道路（光ファイバー網）を通るため、世界中のどこにオリジンサーバーがあっても、驚くほどのスピードでデータを届けることができるのです。

—

3. パケットの旅路：キャッシュヒットとキャッシュミスの違い

では、実際にユーザーがWebサイトにアクセスしたとき、ネットワークの裏側でどのようなデータのやり取りが行われているのか、2つのパターンに分けて見ていきましょう。

パターンA：キャッシュヒット（コンビニに在庫があった！）

ユーザーが求めている画像データが、すでに最寄りのエッジサーバー（Cloud CDN）に保存されていた場合です。

1. ユーザーが「あの画像ちょうだい！」とリクエストします。
2. 一番近いCloud CDN（エッジサーバー）が、「あ、その画像ならここに在庫があるよ！」と判断します。
3. ロードバランサーやオリジンサーバーまで行くことなく、その場ですぐにユーザーに画像を返します。

これにかかる時間はわずか数ミリ秒！本社工場（オリジン）には一切の問い合わせがいかないため、オリジンサーバーの電気代や処理の負担（負荷）を劇的に減らすことができます。

パターンB：キャッシュミス（コンビニに在庫がなかった……）

まだ誰もその画像にアクセスしていないか、保存期間が切れていて、エッジサーバーに在庫がない場合です。

1. ユーザーが「あの画像ちょうだい！」とリクエストします。
2. Cloud CDN（エッジサーバー）が「ごめん、いま在庫を切らしているんだ」と判断します。
3. リクエストは外部HTTP(S)ロードバランサーを経由して、奥にいるオリジンサーバー（本社工場）へ転送されます。
4. オリジンサーバーが「はい、どうぞ！」と画像を出荷します。
5. 帰り道、Cloud CDNは「次のお客さまのために、この画像のコピーを棚に置いておこう」と、自分のところにデータを保存（キャッシュ）します。
6. 無事にユーザーに画像が届きます。

次からは、別のお客さまが来ても「パターンA（キャッシュヒット）」になるため、2回目以降は爆速で届くようになります。

—

4. 実際に構築してみよう！

「難しそう……」と思われるかもしれませんが、Google Cloudでの設定は驚くほどシンプルです。基本的には、「外部HTTP(S)ロードバランサー」のバックエンド（通信の行き先）の設定で、Cloud CDNのスイッチを「ON」にするだけで動き始めます。

ここでは、実務でもよく使われる2つの方法（コマンドラインツール gcloud と、インフラをコードで管理する Terraform）の設定例を見てみましょう。

方法1：gcloud コマンドでCDNを有効化する

すでに作成済みのバックエンドサービス（my-backend-service）に対して、Cloud CDNを有効にするコマンドです。

# バックエンドサービスに対してCloud CDNを有効（Enable）にします
gcloud compute backend-services update my-backend-service \
    --global \
    --enable-cdn \
    --cache-mode=CACHE_ALL_STATIC
  • --enable-cdn: これを指定するだけで、Cloud CDNが有効になります。
  • --cache-mode=CACHE_ALL_STATIC: 「画像やスタイルシートなどの静的なファイルを自動でキャッシュしてね」という設定です。

—

方法2：Terraform（テラフォーム）で美しく定義する

インフラをコードで管理する場合は、以下のように記述します。まるで設計図を書くように、シンプルに定義できますよ。

# 外部HTTP(S)ロードバランサーのバックエンドサービスを定義します
resource "google_compute_backend_service" "default" {
  name                  = "my-cdn-backend-service"
  provider              = google
  protocol              = "HTTP"
  port_name             = "http"
  load_balancing_scheme = "EXTERNAL_MANAGED" # 外部管理型のロードバランサーを指定

  # ★ここが重要！CDNを有効にするスイッチです
  enable_cdn = true

  # CDNの細かい振る舞い（キャッシュポリシー）を設定します
  cdn_policy {
    # キャッシュのモードを指定します（静的コンテンツを自動キャッシュ）
    cache_mode = "CACHE_ALL_STATIC"

    # クライアント（ブラウザ）に対して「最大で1時間（3600秒）は手元に保存していいよ」と指示します
    client_ttl = 3600

    # Cloud CDNのエッジサーバーに「最大で1日間（86400秒）はデータを保存してね」と指示します
    default_ttl = 86400

    # 万が一、オリジンサーバーが一時的に動かなくなっても、
    # 古いキャッシュデータを代わりに返してWebサイトを維持する優しい機能（1時間有効）
    serve_while_stale = 3600
  }
}

—

5. 現場のプロが教える！トラブルを防ぐための泥臭い知見

Cloud CDNは魔法のように便利ですが、実際の現場では少しだけ注意が必要です。初心者が陥りがちな「2つの落とし穴」と、その対策を優しくお伝えします。

落とし穴①：「画像を更新したのに、古い画像が表示され続ける！」

これはCDNの「あるある」です。コンビニの棚に古いお弁当（古いキャッシュ）が残っているため、せっかく本社工場（オリジン）で新しいお弁当を作っても、お客さまには古いものが届いてしまいます。

  • 対策：キャッシュの「パージ（削除）」を行いましょう！

Google Cloudの管理画面やコマンドから、「このURLのキャッシュを今すぐ捨てて！」と命令（パージ）を出すことで、強制的に最新のデータをオリジンに取りに行かせることができます。

# 特定の画像（example.png）のキャッシュを強制的に削除します
gcloud compute url-maps invalidate-cdn-cache my-video-map \
    --path "/images/example.png"

落とし穴②：「個人情報をキャッシュしてしまった！」

マイページのような「ログインした人ごとに内容が変わる画面」をキャッシュしてしまうと、別の人にその個人情報が見えてしまうという大事故に繋がります。

  • 対策：キャッシュする対象は「誰が見ても同じデータ」だけに限定しましょう！

HTMLのヘッダー情報（データの取扱説明書のようなもの）に、Cache-Control: private や no-store という目印をつけておくことで、Cloud CDNに対して「これは個人情報だから、絶対にコンビニの棚に並べちゃダメだよ！」と伝えることができます。

—

まとめ：一歩ずつ、信頼性の高いインフラへ

今回は、GCPの「Cloud CDN」と「外部HTTP(S)ロードバランサー」がどのように手を取り合って、ユーザーに爆速で安全にコンテンツを届けているのかを解説しました。

最後に、今回のポイントを振り返ってみましょう。

1. Cloud CDNは「街のコンビニ」。よく使われるデータをユーザーの近くに置いておく。
2. ロードバランサーは「優秀な仕分け人」。届いたリクエストを整理して、適切に振り分ける。
3. Googleのグローバルネットワークという超高速な専用道路があるから、どこからアクセスしても速い。
4. 「個人情報はキャッシュしない」などのルールを守ることで、安全で快適なWebサイトが作れる。

インフラやネットワークの世界は、一見すると難解な英語や数字の羅列に見えますが、その本質は「いかにして無駄を省き、優しく、スピーディーに目的地まで届けるか」という、現実世界の物流や郵便と同じ思いやりでできています。

焦らず、一歩ずつ理解を深めていきましょう。あなたのインフラエンジニアとしての第一歩を、私たちはいつでも応援しています！

スポンサーリンク

コメント

タイトルとURLをコピーしました