平均使用率が低いのに Amazon EC2 インスタンスがネットワーク制限を超えているのはなぜですか?

所要時間2分

Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの平均使用率は低いですが、インスタンスがまだネットワークの制限を超えています。

簡単な説明

Elastic Network Adapter (ENA) を介して、拡張ネットワーキングをサポートするインスタンスのネットワークパフォーマンスメトリクスをリアルタイムでクエリできます。これらのメトリクスは、最後のデバイスリセット以降、各ネットワークインターフェイスでキューに入れられた、またはドロップされたパケット数の累積値を示します。

ENA メトリクスの一部を以下に示します。

**bw_in_allowance_exceeded:**インバウンドの合計帯域幅がインスタンスの最大帯域幅を超えたためにキューに入れられた、またはドロップされたパケットの数。
**bw_out_allowance_exceeded:**アウトバウンドの合計帯域幅がインスタンスの最大帯域幅を超えたためにキューに入れられた、またはドロップされたパケットの数。
**pps_allowance_exceeded:**双方向の 1 秒あたりのパケット数 (PPS) がインスタンスの最大数を超えたためにキューに入れられた、またはドロップされたパケットの数。
**conntrack_allowance_exceeded:**インスタンスのネットワークトラフィックが追跡可能な最大接続数を超えたためにキューに入れられた、またはドロップされたパケットの数。

ネットワークパフォーマンスの仕様は、インスタンスタイプによって異なります。仕様を確認するには、現行世代のインスタンスを参照してください。場合によっては、Amazon CloudWatch に表示される平均帯域幅や PPS が低くても、キューイングやドロップが発生することがあります。たとえば、CloudWatch の NetworkIn、NetworkOut、NetworkPacketIn、または NetworkPacketsOut のメトリクスには、上限に達しているとは思えない金額が表示される場合があります。

解決方法

マイクロバーストは、前述の症状の最も一般的な原因です。マイクロバーストとは、需要が短期間急上昇した後、活動量が少ないか、まったくない期間が続くことです。これらのバーストは通常、数秒、ミリ秒、さらにはマイクロ秒しか続きません。マイクロバーストの場合、前のセクションにリストした CloudWatch メトリクスはそれらを反映するほど詳細ではありません。

平均値の計算方法

前のセクションにリストした CloudWatch の EC2 メトリクスは 1 分ごとにサンプリングされます。これらのメトリクスは、その期間に転送されたバイトまたはパケットの合計をキャプチャします。その後、これらのサンプルは集約され、5 分間隔で CloudWatch に公開されます。期間内の各統計は、異なるサンプル値を返します：

合計は、すべてのサンプル値の合計です。
SampleCount は、集約されたサンプルの数 (この場合は 5) です。
最小は、バイト数/パケット数が最も少ないサンプル値です。
平均は、合計を SampleCount で割って計算された平均サンプル値です。
最大は、バイト数/パケット数が最も多いサンプル値です。

平均スループットまたは PPS は次の 2 つの方法で計算できます：

合計を期間 (たとえば 300 秒) で割ると、5 分間の単純平均が得られます。
アクティビティが最大の1 分間の平均値を 60 秒で割ります。

マイクロバーストが CloudWatch メトリクスにどのように反映されるか

マイクロバーストの例と、それが CloudWatch にどのように反映されるかを次に示します。

インスタンスのネットワーク帯域幅パフォーマンスは 10 Gbps (1.25 GB/s) です。
あるサンプル (60 秒) では、20 GB のアウトバウンドデータ転送で使用可能な帯域幅がすべて使い果たされ、bw\ _out\ _allowance\ _exceeded が増加します。転送は約 20 秒で完了し、それ以降はデータは送信されません。
残りの 4 サンプル (240 秒) の間、インスタンスはアイドル状態のままです。

この例では、5 分間の平均スループットは、マイクロバースト中のスループットよりもはるかに低くなっています。

SUM(NetworkOut) / PERIOD = ((20 GB * 1 sample) + (0 GB * 4 samples)) / 300 seconds = ~0.066 GB/s * 8 bits = ~0.533 Gbps

最も高いサンプルに基づいてスループットを計算しても、平均にはスループット量が反映されません。

MAXIMUM(NetworkOut) / 60 = 20 GB / 60 seconds = ~0.333 GB/s * 8 bits = ~2.667 Gbps

マイクロバーストの監視

スループットと PPS をより詳細に測定するには、オペレーティングシステム (OS) ツールを使用してネットワーク統計を監視します。シェーピング中やアクティビティの多い時期には、ネットワーク統計をより頻繁に監視してください。

OS ツールの例を以下に示します。

Linux

sar
nload
iftop
iptraf-ng

Windows

パフォーマンスモニター

CloudWatch エージェントは Linux と Windows の両方で使用して、これらの OS レベルのネットワークメトリクスをカスタムメトリクスとして CloudWatch に公開できます。これらのメトリクスは、1 秒という短い間隔で公開できます。高解像度の指標 (期間が 60 秒未満のもの) は料金が高くなることに注意してください。CloudWatch 料金の詳細については、Amazon CloudWatch 料金表を参照してください。

ENA が提供するネットワークパフォーマンスメトリクスを監視するのがベストプラクティスです。メトリクスを表示するには、ドライバーのバージョンが 2.2.10 (Linux) および 2.2.2 (Windows) 以上である必要があります。詳細については、以下を参照してください。

CloudWatch エージェントは ENA メトリクスを公開することもできます。Linux 用の ENA メトリクスを公開する手順については、「ネットワークパフォーマンスメトリクスを収集する」を参照してください。Windows では、ENA メトリクスはパフォーマンスモニターで確認できます。利用可能なメトリクスをパフォーマンスモニターで公開するように CloudWatch エージェントを設定できます。

マイクロバーストの防止

マイクロバーストを回避するには、最大スループットやパケットレートを超えないように、送信側でトラフィックのペースを調整する必要があります。そのため、マイクロバーストを回避するのが難しくなります。送信側でのトラフィックのペーシングには、通常、アプリケーションレベルの変更が必要です。この変更の実装方法によっては、送信側で OS によるトラフィックペーシングのサポートを有効にする必要がある場合があります。ただし、それが常に可能または実用的であるとは限りません。マイクロバーストは、短期間にパケットを送信する接続が多すぎるために発生することもあります。このような場合、個々の送信者のペースを調整しても役に立ちません。

ENA メトリクスを監視するのがベストプラクティスです。上限に頻繁に到達する場合や、トラフィックシェーピングがアプリケーションに影響を与えているという証拠がある場合は、次のことを行ってください。

**スケールアップ:**大きいインスタンスサイズに移動します。通常、インスタンスが大きいほど許容量が大きくなります。ネットワーク最適化インスタンス (C5n のような「n」の付いたインスタンス) は、ネットワーク最適化されていないインスタンスよりも許容量が大きくなります。
**スケールアウト:**トラフィックを複数のインスタンスに分散して、個々のインスタンスでのトラフィックと競合を減らします。

Linux ベースのオペレーティングシステムには、前述のオプションに加えて、上級ユーザー向けの緩和オプションがあります。これらのオプションは単独で実装することも、組み合わせて実装することもできます。テスト環境で緩和策をベンチマークして、ワークロードに悪影響を及ぼすことなくトラフィックシェーピングを軽減または排除できることを確認するのがベストプラクティスです。

**SO_MAX_PACING_RATE:**このソケットオプションをアプリケーションから setsockopt システムコールに渡して、最大ペーシングレート (1 秒あたりのバイト数) を指定できます。次に Linux カーネルは、そのソケットからのトラフィックが制限を超えないようにペーシングします。このオプションには以下が必要です。
アプリケーションコードレベルの変更。
カーネルからのサポート。
フェアキュー (FQ) キューイングディシプリンの使用、またはカーネルの TCP レイヤーでのペーシングサポート (TCP にのみ適用)。
**キューイングディシプリン (qdiscs): **qdisc はパケットスケジューリングとオプションシェーピングを行います。fq などの一部の qdisc は、個々のフローによるトラフィックのバーストをスムーズにするのに役立ちます。詳細については、トラフィックコントロール (TC) のマニュアルページを参照してください。
**シャロートランスミッション (Tx) キュー:**シナリオによっては、Tx キューが浅いと PPS シェーピングの軽減に役立ちます。これには次の 2 つの方法があります。
バイトキュー制限 (BQL):BQL は Tx キューの転送バイト数を動的に制限します。Linux カーネルに同梱されている ENA ドライバーバージョン (末尾が「K」のもの) では、BQL はデフォルトで有効になっています。GitHub の ENA ドライバーバージョン (末尾が「g」のもの) では、BQL は v2.6.1g から利用可能で、デフォルトではオフになっています。enable\ _bql ENA モジュールパラメータを使用して BQL をオンにすることができます。
**Tx キュー長の短縮:**Tx キューの長さをデフォルトの 1,024 パケットからより少ない量 (最小 256) に減らします。この長さは ethtool を使用して変更できます。