持続的な接続性の問題

インバウンドルール:

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

[タイプ]: [カスタム TCP ルール]。

[Protocol]: TCP

[Port Range]: 1024～65535

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

[許可/拒否]: 許可

アウトバウンドルール:

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

[タイプ]: [カスタム TCP ルール]。

[Protocol]: TCP

[Port Range]: 6379

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

[許可/拒否]: 許可

インバウンドルール:

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

[タイプ]: [カスタム TCP ルール]。

[Protocol]: TCP

[Port Range]: 6379

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

[許可/拒否]: 許可

アウトバウンドルール:

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

[タイプ]: [カスタム TCP ルール]。

[Protocol]: TCP

[Port Range]: 1024～65535

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

[許可/拒否]: 許可

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

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

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

アプリケーションは TLS/SSL をサポートしていますが、正しい設定フラグまたは信頼できる証明権限がありません。

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

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

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

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

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

ネットワークトラフィックの制限: 次の Redis OSS の CloudWatch メトリクスを使用して、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.823ms）かかり、クライアント 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)

または、PowerShell を搭載した Windows の場合:

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

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

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

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

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

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

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

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

CPU:

ネットワーク

ネットワーク上: Tcpdump および Wireshark (コマンドラインでは tshark) は、リクエストがネットワークを走行し、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

上記の出力から、TCP スリーウェイハンドシェイクが 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 まで) には多くの時間 (約 20ms) がかかりました。その後、TCP ソケットの作成には 2ms (745659 から 747858)、リクエストに対する応答の送信と受信には 0.4ms (747858 から 748330) が必要でした。