조용한 개발 노트

33편에서는 멀티 모듈 구조에서 Spring Boot를 어디에 두어야 하는지를 기준으로 정리했다.이번 글에서는 그 구조가 한 단계 더 확장된 상황, 여러 개의 Spring Boot 애플리케이션을 동시에 운영해야 하는 시점을 다룬다.이 단계에서는 더 이상 “코드 구조”만의 문제가 아니다. 배포 단위, 운영 책임, 장애 전파 범위가 핵심이 된다.1) “왜 굳이 애플리케이션을 나눠야 할까?”단일 Spring Boot 애플리케이션으로 시작하는 것은 매우 자연스럽고 합리적인 선택이다.하지만 다음 질문이 나오기 시작하면, 분리를 고민할 시점이다.배치 작업이 API 서버 성능에 영향을 준다일부 기능만 따로 배포하고 싶다실행 옵션(JVM, 리소스)이 서로 다르다이 문제들은 코드 정리로 해결되지 않는다. 운영 단위의 문..

이전 글들에서 다룬 것처럼, 대규모 트래픽 환경의 장애는 보통 “한 번에 터지는 사건”이 아니라 느리게 전파되고, 어느 순간 폭발합니다.느린 호출이 자원을 점유하고타임아웃은 기다림을 늘리고재시도는 요청 수를 폭증시키며결국 전체가 같이 느려진다이 흐름을 경험한 팀은 결국 같은 질문에 도달합니다.“그래서… 어디서 끊어야 하지?”Circuit Breaker는 이 질문에 답하는 대표적인 구조입니다. 다만 많은 경우 Circuit Breaker를 “장애가 나면 붙이는 옵션”처럼 취급합니다.하지만 실무에서 Circuit Breaker의 본질은 옵션이 아니라, 장애 전파를 끊는 경계(boundary)입니다.장애 전염을 막는 방법은 ‘기다리지 않는 것’이다장애 전염이 일어나는 핵심은 단순합니다.느린 호출을 기다리는 동..

대규모 트래픽을 처리하는 서비스를 운영하다 보면, 이상한 경험을 하게 됩니다.분명히 한 서비스에서 문제가 시작됐는데,어느 순간 전체 서비스가 같이 느려진다.처음엔 이렇게 생각합니다.“저 서비스가 느려진 거지, 우리 문제는 아니야.”하지만 시간이 지나면,에러율이 조금씩 올라가고p99 레이턴시가 전반적으로 튀며결국 사용자 체감 장애로 이어진다이 글에서는 이 현상을 개별 장애가 아니라 ‘전파되는 장애’라는 관점에서 설명합니다.대부분의 장애는 “혼자” 발생하지 않는다현대의 서비스 구조에서, 하나의 요청은 하나의 서비스에서 끝나지 않습니다.대부분의 경우,프론트엔드 요청 하나가여러 백엔드 서비스를 거치고다시 하나의 응답으로 조합된다이 구조에서 중요한 점은 이것입니다.이 중 어느 한 곳만 느려져도,요청 전체가 같이 ..

[gRPC 공식 문서 정리 4편] proto3 기본 구조와 설계 철학이 글은 Protocol Buffers 공식 문서(proto3)를 기준으로, gRPC API의 실제 계약을 정의하는 proto3의 기본 구조와 설계 철학을 실무 관점에서 정리한 글입니다. 기준 문서: https://protobuf.dev/programming-guides/proto3/ 📌 이 글은 gRPC 공식 문서 정리 시리즈의 일부입니다.(카테고리: Dev > gRPC)1. 왜 proto3를 따로 다뤄야 할까?gRPC에서 API의 진짜 계약은 서버 코드가 아니라 .proto 파일에 있다.서버 구현은 바뀔 수 있지만, proto는 한 번 공개되면 되돌리기 어렵다. 그래서 proto3는 단순한 문법이 아니라 시간을 고려한 설계 언어..

[gRPC 공식 문서 정리 3편] Deadline, Error, Interceptor 실무 패턴이 글은 gRPC 공식 문서(grpc.io)를 기반으로, gRPC에서 반드시 이해해야 할 Deadline, Error Model, Interceptor를 실무 관점에서 정리한 글입니다. 기준 문서: https://grpc.io/docs/what-is-grpc/core-concepts/ 📌 이 글은 gRPC 공식 문서 정리 시리즈의 일부입니다.(카테고리: Dev > gRPC)1. 왜 이 세 가지가 중요한가?gRPC를 실무에 도입하고 나서 발생하는 대부분의 문제는 성능이나 문법이 아니라, 아래 세 가지를 제대로 다루지 않았을 때 발생한다.요청이 언제까지 살아 있어야 하는가? (Deadline)실패를 어떻게 표..

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