NLBはなぜ暖機運転が不要なのか〜NLBの裏で動くサービスの解説〜

本記事はネットワークウィーク 8日目の記事です。
💻 7日目 ▶▶ 本記事 ▶▶ 9日目 🌐

はじめに
NLBはなぜ暖機運転が不要なのか？
AWS HyperPlaneとは
- 1セルあたりの性能（2018年時点）
- AWS HyperPlaneが支えるAWSサービス
AWS HyperPlaneの仕組み
おわりに
参考資料

はじめに

ドーモ、浮田です。

システムを安定して稼働させるためには、ELBのスケーラビリティが非常に重要です。事前にイベントによる急激なトラフィックの増加が判明している場合や負荷テストで大量のトラフィックを流したい場合、ALBに対してキャパシティユニットを予約し、暖機運転を行います。一方で、NLBは数百万リクエスト/秒のトラフィックを処理できるため、基本的に暖機運転を必要としません*1。では、なぜNLBでは暖機運転が不要なのでしょうか？

本記事では、NLBにおいて暖機運転が不要な理由と、NLBの裏で稼働しているAWSの内部サービスについて解説していきます。

※ AWS公式ドキュメントで明示されていない内部サービスに関する情報を含むため、推測や非公式な内容が含まれる可能性があります。あらかじめご了承ください。

NLBはなぜ暖機運転が不要なのか？

NLBは低遅延かつ可用性、拡張性に優れたAWS独自のネットワーク負荷分散サービスであるAWS HyperPlane(後述)を基盤にしており、暖機運転が不要なほどハイパフォーマンスだからです。

AWS HyperPlaneとは

AWS HyperPlane（以下、HyperPlane）は、AWS内部で使用されている限りなく低遅延かつ可用性、拡張性に優れたネットワーク負荷分散サービスのことです。 ALBと同様に実体はEC2インスタンスで構成されており、直接操作することはできません。

HyperPlaneは、アベイラビリティゾーンごとに独立したコントロールプレーンとデータプレーンを持ち、それぞれが独立してスケールアウトします。さらに、セルアーキテクチャに基づいて動作しており、障害が発生した際の影響範囲を最小限に抑える設計となっています。

トラフィックが増加しても、1つ1つのセルのサイズは変わらず、セルの数を増やすことでHyperPlaneの処理能力を拡張します。セルのサイズを固定化することで、大規模なサービスでありながらシンプルかつ堅牢な運用を可能にしています。

また、HyperPlaneでは、パケットがドロップされた場合でもクライアント側のTCP/IPによる再送制御が働くため、HyperPlane自身に再試行の仕組みはありません。

1セルあたりの性能（2018年時点）

TB/秒級のスループット
数億の接続
数千万/秒のトランザクション

※現在はさらに高性能になっている可能性があります。

AWS HyperPlaneが支えるAWSサービス

以下のAWSサービスがHyperPlaneを利用しています。 HyperPlaneの高い可用性とスケーラビリティを活かして構築されているため、トラフィックの急増や障害発生時にも安定したパフォーマンスを提供します。

NAT Gateway
AWS Transit Gateway
Gateway Load Balancer
Network Load Balancer
Amazon Elastic File System
AWS PrivateLink
VPC Lambda
AWS App Runner
etc...

AWS HyperPlaneの仕組み

マルチテナントとノイジーネイバー対策

HyperPlaneはマルチテナントアーキテクチャを採用しており、複数のAWS顧客によって共有されています。マルチテナントアーキテクチャには、ノイジーネイバー問題が発生する可能性があります。これは、ある顧客が過剰にリソースを消費することで、他の顧客のパフォーマンスに悪影響を及ぼす現象です。

この課題に対して、AWSではシャッフルシャーディングという技術を用いて対策しています。各顧客に対してHyperPlaneノードをランダムに割り当てることで、ノードの重複率を低くし、影響範囲を限定する仕組みです。

例えば、顧客Aの1秒あたりの接続数が急増した場合、AWSはその状況を検知し、顧客Aに割り当てるHyperPlaneノードの数を動的に増やします。これにより、顧客Aのトラフィックが増加しても、他の顧客（顧客Bや顧客C）への影響を最小限に抑えられるよう設計されています。

AWS HyperPlaneの構成

Top、Flow Master、Deciderの3つで構成されています。この構造により、HyperPlaneは柔軟かつ高性能なパケット処理を実現しています。初期段階ではFlow MasterとDeciderが関与しますが、接続が確立された後はTopが単独で処理を継続するため、非常に効率的な運用が可能です。

Top	パケットの転送および書き換えを担当する。接続が確立された後は、このTopのみが処理に関与する。
Flow Master	分散接続トラッキング機能を提供し、非常に優れた分散システムを実現する。
Decider	フローに対して適用されるルールを理解し、接続先のリソースを決定する。

パケット処理の流れ

Internet Gateway - NLB - EC2 の構成でユーザがEC2へアクセスした場合、HyperPlaneでは以下のような処理が行われます。

パケットがハッシュ化され、HyperPlaneセルのTopに到達する
TopがプライマリFlow Masterに問い合わせを行い、接続情報を求める
パケットがSYN（接続開始）の場合、Flow Masterは接続情報を持っていないため、Deciderに判断を委ねる
Deciderは、パケットのターゲットとしてEC2リソースを指定する
パケットに対する決定をセカンダリDeciderに共有する
この情報をセカンダリFlow Masterに渡し、分散接続テーブルにエントリが作成される
セカンダリFlow Masterはパケットに対する決定をプライマリFlow Masterに返す
パケットがTopに送られる
Topでパケットが書き換えられ、最終的にEC2インスタンスに転送される

接続が一度確立されると、以降の通信はTopのみで処理され、数十マイクロ秒程度という非常に高速な応答が可能になります。また、接続状態を維持するために、Topから定期的なハートビートがFlow MasterやDeciderに送信され、フロー情報が更新されます。これにより、障害やメンテナンスが発生した場合でも、迅速かつシームレスな復旧が可能となっています。

Topが停止した場合

HyperPlaneのTopがメンテナンスや障害により停止した場合、そのTopに関連付けられていたパケットは別のTopに再ハッシュされます。別のTopは、そのパケットを初めて受け取るため、プライマリFlow Masterに接続情報の問い合わせを行います。プライマリFlow Masterは接続情報を持っているため、それをTopに返すことで、一連のフローが途切れることなく継続されます。

この仕組みにより、たとえNLBに大量のリクエストが集中している状況でも、Topに障害が発生した際に接続が切断されることなく維持される設計となっています。

Flow Masterが停止した場合

プライマリFlow Masterが停止した場合でも、セカンダリFlow Masterが存在しており、フロー情報を引き継ぐことで接続を継続できます。また、Deciderが停止した場合も、同様の冗長構成が取られていると考えられ、フローの継続性が保たれる設計になっていると推測されます。

おわりに

今回は、NLBの裏で動いているHyperPlaneについて解説しました。

HyperPlaneは、AWSの内部ネットワーク負荷分散サービスです。ゾーンサービスやセルアーキテクチャ、Top/Flow Master/Deciderによる分散処理により、高可用性かつ拡張性がある設計になっています。このような仕組みによって、NLBは事前の暖機運転が不要であり、急激なトラフィックの増加にも対応することができます。 HyperPlaneは表に出てこないサービスですが、AWSの主要なサービスを支える重要なコンポーネントであることが、今回の解説を通じてご理解いただけたのではないのでしょうか。

参考資料

*1:https://aws.amazon.com/jp/blogs/news/webinar-bb-elastic-load-balancing-2019/