永続的な接続の問題

インバウンドルール:

ルール番号: 好ましくは拒否ルールよりも低い。

タイプ: カスタムTCPルール

プロトコル: TCP

[Port Range]: 1024～65535

ソース: 0.0.0.0/0 (または ElastiCache クラスターサブネットの個別ルールを作成する）

[許可/拒否]: 許可

アウトバウンドルール:

ルール番号: 好ましくは拒否ルールよりも低い。

タイプ: カスタムTCPルール

プロトコル: TCP

[Port Range]: 6379

ソース: 0.0.0.0/0 (または ElastiCache クラスターサブネット。 特定の を使用すると、クラスターのフェイルオーバーやスケーリング時に問題が発生するIPs可能性があることに注意してください）

[許可/拒否]: 許可

インバウンドルール:

ルール番号: 好ましくは拒否ルールよりも低い。

タイプ: カスタムTCPルール

プロトコル: TCP

[Port Range]: 6379

ソース: 0.0.0.0/0 (または ElastiCache クラスターサブネットの個別ルールを作成する）

[許可/拒否]: 許可

アウトバウンドルール:

ルール番号: 好ましくは拒否ルールよりも低い。

タイプ: カスタムTCPルール

プロトコル: TCP

[Port Range]: 1024～65535

ソース: 0.0.0.0/0 (または ElastiCache クラスターサブネット。 特定の を使用すると、クラスターのフェイルオーバーやスケーリング時に問題が発生するIPs可能性があることに注意してください）

[許可/拒否]: 許可

CPU 使用状況: Valkey と Redis OSSはマルチスレッドアプリケーションです。ただし、各コマンドの実行は単一の (メイン) スレッドで行われます。このため、 はメトリクスCPUUtilizationと ElastiCache を提供しますEngineCPUUtilization。 EngineCPUUtilizationは、Valkey または Redis OSSプロセス専用のCPU使用率と、すべての のCPUUtilization使用状況を提供しますvCPUs。複数の vCPU を持つノードは通常、 CPUUtilizationと の値が異なるためEngineCPUUtilization、2 つ目は通常高くなります。高 は、リクエスト数の増加や、完了までにかなりCPUの時間がかかる複雑な操作が原因EngineCPUUtilizationである可能性があります。両方を特定するには、以下を使用します。

アプリケーションは ElastiCache クラスターモードをサポートしておらず、クラスターモードが有効になってい ElastiCache ます。

アプリケーションは TLS/ をサポートしておらずSSL、転送中の暗号化が有効になってい ElastiCache ます。

アプリケーションは TLS/SSL をサポートしていますが、適切な設定フラグや信頼できる認証機関はありません。

最大接続数: 同時接続にはハード制限があります。各 ElastiCache ノードでは、すべてのクライアント間で最大 65,000 の同時接続が可能です。この制限は、 のCurrConnectionsメトリクスを通じてモニタリングできます CloudWatch。ただし、クライアントにはアウトバウンド接続にも制限があります。Linux では、次のコマンドを使用して、許可されているエフェメラルポート範囲を確認してください。

# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999

前の例では、28231 接続は同じ送信元から同じ送信先 IP (ElastiCache ノード) とポートに許可されます。次のコマンドは、特定の ElastiCache ノード (IP 1.2.3.4) にいくつの接続が存在するかを示します。

ss --numeric --tcp state connected "dst 1.2.3.4 and dport == 6379" | grep -vE '^State' | wc -l

この数値が大きすぎると、接続リクエストを処理しようとしてシステムが過負荷になることがあります。接続をより適切に処理するために、接続プーリングや永続的な接続などの技術の実装を検討することをお勧めします。いつでも可能な限り、接続プールを設定して、接続の最大数を数百に制限します。また、タイムアウトやその他の接続例外を処理するためのバックオフロジックは、問題が発生した場合に接続チャーンを避けるようにすることをお勧めします。

ネットワークトラフィックの制限: CloudWatch Redis の次のメトリクスOSSを確認して、 ElastiCache ノードでヒットする可能性のあるネットワーク制限を特定します。

上記のメトリクスは、ノードがネットワーク制限にヒットしていることを確認するための理想的な方法です。ただし、制限はネットワークメトリクスのプラトーによっても特定できます。

プラトーが長期間観察されると、レプリケーションの遅延、キャッシュに使用されるバイトの増加、空きメモリのドロップ、スワップの増加、CPU使用量の増加が続く可能性があります。Amazon EC2インスタンスには、ENAドライバーメトリクス を通じて追跡できるネットワーク制限もあります。ネットワークサポートが強化され、ENAドライバーが 2.2.10 以降の Linux インスタンスは、 コマンドを使用して制限カウンターを確認できます。

# ethtool -S eth0 | grep "allowance_exceeded"

Redis OSS SlowLogs: ElastiCache デフォルト設定では、完了までに 10 ミリ秒以上かかった最後の 128 コマンドが保持されます。スローコマンドの履歴は、エンジンランタイム中は保持され、障害や再起動時に失われます。リストが 128 エントリに達すると、古いイベントは削除され、新しいイベントのためのスペースが開きます。スローイベントのリストとスローとみなされる実行時間のサイズは、[カスタムパラメータグループ] のパラメータ slowlog-max-len および slowlog-log-slower-than を介して変更できます。スローログのリストは、エンジンで SLOWLOG GET 128 を実行して取得でき、ここで 128 は最後に報告された 128 のスローコマンドになります。各エントリには以下のフィールドがあります。

1) 1) (integer) 1 -----------> Sequential ID
   2) (integer) 1609010767 --> Timestamp (Unix epoch time)of the Event
   3) (integer) 4823378 -----> Time in microseconds to complete the command.
   4) 1) "keys" -------------> Command
      2) "*" ----------------> Arguments 
   5) "1.2.3.4:57004"-> Source

上記のイベントは 12 月 26 日 19:26:07 に発生しUTC、完了までに 4.8 秒 (4.823 ミリ秒) かかり、クライアント 1.2.3.4 からリクエストされたKEYSコマンドによって引き起こされました。

Linux では、タイムスタンプはコマンド date で変換できます。

$ date --date='@1609010767'
Sat Dec 26 19:26:07 UTC 2020

Python の場合:

>>> from datetime import datetime
>>> datetime.fromtimestamp(1609010767)
datetime.datetime(2020, 12, 26, 19, 26, 7)

または を使用する Windows の場合 PowerShell：

PS D:\Users\user> [datetimeoffset]::FromUnixTimeSeconds('1609010767')
DateTime      : 12/26/2020 7:26:07 PM
UtcDateTime  
                : 12/26/2020 7:26:07 PM
LocalDateTime : 12/26/2020 2:26:07 PM
Date          : 12/26/2020 12:00:00 AM
Day           : 26
DayOfWeek    
                : Saturday
DayOfYear     : 361
Hour          : 19
Millisecond   : 0
Minute        : 26
Month        
                : 12
Offset        : 00:00:00Ticks         : 637446075670000000
UtcTicks     
                : 637446075670000000
TimeOfDay     : 19:26:07
Year          : 2020

短時間 (同じ分以下) での多くのスローコマンドは、懸念の理由になります。コマンドの性質と、それらを最適化する方法を確認してください (前の例を参照)。O(1) 時間の複雑さを持つコマンドが頻繁に報告される場合は、前述のCPU使用率が高い他の要因を確認してください。

レイテンシーメトリクス: ElastiCache (Redis OSS) は、さまざまなクラスのコマンドの平均レイテンシーをモニタリングするための CloudWatch メトリクスを提供します。データポイントは、カテゴリ内のコマンドの実行総数を期間内の合計実行時間で割って計算されます。レイテンシーメトリクスの結果は、複数のコマンドの集合であることを理解することが重要です。1 つのコマンドで、メトリクスに大きな影響を与えずに、タイムアウトのような予期しない結果が発生する可能性があります。このような場合、スローログイベントはより正確な情報源になります。次のリストには、使用可能なレイテンシーメトリクスと、それらに影響する各コマンドが含まれています。

Redis OSSランタイムコマンド：

より前のバックアップとレプリケーション: ElastiCache (Redis OSS) バージョンでは、フォークプロセス2.8.22を使用してバックアップを作成し、レプリカとの完全な同期を処理します。このメソッドは、書き込み集中的なユースケースのために多くのメモリオーバーヘッドが発生する可能性があります。

ElastiCache Redis OSS2.8.22 以降、 はフォークレスバックアップとレプリケーションメソッド AWS を導入しました。新しい方法は、障害を防ぐために書き込みを遅らせる場合があります。どちらの方法でも、CPU使用率が高い期間が発生し、応答時間が長くなり、その結果、実行中にクライアントがタイムアウトする可能性があります。バックアップウィンドウの間にクライアントの障害が発生したか、または SaveInProgress メトリクスが期間内で 1 であったかどうかを常に確認してください。クライアントの問題やバックアップ障害の可能性を最小限にするために、使用率の低い期間でバックアップウィンドウをスケジュールすることをお勧めします。

クライアントアプリケーションのバグにより、接続が忘れられ、アイドル状態で確立されたままになることがあります。これは「接続リーク」と呼ばれ、その結果は CurrConnections メトリクスで観測される確立された接続の数の着実な増加となります。この動作により、クライアントまたは ElastiCache 側で飽和が発生する可能性があります。クライアント側から即時修正ができない場合、一部の管理者は ElastiCache パラメータグループに「タイムアウト」値を設定します。タイムアウトは、アイドル接続が持続するために許容される時間 (秒単位) です。クライアントが期間中にリクエストを送信しない場合、Redis OSS エンジンは接続がタイムアウト値に達するとすぐに接続を終了します。タイムアウト値が小さいと、不要な切断が発生する場合があり、クライアントはそれらを適切に処理して再接続する必要があり、遅延が発生します。

キーの格納に使用されるメモリは、クライアントバッファと共有されます。大きなリクエストまたは応答があるスロークライアントは、バッファを処理するために多くの量のメモリを要求する場合があります。デフォルトの ElastiCache (Redis OSS) 設定では、通常のクライアント出力バッファのサイズは制限されません。maxmemory の制限にヒットした場合、エンジンはバッファの使用量を満たすために項目を削除しようとします。メモリが非常に低い状況では、 ElastiCache (Redis OSS) は、メモリを解放し、クラスターの状態を維持するために、大きなクライアント出力バッファを消費するクライアントを切断することを選択する場合があります。

カスタム設定を用いてクライアントバッファのサイズを制限することができ、制限をヒットしているクライアントは切断されます。ただし、クライアントは予期しない切断を処理できる必要があります。通常のクライアントのバッファサイズを処理するパラメータは次のとおりです。

通常のクライアントバッファに加えて、次のオプションは、レプリカノードと Pub/Sub (Publish/Subscribe) クライアントのバッファを制御します。

CPU:

ネットワーク

ネットワーク上: Tcpdumpおよび Wireshark (コマンドライン上のサメ) は、リクエストがネットワークを移動し、 ElastiCache エンジンをヒットしてリターンを得るのにかかった時間を把握するための便利なツールです。次の例では、次のコマンドで作成された 1 つのリクエストを強調表示します。

$ echo ping | nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com 6379
+PONG

上記のコマンドと並行して、tcpdump が実行中であり、次のように返されました。

$ sudo tcpdump -i any -nn port 6379 -tt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
1609428918.917869 IP 172.31.11.142.40966
    > 172.31.11.247.6379: Flags [S], seq 177032944, win 26883, options [mss 8961,sackOK,TS val 27819440 ecr 0,nop,wscale 7], length 0
1609428918.918071 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [S.], seq 53962565, ack 177032945, win
    28960, options [mss 1460,sackOK,TS val 3788576332 ecr 27819440,nop,wscale 7], length 0
1609428918.918091 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918122
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [P.], seq 1:6, ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 5: RESP "ping"
1609428918.918132 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [F.], seq 6, ack
    1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918240 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [.], ack 6, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918295
    IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [P.], seq 1:8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 7: RESP "PONG"
1609428918.918300 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 8, win
    211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
1609428918.918302 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [F.], seq 8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918307
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 9, win 211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

上記の出力から、TCP3 方向ハンドシェイクが 222 マイクロ秒 (918091 ～ 917869) で完了し、ping コマンドが送信され、173 マイクロ秒 (918295 ～ 918122) で返されたことを確認できます。

リクエストから接続を閉じるまで、438 マイクロ秒 (918307～917869) かかりました。これらの結果では、ネットワークとエンジンの応答時間が良好であることを確認し、調査は他のコンポーネントに焦点を当てることができます。

オペレーティングシステム上: Strace は、OS レベルでのタイムギャップを特定するのに役立ちます。実際のアプリケーションの分析では、より広範で特殊なアプリケーションプロファイラやデバッガを使用することをお勧めします。次の例は、基本オペレーティングシステムコンポーネントが予期したとおりに動作しているかどうかを示しています。そうでない場合、さらに調査が必要になることがあります。で同じ Redis OSS PING コマンドを使用するとstrace、次のようになります。

$ echo ping | strace -f -tttt -r -e trace=execve,socket,open,recvfrom,sendto nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com (http://example.xxxxxx.ng.0001.use1.cache.amazonaws.com/)
    6379
1609430221.697712 (+ 0.000000) execve("/usr/bin/nc", ["nc", "example.xxxxxx.ng.0001.use"..., "6379"], 0x7fffede7cc38 /* 22 vars */) = 0
1609430221.708955 (+ 0.011231) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709084
    (+ 0.000124) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709258 (+ 0.000173) open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709637 (+ 0.000378) open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709923
    (+ 0.000286) open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.711365 (+ 0.001443) open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
1609430221.713293 (+ 0.001928) socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
1609430221.717419
    (+ 0.004126) recvfrom(3, "\362|\201\200\0\1\0\2\0\0\0\0\rnotls20201224\6tihew"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 155
1609430221.717890 (+ 0.000469) recvfrom(3, "\204\207\201\200\0\1\0\1\0\0\0\0\rnotls20201224\6tihew"...,
    65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 139
1609430221.745659 (+ 0.027772) socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
1609430221.747548 (+ 0.001887) recvfrom(0, 0x7ffcf2f2ca50, 8192,
    0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK (Socket operation on non-socket)
1609430221.747858 (+ 0.000308) sendto(3, "ping\n", 5, 0, NULL, 0) = 5
1609430221.748048 (+ 0.000188) recvfrom(0, 0x7ffcf2f2ca50, 8192, 0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK
    (Socket operation on non-socket)
1609430221.748330 (+ 0.000282) recvfrom(3, "+PONG\r\n", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 7
+PONG
1609430221.748543 (+ 0.000213) recvfrom(3, "", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 0
1609430221.752110
    (+ 0.003569) +++ exited with 0 +++

上記の例では、コマンドは完了に 54 ミリ秒を若干超える時間がかかりました (752110 - 697712 = 54398 マイクロ秒)。

nc をインスタンス化し、名前解決 (697712 から 717890 まで) を行うには、約 20 ミリ秒というかなりの時間がかかりました。その後、TCPソケットの作成に 2 ミリ秒 (745659 から 747858)、リクエストの応答を送信して受信するには 0.4 ミリ秒 (747858 から 748330) が必要でした。