Cloud NAT を強化しましょう: Cloud NAT の新機能のご紹介

※この投稿は米国時間 2021 年 9 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。

はじめに

Cloud NAT は Google の、フルマネージドでプロキシレスなネットワーク アドレス変換サービスです。このサービスは Andromeda SDN レイヤに完全に実装され、優れたパフォーマンスと容易なスケールを提供します。これにより、Compute Engine と Google Kubernetes Engine（GKE）のワークロードは、外部 IP を使った外部からのアクセスにさらされることなく、スケーラブルかつ安全にインターネット リソースにアクセスできます。

Cloud NAT は基本的に、多数のインスタンスに外部 IP アドレスを「拡張」することで機能します。これは、外部 IP ごとに利用可能なソースポートを、対象範囲内のすべてのインスタンスに均等に割り当てることで実現しています。NAT ゲートウェイに割り当てられた外部 IP アドレスを拡張するために、IP 自動割り当てを利用して自動化します。

ほとんどのお客様のワークロードには十分ですが、一部のモニタリングのベスト プラクティスでは、すべてのインスタンスがインターネットに通信できるだけの外部ポートを持つことを推奨しています。

Cloud NAT のスケーラビリティ、柔軟性、パフォーマンスを向上させる新機能を発表できることを嬉しく思います。

• Cloud NAT の動的ポートの割り当て

• Cloud NAT のカスタマイズされた TCP timewait

• Cloud NAT ルール

ポートを必要なときに、必要なだけ: 動的ポートの割り当ての紹介

Cloud NAT をモニタリングする主なベスト プラクティスの一つは、ワークロードのためのポートの可用性に気をつけておくことです。これは、ワークロードがインターネット上の同じ宛先に多数の並列接続を行う場合に、非常に重要となります。

以前、動的ポートの割り当て（DPA）を導入する前は、すべてのインスタンスが同じ NAT ゲートウェイの背後で同じ量のポート割り当てを受ける必要がありました。

想像できると思いますが、外部エンドポイントへの接続がすべてのワークロードに均等に分散されている場合、この方法はうまく機能します。しかし、特定のノードが外部に多くの接続を開く必要があり、他のノードはそうでない場合でも、すべてのノードのポート割り当てを増やす（ノード構成あたりの最小ポート数を利用して）必要があり、結果、貴重な外部 IP リソースを浪費することになります。

たとえば、NAT ゲートウェイの背後に 4,000 インスタンスをデプロイし、ノードあたりのポート数を 1,024 に構成した場合、NAT ゲートウェイに割り当てる外部 IP アドレスは 64 個必要となります。これらのノードのうちの 1 つが 4,096 ポートにバーストする必要があるとすると、その構成をすべてのノードに適用する必要があり、254 個の外部 IP アドレスを割り当てることになります（外部 IP のほぼ 24 分の 1）。1 つのノードには必要なポートが割り当てられますが、他の 3,999 のノードには、実際には必要のない 4,096 ポートが割り当てられ、ほぼアイドル状態になります。

そこで、DPA がこの問題を華麗に解決します。「VM インスタンスあたりの最小ポート数」と  「VM インスタンスあたりの最大ポート数」の両方を NAT ゲートウェイに構成することができるからです。ノードがポートを使い切り、「VM インスタンスあたりの最小ポート数」の構成を越えそうになると、DPA は自動的にそのノードだけにポートを割り当て、（そのたび、ポート数を 2 倍にしながら）構成された「VM インスタンスあたりの最大ポート数」の設定値まで、必要に応じてポートを割り当て続けます。逆に、ノードが接続の半分以上を解放すると、NAT ゲートウェイは構成された「VM インスタンスあたりの最小ポート数」に戻るまで、余分なポートを割り当てなくなります。

先ほどの例に戻ると、DPA が外部 IP を 1 つ追加して合計 65 個の外部 IP アドレスを割り当てるだけで、15 個のノードが同時に 4,096 ポートにバーストでき、残りのデプロイは 1,024 ポートに抑えられます。254 個もの外部 IP アドレスが必要だったのに比べ、大幅な改善です。

TCP Time_wait のタイムアウトのカスタマイズ

今回、TCP Timewait のタイムアウトが構成可能になりました。以前は、120 秒に静的に設定されていたのですが、構成はできませんでした。このタイムアウトを NAT ゲートウェイごとに構成できるようになったことで、接続完了までのスピードアップや、NAT ソースポートの新しい接続での再利用率の向上につながりました。

NAT ルールでソース IP ベースの宛先を選ぶ

Cloud NAT の一般的な使い方は、NAT ゲートウェイを 手動 IP 割り当てモードで構成し、予約した外部 IP アドレスを予測可能な IP アドレスからの送信元通信に追加または削除するというものです。

手動 IP 割り当てモードを選ぶ大きな理由の一つは、サードパーティのシステムとの通信時に、ソース IP アドレスを許可リストに登録できるようにするためです。たとえば、決済代行業者のエンドポイント、制限されたソース リポジトリ、レート制限された API などが想定できます。Cloud NAT は、予測可能な同じ外部 IP アドレスのセットを多くのインスタンスや GKE ノードに行きわたらせるのに最適と言えます。

残念ながら、これまでの Cloud NAT ゲートウェイでは、インターネット上のすべての宛先に同じセットの手動 IP アドレスが課せられていました。インスタンスがインターネット上の他の宛先により多くのポートを必要とする場合、NAT ゲートウェイに手動で IP アドレスを割り当て、すべての外部パートナーに IP アドレスを通知して、許可リストに加えるよう依頼しなければならなかったのです。  Cloud NAT ルールを使えば、すべて解決します。

NAT ルールは、以下のようなクラウドの革新的なユースケースを実現しました。

1. NAT ゲートウェイを構成すると、IP アドレスの許可を必要とする宛先にのみ小さな定義済み IP アドレスのセットを使用し、それ以外の宛先には大きなセットを使用できます。どちらのセットもそれぞれ独立してスケーリングできます（許可リストは本当に必要なときだけスケールアップできます）。

2. 優先度の低いエンドポイントに属する（つまり、ポートの枯渇による多少の接続の切断を許容できる）宛先 IP アドレスには、より小さな外部 IP アドレスのセットを割り当てられます。これにより、優先度の高い宛先にきちんとポートが割り当てられるようになります。

DPA と NAT ルールを組み合わせることで、さらにスケーラビリティを高めることができます。両方の機能が NAT ゲートウェイに構成されている場合、Cloud NAT は、デフォルトとルールベースの両方の宛先に対するポート割り当てをそれぞれインテリジェントに管理し、個別にスケールアップまたはスケールダウンします。

新しい NAT の機能をぜひ体験してみてください。NAT ルールの Codelab をぜひご試用ください。NAT ルール構成の例や、Cloud NAT の動的ポートの割り当てのドキュメントもご覧ください。まだ Cloud NAT をお使いでない方は、上記を参照して Compute Engine と GKE ワークロード で Cloud NAT を有効にする方法をご覧ください。

-プロダクト マネージャー、Tracy Jiang

- カスタマー エンジニア兼ネットワーキング スペシャリスト、Ghaleb Al-Habian