서비스간 통신 어떻게 진행할까?
일반적으로 우리가 MSA 구조에서, 서비스와 서비스간 통신한다라고 한다면 직관적으로 떠오르는 것은 Endpoint를 생성해서 REST를 이용해서 통신하는 것이다.
하지만, REST의 큰 단점이 존재한다. REST는 HTTP/1.1 프로토콜을 사용하기 때문에, 단일 request에 대해서 단일 response만 제공해준다. 즉, 여러번의 request를 보내서 서버에 처리를 요청해야 된다. 그러면, 불필요한 네트워크 비용이 발생하며, 성능도 저하가 된다. 요즘같이 MSA가 업계 표준이 되가는 상황에서, 서비스간 통신이 진행될 일이 굉장히 많을텐데, 이 점은 굉장히 치명적일 것이다.
그래서 해결하기 위해 등장한 기술이 Socket, RPC와 같은 기술이다. 여기서, 구글이 기존의 RPC 성능을 높여 만든 프레임워크가 바로 GRPC이다.
RPC가 뭐에요?
RPC란 Remote Procedure Call, 즉 원격호출을 의미한다. 이름 그대로 직관적으로 해석해서 네트워크로 연결된 서버의 메서드 등을 원격으로 호출하는 기능이다. REST처럼 Endpoint로 요청을 보내고, 상대 서버가 요청을 듣고 처리하고 다시 응답하는 형태가 아닌, 마치 원래 그 원격 메서드가 내 자원인 것처럼 실행하는 형태이다.
RPC에서 가장 중요한 개념이 Stub이다. 일종의 프록시 객체라고 생각하면 된다. 즉, RPC에서 클라이언트와 서버가 서로 통신할 수 있도록 도와주는 대리자 같은 역할을 하는 것이다. 그런데 왜 Stub이 필요한 것인가? 서버와 클라이언트가 서로 다른 서버니깐, 다른 주소 공간을 사용할 것이다. 그러면, 함수 호출을 할 때, 사용된 매개 변수를 변환할 필요가 있다. 안그러면, 메모리 매개 변수에 대한 포인터가 다른 데이터를 가리킬 것이다!
좀 더 쉽게 예시를 들어보겠다. A나라와 B나라 사람이 있다. 그런데 A는 영어를 사용하고, B는 한국어를 사용한다. 그러면, 서로의 언어를 모르니 대화할 수 없을 것이다. 그래서 대화하기 위해선 통역사가 필요하다. 그것이 바로 Stub이다.
GRPC는 뭐가 다른가요?
GRPC의 두드러진 몇가지 특징이 있다.
1. GRPC는 HTTP/2 프로토콜을 사용한다. 기존 REST는 HTTP/1.1을 사용해서 단일 연결에, 단일 응답만 처리 가능했다. 하지만, HTTP/2 프로토콜부터는 하나의 연결에 여러개의 메시지를 주고 받을 수 있는 양방향 프로토콜이다. 즉, 클라이언트 요청 없이도 서버가 리소스를 여러개 전달할 수 있으므로, 네트워킹 비용이 줄어들 것이다. 또한, HTTP/1.1은 각 요청과 응답에 모든 헤더가 포함된다. 그래서, 헤더가 크거나 반복될 때 비효율 적이다. 반면에, HTTP/2는 헤더를 압축해서 전달하기 때문에 전송해야 하는 데이터 양을 줄여준다.
2. GRPC는 json이 아니라, protobuf라는 데이터 포맷을 사용한다. 이는 구글에서 개발한 데이터를 직렬화하는 기법이다. 해당 데이터 포멧은 xml 또는 json에 비해 굉장히 적은 양으로 데이터 표현이 가능하고, 처리 속도도 몇십배 빠르다. 위 사진 예시 처럼, json으로는 82 byte를 차지했던 것이, protobuf를 사용하니 33 byte로 줄어들었다.
즉, MSA에서 내부적으로 서비스 간의 통신이 필요할 때 사용하면 성능이 매우 향상 될 수 있기 때문에 사용하는 것이다.
다만, GRPC가 브라우저와 서버간 통신을 지원하지 않고, json과 다르게 protobuf는 사람이 알아보기가 힘들다. 그래서, MSA 구조에서 내부 서비스 간 통신에만 사용하는 추세이다.
GRPC와 Message Broker, 비슷한 개념 아닌가요?
GRPC와 Message Broker는 다른 개념이다.
간단히 설명하자면, GRPC는 주체가 무슨 일을 하는 것이다. 반면에 Kafka, RabbitMQ 같은 Message Broker는 신문 구독하는 것 마냥, 일단 상대편 집 앞에 신문을 던져두고, 나중에 천천히 확인하는 그런 방식이다.
예시를 한번 들어보겠다.
GRPC : 내가(Client) 스타벅스(Server)에 전화해서 커피를 주문(메서드)한다.
Message Broker : 내가(Client) 당근 마켓(Message Broker)에 중고 물품을 판다고 공고를 올린다.(Push) 여러 사람들이 내가 올린 글을 스쳐지나가면서 보는데, 한 사람이(Subscriber) 내 물품을 구매하겠다고 요청을 보낸다.(메서드)
즉, GRPC 같은 경우는 사용자가 서버의 메서드를 호출 하는 것이니깐, protobuf라는 파일로 미리 정의가 되었어야 된다. 반면에, Message Broker 같은 경우는 그냥 구독한 메시지를 가지고 처리하면 되는 거니깐, 클라이언트가 어떻게 구성되있는지 알필요가 없다. 즉, Coupling이 낮아지는 것이다.
어쨋든, 둘은 좀 다른 개념이고, 쓰이는 상황이 좀 다르다.
GRPC 어떻게 활용할 수 있을까요?
앞에서 말했다 싶이, MSA 구조에서 내부 서비스간 통신을 고성능으로 만들기 위해서 사용하면 된다.
예를 들어, 내가 현재 개발하고 있는 "이음" 서비스에서는 팀원 추천을 받기 위해서 AI 서버에 접근해야되는데, 이때 Spring 서버에서 GRPC를 이용하여 FastAPI로 구축된 AI 서버의 메서드를 원격 실행해서 정보를 받아오도록 설계했다.
이상, GRPC에 대한 개발 탐구를 마치겠다. 추후, "이음" 서비스에서 GRPC를 이용하여 AI 서버와 통신하는 내용에 대해서 다뤄보고자 한다.
💡참고자료
- https://dev-racoon.tistory.com/18
- https://stackoverflow.com/questions/69416765/which-option-is-more-suitable-for-microservice-grpc-or-message-brokers-like-rab
- https://medium.com/naver-cloud-platform/nbp-%EA%B8%B0%EC%88%A0-%EA%B2%BD%ED%97%98-%EC%8B%9C%EB%8C%80%EC%9D%98-%ED%9D%90%EB%A6%84-grpc-%EA%B9%8A%EA%B2%8C-%ED%8C%8C%EA%B3%A0%EB%93%A4%EA%B8%B0-1-39e97cb3460
- https://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.html
'개발 > 대규모 시스템 설계' 카테고리의 다른 글
| [대규모 시스템 설계] 동시성 처리 (0) | 2024.07.04 |
|---|---|
| [대규모 시스템 설계] 캐시 설계 전략 (0) | 2024.05.20 |
| [대규모 시스템 설계] MSA의 필요성과 고려할 포인트들 (0) | 2024.05.19 |
