ゲバート氏、ティルパク氏によると、EMnifyのサービスを利用したIoT機器のトラフィックは「予測不能」だ。バックエンド障害や一斉ファームウェア更新などによって、数秒で急激なトラフィック増加が発生することがある。そのため、トラフィックを落とさないための過剰設計（オーバープロビジョニング）が不可欠であり、EC2インスタンス（注2）のコストと性能のバランスを正確に理解する必要がある。

　EMnifyのように、予測不能なトラフィック増加を前提としたIoTサービスをAWS上で運用する場合、重要になるのが、EC2インスタンスが「仕様上どこまでの通信性能を持っているのか」を正しく理解することだ。とりわけ、AWSが公開しているネットワーク性能の数値が、実運用でもそのまま得られるのかどうかは、コスト設計や過剰設計の判断に直結する。

　そこでゲバート氏とティルパク氏は、EC2のインスタンス仕様に立ち返り、「ドキュメントに15Gbpsと書かれているインスタンスは、本当に15Gbpsの通信性能を発揮できるのか？」について検証を始めた。

　ここで両氏は、AWSのネットワーク性能を理解する上で見落とされがちな、ある前提条件に注目する。両氏によると、AWSにはネットワーク帯域に以下2つの制限があるという。

• 帯域（Gbps）
• パケットレート（pps：Packets Per Second、1秒間に処理、転送できるパケットの数）

　ゲバート氏とティルパク氏によると、「MTU（注3）を9100バイト（注4）にしても、帯域は15Gbpsに制限される。さらに、1500バイトパケットで15Gbpsを出せるようにppsの上限が設定されている。しかしこれは公式には公開されていない」。

　「例えばこのインスタンスでは1秒間に約125万個までしかパケットを処理できない。パケットが500バイトの場合、実効帯域はおよそ5Gbpsになる」（ゲバート氏とティルパク氏）

　両氏によると、EMnifyのサービスを利用するIoT機器が1回の通信で送信するデータ量の平均サイズは150～200バイトだ。これは、一般的なネットワーク通信で想定されている1500バイト前後のパケットよりもはるかに小さいサイズだ。AWSの汎用（はんよう）インスタンスは、最大15Gbpsといったネットワーク帯域を仕様として示している。しかしこの数値は1500バイト程度のパケットを前提に設計されたものだ。そのため、IoTのように小さなパケットを大量に扱う場合、Gbpsよりも先に、ppsの制限にぶつかってしまう。

　さらにEMnifyのシステムは、受信したパケットをそのまま別の宛先に転送する構成になっている。これは1つのパケットを「受信」と「送信」で2回処理することを意味する。その結果、15Gbpsと仕様に書かれたEC2インスタンスであっても、実際に利用できる通信量は双方向で約750Mbps程度にまで下がる。

制限が存在する理由

　次にゲバート氏とティルパク氏は、次の台詞を紹介した。「制限は“隣人から守るため”にある。しかし同時に、隣人も私たちから守られている。だから、制限を理解しなければならない」。これは、AWSの設計思想を両氏の言葉で説明したものだ。つまり、クラウドの制限とは性能不足ではなく、マルチテナント環境でユーザー間の公平性と安定性を保つための前提条件だ。重要なのはその制限を正しく理解し、どこで制限に当たるのかを把握することだという。

　ところでAWSのネットワーク帯域は、ベースライン帯域（常に使える最低限の速度）と、

バースト帯域（条件が揃った場合に一時的に速く使える速度）で構成されている。ゲバート氏とティルパク氏によると、AWSのインスタンスに関する仕様には「Network performance：Up to 10 Gbps」といった情報が書かれている。しかしこの情報は、条件が整えば実現できる（ベストエフォート）性能であり、状況次第では使えない場合がある。

　AWSは2021年以降、EC2インスタンスのネットワーク制限に達した際の情報を記録するカウンタ（allowance exceeded）を提供している。これらはAWSの「Amazon CloudWatch」ではなく、仮想ネットワークインターフェース（NIC）であるENA（Elastic Network Adapter）のドライバを使って取得する必要がある。そこで重要になるのが、監視ツールの設定やドライバのバージョン管理だ。また、短時間のマイクロバーストは、1分単位の監視では見逃されることがあり、平均帯域が低く見えても制限カウンタが増加するケースがあるとゲバート氏とティルパク氏は説明する。

　両氏は、5分ごとに9MBのファイルを「Amazon Simple Storage Service」（Amazon S3）へアップロードしていたケースを例として紹介する。平均帯域は非常に低いにもかかわらず、26ミリ秒で一気にデータを転送した結果、瞬間的に数Gbps相当の通信が発生し、制限に引っかかった。ここから、AWSの制限は「1秒単位」よりもはるかに細かい粒度で適用されていることが分かると両氏は説明する。

　さらにゲバート氏とティルパク氏は、パケットフラグメンテーション（送信しようとしたパケットが経路上のMTUを超えたときに、送信元や途中の装置がパケットを分割すること）によるネットワーク性能の低下についても触れている。同氏らによると、VPN（仮想プライベートネットワーク）やトンネリングなどを使うと、通信データに追加のヘッダが付くため、送信されるパケットのサイズが大きくなる場合がある。その結果、MTUを超え、パケットが途中で分割されることがある。EC2は通常、通信処理の多くを「AWS Nitro System」（注5）のNitroカードと呼ばれるハードウェアコンポーネントが処理を担い、安定したネットワーク性能を実現する。しかし、パケットフラグメンテーションが発生した瞬間、Nitroカードでの処理からCPUでの処理に切り替わる。このCPU処理は性能に制限があるという。特に送信方向では、インスタンスのサイズや種類に関係なく、1秒あたり約1024ppsまでしか処理できないという限度がある。これは、同氏らがAWSのサポートへ問い合わせたことで確認できた情報だ。そのため、パケットフラグメンテーションが発生すると、回線帯域やインスタンス性能に余裕があっても、ネットワーク性能が急激に低下するという問題が起こり得る。

　この問題を回避するためには、MTUの設定を適切に実施することが基本となる。さらに、あらかじめMTUを小さく設定し、トンネルの内側で分割が起きるようにすることで、AWSのネットワーク側でパケットフラグメンテーションの発生を防ぐことができる。

　合わせて、「ICMP」（注6）の「Fragmentation Needed」メッセージ（注7）を正しく返せるようにすることも重要だ。これにより、送信元は経路上のMTUを検知し、パケットサイズを自動的に調整できるようになる。ICMPを遮断していると、この仕組みが機能せず意図しないパケットフラグメンテーションが発生しやすくなる。

　「TCP」（Transmission Control Protocol）（注8）を使った通信の場合には、「TCP MSSクランプ」を使う方法も有効だ。これは、TCPセグメントに含めるデータの最大サイズ（MSS）を強制的に小さく制限する仕組みで、VPNなどのトンネル環境で使われる。TCPの段階で送信サイズを抑えることで、経路上でIPレベルのパケットフラグメンテーションが発生するのを防げる。

　構成によっては、EC2インスタンス側ではなく、「AWS Transit Gateway」（注9）側でパケットフラグメンテーションを発生させることで、インスタンスのCPU負荷や性能制限の影響を減らせる場合もある。

　加えて、最近のENAドライバは、「fragment bypass」と呼ばれる機能を備えている。これにより、分割したパケットの処理を一部改善できるケースもある。ただし、この機能はCPUリソースとの競合を引き起こす可能性があるため、利用する場合は事前の検証が欠かせない。

　ゲバート氏とティルパク氏は最後に、「クラウドには制限がある。それは悪いものではなく、理解すべき前提条件だ」とまとめている。AWSのドキュメントや監視機能は年々改善されている。しかし、全ての情報が明示されている訳ではない。重要なのは、「制限の存在を前提にアーキテクチャを設計し、全パケットを完全に処理しようとせず、現実的なアプローチを取る姿勢を持つことだ」と締めくくった。