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

こんにちは!クラウドインフラの裏側を覗くのが大好きなSREの皆さん、そしてこれからネットワークの世界に飛び込もうとしているインフラ初学者の皆さん、いつも日々の運用お疲れ様です。

私たちが普段何気なく使っているクラウドサービスですが、その足回りであるネットワークの世界を深く覗いてみると、実は非常にドラマチックな仕組みが隠されています。

今回は、Google Cloud(GCP)の隠れた名機能であり、インフラコストとパフォーマンスのバランスを握る重要キー「Network Service Tiers(ネットワークサービスティア)」について、徹底的に解剖していきたいと思います。

「プレミアムティア」と「スタンダードティア」の2つが存在しますが、この違いを知っているだけで、月々のクラウド請求書を見たときの「うわっ!」という驚きをスマートに防ぎ、かつユーザーには最高の速度を届けることができるようになりますよ。

それでは、パケットが世界中を駆け巡る冒険の旅へ、一歩ずつ一緒に理解していきましょう!

—

1. ネットワークサービスティアってなに? 身近な輸送サービスに例えてみよう

突然ですが、皆さん、遠く離れた友人や家族に荷物を送るとき、どんな配送方法を選びますか?

  • 「絶対に翌日の午前中に届けたい!」から、専用の高速道路と自社便を使うプレミアムな宅配便。
  • 「急がないから、一番安く送りたい!」から、一般的な路線バスやフェリーを乗り継ぐエコノミーな配送方法。

GCPのネットワークサービスティアも、これとまったく同じ考え方です。

GCPには、世界中に張り巡らされたGoogle専用の超高速・超高品質なネットワーク網(グローバルバックボーン)があります。私たちがクラウド上に構築したサーバー(Compute Engineのインスタンスなど)から、インターネットへ向けてデータを送り出すとき、このGoogleの専用道路を使うか、それとも一般的なパブリックインターネット(いわゆる普通の一般道)を使うかを選べるようになっています。

これが、プレミアムティア(Premium Tier)とスタンダードティア(Standard Tier)の正体です。

—

2. プレミアムティア vs スタンダードティアの徹底比較

それぞれのティアが、パケットをどのように目的地まで運んでいるのか、もう少し詳しく見ていきましょう。

プレミアムティア(Premium Tier):Google特急のVIPルート

  • パケットの動き: ユーザーから一番近いGoogleの拠点(エッジロケーション)でデータを受け取り、そこから先はGoogleが自前で海底ケーブルや専用回線を敷き詰めたグローバルバックボーン網を通って、目的地まで一気に直行します。
  • メリット: 世界中のどこからアクセスしても、レイテンシ(遅延)が圧倒的に少なく、パケットロスが少ない安定した通信が可能です。マルチリージョン構成(例えば、東京とオレゴン)のロードバランサーも、このティアの力を借りて美しく動いています。
  • デメリット: その分、料金(データ転送料金)が少しお高めになります。

スタンダードティア(Standard Tier):地域の一般道路ルート

  • パケットの動き: Googleのデータセンターから外に出た瞬間、一般的なインターネットプロバイダー(ISP)の回線にパケットが飛び出します。いわゆる「普通のインターネットの経路」を通ってユーザーに届きます。
  • メリット: プレミアムティアに比べて、データ転送料金が安価に抑えられます。「社内向けのバッチ処理サーバーで、海外からのアクセスはない」「コストを極限まで削りたい」という場合には最高の選択肢になります。
  • デメリット: 経由するルーターやプロバイダーの数が増えるため、インターネットの混雑具合によっては通信速度が遅くなったり、パケットロスが起きやすくなったりします。

—

3. 実務での設定方法:Terraformとgcloudでティアを切り替えてみよう

「理屈は分かったけれど、実際にどうやって使い分けるの?」という声が聞こえてきそうですね。安心してください。GCPでは、リソースを作成する際にこのティアを明示的に指定するだけです。

今回は、実務でよく使われる Google Cloud CLI (gcloud) と、インフラ構成管理の定番である Terraform の設定サンプルをご紹介します。

パターンA: gcloudコマンドで外部IPアドレスを作成する

まずは、手動やスクリプトで静的外部IPアドレスを確保する際の設定です。デフォルトではプレミアムティアになっていますが、明示的にスタンダードティアを指定してみましょう。

# スタンダードティアの静的外部IPアドレスを東京リージョン(asia-northeast1)に作成する
gcloud compute addresses create my-standard-ip \
    --region=asia-northeast1 \
    --network-tier=STANDARD

# 作成されたIPアドレスの情報を確認する
gcloud compute addresses describe my-standard-ip \
    --region=asia-northeast1

> SREのワンポイントアドバイス:
> 上記のコマンドで --network-tier=STANDARD を指定することで、このIPアドレスはコストパフォーマンス重視の挙動に切り替わります。ただし、スタンダードティアのIPアドレスは「リージョン単位」でのみ作成可能(グローバルIPとしては使えない)という制限がある点に注意してくださいね。

パターンB: TerraformでCompute Engineに割り当てる

次に、Infrastructure as Codeの主役であるTerraformを使った設定例です。本番用のフロントエンドサーバーにはプレミアムを、コストを抑えたい内部向けAPIサーバーにはスタンダードを割り当てる、といった使い分けがコード上で一目でわかるように書くことができます。

# コストを抑えた社内向けサーバー用の静的外部IPアドレス(スタンダードティア)
resource "google_compute_address" "cost_effective_ip" {
  name         = "internal-batch-ip"
  region       = "asia-northeast1"
  network_tier = "STANDARD" # ここでスタンダードティアを指定
}

# 上記のIPアドレスをアタッチするCompute Engineインスタンス
resource "google_compute_instance" "app_server" {
  name         = "app-server-01"
  machine_type = "e2-medium"
  zone         = "asia-northeast1-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }

  network_interface {
    network = "default"

    # 外部IPアドレスの紐付け
    access_config {
      nat_ip       = google_compute_address.cost_effective_ip.address
      network_tier = "STANDARD" # アクセスコンフィグ側でもティアを合わせる
    }
  }

  # 設定ファイルの変更履歴や目的をコメントに残すのがプロのSRE流です
  description = "コスト最適化のため、このインスタンスの外部通信にはスタンダードティアを採用しています。"
}

—

4. 現場で直面する「落とし穴」と正しい選び方

ここまで聞くと、「じゃあ、全部スタンダードティアにしてコストを下げちゃえばいいのでは?」と思われるかもしれませんが、世の中そんなに甘くはありません(笑)。私たち現場のエンジニアが頭を悩ませるポイントをいくつかシェアしておきます。

1. サービスの特性を見極める

  • 一般ユーザー向けのWebサイトやECサイト、スマホアプリのバックエンドであれば、わずかな表示遅延がコンバージョン率(売上)の低下に直結します。ここはケチらずプレミアムティア一択です。
  • 一方で、バックアップデータの転送、ログの収集サーバー、限られた内部システム間の通信などであれば、スタンダードティアにすることで、クラウドのランニングコストを大幅に削減できます。

2. 可用性の違いに注意する

  • プレミアムティアはGoogleの堅牢なグローバルバックボーン全体で冗長化されていますが、スタンダードティアは通常のパブリックインターネットを経由するため、経路障害の影響を受けやすくなります。SLA(サービス品質保証)の要件をよく確認しましょう。

—

まとめ:ネットワークの選択は、ビジネスの選択である

今回は、GCPのネットワークサービスティア(プレミアムとスタンダード)について、身近な配送サービスへの例えから、実際のコード設定まで一気に駆け抜けて解説しましたがいかがでしたでしょうか?

一歩ずつ紐解いていくと、クラウドのネットワークは単なる「線のつながり」ではなく、「コスト」と「パフォーマンス」というビジネスの二大要素をコントロールするための強力な武器であることが分かりますよね。

「なぜこの設定にしているのか?」をチームメンバーやステークホルダーに自信を持って説明できるようになると、インフラエンジニアとしての楽しさが何倍にも膨れ上がります。

それでは、また次回のインフラ探訪でお会いしましょう!良いクラウドライフを!

コメント

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