측정과 문제 해결

지연의 네 가지 원인

패킷 하나가 라우터 하나를 지나 다음 라우터에 닿기까지 걸리는 시간은 네 조각의 합이다.

• 처리 지연(processing delay): 라우터가 헤더를 읽고, 오류를 검사하고, 어느 포트로 보낼지 정하는 시간. 요즘 전용 칩(17장)에서는 수 µs 이하다.
• 큐잉 지연(queuing delay): 나가는 포트 앞에서 먼저 온 패킷들이 다 나갈 때까지 줄 서서 기다리는 시간. 0일 수도, 수백 ms일 수도 있는 가장 변덕스러운 성분이다.
• 전송 지연(transmission delay): 패킷의 모든 비트를 선로에 밀어 넣는 시간 = 패킷 크기 ÷ 링크 속도. 1,500바이트를 10 Mbps로 내보내면 1.2 ms, 100 Gbps면 0.12 µs.
• 전파 지연(propagation delay): 신호가 선로를 따라 실제로 이동하는 시간 = 거리 ÷ 전파 속도. 광섬유 속 빛은 초당 약 20만 km(5장)이라 1,000 km에 5 ms. 돈으로도 줄일 수 없는 물리 한계다.

ping: RTT, 지터, 손실

가장 오래되고 가장 많이 쓰는 측정 도구가 ping이다. 상대에게 ICMP Echo Request(“들리나요?”)를 보내고 Echo Reply가 돌아오기까지의 왕복 시간(RTT)을 잰다. 세 가지를 읽는다.

• RTT의 바닥(min): 큐가 비었을 때의 값으로, 거리(전파 지연)와 경로를 반영한다. 서울 안이면 수 ms, 미국 서부까지 약 130 ms 수준.
• 지터(jitter): RTT가 들쭉날쭉한 정도. 큐가 찼다 비었다 하는 신호다. 영상 통화·게임은 평균보다 지터에 더 민감해서, 수신 측은 지터만큼 버퍼를 두고 재생을 늦춘다.
• 패킷 손실(packet loss): 돌아오지 않은 비율. 유선이라면 0%가 정상이고, 1%만 넘어도 TCP 처리율이 크게 떨어진다(9장). 다만 라우터가 ICMP를 일부러 덜 처리하는 경우도 있어 ping 손실이 곧 데이터 손실은 아니다.

traceroute로 길 읽기

8장에서 본 traceroute는 IP 헤더의 TTL(남은 홉 수)을 이용한다. TTL=1로 보낸 패킷은 첫 라우터에서 0이 되어 버려지고, 그 라우터가 “시간 초과(ICMP Time Exceeded)”를 돌려준다. 그 답장의 출발지가 첫 홉의 주소다. TTL을 2, 3, …으로 늘려 가며 길목의 라우터를 하나씩 드러낸다. 홉마다 3번씩 보내서 RTT 세 개를 보여 준다.

• 별표(*): 시간 안에 답이 없었다는 뜻이다. 그 라우터가 보안 정책상 ICMP를 보내지 않거나 속도를 제한하는 경우가 대부분이다. 다음 홉이 정상으로 나오면 그 자리는 무시해도 된다. 반대로 어느 홉부터 끝까지 전부 *라면 거기서 패킷이 막히고 있을 가능성이 크다.
• 큰 점프: 지연이 한 홉에서 크게 늘고 이후 홉에서도 계속 유지되면(6번 홉) 그 구간이 실제로 길다는 뜻이다. 대양 횡단이나 멀리 돌아가는 경로다.
• 중간 홉만 튀는 착시: 7번 홉만 200 ms이고 그다음 홉들이 다시 140 ms라면 그 라우터가 느린 것이 아니다. 라우터는 패킷 전달은 전용 칩으로 빠르게 하지만, 자기에게 온 ICMP 답장 만들기는 느린 제어용 CPU가 낮은 우선순위로 처리한다. 끝까지 유지되는 지연만 진짜다.
• 비대칭 경로: traceroute는 가는 길만 보여 준다. 돌아오는 길은 다를 수 있어(8장의 BGP 정책) 양쪽에서 재 봐야 할 때가 있다. 지연과 손실을 홉별로 계속 집계하는 mtr도 많이 쓴다.

대역폭-지연 곱: 파이프에 담긴 데이터

링크를 물이 흐르는 파이프로 생각하자. 대역폭은 파이프의 굵기, RTT는 길이(왕복)다. 파이프를 가득 채우는 데 필요한 데이터 양이 대역폭-지연 곱(BDP, bandwidth-delay product)이다. TCP(9장)는 확인 응답을 받기 전에 윈도우만큼만 보낼 수 있으므로, 윈도우가 BDP보다 작으면 파이프에 빈틈이 생겨 회선을 다 쓰지 못한다.

원래 TCP 헤더의 윈도우 필드는 16비트라 최대 65,535바이트(약 64 KB)였다. 1980년대 회선에는 충분했지만 지금은 턱없이 작아서, 윈도우 크기 조정 옵션(window scaling)으로 최대 1 GB까지 늘린다. 지금도 오래된 장비나 잘못된 설정이 이 옵션을 지우면 “회선은 1 Gbps인데 해외 다운로드가 몇 Mbps”라는 증상이 나온다.

큐와 버퍼블로트

패킷은 제멋대로 몰려온다. 평균 도착률이 처리 능력보다 낮아도 잠깐 몰리는 순간에는 줄이 생긴다. 이 줄의 길이를 다루는 수학이 큐잉 이론(queueing theory)이다. 가장 단순한 모델인 M/M/1(무작위 도착, 무작위 처리 시간, 창구 하나)에서 도착률을 λ, 처리율을 μ라 하면 이용률 ρ = λ/μ이고, 패킷이 시스템에 머무는 평균 시간은 다음과 같다.

그래서 망 운영자는 링크를 평균 100% 가까이 쓰지 않는다. 출퇴근길 도로가 80%만 차도 막히기 시작하는 것과 같다. 백본 회선은 보통 평균 이용률이 50~70%를 넘으면 증설을 검토한다.

버퍼블로트: 너무 큰 버퍼의 역설

패킷 손실을 줄이겠다며 공유기·모뎀에 메모리를 넉넉히 넣으면 어떻게 될까? TCP는 손실이 나야 속도를 줄이므로(9장), 큰 버퍼를 끝까지 채운다. 버퍼가 늘 가득하니 그 뒤에 선 모든 패킷이 수백 ms씩 기다린다. 큰 파일을 올리는 동안 같은 집의 게임 핑이 20 ms에서 500 ms로 치솟는 현상, 이것이 버퍼블로트(bufferbloat)다. 2010년경 짐 게티스가 이름을 붙였다.

해결책은 버퍼를 무작정 줄이는 것이 아니라 지연을 보고 관리하는 것이다. 이를 AQM(Active Queue Management)이라 한다. 대표인 CoDel은 패킷이 큐에서 머문 시간을 재서, 최소 체류 시간이 100 ms 동안 계속 5 ms를 넘으면 패킷을 하나씩 일부러 버린다. TCP가 이를 보고 속도를 살짝 줄여 큐가 짧게 유지된다. FQ-CoDel은 여기에 흐름별 큐를 더해, 대용량 업로드와 게임 패킷이 같은 줄에 서지 않게 한다. 리눅스의 기본 큐 관리 방식이고, 많은 공유기 펌웨어와 DOCSIS 3.1 케이블 모뎀(AQM 필수)에 들어갔다.

QoS: 줄 세우기와 속도 제한

모든 패킷이 같지는 않다. 0.1초 늦으면 끊기는 음성 패킷과, 1초 늦어도 아무도 모르는 백업 패킷을 같은 줄에 세울 이유가 없다. QoS(Quality of Service)는 트래픽을 분류해 다르게 대우하는 기술의 묶음이다.

1. 분류와 표시: IP 헤더의 6비트 DSCP(Differentiated Services Code Point) 필드에 등급을 적는다. 음성은 보통 EF(46, 신속 전달), 일반 웹은 0(최선형)이다.
2. 우선순위 큐: 높은 등급의 큐가 비어 있지 않으면 그것부터 내보낸다. 음성처럼 작고 급한 트래픽에 좋지만, 무제한이면 낮은 큐가 굶는다.
3. 가중 공정 큐잉(WFQ): 큐마다 가중치를 주고 대역폭을 비율대로 나눈다(예: 영상 50%, 업무 30%, 나머지 20%). 아무도 굶지 않는다.
4. 속도 제한: 정해진 속도를 넘는 트래픽을 버리거나(폴리싱) 늦춰서(셰이핑) 내보낸다. 통신사 요금제의 속도 제한, 클라우드 API의 요청 수 제한이 이 방식이다. 핵심 알고리즘이 토큰 버킷(token bucket)이다.

패킷 캡처와 증상 읽기

측정 도구로도 원인이 안 보이면 실제 패킷을 들여다본다. 패킷 캡처(packet capture)는 네트워크 카드를 지나는 패킷을 그대로 복사해 저장하는 것이다. 명령줄 도구 tcpdump는 필터 문법(tcpdump -i eth0 port 53)으로 원하는 패킷만 골라 pcap 파일로 저장하고, 그래픽 도구 와이어샤크(Wireshark)는 수천 개 프로토콜을 3장처럼 계층별로 풀어 보여 준다. TCP 재전송, 중복 ACK, 0 윈도우 같은 이상 신호를 자동으로 색칠해 주기도 한다.

시간 초과와 즉시 거부의 차이는 중요한 단서다. 포트에 연결했는데 곧바로 “Connection refused”(TCP RST)가 오면 상대 컴퓨터까지는 닿았지만 그 포트에서 듣는 프로그램이 없다는 뜻이다. 아무 답 없이 시간 초과가 나면 중간의 방화벽이 패킷을 조용히 버리고 있을 가능성이 크다.

아래 계층부터: 장애 추적

경험 많은 엔지니어는 “인터넷이 안 돼요”를 들으면 계층(3장)을 아래에서 위로 하나씩 확인한다. 위 계층은 아래 계층이 멀쩡해야만 동작하므로, 아래에서 처음 실패하는 지점이 원인일 가능성이 가장 크다. 각 단계는 하나의 질문에 답한다.

모니터링: 가용성, SLO, 백분위

장애가 난 뒤에 고치는 것보다 미리 아는 것이 낫다. 운영팀은 장비와 서비스의 상태를 계속 재서 그래프로 보고, 기준을 넘으면 알림을 받는다. 핵심 지표는 세 가지다.

• 가용성(22장): 서비스가 정상인 시간의 비율. “나인(9)의 개수”로 말한다. 99.9%(쓰리 나인)는 1년에 약 8.76시간, 99.99%는 약 52.6분, 99.999%는 약 5.3분만 멈춰도 된다는 뜻이다.
• SLO(Service Level Objective): 팀이 스스로 정한 목표. “한 달 동안 요청의 99.9%가 300 ms 안에 성공한다” 같은 형식이다. 남은 허용치(0.1%)를 오류 예산이라 부르며, 예산이 남으면 새 기능을 과감히 배포하고 바닥나면 안정화에 집중한다. 고객과 계약으로 맺어 어기면 보상하는 것은 SLA다.
• 백분위 지연(percentile latency): 평균 대신 p50(중앙값), p99(가장 느린 1%의 경계)를 본다. 평균 50 ms라도 p99가 2초라면 100명 중 1명은 매번 답답하다. 웹 페이지 하나가 요청 수십 개로 이루어지면, 그중 하나라도 느린 꼬리에 걸릴 확률이 높아서 p99가 체감 속도를 좌우한다.

시스템이 여러 부품으로 이루어지면 가용성은 곱셈으로 계산한다. 하나라도 멈추면 전체가 멈추는 직렬 구성은 가용성이 곱해져 낮아지고(99.9% 두 개 → 99.8%), 하나만 살아 있어도 되는 병렬(이중화) 구성은 “둘 다 고장 날 확률”만 남아 크게 높아진다(99% 두 개 → 1 − 0.01² = 99.99%).