gRPC 개념, 사용 사례 및 모범 사례 이해하기

애플리케이션 개발을 진행하면서 다양한 것들 중에 우리가 덜 걱정하는 가장 주요한 것이 있습니다. 바로 컴퓨팅 파워입니다. 클라우드 서비스 제공업체의 등장으로 데이터 센터를 관리하는 데 덜 걱정할 수 있습니다. 모든 것이 즉시 주문 가능합니다. 이로 인해 데이터 크기도 증가합니다. 빅 데이터는 단일 요청에서 다양한 매체를 사용하여 생성되고 전송됩니다.

데이터 크기가 증가함에 따라 직렬화, 역직렬화 및 전송 비용과 같은 활동이 추가됩니다. 컴퓨팅 자원에 대해 걱정하지 않더라도 대기 시간이 오버헤드가 됩니다. 전송을 줄여야 합니다. 과거에는 이를 해결하기 위해 많은 메시징 프로토콜이 개발되었습니다. SOAP는 비쌌고, REST는 간결한 버전이지만 더 효율적인 프레임워크가 필요합니다. 그것이 바로 원격 프로시저 호출(RPC)입니다.

이 글에서는 RPC가 무엇인지, RPC의 다양한 구현체를 살펴보고, 특히 Google의 RPC 구현체인 gRPC에 초점을 맞춥니다. REST와 RPC를 비교하고 gRPC의 다양한 측면, 포함 보안, 도구 등을 이해해 보겠습니다.

RPC란?

RPC는 원격 프로시저 호출을 의미합니다. 정의는 이름에 있습니다. 프로시저 호출은 단순히 함수/메소드 호출을 의미하며, “원격”이라는 단어가 모든 차이를 만듭니다. 원격으로 함수 호출을 할 수 있다면 어떨까요?

간단히 말해, 함수가 서버에 있고 클라이언트 측에서 호출되어야 한다면, 메서드/함수 호출처럼 간단하게 만들 수 있을까요? 실제로 RPC가 하는 일은 클라이언트에게 로컬 메서드를 호출하는 것처럼 보이게 하는 것이지만, 사실은 네트워크 계층의 작업을 추상화하는 원격 시스템의 메서드를 호출하는 것입니다. 이 방식의 아름다움은 계약이 매우 엄격하고 투명하게 유지된다는 점입니다(이 글에서 나중에 논의하겠습니다).

RPC 호출에 관련된 단계:

RPC 시퀀스 흐름

이것이 전형적인 REST 프로세스의 모습입니다:

RPC는 이 프로세스를 다음과 같이 단순화합니다:

이는 요청을 만드는 데 관련된 모든 복잡성이 이제 우리로부터 추상화되었기 때문입니다(코드 생성에 대해 이 글에서 논의하겠습니다). 우리가 걱정해야 할 것은 데이터와 로직뿐입니다.

gRPC: 그것이 무엇인가, 왜 그리고 어떻게 그것을 사용하는가

지금까지 RPC에 대해 논의했습니다. 이는 기본적으로 원격으로 함수/메서드 호출을 하는 것으로, “엄격한 계약 정의,” “데이터의 전송 및 변환 추상화,” “지연 감소” 등의 이점을 제공합니다. 이 글을 진행하면서 이에 대해 더 자세히 논의하겠습니다. 우리가 정말로 깊이 있는 분석을 원하는 것은 RPC의 한 구현체입니다. RPC는 개념이고 gRPC는 그 개념을 기반으로 한 프레임워크입니다.

RPC의 다양한 구현체들은 다음과 같습니다:

• gRPC (구글)

• Thrift (페이스북)

• Finalge (트위터)

Google의 RPC 버전은 gRPC라고 불립니다. 2015년에 소개되었으며 그 이후 인기를 누리고 있습니다. 마이크로서비스 아키텍처에서 가장 선호되는 통신 메커니즘 중 하나입니다.

gRPC는 프로토콜 버퍼(오픈 소스 메시지 형식)를 클라이언트와 서버 간의 기본 통신 방법으로 사용합니다. 또한 gRPC는 HTTP/2를 기본 프로토콜로 사용합니다. gRPC가 지원하는 통신 유형은 네 가지입니다:

• 일대일(Unary) [전형적인 클라이언트와 서버 통신]

• 클라이언트 측 스트리밍 

• 서버 측 스트리밍

• 양방향 스트리밍

gRPC에서 널리 사용되는 메시지 형식으로 나오게 된 프로토콜 버퍼, 줄여서 프로토버프입니다. 프로토버프 메시지는 다음과 같습니다:

여기서 ‘Person’은 요청/응답의 일부로 전송하고자 하는 메시지로, ‘name’(문자열 타입), ‘id’(문자열 타입), ‘email’(문자열 타입) 필드를 가지고 있습니다. 숫자 1,2,3은 이진 형식으로 직렬화될 때 데이터(예: ‘name’, ‘id’, ‘email’)의 위치를 나타냅니다.

개발자가 모든 메시지를 포함한 Protocol Buffer 파일을 생성하면, 우리는 프로토콜 버퍼 컴파일러(바이너리)를 사용하여 작성된 프로토콜 버퍼 파일을 컴파일할 수 있으며, 이는 메시지와 작업하는 데 필요한 모든 유틸리티 클래스와 메서드를 생성합니다. 예를 들어, 여기에 나온 것처럼, 생성된 코드(선택한 언어에 따라)는 이렇게 보일 것입니다.

서비스를 어떻게 정의하나요?

위의 메시지를 사용하여 전송/수신할 서비스를 정의해야 합니다.

필요한 요청 및 응답 메시지 유형을 작성한 후 다음 단계는 서비스 자체를 작성하는 것입니다.

gRPC 서비스도 프로토콜 버퍼에 정의되며 “service” 및 “RPC” 키워드를 사용하여 서비스를 정의합니다.

다음 proto 파일의 내용을 살펴보세요:

여기서 HelloRequest와 HelloResponse는 메시지이며 HelloService는 SayHello라는 단일 RPC를 노출하는데, 이는 HelloRequest를 입력으로 받고 HelloResponse를 출력으로 제공합니다.

언급된 바와 같이, HelloService는 현재 단일 unary RPC를 포함하고 있습니다. 그러나 이 서비스는 하나 이상의 RPC를 포함할 수 있으며, 다양한 유형의 RPC(unary/client-side streaming/server-side streaming/Bidirectional)를 포함할 수 있습니다.

스트리밍 RPC를 정의하려면 요청/응답 인수 앞에 ‘stream ‘을 붙이기만 하면 됩니다. 스트리밍 RPC의 프로토 정의 및 생성된 코드.

위의 코드베이스 링크:

• streaming.proto: 이 파일은 사용자 정의입니다.

• streaming.pb.go & streaming_grpc.pb.go: 이 파일들은 프로토 컴파일러 명령어를 실행할 때 자동 생성됩니다.

gRPC Vs. REST

gRPC에 대해 상당히 많이 이야기했습니다. 또한, REST에 대한 언급도 있었습니다. 우리가 놓친 부분은 차이점에 대한 논의였습니다. 내 말은, REST라는 잘 설립된, 경량의 통신 프레임워크가 있는데, 왜 또 다른 통신 프레임워크를 찾아야 했냐는 겁니다. REST와 관련하여 gRPC에 대해 더 자세히 이해하고, 각각의 장단점을 살펴보도록 하겠습니다.

비교하기 위해 필요한 것은 매개변수입니다. 그러므로 비교를 다음과 같은 매개변수로 나누어 살펴보겠습니다:

• 메시지 형식: 프로토콜 버퍼 vs JSON

  • 직렬화 및 역직렬화 속도는 모든 데이터 크기(작은/중간/큰)에 걸쳐 프로토콜 버퍼의 경우에 훨씬 더 나은 성능을 보입니다. 벤치마크 테스트 결과. 

  • 직렬화 후 JSON은 사람이 읽을 수 있는 반면 프로토버프(이진 형식)는 그렇지 않습니다. 이것이 단점인지 아닌지 확실하지 않은데, 가끔은 구글 개발자 도구나 Kafka 토픽에서 요청 세부 정보를 보고 싶을 때 프로토버프의 경우 아무것도 알아볼 수 없기 때문입니다. 

• 통신 프로토콜: HTTP 1.1 vs. HTTP/2T

  • REST는 HTTP 1.1을 기반으로 하며, REST 클라이언트와 서버 간의 통신은 세션을 설정하는 3-way handshake가 포함된 설정된 TCP 연결을 요구합니다. 클라이언트에서 요청을 보내고 서버로부터 응답을 받으면 그 후에 TCP 연결이 존재하지 않습니다. 새로운 TCP 연결이 필요하며, 각각의 요청마다 TCP 연결을 설정하는 것은 지연 시간에 영향을 줍니다.

  • 따라서 HTTP 2를 기반으로 하는 gRPC는 지속적인 연결을 통해 이 문제를 해결했습니다. 웹 소켓의 지속적인 연결과는 달리 TCP 연결이 납치되고 데이터 전송이 모니터링되지 않는 것을 기억해야 합니다. gRPC 연결에서는 TCP 연결이 설정되면 여러 요청에 재사용됩니다. 동일한 클라이언트와 서버 쌍으로부터의 모든 요청은 동일한 TCP 연결에 공존합니다.

• 데이터와 로직에 대해서만 걱정하면서: 코드 생성이 일급 시민

  • 코드 생성 기능은 gRPC의 내장 protoc 컴파일러를 통해 기본적으로 제공됩니다. REST API의 경우 Swagger와 같은 타사 도구를 사용하여 여러 언어로 API 호출을 위한 코드를 자동으로 생성해야 합니다.

  • gRPC의 경우 마샬링/언마샬링, 연결 설정, 메시지 송수신 과정을 추상화하여 우리가 신경 써야 할 것은 보내거나 받을 데이터와 로직뿐입니다.

• 전송 속도

  • 이진 형식이 JSON 형식보다 훨씬 가볍기 때문에 gRPC의 전송 속도는 REST보다 7에서 10배 빠릅니다.

다시 말하지만, 현재 거의 모든 UI 프레임워크에서 gRPC에 대한 제한적이거나 지원이 없기 때문에 gRPC에는 브라우저 지원이 없습니다. 내부 마이크로서비스 통신에 대해 대부분의 경우 gRPC가 자동으로 선택되지만 UI 통합이 필요한 외부 통신에 대해서는 그렇지 않습니다.

이제 두 프레임워크인 gRPC와 REST를 비교해 보았습니다. 언제 무엇을 사용해야 할까요?

• 여러 개의 가벼운 마이크로서비스가 있는 마이크로서비스 아키텍처에서 데이터 전송의 효율성이 중요한 경우 gRPC는 이상적인 선택입니다.

• 여러 언어 지원을 통한 코드 생성이 요구되는 경우 gRPC가 최우선 프레임워크가 되어야 합니다.

• gRPC의 스트리밍 기능을 통해 거래 또는 OTT와 같은 실시간 애플리케이션은 REST를 사용하여 폴링하는 것보다 더 많은 이점을 얻을 수 있습니다.

• 대역폭이 제한된 경우 gRPC는 훨씬 낮은 레이턴시와 처리량을 제공할 것입니다.

• 더 빠른 개발 및 고속 반복이 요구되는 경우 REST가 최우선 옵션이 되어야 합니다.

gRPC 개념

로드 밸런싱

지속적인 연결은 레이턴시 문제를 해결하지만 로드 밸런서 뒤의 서버와 클라이언트가 지속적인 연결을 형성하는 것과 같은 다른 도전 과제를 제시합니다. 이는 스티키 세션과 유사합니다.

문제나 도전 과제를 데모를 통해 이해할 수 있습니다. 코드와 배포 파일은 다음 링크에 있습니다: https://github.com/infracloudio/grpc-blog/tree/master/grpc-loadbalancing.

위의 데모 코드 베이스에서 부하 분산의 책임이 클라이언트에 있음을 알 수 있습니다. 이로 인해 gRPC의 장점인 지속적인 연결이 이러한 변경과 함께 존재하지 않게 됩니다. 그러나 gRPC는 다른 이점으로 여전히 사용될 수 있습니다.

gRPC에서 부하 분산에 대해 더 알아보세요.

위의 데모 코드 베이스에서는 라운드 로빈 부하 분산 전략만 사용/시연되었습니다. 그러나 gRPC는 첫 번째로 선택하는 “pick-first”라는 다른 클라이언트 기반 부하 분산 전략 OOB도 지원합니다.

또한, 사용자 정의 클라이언트 측 부하 분산도 지원됩니다.

깨끗한 계약

REST에서 클라이언트와 서버 간의 계약은 문서화되지만 엄격하지 않습니다. SOAP로 거슬러 올라가면 계약은 wsdl 파일을 통해 노출되었습니다. REST에서는 계약을 Swagger 및 기타 제공 사항을 통해 노출합니다. 그러나 엄격성이 부족하여 클라이언트 코드가 개발 중일 때 서버 측에서 계약이 변경되었는지 확신할 수 없습니다.

gRPC를 사용하면 proto 파일 또는 proto 파일에서 생성된 스텁을 통해 계약이 클라이언트와 서버 모두에게 공유됩니다. 이는 원격으로 함수 호출을 하는 것과 같습니다. 함수 호출을 하고 있기 때문에 정확히 무엇을 보낼 필요가 있고 어떤 응답을 기대하는지 알 수 있습니다. 클라이언트와의 연결 생성, 보안 관리, 직렬화-역직렬화 등의 복잡성이 추상화되어 있습니다. 우리가 신경 쓰는 것은 데이터뿐입니다.

다음 코드 베이스를 고려하십시오:

https://github.com/infracloudio/grpc-blog/tree/master/greet_app     

클라이언트는 스텁(proto 파일에서 생성된 코드)을 사용하여 클라이언트 객체를 생성하고 원격 함수 호출을 호출합니다: 

```sh

import greetpb "github.com/infracloudio/grpc-blog/greet_app/internal/pkg/proto"



cc, err := grpc.Dial(“<server-address>”, opts)

if err != nil {

    log.Fatalf("could not connect: %v", err)

}



c := greetpb.NewGreetServiceClient(cc)



res, err := c.Greet(context.Background(), req)

if err != nil {

    log.Fatalf("error while calling greet rpc : %v", err)

}

```

마찬가지로 서버도 동일한 스텁(proto 파일에서 생성된 코드)를 사용하여 요청 객체를 수신하고 응답 객체를 생성합니다: 

```sh

import greetpb "github.com/infracloudio/grpc-blog/greet_app/internal/pkg/proto"



func (*server) Greet(_ context.Context, req *greetpb.GreetingRequest) (*greetpb.GreetingResponse, error) {

 

  // 'req'로 무언가를 수행

 

   return &greetpb.GreetingResponse{

    Result: result,

      }, nil

}

```

둘 다 proto 파일에서 생성된 동일한 스텁을 사용하며 해당 파일은 여기에 있습니다.

그리고 스텁은 아래 프로토컴파일러 명령어를 사용하여 생성되었습니다. 

```sh

protoc --go_out=. --go_opt=paths=source_relative --go-grpc_out=. --go-grpc_opt=paths=source_relative internal/pkg/proto/*.proto

```

보안

gRPC 인증 및 권한 부여는 두 단계로 작동합니다:

• 호출 수준 인증/권한 부여는 일반적으로 호출이 이루어질 때 메타데이터에 적용되는 토큰을 통해 처리됩니다. 토큰 기반 인증 예제.

• 채널 수준 인증은 연결 수준에서 적용되는 클라이언트 인증서를 사용합니다. 또한 채널의 모든 호출에 자동으로 적용되는 호출 수준 인증/권한 부여 자격 증명을 포함할 수 있습니다. 인증서 기반 인증 예제.

이 두 메커니즘 중 하나 또는 둘 다를 사용하여 서비스를 보호할 수 있습니다.

중간소프트웨어

REST에서 우리는 다양한 목적으로 중간소프트웨어를 사용합니다:

• 제한 속도

• 요청/응답 전/후 검증

• 보안 위협 처리

gRPC로도 동일한 작업을 수행할 수 있습니다. gRPC에서의 용어는 다릅니다. 인터셉터라고 불리지만, 비슷한 활동을 수행합니다.

‘greet_app’ 코드베이스의 중간소프트웨어 브랜치에서는 로거와 Prometheus 인터셉터를 통합했습니다.

인터셉터가 Prometheus와 로깅 패키지를 사용하도록 구성된 방법을 여기에서 확인하세요.

그러나 패닉 방지 및 복구(예외 처리), 추적, 인증 등의 목적으로 다른 패키지를 인터셉터에 통합할 수도 있습니다.

gRPC 프레임워크에서 지원하는 중간소프트웨어.

Proto 파일의 패키징, 버전 관리 및 코드 관례

패키징

먼저 패키징 브랜치를 따라가 보겠습니다.

시작은 ‘Taskfile.yaml’에서 작업 ‘gen-pkg’을 살펴보면 ‘protoc –proto_path=packaging packaging/*.proto –go_out=packaging’라고 나와 있습니다. 이는 ‘protoc’(컴파일러)가 ‘packaging/*.proto’ 내의 모든 파일을 ‘–go_out=packaging’ 플래그로 지정된 ‘packaging’ 디렉토리 내에서 해당하는 ‘go’ 파일로 변환한다는 의미입니다.

두 번째로 ‘processor.proto’ 파일에서는 ‘CPU’와 ‘GPU’라는 두 가지 메시지가 정의되어 있습니다. CPU는 내장 데이터 타입의 3개 필드를 가진 단순한 메시지이지만, GPU는 ‘Memory’라는 사용자 정의 데이터 타입을 가지고 있습니다. ‘Memory’는 별도의 메시지로 정의되어 있으며, 완전히 다른 파일에 있습니다.

그렇다면 ‘processor.proto’ 파일에서 ‘Memory’ 메시지를 어떻게 사용할까요? import를 사용합니다.

‘import’를 언급한 후 작업 ‘gen-pkg’을 실행하여 프로토 파일을 생성하려고 하면 오류가 발생합니다. 기본적으로 ‘protoc’는 ‘memory.proto’와 ‘processor.proto’ 두 파일이 서로 다른 패키지에 있다고 가정하기 때문입니다. 따라서 두 파일에서 동일한 패키지 이름을 언급해야 합니다.

선택적인 ‘go_package’는 컴파일러에게 ‘pb’로 패키지 이름을 생성하도록 지시합니다. 다른 언어용 프로토 파일이 생성되면 패키지 이름은 ‘laptop_pkg’가 됩니다.

버전 관리

• gRPC에서는 두 가지 유형의 변경 사항이 있을 수 있습니다. 파괴적인 변경과 비파괴적인 변경입니다.

• 비파괴적인 변경에는 새 서비스 추가, 서비스에 새 메서드 추가, 요청 또는 응답 프로토에 필드 추가, 열거형에 값 추가가 포함됩니다.

• 필드 이름 변경, 필드 데이터 타입 변경, 필드 번호 변경, 패키지, 서비스 또는 메서드 이름 변경 또는 제거와 같은 파괴적인 변경은 서비스의 버전 관리를 요구합니다.

• 선택적 패키징.

코드 관행 

• 요청 메시지는 요청 후미에 `CreateUserRequest`로 끝나야 합니다.

• 응답 메시지는 응답 후미에 `CreateUserResponse`로 끝나야 합니다.

• 응답 메시지가 비어있는 경우 빈 객체 `CreateUserResponse`를 사용하거나 `google.protobuf.Empty`를 사용할 수 있습니다.

• 패키지 이름은 의미를 가져야 하며 버전화되어야 합니다. 예를 들어: 패키지 `com.ic.internal_api.service1.v1`

도구

gRPC 생태계는 문서화, REST 게이트웨이를 위한 gRPC 서버, 사용자 정의 검증기 통합, 린팅 등 개발 외적인 작업에 도움이 되는 다양한 도구를 지원합니다. 다음은 이를 달성하는 데 도움이 될 수 있는 몇 가지 도구입니다:

• protoc-gen-grpc-gateway — gRPC REST API 게이트웨이를 생성하는 플러그인입니다. 이를 통해 gRPC 엔드포인트를 REST API 엔드포인트로 사용할 수 있으며 JSON에서 프로토 변환을 수행합니다. 기본적으로 사용자 정의 어노테이션으로 gRPC 서비스를 정의하면 해당 gRPC 메서드를 JSON 요청을 사용하여 REST를 통해 액세스할 수 있습니다.

• protoc-gen-swagger — grpc-gateway의 동반 플러그인으로, gRPC 게이트웨이에 필요한 사용자 정의 어노테이션을 기반으로 swagger.json을 생성할 수 있습니다. 그런 다음 해당 파일을 선택한 REST 클라이언트(예:  Postman)에 가져와 노출한 메서드로 REST API 호출을 수행할 수 있습니다.

• protoc-gen-grpc-web — 프론트엔드가 백엔드와 gRPC 호출을 통해 통신할 수 있게 하는 플러그인입니다. 이에 대한 별도의 블로그 게시물이 조만간 공개될 예정입니다.

• protoc-gen-go-validators — 이 플러그인을 통해 프로토 메시지 필드에 대한 유효성 검사 규칙을 정의할 수 있습니다. 이를 사용하면 GoLang에서 호출할 수 있는 프로토 메시지용 Validate() 오류 메서드를 생성하여 메시지가 미리 정의된 기대치와 일치하는지 확인할 수 있습니다.

• https://github.com/yoheimuta/protolint — 프로토 파일에 린트 규칙을 추가하는 플러그인입니다.

POSTMAN을 사용한 테스팅

REST API를 postman이나 Insomnia와 같은 도구로 테스트하는 것과 달리, gRPC 서비스를 테스트하기는 다소 불편합니다.

참고: gRPC 서비스는 evans-cli와 같은 도구를 사용하여 CLI에서도 테스트할 수 있습니다. 그러나 반射手 기능이 활성화되지 않은 경우 (프로토 파일의 경로가 필요하면) gRPC 서버에서 반射手 기능을 활성화해야 합니다. 변경 사항을 적용하여 반射手 기능을 활성화하고 evans-cli의 repl 모드에 들어가는 방법을 설명합니다. repl 모드에 들어가면 CLI에서 gRPC 서비스를 직접 테스트할 수 있으며, 이 과정은 evans-cli 깃헙 페이지에 설명되어 있습니다.

Postman은 gRPC 서비스를 테스트하기 위한 베타 버전을 제공합니다.

다음은 그 방법에 대한 단계입니다:

1. Postman 열기

2. 왼쪽 사이드바에서 ‘APIs’로 이동

3. 새 API를 생성하기 위해 ‘+’ 기호를 클릭하세요: 

4. 팝업 창에서 ‘이름’, ‘버전’, ‘스키마 세부 정보’를 입력하고 생성을 클릭하십시오 [깃헙/비트버킷과 같은 소스에서 가져오지 않으려면]. 이 단계는 프로토 계약을 복사 붙여넣기하려는 경우에 관련이 있습니다.

5. 아래와 같이 API가 생성됩니다. 버전 ‘1.0.0’을 클릭하고, 정의로 이동하여 프로토 계약을 입력하세요.

6. 여기서 가져오기는 작동하지 않으므로, 모든 종속 프로토를 한 곳에 보관하는 것이 좋습니다.

7. 위의 단계들은 향후 사용을 위해 계약을 유지하는 데 도움이 됩니다.

8. 그런 다음 ‘새로 만들기’를 클릭하고 ‘gRPC 요청’을 선택하세요:

9. URI를 입력하고 저장된 API 목록에서 프로토를 선택하세요:

10. 요청 메시지를 입력하고 ‘호출’을 선택하세요:

위의 단계에서 우리는 POSTMAN을 통해 gRPC API를 테스트하는 과정을 파악했습니다. gRPC 엔드포인트를 테스트하는 과정은 POSTMAN을 사용하여 REST 엔드포인트를 테스트하는 것과 다릅니다. 기억해야 할 한 가지는 #5에서 프로토 계약을 생성하고 저장할 때, 모든 프로토 메시지와 서비스 정의가 동일한 위치에 있어야 한다는 것입니다. POSTMAN에서는 프로토 메시지를 버전 간에 액세스할 수 있는 방법이 없습니다.

결론

이 게시물에서는 RPC에 대한 아이디어를 개발하고, REST와의 유사성을 그리고 차이점을 논의한 후, Google에 의해 개발된 RPC의 구현인 gRPC를 논의했습니다. 

gRPC는 프레임워크로서 특히 마이크로서비스 기반 아키텍처의 내부 통신에 중요할 수 있습니다. 외부 통신에도 사용할 수 있지만 REST 게이트웨이가 필요합니다. gRPC는 스트리밍 및 실시간 애플리케이션에 필수적입니다. 

Golang이 서버 측 스크립팅 언어로서 자신을 입증하고 있는 방식대로, gRPC는 사실상의 통신 프레임워크로 자신을 입증하고 있습니다.