AWSでジャンボフレーム使えるって知っていましたか？
みなさんはジャンボフレームという言葉を知っているでしょうか？
今回はAWSを普通に利用しているとあまり意識することがないであろうジャンボフレームを解説していこうと思います。
最初にまとめ
Q1. ジャンボフレームってなに？
A1. 私たちが普段利用しているイーサネットの最大MTUサイズは1,500なのですが、1,500を超えるものが総称してジャンボフレームと呼ばれています。
※ジャンボフレームは大抵の場合、9,000前後のMTUが利用されることが多いようです。
Q2. AWSでジャンボフレームってどうやって使うの？
A2. EC2やFargateなどの場合は、比較的新しい世代のインスタンスタイプ(EC2)やバージョン(Fargate)では自動で利用できるようになっています。AWSとオンプレなどをDXで接続する際にジャンボフレームを利用する際にはプライベート仮想インターフェイスまたはトランジット仮想インターフェイスのネットワーク MTU の設定を参考に設定する必要があります。
MTUとは
ジャンボフレームを説明する上でMTU(Maximum Transmission Unit)の理解が必要ですので、知らない方は↓をご参照ください。
ポイントは1回の通信で転送可能な最大のデータグラムサイズという部分です。
MTU (Maximum Transmission Unit)とは、 ノードが隣接したネットワークへ、1回の通信で転送可能な最大のデータグラムサイズです。
ジャンボフレームは何が嬉しいのか
イーサネットフレームの中には宛先アドレスや送信元アドレスなど、実際に送信したいデータ以外のオーバーヘッドが多く含まれます。
そのため、1つのイーサネットフレーム内に1,500ではなく、もっとたくさんデータを詰め込めば転送効率いいんじゃない！！的な発想から生まれました。
ジャンボフレームを利用することにより1回の通信でたくさんのデータが送れる上に、データ作成のオーバーヘッドが減ることでCPU利用効率も高くなります。
※考え方としては「小さな段ボールで荷物をたくさん送るよりも、大きな段ボールを使った方が効率良いよね。」みたいな感じです。
AWSサービスにおけるジャンボレームの取り扱い
コンポーネントやネットワークサービスによって違うようです。
詳しくは各ドキュメントを見ていただければと思います。
EC2のジャンボフレームについて
AWS 公式ドキュメント：ジャンボフレーム (9001 MTU)
TGWのジャンボフレームについて
AWS 公式ドキュメント：MTU
DXのジャンボフレームについて
AWS 公式ドキュメント：プライベート仮想インターフェイスまたはトランジット仮想インターフェイスのネットワーク MTU の設定
通信経路によるMTUの違い
今回はVPC AのEC2(10.0.0.10) <--> VPC XのEC2(10.100.0.250)間で通信する際のMTUの違いを図示します。
IGW, TGW, VPC peeringの経路ごとにMTUが異なっているのがパッとわかると思います。
※本来であればTGW or VPC peeringどちらか一方での通信となりますが、両方いっぺんに図示しています。
Tipsなのですが、①の通信はInternetを経由しません。
--> 図中の矢印①のようにAWS内のネットワークのみを経由するということことです。
Q:2 つのインスタンスがパブリック IP アドレスを使用して通信する場合、またはインスタンスがパブリックな AWS のサービスエンドポイントと通信する場合、トラフィックはインターネットを経由しますか?
いいえ。パブリック IP アドレスを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。
さらに、データセンターとリージョンを相互接続する AWS グローバルネットワークを流れるすべてのデータは、安全性が保証された施設を離れる前に、物理レイヤーで自動的に暗号化されます。すべての VPC クロスリージョンピアリングトラフィックや、カスタマーまたはサービス間のトランスポート層セキュリティ (TLS) 接続などといった追加の暗号化レイヤーもあります。
VPC peeringからTGWへ切り替える際の注意点
注意点を端的にいうと、 「VPC peeringとTGWのMTU不一致によりパケットがドロップされる可能性がある」 ということです。
TGWのAWS公式ドキュメントMTUに記載がある通り、TGWではMTU8,500を超えるパケットはドロップされます。
図中矢印の③VPC peering-->②TGWへ通信経路を切り替える途中でルーティングが非対称になった場合、VPC peeringではMTU:9,001。TGWではMTU:8,500となるため、VPC peering側のMTU:9,001が利用された場合にはTGWでパケットがドロップされます。
この注意点はAWS公式ドキュメントMTUにも以下記載があります。
transit gatewayを使用するために VPC ピアリングから移行している場合、VPC ピアリングとtransit gateway間の MTU サイズの不一致により、非対称トラフィックのパケットがドロップされる可能性があります。サイズの不一致によりジャンボパケットがドロップされないように、両方の VPC を同時に更新します。
そのため、VPC peering-->TGWへ切り替える際にはルートテーブルを同じタイミングで切り替えるように注意しましょう。
同じタイミングでルートテーブルを切り替えられない際は、事前にEC2にてMTUを8,500に設定しておくなどすることで回避できると思います。
MTUの変更については利用OSやインターフェース(ENI)の状況により様々なので、AWS公式ドキュメントなどを参考に設定変更していただければと思います。
また、EC2(Amazon Linux2)のpingコマンドを利用してTGWでMTU 8,500を超えるパケットがドロップされるのを確認する場合、以下のようにして確認することができます。
※pingはIPヘッダー(20byte)とICMPヘッダー(8byte)合わせて28byteなので、引数-sには(MTU - 28)を指定しています
VPC AのEC2 --> VPC XのEC2にMTU 8,500でping(pingが返ってくる)
[root@ip-10-0-0-10 ~]# ping 10.100.0.250 -s 8472 -c 1 -W 3
PING 10.100.0.250 (10.100.0.250) 8472(8500) bytes of data.
8480 bytes from 10.100.0.250: icmp_seq=1 ttl=254 time=1.45 ms
--- 10.100.0.250 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.458/1.458/1.458/0.000 ms
VPC AのEC2 --> VPC XのEC2にMTU 8,501でping(pingが返ってこない --> TGWでパケットドロップされた)
[root@ip-10-0-0-10 ~]# ping 10.100.0.250 -s 8473 -c 1 -W 3
PING 10.100.0.250 (10.100.0.250) from 10.0.0.10 : 8473(8501) bytes of data.
--- 10.100.0.250 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
おわり
ジャンボフレームやMTUについて理解できたでしょうか？
私もジャンボフレームやMTUなどの用語については知っていましたが、今回実際に手を動かしたことでさらに理解が深まりました。
数時間程度で削除すれば数ドル程度で図示した構成を作成することができますので、興味が出た方は実際に手を動かしてみてはいかがでしょうか？
この記事を読んでくださってくれた方がAWSやネットワークに少しでも興味を持ってくれると何より嬉しいです。
ここまで読んでくださってありがとうございました。
Discussion