조용한 개발 노트

지금까지의 편들은 모두 하나의 사실로 수렴합니다.네트워크 지연은 운영 중에만 생기는 문제가 아니라, 설계에서 이미 결정된다는 점입니다.지연을 완전히 제거할 수는 없습니다.하지만 지연이 장애로 번지지 않게 설계하는 것은 가능합니다.이 마지막 편에서는 네트워크 지연을 전제로 한 설계에서 무엇을 미리 결정해야 하는지를 정리합니다.1. “빠름”이 아니라 “지연 가능성”을 기준으로 설계한다설계 단계에서 흔히 묻는 질문은 이것입니다.“평균 응답 시간은 얼마나 나올까?”하지만 더 중요한 질문은 다음입니다.“이 요청이 느려질 수 있는 지점은 어디인가?”DNS, 연결 생성, TLS, 로드 밸런서, 큐잉.요청 경로를 단계별로 나누고, 각 단계가 느려졌을 때의 영향을 먼저 상상해야 합니다.2. 요청 경로를 짧게 유지한다요청..

지연이 발생하면 가장 먼저 손대는 설정은 보통 타임아웃과 재시도입니다.값을 조금 줄이거나, 재시도를 한 번 더 추가합니다.하지만 이 선택은 문제를 해결하기도 하고, 반대로 장애를 더 빠르게 키우기도 합니다.이 편에서는 타임아웃과 재시도가 언제 도움이 되고, 언제 위험해지는지를 요청 흐름 기준으로 정리합니다.1. 타임아웃은 실패를 만들기 위한 장치다타임아웃의 목적은 요청을 성공시키는 것이 아닙니다.더 이상 기다리지 않겠다는 선언에 가깝습니다.즉, 타임아웃은 시스템을 빠르게 만들기 위한 장치가 아니라, 실패를 언제 인정할지 결정하는 기준입니다.이 전제를 놓치면, 타임아웃 값은 항상 “짧을수록 좋다”는 방향으로 흐릅니다.2. 타임아웃은 요청 경로 전체를 포함해야 한다요청 하나가 끝나기까지의 시간은 단일 지점에..

처음에는 단순한 지연으로 시작합니다.응답이 조금 느려지고, p99가 튀기 시작합니다.하지만 시간이 지나면 상황은 달라집니다.타임아웃이 늘고, 재시도가 증가하며, 결국 서비스 전체가 흔들립니다.이 편에서는 작은 네트워크 지연이 어떻게 연쇄 장애로 확장되는지를 요청 흐름 기준으로 정리합니다.1. 지연은 실패보다 먼저 전파된다시스템은 실패에는 비교적 강합니다.하지만 지연에는 훨씬 취약합니다.실패는 즉시 감지되고 처리되지만, 지연은 정상 요청처럼 보이기 때문입니다.요청은 살아 있다연결은 끊기지 않았다단지 응답이 늦을 뿐이다이 때문에 지연은 조용히 쌓이고, 임계점을 넘는 순간 한꺼번에 문제를 드러냅니다.2. 느린 요청은 자원을 오래 점유한다요청 하나가 느려지면, 그 요청이 사용하는 자원도 더 오래 묶입니다.스레드..

트래픽이 늘어나면 가장 먼저 떠올리는 해법은 보통 로드 밸런서입니다.하지만 로드 밸런서는 단순히 요청을 분산하는 장치가 아닙니다.요청이 어디를 거쳐 가고, 어디서 지연이 만들어지는지를 이해하지 못하면, 로드 밸런서는 문제를 해결하기보다 숨기는 역할을 하기도 합니다.1. 로드 밸런서는 요청 경로에 들어온다클라이언트에서 서버로 가는 요청은 대개 한 번에 목적지로 도달하지 않습니다.대부분의 환경에서는 다음과 같은 경로를 거칩니다.클라이언트로드 밸런서백엔드 서버즉, 로드 밸런서는 요청 경로의 한가운데에 존재합니다.이 말은 곧, 로드 밸런서의 동작 방식이 전체 지연에 직접적인 영향을 준다는 뜻입니다.2. L4와 L7은 처리 단위가 다르다로드 밸런서는 크게 L4와 L7로 나뉩니다.L4 - IP와 포트를 기준으로 트..

HTTPS는 이제 선택이 아니라 기본입니다.대부분의 서비스는 TLS 위에서 동작하고, 평소에는 그 존재를 거의 의식하지 않습니다.하지만 지연을 추적하다 보면, TLS가 요청 처리 이전에 꽤 많은 일을 하고 있다는 사실을 마주하게 됩니다.이 편에서는 TLS가 어떤 비용을 요구하고, 그 비용이 언제 지연으로 드러나는지를 정리합니다.1. TLS는 요청을 보내기 전에 끝나야 한다TLS는 HTTP 요청을 보내기 전에 연결의 안전성을 먼저 합의해야 합니다.이 과정에는 다음 단계가 포함됩니다.암호 스위트 협상서버 인증서 검증키 교환즉, TLS handshake가 끝나기 전에는 애플리케이션 데이터는 한 바이트도 전송되지 않습니다.이 과정은 추가 RTT를 요구합니다.2. TLS handshake는 생각보다 무겁다TLS ..

요청이 느려질 때 흔히 보는 설정 중 하나가 Keep-Alive입니다.HTTP/2를 쓰면 빨라진다는 이야기도 자주 듣습니다.하지만 왜 이 설정들이 필요한지, 그리고 무엇을 해결하려는 것인지는 명확하지 않은 경우가 많습니다.이 편에서는 연결을 계속 유지하는 선택이 왜 지연 문제를 완화하는지부터 정리합니다.1. 매 요청마다 연결을 만드는 구조의 문제Keep-Alive가 없으면, 요청 하나마다 다음 작업이 반복됩니다.DNS 조회TCP 연결 생성TLS handshake요청 전송연결 종료이 흐름은 단순하지만, 지연 관점에서는 가장 비싼 선택입니다.2편에서 다뤘듯이, TCP 연결 자체가 이미 RTT 비용을 포함합니다.여기에 TLS까지 얹히면, 요청 처리 이전에 이미 상당한 시간이 소비됩니다.2. Keep-Alive..

API 지연을 추적하다 보면 가끔 납득하기 어려운 상황을 만납니다.코드도, 쿼리도, 네트워크 경로도 크게 변한 게 없는데 특정 시점부터 요청이 느려집니다.이때 로그나 트레이스를 조금 더 들여다보면 의외로 요청을 보내기 전 단계에서 시간이 소비되고 있는 경우가 있습니다.바로 DNS입니다.1. DNS 조회는 생각보다 자주 발생한다DNS는 보통 “처음 한 번만” 일어나는 작업처럼 인식됩니다.하지만 실제로는 훨씬 다양한 지점에서 반복적으로 발생합니다.새로운 TCP 연결을 만들 때커넥션 풀이 비어 있을 때기존 연결이 끊어진 뒤 재연결할 때TTL이 만료되었을 때즉, 연결이 많아지고 재시도가 늘어날수록 DNS 조회 역시 함께 늘어날 가능성이 큽니다.2. DNS는 네트워크 경로 밖에 있다DNS는 실제 요청을 보내는 네..

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, 락 대기, 쿼리, 직렬화/역직렬화네트워크 시간 - 연결, 전송, 대기, 재전송,..