조용한 개발 노트

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

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

HTTP는 오랜 시간 동안 웹의 표준 통신 프로토콜로 사용되어 왔다.하지만 HTTP의 핵심은 “의미(Semantics)”뿐 아니라 전송 방식에도 있다.이 글에서는 HTTP/1.1이 어떤 한계를 가졌는지, 그리고 HTTP/2가 그 한계를 어떻게 해결했는지를 RFC 기준으로 정리한다.1. HTTP/1.1의 기본 전송 모델HTTP/1.1은 요청-응답(Request-Response) 모델을 기반으로 한다.하나의 요청을 보내면, 그에 대한 응답을 받은 뒤 다음 요청을 보낼 수 있다.HTTP/1.0 시절에는 요청마다 연결을 새로 맺었지만, HTTP/1.1에서는 Keep-Alive를 통해 연결을 재사용할 수 있게 되었다.2. HTTP/1.1의 구조적 한계Keep-Alive로 연결 재사용이 가능해졌지만, HTTP/1...

gRPC Flow Control & Backpressure이 글은 gRPC 공식 문서와 HTTP/2 전송 방식을 기준으로, Streaming RPC에서 응답이 에러 없이 지연되거나 멈춘 것처럼 보이는 현상이 왜 발생하는지와, 실무에서 이를 어떻게 설계로 해결하는지에 대해 정리한 글입니다. 기준 문서: https://grpc.io/docs/guides/concepts/ , https://grpc.io/docs/guides/performance/ 📌 카테고리: Dev > gRPC1. Streaming RPC에서 자주 겪는 현상에러는 발생하지 않는다연결은 유지되고 있다응답이 일정 시점부터 오지 않는다이 현상은 네트워크 오류나 서버 장애가 아니라, gRPC와 HTTP/2의 흐름 제어 메커니즘에 의해 발생..

[gRPC 공식 문서 정리] Concurrency & Threading Model: 동시성은 어디서 깨질까?이 글은 gRPC Java 공식 문서(Concurrency / Performance)를 기준으로, gRPC 서버와 클라이언트에서 요청이 어떤 스레드에서 실행되는지, 그리고 동시 요청이 많아질 때 왜 성능·안정성 문제가 발생하는지를 실무 관점에서 정리한 글입니다. 기준 문서: https://grpc.io/docs/languages/java/basics/ https://grpc.io/docs/guides/performance/ 📌 이 글은 gRPC 공식 문서 정리 시리즈의 일부입니다.(카테고리: Dev > gRPC)1. gRPC에서 “동시성 모델”을 이해해야 하는 이유gRPC는 단순한 HTTP ..

[gRPC 공식 문서 정리] Connection Management & Keepalive: 연결은 왜, 언제 끊기는가이 글은 gRPC 공식 문서(Connection Management, Keepalive)를 기준으로, gRPC에서 연결(Connection)이 어떻게 관리되는지, Keepalive는 왜 존재하는지, 그리고 운영 환경에서 연결 끊김/지연 문제가 왜 발생하는지를 실무 관점에서 정리한 글입니다. 기준 문서: https://grpc.io/docs/guides/keepalive/ https://grpc.io/docs/guides/connection-management/ 📌 이 글은 gRPC 공식 문서 정리 시리즈의 일부입니다.(카테고리: Dev > gRPC)1. gRPC에서 “연결”은 왜 중..

[gRPC 공식 문서 정리 2편] Unary vs Streaming, 언제 무엇을 써야 할까?이 글은 gRPC 공식 문서(grpc.io)를 기반으로, gRPC의 4가지 호출 방식(Unary / Streaming)을 실무 선택 기준 중심으로 정리한 글입니다. 기준 문서: https://grpc.io/docs/what-is-grpc/core-concepts/ 📌 이 글은 gRPC 공식 문서 정리 시리즈의 일부입니다.(카테고리: Dev > gRPC)1. gRPC 호출 방식은 왜 중요한가?gRPC를 REST처럼 쓰는 순간, gRPC의 장점은 대부분 사라진다.gRPC의 핵심 차별점은 단순한 성능이 아니라 Streaming을 포함한 다양한 호출 모델에 있다.이 글에서는 다음 질문에 답하는 것을 목표로 한다.U..

[gRPC 공식 문서 정리 1편] gRPC Core Concepts 한 번에 이해하기이 글은 gRPC 공식 문서(grpc.io)를 기반으로, Spring Boot + Kotlin 환경에서 gRPC를 이해하기 쉽게 정리한 글입니다. 기준 문서: https://grpc.io/docs/ 1. gRPC는 무엇인가?gRPC는 고성능 RPC(Remote Procedure Call) 프레임워크입니다. 핵심은 “HTTP API”가 아니라 함수 호출처럼 보이는 서비스 간 통신을 제공한다는 점입니다.RPC: 네트워크 호출을 메서드 호출처럼 다룸High performance: HTTP/2 + 바이너리 프로토콜Modern: Streaming, Deadline, Cancellation, Code generation2. gRPC..