AWS Hyperplane を「都市の交通インフラ」にたとえて理解しましょう。
大都市には、地上の道路だけでなく、地下に張り巡らされたトンネルネットワークがあります。 水道管、ガス管、電線、地下鉄 — これらは市民には見えませんが、街のすべてのインフラを支えています。 AWS Hyperplaneは、AWSクラウドにおけるこの「地下インフラ」です。 NLB(ロードバランサー)やNAT Gatewayなどのサービスは「地上の建物」にあたり、 それらの裏側でパケット転送・フロー追跡を高速に処理しているのがHyperplaneです。
公開されている技術情報から、Hyperplaneの規模感を理解しましょう。
AWSサービス → Hyperplane → 物理インフラの3層構造を図解します。
Hyperplaneの内部は「頭脳」と「手足」の2つの役割に分かれています。
カーナビ(GPS)は「どのルートで行くべきか」を判断・計画します。 一方、道路そのものは車が実際に走る場所です。 仮にGPSが一時的に故障しても、すでに道を知っている車は走り続けられます。 コントロールプレーンはGPSナビ、データプレーンは道路にあたります。
Hyperplaneは8つ以上のAWSサービスのバックエンドとして機能しています。
マルチテナント環境で、特定顧客の大量トラフィックが他の顧客に影響しない仕組みを図解します。
病院に8人の医師がいるとします。従来の方法では4つの部門に2人ずつ配置(通常シャーディング)。 1部門に患者が殺到すると、その部門の医師が手一杯になり他の患者も診られません。 シャッフルシャーディングでは、各患者にランダムに3人の医師を割り当てます。 ある患者が大量に医師を使っても、他の患者と共有する医師は確率的に少なくなり、影響範囲が最小化されます。
Hyperplaneがサービスとユーザーのリソースを接続する「窓口」の仕組みを理解しましょう。
通常のENI(ネットワークインターフェース)は、1つのEC2に対して1つの「専用ポスト」のようなものです。 一方、Hyperplane ENI は「共有私書箱」です。 複数のLambda関数やApp Runnerサービスが同じサブネット + セキュリティグループの組み合わせであれば、 1つのHyperplane ENIを共有できます。 これにより、ENI上限に達することなく、大量のサービスをVPCに接続できます。
Hyperplaneの中核機能であるフロー追跡の仕組みと重要性を解説します。
ホテルのフロント係は、チェックイン時にお客さまに部屋番号を割り当て、 お客さまが滞在中は常に同じ部屋に案内します。 もし毎回ランダムな部屋に案内したら、荷物は迷子になり大混乱です。 Hyperplaneのフロー追跡は、通信の「お客さま」であるパケットフローを追跡し、 常に正しい宛先に届ける役割を担っています。
| サービス | フロー追跡で保証すること | 追跡しないとどうなるか |
|---|---|---|
| ⚖️ NLB | 同じクライアントの通信を常に同じターゲットインスタンスへ転送 | セッションが切れ、TCPコネクションが壊れる |
| 🌐 NAT GW | 各「送信元IP:ポート」ペアに一意な外部ポートを割り当て | ポート衝突が発生し、通信が混線する |
| 🔒 PrivateLink | プロバイダーVPCとコンシューマーVPC間のセッション維持 | VPC間の通信が断続的に切断される |
| 🛡️ Security Groups | 受信トラフィックに対応する送信ポートの自動解放(ステートフル) | 戻りトラフィックがブロックされ通信不能に |
2015年の本番投入から現在まで、Hyperplaneは対応サービスを拡大し続けています。
Hyperplaneは顧客のVPC分離をどう維持しているのか、セキュリティの観点から解説します。
ホテルの各部屋には水道があり、配管は建物全体で共有されています。 しかし、別の部屋の蛇口から他の部屋の水を出すことは絶対にできません。 Hyperplaneも同様に、複数の顧客のトラフィックを処理しますが、 VPCパケットのカプセル化により、他のVPCのデータが見えることはありません。 Hyperplaneはフロー追跡のみを行い、VPCの分離は物理ネットワーク層が担保します。
Created by SSuzuki1063
AWS SAP Learning Resources