gRPC 서비스 퍼블리싱 1탄 – 급부상하고 있는 gRPC란?

애플리케이션 운영을 보다 빠르고, 스마트하며, 안전하게 운영할 수 있도록 지원하는 글로벌 No.1 브랜드​ <F5 네트웍스 코리아> 공식 블로그를 방문해주신 여러분, 반갑습니다! 최근 분산 애플리케이션과 특히 마이크로서비스 개발을 위한 대안으로 부상하고 있는 것이 무엇인지 아시나요? 바로 ‘gRPC’입니다. 구글에서 개발된 gRPC는 2015년에 오픈소스로 제공되었으며, 현재는 CNCF(Cloud Native Computing Foundation)의 새로운 프로젝트 중 하나입니다. F5네트웍스 코리아 블로그에서는 급부상하고 있는 흐름에 따라 gRPC 서비스 퍼블리싱 시리즈를 준비했습니다. 1탄에서는 gRPC란 무엇인지 알아보는 시간을 갖도록 하겠습니다.​

gRPC는 HTTP/2를 전송 방식으로 활용합니다. 그렇기 때문에 바이너리 데이터 형식의 이점과 다중화 된 스트리밍 기능을 활용할 수 있습니다. 이번 시리즈에서는 gRPC의 주요 이점을 먼저 알아보고, 예제를 통해 알기 쉽게 설명해 드리겠습니다. 참고로 별도로 언급한 경우를 제외하고 본 시리즈에 포함된 모든 정보는 NGINX Plus 및 NGINX Open Source 모두에 해당된다는 사실 기억하세요!

​• 강결합 구조의 인터페이스 정의 언어(프로토콜 버퍼)• 스트리밍 데이터에 대한 네이티브 지원(양방향으로)• 효율적인 바이너리 데이터 형식• 많은 프로그래밍 언어를 위한 자동 코드 생성을 통해 상호 운영성 문제없이 진정한 다수 프로그래밍 언어 개발 환경 실현​

gRPC 게이트웨이 정의하기

이전에 NGINX 카테고리를 통해 소개해드린 <NGINX Plus 및 API 게이트웨이로 시작하기> 시리즈나 <백엔드 API 서비스 보호하기>시리즈에서는 https://api.example.com과 같이 단일 진입 지점을 통해 다수의 API들을 제공하는 방법을 설명했습니다. gRPC은 트래픽의 기본 동작 및 특성에 따라, NGINX Plus를 gRPC 게이트웨이로서 구축할 때와 동일한 접근 방식으로사용할 수 있습니다. 동일한 호스트 이름 및 포트에서 HTTP 및 gRPC 트래픽 모두 공유하는 것도 가능합니다. 그렇지만 이를 분리하는 것은 아래와 같은 이유들로 바람직하지 않습니다.

• REST 및 gRPC 애플리케이션용 API 클라이언트들은 서로 다른 형식의 오류 응답을 받을 것으로 기대합니다.

• 액세스 로그를 위한 관련 필드는 REST와 gRPC에 따라 다릅니다.

• gRPC는 절대 레거시 웹 브라우저를 다루지 않기 때문에 보다 엄격한 TLS 정책을 가질 수 있습니다.

​이러한 분리를 달성하기 위해 /etc/nginx/conf.d 디렉토리에 위치한 메인 gRPC 구성 파일, grpc_gateway.conf의 고유한 server{} 블록 내에 gRPC 게이트웨이를 위한 구성을 추가합니다.

​​

라인 1-4처럼 gRPC 트래픽을 위한 액세스 로그에 항목 형식을 정의하는 것으로 시작합니다. 위의 예제에서는 JSON 형식을 사용해 각 요청에서 가장 연관성 높은 데이터를 포착합니다. 예를 들어, 모든 gRPC 요청은 POST를 사용하기 때문에, HTTP 메소드는 포함되어 있지 않다는 점을 유의해야 합니다. gRPC 상태 코드는 물론, HTTP 상태 코드도 기록하지만, gRPC 상태 코드는 여러 다양한 방식으로 생성될 수 있습니다. 정상 조건에서 grpc-status는 백엔드로부터 HTTP/2 트레일러로서 반환됩니다. 다만 일부 오류 조건의 경우, 백엔드 또는 NGINX Plus 자체에 의해 HTTP/2 헤더로서 반환될 수 있습니다. 액세스 로그를 단순화하기 위해 map 블록(라인 6–11)을 사용해 새 변수 $grpc_status를 평가하고 출처에 관계없이 gRPC 상태를 입수합니다.

이 구성은 평문(포트 50051) 및 TLS로 보호된(포트 443) 트래픽 모두를 테스트할 수 있도록 2개의 listen 지시문(라인 14 및 15)을 포함하고 있습니다. http2 매개변수는 NGINX Plus가 HTTP/2 연결을 수용하도록 구성합니다. 이는 ssl 매개변수와는 독립적입니다. 또한 포트 50051은 gRPC을 위한 일반적인 평문 포트이지만, 운영 환경에서 사용하기에는 적합하지 않다는 점도 유념해야 합니다.

TLS 1.2를 가장 취약한 허용 프로토콜로 지정한 ssl_protocols 지시문(라인 25)을 제외하면, 이 TLS 구성이 일반적입니다. HTTP/2 스펙은 TLS 1.2(또는 상위 버전)의 사용을 의무로 규정하고 있으며, 이에 따라 모든 클라이언트가 TLS에 대한 SNI(Server Name Indication) 확장을 지원하도록 보장합니다. 이는 gRPC 게이트웨이가 다른 server{} 블록에서 정의된 가상 서버와 포트 443을 공유할 수 있다는 것을 의미합니다.

지금까지 gRPC를 알아보고 게이트웨이로 정의하는 방법에 대해 알아보았습니다. gRPC에 대해 더 많은 것이 궁금하신 분들은 다음 시리즈도 주목해 주세요. 2탄에서는 샘플 gRPC 서비스 실행을 통해 NGINX Plus의 gRPC 기능을 살펴보고 주요 구성 요소들을 확인해 볼 예정입니다. 이번 포스팅에 대해 궁금한 사항은 댓글 또는 Contact F5를 통해 문의해 주세요! “Code Connects Us All!” F5 네트웍스 코리아는 귀사의 애플리케이션이 보다 빠르고 스마트하며 안전하게 운영될 수 있도록 항상 최선을 다하겠습니다.

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

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>