[Linux 성능 분석] Day 5: 네트워크와 종합 진단 - 패킷 손실에서 원인까지

서론: 오늘의 문제

네트워크 문제는 연결 실패, 지연, 처리량 저하로 다르게 나타난다. 소켓, TCP, 인터페이스와 애플리케이션 timeout을 한 타임라인에 놓고 안전한 사건 대응 절차를 완성한다.

1. 연결과 대기열

listen backlog와 accept queue가 넘치면 새 연결이 지연되거나 실패한다. 연결 수뿐 아니라 SYN 상태, accept 속도와 애플리케이션 event loop 지연을 함께 본다.

2. 재전송과 손실

TCP retransmit 증가는 네트워크 손실, 혼잡, 수신 측 처리 지연을 모두 의심하게 한다. 인터페이스 drop과 경로별 지연, 특정 peer 집중 여부로 범위를 좁힌다.

3. 소켓 버퍼와 처리량

큰 대역폭·긴 지연 경로에서는 window와 버퍼가 처리량을 제한할 수 있다. 무조건 최대값을 키우기 전에 동시 연결 수가 만드는 총 메모리 비용을 계산한다.

4. DNS와 연결 풀

DNS 지연이나 오래된 endpoint가 애플리케이션 네트워크 장애처럼 보일 수 있다. resolve, connect, TLS, first byte 시간을 구간별로 계측하고 풀의 실패 연결 제거 정책을 확인한다.

5. 증거 보존과 변경

사건 중 명령 결과와 시간, 호스트, namespace를 기록한다. 한 번에 한 변수만 바꾸고 변경 전후 핵심 지표를 비교해 임시 완화와 근본 해결을 분리한다.

6. 자주 실패하는 방식

패킷 캡처에 자격 증명과 개인정보가 포함될 수 있으므로 접근과 보존을 통제해야 한다. sysctl을 여러 개 동시에 바꾸면 효과와 부작용을 구분할 수 없다.

7. 관측과 검증

connect 오류, SYN/accept queue, retransmit, interface drop, DNS 지연, socket memory, 구간별 요청 지연을 사건 타임라인에 맞춘다. 기준값은 정상 시간대와 변경 전후를 비교해 정하고, 점검 결과가 실제 행동으로 이어지는지 정기적으로 확인한다.

실행 흐름

1. 연결과 대기열
   ↓
2. 재전송과 손실
   ↓
3. 소켓 버퍼와 처리량
   ↓
4. DNS와 연결 풀
   ↓
5. 증거 보존과 변경

개별 도구보다 이 순서를 팀의 설계 리뷰와 Runbook에 남기는 것이 중요하다. 상황이 달라져도 판단 근거와 검증 결과가 이어져야 한다.

실전 체크리스트

• 연결과 대기열: 기준과 책임자를 문서화했다.
• 재전송과 손실: 기준과 책임자를 문서화했다.
• 소켓 버퍼와 처리량: 기준과 책임자를 문서화했다.
• DNS와 연결 풀: 기준과 책임자를 문서화했다.
• 증거 보존과 변경: 기준과 책임자를 문서화했다.
• 실패 패턴을 재현하고 안전한 복구 경로를 확인했다.
• 핵심 신호를 대시보드와 변경 검증에 연결했다.

참고 자료

• Linux PSI Documentation
• Linux cgroup v2

시리즈 마무리

이번 연재에서 다룬 원칙을 실제 시스템의 설계·배포·운영 흐름에 연결해 반복 가능한 기준으로 만들자.