gRPC Series #1

개인적으로 gRPC는 다룰 일이 생겨서 그에 대한 내용과 공부를 지속적으로 작성할려고 한다. gRPC에 관한 내용은 O'Reilly 의 gRPC: Up and Running 과 여러 인터넷 정보를 기반으로 작성될 예정이다.

What is gRPC?

gRPC가 무엇인교? 라고 지나가던 교수님께서 여쭤보신다면 나는 이렇게 말할 것 같다.

Mircoservices Architecture를 위해 만들어졌다고 할 수 있을 정도로 각각의 독립적인 서비스 간의 통신 방법이라 생각하시면 됩니다. REST API와 비슷합니다.

잠깐, Microservice는 무엇일까? 아래 귀하디 귀하신 코딩애플 의 영상을 한번만 본다면 바로 이해가 될 것이다.

단순히 말하면... 각각의 서비스들이 잘게 나뉘어져서 독립적으로 서빙을 한다. 여기서 서로서로가 API 통신을 통해서 정보를 주고 받으면서 관계성을 짓는다. Mircoservice의 대한 내용을 짧게 하고 다시 gRPC로 돌아가면... 뭐가 되었던 Microservice 에서 서빙이 빠르고 큰 충돌 없이 Communication이 되어야한다. 그래야지, 다른 서비스에서도 큰 이상이 없고 각각의 서비스가 모여 하나의 서비스가 올바르게 제공 될 것이다.

gRPC Architecture

O'Reilly 의 gRPC: Up and Running 의 Figure 1-1. 에는 아래와 이미지와 함께 기본적인 gRPC의 형태에 대해서 말해주고 있다.

*.proto 는 Service에 대한 정의를 담고 있으며 Consumer와 Product Info 라는 Service에 동일하게 담긴다. Definition은 일종의 IDL (Interface Definition Language) 인데 서로 어떻게 대화를 할 것인지에 대한 계약서이자 규격 와 같은 역할을 한다. 이 말이 이해가 안된다면 쉽게 생각해서 API Document와 같다고 봐도 된다. 어떤 변수와 해당 변수의 형태는 무엇인지에 대한 정의를 담고 있다.

gRPC는 HTTP/2 규격에 따라 통신된다. 다른 RPC와 다르게 gRPC는 동기, 비동기 모두 가능하다. 여기서 동기는 Synchoize 를 맞추는 것, 비동기는 Asychroize로 각자 할 일만 하는 것을 말한다.

Server & Client

Server는 Client의 요청에 따라 응답을 한다. 그렇기 때문에 Server는 언제나 Listen으로 대기하고 응답을 대기하고 있는다. 반대로 Client는 열려 있는 Server Port를 찾아 언제 요청을 해야하고 응답을 받으면 종료하는가? 와 같은 것은 서비스 또는 구현에 따라 다를 것이다.

Why need gRPC?

책에서는 여러 이유가 있지만 가장 먼저 Inter-process Communication의 장점을 크게 언급하고 있다. JSON, XML와 같은 규격으로 통신을 하는 타 Protocol와 달리 buffer based binary protocol를 규격으로 활용하고 있으며 HTTP/2 위에서 작동하기 때문에 빠르고 보다 효과적이다.

더불어 Proto 를 통해 정의하게 되면 통신 규격의 단일화가 가능해져 관리 측면에서도 편하다고 한다. 그리고 무엇보다... 여러 언어에서 지원이 된다.

Microservice의 장점은 각각의 기능 구현을 다른 언어들로 하고 Communication Over-head를 통해서 하나의 서비스를 구축한다는 것이다. 그렇기 때문에 그의 장점을 그대로 갖고 가면서 gRPC는 Python, Java, C, GO 등의 형태로 보여준다. 그 외에도 너무 많은 장점을 나열 했지만 나에게 와닿는 내용은 이렇다.