조용한 개발 노트

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

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

[gRPC 공식 문서 정리] Load Balancing & Name Resolution: 기본 설정부터 운영 함정까지이 글은 gRPC 공식 문서(Load Balancing, Name Resolution)를 기준으로, gRPC의 클라이언트 사이드 로드 밸런싱 구조와 기본 로드 밸런서 동작 방식, 그리고 운영 환경(Kubernetes 포함)에서 실제로 문제가 되는 포인트까지 실무 관점에서 정리한 글입니다. 기준 문서: https://grpc.io/docs/guides/load-balancing/ https://grpc.io/docs/guides/name-resolution/ 📌 이 글은 gRPC 공식 문서 정리 시리즈의 일부입니다.(카테고리: Dev > gRPC)1. gRPC에서 로드 밸런싱은 “옵션”..