【実務・中級編】 GCP Network Service Tiers (ネットワークサービスティア) の違い – クラウドインフラと仮想化ネットワーク実践ガイド

Google Cloudのネットワーク階層を使いこなす:Premium vs Standardの「見えない格差」を読み解く

インフラエンジニアの皆さんがGCPでロードバランサーを構築する際、ふと目にする「ネットワークサービスティア」の設定。深く考えずにデフォルトの「プレミアム」を選択し、そのまま運用していませんか?

あるいは、「コスト削減のためにスタンダードに切り替えたら、外形監視のレイテンシが悪化した」といった経験はないでしょうか。

この「ネットワークサービスティア」こそが、Googleという巨大なインフラの真髄を体現する設定項目です。今回は、単なる価格差の話を超えて、パケットが地球規模でどう流れているのか、その「物理的な真実」を解説します。

—

1. プレミアムティア:Googleの「専用高速道路」

プレミアムティアを選択するということは、「Googleの巨大なグローバル光ファイバー網」をエンドツーエンドで利用するということです。

パケットの旅路

ユーザーが東京からアクセスし、バックエンドが米国にあると仮定しましょう。プレミアムティアでは、ユーザーのパケットは最寄りのGoogleエッジPOPに入った瞬間、そこからはGoogleの私有バックボーン網を通ります。公衆インターネットの混雑や、ISP間の経路制御(BGP)の不安定さに左右されることはありません。

  • メリット: 低レイテンシ、低ジッタ、高い可用性。
  • 用途: グローバル展開するWeb API、リアルタイム性が求められるアプリケーション。

実際に体感してみる(調査用コマンド)

プレミアムティアであれば、tracerouteを実行すると、経由するホップの多くがGoogleの独自ドメイン(1e100.net)であることを確認できます。

# 自身のロードバランサーIPに向けてトレースを実行
# Googleのバックボーン内をいかに長く移動しているかがわかります
traceroute <ロードバランサーのIPアドレス>

—

2. スタンダードティア:インターネットという「荒野」

一方、スタンダードティアは「コスト最適化」の選択肢です。Googleのバックボーン網から降りた後のパケットは、パブリックインターネットを経由して目的地へ向かいます。

パケットの旅路

インターネットは「ベストエフォート」の塊です。パケットはISPの混雑状況によって、思わぬ遠回りをしたり、夜間にトラフィックが集中してパケットロスが発生したりします。

  • メリット: コストが安い。
  • デメリット: 経路が不安定。TCPの再送制御が頻発し、APIのレスポンスタイムが「揺らぐ」原因になります。

注意: Googleは、スタンダードティアの通信に対してSLAを保証していません。ミッションクリティカルなシステムでこれを選ぶのは、冬の雪山をノーマルタイヤで走るようなものです。

—

3. 実践:Terraformでのティア設定

インフラをコード化する際、このティアはnetwork_tierプロパティで制御します。

# GCPの外部ロードバランサー用IPアドレスの設定例
resource "google_compute_global_address" "default" {
  name         = "prod-api-lb-ip"
  address_type = "EXTERNAL"
  # ここを "PREMIUM" にするとGoogle網、"STANDARD" にすると公衆網
  network_tier = "PREMIUM" 
}

コストだけを見て STANDARD に変更する際は、APIの P99 レイテンシが悪化するリスクを許容できるか、必ず事前に検証してください。

—

4. 現場で使える「ティア判定」のデバッグ術

「この通信、本当にGoogleのバックボーンを通っているのか?」と疑ったとき、Pythonで手軽にレイテンシの揺らぎを可視化してみましょう。

import requests
import time

# 指定したURLのRTTを計測するシンプルなツール
def check_latency(url):
    for _ in range(5):
        start = time.time()
        try:
            requests.get(url, timeout=5)
            end = time.time()
            print(f"Latency: {(end - start) * 1000:.2f} ms")
        except Exception as e:
            print(f"Error: {e}")
        time.sleep(1)

# プレミアムティアとスタンダードティアで計測し、
# 偏差(ジッタ)が大きいならスタンダードの可能性が高い
check_latency("https://your-api-endpoint.com")

—

5. SREとしての「使い分け」の哲学

結局のところ、どちらを選ぶべきか。私の経験則としては以下の通りです。

1. グローバルなユーザー向けAPI: 迷わず プレミアムティア。レイテンシはユーザー体験(UX)そのものであり、直帰率に直結します。
2. 社内向けバッチ転送やバックアップ通信: スタンダードティア を検討。遅延や一時的な中断が許容できるなら、コスト効率を優先すべきです。
3. 特定のリージョン内で完結するサービス: Googleのバックボーンを経由する距離が短いため、プレミアムティアの恩恵を最大化できます。

最後に

クラウドインフラは「箱」ではなく「生き物」です。ネットワークサービスティアを理解することは、インターネットという巨大なインフラの上に、自分のビジネスをどう配置するかという意思決定そのものです。

「とりあえずプレミアム」で済ませるのではなく、その理由を語れるようになること。それが、一段上のエンジニアへと成長する第一歩ではないでしょうか。次回の配信では、このネットワーク階層と Cloud CDN を組み合わせた際の、キャッシュヒット率の劇的な変化について掘り下げていこうと思います。

コメント

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