Cloud Service Mesh 개요
Cloud Service Mesh는 Google Cloud 및 지원되는 GKE Enterprise 플랫폼 전반에서 사용할 수 있는 서비스 메시입니다. 다양한 컴퓨팅 인프라에서 실행되는 서비스를 지원합니다. Cloud Service Mesh는 Google Cloud, 오픈소스 또는 둘 다를 위해 설계된 API로 제어됩니다.
이 문서는 Cloud Service Mesh 신규 사용자 또는 기존의 Anthos Service Mesh나 Traffic Director 고객을 대상으로 합니다.
서비스 메시란 무엇인가요?
서비스 메시는 서비스 간에 관리되는 통신, 관측 가능한 통신, 보안 통신을 사용 설정하여 선택된 인프라의 여러 마이크로서비스로 구성된 강력한 엔터프라이즈 애플리케이션을 더 쉽게 만들 수 있게 해주는 아키텍처입니다. 서비스 메시는 일관되고 강력한 도구를 사용하여 모니터링, 네트워킹, 보안과 같은 서비스 실행과 관련된 일반적인 요구사항을 관리하므로 서비스 개발자와 운영자는 사용자를 위한 훌륭한 애플리케이션을 만들고 관리하는 데 집중할 수 있습니다.
구조적으로 서비스 메시는 1개 이상의 제어 영역과 데이터 영역으로 구성됩니다. 서비스 메시는 서비스의 모든 인바운드 및 아웃바운드 트래픽을 모니터링합니다. Kubernetes에서 프록시는 사이드카 패턴에 의해 메시의 마이크로서비스에 배포됩니다. Compute Engine에서는 VM에 프록시를 배포하거나 데이터 영역에 프록시리스 gRPC를 사용할 수 있습니다.
이 패턴은 애플리케이션 또는 비즈니스 로직을 네트워크 기능에서 분리하므로 개발자는 비즈니스에 필요한 기능에 집중할 수 있습니다. 또한 서비스 메시를 사용하면 운영팀과 개발팀이 작업을 서로 분리할 수 있습니다.
애플리케이션을 마이크로서비스로 설계하면 많은 이점이 있습니다. 하지만 워크로드가 확장됨에 따라 더 복잡해지고 파편화될 수 있습니다. 서비스 메시는 단편화 문제를 해결하고 마이크로서비스를 더 쉽게 관리하는 데 도움이 됩니다.
Cloud Service Mesh란 무엇인가요?
Cloud Service Mesh는 Google Cloud와 지원되는 GKE Enterprise 환경 모두를 위한 Google의 솔루션입니다.
- Google Cloud: Cloud Service Mesh는 워크로드가 실행되는 컴퓨팅 인프라에 맞는 API를 제공합니다.
- Compute Engine 워크로드의 경우 Cloud Service Mesh는 Google Cloud 전용 서비스 라우팅 API를 사용합니다.
- Google Kubernetes Engine(GKE) 워크로드의 경우 Cloud Service Mesh는 오픈소스 Istio API를 사용합니다.
- Google Cloud 외부: Distributed Cloud 또는 GKE 멀티 클라우드에서 Cloud Service Mesh는 Kubernetes 워크로드의 Istio API를 지원합니다.
Cloud Service Mesh를 사용하면 Google Cloud를 사용하든 사용하지 않든 애플리케이션 코드를 변경하지 않고도 서비스를 관리, 관찰, 보호할 수 있습니다.
Cloud Service Mesh는 트래픽 관리에서 메시 원격 분석, 서비스 간 통신 보안까지 서비스 제공을 간소화하여 운영 및 개발팀의 부담을 줄여줍니다. Google의 완전 관리형 서비스 메시를 사용하면 복잡한 환경을 관리하고 약속된 이점을 누릴 수 있습니다.
기능
Cloud Service Mesh에는 트래픽 관리, 관측 가능성 및 원격 분석, 보안을 위한 기능 모음이 있습니다.
트래픽 관리
Cloud Service Mesh는 메시 내의 서비스 간 트래픽 흐름, 메시 내부로의 트래픽 흐름(인그레스), 외부 서비스로의 트래픽 흐름(이그레스)을 제어합니다. 리소스를 구성하고 배포하여 애플리케이션(L7) 레이어에서 이 트래픽을 관리합니다. 예를 들어 다음을 수행할 수 있습니다.
- 서비스 검색 사용
- 서비스 간의 부하 분산 구성
- 카나리아 및 블루-그린 배포 만들기
- 서비스의 라우팅을 세부적으로 제어
- 회로 차단기 설정
Cloud Service Mesh는 메시 내 모든 서비스의 목록을 이름과 해당 엔드포인트별로 유지합니다. 이 목록은 트래픽 흐름을 관리하기 위해 유지됩니다(예: Kubernetes 포드 IP 주소 또는 관리형 인스턴스 그룹의 Compute Engine VM IP 주소). 이 서비스 레지스트리를 사용하고 프록시를 서비스와 나란히 실행하면 메시는 트래픽을 적절한 엔드포인트로 전송할 수 있습니다. 프록시리스 gRPC 워크로드는 Envoy 프록시를 사용하는 워크로드와 동시에 사용할 수도 있습니다.
관측 가능성 통계
Google Cloud 콘솔의 Cloud Service Mesh 사용자 인터페이스는 서비스 메시에 대한 유용한 정보를 제공합니다. 이러한 측정항목은 Istio API를 통해 구성된 워크로드에 자동으로 생성됩니다.
- 메시의 GKE 클러스터 내 HTTP 트래픽의 서비스 측정항목 및 로그는 Google Cloud에 자동으로 수집됩니다.
- 사전 구성된 서비스 대시보드는 서비스를 이해하는 데 필요한 정보를 제공합니다.
- Cloud Monitoring, Cloud Logging, Cloud Trace를 기반으로 한 심층 원격 분석으로 서비스 측정항목 및 로그를 자세히 확인할 수 있습니다. 다양한 속성별로 데이터를 필터링 및 세분화할 수 있습니다.
- 서비스 간 관계를 한눈에 볼 수 있어 서비스 간 의존 관계와 각 서비스에 연결된 사용자를 한눈에 파악할 수 있습니다.
- 보유 서비스의 통신 보안 상태뿐 아니라 다른 서비스와의 관계를 신속하게 확인할 수 있습니다.
- 서비스 수준 목표(SLO)는 서비스 상태에 관한 유용한 정보를 제공합니다. SLO를 정의하고 자체 서비스 상태 표준을 알릴 수 있습니다.
관측 가능성 가이드에서 Cloud Service Mesh의 관측 가능성을 자세히 알아보세요.
보안 이점
Cloud Service Mesh는 다양한 보안 이점을 제공합니다.
- 도용된 사용자 인증 정보를 사용하는 재생 또는 명의 도용 공격의 위험을 완화합니다. Cloud Service Mesh는 JSON 웹 토큰(JWT)과 같은 Bearer 토큰이 아닌 상호 TLS(mTLS) 인증서를 사용하여 피어를 인증합니다.
- 전송 중인 데이터 암호화를 보장합니다. 인증에 대한 mTLS를 사용하면 전송 시 모든 TCP 통신이 암호화됩니다.
- 승인되지 않은 클라이언트가 클라이언트의 네트워크 위치와 애플리케이션 수준 사용자 인증 정보와 관계없이 민감한 정보를 포함한 서비스에 액세스할 수 있는 위험을 완화합니다.
- 프로덕션 네트워크 내에서 사용자 데이터 위반 위험을 완화합니다. 내부 사용자가 승인된 클라이언트를 통해서만 민감한 정보에 액세스하도록 할 수 있습니다.
- 민감한 정보를 포함한 서비스에 액세스한 클라이언트를 식별합니다. Cloud Service Mesh 액세스 로깅은 IP 주소와 함께 클라이언트의 mTLS ID를 캡처합니다.
- 모든 클러스터 내 컨트롤 플레인 구성요소는 FIPS 140-2 검증 암호화 모듈로 빌드됩니다.
보안 가이드에서 Service Mesh의 보안 이점과 기능을 자세히 알아보세요.
배포 옵션
Cloud Service Mesh에는 다음과 같은 배포 옵션이 있습니다.
- Google Cloud 측
- 관리형 Cloud Service Mesh - GKE용 관리형 컨트롤 및 데이터 영역(권장)
- 관리형 Cloud Service Mesh - VM이 있는 Compute Engine용 관리형 컨트롤 및 데이터 영역(권장)
- Istio API가 있는 GKE용 클러스터 내 컨트롤 플레인(권장하지 않음)
- Google Cloud 외부
- Istio API가 있는 Kubernetes용 클러스터 내 컨트롤 플레인
관리형 Cloud Service Mesh
관리형 Cloud Service Mesh는 모든 인프라의 관리형 컨트롤 플레인과 GKE의 관리형 데이터 영역으로 구성됩니다. 관리형 Cloud Service Mesh를 사용하면 Google에서 업그레이드, 확장, 보안을 자동으로 처리하므로 사용자가 직접 유지보수할 필요가 최소화됩니다. 여기에는 컨트롤 플레인, 데이터 영역, 관련 리소스가 포함됩니다.
데이터 영역 구현
Google Cloud API를 사용하는 경우 데이터 영역은 Envoy 프록시 또는 프록시리스 gRPC 애플리케이션에서 제공할 수 있습니다. 기존 애플리케이션을 업데이트하는 경우 사이드카 기반 접근 방식을 사용하면 애플리케이션을 변경하지 않고도 메시에 통합할 수 있습니다. 사이드카 실행의 오버헤드를 피하려면 gRPC를 사용하도록 애플리케이션을 업데이트하면 됩니다.
Envoy 프록시와 프록시리스 gRPC는 모두 xDS API를 사용하여 컨트롤 플레인에 연결합니다. 프록시리스 gRPC를 사용하는 경우 Go, C++, Java, Python 등 애플리케이션에 지원되는 언어를 선택할 수 있습니다.
오픈소스 Istio API를 사용하는 경우 데이터 영역은 Envoy 프록시에서 제공합니다.
컨트롤 플레인 구현
Cloud Service Mesh 컨트롤 플레인은 Google Cloud에서 사용 설정되어 있는지 여부와 신규 고객인지 여부에 따라 구성이 다릅니다.
기존 사용자를 위한 컨트롤 플레인 구현
- 구성이 Google Cloud에서 외부에 있는 경우 Cloud Service Mesh의 클러스터 내 비관리형 컨트롤 플레인을 사용하고 있는 것입니다. 자세한 내용은 클러스터 내 컨트롤 플레인 지원 기능을 참고하세요.
- Google Cloud의 Anthos Service Mesh 사용자인 경우 Istio API를 사용하고 있는 것입니다. 자세한 내용은 Istio API를 사용하는 지원 기능(관리형 컨트롤 플레인)을 참고하세요.
- Traffic Director 사용자인 경우 Google Cloud API와 함께 Cloud Service Mesh의 관리형 컨트롤 플레인을 사용하고 있습니다. 자세한 내용은 Google Cloud API 지원 기능이 있는 Cloud Service Mesh를 참고하세요.
현재 컨트롤 플레인을 확인하려면 컨트롤 플레인 구현 식별을 참고하세요. 컨트롤 플레인 및 컨트롤 플레인 마이그레이션에 관한 자세한 내용은 기존 고객을 위한 관리형 컨트롤 플레인 개요를 참고하세요.
신규 사용자를 위한 컨트롤 플레인 구현
- Google Cloud 외부 구성을 계획한다면 Cloud Service Mesh의 클러스터 내 비관리형 컨트롤 플레인을 선택하는 것입니다. 자세한 내용은 클러스터 내 컨트롤 플레인 지원 기능을 참고하세요.
- Kubernetes에서 Google Cloud 온프레미스 구성을 계획하는 경우 Istio API를 선택하지만 컨트롤 플레인은 컨트롤 플레인 구현을 결정하는 요소에 자세히 설명된 특정 사례를 제외하고 Traffic Director 구현을 사용합니다. 자세한 내용은 Istio API를 사용하는 지원 기능(관리형 컨트롤 플레인)을 참고하세요.
- Compute Engine VM에서 Google Cloud 온프레미스 구성을 계획하는 경우 컨트롤 플레인은 Traffic Director 구현이라고 하는 전역 멀티 테넌트 컨트롤 플레인을 사용합니다. 자세한 내용은 Google Cloud API 지원 기능이 있는 Cloud Service Mesh를 참고하세요.
컨트롤 플레인 마이그레이션
Anthos Service Mesh를 계속 사용하는 고객이 Istio API를 사용하는 경우 클러스터가 Traffic Director 컨트롤 플레인으로 마이그레이션되기 시작합니다. 구성에는 Istio API를 계속 사용할 수 있습니다.
클러스터에서 여전히 Istio 컨트롤 플레인을 사용하는지 또는 새 전역 컨트롤 플레인으로 마이그레이션했는지 확인하려면 컨트롤 플레인 구현 식별을 참고하세요.
다음 단계
- 기존 사용자인 경우 기존 고객을 위한 관리형 컨트롤 플레인을 참고하세요.
- GKE로 설정하려면 컨트롤 플레인 프로비저닝을 참고하세요.
- Compute Engine 및 VM으로 설정하려면 Envoy 및 프록시리스 워크로드로 서비스 라우팅 API 설정 준비를 참고하세요.