Amazon EC2 インスタンスの平均使用率が低いにもかかわらず、ネットワーク制限を超えている理由を教えてください。
Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの平均ネットワーク使用率が低いにもかかわらず、インスタンスの帯域幅または 1 秒あたりのパケット数 (PPS) クォータを超えています。
簡単な説明
Elastic Network Adaptor (ENA) のネットワークパフォーマンスメトリクスのうち、bw_in_allowance_exceeded、bw_out_allowance_exceeded、pps_allowance_exceeded は、平均使用率が低い場合も増加する可能性があります。この問題の最も一般的な原因はネットワークリソースに対する需要の急増です。この現象は、マイクロバーストと呼ばれます。マイクロバーストは通常、数秒かミリ秒 (場合によってはマイクロ秒) のみ継続します。Amazon CloudWatch のメトリクスは、そのようなマイクロバーストを反映するほど詳細ではありません。例えば、CloudWatch のインスタンスメトリクスである NetworkIn および NetworkOut を使用すると 1 秒あたりの平均スループットを計算できます。ただし、マイクロバーストが原因で、計算されたレートがインスタンスタイプで使用可能なインスタンスの帯域幅よりも低くなる場合があります。
小規模なインスタンスでも、「1 秒当たり 10 ギガビット (Gbps) まで」などの最大帯域幅が設定されている場合は、bw_in_allowance_exceeded および bw_out_allowance_exceeded メトリクスが増加する可能性があります。 小規模なインスタンスでは、ネットワーク I/O クレジットを使用して一定期間のみベースラインの帯域幅を超えてバーストします。クレジットがなくなると、トラフィックはベースライン帯域幅に合わせて調整され、メトリクスが増加します。インスタンスのバーストはベストエフォートベースで発生するため、インスタンスに使用可能な I/O クレジットがある場合にもメトリクスが増加する可能性があります。
最適ではないトラフィックパターンが原因で PPS レートが低下し、パケットのドロップが発生した場合は、pps_allowance_exceeded メトリクスも増加します。非対称ルーティング、古いドライバー、小規模のパケット、断片化、接続の追跡などが、ワークロードの PPS パフォーマンスに影響します。
解決策
平均の計算
CloudWatch は 60 秒ごとに Amazon EC2 メトリクスをサンプリングし、1 分間に転送された合計バイト数またはパケット数をキャプチャします。Amazon EC2 はサンプルを集約し、5 分間隔で CloudWatch に発行します。その期間の各統計情報には異なる値が表示されます。
詳細モニタリングを使用すると、CloudWatch は 1 分間隔の集約を行わずに NetworkIn および NetworkOut メトリクスを発行します。Sum、Minimum、Average、Maximum の値は同一になり、SampleCount の値は 1 になります。CloudWatch は常に、5 分間隔で NetworkPacketsIn および NetworkPacketsOut メトリクスを集計して発行します。
次の方法で、ある期間の平均スループットをバイト/秒 (Bps) または PPS 単位で計算します。
- 指定した期間の単純平均を求めるには、Sum を Period で除算するか、値のタイムスタンプ差 (DIFF_TIME) で除算します。
- アクティビティが最も多い 1 分間における平均を求めるには、Maximum を 60 秒で除算します。
Bps を Gbps に変換するには、計算結果を 1,000,000,000 バイトで除算してから 8 ビットを乗算します。
CloudWatch メトリクスでのマイクロバースト
次の例は、CloudWatch でマイクロバーストがどのように表示されるかを示しています。インスタンスのネットワーク帯域幅許容量は 10 Gbps で、基本的なモニタリングを使用しています。
60 秒のサンプルでは、約 24 GB のアウトバウンドデータ転送が、使用可能な帯域幅をすべて使用しています。データ転送により bw_out_allowance_exceeded 値が増加します。この転送は約 20 秒で完了し、平均速度は 9.6 Gbps です。Amazon EC2 は他のデータを送信せず、240 秒間、残りの 4 つのサンプルではインスタンスはアイドル状態のままになります。
5 分間の平均スループット (Gbps 単位) は、マイクロバースト中のスループットよりもはるかに低くなっています。
計算式 AVERAGE_Gbps = SUM(NetworkOut) / PERIOD(NetworkOut) / 1,000,000,000 バイト * 8 ビット
SUM(NetworkOut) = (約 24 GB * 1 サンプル) + (~0 GB * 4 サンプル) = 約 24 GB
PERIOD(NetworkOut) = 300 秒 (5 分)
AVERAGE_Gbps = 約 24 / 300 / 1,000,000,000 * 8 = 約 0.64 Gbps
最も高いサンプルに基づいて平均スループットを計算しても、その数値にはマイクロバースト中のスループットが反映されません。
計算式 AVERAGE_Gbps = MAXIMUM(NetworkOut) / 60 秒 / 1,000,000,000 バイト / 8 ビット
MAXIMUM(NetworkOut) = 約 24 GB
AVERAGE_Gbps = 約 24 GB / 60 / 1,000,000,000 * 8 = 約 3.2 Gbps
高解像度のデータが利用できる場合は、より正確な平均値を取得できます。オペレーティングシステム (OS) のネットワーク使用状況メトリクスを 1 秒間隔で収集すると、平均スループットは一時的に、約 9.6 Gbps に達します。
マイクロバーストを監視する
Linux と Windows で CloudWatch エージェントを使用すると、OS レベルのネットワークメトリクスを最大 1 秒間隔で CloudWatch に発行できます。エージェントは、ENA のネットワークパフォーマンスに関するメトリクスも発行できます。
注: メトリクスの解像度が高いほど、価格が増加します。
OS ツールを使用しても、最大 1 秒間隔でネットワーク統計を監視できます。Windows インスタンスでは、Performance Monitor を使用します。Linux では、sar、nload、iftop、iptraf-ng、netqtop のいずれかを使用します。
マイクロバーストを明確に識別するには、OS のパケットキャプチャを実行してから、Wireshark を使用して 1 ミリ秒間隔で I/O グラフをプロットします。詳細については、Wireshark のウェブサイトで「Download Wireshark」(Wireshark のダウンロード) および「8.8.The "I/O Graphs" window」(8.8. "I/O グラフ" ウィンドウ) を参照してください。
この方法には次の制限が適用されます。
- ネットワーク許容量は、おおよそマイクロ秒単位で比例します。例えば、帯域幅パフォーマンスが 10 Gbps のインスタンスタイプでは、1 ミリ秒で約 10 メガビット (Mb) を送受信できます。
- パケットキャプチャにより、システム負荷が増加し、全体的なスループットと PPS レートが低下する可能性があります。
- バッファに空きがないことが原因でパケットがドロップされた結果、パケットキャプチャにすべてのパケットが含まれない場合があります。
- タイムスタンプは、ネットワークが送信した時期と ENA がパケットを受信した時期を正確には反映しません。
- Amazon EC2 はクォータを超えるトラフィックをインスタンスに到達する前にシェーピングするため、I/O グラフでは、インバウンドトラフィックのアクティビティが少なく表示される場合があります。
パケットのキューとドロップ
ネットワークがパケットをキューに入れる際、その結果生じる遅延はミリ秒単位で測定されます。TCP 接続がスループットをスケーリングし、EC2 インスタンスタイプのクォータを超える場合があります。その結果、ボトルネック帯域幅とラウンドトリップ (BBR) や、遅延をシグナルとして使用する他の輻輳制御アルゴリズムを使用する場合も、ある程度のパケットキューが想定されます。ネットワークがパケットをドロップすると、TCP は失われたセグメントを自動的に再送信します。パケットのキューおよびドロップにより、遅延が長くなり、スループットが低下する可能性があります。ただし、リカバリアクションは表示されません。通常、アプリケーションのタイムアウト時間が短い場合や、ネットワークがパケットを相当量ドロップした結果接続が強制的に閉じられた場合のエラーのみが表示されます。
ENA のネットワークパフォーマンスメトリクスでは、キューに入れられたパケットとドロップされたパケットは区別されません。Linux で接続レベルの TCP 遅延を測定するには、ss コマンドまたは tcprtt コマンドを使用します。TCP 再送信を測定するには、接続レベルの統計情報には ss コマンドまたは tcpretrans コマンドを使用し、システム全体の統計情報には nstat コマンドを使用します。BPF Compiler Collection (BCC) に含まれるツールである tcprtt と tcpretrans をダウンロードする方法については、GitHub のウェブサイトで bcc を参照してください。パケットキャプチャを使用しても、遅延と再送信を測定できます。
注: インスタンスクォータを超えたことが原因でネットワークがドロップしたパケットは、ip または ifconfig のドロップカウンターに表示されません。
マイクロバーストを防ぐ
まず、ENA のネットワークパフォーマンスメトリクスをアプリケーションの主要業績評価指標 (KPI) と照合し、パケットのキューやドロップによる影響を判断します。
KPI が必要なしきい値を下回っているか、アプリケーションログでエラーが発生した場合は、次の手順を実行してパケットキューとドロップを減らします。
- スケールアップ インスタンスサイズを、ネットワーク許容量の大きいインスタンスに増やします。C7gn など、「n」の付いたインスタンスタイプはネットワーク許容量が大きくなります。
- スケールアウト トラフィックを複数のインスタンスに分散し、個々のインスタンスでのトラフィックと競合を減らします。
Linux ベースの運用では、次の戦略を実装してもマイクロバーストを回避できます。テスト環境で戦略をテストし、ワークロードに悪影響を及ぼすことなくトラフィックのシェーピングが削減されることを確認することをおすすめします。
注: 次の戦略は、アウトバウンドトラフィックのみを対象としています。
SO_MAX_PACING_RATE
SO_MAX_PACING_RATE ソケットオプションを使用して、接続の最大ペーシングレートを Bps 単位で指定します。すると、Linux カーネルは、ソケットからのパケット間に遅延を導入し、スループットが指定したクォータを超えないようにします。
この手法を実施するには、次の変更を実装する必要があります。
- アプリケーションコードの変更。
- カーネルによるサポート。詳細については、GitHub のウェブサイトで「net: introduce SO_MAX_PACING_RATE」(net: SO_MAX_PACING_RATE を導入する) を参照してください。
- 公平キュー (FQ) キューイング規則、またはカーネルによる TCP レイヤーでのペーシングのサポート (TCP のみ)。
詳細については、man7 のウェブサイトで「getsockopt(2) - Linux manual page」(getsockopt(2) - Linux マニュアルページ) および「tc-fq(8) - Linux manual page」(tc-fq(8) - Linux マニュアルページ) を参照してください。GitHub のウェブサイトで「tcp: internal implementation for pacing」(tcp: ペーシング用の内部実装) も参照してください。
qdiscs (キュー規則)
Linux では、キュー規則 (qdisc) pfifo_fast のデフォルト設定を各 ENA キューに使用してパケットをスケジュールします。qdisc に fq を使用すると、個々のフローからのトラフィックバーストを減らし、スループットを調整できます。または、fq_codel と cake を使用してアクティブキュー管理 (AQM) 機能を実現すると、ネットワークの混雑を緩和し、遅延を改善できます。詳細については、man7 のウェブサイトで「tc(8) - Linux manual page」(tc(8) - Linux マニュアルページ) を参照してください。
TCP で、クライアントとサーバー側の明示的輻輳通知 (ECN) を有効にします。次に ECN を、ECN を Congestion Experienced (CE) とマークできるキュー規則と組み合わせます。CE マークが付与されると、OS は接続のスループットを低下させることで、インスタンスクォータの超過による遅延とパケットロスを軽減します。このソリューションを使用するには、接続の平均ラウンドトリップタイム (RTT) に基づいて、キュー規則の CE しきい値を低く設定する必要があります。このソリューションは、接続間の平均 RTT があまり変化しない場合にのみ使用することをおすすめします。例えば、インスタンスは 1 つのアベイラビリティーゾーンのトラフィックのみを管理する場合は、
パフォーマンス上の問題が発生するため、インスタンスレベルで集約帯域幅シェーピングを設定することはおすすめしません。
Shallow Transmission (Tx) キュー
Tx キューを使用すると、PPS のシェーピングを削減できます。バイトキュー制限 (BQL) により、Tx キューの転送バイト数が動的に制限されます。BQL を有効化するには、GRUB でカーネルコマンドラインに ena.enable_bql=1 を追加します。
注: このソリューションを使用するには、ENA ドライバーバージョン 2.6.1g 以降が必要です。BQL は、K で終わる Linux カーネルバージョンの ENA ドライバーでは有効化済みです。
詳細については、LWN.net のウェブサイトで「bql: Byte Queue Limits」(bql: バイトキュー制限) を参照してください。
ENA Express を使用する場合は、帯域幅を最大化するには BQL を無効化する必要があります。
ethtool を使用しても、Tx キューの長さをデフォルトの 1,024 パケットから減らすことができます。詳細については、man7 のウェブサイトで「ethtool(8) - Linux manual page」(ethtool(8) - Linux マニュアルページ) を参照してください。
