gRPC 서비스 퍼블리싱 2탄 – 샘플 gRPC 서비스 실행하기

애플리케이션 운영을 보다 빠르고, 스마트하며, 안전하게 운영할 수 있도록 지원하는 글로벌 No.1 브랜드 <F5 네트웍스 코리아> 공식 블로그를 방문해주신 여러분, 반갑습니다! 지난 번 소개해 드린 gRPC 시리즈 제 1탄 급부상하고 있는 gRPC(링크 클릭)에 대해 보여주신 뜨거운 관심에 힘입어 이번에는 샘플 gRPC 서비스 실행 편을 준비했습니다. 실전을 위한 구체적 정보가 궁금했던 분들이라면 주목해 주세요. 여러 gRPC 서비스가 설치된 간단한 테스트 환경을 통해 기능 및 주요 구성 요소들에 대한 정보를 쉽게 얻어 가실 수 있습니다.

공식 gRPC 가이드에서 helloworld (Go로 작성) 및 RouteGuide (Python으로 작성) 등 2개의 샘플 애플리케이션을 사용합니다. RouteGuide 애플리케이션은 4개의 각 gRPC 서비스 메소드를 포함하고 있기 때문에 매우 유용합니다.

• Simple RPC (단일 요청-응답)

• Response‑streaming RPC

• Request‑streaming RPC

• Bidirectional‑streaming RPC

두 gRPC 서비스 모두 NGINX Plus 호스트상의 Docker 컨테이너로서 설치됩니다. 참고로 F5 네트웍스 코리아 블로그에서는 ‘테스트 환경을 구축하는 지침’에 대한 포스팅도 준비 중이니 꾸준한 관심 부탁드려요!

gRPC 게이트웨이로서 NGINX Plus를 위한 테스트 환경

가용 컨테이너의 주소와 함께 RouteGuide와 helloworld 서비스에 대해 알 수 있도록 NGINX Plus를 구성합니다.

각 gRPC 서비스를 위한 upstream 블록(라인 42–47 및 49–53)을 추가하고 gRPC 서버 코드를 실행하는 개별 컨테이너의 주소와 함께 이를 입력합니다.

gRPC 요청 라우팅

이번에는 gRPC 요청 라우팅에 대해 알아보겠습니다. NGINX Plus가 gRPC (50051)를 위한 일반적인 평문 포트에서 수신 대기하는 경우, 클라이언트 요청이 정확한 백엔드 서비스에 도달할 수 있도록 구성에 라우팅 정보를 추가합니다. 하지만, 먼저 gRPC 메소도 호출을 HTTP/2 요청으로 표현하는 방법을 이해해야 합니다. 아래 그림은 RouteGuide 서비스를 위한 route_guide.proto 파일의 요약 버전을 보여 주고 있으며 NGINX Plus에서와 같이 패키지, 서비스 및 RPC 메소드가 URI를 구성하는 방법을 나타내고 있습니다.

Protocol Buffer RPC 메소드가 HTTP/2 요청으로 전환하는 방법

따라서 HTTP/2 요청에 포함된 정보는 단순히 패키지 이름(여기에서는 routeguide 또는 helloword)을 매칭시켜 라우팅하는 목적으로 사용될 수 있습니다.

첫 번째 location 블록(라인 28)은 수정자 없이 /routeguide.가 해당 패키지를 위한 .proto 파일에서 정의된 모든 서비스 및 RPC 메소드와 일치하도록 prefix 매치를 정의합니다. 따라서 grpc_pass directive(라인 29)은 RouteGuide 클라이언트의 모든 요청을 upstream 그룹 routeguide_service로 전달합니다. 이 구성은 gRPC 패키지와 그 백엔드 서비스 간의 단순한 매핑을 제공합니다.

grpc_pass 지시문에 대한 인수는 평문 plaintext gRPC 연결을 이용해 요청을 프록시하는 grpc:// 구조로 시작합니다. 백엔드가 TLS를 위해 구성된 경우, grpcs:// 구조를 이용해 엔드 투 엔드 암호화로 gRPC 연결을 보호할 수 있습니다.

RouteGuide 클라이언트를 실행한 후, 로그 파일 항목을 검토함으로써 라우팅 동작을 확인할 수 있습니다. 여기에서 RouteChat RPC 메소드는 포트 10002에서 실행되는 컨테이너로 라우팅된 것을 볼 수 있습니다.

정교한 라우팅

지금까지 살펴본 것 처럼 여러 gRPC 서비스를 서로 다른 백엔드로 라우팅하는 것은 단 몇 라인의 구성만을 필요로 하기 때문에 단순하고 효율적입니다. 하지만, 운영 환경의 라우팅 요구 사항은 보다 복잡합니다. 뿐만 아니라 URI의 다른 요소들(gRPC 서비스 또는 심지어 개별 RPC 메소드)을 기반으로 라우팅해야 할 수도 있습니다.

아래의 구성 스니펫은 앞서 나온 예제를 확장한 것으로 bidirectional streaming RPC 메소드 RouteChat가 하나의 백엔드로 라우팅되고 여타 모든 RouteGuide 메소드는 다른 백엔드로 라우팅됩니다.

두 번째 location 지시문(라인 7)은 = (등호) 수정자를 이용해 이것이 RouteChat RPC 메소드를 위한 URI에 완전 일치 매칭(exact match)임을 나타냅니다. 완전 일치 매칭(exact match)은 prefix 매칭 이전에 처리됩니다 이는 RouteChat URI에 여타 그 어떤 location 블록도 고려되지 않는다는 것을 의미합니다.

지금까지 샘플 gRPC 서비스 실행하기와 함께 gRPC 요청 라우팅, 정교한 라우팅에 대해 알려 드렸는데요. 도움이 되셨나요? 🙂 다음 시리즈에서는 일반적인 HTTP 트래픽 관련 에러와는 다소 차이가 있는 gRPC 에러에 응답하는 방법에 대해 다룰 예정이니 놓치지 마세요~ 본 포스팅에 대해 궁금한 사항은 댓글 또는 Contact F5를 통해 문의해 주세요! “Code Connects Us All!” F5 네트웍스 코리아는 귀사의 애플리케이션이 보다 빠르고 스마트하며 안전하게 운영될 수 있도록 항상 최선을 다하겠습니다.

출처 : F5코리아 공식블로그 https://blog.naver.com/f5networks_korea/221921260914

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>