Cloud Service Mesh 개요
이 문서는 Cloud Service Mesh 및 해당 기능을 학습하려는 네트워크 관리자 및 서비스 소유자를 대상으로 합니다. 부하 분산 API를 사용하는 구성에 적용되는 기존 문서입니다.
Cloud Service Mesh는 애플리케이션 네트워킹을 위한 관리형 컨트롤 플레인입니다. Cloud Service Mesh를 사용하면 트래픽 관리 및 관측 가능성과 같은 고급 애플리케이션 네트워킹 기능을 갖춘 가용성이 높은 전역 서비스를 제공할 수 있습니다.
배포 시 서비스 및 마이크로서비스 수가 증가하면 일반적으로 다음과 같은 일반적인 애플리케이션 네트워킹 문제가 발생하기 시작합니다.
- 서비스를 탄력적으로 설정하려면 어떻게 해야 하나요?
- 서비스에 트래픽을 어떻게 전달하고 서비스가 서로 어떻게 알고 통신하나요?
- 서비스가 서로 통신할 때 어떤 일이 일어나는지 어떻게 알 수 있나요?
- 서비스 중단 없이 서비스를 업데이트하려면 어떻게 해야 하나요?
- 이를 가능하게 하는 인프라를 관리하려면 어떻게 해야 하나요?
Cloud Service Mesh는 현대적인 서비스 기반 배포에서 이러한 유형의 문제를 해결하는 데 도움이 됩니다. Cloud Service Mesh는 Google Cloud 관리 인프라에 의존하므로 자체 인프라를 관리할 필요가 없습니다. 애플리케이션 네트워킹 복잡성의 관리는 Cloud Service Mesh에 맡기고 비즈니스 문제를 해결하는 애플리케이션 코드를 제공하는 데 집중하세요.
Cloud Service Mesh
애플리케이션 네트워킹 문제를 해결하기 위한 일반적인 패턴은 서비스 메시를 사용하는 것입니다. Cloud Service Mesh는 서비스 메시와 필요에 맞는 기타 배포 패턴을 지원합니다.
일반적인 서비스 메시는 다음과 같습니다.
- 서비스를 Kubernetes 클러스터에 배포합니다.
- 각 서비스의 pod에는 사이드카 프록시로 실행되는 전용 프록시(일반적으로 Envoy)가 있습니다.
- 각 사이드카 프록시는 클러스터에 설치된 네트워킹 인프라 (제어 영역)와 통신합니다. 제어 영역은 사이드카 프록시에 서비스 메시의 서비스, 엔드포인트, 정책에 대하여 알려줍니다.
- pod가 요청을 전송하거나 수신하면 요청은 pod의 사이드카 프록시로 이동합니다. 사이드카 프록시는 요청을 의도한 대상에게 보내는 등의 요청을 처리합니다.
이 문서 및 기타 Cloud Service Mesh 문서의 다이어그램에서 6면의 분홍색 아이콘은 프록시를 나타냅니다. 제어 영역은 각 프록시에 연결되어 프록시가 요청을 처리하는 데 필요한 정보를 제공합니다. 상자 사이의 화살표는 트래픽 흐름을 나타냅니다. 예를 들어 Service A의 애플리케이션 코드는 요청을 전송합니다. 프록시는 요청을 처리하여 Service B에 전달합니다.
이 모델을 사용하면 애플리케이션 코드 밖으로 네트워킹 로직을 이동할 수 있습니다. 인프라에서 애플리케이션 네트워킹을 처리하도록 허용하면서 비즈니스 가치를 제공하는 데 집중할 수 있습니다.
Cloud Service Mesh의 차이점
Cloud Service Mesh는 해당 모델과 비슷하게 작동하지만 중요한 차이점이 있습니다. 이 차이점은 Cloud Service Mesh가 Google Cloud 관리형 서비스라는 사실에서 비롯됩니다. 설치하지 않고 클러스터에서 실행되지 않으며 이를 유지관리할 필요가 없습니다.
다음 다이어그램에서 Cloud Service Mesh는 컨트롤 플레인입니다. 이 Kubernetes 클러스터에는 Cloud Service Mesh에 연결된 사이드카 프록시를 각각 사용하는 네 개의 서비스가 있습니다. Cloud Service Mesh는 프록시가 요청을 라우팅하는 데 필요한 정보를 제공합니다. 예를 들어 Service A에 속하는 pod의 애플리케이션 코드는 요청을 전송합니다. 이 pod와 함께 실행되는 사이드카 프록시는 요청을 처리하고 Service B에 속하는 pod로 라우팅합니다.
서비스 메시를 벗어남
Cloud Service Mesh는 일반적인 서비스 메시보다 더 많은 유형의 배포를 지원합니다.
멀티 클러스터 Kubernetes
Cloud Service Mesh를 사용하면 Kubernetes 클러스터 전체에서 작동하는 애플리케이션 네트워킹을 이용할 수 있습니다. 다음 다이어그램에서 Cloud Service Mesh는 us-central1 및 europe-west1에서 Kubernetes 클러스터의 컨트롤 플레인을 제공합니다.
us-central1의 세 가지 서비스, europe-west1의 두 가지 서비스, 두 클러스터의 서비스 간에 요청이 라우팅될 수 있습니다.
서비스 메시는 여러 Google Cloud 리전의 여러 Kubernetes 클러스터에서 확장될 수 있습니다. 한 클러스터의 서비스는 다른 클러스터의 서비스와 통신할 수 있습니다. 또한 여러 클러스터의 pod로 구성된 서비스도 사용할 수 있습니다.
Cloud Service Mesh의 근접 기반 전역 부하 분산을 통해 Service B를 대상으로 하는 요청은 요청을 처리할 수 있는 가장 가까운 포드로 이동합니다. 또한 장애 조치도 원활하게 이루어집니다. pod가 다운되면 요청은 이 pod가 다른 Kubernetes 클러스터에 있더라도 요청에서 처리할 수 있는 다른 pod로 자동으로 장애 조치됩니다.
가상 머신
Kubernetes가 점점 인기가 많아지고 있지만 가상 머신(VM)에 많은 워크로드가 배포됩니다. Cloud Service Mesh는 이러한 워크로드의 애플리케이션 네트워킹도 해결합니다. VM 기반 워크로드는 Kubernetes 기반 워크로드와 상호 운용됩니다.
다음 다이어그램에서는 트래픽이 외부 애플리케이션 부하 분산기를 통해 배포로 들어갑니다. asia-southeast1의 Kubernetes 클러스터에 있는 Service A 및 europe-west1의 VM에서 Service D로 라우팅됩니다.
Google은 Cloud Service Mesh로 VM 기반 워크로드를 설정할 수 있는 원활한 메커니즘을 제공합니다. Compute Engine VM 인스턴스 템플릿에 플래그만 추가하면 Google에서 인프라 설정을 처리합니다. 이 설정에는 애플리케이션 네트워킹 기능을 제공하는 프록시 설치 및 구성이 포함됩니다.
프록시 없는 gRPC
gRPC는 고성능 마이크로서비스를 작성하는 데 사용할 수 있는 기능이 풍부한 오픈소스 RPC 프레임워크입니다. Cloud Service Mesh를 사용하면 애플리케이션 네트워킹 기능(예: 서비스 검색, 부하 분산, 트래픽 관리)을 gRPC 애플리케이션에 가져올 수 있습니다. 자세한 내용은 Cloud Service Mesh 및 gRPC: 서비스 메시용 프록시리스 서비스를 참고하세요.
다음 다이어그램에서 gRPC 애플리케이션은 한 리전의 Kubernetes 클러스터에 기반을 둔 서비스와 다른 리전의 VM에서 실행되는 서비스로 트래픽을 라우팅합니다. 이 중 두 가지 서비스에는 사이드카 프록시가 포함되고 다른 서비스는 프록시리스입니다.
Cloud Service Mesh는 프록시리스 gRPC 서비스를 지원합니다. 이 서비스는 xDS API를 지원하는 최신 버전의 오픈소스 gRPC 라이브러리를 사용합니다. gRPC 애플리케이션은 Envoy에서 사용하는 것과 동일한 xDS API를 사용하여 Cloud Service Mesh에 연결할 수 있습니다.
gRPC 라이브러리는 애플리케이션이 연결되면 서비스 검색, 부하 분산 및 트래픽 관리와 같은 애플리케이션 네트워킹 기능을 처리합니다. 이는 gRPC에서 기본적으로 발생하므로 서비스 프록시가 필요하지 않습니다. 따라서 프록시리스 gRPC 애플리케이션이라고 부릅니다.
인그레스 및 게이트웨이
많은 사용 사례의 경우 Cloud Service Mesh로 구성되지 않은 클라이언트에서 발생하는 트래픽을 처리해야 합니다. 예를 들어 공개 인터넷 트래픽을 마이크로서비스에 인그레스해야 할 수 있습니다. 또한 트래픽을 대상으로 보내기 전에 클라이언트의 트래픽을 처리하는 역방향 프록시로 부하 분산기를 구성할 수도 있습니다.
다음 다이어그램에서 외부 애플리케이션 부하 분산기는 Kubernetes 클러스터의 서비스로 라우팅되는 트래픽을 가지고 외부 클라이언트에 대해 인그레스를 사용 설정합니다. 내부 애플리케이션 부하 분산기는 내부 트래픽을 VM에서 실행되는 서비스로 라우팅합니다.
Cloud Service Mesh는 Cloud Load Balancing과 협력하여 관리형 인그레스 환경을 제공합니다. 외부 또는 내부 부하 분산기를 설정한 후 부하 분산기가 트래픽을 마이크로서비스로 전송하도록 구성합니다. 위의 다이어그램에서 공개 인터넷 클라이언트는 외부 애플리케이션 부하 분산기를 통해 서비스에 도달합니다. Virtual Private Cloud(VPC) 네트워크에 있는 마이크로서비스와 같은 클라이언트는 내부 애플리케이션 부하 분산기를 사용하여 서비스에 연결합니다.
일부 사용 사례에서는 Cloud Service Mesh를 설정하여 게이트웨이를 구성해야 할 수 있습니다. 게이트웨이는 기본적으로 하나 이상의 VM에서 실행되는 전형적인 Envoy인 리버스 프록시로 수신 요청을 리슨하고 처리한 다음 대상으로 전송합니다. 대상은 모든 Google Cloud 리전 또는 Google Kubernetes Engine(GKE) 클러스터에 있을 수 있습니다. 하이브리드 연결을 사용하여 Google Cloud에서 연결할 수 있는 Google Cloud 외부의 대상일 수도 있습니다. 게이트웨이를 사용해야 하는 경우에 대한 자세한 내용은 메시의 인그레스 트래픽을 참조하세요.
다음 다이어그램에서 europe-west1 리전의 VM은 프록시를 실행하지 않는 세가지 서비스의 게이트웨이 역할을 하는 프록시를 실행합니다. 외부 애플리케이션 부하 분산기와 내부 애플리케이션 부하 분산기의 트래픽은 모두 게이트웨이로 라우팅된 후 3개의 서비스로 라우팅됩니다.
여러 환경
Google Cloud, 온프레미스, 다른 클라우드 또는 이 모든 부분 어디에 서비스를 제공하더라도 기본 애플리케이션 네트워킹 문제는 동일하게 유지됩니다. 이러한 서비스로 트래픽을 어떻게 가져오나요? 그리고 이러한 서비스가 서로 어떻게 통신하나요?
다음 다이어그램에서 Cloud Service Mesh는 Google Cloud에서 실행 중인 서비스로부터 다른 퍼블릭 클라우드에서 실행 중인 Service G와 온프레미스 데이터 센터에서 실행 중인 Service E 및 Service F로 트래픽을 라우팅합니다.
Service A, Service B, Service C은 Envoy를 사이드카 프록시로 사용하고 Service D는 프록시리스 gRPC 서비스입니다.
Cloud Service Mesh를 사용하면 Google Cloud 외부의 대상으로 요청을 보낼 수 있습니다. 이렇게 하면 Cloud Interconnect 또는 Cloud VPN을 사용하여 Google Cloud 내부의 서비스에서 다른 환경의 서비스 또는 게이트웨이로 트래픽을 비공개로 라우팅할 수 있습니다.
Cloud Service Mesh 설정
Cloud Service Mesh 설정은 두 단계로 구성됩니다. 설정 프로세스를 완료하면 인프라가 애플리케이션 네트워킹을 처리하고 Cloud Service Mesh가 배포 변경사항을 기반으로 모든 것을 최신 상태로 유지합니다.
애플리케이션 배포
먼저 애플리케이션 코드를 컨테이너 또는 VM에 배포합니다. Google은 애플리케이션 네트워킹 인프라(일반적으로 Envoy 프록시)를 VM 인스턴스와 포드에 추가할 수 있는 메커니즘을 제공합니다. 이 인프라는 Cloud Service Mesh와 통신하고 서비스에 대해 학습하도록 설정되었습니다.
Cloud Service Mesh 구성
다음으로 전역 서비스를 구성하고 트래픽 처리 방법을 정의합니다. Cloud Service Mesh를 구성하려면 Google Cloud 콘솔(일부 기능 및 구성), Google Cloud CLI, Traffic Director API 또는 Terraform과 같은 기타 도구를 사용하면 됩니다.
이 단계를 완료하면 Cloud Service Mesh가 애플리케이션 네트워킹 인프라를 구성할 수 있게 됩니다.
인프라에서 애플리케이션 네트워킹 처리
애플리케이션이 my-service로 요청을 전송하면 애플리케이션 네트워킹 인프라(예: Envoy 사이드카 프록시)는 Cloud Service Mesh에서 받은 정보에 따라 요청을 처리합니다. 이렇게 하면 my-service 요청이 요청을 수신할 수 있는 애플리케이션 인스턴스로 원활하게 라우팅됩니다.
모니터링 및 지속적 업데이트
Cloud Service Mesh는 서비스를 구성하는 애플리케이션 인스턴스를 모니터링합니다. 이 모니터링을 통해 Cloud Service Mesh는 서비스가 정상인지 또는 새 Kubernetes 포드 생성 등으로 인해 서비스 용량이 변경되었는지 확인할 수 있습니다. 이 정보를 기반으로 Cloud Service Mesh는 애플리케이션 네트워킹 인프라를 지속적으로 업데이트합니다.
기능
Cloud Service Mesh의 기능은 마이크로서비스에 애플리케이션 네트워킹 기능을 제공합니다. 몇 가지 주요 내용이 이 섹션에서 설명되어 있습니다.
완전 관리형 제어 영역, 상태 점검 및 부하 분산
인프라 관리가 아닌 비즈니스 가치를 제공하는 데 시간을 소비하고자 합니다. Cloud Service Mesh는 완전 관리형 솔루션이므로 인프라를 설치, 구성, 업데이트할 필요가 없습니다. Google이 상태 점검 및 글로벌 부하 분산에 사용하는 것과 동일한 인프라의 이점을 누릴 수 있습니다.
오픈소스 제품 기반 빌드
Cloud Service Mesh는 Envoy 및 Istio와 같은 오픈소스 프로젝트에 널리 사용되는 동일한 컨트롤 플레인(xDS API)를 사용합니다. 지원되는 API 버전을 보려면 xDS 컨트롤 플레인 API를 참조하세요.
사용 사례에 따라 Envoy 또는 gRPC와 같은 애플리케이션 네트워킹 기능을 제공하는 인프라도 오픈소스이므로 독점 인프라에 종속될 걱정이 없습니다.
확장
Cloud Service Mesh는 일회성 애플리케이션 네트워킹 솔루션부터 수천 개의 서비스를 갖춘 대규모 서비스 메시 배포에 이르기까지 확장 요구사항을 충족하도록 빌드되었습니다.
엔드포인트 및 백엔드 서비스 검색 및 추적
애플리케이션이 my-service에 요청을 보내면 인프라가 원할하게 요청을 처리하고 올바른 대상으로 보냅니다. 애플리케이션은 IP 주소, 프로토콜 또는 기타 네트워킹 복잡성에 대해 아무것도 알 필요가 없습니다.
글로벌 부하 분산 및 장애 조치
Cloud Service Mesh는 Google의 전역 부하 분산 및 상태 점검을 사용하여 클라이언트 및 백엔드 위치, 백엔드 근접성, 상태, 용량을 기준으로 트래픽을 최적으로 조정합니다. 트래픽이 용량이 있는 정상 백엔드로 자동으로 장애 조치를 수행하여 서비스 가용성을 높이세요. 부하 분산을 맞춤설정하여 비즈니스 요구사항을 적절히 지원하도록 트래픽을 분산할 수 있습니다.
트래픽 관리
라우팅 및 요청 조작(호스트 이름, 경로, 헤더, 쿠키 등)을 포함한 고급 트래픽 관리를 통해 서비스 간 트래픽 흐름 방식을 확인할 수 있습니다. 또한 카나리아 배포를 위해 재시도, 리디렉션, 가중치 기반 트래픽 분할과 같은 작업을 적용할 수 있습니다. 결함 주입, 트래픽 미러링, 이상점 감지와 같은 고급 패턴을 사용하면 DevOps 사용 사례를 통해 복원력을 향상시킬 수 있습니다.
관측 가능성
애플리케이션 네트워킹 인프라는 Google Cloud Observability에서 중앙 집중식으로 집계할 수 있는 측정항목, 로그, trace와 같은 원격 분석 정보를 수집합니다. 이 정보가 수집된 후 유용한 정보를 얻고 알림을 만들어 문제가 발생하면 알림을 받을 수 있습니다.
VPC 서비스 제어
VPC 서비스 제어를 사용하여 애플리케이션 리소스와 서비스에 추가 보안을 제공할 수 있습니다. 리소스와 서비스(예: Cloud Service Mesh)를 경계 외부에서 발생하는 요청으로부터 보호하는 서비스 경계에 프로젝트를 추가할 수 있습니다. VPC 서비스 제어에 대한 자세한 내용은 VPC 서비스 제어 개요를 참조하세요.
VPC 서비스 제어와 함께 Cloud Service Mesh를 사용하는 방법에 대한 자세한 내용은 지원되는 제품 페이지를 참조하세요.
다음 단계
부하 분산 API에 주로 적용되는 기존 문서입니다. 부하 분산 API를 사용하여 Cloud Service Mesh를 구성하지 않는 것이 좋습니다.
Cloud Service Mesh를 배포하려면 다음 안내를 따르세요.
- VM이 있는 Compute Engine의 경우 서비스 라우팅 API를 사용합니다.
- 포드가 있는 Google Kubernetes Engine의 경우 Gateway API를 사용합니다.
프록시리스 gRPC 서비스의 사용 사례 및 아키텍처 패턴을 찾으려면 프록시리스 gRPC 서비스 개요를 참조하세요.
트래픽 관리를 통해 트래픽이 처리되는 방식을 제어하는 방법에 대해 자세히 알아보려면 고급 트래픽 관리 개요를 참조하세요
Cloud Service Mesh에서 Google Cloud 외부로 확장되는 환경을 지원하는 방법은 다음 문서를 참고하세요.