메시징을 위한 NATS와 gRPC: 정답이 둘 다 아닐 때

신뢰할 수 있는 서비스 간 통신(inter-service communication)이 필요한 분산 시스템을 구축한다면, NATS와 gRPC에 대한 논쟁은 초기에 발생합니다. 엔지니어들은 하나를 선택하고 보통 작동하게 만드는데 — 그것이 어떻게 작동하는지, 그리고 어떤 아키텍처를 가정하는지가 매우 중요합니다.

여기는 승자를 가리는 것이 아니라 트레이드오프(trade-offs)에 대한 지도입니다. 그리고 자율 에이전트가 클라우드를 넘나들고 NAT 경계를 통과하여 대화해야 하는 하나의 성장하는 사용 사례의 경우, 둘 다 적절한 형태가 아닐 수 있습니다.

gRPC: 강력한 계약을 가진 RPC

gRPC는 Protocol Buffers를 HTTP/2에 래핑(wrap)하여 타입이 지정된 RPC 메서드, 서버 스트리밍(server streaming), 클라이언트 스트리밍(client streaming), 양방향 스트리밍(bidirectional streaming)을 제공합니다. 다음과 같은 경우에 빛을 발합니다:

• 엄격한 서비스 계약(Strict service contracts). .proto 파일은 각 서비스가 정확히 무엇을 하는지 정의합니다. 코드 생성(Code generation)은 12개 이상의 언어로 클라이언트와 서버를 만듭니다.
• 요청-응답 패턴(Request-reply patterns). 대부분의 gRPC 사용 사례는 유니캐스트 RPC(unary RPC)입니다 — 메서드를 호출하고 응답을 받습니다.
• 서비스 메시 또는 DNS 계층 하부 구조. gRPC는 엔드포인트가 호스트 이름으로 도달 가능하다고 가정합니다. 피어(peer)를 검색하거나 NAT를 통과하는 것은 서비스 메시(Istio, Linkerd)나 별도의 디스커버리 시스템에 맡겨집니다.

비용: TLS 인증서가 필수적이며 (gRPC는 이것 없이는 연결하지 않습니다), 모든 서비스는 안정적인 DNS 이름이나 프록시가 앞에 필요합니다. 이는 Kubernetes 클러스터 내부나 VPN 내에서는 잘 작동하지만, 그 경계를 벗어나면 복잡해집니다.

NATS: 클라우드 네이티브 메시징

• Pub/sub, 요청-응답, 및 큐 그룹(queue groups). NATS는 이벤트 기반 아키텍처와 워크로드 분배에 탁월한 의미론적 특성(semantics)을 가지고 있습니다.
• 기본적으로 최대 한 번 전달(At-most-once delivery) (필요한 경우 영속성을 위해 JetStream 사용).
• 높은 처리량과 낮은 지연 시간. NATS 서버는 유명할 정도로 빠릅니다 — 초당 수백만 개의 메시지를 처리하는 단일 Go 바이너리입니다.

트레이드오프(Trade-off): 모든 클라이언트가 NATS 클러스터에 도달해야 합니다. 만약 서비스들이 서로 다른 NAT 뒤, 서로 다른 클라우드에 있거나, 서로 다른 기업 네트워크에 있다면, 브로커가 공용으로 접근 가능해야 하거나 — 아니면 각 네트워크마다 클러스터를 운영하고 이들을 연결(bridge)해야 합니다. 또한 브로커는 메시지 페이로드도 확인합니다 (별도의 암호화 계층을 추가하지 않는 한). 그리고 클러스터 운영에 대한 책임은 사용자에게 있습니다.

두 기술 모두가 전제하는 것들

gRPC는 도달 가능한 엔드포인트(reachable endpoints)를 가정합니다. NATS는 도달 가능한 브로커(reachable broker)를 가정합니다. 둘 다 사용자가 네트워크를 제어하거나, 엔드포인트를 도달 가능하게 만들 인프라(VPN, 서비스 메시(service mesh), 공용 DNS 등)를 가지고 있다고 전제합니다.

이러한 전제는 VPC 내부에 있는 마이크로서비스에게는 유효합니다. 하지만 다음과 같은 상황에서는 깨지게 됩니다:

• 사용자의 라우터 뒤에서 실행되는 에이전트(Agents)
• 크로스 클라우드 에이전트 플릿 (AWS → GCP → Azure, 공유 VPC 없음)
• 동적 IP를 사용하며 서로 찾아야 하는 에이전트
• 중앙 브로커가 통제되지 않는 모든 토폴로지(topology)

세 번째 형태: 에이전트 오버레이(agent overlay)

gRPC나 NATS 어느 것과도 경쟁하지 않으며, 다른 문제를 해결하는 세 번째 범주가 있습니다. 에이전트 오버레이 네트워크는 모든 에이전트에 영구적인 가상 주소를 부여하고, NAT 트래버설(NAT traversal)을 투명하게 처리하며, 기본적으로 모든 것을 종단 간 암호화(end-to-end encryption)합니다.

Pilot Protocol은 이 접근 방식의 오픈 소스 예시입니다. 이는 메시징 브로커(NATS)도 아니고 RPC 프레임워크(gRPC)도 아닙니다. 이것은 레이어 3.5 오버레이(layer-3.5 overlay)이며, 에이전트는 재시작과 IP 변경에도 살아남는 안정적인 주소(N:NNNN.HHHH.LLLL)를 얻고, 암호화된 UDP 터널이 어떤 인프라 없이 NAT를 통과하며, 신뢰는 모든 참여자를 믿는 VPN 방식이 아니라 암호학적 핸드셰이크(cryptographic handshake)를 통해 확립됩니다.

NATS와 gRPC 옆에서 어디에 위치할까요?

실용적인 관점: 이들은 대안이 아니라 상호 보완적인 도구입니다. NAT 뒤에 있는 에이전트 플릿은 연결성(피어 디스커버리, 암호화 터널)을 위해 오버레이를 사용할 수 있으며, 여전히 메시징 의미론을 위해 그 위에 gRPC나 NATS를 사용할 수 있습니다. 오버레이 위에서 작동하는 NATS는 모든 네트워크에 걸친 pub/sub를 의미합니다. 오버레이 위에서 작동하는 gRPC는 모든 에이전트에 대한 TLS 인증서 관리 없이 RPC를 의미합니다.

'메시징을 위한 NATS vs gRPC'라는 질문은 단일 VPC 배포 환경에서는 적절한 질문입니다. 멀티 클라우드, 멀티 네트워크, 멀티 조직의 에이전트 시스템의 경우, 진짜 질문은 '내가 메시징 계층을 선택하기 전에 무엇이 연결성을 제공하는가?'이며 — 바로 그 지점에서 세 번째 형태가 자리를 얻게 됩니다.

시작하기

오버레이 접근 방식을 시도해 보고 싶다면:

curl -fsSL https://pilotprotocol.network/install.sh | sh
pilotctl send-message list-agents --data '/data' --wait

이제 귀하의 에이전트는 NAT 뒤에, DNS도 없고, TLS 인증서도 없고, 유지 관리할 브로커도 없는 오버레이 네트워크에서 주소 지정이 가능합니다. 그 후 필요한 의미론을 위해 NATS나 gRPC를 계층화하면 됩니다 — 오버레이가 연결성 문제를 처리하므로 메시징 계층은 자신이 가장 잘하는 것에 집중할 수 있습니다.