🔥 gRPC로 장애낸 사람이 정리해 본 gRPC

🔥 gRPC란?

gRPC (Google Remote Procedure Call)는 Google이 만든 오픈소스 원격 프로시저 호출(RPC) 프레임워크로, 고성능, 다중 언어 지원, HTTP/2 기반의 통신을 제공합니다.

쉽게 말하면?
💡 서버와 클라이언트가 서로 원격에서 함수 호출을 하듯이 통신할 수 있도록 도와주는 프레임워크!

🎯 gRPC의 주요 특징

1️⃣ HTTP/2 기반 → 빠르고 효율적 🚀

• 기존 REST API는 HTTP 1.1을 사용 → 요청마다 새로운 연결을 맺음 (비효율적, 단방향 통신)
• gRPC는 HTTP/2 기반으로 멀티플렉싱 지원 → 하나의 연결에서 여러 요청을 동시에 처리

2️⃣ Protocol Buffers(프로토버프) 사용 📦

• JSON 대신 바이너리 형식(.proto) 사용 → 빠르고 가볍다
• 자동 코드 생성 지원 → 다양한 언어에서 사용 가능

3️⃣ 다양한 통신 방식 지원 🔄

• Unary (기본 요청-응답): 클라이언트 → 서버 요청 후 응답 받음 (REST API와 동일)
• Server Streaming: 클라이언트가 요청하면 서버가 여러 응답을 스트리밍
• Client Streaming: 클라이언트가 여러 개의 요청을 보내고 서버가 한 번에 응답
• Bidirectional Streaming: 클라이언트와 서버가 양방향 스트리밍 가능

4️⃣ 다중 언어 지원 🌎

• Java, Python, Go, Node.js, C++, C#, Rust 등 다양한 언어에서 사용 가능

5️⃣ 로드 밸런싱 & 인증 지원 🔐

• NLB, ALB와 함께 사용 가능 (로드 밸런싱 지원)
• TLS/SSL을 이용한 보안 기능 제공

gRPC vs REST API 비교

🚀 gRPC를 언제 써야 할까?

✅ 고성능 API가 필요할 때 (REST보다 빠름)
✅ 양방향 스트리밍이 필요할 때 (예: 채팅, 실시간 데이터 처리)
✅ 멀티플랫폼 서비스 개발 시 (다양한 언어 지원)
✅ 마이크로서비스 간 통신 (가볍고 효율적)

✅ 결론

• gRPC는 고성능, 경량, 스트리밍 지원이 강점
• HTTP/2 기반으로 REST API보다 더 빠르고 효율적
• 하지만 JSON이 아니라 바이너리 데이터(프로토버프) 사용 → 디버깅이 어렵다

💡 한마디로?
➡ REST보다 빠르고, 다양한 언어에서 쉽게 쓸 수 있는 API 프레임워크! 🚀

여기까지 gRPC의 개념과 특.장점을 알았다.
그럼 위에서 배운 개념을 좀 더 깊이 비교.이해해보자.

✅ REST API가 HTTP/1.1이라서 양방향 스트리밍이 안 되는가?

REST API 자체는 HTTP/1.1을 기반으로 설계되었고, 기본적으로 요청-응답 방식(Req-Res)만 지원합니다.
즉, 클라이언트가 요청하면 서버가 응답하는 단방향 통신이 기본 동작이므로, 양방향 스트리밍이 원활하지 않습니다.

🎯 1️⃣ HTTP/1.1의 한계: 연결 유지와 스트리밍 문제

• REST API는 요청-응답 방식 (Request-Response Model)
  • 클라이언트가 요청을 보내야 서버가 응답
  • 서버가 클라이언트에게 먼저 메시지를 보낼 수 없음 (PUSH 불가)
• HTTP/1.1의 기본 동작 방식
  • 하나의 요청이 끝나면 연결이 닫힘 (Keep-Alive를 사용하면 연결 유지 가능하지만 지속적 스트리밍은 어려움)
  • 클라이언트는 지속적인 데이터를 받으려면 반복해서 요청(Polling)해야 함

🚀 2️⃣ 그러면 HTTP/1.1에서도 스트리밍이 가능한 방법은 없을까?

REST API에서 스트리밍이 필요할 때 다음과 같은 우회 방법이 있음.

1️⃣ Long Polling (롱 폴링)

• 클라이언트가 서버에 요청을 보내고, 서버는 즉시 응답하지 않고 데이터가 준비될 때까지 기다렸다가 응답
• 데이터를 받은 후 클라이언트는 다시 요청을 보내야 함 (반복)
• 단점: 지속적인 HTTP 연결로 인해 성능 오버헤드가 큼

2️⃣ Server-Sent Events (SSE)

• 서버가 클라이언트에게 단방향 푸시 가능
• HTTP 연결을 유지하면서 서버가 실시간 데이터를 클라이언트에 보낼 수 있음
• 한계: 양방향 통신은 불가능 (클라이언트 → 서버 전송 불가)

3️⃣ 웹소켓 (WebSockets)

• HTTP 핸드셰이크 이후, TCP 연결을 유지하면서 양방향 통신 가능
• REST API와 달리 서버도 클라이언트에게 자유롭게 메시지 전송 가능
• 단점: REST API와 다른 방식이라 기존 시스템과의 통합이 어려울 수 있음

🔥 3️⃣ HTTP/2 기반이면 REST API에서 양방향 스트리밍이 가능할까?

가능함! HTTP/2는 멀티플렉싱(Multiplexing)을 지원하여, 단일 연결에서 여러 요청과 응답을 동시에 처리 가능
➡️ gRPC가 HTTP/2를 사용하여 양방향 스트리밍을 지원하는 이유

하지만, 일반적인 REST API는 여전히 HTTP/1.1을 기반으로 하고 있어서, 기본적으로 양방향 스트리밍이 어려움.
➡️ REST API에서 스트리밍을 원하면 웹소켓이나 HTTP/2 기반의 gRPC 같은 기술을 활용해야 함

✅ REST API도 HTTP/2를 쓸 수 있을까?

네, REST API도 HTTP/2를 사용할 수 있습니다! 🚀
하지만 결론부터 말하자면, HTTP/2를 쓴다고 해서 REST API가 자동으로 gRPC처럼 동작하는 것은 아닙니다.

• REST API는 기본적으로 HTTP/1.1 기반이지만, 서버와 클라이언트가 HTTP/2를 지원하면 사용 가능
• 대부분의 최신 웹 서버(Apache, Nginx, AWS API Gateway 등)는 HTTP/2를 지원
• 브라우저도 기본적으로 HTTP/2를 지원하기 때문에, 특별한 설정 없이도 HTTP/2를 사용할 수 있음
  ➡️ 즉, REST API도 HTTP/2를 통해 멀티플렉싱, 헤더 압축 등의 성능 이점을 누릴 수 있음

🚀 2️⃣ HTTP/2를 사용하면 REST API가 빨라질까?

어느 정도 빨라질 수 있지만, gRPC 수준은 아님.

✅ HTTP/2의 주요 이점

✔ 멀티플렉싱 (Multiplexing) → 하나의 연결에서 여러 개의 요청/응답 가능
✔ 헤더 압축 (HPACK) → HTTP 헤더 크기를 줄여서 네트워크 효율 증가
✔ 서버 푸시 (Server Push) → 서버가 미리 데이터를 클라이언트에게 보낼 수 있음

➡️ 즉, HTTP/2를 사용하면 REST API도 더 빠르고 효율적으로 동작할 수 있음!

🔄 3️⃣ HTTP/2를 쓴다고 REST API가 gRPC처럼 되지는 않음

REST API가 HTTP/2를 사용해도 다음 한계는 그대로 유지됨

1. JSON 기반이라 여전히 바이너리보다 무겁다 (gRPC의 프로토버프보다 속도↓)
2. RPC 스타일이 아니라 HTTP 메서드(GET, POST, PUT 등) 기반이다
3. ⭐️ 양방향 스트리밍이 기본적으로 불가능하다 (웹소켓 등 다른 방식 필요)

➡️ HTTP/2를 쓴다고 REST API가 gRPC처럼 되는 건 아니고, 일부 성능 개선만 가능!

⚖️ 정리: REST API에서 HTTP/2를 쓰는 것 vs gRPC

🎯 결론

✔ REST API는 기본적으로 HTTP/1.1을 사용하므로 단방향 요청-응답 모델
✔ HTTP/1.1 기반의 스트리밍은 롱 폴링, SSE, 웹소켓 등의 우회 방법 필요
✔ REST API도 HTTP/2를 사용할 수 있지만, gRPC처럼 동작하지는 않음
✔ HTTP/2를 사용하면 멀티플렉싱과 성능 향상이 가능하지만, JSON 기반이라 gRPC만큼 효율적이지 않음
✔ 양방향 스트리밍이 필요한 경우 gRPC를 고려해야 함 (HTTP/2 기반의 gRPC는 양방향 스트리밍을 기본 지원)

💡 한마디로?
REST API는 HTTP/1.1을 기반으로 해서 기본적으로 양방향 스트리밍이 어려움.
➡️ 진짜 양방향 통신이 필요하면 웹소켓이나 gRPC를 쓰는 게 더 적절함! 🚀

❓ gRPC가 더 좋아 보이는데, 왜 REST API가 더 많이 쓰일까?

gRPC는 고성능, 스트리밍 지원, 다중 언어 지원 등 여러 장점이 있지만,
그럼에도 REST API가 더 널리 쓰이는 이유는 호환성, 사용 편의성, 브라우저 지원 때문입니다.

🚀 1️⃣ REST API는 웹 친화적 (브라우저 지원)

• REST API는 HTTP 기반이므로 웹 브라우저에서 바로 요청 가능
  • 예: curl이나 Postman에서 쉽게 요청 가능
• gRPC는 HTTP/2와 Protocol Buffers 사용 → 브라우저에서 직접 요청할 수 없음
  • 브라우저에서 gRPC를 쓰려면 별도의 프록시(gRPC-Web) 필요

➡️ 웹 애플리케이션에서는 REST API가 훨씬 쉽고 직관적

🎯 2️⃣ REST API는 사용하기 쉽고 직관적

• REST API는 GET, POST, PUT, DELETE 같은 HTTP 메서드 기반으로 직관적
• JSON 데이터 포맷 사용 → 사람이 읽고 이해하기 쉬움
• gRPC는 Protocol Buffers (바이너리 포맷) 사용 → 디버깅 & 로깅이 어려움

➡️ 개발자 경험이 REST API가 더 좋고, 학습 곡선이 낮음

🔌 3️⃣ REST API는 광범위한 호환성과 지원

• REST API는 거의 모든 프로그래밍 언어와 HTTP 클라이언트에서 기본 지원
• gRPC는 HTTP/2 기반이라 일부 네트워크 환경에서 제한될 수 있음
  • 예: 방화벽이나 프록시에서 HTTP/2 트래픽이 차단될 수도 있음
  • HTTP/2는 바이너리 프로토콜이라, 방화벽이나 프록시가 기존 방식으로 요청을 분석하기 어려움
  • 일부 보안 시스템은 HTTP/2 트래픽을 알 수 없는 데이터로 간주하고 차단할 수 있음
  • HTTP/2는 하나의 연결에서 여러 요청을 멀티플렉싱함 → 어떤 요청이 어떤 데이터인지 식별이 어려워 위험한 프로토콜로 간주하고 차단할 수 있음
• REST는 쿠키, 인증 토큰, 캐시 등 웹 표준 기능과 쉽게 연동 가능

➡️ 호환성 측면에서 REST API가 더 유연하고 범용적으로 사용 가능

🔥 4️⃣ REST API는 성숙한 생태계를 가지고 있음

• REST는 오랜 기간 표준으로 사용됨 → 많은 라이브러리와 도구 지원
• gRPC는 상대적으로 신기술이라 기존 시스템과의 통합이 어렵거나 추가 작업이 필요

➡️ 기업에서는 기존 REST API 시스템을 유지하면서 새 기술 도입을 신중하게 검토함

⚖️ 정리: gRPC vs REST API

✅ 결론: REST API가 더 많이 쓰이는 이유

• 웹 브라우저에서 바로 사용 가능
• JSON 기반이라 사람이 읽기 쉽고, 디버깅 & 로깅이 쉬움
• 거의 모든 언어와 환경에서 지원 (방화벽/네트워크 문제 없음)
• 오랜 기간 사용되면서 강력한 생태계를 형성함

➡️ gRPC는 속도와 성능이 뛰어나지만, REST API가 더 범용적으로 사용하기 편함!
➡️ 그래서 대부분의 일반적인 API는 REST API로 제공하고, 성능이 중요한 경우 gRPC를 선택! 🚀

그래서 글쓴이가 낸 장애가 무엇인가

나의 개발 서비스는 리버스 프록시로 NGINX를 쓰고 있는데 일부 서비스가 gRPC 통신을 하고 있다.

gRPC 동작 방식을 잘 몰랐던 나는.. Nginx config 변경 후 당차게 재기동을 하였다.
그리고.. 재기동 동안 일부 트래픽 유입 불가 장애를 내어버린 것이다.

왜 트래픽 유입이 안되었나

NGINX가 서버 재시작 시 새로운 프로세스를 시작하고 기존 프로세스가 종료되기 때문에 재기동되면서 gRPC 소켓이 리셋되었기 때문이다.

gRPC는 기본적으로 HTTP/2 기반의 프로토콜을 사용하고, 이를 NGINX와 통합할 때에는 NGINX가 프록시 역할을 합니다. NGINX를 재기동하면, 프록시로서의 연결도 종료되고 다시 설정되는 과정에서 gRPC 연결도 재설정되는 것입니다.

반면, REST API 통신을 사용하는 NGINX는 재기동 시에도 반드시 연결이 끊어지지 않는 것은 아닙니다.
NGINX는 기본적으로 요청을 처리하는 과정에서 새로운 프로세스를 생성하고 기존 프로세스를 종료하는 방식으로 동작합니다.
즉, NGINX 재기동 시에도 일시적인 연결 끊김이 발생할 수 있습니다.
다만, REST API 통신은 HTTP/1.x 또는 HTTP/2를 사용하는 방식인데, 이 방식은 gRPC와 다르게 요청-응답 기반의 단기적인 연결을 유지합니다.

REST API와 NGINX의 재기동 시 연결에 대한 차이점

1. HTTP 요청-응답
   REST API는 요청을 보내고 응답을 받는 단기적인 연결을 기반으로 합니다. 따라서, 한 번의 HTTP 요청에 대한 처리가 끝나면 연결이 종료됩니다.
   이 방식에서는 연결 끊김이 발생하더라도 클라이언트가 새로운 요청을 보내면 재연결됩니다.
2. gRPC
   반면, gRPC는 지속적인 연결을 유지하며 요청과 응답을 주고받습니다. NGINX가 gRPC를 사용할 때는 연결을 유지한 채로 여러 요청을 처리하는 방식이라, NGINX 재기동 시 기존의 지속적인 연결이 끊어지게 됩니다.

재발 방지는 어떻게?

1. Connection persistence
   NGINX에서 connection을 유지하도록 설정하거나, 세션을 관리하는 방식으로 클라이언트 측에서 재연결을 처리할 수 있습니다.
2. Zero downtime deployment
   NGINX를 재기동할 때, 새로운 프로세스가 준비되었을 때 기존 프로세스를 종료하도록 설정하여, 완전한 다운타임 없이 서비스를 제공할 수 있습니다.
3. gRPC 연결 유지
   NGINX의 proxy 설정을 통해 keepalive 옵션을 적절히 설정하여 연결을 유지하도록 할 수 있습니다.