RPC? gRPC? 에 대해서 알아보자 -(2)

이전 글에서 RPC 에 대해서 간단하게 살펴보았습니다. 이번 글에서는 RPC 를 기반으로한 gRPC 에 대해서 알아보도록 하겠습니다.

RPC? gRPC? 에 대해서 알아보자 -(1)

gRPC 란?

gRPC 는 원격 서버에 정의된 프로세스를 로컬에서 호출하는 것 처럼 쉽게 클라이언트에서 호출하고 운영하고 디버깅할 수 있는 프로세스 간의 통신 기술 입니다. gRPC 는 google 에서 만든 RPC 로, gRPC 의 g는 릴리즈 마다 다른 의미를 가지고 있습니다. 그러면 기존의 RPC 에서 어떤 점이 달라졌길래 gRPC 라는 이름으로 사용되고 있을까요?

gRPC 를 설명할 수 있는 그림으로 아래 그림이 있습니다. 왼쪽에 Service 라고 나와 있는 박스가 서버이고, 왼쪽에 Client 라고 표시되어 있는 박스가 말 그대로 클라이언트 입니다. 각각의 이름 앞에 프로그래밍 언어가 붙어 있는 이유는 각기 다른 언어로 개발된 프로세스들 끼리도 통신할 수 있다는 것을 알리기 위해 예시로서 표기되었습니다. 그리고 각각의 박스를 연결하는데 Proto Request 와 Proto Response 라고 나와 있는데, 이 부분이 gRPC 에서 중요한 포인트 입니다.

서비스 인터페이스를 정의하는 방법?

gRPC 는 위 그림과 같이 통신하기 위해서는 특정한 서비스 인터페이스를 정의하기 위한 방법으로 프로토콜 버퍼(Protoco buffer) 를 사용합니다. 이 프로토콜 버퍼는 어떤 프로그래밍 언어와도 통신을 할 수 있으며, 서버와 클라이언트 사이의 주고받는 메시지를 직렬화하여 통신할 수 있게 합니다.

프로토 파일의 예시

프로토콜 버퍼는 프로토 파일로 정의된 메시지 포맷들을 이용하여 직렬화 하고, 또한 프로토 파일을 토대로 받은 메시지를 역직렬화해서 가져오는 등의 작업을 진행합니다.. 프로토 파일 작성 예시는 아래와 같습니다.

service School { 
    rpc getPerson (int) returns (Person); 
}


message Person {
    string name = 1; 
    int32 id = 2;
}

만약 School 이라고 하는 서비스가 존재한다고 하고, 그 서비스에서 getPerson 이라고 하는 함수가 정의되어 있다고 가정해봅시다. 그러면 위와 같이 School 이라고 하는 서비스 객체를 선언 후 내부에 getPerson 이라고 하는 인터페이스를 정의해 줍니다. 파라미터와 반환 타입은 실제로 정의되어 있는 함수의 인터페이스와 동이랗게 선언 합니다. 입력 혹은 반환 타입이 여러 자료형들의 조합일 경우 즉 구조체 와 같은 타입일 경우 message 형식으로 그 자료들을 묶어서 전달할 수 있습니다.

gRPC 의 장점

• 통신 속도가 빠름 - gRPC 는 JSON 이나 XML 등의 데이터 포맷이 아닌 프로토콜 버퍼 기반의 메시지를 바이너리 형식으로 직렬화 하여 통신하기 때문에 보다 통신 속도가 빠릅니다.
• 엄격한 타입 검사 - 프로토콜 버퍼로 원하는 메시지 타입을 미리 정의를 해 놓고 통신하기 때문에 런타임 에러 발생률을 줄입니다.
• 이중 스트리밍 - 이는 gRPC 가 HTTP/2 를 사용하기 때문에 가능한 방법중에 하나로, 단순 요청-응답 방식의 통신을 뛰어 넘어 스트리밍 방식을 지원할 수 있습니다.

gRPC 의 단점

• 엄격한 타입 검사 - 이는 위에서 장점으로 설명을 드렸지만, 개발의 변경 사항이 많은 환경일 경우 이 또한 단점으로 다가올 수 있습니다. 주기적으로 변경하고 업데이트 해 나가야 하는 와중에 프로토콜 버퍼를 동기화 하며 반영해 나가는 것이 부담일 수 있습니다.
• 아직 부족한 생태계 - 이미 많이 발전해 있는 REST API 등에 비해 상대적으로 아직 많이 사용되고 있지 않고, 사용될 수 있는 환경이 국한되어 있다는 단점도 있습니다.