조용한 개발 노트

이 글은 gRPC 공식 문서와 OpenTelemetry 가이드를 기준으로, gRPC 서비스를 운영하면서 수집한 지표를 어떤 순서로 확인하고, 각 지표가 무엇을 의미하는지, 그리고 어디를 먼저 의심해야 하는지를 트러블슈팅 관점에서 정리한 글입니다.단순히 지표 목록을 나열하는 것이 아니라, 실제 장애 상황에서 지표를 어떻게 읽고 판단하는지에 초점을 둡니다. 기준 문서: https://grpc.io/docs/guides/observability/ , https://opentelemetry.io/docs/ 📌 카테고리: Dev > gRPC1. 트러블슈팅은 지표를 보는 순서가 중요하다gRPC 장애 분석에서 흔한 실수는 하나의 지표만 보고 원인을 단정하는 것이다.실제 운영에서는 다음 순서로 지표를 확인하는 ..

이 글은 gRPC 공식 문서의 Error Handling과 Status Codes를 기준으로, 기존 REST API를 gRPC로 전환할 때 HTTP 상태 코드를 gRPC Status로 어떻게 매핑하는 것이 적절한지를 실무 기준으로 정리한 글입니다.새로운 에러 모델을 소개하기보다는, REST 환경에서 이미 사용 중인 에러를 gRPC에서 어떻게 표현해야 혼란이 적은지에 초점을 둡니다.📌 카테고리: Dev > gRPC1. REST와 gRPC의 에러 표현 방식 차이REST API에서는 보통 HTTP Status Code와 응답 바디를 함께 사용해 에러를 표현한다.gRPC에서는 HTTP Status가 아닌, gRPC Status Code가 에러의 의미를 결정한다. HTTP 레벨의 상태 코드는 대부분 내부적으로 ..

이 글은 gRPC Java 공식 문서의 Performance 및 Resource Usage 내용을 기준으로, gRPC 서비스를 운영할 때 메모리가 어디서 사용되고, 어떤 상황에서 OOM이나 리소스 고갈이 발생하는지, 그리고 이를 설정과 설계로 어떻게 예방하는지를 정리한 글입니다. 기준 문서: https://grpc.io/docs/guides/performance/ 📌 카테고리: Dev > gRPC1. gRPC에서 메모리 문제는 왜 늦게 드러날까?gRPC 메모리 문제는 보통 다음 특징을 가진다.에러 없이 트래픽을 정상 처리하다가부하가 누적된 뒤갑자기 OOM이나 응답 지연으로 나타난다이는 gRPC가 연결 기반이고, 메시지를 버퍼링하며 처리하기 때문이다. 즉, 요청 하나하나는 가볍지만, 누적된 리소스 사..

이 글은 gRPC 공식 문서의 Best Practices, Performance, Security, Observability 가이드를 기준으로, gRPC를 실무에서 사용할 때 반드시 지켜야 할 기준과 피해야 할 패턴을 체크리스트 형태로 정리한 글입니다.이 글은 새로운 개념을 소개하지 않고, 지금까지 정리한 gRPC 설계·운영 원칙을 하나의 기준 문서로 묶는 것을 목표로 합니다. 기준 문서: https://grpc.io/docs/guides/concepts/ , https://grpc.io/docs/guides/performance/ , https://grpc.io/docs/guides/observability/ 📌 카테고리: Dev > gRPC1. API 설계메서드는 명확한 동작 단위를 나타내야..

이 글은 gRPC 공식 문서와 OpenTelemetry 가이드를 기준으로, gRPC 서비스를 운영하면서 실제로 어떤 지표를 대시보드에 올리고, 어디에 알람을 걸어야 하는지를 실무 기준으로 정리한 글입니다. 기준 문서: https://grpc.io/docs/guides/observability/ , https://opentelemetry.io/docs/specs/otel/metrics/ 📌 카테고리: Dev > gRPC1. Observability 실전의 출발점gRPC Observability의 목적은 “모든 지표를 수집하는 것”이 아니다.운영에서 필요한 것은 다음 두 가지다.지금 서비스가 정상인지 빠르게 판단할 수 있는가문제가 생겼을 때 원인을 좁혀갈 수 있는가따라서 대시보드와 알람은 최소한의 핵..

Service Mesh 환경에서 gRPC는 무엇이 달라지는가이 글은 gRPC 공식 문서(xDS)와 서비스 메쉬의 트래픽 관리 개념을 기준으로, Service Mesh를 도입했을 때 gRPC 애플리케이션에서 무엇이 달라지고, 무엇은 여전히 애플리케이션이 책임져야 하는지를 실무 관점에서 정리한 글입니다. 기준 문서: https://grpc.io/docs/guides/concepts/ , https://grpc.io/docs/guides/xds/ 📌 카테고리: Dev > gRPC1. Service Mesh를 쓰면 gRPC는 자동으로 좋아질까?Service Mesh를 도입하면 gRPC 트래픽 앞단에 프록시가 추가된다. 이 프록시는 애플리케이션 대신 네트워크 관련 기능을 처리한다.하지만 Mesh가 모든 문..

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의 흐름 제어 메커니즘에 의해 발생..

[proto3] Well-Known Types 실무 사용 가이드이 글은 Protocol Buffers 공식 문서(Well-Known Types)를 기준으로, proto3에서 제공하는 Well-Known Types를 실무에서 어떻게 사용하는 것이 적절한지, 그리고 어떤 경우에 사용을 피해야 하는지를 기준 중심으로 정리한 글입니다. 기준 문서: https://protobuf.dev/reference/protobuf/google.protobuf/ 📌 카테고리: Dev > gRPC1. Well-Known Types는 어떤 문제를 해결하기 위한 것인가proto3의 기본 scalar 타입만으로는 의미를 명확히 표현하기 어려운 경우가 있다.특정 시점과 시간의 길이타입이 고정되지 않은 데이터JSON과의 경계에 있..

[gRPC 공식 문서 정리] Observability: Metrics, Logging, Tracing으로 무엇을 봐야 할까?이 글은 gRPC 공식 문서(Observability)와 OpenTelemetry 가이드를 기준으로, gRPC 서비스를 운영할 때 무엇을 관측해야 하는지, 그리고 어떤 신호가 실제 장애로 이어지는지를 실무 관점에서 정리한 글입니다. 기준 문서: https://grpc.io/docs/guides/observability/ https://opentelemetry.io/docs/instrumentation/java/ 📌 이 글은 gRPC 공식 문서 정리 시리즈의 일부입니다.(카테고리: Dev > gRPC)1. Observability는 선택이 아니라 전제다gRPC는 고성능 RPC 프..

[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 ..