セルフマネージド ElastiCache クラスターで「Network allowance exceeded」というメトリクスが表示される理由を知りたいです。
Amazon ElastiCache 環境で「Network allowance exceeded」というメトリクスが表示されます。
簡単な説明
アプリケーションのワークロードが基盤 ElastiCache ノードのネットワーク機能を超えると、トラフィックシェーピングが発生する可能性があります。トラフィックシェーピングを追跡するには、次のメトリクスを使用します。
- NetworkBandwidthInAllowanceExceeded および NetworkBandwidthOutAllowanceExceeded
- NetworkPacketsPerSecondAllowanceExceeded
- NetworkConntrackAllowanceExceeded
解決策
NetworkBandwidthInAllowanceExceeded および NetworkBandwidthOutAllowanceExceeded
メトリクス NetworkBandwidthInAllowanceExceeded および NetworkBandwidthOutAllowanceExceeded は、スループットが合計帯域幅制限を超えたときに ElastiCache がシェーピングするネットワークパケットの数を追跡します。
NetworkBandwidthInAllowanceExceeded および NetworkBandwidthOutAllowanceExceeded をレビューする際は、Amazon CloudWatch の NetworkBytesIn メトリクスおよび NetworkBytesOut メトリクスもレビューする必要があります。CloudWatch の帯域幅使用率メトリクスである NetworkBytesIn および NetworkBytesOut がノードレベルの制限を下回っている場合、ネットワークパフォーマンスのメトリクスは、ElastiCache が許容値を超えたことを示す可能性があります。詳細については、「インスタンスの帯域幅を監視する」を参照してください。
注: 平均帯域幅が制限内であっても、小規模なトラフィックのバーストがトラフィックシェーピングを引き起こす可能性があります。これらの許容帯域幅に関するメトリクスが時折急増しても、アプリケーション側への影響がない場合は追加のアクションは必要ありません。Valkey と Redis OSS は TCP を使用するため、TCP はドロップされたパケットを再送信します。
これらの許容帯域幅に関するメトリクスが常に高く、アプリケーションで遅延の問題が発生している場合は、その遅延が発生したタイムスタンプを確認します。エラーのタイムスタンプがメトリクスが急増した時間と一致する場合は、クラスターをスケールアップしてください。詳細については、「独自設計クラスターのスケーリング」を参照してください。
さらに、クラスターのキャッシュノードタイプを確認します。アプリケーションのワークロードにより、ベースラインの帯域幅を超えてネットワーク使用量が絶えず急増している場合は、トラフィックシェーピングが行われる可能性があります。詳細については、「利用可能なインスタンス帯域幅」を参照してください。
注: ElastiCache がプライマリノードに 1 バイト書き込むごとに、ElastiCache は同じ情報を他のすべてのレプリカにレプリケートします。クラスターがレプリケーションのバックログを処理しようとする際、ノードタイプが小さく、レプリカが複数あり、書き込みリクエストが集中するクラスターでは問題が発生する可能性があります。このバックログにより、プライマリノードで NetworkBandwidthoutAllowanceExceeded の値が高くなる可能性があります。
アプリケーション側でメトリクスが急増した原因を判断するには、複数のキーを操作するコマンドを特定します。たとえば、次の例が含まれます。
- MGET
- MSET
- HGETALL
大容量 JSON オブジェクトやハッシュ値など、複数の大容量キーを扱う場合、使用しているノードタイプの帯域幅制限を超える可能性があります。その場合、ElastiCache は現在の負荷に基づいて超過トラフィックをドロップするか、キューに追加します。
NetworkPacketsPerSecondAllowanceExceeded
このメトリクスが 0 以外の値の場合、基盤キャッシュノードでのネットワーク使用量が 1 秒あたりのパケット数 (PPS) 制限を超えています。この制限は、使用するノードタイプによって異なります。ElastiCache は、ノード制限を超える超過パケットをドロップするか、キューに入れます。
小さなリクエストの 1 秒あたりのクエリ数 (QPS) が多いアプリケーションでは、ノードが PPS 制限を超える可能性があります。コマンドの実行レートを判断するには、各コマンドデータ型に関する CloudWatch メトリクスを使用します。詳細については、「Valkey および Redis OSS のメトリクス」を参照してください。
クラスターを一時的に大容量ノードタイプにスケールアップすると、この問題を解決できます。大量の読み取りを行う操作では、クラスターまたはシャードにリードレプリカを追加すると負荷を分散できます。クラスターモード対応 (CME) クラスターでは、操作が大量の書き込みを行う場合、シャードを追加してクラスターをスケールアウトします。
注: クラスターモード無効 (CMD) クラスターでは、書き込み操作をスケーリングするには、クラスターをより大容量のノードに移動する必要があります。
NetworkConntrackAllowanceExceeded
このメトリクスが 0 以外の値の場合、ElastiCache はすべてのノードのセキュリティグループで追跡される接続の最大数を超えています。接続制限に達すると、ElastiCache が既存の接続を閉じるまで、新しい接続は失敗します。詳細については、「Amazon Elastic Compute Cloud (Amazon EC2) セキュリティグループの接続を追跡する」を参照してください。
ワークロードによって多数のネットワーク接続が作成されている場合、接続を適切に閉じないと、サーバー側では接続が開いたままになります。これらの接続はアイドル状態に留まるため、conntrack の枯渇につながります。その場合、ElastiCache が既存の接続を閉じるまで、ElastiCache は新しい接続を受け入れられません。
ElastiCache におけるこの問題を解決するには、timeout パラメータを使用してアイドル接続のタイムアウトを確認し、変更します。ElastiCache サーバーのパラメータを設定し、アイドル期間の経過後に接続を閉じるようにします。
アプリケーション側でこの問題を解決するには、接続プールの設定を使用して既存の接続を再利用し、NewConnections のレートを低減します。詳細については、「ベストプラクティス: Redis クライアントおよび Amazon ElastiCache for Redis」を参照してください。
注: サーバー側の timeout パラメータおよび、クライアント側の [接続プール] 設定の両方が接続の確立を管理します。アプリケーションによる負荷テストを行う必要があります。アプリケーションの負荷テストを行い、タイムアウト設定と接続プール設定の両方に最適な構成を決定します。
