REST, gRPC, Kafka

REST, gRPC, Kafka

현재 아키텍처 분석

• MSA 구조: api-gateway, data-service, simulator-service로 서비스가 분리되어 있습니다.
• 통신 방식: 서비스 간 통신은 REST API (HTTP/JSON)를 사용하고 있을 것으로 보입니다. 클라이언트(React)와 api-gateway 간의 통신도 마찬가지입니다.

---

1. gRPC 도입: 서비스 간 통신 고도화gRPC는 주로 서비스 간의 동기적(Synchronous) 호출을 더 효율적으로 만들기 위해 REST API를 대체하는 기술입니다.

   • 적용 시나리오:
     • api-gateway ↔ data-service
     • api-gateway ↔ simulator-service
     • simulator-service ↔ data-service

   장점 (Pros)

   1. 성능 향상:
      • HTTP/2 사용: 하나의 TCP 연결로 여러 메시지를 동시에 주고받는 멀티플렉싱을 지원하여 통신 지연을 줄입니다.
      • Protocol Buffers (Protobuf): JSON/XML 같은 텍스트 기반 데이터 형식 대신, 바이너리(이진) 기반의 Protobuf를 사용합니다. 데이터 크기가 작고 직렬화/역직렬화
        속도가 매우 빠릅니다. 서비스 간 데이터 교환이 많은 시뮬레이터 프로젝트에 큰 이점이 될 수 있습니다.
   2. 엄격한 API 명세 관리:
      • .proto 파일을 통해 API의 서비스, 요청, 응답 메시지 구조를 명확하게 정의합니다.
      • 이 명세로부터 각 언어에 맞는 클라이언트/서버 코드를 자동으로 생성할 수 있어, 서비스 간 데이터 타입 불일치 같은 실수를 컴파일 타임에 잡을 수 있습니다.
   3. 스트리밍 지원:
      • 단순 요청/응답뿐만 아니라, 클라이언트 스트리밍, 서버 스트리밍, 양방향 스트리밍을 지원합니다. 대용량 데이터를 주고받거나, 실시간 통신이 필요할 때 유용합니다.

   단점 (Cons)

   4. 브라우저 호환성 문제:
      • 웹 브라우저는 기본적으로 gRPC를 직접 지원하지 않습니다. frontend에서 api-gateway를 gRPC로 호출하려면 gRPC-Web과 Envoy 같은 프록시를 추가로 구성해야 합니다.
        이는 아키텍처 복잡도를 높입니다.
      • 따라서 보통 frontend ↔ api-gateway 구간은 기존 REST API를 유지하고, 내부 서비스망(api-gateway ↔ 다른 서비스들)에만 gRPC를 적용하는 경우가 많습니다.
   5. 디버깅 및 가독성:
      • 메시지가 바이너리 형태라 REST API처럼 curl 같은 도구로 쉽게 요청을 보내고 응답을 눈으로 확인하기 어렵습니다. BloomRPC, grpcurl 등 별도의 도구가 필요합니다.
   6. 러닝 커브:
      • REST API에 비해 Protobuf 문법, gRPC 개념 등 초기 학습 곡선이 존재합니다.

---

2. Kafka 도입: 서비스 간 비동기(Asynchronous) 메시지 처리

   • 적용 시나리오:

     • 시뮬레이션 요청 처리: api-gateway가 시뮬레이션 요청을 받으면, 직접 simulator-service를 호출하는 대신 Kafka 토픽(Topic)에 '시뮬레이션 요청' 이벤트를 발행합니다.
       simulator-service는 이 토픽을 구독하고 있다가 요청을 받아 처리한 후, 결과를 다른 토픽에 발행할 수 있습니다.
     • 데이터 동기화: data-service에서 캐릭터 정보가 변경되면, '캐릭터 변경' 이벤트를 발행하여 관련된 다른 서비스들이 데이터를 업데이트하도록 할 수 있습니다.

     장점 (Pros)

     1. 서비스 간 결합도 감소 (Decoupling):
        • 서비스들은 서로를 직접 호출할 필요 없이 Kafka만 바라보면 됩니다. simulator-service가 일시적으로 장애가 나도 api-gateway는 계속 시뮬레이션 요청을 받아 Kafka에 쌓아둘 수 있습니다. simulator-service가 복구되면 쌓여있던 요청을 순차적으로 처리합니다. 이는 시스템의 회복탄력성(Resilience)을 크게 향상시킵니다.
     2. 확장성 (Scalability):
        • 시뮬레이션 요청이 많아지면, simulator-service 인스턴스를 여러 개로 늘려서 같은 토픽의 메시지를 병렬로 처리하도록 쉽게 확장할 수 있습니다.
     3. 대용량 데이터 처리:
        • 대규모 트래픽과 데이터를 안정적으로 처리하도록 설계되었습니다. 수많은 게임 데이터나 사용자 로그를 처리하는 데 적합합니다.

     단점 (Cons)

     1. 운영 복잡성 증가:

        • Kafka는 Broker, Zookeeper(또는 KRaft), Topic, Partition 등 관리해야 할 요소가 많은 분산 시스템입니다. 직접 설치하고 운영하는 것은 상당한 부담이 될 수 있습니다. (물론 클라우드 매니지드 서비스를 사용하면 부담이 줄어듭니다.)

     2. 아키텍처의 근본적인 변화:

        • 단순히 통신 기술을 바꾸는 것이 아니라, 시스템 전체를 이벤트 기반(Event-Driven)으로 생각하고 설계해야 합니다. 이는 개발 패러다임의 변화를 요구합니다.

     3. 지연 시간:

        • 중간에 Broker를 거치기 때문에, 직접 호출하는 REST나 gRPC에 비해 응답 시간(Latency)은 일반적으로 더 깁니다. 실시간으로 즉각적인 응답이 필요한 동기식 요청에는 적합하지 않습니다.

Kafka는 서비스 간의 결합도를 낮추고, 대용량 데이터를 안정적으로 처리하기 위한 이벤트 스트리밍 플랫폼입니다. 서비스 간의 직접적인 호출 대신, '이벤트(메시지)'를 발행(Produce)하고 구독(Consume)하는 방식으로 동작합니다.

---

4. 결론 및 추천

• gRPC와 Kafka는 경쟁 관계가 아니라 상호 보완적인 기술입니다.
  • "서비스 간의 내부 통신 성능을 높이고, 명확한 데이터 규약을 강제하고 싶다"
    • ➡️ gRPC 도입을 추천합니다. 특히 api-gateway와 백엔드 서비스들 간의 통신에 적용하면 효과적입니다.
  • "시간이 오래 걸리는 시뮬레이션 작업을 비동기적으로 처리하고 싶다. 또는 특정 서비스의 장애가 다른 서비스에 영향을 주지 않도록 시스템을 안정적으로 만들고 싶다"
    • ➡️ Kafka 도입을 추천합니다. 시뮬레이션 요청/결과 처리를 비동기로 전환하여 사용자 경험을 개선하고 시스템 안정성을 높일 수 있습니다.

두 기술을 함께 사용할 수도 있습니다. 예를 들어, frontend → api-gateway는 REST, api-gateway → Kafka로 시뮬레이션 요청을 발행하고, simulator-service와 data-service 간의 실시간 데이터 조회는 빠른 gRPC를 사용하는 복합적인 아키텍처도 가능합니다.

REST vs gPRC

특징	REST (Representational State Transfer)	gRPC (gRPC Remote Procedure Call)
기반 프로토콜	HTTP/1.1 (주로 사용)	HTTP/2
데이터 형식	JSON, XML (텍스트 기반, 유연함)	Protocol Buffers (바이너리 기반, 엄격함)
API 정의	별도 명세 필요 (OpenAPI/Swagger 등)	.proto 파일로 명세와 코드 동시 관리
개발 패러다임	자원(Resource) 중심 (명사 중심) GET /users/123	함수(Function) 호출 중심 (동사 중심) getUser(userId: 123)
주요 장점	범용성, 가독성, 쉬운 사용법	성능, 타입 안정성, 스트리밍
주요 단점	성능 한계, 명세 관리의 번거로움	브라우저 호환성, 디버깅의 어려움
적합한 환경	외부에 공개되는 Public API, 웹 클라이언트 통신	내부 마이크로서비스 간 통신 (MSA)

경쟁 관계 요약

• 웹의 표준 vs 성능의 강자: REST는 오랫동안 웹 API의 사실상 표준(de facto standard)으로 자리 잡아왔습니다. 배우기 쉽고, HTTP 기반이라 누구나 쉽게 이해하고 사용할
  수 있습니다. 반면 gRPC는 구글이 MSA 환경에서의 성능 문제를 해결하기 위해 내놓은 후발주자로, 성능과 안정성에 초점을 맞춘 '도전자'의 위치에 있습니다.
• 선택의 기준: 어떤 API를 만드느냐에 따라 선택이 달라집니다.
  • Public API (외부 공개용): 불특정 다수의 클라이언트가 사용할 가능성이 있고, 브라우저와의 호환성이 중요하다면 REST가 거의 항상 정답입니다.
  • Internal API (내부 서비스용): 성능이 매우 중요하고, 통신하는 서비스들이 명확하게 정해져 있는 MSA 환경이라면 gRPC가 훨씬 더 나은 선택입니다.결론적으로, "어떤 통신 API를 만들 것인가?" 라는 질문에 대해 REST와 gRPC는 각기 다른 장단점을 가진 선택지를 제공하는 경쟁 기술이라고 할 수 있습니다.