지속적인 연결 문제

인바운드 규칙:

규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.

유형: 사용자 지정 TCP 규칙,

프로토콜: TCP

포트 범위: 1024-65535

소스: 0.0.0.0/0(또는 ElastiCache 클러스터 서브넷에 대한 개별 규칙 생성)

허용/거부: 허용

아웃바운드 규칙:

규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.

유형: 사용자 지정 TCP 규칙,

프로토콜: TCP

포트 범위: 6379

소스: 0.0.0.0/0(또는 ElastiCache 클러스터 서브넷. 특정 를 사용하면 장애 조치 또는 클러스터 크기 조정 시 문제가 발생할 IPs 수 있음에 유의하세요.)

허용/거부: 허용

인바운드 규칙:

규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.

유형: 사용자 지정 TCP 규칙,

프로토콜: TCP

포트 범위: 6379

소스: 0.0.0.0/0(또는 ElastiCache 클러스터 서브넷에 대한 개별 규칙 생성)

허용/거부: 허용

아웃바운드 규칙:

규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.

유형: 사용자 지정 TCP 규칙,

프로토콜: TCP

포트 범위: 1024-65535

소스: 0.0.0.0/0(또는 ElastiCache 클러스터 서브넷. 특정 를 사용하면 장애 조치 또는 클러스터 크기 조정 시 문제가 발생할 IPs 수 있음에 유의하세요.)

허용/거부: 허용

CPU 사용량: Valkey 및 RedisOSS는 다중 스레드 애플리케이션입니다. 그러나 각 명령의 실행은 단일(주) 스레드에서 발생합니다. 이러한 이유로 는 지표 CPUUtilization 및 를 ElastiCache 제공합니다EngineCPUUtilization. EngineCPUUtilization는 Valkey 또는 Redis OSS 프로세스 전용 CPU 사용률과 모든 의 사용량CPUUtilization을 제공합니다vCPUs. vCPU가 둘 이상인 노드는 일반적으로 CPUUtilization 및 에 대해 값이 다르EngineCPUUtilization며, 두 번째 노드는 일반적으로 더 높습니다. 높음은 완료하는 데 상당한 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

이전 예제에서는 동일한 소스에서 동일한 대상 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

숫자가 너무 높으면 연결 요청을 처리하는 동안 시스템에 과부하가 걸릴 수 있습니다. 연결 처리를 개선하려면 연결 풀링이나 지속적인 연결과 같은 기술을 구현하는 것이 좋습니다. 가능한 경우 항상 연결 풀을 구성하여 최대 연결 수를 수백 개로 제한합니다. 또한 문제가 발생할 경우 연결 이탈을 방지하려면 시간 초과 또는 기타 연결 예외를 처리하는 백오프 로직이 필요합니다.

네트워크 트래픽 제한: CloudWatch Redis에 대한 다음 지표OSS를 확인하여 ElastiCache 노드에서 발생할 수 있는 네트워크 제한을 식별합니다.

위의 지표는 네트워크 제한에 도달한 노드를 확인하는 이상적인 방법입니다. 그러나 제한은 네트워크 지표의 안정기로 식별할 수도 있습니다.

고평부가 장기간 관찰되면 복제 지연, 캐시에 사용되는 바이트 증가, 사용 가능한 메모리 삭제, 높은 스왑 및 CPU 사용량이 뒤따를 수 있습니다. Amazon EC2 인스턴스에는 ENA 드라이버 지표를 통해 추적할 수 있는 네트워크 제한도 있습니다. 향상된 네트워킹 지원이 포함된 Linux 인스턴스 및 ENA 드라이버 2.2.10 이상은 명령으로 제한 카운터를 검토할 수 있습니다.

# 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)

또는 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

짧은 시간(1분 이하) 동안 발생한 많은 느린 명령이 우려의 이유입니다. 명령의 특성과 명령을 최적화할 수 있는 방법을 검토합니다(이전 예제 참조). O(1) 시간 복잡성이 있는 명령이 자주 보고되는 경우 앞서 CPU 언급한 사용량이 높은 다른 요인을 확인합니다.

지연 시간 지표: ElastiCache (Redis OSS)는 다양한 명령 클래스의 평균 지연 시간을 모니터링하는 CloudWatch 지표를 제공합니다. 데이터 포인트는 한 범주에 속하는 명령의 총 실행 횟수를 해당 기간의 총 실행 시간으로 나누어 계산합니다. 대기 시간 지표의 결과는 여러 명령의 집계임을 이해하는 것이 중요합니다. 단일 명령을 사용하면 지표에 큰 영향을 주지 않으며 시간 초과와 같은 예기치 않은 결과가 발생할 수 있습니다. 이러한 경우 느리 로그 이벤트가 보다 정확한 정보 소스가 될 수 있습니다. 다음 목록에는 사용 가능한 대기 시간 지표와 이에 영향을 주는 각 명령이 나와 있습니다.

Redis OSS 런타임 명령:

백업 및 복제: 2.8.22 이전의 ElastiCache (Redis OSS) 버전은 포크 프로세스를 사용하여 백업을 생성하고 복제본과의 전체 동기화를 처리합니다. 이 방법은 쓰기 집약적인 사용 사례에서 상당한 메모리 오버헤드가 발생시킬 수 있습니다.

ElastiCache Redis OSS 2.8.22부터는 포크리스 백업 및 복제 방법을 AWS 도입했습니다. 새로운 방법은 실패를 방지하기 위해 쓰기를 지연시킬 수 있습니다. 두 방법 모두 CPU 사용률이 높아지고 응답 시간이 길어지므로 실행 중에 클라이언트 제한 시간이 발생할 수 있습니다. 백업 기간 중에 클라이언트 장애가 발생하거나 이 기간 중에 SaveInProgress 지표가 1이었는지 항상 확인하세요. 클라이언트 문제 또는 백업 실패의 가능성을 최소화하기 위해 사용률이 낮은 기간으로 백업 기간을 예약하는 것이 좋습니다.

클라이언트 애플리케이션의 버그로 인해 연결이 손실되고 유휴 상태로 설정이 유지될 수 있습니다. 이것을 “연결 누수“라고 하며 결과적으로 CurrConnections 지표에서 관찰되는 설정된 연결의 수가 지속적으로 증가합니다. 이 동작은 클라이언트 또는 ElastiCache 측에서 포화될 수 있습니다. 클라이언트 측에서 즉각적인 수정이 불가능한 경우 일부 관리자는 ElastiCache 파라미터 그룹에서 “타임아웃” 값을 설정합니다. 시간 초과는 유휴 연결이 지속되도록 허용된 기간(초)입니다. 클라이언트가 해당 기간에 요청을 제출하지 않으면 Redis OSS 엔진은 연결이 제한 시간에 도달하는 즉시 연결을 종료합니다. 시간 초과 값이 작으면 불필요한 연결 끊기가 발생할 수 있으며 클라이언트가 연결을 올바르게 처리하고 다시 연결해야 하므로 지연이 발생합니다.

키를 저장하는 데 사용되는 메모리는 클라이언트 버퍼와 공유됩니다. 크기가 큰 요청이나 응답이 있는 느린 클라이언트는 버퍼를 처리하기 위해 상당한 양의 메모리를 요구할 수 있습니다. 기본 ElastiCache (Redis OSS) 구성은 일반 클라이언트 출력 버퍼의 크기를 제한하지 않습니다. maxmemory 제한에 도달하면 엔진은 버퍼 사용량을 충족하기 위해 항목을 제거하려고 시도합니다. 메모리가 매우 낮은 조건에서는 ElastiCache (Redis OSS)가 대용량 클라이언트 출력 버퍼를 사용하는 클라이언트의 연결을 해제하여 메모리를 확보하고 클러스터의 상태를 유지할 수 있습니다.

사용자 지정 구성으로 클라이언트 버퍼의 크기를 제한할 수 있으며 이 제한에 도달한 클라이언트는 연결이 끊어집니다. 그러나 클라이언트는 예기치 않은 연결 해제를 처리할 수 있어야 합니다. 일반 클라이언트의 버퍼 크기를 처리하는 파라미터는 다음과 같습니다.

일반 클라이언트 버퍼 외에도, 다음 옵션은 복제본 노드 및 Pub/Sub(게시/구독) 클라이언트에 대한 버퍼를 제어합니다.

CPU:

네트워크

네트워크에서: Tcpdump 및 Wireshark (명령줄의 tshark)는 요청이 네트워크를 이동하는 데 걸린 시간을 이해하고, ElastiCache 엔진을 쳐서 반환을 받을 수 있는 편리한 도구입니다. 다음 예제에서는 다음과 같은 명령을 사용하여 생성한 단일 요청을 강조 표시합니다.

$ 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으로)을 수행하는 데 약 20ms의 상당한 시간이 소요되었으며, 그 후 TCP 소켓을 생성하는 데 2ms(745659에서 747858로), 요청에 대한 응답을 제출하고 수신하기 위해 0.4ms(747858에서 748330으로)가 필요했습니다.