기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
추가 문제 해결 단계
지속적 연결 문제를 해결하는 동안 다음 항목을 확인해야 합니다 ElastiCache.
주제
보안 그룹
보안 그룹은 ElastiCache 클라이언트 (EC2 인스턴스, AWS Lambda 함수, Amazon ECS 컨테이너 등) 와 캐시를 보호하는 가상 방화벽입니다. ElastiCache 보안 그룹은 상태 유지(stateful) 방식으로 작동합니다. 즉, 들어오거나 나가는 트래픽이 허용되면 해당 트래픽에 대한 응답이 관련 보안 그룹의 컨텍스트에서 자동으로 승인됩니다.
상태 유지 기능을 사용하려면 보안 그룹이 권한이 부여된 모든 연결을 추적해야 하며, 이렇게 추적되는 연결에는 제한이 있습니다. 이 제한에 도달하면 새 연결이 실패합니다. 클라이언트 또는 측에서 한도에 도달했는지 확인하는 방법에 대한 도움말은 문제 해결 섹션을 참조하십시오. ElastiCache
클라이언트와 ElastiCache 클러스터에 단일 보안 그룹을 동시에 할당하거나 각각에 대해 개별 보안 그룹을 할당할 수 있습니다.
두 경우 모두 소스에서 나오는 ElastiCache 포트의 TCP 아웃바운드 트래픽과 동일한 포트의 인바운드 트래픽을 허용해야 합니다. ElastiCache 기본 포트는 Memcached의 경우 11211, Redis의 경우 6379입니다. 기본적으로 보안 그룹은 모든 아웃바운드 트래픽을 허용합니다. 이 경우 대상 보안 그룹의 인바운드 규칙만 필요합니다.
자세한 내용은 Amazon VPC의 ElastiCache 클러스터에 액세스하기 위한 액세스 패턴을 참조하십시오.
네트워크 ACL
네트워크 액세스 제어 목록(ACL)은 무상태 규칙입니다. 트래픽이 성공하려면 양방향(인바운드 및 아웃바운드)으로 허용되어야 합니다. 네트워크 ACL은 특정 리소스가 아닌 서브넷에 할당됩니다. 특히 클라이언트 리소스가 동일한 서브넷에 있는 경우 동일한 ElastiCache ACL과 클라이언트 리소스를 할당할 수 있습니다.
기본적으로 네트워크 ACL은 모든 트래픽을 허용합니다. 그러나 트래픽을 거부하거나 허용하도록 네트워크 ACL을 사용자 지정할 수 있습니다. 또한 ACL 규칙의 평가는 순차적입니다. 즉, 트래픽과 일치하는 가장 빠른 번호의 규칙이 트래픽을 허용하거나 거부합니다. Redis 트래픽을 허용하는 최소 구성은 다음과 같습니다.
클라이언트 측 네트워크 ACL:
인바운드 규칙:
규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.
유형: 사용자 지정 TCP 규칙
프로토콜: TCP
포트 범위: 1024-65535
소스: 0.0.0.0/0 (또는 클러스터 서브넷에 대한 개별 규칙 생성) ElastiCache
허용/거부: 허용
아웃바운드 규칙:
규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.
유형: 사용자 지정 TCP 규칙
프로토콜: TCP
포트 범위: 6379
소스: 0.0.0.0/0 (또는 클러스터 서브넷) ElastiCache 특정 IP를 사용하면 장애 조치 또는 클러스터 규모 조정 시 문제가 발생할 수 있다는 점에 유의하세요.
허용/거부: 허용
ElastiCache 네트워크 ACL:
인바운드 규칙:
규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.
유형: 사용자 지정 TCP 규칙
프로토콜: TCP
포트 범위: 6379
출처: 0.0.0.0/0 (또는 클러스터 서브넷에 대한 개별 규칙 생성) ElastiCache
허용/거부: 허용
아웃바운드 규칙:
규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.
유형: 사용자 지정 TCP 규칙
프로토콜: TCP
포트 범위: 1024-65535
소스: 0.0.0.0/0 (또는 클러스터 서브넷) ElastiCache 특정 IP를 사용하면 장애 조치 또는 클러스터 규모 조정 시 문제가 발생할 수 있다는 점에 유의하세요.
허용/거부: 허용
자세한 내용은 네트워크 ACL을 참조하세요.
라우팅 테이블
네트워크 ACL과 마찬가지로 각 서브넷에는 서로 다른 라우팅 테이블이 있을 수 있습니다. 클라이언트와 ElastiCache 클러스터가 서로 다른 서브넷에 있는 경우 라우팅 테이블을 통해 서로 연결할 수 있는지 확인하십시오.
여러 VPC, 동적 라우팅 또는 네트워크 방화벽이 관련된 복잡한 환경에서는 문제 해결이 어려울 수 있습니다. 네트워크 연결 검증 섹션을 참조하여 네트워크 설정이 적절한지 확인하세요.
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 사용량: Redis는 다중 스레드 애플리케이션입니다. 그러나 각 명령의 실행은 단일(주) 스레드에서 발생합니다. 이러한 이유로
CPUUtilization메트릭과EngineCPUUtilization를 ElastiCache 제공합니다.EngineCPUUtilizationRedis 프로세스 전용 CPU 사용률과 모든CPUUtilizationvCPU의 사용량을 제공합니다. 두 개 이상의 vCPU가 있는 노드는 대개CPUUtilization및EngineCPUUtilization의 값이 서로 다르며, 일반적으로 두 번째 값이 더 큽니다. 높은EngineCPUUtilization값은 많은 수의 요청이나 완료하는 데 상당한 양의 CPU 시간이 필요한 복잡한 작업으로 인해 발생할 수 있습니다. 다음을 사용하여 둘 모두를 식별할 수 있습니다.많은 수의 요청:
EngineCPUUtilization패턴과 일치하는 다른 지표의 증가 여부를 확인합니다. 유용한 지표는 다음과 같습니다.CacheHits및CacheMisses: 성공한 요청 또는 캐시에서 유효한 항목을 찾지 못한 요청의 수입니다. 적중률에 비해 누락률이 높으면 애플리케이션에서 무의미한 요청에 시간과 리소스를 낭비하고 있는 것입니다.SetTypeCmds및GetTypeCmds:EngineCPUUtilization과 상관 관계가 있는 이 두 지표는SetTypeCmds에 의해 측정되는 쓰기 요청 또는GetTypeCmds에 의해 측정되는 읽기 요청에 대한 로드가 얼마나 높은지 파악하는 데 도움이 될 수 있습니다 로드가 주로 읽기인 경우 여러 읽기 전용 복제본을 사용하면 여러 노드에 요청을 분산시켜 균형을 유지하고 기본 노드를 쓰기용으로 할당할 수 있습니다. 클러스터 모드가 비활성화된 클러스터에서는 리더 엔드포인트를 사용하여 애플리케이션에서 추가 연결 구성을 생성하여 읽기 전용 복제본을 사용할 수 있습니다. ElastiCache 자세한 내용은 연결 엔드포인트 찾기를 참조하세요. 읽기 작업은 이 추가 연결에 제출되어야 합니다. 쓰기 작업은 일반적인 기본 엔드포인트를 통해 수행됩니다. 클러스터 모드가 활성화된 클러스터에서는 기본적으로 읽기 전용 복제본을 지원하는 라이브러리를 사용하는 것이 좋습니다. 올바른 플래그를 사용하면 라이브러리가 클러스터 토폴로지와 복제본 노드를 자동으로 검색하고, READONLYRedis 명령을 통해 읽기 작업을 활성화하고, 복제본에 읽기 요청을 제출할 수 있습니다.
많은 수의 연결:
CurrConnections및NewConnections:CurrConnection은 데이터 포인트 컬렉션 순간에 설정된 연결 수이고,NewConnections는 이 기간에 생성된 연결 수를 보여줍니다.연결 생성 및 처리에서는 상당한 CPU 오버헤드가 발생합니다. 또한 새 연결을 생성하는 데 필요한 TCP 3방향 핸드셰이크는 전체 응답 시간에 부정적인 영향을 미칩니다.
ElastiCache 노드가
NewConnections분당 수천 개라는 것은 몇 개의 명령만으로 연결이 생성되고 사용된다는 것을 나타내며, 이는 최적이 아닙니다. 설정된 연결을 유지하고 새 작업에 이 연결을 다시 사용하는 것이 모범 사례입니다. 이것이 가능하려면 클라이언트 애플리케이션이 연결 풀링이나 영구 연결을 지원하고 적절하게 구현해야 합니다. 연결 풀링을 사용하는 경우currConnections수에는 큰 변화가 없으며NewConnections는 가능한 낮아야 합니다. Redis는 작은 수의 currConnections에서 최적의 성능을 제공합니다. currConnections를 대략 수십 개나 수백 개로 유지하면 클라이언트 버퍼와 같은 개별 연결을 지원하기 위한 리소스 사용량과 연결을 제공하기 위한 CPU 사이클을 최소화할 수 있습니다.
네트워크 처리량:
대역폭 결정: ElastiCache 노드의 네트워크 대역폭은 노드 크기에 비례합니다. 애플리케이션마다 특성이 다르기 때문에 워크로드에 따라 결과가 달라질 수 있습니다. 예를 들어 크기가 작은 요청의 비율이 높은 애플리케이션은 네트워크 처리량보다 CPU 사용량에 더 많은 영향을 미치는 경향이 있으며, 키가 커질수록 네트워크 사용률도 높아집니다. 그러므로 제한을 보다 정확하게 이해하기 위해 실제 워크로드로 노드를 테스트하는 것이 좋습니다.
애플리케이션의 로드를 시뮬레이션하면 보다 정확한 결과를 얻을 수 있습니다. 그러나 벤치마크 도구가 제한에 대한 좋은 아이디어를 줄 수 있습니다.
요청이 주로 읽기인 경우 읽기 작업에 복제본을 사용하면 기본 노드의 로드가 줄어듭니다. 사용 사례가 주로 쓰기인 경우 많은 복제본을 사용하면 네트워크 사용량이 크게 늘어납니다. 기본 노드에 한 바이트가 쓰여질 때마다 N바이트가 복제본으로 전송됩니다. 여기서 N은 복제본 수입니다. 쓰기 집약적 워크로드의 모범 사례는 클러스터 모드가 활성화된 Redis를 사용하여 ElastiCache 여러 샤드에 걸쳐 쓰기를 분산하거나 더 많은 네트워크 기능을 갖춘 노드 유형으로 확장할 수 있는 Redis를 사용하는 것입니다.
CloudWatchmetrics
NetworkBytesIn및 는 각각 노드로 들어오거나 나가는 데이터의 양을NetworkBytesOut제공합니다.ReplicationBytes데이터 복제 전용 트래픽입니다.
자세한 정보는 네트워크 관련 제한 사항을 참조하세요.
복잡한 명령: Redis 명령은 단일 스레드에서 제공되므로 요청이 순차적으로 제공됩니다. 단일 느린 명령은 다른 요청 및 연결에 영향을 줄 수 있으며 시간 초과로 이어질 수 있습니다. 여러 값, 키 또는 데이터 유형에 작동하는 명령을 사용할 때 신중하게 사용해야 합니다. 연결은 파라미터의 수나 입력 또는 출력 값의 크기에 따라 차단되거나 종료될 수 있습니다.
악명 높은 예는
KEYS명령입니다. 이 명령은 전체 키스페이스에 걸쳐 주어진 패턴을 검색하며, 실행 중에 다른 명령의 실행을 차단합니다. Redis는 “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외에도, 올바르게 사용하지 않으면 잠재적인 문제를 일으킬 수 있는 여러 다른 명령이 있습니다. 모든 명령의 목록과 각각의 시간 복잡도를 보려면 https://redis.io/commands로 이동하세요. 잠재적 문제의 예:
Lua 스크립트: Redis는 서버 측에서 스크립트를 실행할 수 있도록 임베디드 Lua 인터프리터를 제공합니다. Redis의 Lua 스크립트는 엔진 수준에서 실행되며 정의에 따라 원자적입니다. 즉, 한 스크립트가 실행되는 동안 다른 명령이나 스크립트가 실행될 수 없습니다. Lua 스크립트는 Redis 엔진에서 직접 다중 명령, 의사 결정 알고리즘, 데이터 구문 분석 등을 실행할 수 있는 길을 열어줍니다. 스크립트의 원자성과 애플리케이션을 오프로드할 수 있는 기능은 유혹적이지만 스크립트는 작은 작업에 신중하게 사용해야 합니다. ElastiCache에서는 Lua 스크립트의 실행 시간이 5초로 제한됩니다. 키스페이스에 기록되지 않은 스크립트는 5초 후에 자동으로 종료됩니다. 데이터 손상 및 불일치를 방지하기 위해 스크립트 실행이 5초 내에 완료되지 않았고 실행 중에 쓰기가 있는 경우 노드가 장애 조치됩니다. 트랜잭션
은 Redis에서 여러 관련 키 수정 사항의 일관성을 보장하는 다른 방법입니다. 트랜잭션을 사용하면 명령 블록을 실행하여 기존 키의 수정을 감시할 수 있습니다. 트랜잭션이 완료되기 전에 감시된 키가 변경되면 모든 수정 사항이 무시됩니다. 항목의 일괄 삭제:
DEL명령에는 삭제할 키 이름에 해당하는 파라미터 여러 개를 사용할 수 있습니다. 삭제 작업은 동기식이며 파라미터 목록이 크거나 큰 목록, 집합, 정렬된 집합 또는 해시(여러 하위 항목을 포함하는 데이터 구조)가 포함된 경우 상당한 CPU 시간을 소비합니다. 즉, 단일 키를 삭제하는 경우에도 요소가 많은 경우 상당한 시간이 걸릴 수 있습니다.DEL의 대안은 Redis 4부터 사용할 수 있는 비동기 명령인UNLINK입니다. 가능한 경우 항상DEL대신UNLINK를 사용해야 합니다. Redis 6x부터 이lazyfree-lazy-user-del매개 변수를 사용하면DEL명령이 활성화되었을 때와 같이UNLINK동작합니다. ElastiCache 자세한 내용은 Redis 6.0 파라미터 변경 사항 섹션을 참조하세요.여러 키에 작동하는 명령:
DEL은 이전에 여러 인수를 허용하는 명령으로 언급되었으며 실행 시간은 이에 직접적으로 비례합니다. 그러나 Redis는 유사하게 작동하는 많은 다른 명령을 제공합니다. 예를 들면MSET및MGET를 사용하면 한 번에 여러 문자열 키를 삽입하거나 검색할 수 있습니다. 이러한 명령을 사용하면 개별SET또는GET명령을 여러 번 사용할 때 발생하는 네트워크 대기 시간을 줄일 수 있습니다. 그러나 파라미터의 광범위한 목록은 CPU 사용량에 영향을 미칩니다.CPU 사용률만으로는 연결 문제의 원인이라고 할 수 없지만 여러 키에 대해 하나 또는 몇 개의 명령을 처리하는 데 너무 많은 시간이 소비되면 다른 요청이 실패하고 전반적인 CPU 사용률이 높아질 수 있습니다.
키의 수와 해당 크기는 명령의 복잡도, 결과적으로 완료 시간에 영향을 미칩니다.
여러 키에 작동할 수 있는 다른 명령의 예에는
HMGET,HMSET,MSETNX,PFCOUNT,PFMERGE,SDIFF,SDIFFSTORE,SINTER,SINTERSTORE,SUNION,SUNIONSTORE,TOUCH,ZDIFF,ZDIFFSTORE,ZINTER,ZINTERSTORE등이 있습니다.여러 데이터 유형에 작동하는 명령: Redis는 데이터 유형에 관계없이 하나 이상의 키에 작동하는 명령도 제공합니다. ElastiCache for Redis는 이러한 명령을
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는 크기와 사용된 명령에 따라 처리하는 데 상당한 시간이 걸릴 수 있습니다. 이러한 명령에 대한 자세한 내용은 https://redis.io/commands
를 참조하세요.
네트워크 연결 검증
DNS 확인, 보안 그룹, 네트워크 ACL 및 라우팅 테이블과 관련된 네트워크 구성을 검토한 후 VPC Reachability Analyzer 및 시스템 도구를 사용하여 연결을 검증할 수 있습니다.
Reachability Analyzer는 네트워크 연결을 테스트하고 모든 요구 사항 및 권한이 충족되는지 확인합니다. 아래 테스트에는 VPC에서 사용할 수 있는 ElastiCache 노드 중 하나의 ENI ID (엘라스틱 네트워크 인터페이스 식별) 가 필요합니다. 다음을 수행하여 이 ID를 찾을 수 있습니다.
ElastiCache 클러스터 이름 또는 이전 DNS 검증에서 가져온 IP 주소를 기준으로 인터페이스 목록을 필터링합니다.
ENI ID를 적어 두거나 따로 저장하세요. 여러 인터페이스가 표시되는 경우 설명을 검토하여 해당 인터페이스가 올바른 ElastiCache 클러스터에 속하는지 확인하고 그 중 하나를 선택합니다.
다음 단계를 진행합니다.
https://console.aws.amazon.com/vpc/home? ReachabilityAnalyzer #에서
분석 경로를 생성하고 다음 옵션을 선택합니다. 소스 유형: ElastiCache 클라이언트가 Amazon EC2 인스턴스에서 실행되는 경우 인스턴스를 선택하고, 다른 서비스 (예: awsvpc 네트워크를 사용하는 AWS Fargate Amazon ECS 등) 및 해당 리소스 ID (EC2 인스턴스 또는 ENI ID) 를 사용하는 경우 네트워크 인터페이스를 선택합니다. AWS Lambda
대상 유형: 네트워크 인터페이스를 선택하고 목록에서 ElastiCache ENI를 선택합니다.
대상 포트: Redis의 경우 6379, Memcached의 경우 ElastiCache 11211을 지정합니다. ElastiCache 이러한 포트는 기본 구성으로 정의된 포트이며 이 예에서는 포트가 변경되지 않는다고 가정합니다.
프로토콜: TCP
분석 경로를 생성하고 결과를 몇 분 정도 기다립니다. 상태가 연결할 수 없음인 경우 분석 세부 정보를 열고 분석 탐색기에서 요청이 차단된 위치에 대한 자세한 정보를 검토합니다.
연결성 테스트가 통과되면 OS 수준에서 확인을 진행합니다.
ElastiCache 서비스 포트에서 TCP 연결을 확인하는 방법: Amazon Linux에서는 패키지로 Nping nmap 제공되며 포트에서 TCP 연결을 테스트할 수 있을 뿐만 아니라 연결을 설정하는 데 필요한 네트워크 왕복 시간을 제공할 수 있습니다. ElastiCache 이를 사용하여 다음과 같이 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숫자가 너무 높으면 연결 요청을 처리하는 동안 시스템에 과부하가 걸릴 수 있습니다. 연결 처리를 개선하려면 연결 풀링이나 지속적인 연결과 같은 기술을 구현하는 것이 좋습니다. 가능한 경우 항상 연결 풀을 구성하여 최대 연결 수를 수백 개로 제한합니다. 또한 문제가 발생할 경우 연결 이탈을 방지하려면 시간 초과 또는 기타 연결 예외를 처리하는 백오프 로직이 필요합니다.
네트워크 트래픽 제한: Redis에 대한 다음 CloudWatch 지표를 확인하여 노드에서 발생할 수 있는 네트워크 한도를 식별하십시오. ElastiCache
NetworkBandwidthInAllowanceExceeded/NetworkBandwidthOutAllowanceExceeded: 처리량이 집계된 대역폭 제한을 초과하여 형성된 네트워크 패킷입니다.기본 노드에 한 바이트가 쓰여질 때마다 N개 복제본으로 복제됩니다. 여기서 N은 복제본 수입니다. 노드 유형이 작고, 여러 개의 복제본이 있으며 많은 쓰기 요청이 있는 클러스터는 복제 백로그를 처리하지 못할 수 있습니다. 이러한 경우 확장(노드 유형 변경), 스케일 아웃(클러스터 모드가 활성화된 클러스터에 샤드 추가), 복제본 수를 줄이기 또는 쓰기 수 최소화를 수행하는 것이 모범 사례입니다.
NetworkConntrackAllowanceExceeded: 노드에 할당된 모든 보안 그룹에서 추적되는 최대 연결 수를 초과했기 때문에 형성되는 패킷입니다. 이 기간 동안 새 연결이 실패할 가능성이 높습니다.NetworkPackets PerSecondAllowanceExceeded: 초당 최대 패킷 수를 초과했습니다. 매우 크기가 작은 요청의 비율이 높은 워크로드는 최대 대역폭 전에 이 제한에 도달할 수 있습니다.
위의 지표는 네트워크 제한에 도달한 노드를 확인하는 이상적인 방법입니다. 그러나 제한은 네트워크 지표의 안정기로 식별할 수도 있습니다.
안정기가 오랜 기간 동안 관찰되면 이후에 복제 지연, 캐시에 사용되는 바이트 수 증가, 여유 메모리 하락, 높은 스왑 및 CPU 사용량이 뒤따를 가능성이 높습니다. 또한 Amazon EC2 인스턴스에는 ENA 드라이버 지표를 통해 추적할 수 있는 네트워크 제한이 있습니다. 향상된 네트워킹 지원과 ENA 드라이버 2.2.10 이상을 사용하는 Linux 인스턴스에서는 다음 명령을 사용하여 제한 카운터를 검토할 수 있습니다.
# ethtool -S eth0 | grep "allowance_exceeded"
CPU 사용량
CPU 사용량 지표는 조사의 출발점이며, 다음 항목은 ElastiCache 측면에서 발생할 수 있는 문제의 범위를 좁히는 데 도움이 될 수 있습니다.
Redis 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위의 이벤트는 UTC 기준으로 12월 26일 19:26:07에 발생했고 완료하는 데 4.8초(4,823밀리초)가 걸렸으며 클라이언트 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 for Redis는 다양한 명령 클래스의 평균 지연 시간을 모니터링하는 CloudWatch 지표를 제공합니다. 데이터 포인트는 한 범주에 속하는 명령의 총 실행 횟수를 해당 기간의 총 실행 시간으로 나누어 계산합니다. 대기 시간 지표의 결과는 여러 명령의 집계임을 이해하는 것이 중요합니다. 단일 명령을 사용하면 지표에 큰 영향을 주지 않으며 시간 초과와 같은 예기치 않은 결과가 발생할 수 있습니다. 이러한 경우 느리 로그 이벤트가 보다 정확한 정보 소스가 될 수 있습니다. 다음 목록에는 사용 가능한 대기 시간 지표와 이에 영향을 주는 각 명령이 나와 있습니다.
EvalBasedCmdsLatency: Lua 스크립트 명령 관련,,;
evalevalshaGeoSpatialBasedCmdsLatency:
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: 다양한 데이터 유형에 사용할 수 있는 명령:
dumpexists,keys,object,pttl,randomkey,ttl,typedel,expire,expireat,move,persist,pexpire,pexpireat,renamerenamenx,restoreK,sort,unlink,ListBasedCmdsLatency: 인덱스, 렌즈, 오렌지, 블팝, 브로퍼, 브로플푸시, 인서트, 루프, 푸시, 플럭스, lem, ltrim, rpop, rpush, rpush, rpush, rpush, rpush
PubSubBasedCmdsLatency: 구독, 게시, 게시, 구독 취소, 구독 취소
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 런타임 명령:
info commandstats: Redis 엔진이 시작된 이후 실행된 명령, 누적 실행 횟수, 총 실행 시간 및 명령당 평균 실행 시간으로 구성된 목록을 제공합니다.
client list: 현재 연결된 클라이언트와 버퍼 사용량, 마지막으로 실행된 명령 등과 같은 관련 정보의 목록을 제공합니다.
백업 및 복제: ElastiCache 2.8.22 이전의 Redis 버전에서는 포크 프로세스를 사용하여 백업을 생성하고 복제본과의 전체 동기화를 처리합니다. 이 방법은 쓰기 집약적인 사용 사례에서 상당한 메모리 오버헤드가 발생시킬 수 있습니다.
ElastiCache Redis 2.8.22부터 포크 없는 백업 및 복제 방법이 도입되었습니다. AWS 새로운 방법은 실패를 방지하기 위해 쓰기를 지연시킬 수 있습니다. 두 방법 모두 CPU 사용률을 높일 수 있고 응답 시간이 길어지게 만들 수 있으므로 실행 중에 클라이언트 시간 초과가 발생할 수 있습니다. 백업 기간 중에 클라이언트 장애가 발생하거나 이 기간 중에
SaveInProgress지표가 1이었는지 항상 확인하세요. 클라이언트 문제 또는 백업 실패의 가능성을 최소화하기 위해 사용률이 낮은 기간으로 백업 기간을 예약하는 것이 좋습니다.
서버 측에서 연결이 종료되는 경우
Redis 구성의 기본값은 ElastiCache 클라이언트 연결을 무기한 설정된 상태로 유지합니다. 그러나 경우에 따라 연결 종료가 필요할 수 있습니다. 예:
클라이언트 애플리케이션의 버그로 인해 연결이 손실되고 유휴 상태로 설정이 유지될 수 있습니다. 이것을 “연결 누수“라고 하며 결과적으로
CurrConnections지표에서 관찰되는 설정된 연결의 수가 지속적으로 증가합니다. 이 동작으로 인해 클라이언트 또는 측에서 포화 상태가 발생할 수 있습니다. ElastiCache 클라이언트 측에서 즉각적인 수정이 불가능한 경우 일부 관리자는 ElastiCache 파라미터 그룹에 “timeout” 값을 설정합니다. 시간 초과는 유휴 연결이 지속되도록 허용된 기간(초)입니다. 클라이언트가 이 기간 동안 요청을 제출하지 않으면 Redis 엔진은 연결이 시간 초과 값에 도달하는 즉시 연결을 종료합니다. 시간 초과 값이 작으면 불필요한 연결 끊기가 발생할 수 있으며 클라이언트가 연결을 올바르게 처리하고 다시 연결해야 하므로 지연이 발생합니다.키를 저장하는 데 사용되는 메모리는 클라이언트 버퍼와 공유됩니다. 크기가 큰 요청이나 응답이 있는 느린 클라이언트는 버퍼를 처리하기 위해 상당한 양의 메모리를 요구할 수 있습니다. Redis 구성의 기본값은 ElastiCache 일반 클라이언트 출력 버퍼의 크기를 제한하지 않습니다.
maxmemory제한에 도달하면 엔진은 버퍼 사용량을 충족하기 위해 항목을 제거하려고 시도합니다. 메모리가 극도로 부족한 상황에서 ElastiCache for Redis는 메모리를 확보하고 클러스터의 상태를 유지하기 위해 대용량 클라이언트 출력 버퍼를 사용하는 클라이언트의 연결을 끊을 수 있습니다.사용자 지정 구성으로 클라이언트 버퍼의 크기를 제한할 수 있으며 이 제한에 도달한 클라이언트는 연결이 끊어집니다. 그러나 클라이언트는 예기치 않은 연결 해제를 처리할 수 있어야 합니다. 일반 클라이언트의 버퍼 크기를 처리하는 파라미터는 다음과 같습니다.
client-query-buffer-limit: 단일 입력 요청의 최대 크기
client-output-buffer-limit-normal-soft-limit: 클라이언트 연결의 소프트 리밋. 에 정의된 시간 (초) 보다 오랫동안 소프트 한도를 normal-soft-seconds 초과하거나 하드 제한에 client-output-buffer-limit 도달하면 연결이 종료됩니다.
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 확인할 수 있습니다.짧은 기간 동안 CPU 사용량이 높으면 사용률 100% 를 반영하지 않고 시간 초과가 발생할 수 있습니다 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 DNS를 통한 NTP에 대한 과도한 요청으로 인해 손실된 패킷 수. 이 제한은 모든 서비스에 대해 초당 1024패킷입니다.pps_allowance_exceeded: 과도한 초당 패킷 수 비율로 인해 손실된 패킷 수. 네트워크 트래픽이 초당 수천 또는 수백만 개의 매우 작은 요청으로 구성된 경우 PPS 제한에 도달할 수 있습니다. ElastiCache 대신 여러 작업을 한 번에 수행하는 파이프라인이나 명령을 통해 네트워크 패킷을 더 잘 활용하도록 트래픽을 최적화할 수 있습니다.MGETGET
단일 요청을 완료하는 데 걸리는 시간 분석
On the network:
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위의 출력에서 TCP 3방향 핸드셰이크가 완료되는 데 222마이크로초(918091 - 917869)가 걸렸고 ping 명령이 제출되어 반환되는 데 173마이크로초(918295 - 918122)가 걸렸음을 확인할 수 있습니다.
요청부터 연결을 닫는 데까지 438마이크로초(918307 - 917869)가 걸렸습니다. 이러한 결과를 통해 네트워크 및 엔진 응답 시간이 양호하다고 확신할 수 있으며 조사를 다른 구성 요소에 집중할 수 있습니다.
운영 체제에서
Strace를 사용하여 OS 수준의 시간 간격을 식별할 수 있습니다. 실제 애플리케이션의 분석에는 보다 광범위하고 전문화된 애플리케이션 프로파일러 또는 디버거를 사용하는 것이 좋습니다. 다음 예제에서는 기본 운영 체제 구성 요소가 예상대로 작동하는지 여부만 보여 주며, 예상대로 작동하지 않는 경우 추가 조사가 필요할 수 있습니다.strace와 함께 동일한 RedisPING명령을 사용하여 얻은 결과:$ 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를 인스턴스화하고 이름을 확인하는 데 약 20밀리초(697712에서 717890)의 상당한 시간이 걸렸으며, 그 후에 TCP 소켓을 생성하는 데 2밀리초(745659에서 747858), 요청을 제출하고 응답을 받는 데 0.4밀리초(747858에서 748330)가 필요했습니다.
