메시의 인그레스 트래픽
서비스 메시는 메시에서 실행되는 서비스 간의 통신을 용이하게 합니다. 메시로 트래픽을 유도하려면 어떻게 해야 할까요? 게이트웨이를 사용하여 진입점을 통해 메시 외부에서 메시로 트래픽을 직접 전달할 수 있습니다.
이 문서에서는 Cloud Load Balancing을 게이트웨이로 사용하여 메시로 트래픽을 가져오는 방법을 설명하고 다음을 포함하고 있습니다.
- 게이트웨이에 대한 높은 수준의 고려사항
- 메시 게이트웨이를 선택할 때의 옵션 개요
- 게이트웨이 토폴로지에 적용할 수 있는 아키텍처 권장 사항
이 문서는 Traffic Director 서비스 라우팅 API에 적용됩니다. 준비 설정 단계를 마친 후 인그레스 게이트웨이를 사용하여 배포하는 지침이 포함된 인그레스 게이트웨이를 위한 Traffic Director 설정을 참조하세요.
서비스 메시를 설계할 때 다음 소스에서 들어오는 트래픽을 고려합니다.
- 메시 내부에서 발생하는 트래픽
- 메시 외부에서 발생하는 트래픽
메시 내부에서 발생하는 트래픽은 서비스 메시 데이터 영역으로 이동하여 대상 서비스와 연결된 백엔드 또는 엔드포인트에 도달합니다. 하지만 메시 외부에서 발생하는 트래픽은 먼저 서비스 메시 데이터 영역에 도달해야 합니다.
메시 내부에서 발생하는 다음 트래픽 예시에서 Traffic Director는 사이드카 프록시를 구성합니다. 이러한 사이드카 프록시는 서비스 메시의 데이터 영역을 형성합니다. 서비스 A가 서비스 B와 통신하려는 경우 다음이 발생합니다.
- 서비스 A가 이름을 사용하여 서비스 B에 요청을 수행합니다.
- 이 요청은 가로채기되고 서비스 A의 사이드카 프록시로 리디렉션됩니다.
- 그런 다음 사이드카 프록시가 서비스 B와 연결된 엔드포인트로 요청을 보냅니다.
다음 예시에서는 트래픽이 서비스 메시 외부에서 발생하여 서비스 메시 데이터 영역을 따라 이동하지 않습니다.
이 예시에서 클라이언트는 서비스 메시의 외부에 있습니다. 메시에 직접 참여하지 않기 때문에 클라이언트가 메시 내부 서비스에 속하는 엔드포인트를 알 수 없습니다. 다시 말해 클라이언트가 Traffic Director로 구성된 프록시를 사용하여 아웃바운드 요청을 전송하지 않으므로, 서비스 A 또는 서비스 B로 트래픽을 전송할 때 사용할 IP 주소-포트 쌍을 알 수 없습니다. 이 정보가 없으면 클라이언트가 메시 내부의 서비스에 연결할 수 없습니다.
게이트웨이 고려사항
이 섹션에서는 다음을 포함하여 게이트웨이를 선택할 때 고려해야 할 문제를 간략하게 설명합니다.
- 클라이언트가 내 게이트웨이에 어떻게 도달할 수 있나요?
- 게이트웨이에 도달하는 트래픽에는 어떤 정책을 적용해야 하나요?
- 게이트웨이에서 메시 내부 서비스로 트래픽을 분산하려면 어떻게 해야 하나요?
클라이언트가 메시의 게이트웨이에 도달할 수 있도록 지원
공개 인터넷, 온프레미스 환경 또는 Google Cloud 내에서 클라이언트는 메시 내의 서비스에 연결할 수 있는 방법이 필요합니다. 메시의 서비스에 연결하려면 일반적으로 게이트웨이로 확인되는 공개 또는 비공개 라우팅 가능한 IP 주소와 포트를 사용해야 합니다. 메시 외부의 클라이언트는 이 IP 주소와 포트를 사용하여 게이트웨이를 통해 메시의 서비스로 요청을 보냅니다.
Cloud Load Balancing은 메시에 게이트웨이로 사용할 수 있는 다양한 부하 분산 옵션을 제공합니다. 게이트웨이로 사용할 Google Cloud 부하 분산기를 선택할 때는 다음과 같은 질문을 확인해야 합니다.
- 클라이언트가 공개 인터넷, 온프레미스 환경 또는 Virtual Private Cloud(VPC) 네트워크 일부에 있나요?
- 클라이언트에 사용되는 통신 프로토콜은 무엇인가요?
클라이언트 위치 및 통신 프로토콜에 따른 Cloud Load Balancing 옵션에 대한 간략한 내용은 메시 게이트웨이 선택 섹션을 참조하세요.
게이트웨이에서 트래픽 처리
게이트웨이는 메시 외부에 있는 클라이언트와 메시 내부에 있는 서비스 사이의 메시 에지에 있으므로 게이트웨이는 트래픽이 메시에 들어올 때 자연스럽게 정책을 적용할 수 있습니다. 이러한 정책에는 다음이 포함됩니다.
- 트래픽 관리(예: 라우팅, 리디렉션, 요청 변환)
- 보안(예: TLS 종료 및 Google Cloud Armor DDoS 보호)
- Cloud CDN 캐싱
메시 게이트웨이 선택 섹션에서는 메시 에지와 관련된 정책을 강조 표시합니다.
게이트웨이에서 메시에 있는 서비스로 트래픽 전송
게이트웨이가 들어오는 트래픽에 정책을 적용한 다음에는 게이트웨이가 트래픽을 전송할 위치를 결정합니다. 트래픽 관리 정책과 부하 분산 정책을 사용하여 이를 구성합니다. 예를 들어 게이트웨이는 요청 헤더를 검사하여 트래픽을 수신해야 하는 메시 서비스를 식별할 수 있습니다. 게이트웨이에서 서비스를 식별한 후 부하 분산 정책에 따라 트래픽을 특정 백엔드로 분산합니다.
메시 게이트웨이 선택 섹션에서는 게이트웨이가 트래픽을 보낼 수 있는 백엔드를 설명합니다.
메시 게이트웨이 선택
Google Cloud는 메시의 게이트웨이 역할을 할 수 있는 다양한 부하 분산기를 제공합니다. 이 섹션에서는 게이트웨이 패턴과 관련된 다음 옵션을 비교하면서 게이트웨이 선택을 논의합니다.
이 섹션에서는 1차 및 2차 게이트웨이를 참조합니다. 이 용어는 하나 또는 여러 개의 게이트웨이를 사용하여 메시에 대한 인그레스 트래픽을 처리하는 데 사용됩니다.
메시에 대해 게이트웨이 역할을 수행하는 한 수준의 단일 부하 분산기만 필요할 수 있습니다. 그렇더라도 일부 경우에는 게이트웨이가 여러 개 필요할 수도 있습니다. 이러한 구성에서는 하나의 게이트웨이가 Google Cloud로 들어오는 트래픽을 처리하고, 별도의 2차 게이트웨이가 서비스 메시에 들어오는 트래픽을 처리합니다.
예를 들어 Google Cloud에 들어오는 트래픽에 대해 Google Cloud Armor 보안 정책을 적용하고 메시에 들어오는 트래픽에 대해 고급 트래픽 관리 정책을 적용해야 할 수 있습니다. 두 번째 Traffic Director 구성 게이트웨이를 사용하는 패턴에 대해서는 메시 에지에서 2차 게이트웨이를 사용하여 인그레스 트래픽 처리 섹션을 참조하세요.
다음 테이블에서는 선택한 게이트웨이 옵션에 따라 사용 가능한 기능을 비교합니다.
| 게이트웨이 | 클라이언트 위치 | 프로토콜 | 정책 | 백엔드/엔드포인트 |
|---|---|---|---|---|
| 내부 애플리케이션 부하 분산기 | 부하 분산기와 동일한 리전에 있는 Google Cloud 기반 클라이언트 요청이 부하 분산기와 동일한 Google Cloud 리전에 도착하는 온프레미스 클라이언트(예: Cloud VPN 또는 Cloud Interconnect 사용) |
HTTP/1.1 HTTP/2 HTTPS |
고급 트래픽 관리 자체 관리형 인증서를 사용하는 TLS 종료 |
부하 분산기와 동일한 Google Cloud 리전의 백엔드로, 다음에서 실행됩니다.
|
| 외부 애플리케이션 부하 분산기 | 공개 인터넷의 클라이언트 | HTTP/1.1 HTTP/2 HTTPS |
트래픽 관리 Cloud CDN(Cloud Storage 버킷 백엔드 포함) Google 또는 자체 관리형 인증서를 사용한 TLS 종료 SSL 정책 DDoS 및 웹 공격 방지를 위한 Google Cloud Armor 사용자 인증용 IAP(Identity-Aware Proxy) 지원 |
다음에서 실행되는 모든 Google Cloud 리전의 백엔드:
|
| 내부 패스 스루 네트워크 부하 분산기 | 모든 리전의 Google Cloud 기반 클라이언트는 클라이언트가 부하 분산기와 다른 리전에 있는 경우 전역 액세스가 필요합니다. 요청이 Google Cloud 리전에 도착하는 온프레미스 클라이언트(예: Cloud VPN 또는 Cloud Interconnect 사용) |
TCP | Compute Engine의 VM에서 실행되는 부하 분산기와 동일한 Google Cloud 리전에 있는 백엔드 | |
| 외부 패스 스루 네트워크 부하 분산기 | 공개 인터넷의 클라이언트 | TCP 또는 UDP | Compute Engine의 VM에서 실행되는 부하 분산기와 동일한 Google Cloud 리전에 있는 백엔드 | |
| 외부 프록시 네트워크 부하 분산기 | 공개 인터넷의 클라이언트 | SSL 또는 TCP | Google 또는 자체 관리형 인증서를 사용한 TLS 종료(SSL 프록시만 해당) SSL 정책(SSL 프록시만 해당) |
다음에서 실행되는 모든 Google Cloud 리전의 백엔드:
|
| Traffic Director에서 구성한 에지 프록시(VM 또는 컨테이너 인스턴스) |
클라이언트는 다음 중 하나에 해당하는 위치에 있어야 합니다.
|
HTTP/1.1 HTTP/2 |
고급 트래픽 관리(regex 지원 포함) |
다음에서 실행되는 모든 Google Cloud 리전의 백엔드:
|
자세한 기능별 비교는 부하 분산기 기능 페이지를 참조하세요. Traffic Director 기능에 대한 자세한 개요는 Traffic Director 기능 페이지를 참조하세요.
게이트웨이 배포 및 구성
게이트웨이 선택 시 마지막으로 고려할 사항은 사용하려는 개발자 환경 및 도구입니다. Google Cloud는 게이트웨이를 만들고 관리하기 위한 여러 방법을 제공합니다.
Google Cloud CLI 및 Compute Engine API
Google Cloud의 관리형 부하 분산 제품과 Traffic Director를 구성하려면 Google Cloud CLI와 Compute Engine API를 사용하면 됩니다. gcloud CLI 및 API는 Google Cloud 리소스를 명령적으로 배포하고 구성하는 메커니즘을 제공합니다. 반복되는 태스크를 자동화하려면 스크립트를 만들면 됩니다.
Google Cloud Console
Traffic Director 및 Google Cloud의 관리형 부하 분산기를 구성하려면 Google Cloud Console을 사용하면 됩니다.
게이트웨이 패턴을 구성하려면 Traffic Director 페이지와 부하 분산 페이지가 모두 필요할 수 있습니다.
GKE 및 멀티 클러스터 인그레스
GKE 및 GKE Enterprise 네트워크 컨트롤러는 컨테이너 네트워킹과의 기본 통합을 위한 Cloud Load Balancing 배포도 지원합니다. 게이트웨이 배포 및 구성을 위한 Kubernetes-style 선언 인터페이스를 제공합니다. GKE 인그레스 및 멀티 클러스터 인그레스 컨트롤러는 단일 클러스터 또는 여러 GKE 클러스터로 트래픽을 전송하기 위한 내부 및 외부 부하 분산기를 관리합니다. 인그레스 리소스는 GKE 클러스터에 배포된 Traffic Director 구성 서비스를 가리키도록 구성할 수도 있습니다.
게이트웨이 아키텍처 패턴
이 섹션에서는 게이트웨이의 대략적인 패턴을 설명하며 아키텍처 다이어그램을 제공합니다.
가장 일반적인 패턴은 Google Cloud 관리형 부하 분산기를 게이트웨이로 사용하는 것입니다.
클라이언트는 게이트웨이 역할을 하는 Google Cloud 관리형 부하 분산기로 트래픽을 전송합니다.
- 게이트웨이가 정책을 적용합니다.
게이트웨이가 메시의 서비스로 트래픽을 보냅니다.
고급 패턴에는 두 가지 수준의 게이트웨이가 포함됩니다. 게이트웨이는 다음과 같이 작동합니다.
클라이언트는 1차 게이트웨이 역할을 하는 Google Cloud 관리형 부하 분산기로 트래픽을 전송합니다.
- 게이트웨이가 정책을 적용합니다.
게이트웨이는 트래픽을 Traffic Director에서 구성한 에지 프록시(또는 에지 프록시 풀)로 보냅니다. 이 에지 프록시는 2차 게이트웨이 역할을 합니다. 이 수준은 다음을 수행합니다.
예를 들어 한 팀이 Google Cloud로 들어오는 인그레스 트래픽을 담당하고 다른 팀은 해당 팀의 메시로 들어오는 인그레스 트래픽을 담당하는 문제를 명확히 구분해 제공합니다.
Google Cloud 관리형 부하 분산기에서 지원되지 않을 수 있는 정책을 적용합니다.
2차 게이트웨이는 메시의 서비스로 트래픽을 전송합니다.
트래픽이 메시 내 서비스에 도달하면 인그레스 패턴이 종료됩니다. 다음 섹션에서는 일반적인 사례와 고급 패턴을 모두 설명합니다.
인터넷에서 인그레스 트래픽 사용 설정
클라이언트가 Google Cloud 외부에 있고 공개 인터넷을 통해 Google Cloud에 연결해야 하는 경우 다음 부하 분산기 중 하나를 게이트웨이로 사용할 수 있습니다.
이 패턴에서 Google Cloud 관리형 부하 분산기는 게이트웨이 역할을 합니다. 게이트웨이는 인그레스 트래픽을 메시의 서비스로 전달하기 전에 처리합니다.
예를 들어 외부 애플리케이션 부하 분산기를 게이트웨이로 선택하여 다음을 사용할 수 있습니다.
- 지연 시간과 네트워크 순회 비용을 최소화하는 공개 라우팅 가능한 Anycast IP 주소
- 메시 트래픽 보안을 위한 Google Cloud Armor 및 TLS 종료
- 웹 및 동영상 콘텐츠 전송을 위한 Cloud CDN
- 호스트 및 경로 기반 라우팅과 같은 트래픽 관리 기능
적절한 게이트웨이를 결정하는 데 도움이 되는 자세한 내용은 메시 게이트웨이 선택 섹션을 참조하세요.
VPC 및 연결된 온프레미스 네트워크에서 클라이언트의 인그레스 트래픽 사용 설정
클라이언트가 VPC 네트워크 내부에 있거나 온프레미스에 있고 비공개 연결 메서드(예: Cloud VPN 또는 Cloud Interconnect)를 사용하여 Google Cloud 서비스에 연결할 수 있는 경우 다음 부하 분산기 중 하나를 게이트웨이로 사용할 수 있습니다.
이 패턴에서 Google Cloud 관리형 부하 분산기는 게이트웨이 역할을 합니다. 게이트웨이는 인그레스 트래픽을 메시의 서비스로 전달하기 전에 처리합니다.
예를 들어 내부 애플리케이션 부하 분산기를 게이트웨이로 선택하여 다음 기능을 사용할 수 있습니다.
- 비공개 주소로 지정할 수 있는 IP 주소
- 메시 보안을 위한 TLS 종료
- 가중치 기반 트래픽 분할과 같은 고급 트래픽 관리 기능
- NEG로 백엔드
적절한 게이트웨이를 결정하는 데 도움이 되는 자세한 내용은 메시 게이트웨이 선택 섹션을 참조하세요.
메시 에지에 있는 2차 게이트웨이를 사용하여 인그레스 트래픽 처리
필요에 따라 게이트웨이를 추가하는 고급 패턴을 고려할 수도 있습니다.
이 게이트웨이는 Google Cloud 관리형 부하 분산기 뒤에 있는 Traffic Director 구성 에지 프록시(또는 프록시 풀)입니다. Compute Engine VM(관리형 인스턴스 그룹) 또는 GKE 서비스의 풀을 사용하여 프로젝트에서 이 2차 게이트웨이를 호스팅할 수 있습니다.
이 패턴은 고급 옵션이지만 추가적인 이점을 제공합니다.
Google Cloud 관리형 부하 분산기는 초기 정책 모음(예: 외부 애플리케이션 부하 분산기를 사용하는 경우 Google Cloud Armor 보호)을 적용합니다.
Traffic Director로 구성된 에지 프록시는 Google Cloud 관리형 부하 분산기에서 사용할 수 없는 두 번째 정책 집합을 적용합니다. 이러한 정책에는 HTTP 헤더 및 가중치 기반 트래픽 분할에 적용되는 정규 표현식을 사용하는 고급 트래픽 관리가 포함됩니다.
이 패턴은 조직 구조를 반영하여 설정할 수 있습니다. 예를 들면 다음과 같습니다.
한 팀은 Google Cloud에 대한 인그레스 트래픽을 처리하고 다른 팀은 메시에 대한 인그레스 트래픽을 처리해야 합니다.
여러 팀이 하나의 공유 VPC에서 서비스를 제공하는 경우 각 팀은 자체 서비스 프로젝트를 소유하며 이 패턴을 사용하여 자체 메시에서 정책을 관리하고 적용할 수 있습니다. 각 팀은 단일 IP 주소 및 포트 쌍에서 연결할 수 있는 Traffic Director 구성 게이트웨이를 노출할 수 있습니다. 그러면 팀은 팀의 메시로 들어오는 인그레스 트래픽에 적용되는 정책을 독립적으로 정의하고 관리할 수 있습니다.
이 패턴은 부하 분산기가 Traffic Director로 구성된 게이트웨이를 호스팅하는 백엔드로 트래픽을 전송할 수 있는 한 모든 Google Cloud 관리형 부하 분산기를 사용하여 구현할 수 있습니다.
인그레스 트래픽에 서비스 라우팅 API 사용
서비스 라우팅 API는 인그레스 게이트웨이로 작동하는 Envoy 프록시의 트래픽 관리 및 보안을 구성하기 위한 Gateway 리소스를 제공하여 외부 클라이언트가 서비스 메시(North-South)에 연결할 수 있도록 합니다.
자세한 내용은 서비스 라우팅 개요 및 인그레스 게이트웨이 설정을 참조하세요.
다음 단계
- 코드를 서비스의 엔드포인트로 실행하는 VM 및 컨테이너를 그룹화하려면 Traffic Director 서비스 검색을 참조하세요.
- 공유 VPC에서 Traffic Director를 사용하려면 멀티 클러스터 서비스 메시 설정을 참조하세요.
- Traffic Director에 대한 자세한 내용은 Traffic Director 개요를 참조하세요.