문제 상황
캡스톤 디자인 주제를 고르던 중, Full-Stack Service Network 수업에서 gRPC를 처음으로 접했다.
https://hanvp.notion.site/gRPC-66050c357fa349d09251793497c52e55?pvs=4
gRPC는 Protocol Buffer를 사용해 데이터 전달 속도가 빠르며 서버간 의존도가 낮아 MSA에서 많이 사용된다기에, 서버를 기능별로 분리할 계획이었던 나는 꽤 좋은 주제를 찾았다고 생각했다.
따라서 알림 내용을 생성하고 DB에서 가져오는 알림 서버와 해당 내용을 서드파티로 보내는 작업 서버를 나누되, 서버 간 데이터 전달을 gRPC로 하여 기존 RESTful보다 속도를 높이는 방향으로 가고자 했다.
그런데 이는 지금까지 HTTP만 주로 다뤄본 나의 패착이었다!!
다시 말하자면, MQ를 서비스에 적용한 경험이 없어 서버 간의 데이터 전달은 HTTP로만 상상(?)해 볼 수 있던 나의 한계였다.
실제로 알림-작업 서버간 데이터 전달 사례를 찾아보니 모두 MQ를 사용하고 있었다. 그렇다면 빠른 속도 및 서버 간 의존도를 낮춰준다는 공통점이 있는 gRPC와 MQ는 어떤 차이가 있을까?
gRPC는 어떤 상황에 사용하면 좋을까?
gRPC에 앞서 RPC란?
RPC는 Remote Procedure Call의 약자로, 분산 컴퓨팅 환경에서 프로그램 간의 원격 호출을 위한 메커니즘이다. 즉, 클라이언트가 서버에 있는 프로시저(or 메서드)를 마치 로컬의 프로시저를 호출하는 것처럼 쓸 수 있도록 하는 것이다.
gRPC는 기존의 RPC에서 protocol buffer를 기반으로 단방향/양방향 스트리밍을 지원하며, Google RPC가 gRPC로 축약된 것으로 생각된다.
gRPC를 사용하는 상황은?
(다음 내용은, 여러 정보를 찾으면서 내 나름대로 정리한 것으로 실제와는 차이가 있을 수 있다.)
gRPC도 RPC이므로, 메서드를 호출하는 상황에 사용할 수 있다. 그 메서드가 로컬이 아니라 원격 서버 어딘가에 있을 뿐인 것이다.
메서드 호출은 프로그래밍을 처음 배우기 시작한 때부터 지금까지 늘 해오던 것이니 어떤 상황에 쓰이는지 쉽게 상상할 수 있다.
- 인풋(파라미터)를 가공해 아웃풋(반환값)을 되돌려 줄 때
- 즉, 요청이 있고, 응답이 있을 때
- 반환해야 하는 값이 없을 때도, 일반적으로 해당 로직이 잘 처리되었는지 확인하기 위해 message를 리턴
gRPC도 똑같다. 원격 서버의 메서드를 호출하기 때문에 로컬에서는 서버에서 로직을 잘 처리했는지, 반환 값이 올바로 잘 오는지를 궁금해 한다. 따라서 원격 서버가 다운되어 메서드가 동작하지 않으면 로컬의 서버는 영향을 받는 의존성이 생긴다.(물론 로드밸런싱이나 에러 핸들링에 관한 메커니즘은 별도로 존재)
⛔이 때의 의존성은 위에서 언급한 의존성과는 다르다.
-
Protocol Buffer를 사용할 때 서버 간 의존도가 낮아진 다는 것은, 데이터를 송수신 할 때 직렬화하므로 받는 대상이 Spring인지, Node.js인지, Pyhton인지 신경을 쓰지 않아도 된다는 뜻이다.
-
반면, 로컬의 요청에 대한 원격 서버의 응답을 받는다는 점에서 서버 상태에 대한 의존성이 생긴다.
MQ는 어떤 상황에 사용하면 좋을까?
MQ는 gRPC와 반대의 경우를 생각하면 된다. 작업에 대한 요청을 보냈지만, 결과는 전혀 신경쓰지 않아도 될 때 사용하면 좋다.
예시로 든 알림 서버가 이에 적합한 상황이다. 배치로 100,000명의 사용자에게 한번에 공지 문자를 보낼 때, 작업을 요청한 서버가 개별 요청이 잘 처리되었는지 확인하지 않아도 된다면 해당 서버는 다른 작업을 맘 편히 수행할 수 있을 것이다.
그래서 데이터를 보내는 쪽(Producer)는 송신하는 역할만 하고, MQ에게 모든 데이터가 누락 없이 전달되었는지 확인하고, 재전송하는 역할을 위임한다. 데이터를 받는 쪽(Consumer)도 송신자에게 응답을 보내야 하는 의무가 사라진다.
따라서 MQ는 두 가지 의존성이 모두 제거된다.
-
MQ도 데이터를 전송할 때 직렬화하므로, 플랫폼 및 언어에 독립적이다.
-
또한, MQ 서버가 데이터 핸들링에 관한 작업을 대신 해주므로 Producer와 Consumer는 상대 서버의 상태를 몰라도 된다는 점에서 의존성이 제거된다.
결론
gRPC와 MQ의 차이를 이해하고 나니, 이번 캡스톤 디자인에서는 MQ를 사용하는 것이 맞다고 판단되었다.
그렇다면, MQ는 Producer와 Consumer 사이에서 정확히 어떤 역할을 하는지, 주로 쓰이는 RabbitMQ와 Kafka의 특징은 무엇이고 왜 Redis Stream과 비교를 하게 되었는지는 다음 게시들에서 풀어나가고자 한다.
