VPCにおけるレイヤ2を意識する！裏側で輝く『マッピングサービス』を絵を描いて理解してみた
コンバンハ、千葉（幸）です。
突然ですが皆さんはVPCのマッピングサービス（Mapping Service）というものをご存知でしょうか？普段カスタマーとしてVPCを利用する上では意識する必要がないため、ご存知ない方も多いかと思います。かく言う私もきちんと存在を認識したのはごく最近です。
調べてみるとなかなか面白い世界だったため、自分なりに絵を描いて理解し、まとめてみました。本稿ではそれを用いて皆さんにMapping Serviceとは何ぞやのご紹介をしたいと思います。
（ちなみにブログのアイキャッチはこちらのスライドから引用しました）
なお、Mapping Serviceの詳細な仕様は公開されていないため、ソースとしては主に以下の2つを参照しています。
こちらはAWSのクラウドサポートエンジニアの方が寄稿された記事です。公開可能な範囲としてはこちらに網羅されているかと思いますので、メインのソースとさせていただきました。
こちらはSentiaという会社がまとめている記事です。末尾にAWS re:Inventの動画など各種ソースが載っているので、一次情報にあたりたいときはそれらを確認するとよいでしょう。
本稿を書くにあたってはなるべく一次情報を参照しましたが、解釈を誤っている箇所がある可能性があります。飽くまで参考に捉えていただければと思います。
目次
3行まとめ
- マッピングサービスには仮想マシンと物理ホストの紐付けを行う情報が記録されている
- 一部ゲートウェイはEdgeと呼ばれるデバイスでホストされており、その情報もマッピングサービスに記録されている
- マッピングサービスのおかげでゲストOSは物理層を意識することなく通信を実現できる
ケース1. 同一サブネットの通信
はじめに、以下のような構成を考えてみます。
VPC内に複数のサブネットがあり、そこに複数のインスタンスが存在します。ここでは、同一サブネット上に存在するインスタンスAからインスタンスBに通信を行いたいとします。同一サブネットの通信のため、VPC上に存在する仮想ルーターは経由しません。
一般的な同一セグメント内の通信
EC2インスタンスであることを一旦置いておいて、通常のTCP/IP通信に置き換えて考えてみましょう。
論理的には以下のように表されます。
ノードAが、ノードBに対して通信がしたいです。
ここでの通信において、送信元ノードは、宛先ノードのIPアドレスとMACアドレスの組み合わせを知っている必要があります。ノードAは自分が通信したい宛先のIPアドレスは把握していますが、初期状態においては、対応するMACアドレスを持つノードが分かりません。そこを確認するプロセスが必要であり、それはARP（Address Resolution Protocol）のリクエストとリプライによって行われます。
ノードAは、同一セグメント内のすべてのノードに対してブロードキャストでARPリクエストを送ります。ARPリクエストの中には宛先IPアドレスの情報が含まれています。
ARPリクエストを受領した各ノードはリクエスト内の宛先IPアドレスの情報を確認し、自身が宛先IPアドレスであった場合には送信元ノードに対するユニキャストでARPリプライを返答します。ARPリプライの中には自身のMACアドレス情報が含めています。このプロセスによって、ノードAはノードBのIPアドレスおよびMACアドレスの組み合わせを把握し、通信が可能となります。
VPC上のEC2インスタンスで考える
上記のような挙動をEC2インスタンス上のゲストOSがどのように実現するかを考えましょう。
（一部を）物理的に表したイメージは以下のようになります。
EC2インスタンスは、Amazonが管理する物理ホスト上で稼働しています。（実際には、また別の物理ホスト上に存在するEBSボリュームとネットワーク経由で接続されているわけですが、ここではその表現は割愛することにします。）同一サブネットに存在するインスタンスであっても、同一の物理ホストで稼働しているとは限りません。むしろ同一のホストで稼働している可能性の方が低いかと思います。インスタンスタイプの種別ごとにハードウェアの仕様が異なるため、そこの切り口によっても物理ホストは分かれることになります。
また、通常、1つの物理ホスト上に複数のVPCのインスタンスが稼働することになります。EC2のパラメータであるテナントがデフォルトの場合、物理ホストの占有はしないため、複数のAWSカスタマーのVPCおよびインスタンスが、1つの物理ホストに相乗りすることになります。
そして、EC2インスタンスは、アタッチされたENIによって、IPアドレスとMACアドレスの組み合わせを持つというのも大事なポイントです。
ここで、インスタンスAがインスタンスBの持つMACアドレスを知りたい場合、どのように解決することになるでしょうか。
Mapping Service
ここで登場するのが Mapping Serviceです。
Mapping Serviceは分散参照システムであり、いくつかの情報を管理しています。このケースでは以下の対応づけを担っています。
- インスタンスのIPアドレス
- インスタンスのMACアドレス
- 所属するVPC ID
- それらをホストする物理ホストのIPアドレス
インスタンスAがインスタンスBのMACアドレスを知るためにARPリクエストを送信すると、物理ホストはそれをインターセプトし、Mapping Serviceにクエリを投げます。Mapping ServiceにインスタンスBの情報が正しく登録されていればクエリの結果として返答されるため、物理ホストはその内容に基づきインスタンスBのMACアドレスをインスタンスAに対してARPリプライします。
Mapping Serviceは、インスタンスのローンチ時や停止→起動時など、インスタンスと物理ホストの紐付けがなされたタイミングで内容が随時更新されています。また、物理ホストに変更がなくとも、ENIの付け替えや、ENI内でのIPアドレスの割り当て/解放を実施したタイミングでも更新されていきます。
上記の流れによってインスタンスAはインスタンスBのIPアドレスとMACアドレスの組み合わせを把握したため、そこに向けたパケットを送信することが可能になります。
パケットは、物理ホストによって再度インターセプトされ、VPC IDに紐づいた形でカプセル化されます。物理ホスト間の通信は、それら（物理ホスト）が持つIPアドレスとMACアドレスの組み合わせによって実現されます。その通信におけるパケットが持つデータとして、カプセル化されたパケット（インスタンスが送信したもの）が含まれているということになります。インスタンスAの物理ホストは、Mapping Serviceへのクエリの結果からインスタンスBの物理ホストのIPアドレスを把握しているため、問題なく通信を行うことができます。
インスタンスBの物理ホストがパケットを受信すると、パケットが正しいものかを検証した上で、非カプセル化し、インスタンスBに対してパケットを送信します。こういった一連の挙動によって、インスタンス間の通信は物理ホストの経由を意識することなく実現できるようになっています。
ケース2. サブネットをまたいだ通信
続いて、以下のようにサブネットをまたいだ通信を行うケースを考えてみましょう。
インスタンスAが、別サブネットに存在するインスタンスDに対して通信を行いたいとします。
一般的なセグメントをまたいだ通信
再び論理的なイメージで考えます。
ノードAから見てノードDは異なるセグメントに所属しているため、直接「ノードDのIPアドレスとMACアドレス」の組み合わせでパケットを送信する事はできません。宛先MACアドレスにはデフォルトゲートウェイであるルーターが持つそれを指定することになります。
ノードAはデフォルトゲートウェイのIPアドレスに対するARPリクエストによってルーターのMACアドレスを把握したのち、パケットを送信します。宛先IPアドレスはノードDであるものの、宛先MACアドレスはルーターになります。
ルーターを経由する際に送信元MACアドレス、宛先MACアドレスの書き換えが行われ、一連の通信が実現することになります。
VPC上のEC2インスタンスで考える
こちらも物理ホストを踏まえた形式で考えてみます。
基本的な考え方は同一サブネット間の通信の際と変わりません。（両者のインスタンスがAZをまたぐ形で存在していれば、物理ホストが存在するファシリティも必ず異なることになりますが、ここではその表現は省略します。）
VPC上には仮想ルータが存在しており、これが各サブネット上のEC2インスタンスのデフォルトゲートウェイとなります。（ここでは各サブネットの第3オクテットから拝借して、仮想ルータ2、仮想ルータ3が存在するものとします。）
インスタンスAは自身のデフォルトゲートウェイである仮想ルータ2のMACアドレスを把握するためにARPリクエストを送信します。先ほどのケースと同じように物理ホストがインターセプトし、Mapping Serviceへのクエリの結果から仮想ルータ2のMACアドレスをARPリプライで返します。
宛先のIPアドレスとMACアドレスを把握したインスタンスAはパケットを送信しますが、それは再度物理ホストによってインターセプトされます。インスタンスDの物理ホストのIPアドレスについてMapping Serviceへのクエリが行われたのち、パケットはカプセル化され、インスタンスDの物理ホストに送信されます。物理ホストからインスタンスDに対してパケットが届く際には非カプセル化が行われるため、ケース1と同様に物理ホストにおける通信を意識しない形で通信が実現します。
このようにMapping Serviceに対するクエリは頻繁に行われるため、各物理ホストでキャッシュされるほか、単一障害点とならない工夫がなされているようです。
（仮想ルータのMACアドレスもMapping Serviceに登録されているという記述は確認できましたが、それをホストする物理ホストのIPアドレスも登録されているのか？については不明です。おそらく登録されていないと考えています。便宜上、上記の絵のように表現しましたが、仮想ルータはインスタンスのように単一の物理ホストによってホストされているものではないと想像しています。また、一連の通信において仮想ルータの物理ホストのIPアドレスは不要です。そのため、Mapping Serviceには登録されていないと考えています。）
ケース3. 各種ゲートウェイを経由した通信
以下のように、VPC内のインスタンスが各種ゲートウェイを経由して外部と通信するケースを考えてみます。
- インターネットゲートウェイ
- バーチャルプライベートゲートウェイ
- VPCエンドポイント（ゲートウェイ型）
Edgeデバイス（Blackfoot）
物理ホストを踏まえた形で考えます。新たな登場人物として、Edgeデバイスというものがあります。上述したようなゲートウェイは、EC2インスタンスの物理ホストとは異なる種類のデバイスによってホストされています。名称はBlackfootで、これは「黒足ペンギン（ケープペンギン）」が由来とのことです。デバイスがLinuxベースで開発されたことから、Linuxのマスコットであるペンギンのタックスに引っ掛けたようです。かわいいですね。
ここでは表現していませんが、これらのデバイスは冗長構成になっていて、可用性が担保されているものと思われます。例えばインターネットゲートウェイについては、以下の記載があります。
Q:インターネットゲートウェイに帯域幅制限はありますか? 可用性を気にする必要がありますか? これは単一の障害点になる恐れがありますか?
インターネットゲートウェイは水平にスケーリングされるため、冗長性と高可用性を達成できます。帯域幅制限はありません。
Amazon VPC のよくある質問
Edgeデバイスが持つIPアドレスもMapping Serviceに記録されています。インスタンスが各種ゲートウェイを経由して対向の環境に通信をしたい場合には、以下のような流れで実現されます。
- インスタンスがデフォルトゲートウェイである仮想ルータのMACアドレスをARPによって把握する
- インスタンスが仮想ルータに対してパケットを送信する
- 物理ホストがパケットをインターセプトし、パケット内の宛先IPを基にMapping Serviceから該当するエッジを判断する
- パケットをVPC IDに紐づく形でカプセル化し、エッジへ送信する
- エッジにより非カプセル化されのち、対向の環境に応じた再カプセル化などの処理を行った上で送信する
Edgeデバイスによるパケットの処理については以下のようなものがあります。
- インターネットゲートウェイであれば送信元IPをグローバルIPにNATする
- バーチャルプライベートゲートウェイ（VPN）であれば、IPsecヘッダで再カプセル化
- バーチャルプライベートゲートウェイ（DX）であれば、IEEE802.1QのVLANタグで再カプセル化
VPCエンドポイントについてはどのような処理が行われているかうまく汲み取れませんでしたが、以下のようにVPCエンドポイントIDに紐づく形で再カプセル化されているようです。
AWS re:Invent 2015 | (NET403) Another Day, Another Billion Packets より
上記以外のゲートウェイでは？
ここまで見てきたゲートウェイの他にも、VPCで使用できるネットワークコンポーネントとしてはTransit Gateway、NAT Gateway、VPCエンドポイント（インタフェース型）などがあります。これらはEdgeデバイスとはまた異なるアーキテクチャによって支えられています。
HyperPlaneと呼ばれるもので、相対的に新しい技術となります。こちらもなかなか興味深い技術なので、また別途取り上げたいと思います。
終わりに
というわけで、VPCを支える技術の一つであるMapping Serviceについてのご紹介でした。こういった仕組みのおかげで、カスタマーは難しいことを考えずネットワークを構成することができます。ルーターやスイッチといったネットワーク機器が抽象化され、コンポーネントの組み合わせだけで環境を構成できるようになっているというのは、VPCの大きな魅力であると思います。
サーバレスという話になると更に抽象化が進み、VPCすら意識する必要が無くなってくるわけですが、まだまだVPCが活躍する場面は多いですし、より深く知っていきたいものです。
VPCの裏側について皆さんが興味を持っていただければ何よりです。
以上、千葉がお送りしました。
