AWSのサーバ、ネットワークインタフェースカード
もっと深く見ていきます。今度はサーバ、そしてネットワークインタフェースカード（NIC）について見てみます。
ここで取り上げたいのがサーバ間の遅延です。アベイラビリティーゾーンの説明の中で遅延とアプリケーションの関係、さらにそれがシステム設計に与える影響についてお話をしましたが、ではたとえばデータセンター内で2台のサーバを光ファイバで接続した場合の遅延が最も発生するはどこでしょうか？
「アプリケーション → ゲストOS → ハイパーバイザー → NIC → 光ファイバ → NIC …」とデータが経由していく中で、実際にはNICや光ファイバを経由する遅延はほとんど無視できる値となる一方、アプリケーションからNICまでの遅延が数msにもなります。つまり遅延を小さくしたいと思ったら、NICから出る前のソフトウェアによる遅延を小さくする必要があります。
そこで出てくるワンダフルな技術が「Single Root I/O Virtualization（SR-IOV）」です。デバイスやハイパーバイザーによるサポートが必要ですが、SR-IOVによってゲストOSは直接NICにアクセスできるようになり遅延の低減が見込めます。AWSではAmazon EC2にて「拡張ネットワーキング」という名前で2013年からC4、R3、I2、M4などの特定のインスタンスタイプでサポートされています。
さらに2016年6月29日からはElastic Network Adapter（ENA）と呼ばれる高性能パフォーマンスネットワークインターフェイスもお使いいただけるようになりました。ENAでは低レイテンシーで安定したパフォーマンスを最大20Gbpsで使えます（2016年11月現在、P2、X1およびm4.16xlargeインスタンスでご利用になれます）。
ところで、拡張ネットワーキングによる遅延値の低減は以下の通り簡単に試していただけます。
sriovNetSupport-enabled$ ping -c10 172.31.40.216 PING 172.31.40.216 (172.31.40.216) 56(84) bytes of data. 64 bytes from 172.31.40.216: icmp_seq=1 ttl=255 time=2.05 ms 64 bytes from 172.31.40.216: icmp_seq=2 ttl=255 time=2.02 ms 64 bytes from 172.31.40.216: icmp_seq=3 ttl=255 time=2.01 ms 64 bytes from 172.31.40.216: icmp_seq=4 ttl=255 time=2.03 ms 64 bytes from 172.31.40.216: icmp_seq=5 ttl=255 time=2.01 ms 64 bytes from 172.31.40.216: icmp_seq=6 ttl=255 time=2.00 ms 64 bytes from 172.31.40.216: icmp_seq=7 ttl=255 time=2.00 ms 64 bytes from 172.31.40.216: icmp_seq=8 ttl=255 time=2.00 ms 64 bytes from 172.31.40.216: icmp_seq=9 ttl=255 time=2.02 ms 64 bytes from 172.31.40.216: icmp_seq=10 ttl=255 time=1.99 ms --- 172.31.40.216 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9010ms rtt min/avg/max/mdev = 1.995/2.016/2.059/0.059 ms sriovNetSupport-enabled$ sriovNetSupport-disabled$ ping -c10 172.31.25.221 PING 172.31.25.221 (172.31.25.221) 56(84) bytes of data. 64 bytes from 172.31.25.221: icmp_seq=1 ttl=255 time=2.17 ms 64 bytes from 172.31.25.221: icmp_seq=2 ttl=255 time=2.14 ms 64 bytes from 172.31.25.221: icmp_seq=3 ttl=255 time=2.13 ms 64 bytes from 172.31.25.221: icmp_seq=4 ttl=255 time=2.13 ms 64 bytes from 172.31.25.221: icmp_seq=5 ttl=255 time=2.14 ms 64 bytes from 172.31.25.221: icmp_seq=6 ttl=255 time=2.16 ms 64 bytes from 172.31.25.221: icmp_seq=7 ttl=255 time=2.12 ms 64 bytes from 172.31.25.221: icmp_seq=8 ttl=255 time=2.11 ms 64 bytes from 172.31.25.221: icmp_seq=9 ttl=255 time=2.18 ms 64 bytes from 172.31.25.221: icmp_seq=10 ttl=255 time=2.11 ms --- 172.31.25.221 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9011ms rtt min/avg/max/mdev = 2.110/2.142/2.188/0.052 ms sriovNetSupport-disabled$
以上の実行結果はいずれも異なるアベイラビリティーゾーンにあるインスタンス間でのpingの結果ですが、上は拡張ネットワーキングが有効なc3.largeインスタンス同士、下は拡張ネットワーキングが無効なc3.largeインスタンス同士のpingの結果となります。(いずれも Amazon Linux AMI 2016.03 を使ってます)
同じインスタンス間、同じアベイラビリティーゾーン間のpingの結果ですが、拡張ネットワーキングが無効なインスタンス間の方が遅延が0.1ms強長くなっていることを確認していただけると思います。
ちなみにAmazon Linux AMI 2016.03では既定で拡張ネットワーキングが有効になっているため、一度インスタンスからスナップショットをとり、スナップショットから再度AMIを作ることで拡張ネットワーキング属性（sriovNetSupport）を無効にして試しました。
中締め
ここまででご紹介したのは「AWSのネットワーク」の物理的な側面でした。リージョンのグローバルフットプリントから構成、アベイラビリティーゾーンの構成、そしてサーバ・NICの構成まで、どのような考えにもとづき、どのように作られているのか、おおよそのイメージをもっていただけたかと思います。
しかし、ここにはまだAmazon EC2インスタンスは出てきません。
ラック内の各物理サーバがデータセンター内、データセンター間、リージョン間、そしてインターネットとどのように通信をしているのかについては少し分かっていただけたかと思いますが、ではEC2インスタンス同士はどのように通信をしているのでしょうか。新しく起動したインスタンスはどうやって他のインスタンスと通信をするのでしょうか？ そもそも他のインスタンスをどうやって見つければいいのでしょうか？
それについては、次回の「AWSのネットワークの論理的な側面」にてお話しします。
なお、アマゾン ウェブ サービス ジャパン株式会社ではクラウドサポートエンジニアを絶賛募集中です。 誰よりもAWSの仕組みを深く知り、最先端の技術に触れられる刺激的な仕事です（本稿よりももっと突っ込んだところを知ることができますよ！）。
興味を持ってくださった方はこちらからオープンハウス参加の登録をお願いいたします。
