기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
지속적인 연결 문제
의 지속적 연결 문제를 해결하는 동안 다음 항목을 확인해야 합니다 ElastiCache.
주제
보안 그룹
보안 그룹은 ElastiCache 클라이언트(EC2인스턴스, AWS Lambda 함수, Amazon ECS 컨테이너 등) 및 ElastiCache 캐시를 보호하는 가상 방화벽입니다. 보안 그룹은 상태 유지(stateful) 방식으로 작동합니다. 즉, 들어오거나 나가는 트래픽이 허용되면 해당 트래픽에 대한 응답이 관련 보안 그룹의 컨텍스트에서 자동으로 승인됩니다.
상태 유지 기능을 사용하려면 보안 그룹이 권한이 부여된 모든 연결을 추적해야 하며, 이렇게 추적되는 연결에는 제한이 있습니다. 이 제한에 도달하면 새 연결이 실패합니다. 클라이언트 또는 ElastiCache 측에서 한도에 도달했는지 확인하는 방법에 대한 도움말은 문제 해결 섹션을 참조하세요.
클라이언트와 ElastiCache 클러스터에 동시에 단일 보안 그룹을 할당하거나 각각에 대해 개별 보안 그룹을 할당할 수 있습니다.
두 경우 모두 소스에서 ElastiCache 포트의 TCP 아웃바운드 트래픽과 동일한 포트의 인바운드 트래픽을 로 허용해야 합니다 ElastiCache. 기본 포트는 Memcached의 경우 11211이고 Valkey 또는 Redis 의 경우 6379입니다OSS. 기본적으로 보안 그룹은 모든 아웃바운드 트래픽을 허용합니다. 이 경우 대상 보안 그룹의 인바운드 규칙만 필요합니다.
자세한 내용은 Amazon 에서 ElastiCache 클러스터에 액세스하기 위한 액세스 패턴을 참조하세요VPC.
네트워크 ACLs
네트워크 액세스 제어 목록(ACLs)은 상태 비저장 규칙입니다. 트래픽이 성공하려면 양방향(인바운드 및 아웃바운드)으로 허용되어야 합니다. 네트워크ACLs는 특정 리소스가 아닌 서브넷에 할당됩니다. 특히 클라이언트 리소스가 동일한 서브넷에 있는 경우 ElastiCache 및 클라이언트 리소스에 동일한 를 ACL 할당할 수 있습니다.
기본적으로 네트워크는 모든 추적을 ACLs 허용합니다. 그러나 트래픽을 거부하거나 허용하도록 네트워크 ACL을 사용자 지정할 수 있습니다. 또한 ACL 규칙 평가는 순차적입니다. 즉, 트래픽과 일치하는 숫자가 가장 낮은 규칙에서 허용하거나 거부합니다. Valkey 또는 Redis OSS 트래픽을 허용하는 최소 구성은 다음과 같습니다.
클라이언트 측 네트워크ACL:
인바운드 규칙:
규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.
유형: 사용자 지정 TCP 규칙,
프로토콜: TCP
포트 범위: 1024-65535
소스: 0.0.0.0/0(또는 ElastiCache 클러스터 서브넷에 대한 개별 규칙 생성)
허용/거부: 허용
아웃바운드 규칙:
규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.
유형: 사용자 지정 TCP 규칙,
프로토콜: TCP
포트 범위: 6379
소스: 0.0.0.0/0(또는 ElastiCache 클러스터 서브넷. 특정 를 사용하면 장애 조치 또는 클러스터 크기 조정 시 문제가 발생할 IPs 수 있음에 유의하세요.)
허용/거부: 허용
ElastiCache 네트워크ACL:
인바운드 규칙:
규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.
유형: 사용자 지정 TCP 규칙,
프로토콜: TCP
포트 범위: 6379
소스: 0.0.0.0/0(또는 ElastiCache 클러스터 서브넷에 대한 개별 규칙 생성)
허용/거부: 허용
아웃바운드 규칙:
규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.
유형: 사용자 지정 TCP 규칙,
프로토콜: TCP
포트 범위: 1024-65535
소스: 0.0.0.0/0(또는 ElastiCache 클러스터 서브넷. 특정 를 사용하면 장애 조치 또는 클러스터 크기 조정 시 문제가 발생할 IPs 수 있음에 유의하세요.)
허용/거부: 허용
자세한 내용은 네트워크 섹션을 ACLs참조하세요.
라우팅 테이블
네트워크 와 마찬가지로 ACLs각 서브넷에는 서로 다른 라우팅 테이블이 있을 수 있습니다. 클라이언트와 ElastiCache 클러스터가 서로 다른 서브넷에 있는 경우 라우팅 테이블에서 서로 연결할 수 있도록 허용해야 합니다.
여러 , VPCs동적 라우팅 또는 네트워크 방화벽을 포함하는 더 복잡한 환경은 문제를 해결하기 어려울 수 있습니다. 네트워크 연결 검증 섹션을 참조하여 네트워크 설정이 적절한지 확인하세요.
DNS 해상도
ElastiCache 는 DNS 이름을 기반으로 서비스 엔드포인트를 제공합니다. 사용 가능한 엔드포인트는 Configuration, Primary, Reader 및 Node 엔드포인트입니다. 자세한 내용은 연결 엔드포인트 찾기를 참조하세요.
장애 조치 또는 클러스터 수정의 경우 엔드포인트 이름에 연결된 주소가 변경될 수 있으며 자동으로 업데이트됩니다.
사용자 지정 DNS 설정(즉, VPC DNS 서비스를 사용하지 않음)은 ElastiCache제공된 DNS 이름을 인식하지 못할 수 있습니다. (다음과 dig 같이) 또는 와 같은 시스템 도구를 사용하여 시스템이 ElastiCache 엔드포인트를 성공적으로 해결할 수 있는지 확인합니다nslookup.
$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com example-001.xxxxxx.0001.use1.cache.amazonaws.com. 1.2.3.4
VPC DNS 또한 서비스를 통해 이름 확인을 강제로 적용할 수 있습니다.
$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com @169.254.169.253 example-001.tihewd.0001.use1.cache.amazonaws.com. 1.2.3.4
서버 측 진단을 사용하여 문제 식별
CloudWatch ElastiCache 엔진의 지표 및 런타임 정보는 연결 문제의 잠재적 원인을 식별하기 위한 일반적인 소스 또는 정보입니다. 좋은 분석은 일반적으로 다음과 같은 항목으로 시작됩니다.
CPU 사용량: Valkey 및 RedisOSS는 다중 스레드 애플리케이션입니다. 그러나 각 명령의 실행은 단일(주) 스레드에서 발생합니다. 이러한 이유로 는 지표
CPUUtilization및 를 ElastiCache 제공합니다EngineCPUUtilization.EngineCPUUtilization는 Valkey 또는 Redis OSS 프로세스 전용 CPU 사용률과 모든 의 사용량CPUUtilization을 제공합니다vCPUs. vCPU가 둘 이상인 노드는 일반적으로CPUUtilization및 에 대해 값이 다르EngineCPUUtilization며, 두 번째 노드는 일반적으로 더 높습니다. 높음은 완료하는 데 상당한 CPU 시간이 걸리는 요청 수 증가 또는 복잡한 작업으로 인해 발생할EngineCPUUtilization수 있습니다. 다음을 사용하여 둘 모두를 식별할 수 있습니다.많은 수의 요청:
EngineCPUUtilization패턴과 일치하는 다른 지표의 증가 여부를 확인합니다. 유용한 지표는 다음과 같습니다.CacheHits및CacheMisses: 성공한 요청 또는 캐시에서 유효한 항목을 찾지 못한 요청의 수입니다. 적중률에 비해 누락률이 높으면 애플리케이션에서 무의미한 요청에 시간과 리소스를 낭비하고 있는 것입니다.SetTypeCmds및GetTypeCmds:EngineCPUUtilization과 상관 관계가 있는 이 두 지표는SetTypeCmds에 의해 측정되는 쓰기 요청 또는GetTypeCmds에 의해 측정되는 읽기 요청에 대한 로드가 얼마나 높은지 파악하는 데 도움이 될 수 있습니다 로드가 주로 읽기인 경우 여러 읽기 전용 복제본을 사용하면 여러 노드에 요청을 분산시켜 균형을 유지하고 기본 노드를 쓰기용으로 할당할 수 있습니다. 클러스터 모드 비활성화 클러스터에서는 ElastiCache 리더 엔드포인트를 사용하여 애플리케이션에서 추가 연결 구성을 생성하여 읽기 전용 복제본을 사용할 수 있습니다. 자세한 내용은 연결 엔드포인트 찾기를 참조하세요. 읽기 작업은 이 추가 연결에 제출되어야 합니다. 쓰기 작업은 일반적인 기본 엔드포인트를 통해 수행됩니다. 클러스터 모드가 활성화된 클러스터에서는 기본적으로 읽기 전용 복제본을 지원하는 라이브러리를 사용하는 것이 좋습니다. 올바른 플래그를 사용하면 라이브러리가 클러스터 토폴로지, 복제본 노드를 자동으로 검색하고, READONLYValkey 또는 Redis OSS 명령을 통해 읽기 작업을 활성화하고, 읽기 요청을 복제본에 제출할 수 있습니다.
많은 수의 연결:
CurrConnections및NewConnections:CurrConnection은 데이터 포인트 컬렉션 순간에 설정된 연결 수이고,NewConnections는 이 기간에 생성된 연결 수를 보여줍니다.연결을 생성하고 처리하면 상당한 CPU 오버헤드가 발생합니다. 또한 새 연결을 생성하는 데 필요한 TCP3방향 핸드셰이크는 전체 응답 시간에 부정적인 영향을 미칩니다.
NewConnections분당 수천 개의 ElastiCache 노드는 연결이 최적의 상태가 아닌 몇 가지 명령으로만 생성되고 사용됨을 나타냅니다. 설정된 연결을 유지하고 새 작업에 이 연결을 다시 사용하는 것이 모범 사례입니다. 이것이 가능하려면 클라이언트 애플리케이션이 연결 풀링이나 영구 연결을 지원하고 적절하게 구현해야 합니다. 연결 풀링을 사용하는 경우currConnections수에는 큰 변화가 없으며NewConnections는 가능한 낮아야 합니다. Valkey 및 Redis는 적은 수의 로 최적의 성능을 OSS 제공합니다currConnections. 수십 또는 수백 currConnection 개 순으로 유지하면 클라이언트 버퍼 및 연결 서비스 CPU 주기와 같은 개별 연결을 지원하는 리소스 사용을 최소화할 수 있습니다.
네트워크 처리량:
대역폭: ElastiCache 노드에 노드 크기에 비례하는 네트워크 대역폭이 있는지 확인합니다. 애플리케이션마다 특성이 다르기 때문에 워크로드에 따라 결과가 달라질 수 있습니다. 예를 들어 작은 요청의 비율이 높은 애플리케이션은 네트워크 처리량보다 CPU 사용량에 더 많은 영향을 미치는 경향이 있는 반면 키가 클수록 네트워크 사용률이 높아집니다. 그러므로 제한을 보다 정확하게 이해하기 위해 실제 워크로드로 노드를 테스트하는 것이 좋습니다.
애플리케이션의 로드를 시뮬레이션하면 보다 정확한 결과를 얻을 수 있습니다. 그러나 벤치마크 도구가 제한에 대한 좋은 아이디어를 줄 수 있습니다.
요청이 주로 읽기인 경우 읽기 작업에 복제본을 사용하면 기본 노드의 로드가 줄어듭니다. 사용 사례가 주로 쓰기인 경우 많은 복제본을 사용하면 네트워크 사용량이 크게 늘어납니다. 기본 노드에 한 바이트가 쓰여질 때마다 N바이트가 복제본으로 전송됩니다. 여기서 N은 복제본 수입니다. 쓰기 집약적 워크로드의 모범 사례는 클러스터 모드가 활성화된 ElastiCache (Redis OSS)를 사용하여 쓰기를 여러 샤드 간에 균형을 맞추거나 네트워크 기능이 더 많은 노드 유형으로 확장하는 것입니다.
및 는 CloudWatchmetrics
NetworkBytesIn각각 노드로 들어오거나 노드에서 나가는 데이터의 양을NetworkBytesOut제공합니다.ReplicationBytes는 데이터 복제 전용 트래픽입니다.
자세한 내용은 네트워크 관련 제한 사항 단원을 참조하십시오.
복잡한 명령: Redis OSS 명령은 단일 스레드에서 제공되므로 요청이 순차적으로 제공됩니다. 단일 느린 명령은 다른 요청 및 연결에 영향을 줄 수 있으며 시간 초과로 이어질 수 있습니다. 여러 값, 키 또는 데이터 유형에 작동하는 명령을 사용할 때 신중하게 사용해야 합니다. 연결은 파라미터의 수나 입력 또는 출력 값의 크기에 따라 차단되거나 종료될 수 있습니다.
악명 높은 예는
KEYS명령입니다. 이 명령은 전체 키스페이스에 걸쳐 주어진 패턴을 검색하며, 실행 중에 다른 명령의 실행을 차단합니다. RedisOSS는 “Big O” 표기법을 사용하여 명령의 복잡성을 설명합니다.Keys 명령은 O(N) 시간 복잡도를 가지며 N은 데이터베이스의 키 수입니다. 따라서 키 수가 클수록 명령 속도가 느려집니다.
KEYS는 여러 방식으로 문제를 일으킬 수 있습니다. 검색 패턴을 사용하지 않으면 이 명령은 사용 가능한 모든 키 이름을 반환합니다. 수 천개나 수 백만 개의 항목이 있는 데이터베이스에서는 엄청난 출력이 생성되어 네트워크 버퍼가 가득 차게 됩니다.검색 패턴을 사용하는 경우 패턴과 일치하는 키만 클라이언트로 반환됩니다. 그러나 엔진은 여전히 전체 키스페이스에 걸쳐 키를 검색하며 명령을 완료하는 데 걸리는 시간은 동일합니다.
KEYS명령의 대안은SCAN명령입니다. 이 명령은 키스페이스를 반복해서 처리하고 특정 수의 항목으로 반복을 제한하여 엔진의 장기적인 차단을 방지합니다.Scan에는 반복 블록의 크기를 설정하는 데 사용되는
COUNT파라미터가 있습니다. 기본값은 10(반복당 10개 항목)입니다.데이터베이스의 항목 수에 따라, 작은
COUNT값 블록이 전체 스캔을 완료하는 데 더 많은 반복을 필요로 하며 값이 클수록 각 반복마다 엔진을 더 오래 사용할 수 있습니다. 작은 count 값은 큰 데이터베이스에서SCAN속도를 느리게 만들며, 값이 클수록KEYS에서 언급한 동일한 문제가 발생할 수 있습니다.예를 들어,
SCAN명령을 count 값 10으로 실행하면 1백만 개의 키가 있는 데이터베이스에서 100,000번의 반복이 필요합니다. 평균 네트워크 왕복 시간이 0.5밀리초인 경우 요청을 전송하는 데 약 50,000밀리초(50초)가 소비됩니다.반면에 count 값이 100,0000인 경우 단일 반복으로 충분하며 요청을 전송하는 데 단지 0.5밀리초가 소비됩니다. 그러나 명령이 모든 키스페이스의 처리를 마칠 때까지 엔진이 다른 작업에 대해 완전히 차단됩니다.
KEYS외에도, 올바르게 사용하지 않으면 잠재적인 문제를 일으킬 수 있는 여러 다른 명령이 있습니다. 모든 명령의 목록과 각각의 시간 복잡성을 보려면 Valkey 및 Redis OSS 명령으로이동합니다. 잠재적 문제의 예:
Lua 스크립트: Valkey 및 Redis는 임베디드 Lua 해석기를 OSS 제공하여 서버 측에서 스크립트를 실행할 수 있습니다. Valkey 및 Redis의 Lua 스크립트OSS는 엔진 수준에서 실행되며 정의에 따라 원자적입니다. 즉, 스크립트가 실행되는 동안에는 다른 명령 또는 스크립트를 실행할 수 없습니다. Lua 스크립트는 엔진에서 직접 여러 명령, 의사 결정 알고리즘, 데이터 구문 분석 등을 실행할 수 있는 가능성을 제공합니다. 스크립트의 원자성과 애플리케이션을 오프로드할 수 있는 기능은 유혹적이지만 스크립트는 작은 작업에 신중하게 사용해야 합니다. 에서 Lua 스크립트의 ElastiCache실행 시간은 5초로 제한됩니다. 키스페이스에 기록되지 않은 스크립트는 5초 후에 자동으로 종료됩니다. 데이터 손상 및 불일치를 방지하기 위해 스크립트 실행이 5초 내에 완료되지 않았고 실행 중에 쓰기가 있는 경우 노드가 장애 조치됩니다. 트랜잭션
은 Redis 에서 여러 관련 키 수정의 일관성을 보장하는 대안입니다OSS. 트랜잭션을 사용하면 명령 블록을 실행하여 기존 키의 수정을 감시할 수 있습니다. 트랜잭션이 완료되기 전에 감시된 키가 변경되면 모든 수정 사항이 무시됩니다. 항목의 일괄 삭제:
DEL명령에는 삭제할 키 이름에 해당하는 파라미터 여러 개를 사용할 수 있습니다. 삭제 작업은 동기식이며 파라미터 목록이 크거나 큰 목록, 세트, 정렬된 세트 또는 해시(여러 하위 항목을 포함하는 데이터 구조)가 포함된 경우 상당한 CPU 시간이 걸립니다. 즉, 단일 키를 삭제하는 경우에도 요소가 많은 경우 상당한 시간이 걸릴 수 있습니다. 의 대안은 Redis 4 이후 사용할 수UNLINK있는 비동기 명령인 OSSDEL입니다. 는 가능하면DEL보다 선호되어야UNLINK합니다. ElastiCache (Redis OSS) 6x부터lazyfree-lazy-user-del파라미터는 활성화UNLINK시DEL처럼 명령을 작동합니다. 자세한 내용은 Redis OSS 6.0 파라미터 변경 사항을 참조하세요.여러 키에 작동하는 명령:
DEL은 이전에 여러 인수를 허용하는 명령으로 언급되었으며 실행 시간은 이에 직접적으로 비례합니다. 하지만 RedisOSS는 비슷한 방식으로 작동하는 더 많은 명령을 제공합니다. 예를 들면MSET및MGET를 사용하면 한 번에 여러 문자열 키를 삽입하거나 검색할 수 있습니다. 이러한 명령을 사용하면 개별SET또는GET명령을 여러 번 사용할 때 발생하는 네트워크 대기 시간을 줄일 수 있습니다. 그러나 광범위한 파라미터 목록은 CPU 사용량에 영향을 미칩니다.사용CPU률만으로는 연결 문제가 발생하지 않지만 여러 키를 통해 하나 또는 몇 개의 명령을 처리하는 데 너무 많은 시간을 할애하면 다른 요청이 실패하고 전체 CPU 사용률이 증가할 수 있습니다.
키의 수와 해당 크기는 명령의 복잡도, 결과적으로 완료 시간에 영향을 미칩니다.
여러 키에 작동할 수 있는 다른 명령의 예에는
HMGET,HMSET,MSETNX,PFCOUNT,PFMERGE,SDIFF,SDIFFSTORE,SINTER,SINTERSTORE,SUNION,SUNIONSTORE,TOUCH,ZDIFF,ZDIFFSTORE,ZINTER,ZINTERSTORE등이 있습니다.여러 데이터 유형에 작용하는 명령: Redis는 데이터 유형에 관계없이 하나 이상의 키에 작용하는 명령OSS도 제공합니다. ElastiCache (Redis OSS)는 이러한 명령을 모니터링하는 지표
KeyBasedCmds를 제공합니다. 이 지표는 선택한 기간 동안 다음과 같은 명령의 실행을 합산합니다.O(N) 복잡도:
KEYS
O(1)
EXISTSOBJECTPTTLRANDOMKEYTTLTYPEEXPIREEXPIREATMOVEPERSISTPEXPIREPEXPIREATUNLINK (O(N)를 사용하여 메모리를 회수합니다. 그러나 메모리 회수 작업은 분리된 스레드에서 발생하며 엔진을 차단하지 않습니다.
데이터 유형에 따라 복잡도 시간이 다릅니다.
DELDUMPRENAME은 복잡도가 O(1)인 명령으로 간주되지만 내부적으로DEL을 실행합니다. 실행 시간은 이름이 바뀐 키의 크기에 따라 달라집니다.RENAMENXRESTORESORT
큰 해시: 해시는 여러 키-값 하위 항목이 있는 단일 키를 허용하는 데이터 유형입니다. 각 해시는 4,294,967,295개 항목을 저장할 수 있으며 큰 해시에 대한 작업은 비용이 많이 들 수 있습니다.
KEYS와 유사하게, 해시에는 O(N) 시간 복잡도를 갖는HKEYS명령이 있으며, N은 해시의 항목 수입니다. 장기 실행 명령을 방지하려면HKEYS대신HSCAN을 사용해야 합니다.HDEL,HGETALL,HMGET,HMSET및HVALS는 큰 해시에서 주의해서 사용해야 하는 명령입니다.
기타 빅 데이터 구조: CPU 해시 외에도 다른 데이터 구조는 집약적일 수 있습니다. 집합, 목록, 정렬된 집합 및 Hyperloglog는 크기와 사용된 명령에 따라 처리하는 데 상당한 시간이 걸릴 수 있습니다. 이러한 명령에 대한 자세한 내용은 Valkey 및 Redis OSS 명령 을
참조하세요.
네트워크 연결 검증
DNS 해상도, 보안 그룹, 네트워크 ACLs및 라우팅 테이블과 관련된 네트워크 구성을 검토한 후 VPC Reachability Analyzer 및 시스템 도구를 사용하여 연결을 검증할 수 있습니다.
Reachability Analyzer는 네트워크 연결을 테스트하고 모든 요구 사항 및 권한이 충족되는지 확인합니다. 아래 테스트를 수행하려면 에서 사용할 수 있는 ElastiCache 노드 중 하나의 ENI ID(Elastic Network Interface Identification)가 필요합니다VPC. 다음을 수행하여 이 ID를 찾을 수 있습니다.
ElastiCache 클러스터 이름 또는 이전에 DNS 검증한 IP 주소를 기준으로 인터페이스 목록을 필터링합니다.
ENI ID를 기록하거나 저장합니다. 여러 인터페이스가 표시되는 경우 설명을 검토하여 해당 인터페이스가 올바른 ElastiCache 클러스터에 속하는지 확인하고 그 중 하나를 선택합니다.
다음 단계를 진행합니다.
집에서 https://console.aws.amazon.com/vpc/분석 경로를 생성하시겠습니까?#ReachabilityAnalyzer
다음 옵션을 선택합니다. 소스 유형 : ElastiCache 클라이언트가 Amazon 인스턴스 또는 awsvpc 네트워크가 있는 Amazon 등 다른 서비스를 사용하는 경우 네트워크 인터페이스에서 실행되는 EC2 경우 인스턴스를 선택하고 해당 리소스 ID(EC2인스턴스 또는 ENI ID) AWS Lambda를 선택합니다. AWS Fargate ECS
대상 유형 : 네트워크 인터페이스를 선택하고 목록에서 ElasticacheENI를 선택합니다.
대상 포트 : ElastiCache (Redis OSS)의 경우 6379를 지정하고 ElastiCache (Memcached)의 경우 11211을 지정합니다. 이러한 포트는 기본 구성으로 정의된 포트이며 이 예에서는 포트가 변경되지 않는다고 가정합니다.
프로토콜: TCP
분석 경로를 생성하고 결과를 몇 분 정도 기다립니다. 상태가 연결할 수 없음인 경우 분석 세부 정보를 열고 분석 탐색기에서 요청이 차단된 위치에 대한 자세한 정보를 검토합니다.
연결성 테스트가 통과되면 OS 수준에서 확인을 진행합니다.
ElastiCache 서비스 포트의 TCP 연결 검증: Amazon Linux에서 Nping는 패키지에서 사용할 수 nmap 있으며 ElastiCache 포트의 TCP 연결을 테스트하고 네트워크 왕복 시간을 제공하여 연결을 설정할 수 있습니다. 다음과 같이 이를 사용하여 ElastiCache 클러스터에 대한 네트워크 연결 및 현재 지연 시간을 검증합니다.
$ sudo nping --tcp -p 6379 example.xxxxxx.ng.0001.use1.cache.amazonaws.com Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2020-12-30 16:48 UTC SENT (0.0495s) TCP ... (Output suppressed ) Max rtt: 0.937ms | Min rtt: 0.318ms | Avg rtt: 0.449ms Raw packets sent: 5 (200B) | Rcvd: 5 (220B) | Lost: 0 (0.00%) Nping done: 1 IP address pinged in 4.08 seconds
기본적으로, nping은 5개의 프로브를 사이에 1초의 지연 시간을 두어 전송합니다. “-c” 옵션을 사용하여 프로브 수를 늘리고 “--delay“ 옵션을 사용하여 새 테스트를 전송하는 시간을 변경할 수 있습니다.
가 포함된 테스트가 nping 실패하고 VPC Reachability Analyzer 테스트가 통과된 경우 시스템 관리자에게 가능한 호스트 기반 방화벽 규칙, 비대칭 라우팅 규칙 또는 운영 체제 수준에서 발생할 수 있는 기타 제한을 검토하도록 요청합니다.
ElastiCache 콘솔에서 ElastiCache 클러스터 세부 정보에서 전송 중 암호화가 활성화되어 있는지 확인합니다. 전송 중 암호화가 활성화된 경우 다음 명령을 사용하여 TLS 세션을 설정할 수 있는지 확인합니다.
openssl s_client -connectexample.xxxxxx.use1.cache.amazonaws.com:6379
연결 및 TLS 협상이 성공하면 광범위한 출력이 예상됩니다. 마지막 줄에서 사용할 수 있는 반환 코드를 확인하세요. 값이 0 (ok)여야 합니다. openssl이 다른 것을 반환하는 경우 https://www.openssl.org/docs/man1.0.2/man1/verify.html#DIAGNOSTICS
모든 인프라 및 운영 체제 테스트가 통과되었지만 애플리케이션이 여전히 에 연결할 수 없는 경우 애플리케이션 구성이 ElastiCache 설정을 준수하는지 ElastiCache확인합니다. 일반적인 실수는 다음과 같습니다.
애플리케이션이 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 노드에서 발생할 수 있는 네트워크 제한을 식별합니다.
NetworkBandwidthInAllowanceExceeded/NetworkBandwidthOutAllowanceExceeded: 처리량이 집계된 대역폭 제한을 초과하여 형성된 네트워크 패킷입니다.기본 노드에 한 바이트가 쓰여질 때마다 N개 복제본으로 복제됩니다. 여기서 N은 복제본 수입니다. 노드 유형이 작고, 여러 개의 복제본이 있으며 많은 쓰기 요청이 있는 클러스터는 복제 백로그를 처리하지 못할 수 있습니다. 이러한 경우 확장(노드 유형 변경), 스케일 아웃(클러스터 모드가 활성화된 클러스터에 샤드 추가), 복제본 수를 줄이기 또는 쓰기 수 최소화를 수행하는 것이 모범 사례입니다.
NetworkConntrackAllowanceExceeded: 노드에 할당된 모든 보안 그룹에서 추적되는 최대 연결 수를 초과했기 때문에 형성되는 패킷입니다. 이 기간 동안 새 연결이 실패할 가능성이 높습니다.NetworkPackets PerSecondAllowanceExceeded: 초당 최대 패킷 수를 초과했습니다. 매우 크기가 작은 요청의 비율이 높은 워크로드는 최대 대역폭 전에 이 제한에 도달할 수 있습니다.
위의 지표는 네트워크 제한에 도달한 노드를 확인하는 이상적인 방법입니다. 그러나 제한은 네트워크 지표의 안정기로 식별할 수도 있습니다.
고평부가 장기간 관찰되면 복제 지연, 캐시에 사용되는 바이트 증가, 사용 가능한 메모리 삭제, 높은 스왑 및 CPU 사용량이 뒤따를 수 있습니다. Amazon EC2 인스턴스에는 ENA 드라이버 지표를 통해 추적할 수 있는 네트워크 제한도 있습니다. 향상된 네트워킹 지원이 포함된 Linux 인스턴스 및 ENA 드라이버 2.2.10 이상은 명령으로 제한 카운터를 검토할 수 있습니다.
# ethtool -S eth0 | grep "allowance_exceeded"
CPU 사용량
CPU 사용량 지표는 조사의 시작점이며, 다음 항목은 ElastiCache 측면에서 발생할 수 있는 문제를 좁히는 데 도움이 될 수 있습니다.
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 2020Python 사용:
>>> 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 지표를 제공합니다. 데이터 포인트는 한 범주에 속하는 명령의 총 실행 횟수를 해당 기간의 총 실행 시간으로 나누어 계산합니다. 대기 시간 지표의 결과는 여러 명령의 집계임을 이해하는 것이 중요합니다. 단일 명령을 사용하면 지표에 큰 영향을 주지 않으며 시간 초과와 같은 예기치 않은 결과가 발생할 수 있습니다. 이러한 경우 느리 로그 이벤트가 보다 정확한 정보 소스가 될 수 있습니다. 다음 목록에는 사용 가능한 대기 시간 지표와 이에 영향을 주는 각 명령이 나와 있습니다.
EvalBasedCmdsLatency: Lua Script 명령 관련,
eval,evalsha;GeoSpatialBasedCmdsLatency:
geodist,geohash,geopos,georadius,georadiusbymember,geoadd;GetTypeCmdsLatency: 데이터 유형에 관계없이 명령 읽기
HashBasedCmdsLatency:
hexists,hget,hgetall,hkeys,hlen,hmget,hvals,hstrlen,hdel,hincrby,hincrbyfloat,hmset,hset,hsetnx;HyperLogLogBasedCmdsLatency:
pfselftest,pfcount,pfdebug,pfadd,pfmerge;KeyBasedCmdsLatency:
dump, ,exists,keys,object, , , , ,pttlrandomkeyttltype, , ,delexpireexpireat,move, ,persist,pexpire,pexpireat,rename,restoreK,renamenx, 등 다양한 데이터 유형에 따라 작동할 수 있는 명령sortunlinkListBasedCmdsLatency: lindex, llen, lrange, blpop, brpop, brpoplpush, linsert, lpop, lpush, lpushx, lrem, lset, ltrim, rpop, rpoplpush, rpush, rpush;
PubSubBasedCmdsLatency: 구독, 게시, pubsub, punsub, 구독, 구독 취소
SetBasedCmdsLatency:
scard,sdiff,sinter,sismember,smembers,srandmember,sunion,sadd,sdiffstore,sinterstore,smove,spop,srem,sunionstore;SetTypeCmdsLatency: 데이터 유형에 관계없이 명령 쓰기
SortedSetBasedCmdsLatency:
zcard,zcount,zrange,zrangebyscore,zrank,zrevrange,zrevrangebyscore,zrevrank,zscore,zrangebylex,zrevrangebylex,zlexcount,zadd.zincrby,zinterstore,zrem,zremrangebyrank,zremrangebyscore,zunionstore,zremrangebylex,zpopmax,zpopmin,bzpopmin,bzpopmax;StringBasedCmdsLatency:
bitcount,get,getbit,getrange,mget,strlen,substr,bitpos,append,bitop,bitfield,decr,decrby,getset,incr,incrby,incrbyfloat,mset,msetnx,psetex,set,setbit,setex,setnx,setrange;StreamBasedCmdsLatency:
xrange,xrevrange,xlen,xread,xpending,xinfo,xadd,xgroup,readgroup,xack,xclaim,xdel,xtrim,xsetid;
Redis OSS 런타임 명령:
info commandstats: Redis OSS 엔진이 시작된 이후 실행된 명령 목록, 누적 실행 수, 총 실행 시간 및 명령당 평균 실행 시간을 제공합니다.
client list: 현재 연결된 클라이언트와 버퍼 사용량, 마지막으로 실행된 명령 등과 같은 관련 정보의 목록을 제공합니다.
백업 및 복제: 2.8.22 이전의 ElastiCache (Redis OSS) 버전은 포크 프로세스를 사용하여 백업을 생성하고 복제본과의 전체 동기화를 처리합니다. 이 방법은 쓰기 집약적인 사용 사례에서 상당한 메모리 오버헤드가 발생시킬 수 있습니다.
ElastiCache Redis OSS 2.8.22부터는 포크리스 백업 및 복제 방법을 AWS 도입했습니다. 새로운 방법은 실패를 방지하기 위해 쓰기를 지연시킬 수 있습니다. 두 방법 모두 CPU 사용률이 높아지고 응답 시간이 길어지므로 실행 중에 클라이언트 제한 시간이 발생할 수 있습니다. 백업 기간 중에 클라이언트 장애가 발생하거나 이 기간 중에
SaveInProgress지표가 1이었는지 항상 확인하세요. 클라이언트 문제 또는 백업 실패의 가능성을 최소화하기 위해 사용률이 낮은 기간으로 백업 기간을 예약하는 것이 좋습니다.
서버 측에서 연결이 종료되는 경우
기본 ElastiCache (Redis OSS) 구성은 클라이언트 연결을 무기한으로 설정합니다. 그러나 경우에 따라 연결 종료가 필요할 수 있습니다. 예:
클라이언트 애플리케이션의 버그로 인해 연결이 손실되고 유휴 상태로 설정이 유지될 수 있습니다. 이것을 “연결 누수“라고 하며 결과적으로
CurrConnections지표에서 관찰되는 설정된 연결의 수가 지속적으로 증가합니다. 이 동작은 클라이언트 또는 ElastiCache 측에서 포화될 수 있습니다. 클라이언트 측에서 즉각적인 수정이 불가능한 경우 일부 관리자는 ElastiCache 파라미터 그룹에서 “타임아웃” 값을 설정합니다. 시간 초과는 유휴 연결이 지속되도록 허용된 기간(초)입니다. 클라이언트가 해당 기간에 요청을 제출하지 않으면 Redis OSS 엔진은 연결이 제한 시간에 도달하는 즉시 연결을 종료합니다. 시간 초과 값이 작으면 불필요한 연결 끊기가 발생할 수 있으며 클라이언트가 연결을 올바르게 처리하고 다시 연결해야 하므로 지연이 발생합니다.키를 저장하는 데 사용되는 메모리는 클라이언트 버퍼와 공유됩니다. 크기가 큰 요청이나 응답이 있는 느린 클라이언트는 버퍼를 처리하기 위해 상당한 양의 메모리를 요구할 수 있습니다. 기본 ElastiCache (Redis OSS) 구성은 일반 클라이언트 출력 버퍼의 크기를 제한하지 않습니다.
maxmemory제한에 도달하면 엔진은 버퍼 사용량을 충족하기 위해 항목을 제거하려고 시도합니다. 메모리가 매우 낮은 조건에서는 ElastiCache (Redis OSS)가 대용량 클라이언트 출력 버퍼를 사용하는 클라이언트의 연결을 해제하여 메모리를 확보하고 클러스터의 상태를 유지할 수 있습니다.사용자 지정 구성으로 클라이언트 버퍼의 크기를 제한할 수 있으며 이 제한에 도달한 클라이언트는 연결이 끊어집니다. 그러나 클라이언트는 예기치 않은 연결 해제를 처리할 수 있어야 합니다. 일반 클라이언트의 버퍼 크기를 처리하는 파라미터는 다음과 같습니다.
client-query-buffer-limit: 단일 입력 요청의 최대 크기
client-output-buffer-limit-normal-soft-limit: 클라이언트 연결에 대한 소프트 제한입니다. 가 에 정의된 시간보다 초 이상 소프트 제한을 초과 client-output-buffer-limitnormal-soft-seconds 하거나 하드 제한에 도달하면 연결이 종료됩니다.
client-output-buffer-limit-normal-soft-seconds: client-output-buffer-limit-를 초과하는 연결에 허용되는 시간normal-soft-limit
client-output-buffer-limit-normal-hard-limit: 이 제한에 해당하는 연결이 즉시 종료됩니다.
일반 클라이언트 버퍼 외에도, 다음 옵션은 복제본 노드 및 Pub/Sub(게시/구독) 클라이언트에 대한 버퍼를 제어합니다.
client-output-buffer-limit-replica-hard-limit;
client-output-buffer-limit-replica-soft-seconds;
client-output-buffer-limit-replica-hard-limit;
client-output-buffer-limit-pubsub-soft-limit;
client-output-buffer-limit-pubsub-soft-seconds;
client-output-buffer-limit-pubsub-hard-limit;
Amazon EC2 인스턴스에 대한 클라이언트 측 문제 해결
클라이언트 측의 로드 및 응답성도 에 대한 요청에 영향을 미칠 수 있습니다 ElastiCache. EC2 간헐적인 연결 또는 제한 시간 문제를 해결하는 동안 인스턴스 및 운영 체제 제한을 주의 깊게 검토해야 합니다. 관찰할 몇 가지 핵심 사항:
CPU:
EC2 인스턴스 CPU 사용량: CPU 이 포화되지 않았거나 100%에 가깝지 않은지 확인합니다. 과거 분석은 를 통해 수행할 수 CloudWatch있지만 데이터 포인트 세분화는 1분(세부 모니터링 활성화됨) 또는 5분이라는 점에 유의하세요.
버스트 가능한 EC2 인스턴스를 사용하는 경우 CPU 크레딧 잔고가 고갈되지 않았는지 확인하세요. 이 정보는
CPUCreditBalanceCloudWatch 지표에서 확인할 수 있습니다.사용량이 많으면 의 100% 사용률을 반영하지 않고 시간 초과가 발생할 CPU 수 있습니다 CloudWatch. 이러한 경우에는
top,ps및mpstat같은 운영 체제 도구를 사용하여 실시간 모니터링을 수행해야 합니다.
네트워크
네트워크 처리량이 인스턴스 용량에 따라 허용 가능한 값 이하인지 확인합니다. 자세한 내용은 Amazon EC2 인스턴스 유형을 참조하세요
. enaEnhanced Network 드라이버를 사용하는 인스턴스의 경우 ena statistics에서 시간 초과 또는 제한 초과를 확인합니다. 다음 통계는 네트워크 제한 도달 상태를 확인하는 데 유용합니다.bw_in_allowance_exceeded/bw_out_allowance_exceeded: 과도한 인바운드 또는 아웃바운드 처리량으로 인해 형성된 패킷 수conntrack_allowance_exceeded: 보안 그룹 연결 추적 제한으로 인해 삭제된 패킷 수. 이 제한에 도달하면 새 연결이 실패합니다.linklocal_allowance_exceeded: VPC 를 NTP 통해 인스턴스 메타데이터에 대한 과도한 요청으로 인해 삭제된 패킷 수입니다DNS. 이 제한은 모든 서비스에 대해 초당 1024패킷입니다.pps_allowance_exceeded: 과도한 초당 패킷 수 비율로 인해 손실된 패킷 수. 네트워크 트래픽이 초당 수천 개 또는 수백만 개의 매우 작은 요청으로 구성된 경우 PPS 제한이 발생할 수 있습니다. ElastiCache 트래픽은MGET대신 와 같이 한 번에 여러 작업을 수행하는 파이프라인 또는 명령을 통해 네트워크 패킷을 더 잘 사용하도록 최적화할 수 있습니다GET.
단일 요청을 완료하는 데 걸리는 시간 분석
네트워크에서:
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 OSSPING명령을 와 함께 사용하면 다음과 같은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으로)가 필요했습니다.
