Google Cloud Platform

Cloud NAT : ソフトウェア定義型の新しいネットワーク アドレス変換サービス

※この投稿は米国時間 2018 年 10 月 17 日に Google Cloud blog に投稿されたものの抄訳です。

アプリケーションを実行するときに利用するネットワーク サービスの中でも、NAT(ネットワーク アドレス変換)はきわめて重要です。NAT により、アプリケーションのデプロイ環境をプライベートに保ちながらインターネットにアクセスすることができます。私たちは先ごろロンドンで開催した Google Cloud Next London '18 において、フルマネージドの Cloud NAT サービスのベータ版を発表しました。今回はこのサービスについて詳しく見ていきましょう。

Cloud NAT のメリット

アプリケーションを Cloud NAT ゲートウェイの背後に配置すると、そのアプリケーションは管理された効率的な方法でインターネットにアクセスできますが(更新、パッチ管理、構成管理などのため)、外部のリソースはそれらのインスタンスに直接アクセスすることはできません。したがって、お客様の Google Cloud VPC(Virtual Private Cloud)は分離によって安全性が保たれます。

fvSUig3JTZPtrOZ580pP85oeeRGzfcYJ5n4d3ldQNlKnkMNodj4KrEeIFI_LpNg0sW0YBpAZiZ0E9DYNzU_860hf2daUqJCZyzGEApUjAGtT4PlK2JbPFbz8L3VAYhiNS739Q_7qhjob.PNG

Cloud NAT は、他の NAT サービスと比べてさまざまなメリットを提供します。

  • Cloud NAT は、管理される中間プロキシがないソフトウェア定義型ソリューションであり、ボトルネックのない設計によって高い信頼性、パフォーマンス、スケーラビリティを実現します。
  • Google Compute Engine 仮想マシン(VM)と Google Kubernetes Engine(コンテナ)の両方をサポートします。
  • NAT ゲートウェイごとに複数の NAT IP アドレスを構成できるので、別の NAT ゲートウェイの追加や管理を行うことなく、ネットワーク規模に基づいてスケーリングを行えます。
  • お客様に固有の要件に応じて、手動モードと自動モードのどちらかを選んで NAT IP アドレス割り当てを行うことができます。手動モードのときは、IP アドレス指定時に完全な制御が可能です。自動モードのときは、インスタンス数に基づいて NAT IP アドレスの割り当てとスケーリングが自動的に行われます。
  • 構成可能な NAT タイムアウト タイマーでタイマー値を調整できます。
  • サブネット内のインスタンス数にかかわらず、1 つの NAT ゲートウェイでリージョンの VPC 内のすべてのサブネットで NAT を実現します。
  • 1 つのゾーンが使用不能でも、リージョン単位で高い可用性を提供します。

Cloud NAT を早期に導入したお客様は、こうした機能を既存の Google Cloud 環境に首尾よく実装しています。

「Cloud NAT を導入したのは、私たちの 既存の Google Cloud 環境を Cloud NAT がどのように扱うかを調べるためでした。すべてが指定どおりに、すぐに順調に機能しました」と、bol.com のリード システム エンジニアである Wietse Muizelaar 氏は述べています。

ボトルネックのないソフトウェア定義型の NAT

dhcI6lOeRoyrquzCE_vpbvgH_1PTr_Va7B_CHI-qHfyj-bdp2fSgxspHvJDOnRBAfWrVLEMyF9n74TjAdkd7n7B83ckgbM99KuEnScBt2A-BK45gewqPCtPJuPZPqIemQMMs_rxJi3c2.PNG

Cloud NAT はフルマネージドのソフトウェア定義型サービスであり、インスタンスやアプライアンス ベースのソリューションではありません。インスタンスから宛先への経路に NAT 中間プロキシがないという点で、従来の NAT プロキシ ソリューションとは異なります。各インスタンスには、NAT IP アドレスとともに、対応づけられたポート範囲が割り当てられます。この割り当てられた IP アドレスとポート範囲は、Google の Andromeda ネットワーク仮想化スタックによってインスタンスにプログラミングされ、インスタンスによって NAT を実行するために使用されます。

実際、私たちの Cloud NAT 実装は、ファイアウォールのように、お客様の内部のインスタンスと外部の宛先の間の経路にボトルネックが発生しないように分散されます。このアプローチは、Cloud NAT のスケーラビリティ、パフォーマンス、スループット、可用性を高めることに貢献します。

NAT IP アドレスの割り当てモード

私たちが Cloud NAT の IP アドレス割り当てモデルを設計していた頃のことですが、「手動による静的な NAT IP アドレスの指定を構成できることが不可欠」という声がお客様から寄せられました。外部サーバー上のファイアウォールでこうした NAT IP アドレスを許可できるようにするためとのことでした。また、Google Cloud Load Balancing などの Google サービスを使い慣れたお客様からは、ロード バランサと同じように「Cloud NAT IP アドレスも自動スケーリングできるようにしてほしい」との要望をいただきました。

そこで私たちは、NAT IP アドレス割り当てに関して 2 つのモードを用意することにしました。

  • NAT ゲートウェイによる IP アドレスの自動割り当て : GCP が VM の数に基づいて NAT IP アドレスの自動割り当てと自動スケーリングを行います。これは、NAT のために十分な IP アドレスを確保する最良の方法です。ただし、この方法の場合、NAT IP アドレスからアクセスされる側では IP ホワイトリスティングが難しいことに注意してください。不要になった一部の IP アドレスが解放されるからです。
  • NAT ゲートウェイで使用される特定の NAT IP アドレスを指定 : NAT ゲートウェイで使用されるように 1 つまたは複数の NAT IP アドレスを手動で指定します。これらの IP アドレスは、予約された静的なものでなければならず、IP アドレスの自動割り当ては行われません。このモードが好まれるのは、NAT IP アドレスからアクセスされる側で NAT IP ホワイトリスティングを行う必要があるときです。ただし、すべての必要なインスタンスのために NAT を実行するのに十分な NAT IP アドレスがない場合、インスタンスの一部は NAT を利用できないことに注意してください。より多くの NAT IP アドレスが必要なときはログ メッセージが表示されます。

VPC で NAT ゲートウェイを起動

以上で、お客様の環境で NAT ゲートウェイをセットアップする準備が整いました。例を見てみましょう。

2 つのリージョンにおいて、3 つのサブネットを含む GCP ネットワークを使っているとします。

  • Us-east1
  • subnet 1(10.240.0.0/16)と subnet 2(172.16.0.0/16)
  • europe-west1
  • subnet 3(192.168.1.0/24)

subnet 1(10.240.0.0/16)と subnet 3(192.168.1.0/24)の VM は外部 IP アドレスを持っていませんが、203.0.113.1 の外部サーバーから定期的にアップデートを取り込む必要があります。subnet 2(172.16.0.0/16)の VM は、こうしたアップデートを取り込む必要がなく、NAT ゲートウェイを使用する場合でもインターネットへの接続を許可してはなりません。

DZPXtJ7jMQoC2-kiXixSPx2GiWotjPCSOeb1fmk2e_05q3Lq7r1Wz8jOi88fqQSxxx-3aDA-hON7wUGGuc9ht6OTVYpec42UrOICmj1fN-r8D1FFo0-NlARTPw_HQ64NFZj4eXUb5w30.PNG

このセットアップを適用するには、リージョンおよびネットワークごとに 1 つの NAT ゲートウェイを構成します。

1. subnet 1(10.240.0.0/16)に NAT-GW-US-EAST を構成します。

2. subnet 3(192.168.1.0/24)にNAT-GW-EU を構成します。3

3.各 NAT ゲートウェイを、トラフィックの変換が必要なサブネットワークで構成します。

  • NAT-GW-US-EAST を subnet 1(10.240.0.0/16)
  • NAT-GW-EU を subnet 3(192.168.1.0/24)

4. subnet 2 については NAT を構成しません。これによって subnet 2 は、この例で想定されているようにインターネットから分離されます。

Cloud NAT のセットアップの詳細については、Google Compute Engine と Google Kubernetes Engine に対応したこちらの Cloud NAT 構成をご覧ください。

GKE 用の Cloud NAT

サブネットの全範囲を NAT 変換するように Cloud NAT を構成することで、Google Kubernetes Engine(GKE)コンテナで Cloud NAT を利用できます。

OxKFX_e3nQ2UATEurZcuyPEAzNowy2PAfLwBYy9ZFCOU2Y8UMatDw6BJrcvjv5rV0DBBI9gnQJMGbFGMbgzL9CWmKaSu4zM1Q_btZuae6j3mIesZmulHDnejfRTUF3GGBlDc86Tqwhjl.PNG

ノードとポッドの両方が Cloud NAT を利用できます。ポッドが NAT を利用できないようにしたい場合は、そのためのクラスタ ネットワーク ポリシーを作成します。

上の例では、コンテナに対して NAT 変換が行われるようにします。すべてのコンテナと GKE ノードで NAT を有効にするには、subnet 1 のすべての IP アドレス範囲を NAT 候補として選択しなければなりません。Container1 または Container2 でのみ NAT を利用することはできません。

利用料金

Cloud NAT は Google Cloud のすべてのリージョンで提供されており、ベータ期間中の利用は無料です。Cloud NAT の正式公開(GA)後は、各ゲートウェイについて以下の料金が課金されます。

  • 各 NAT ゲートウェイにつき 1 時間あたり 0.045 ドルから
  • NAT データ処理費用

また、GCP インスタンスとインターネット間でデータを移動するための下り転送コストについては、これまでと変わりません。詳しくはこちらをご覧ください。

今すぐお試しを!

私たちは、お客様の Google Cloud ワークロードやサービスのデプロイと管理を容易にするべく、Cloud NAT のような機能の提供に精力的に取り組んでいます。Cloud NAT の詳細はオンライン ドキュメントをご覧ください。Cloud NAT サンプルを使用してデプロイをお試しいただければ幸いです。フィードバックがありましたら、ぜひ gcp-networking@google.com までお寄せください。

- By Vijay Madhavapeddi, Technical Lead and Engineering Manager and Prajakta Joshi, Sr. Product Manager, Cloud Networking