Pod 네트워크 실측 벤치마크 퀴즈

문항은 2026년 9월 2일 기록을 기준으로 하며 보편적인 성능·과금 보장을 뜻하지 않습니다.

1. ping -c 200 -i 0.05로 측정한 Pod 간 RTT 평균은 같은 노드 → 같은 AZ의 다른 노드 → 다른 AZ 순서로 어떻게 나타났나요?
   • A) 0.040 ms → 0.544 ms → 0.339 ms — 다른 AZ가 같은 AZ보다 빨랐다
   • B) 세 경로 모두 0.3 ms 안팎으로 차이가 없었다
   • C) 이 실행에서는 0.040 ms → 0.339 ms → 0.544 ms로, 인접 배치 간 차이가 약 +0.30 ms와 +0.21 ms였다
   • D) 0.040 ms → 0.339 ms → 5.4 ms — AZ 경계가 RTT를 밀리초 단위로 늘렸다

정답 보기

정답: C) 이 실행에서는 0.040 ms → 0.339 ms → 0.544 ms로, 인접 배치 간 차이가 약 +0.30 ms와 +0.21 ms였다

설명: ping 평균은 경로마다 200회, 손실 0/200의 기록입니다. 다른 AZ − 같은 AZ는 0.205 ms로 약 0.21 ms, 다른 AZ − 같은 노드는 0.504 ms입니다. HTTP p50은 0.259 → 0.461 → 0.704 ms였습니다. HTTP 중앙값과 ping 평균을 빼서 유저 공간 비용을 분리할 수는 없습니다. 5.4 ms는 부하 중 TCP RTT이며 큐 위치는 측정하지 않았습니다. 별도 Istio 문서의 +1.29 ms는 다른 하드웨어·부하의 시나리오 전체 p50 차이이지 이 값에 더할 프록시 하나의 비용이 아닙니다.

2. iperf3 단일 TCP 스트림(-P 1)은 같은 AZ와 다른 AZ 모두 4.96 Gbps에서 멈췄고, 8 스트림(-P 8)에서는 두 경로 모두 9.94 Gbps가 나왔습니다. 이 두 숫자를 가장 잘 설명하는 것은?
   • A) 4.96 Gbps는 클라이언트 CPU 한 코어의 포화 때문이고, 8 스트림은 코어를 더 쓰기 때문에 빨라졌다
   • B) 일반적인 단일 플로우 5 Gbps 한도에 4.96 Gbps가 부합하고, 병렬 플로우는 이 m5.xlarge의 10 Gbps 버스트 피크에 접근했다
   • C) 4.96 Gbps는 m5.xlarge의 베이스라인 대역폭이고, 8 스트림에서 버스트 크레딧을 써서 피크에 도달했다
   • D) MTU 9001 점보 프레임이 단일 스트림에서는 비활성이었기 때문이다

정답 보기

정답: B) 일반적인 단일 플로우 5 Gbps 한도에 4.96 Gbps가 부합하고, 병렬 플로우는 이 m5.xlarge의 10 Gbps 버스트 피크에 접근했다

설명: m5.xlarge의 베이스라인은 1.25 Gbps, best-effort 버스트 피크는 10 Gbps이며 20초 실행으로 지속 피크를 보장할 수는 없습니다. 노드 간 클라이언트 프로세스 CPU는 19.5% / 20.0%, 같은 노드 29.97 Gbps 단일 플로우에서는 99.8%였습니다. 대역폭 한도 해석을 뒷받침하지만 모든 호스트 병목을 배제하지는 않습니다. 재전송은 4 / 2에서 5,874 / 5,979로 늘었지만 ENA 카운터를 수집하지 않아 셰이핑을 입증하지 못했습니다. AWS는 클러스터 배치 그룹 내부 최대 10 Gbps, 지원되는 같은 AZ ENA Express 플로우 최대 25 Gbps도 설명하므로 5 Gbps를 보편적인 한도로 단정하면 안 됩니다.

3. 8개 플로우 iperf3가 두 경로에서 모두 9.94 Gbps였는데 고정 풀 HTTP 처리량이 달랐던 결과를 어떻게 해석해야 하나요?
   • A) AZ 간 링크가 요청/응답 트래픽에는 대역폭을 절반으로 제한하기 때문에
   • B) 다른 AZ 경로에서 요청 오류가 늘어 재시도가 발생했기 때문에
   • C) srv-b가 있는 노드의 CPU가 srv-a 노드보다 느렸기 때문에
   • D) 평균 약 16개 요청이 진행 중인 정상상태 폐루프에서 처리량 ≈ 16 / 평균 지연과 부합한다. 관측 요청률 차이는 33.5%이며 보편적인 AZ 페널티를 입증하지는 않는다

정답 보기

정답: D) 평균 약 16개 요청이 진행 중인 정상상태 폐루프에서 처리량 ≈ 16 / 평균 지연과 부합한다. 관측 요청률 차이는 33.5%이며 보편적인 AZ 페널티를 입증하지는 않는다

설명: 기록된 평균 지연은 0.355 / 0.415 / 0.624 ms입니다. 16을 각 시간으로 나누면 45,070 / 38,554 / 25,641 qps로 실측 44,991 / 38,507 / 25,602에 가깝습니다. (38,507 − 25,602) / 38,507 ≈ 33.5%입니다. Little의 법칙은 명시한 정상상태의 동시성·처리량·평균 시간 관계이며 지연의 단독 원인을 특정하지 않습니다. 원문은 오류 0건과 동일 인스턴스 타입을 기록하므로 B·C의 근거는 없습니다. 같은 노드의 꼬리 지연에 CPU 경합이 기여했을 수 있지만 프로파일링으로 입증하지 않았습니다.

4. 같은 100 qps / 커넥션 4개 조건에서 -keepalive=false(요청마다 새 TCP 커넥션)로 바꾸자 다른 AZ 경로의 HTTP p50이 어떻게 변했나요?
   • A) 0.704 ms → 1.517 ms(+0.813 ms)로 두 배 이상이었다. 연결 수립이 작업을 추가하지만 이 실험은 구성 요소별 비용을 분리하지 않았다
   • B) 변화 없음 — 커널이 커넥션을 재사용하기 때문에
   • C) 0.704 ms → 0.813 ms로 소폭 증가
   • D) p50은 그대로였고 p99만 나빠졌다

정답 보기

정답: A) 0.704 ms → 1.517 ms(+0.813 ms)로 두 배 이상이었다. 연결 수립이 작업을 추가하지만 이 실험은 구성 요소별 비용을 분리하지 않았다

설명: keepalive를 끈 중앙값은 0.664 / 1.079 / 1.517 ms, 증가분은 0.405 / 0.618 / 0.813 ms입니다. 마지막 숫자는 새 중앙값이 아니라 증가분이므로 C는 틀렸습니다. 연결 수립이 기여하지만 ping RTT를 뺀 나머지가 고정 0.3 ms 소켓 비용이라고 독립 측정한 것은 아닙니다. 애플리케이션에서 연결 재사용 효과를 시험할 수 있습니다. TIME_WAIT는 측정하지 않았으며 종료 주체와 연결 종료 방식에 따라 달라집니다.

5. 원문이 명시한 십진 GB 환산과 EC2 양 끝의 $0.01/GB를 적용하면 페이로드 223,376,179,200바이트의 모델 추정값은 얼마인가요?
   • A) $0 — 같은 리전 안의 트래픽은 무료다
   • B) $2.23 — GB당 $0.01이 한 번 부과된다
   • C) 원문의 십진 GB 페이로드 모델에서 송신·수신 양 끝에 $0.01/GB를 적용한 약 $4.47이며, 실제 청구서는 확인하지 않았다
   • D) 베이스라인 1.25 Gbps 이하 구간은 무료이고 버스트 구간만 과금된다

정답 보기

정답: C) 원문의 십진 GB 페이로드 모델에서 송신·수신 양 끝에 $0.01/GB를 적용한 약 $4.47이며, 실제 청구서는 확인하지 않았다

설명: 정확한 페이로드는 223,376,179,200바이트입니다. 과거 모델은 10⁹으로 나눈 뒤 $0.01을 두 번 적용해 약 $4.47을 계산합니다. AZ 간 iperf3 세 실행은 합계 260,633,264,128바이트로 같은 모델에서 약 $5.21입니다. 한 방향 페이로드에도 양 끝 과금이 가능하지만 공개 get-products 가격은 계정의 실제 청구액이 아닙니다. 이번 감사에서는 EC2 과금 단위가 십진 페이로드 GB와 같다는 근거를 확보하지 못했습니다. CUR 계량 단위·프로토콜 오버헤드·양 끝·할인을 대조해야 합니다. 18개 구간의 9.92–9.94 Gbps 결과가 베이스라인 전송 무료 구간을 만들지는 않습니다.

6. 기본 ndots:5 Pod(glibc 2.41)에서 sts.ap-northeast-2.amazonaws.com(점 3개)을 한 번 콜드 resolve할 때 tcpdump에 잡힌 DNS 쿼리 수와 NXDOMAIN 응답 수는?
   • A) 쿼리 2개, NXDOMAIN 0개 — 점이 3개라 바로 절대 이름으로 질의된다
   • B) 기록된 조회에서는 쿼리 10개와 NXDOMAIN 8개였다. 실패한 search 후보 4개에 각각 A+AAAA를 질의하고 절대 이름에서 성공했다
   • C) 쿼리 5개, NXDOMAIN 4개 — 후보마다 A 레코드 하나만 보낸다
   • D) 쿼리 4개, NXDOMAIN 2개

정답 보기

정답: B) 기록된 조회에서는 쿼리 10개와 NXDOMAIN 8개였다. 실패한 search 후보 4개에 각각 A+AAAA를 질의하고 절대 이름에서 성공했다

설명: 이 Pod는 기록된 search 목록 4개와 glibc AF_UNSPEC 동작을 사용했습니다. 앞 후보 4개가 실패해 NXDOMAIN 8개를 만든 뒤 절대 이름의 A 10.0.3.84 / 10.0.2.129를 받았습니다. 4.37 ms는 A 응답까지이며 프로세스 첫 호출 전체가 아닙니다. 표에는 AAAA 완료 시간이 없습니다. 웜 중앙값은 3.78 ms, 끝점 사용 시 0.80 ms였습니다. cache 30은 최대 TTL이며 업스트림 조회가 없었다는 증거가 아닙니다. 같은 응답 패턴에서 1,000조회/s는 10,000쿼리/s와 NXDOMAIN 8,000개가 되지만 CoreDNS CPU 80%라는 뜻은 아닙니다. kubernetes.default처럼 먼저 성공하면 4쿼리만 필요할 수 있습니다.

7. 같은 ndots:5 Pod에서 FQDN처럼 보이는 kubernetes.default.svc.cluster.local(끝에 점 없음)을 resolve하자 역시 쿼리 10개·NXDOMAIN 8개가 나왔습니다. 왜 search 목록을 다 돌았을까요?
   • A) CoreDNS의 kubernetes 플러그인은 cluster.local 존 밖의 이름만 즉시 응답하기 때문에
   • B) glibc가 svc.cluster.local로 끝나는 이름은 항상 Service 이름으로 간주하기 때문에
   • C) .ap-northeast-2.compute.internal 접미사가 search 목록 맨 앞에 있어서 먼저 시도되기 때문에
   • D) 점 4개는 ndots 5보다 작아 리졸버가 search 후보를 먼저 시도했다. 이 후보들이 실패한 뒤 원래 이름에서 성공했고, 끝점을 붙인 조회는 search 확장을 생략했다

정답 보기

정답: D) 점 4개는 ndots 5보다 작아 리졸버가 search 후보를 먼저 시도했다. 이 후보들이 실패한 뒤 원래 이름에서 성공했고, 끝점을 붙인 조회는 search 확장을 생략했다

설명: 리졸버는 점을 세며 Kubernetes Service 접미사를 search 생략 지시로 해석하지 않습니다. 이 표본에서는 확장 후보 4개가 모두 실패했습니다. 원문은 포워딩 후보 2.2 ms, 해당 패킷 walk 5.6 ms, 끝점 없는 웜 중앙값 3.63 ms와 끝점 사용 시 0.46 ms를 기록하며, 별도의 프로세스 첫 호출 값은 7.40 ms였습니다. 끝점은 DNS 이름을 절대 이름으로 만들지만 애플리케이션 URL에 사용할 때는 Host/SNI·인증서·서명 처리가 호환되어야 합니다. 모든 HTTPS나 AWS SDK 엔드포인트 설정에서 안전하다고 가정하면 안 됩니다.

8. dnsConfig.options로 ndots:1을 준 Pod에서는 외부 이름 쿼리가 10 → 2개로 줄었지만, 짧은 인클러스터 이름 kubernetes.default는 오히려 나빠졌습니다(쿼리 6개·NXDOMAIN 4개, 중앙값 2.04 ms vs ndots:5의 1.71 ms). 무슨 일이 있었나요?
   • A) ndots:1에서 점 1개인 이름을 먼저 절대 이름으로 질의한 뒤 NXDOMAIN을 받아 search 목록으로 폴백했고, 그 내부 이름이 업스트림에 노출되었다
   • B) ndots:1에서는 CoreDNS 캐시가 비활성화되기 때문에
   • C) kubernetes.default는 ndots:1에서는 전혀 resolve되지 않았다
   • D) glibc가 A와 AAAA를 순차적으로 보내기 때문에 두 배 느려졌다

정답 보기

정답: A) ndots:1에서 점 1개인 이름을 먼저 절대 이름으로 질의한 뒤 NXDOMAIN을 받아 search 목록으로 폴백했고, 그 내부 이름이 업스트림에 노출되었다

설명: 관측 순서는 kubernetes.default.(포워딩 후 기록상 1.6 ms에 NXDOMAIN), kubernetes.default.bench-net.svc.cluster.local(NXDOMAIN), kubernetes.default.svc.cluster.local(172.20.0.1)입니다. 따라서 6쿼리/NXDOMAIN 4개이며 ndots:5에서는 4개/2개였습니다. ndots는 클라이언트 조회 순서를 바꾸며 CoreDNS 캐시 활성화 여부를 바꾸지 않습니다. 당시 glibc 조회는 A/AAAA 쌍을 사용했지만 주소 패밀리와 리졸버 옵션에 따라 달라집니다. ndots:1에서 전체 Service 이름은 실패한 절대 이름 시도를 줄입니다. 끝점은 search를 생략할 뿐 모든 리졸버·장애 상황에서 특정 쿼리 수나 지연을 보장하지 않습니다.

9. 기록된 Fortio -r 0.00001 재측정을 올바르게 해석한 것은?
   • A) 첫 실행에서 오류율이 높았기 때문에
   • B) 원문은 비교하려는 지연에 기본 최소 버킷 해상도 1 ms가 거칠어 10 µs로 다시 측정했다. 단일 버킷이라고 p50이 항상 0.5 ms인 것은 아니다
   • C) 기본 해상도에서는 fortio가 p99.9를 계산하지 않기 때문에
   • D) 첫 실행이 실수로 keepalive 없이 돌았기 때문에

정답 보기

정답: B) 원문은 비교하려는 지연에 기본 최소 버킷 해상도 1 ms가 거칠어 10 µs로 다시 측정했다. 단일 버킷이라고 p50이 항상 0.5 ms인 것은 아니다

설명: Fortio 1.69.5에서 -r은 초 단위로, 최소 버킷의 0.001은 1 ms, 0.00001은 10 µs입니다. 큰 버킷은 폭이 넓어질 수 있습니다. 분위수는 버킷 경계 안에서 보간하며 관측 최소·최대값이 처음과 마지막 버킷에 반영됩니다. 따라서 원문의 “1 ms 미만이면 모두 p50 = 0.5 ms”는 잘못된 주장입니다. keepalive 중앙값 0.259–0.704 ms는 1 ms 미만이지만 일부 꼬리 값과 새 연결 중앙값은 1 ms를 넘습니다. 재실행 이력과 평균·전체 히스토그램·오류 수를 보존하고 보간 자체가 무의미하다고 단정하지 마세요.

10. 과거 애플리케이션 벤치마크가 Service/트래픽 분산 비교를 생략한 이유는?

• A) fortio가 Service DNS 이름을 대상으로 지원하지 않기 때문에
• B) kube-proxy가 IPVS 모드라 iptables 홉이 존재하지 않았기 때문에
• C) 기록에 따르면 실패한 LBC admission 웹훅이 벤치마크의 Service 생성 요청을 거부했다. 이를 우회하지 않고 애플리케이션 테스트에 Pod IP를 사용했다
• D) 측정했지만 Pod IP와 차이가 없어 표에서 생략했다

정답 보기

정답: C) 기록에 따르면 실패한 LBC admission 웹훅이 벤치마크의 Service 생성 요청을 거부했다. 이를 우회하지 않고 애플리케이션 테스트에 Pod IP를 사용했다

설명: 과거 진단 기록은 LBC v3.2.1, replica 2개, 48일 CrashLoopBackOff, 9,250회 재시작과 no matches for kind "ListenerSet" in version "gateway.networking.k8s.io/v1", 약 2분 18초 뒤 캐시 동기화 타임아웃을 설명합니다. 이는 귀속을 명시한 사건 기록이며 이번 감사에서 원시 로그를 복구하거나 실제 클러스터를 조회하지 않았습니다. 실패한 failurePolicy: Fail 웹훅은 rules·selector·condition에 매칭되는 요청을 거부합니다. namespaceSelector: {}만으로 모든 Service CREATE가 가로채진다고 입증할 수 없습니다. 애플리케이션 벤치마크는 Service를 생략했지만 DNS는 기존 kube-dns를 사용했습니다. 현재 PreferClose는 PreferSameZone의 폐기 예정 별칭이며 둘 다 여기서 시험하지 않았습니다. ENA 카운터와 독립 반복 측정도 없습니다.

---

학습 자료로 돌아가기 | 네트워킹 홈으로