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

最終更新日: 2022 年 5 月 26 日

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

簡単な説明

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

  • bw_in_allowance_exceeded: インバウンドの総帯域幅がインスタンスの最大帯域幅を超えたためにキューに入れられた、またはドロップされたパケットの数。
  • bw_out_allowance_exceeded: アウトバウンドの総帯域幅がインスタンスの最大帯域幅を超えたためにキューに入れられた、またはドロップされたパケットの数。
  • pps_allowance_exceeded: 双方向のパケット毎秒 (PPS) がインスタンスの最大値を超えたためにキューに入れられた、またはドロップされたパケットの数。

場合によっては、Amazon CloudWatch で見られるような平均帯域幅または PPS が低くても、キューイングまたはドロップが発生することがあります。例えば、CloudWatch の NetworkInNetworkOutNetworkPacketsIn、または NetworkPacketsOut メトリクスでは、表示される量は、制限への到達を示唆しない場合があります。

解決方法

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

平均の計算方法

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

  • Minimum は、バイト/パケット数が最も少ないサンプル値です。
  • Maximum は、バイト/パケット数が最も多いサンプル値です。
  • Sum はすべてのサンプル値の合計です。
  • SampleCount は、集計されたサンプルの数です (この場合は 5)。
  • Average は、Sum を SampleCount で割ることによって計算される平均サンプル値です。

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

  • Sum 期間 (例: 300 秒) で割ると、単純な 5 分間の平均が得られます。
  • Maximum 60 秒で割ると、アクティビティが最も多い分間の平均を求めます。

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

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

  • インスタンスのネットワーク帯域幅パフォーマンスは 10 Gbps (1.25 GB/秒) です。
  • 特定のサンプル (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 seconds = 20 GB / 60 = ~0.333 GB/s * 8 bits = ~2.667 Gbps

マイクロバーストのモニタリング

スループットと PPS をより細かく測定するには、オペレーティングシステム (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) 以上である必要があります。詳細については、LinuxWindows の関連ページを確認してください。CloudWatch エージェントは ENA メトリクスを公開することもできます。

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

マイクロバーストを防ぐ

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

これらの理由により、前述のとおり、ENA メトリクスをモニタリングすることがベストプラクティスです。制限に頻繁に到達する場合、またはこれがアプリケーションに影響を与えているという証拠がある場合は、次の操作を行います。

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

Linux では、前述のオプションに加えて、上級ユーザー向けの潜在的な緩和オプションがあります。

  • SO_MAX_PACING_RATE: このソケットオプションは、最大ペーシングレート (バイト/秒) を指定するために、アプリケーションにより setsockopt へ受け渡されることがあります。その後、Linux カーネルはそのソケットからのトラフィックをペーシングして、制限を超えないようにします。このオプションには以下が必要です。
    アプリケーションレベルのコードの変更。
    カーネルからのサポート
    Fair Queue (FQ) キューイング規律の使用、または TCP 層でのペーシングに対するカーネルのサポート (TCP のみに適用)。
  • キューイング規律 (qdiscs): いくつかの qdiscs は、さまざまなレベルでトラフィックシェーピングをサポートします。詳細については、トラフィックコントロール (TC) マニュアルページを参照してください。
  • 浅い送信 (Tx) キュー: シナリオによっては、浅い Tx キューが PPS スロットリングを減らすのに役立ちます。これは、次の 2 つの方法で実現できます。
    バイトキュー制限 (BQL): BQL は Tx キューのインフライトバイト数を動的に制限します。Linux カーネルに同梱されている ENA ドライバーバージョン (「K」で終わるもの) では、BLQ はデフォルトでオンになっています。GitHub の ENA ドライバーバージョン (「g」で終わるもの) では、BQL は v2.6.1g から利用可能で、デフォルトではオフになっています。enable_bql ENA モジュールパラメーターを使用して BQL を有効にできます。
    Tx キュー長の短縮: Tx キューの長さをデフォルトの 1,024 パケットからより低い量 (最小 256) に減らします。この長さは ethtool を使って変更できます。