조용한 개발 노트

API가 느려졌을 때 로그를 보면 자주 등장하는 단어들이 있습니다.타임아웃, 재시도, 그리고 원인을 특정하기 어려운 지연.이 상황에서 가장 쉽게 떠올리는 대응은 보통 이렇습니다.“요청이 실패했으니 한 번 더 보내면 되지 않을까?”하지만 네트워크에서는 이 선택이 지연을 줄이기보다는 지연을 더 키우는 방향으로 작동하는 경우가 많습니다.1. 패킷 손실은 예외가 아니라 전제다많은 시스템은 “네트워크는 안정적이다”라는 가정 위에서 설계됩니다.하지만 안정적이라는 말은 패킷 손실이 전혀 없다는 의미가 아닙니다.순간적인 트래픽 증가, 라우터 큐 포화, 커널 스케줄링 지연 등으로 소량의 패킷 손실은 언제든 발생할 수 있습니다.중요한 것은 손실 자체보다, TCP가 손실을 어떻게 해석하고 반응하는지입니다.2. TCP는 손실..

API 응답이 느릴 때, 가장 먼저 확인하는 것은 보통 코드와 쿼리입니다.하지만 코드와 쿼리가 문제가 아닌 상황에서도 지연은 반복됩니다.이때 많은 경우 원인은 요청을 처리하기 전에 이미 지불한 비용에 있습니다.바로 TCP 연결입니다.1. 요청 하나는 생각보다 많은 일을 한다HTTP 요청 하나를 보낼 때, 애플리케이션은 단순히 데이터를 전송하지 않습니다.연결이 없다면, 먼저 연결부터 만들어야 합니다.클라이언트가 서버에 연결 요청을 보낸다서버가 이를 받아 응답한다클라이언트가 다시 확인 응답을 보낸다이 과정을 TCP 3-way handshake라고 부릅니다.중요한 점은 이 과정이 최소 1 RTT를 소모한다는 사실입니다.RTT가 30ms면 30ms, 100ms면 100ms가 요청 처리 이전에 이미 소비됩니다.2..

API 응답이 갑자기 느려졌습니다.CPU 사용률은 낮고, GC 로그도 깨끗합니다. 쿼리 플랜을 다시 봐도 이상한 점은 없습니다.이럴 때 백엔드 엔지니어가 가장 자주 듣는 말은 보통 이겁니다.“네트워크 문제인 것 같습니다.”하지만 막상 네트워크를 보려고 하면 애매해집니다. 패킷을 직접 보자는 얘기도 아니고, 단순히 핑 몇 번 찍어본다고 해결될 문제도 아닙니다.이 글은 이런 상황에서 자주 나오는 질문,“네트워크는 도대체 왜 느려지는 걸까?”에 답하기 위해 시작합니다.1. 느림은 대부분 애플리케이션 밖에서 발생한다백엔드 요청 하나의 응답 시간을 단순화하면 다음 두 덩어리로 나눌 수 있습니다.서버 내부 시간 - CPU 실행, GC, 락 대기, 쿼리, 직렬화/역직렬화네트워크 시간 - 연결, 전송, 대기, 재전송,..