Traffic Director의 기능
Traffic Director를 사용하면 글로벌 서비스 메시에서 마이크로서비스를 실행할 수 있습니다. 메시는 기본 네트워킹 복잡성에 대해 알 필요가 없는 애플리케이션 코드를 작성할 수 있도록 마이크로서비스의 네트워킹을 처리합니다. 애플리케이션 로직을 네트워킹 로직과 분리하면 개발 속도를 높이고 서비스 가용성을 높이며 최신 DevOps 관행을 조직에 도입할 수 있습니다.
서비스 메시는 애플리케이션, xDS 호환 데이터 영역(일반적으로 오픈소스 Envoy 프록시) 및 메시 제어 영역인 Traffic Director로 구성됩니다.
서비스 메시에 Traffic Director로 프록시리스 gRPC 서비스를 배포하려면 지원되는 gRPC 버전을 사용하면 됩니다.
이 문서에는 Traffic Director에서 사용할 수 있는 기능이 요약되어 있습니다. 'N/A(해당 없음)'은 해당 기능이 특정 Traffic Director 구성과 호환되지 않으므로 지원되지 않음을 의미합니다. 체크표시나 N/A 표시가 없는 공백은 이 기능이 지원되지 않지만 향후에 지원될 수 있음을 의미합니다.
서비스 메시를 위한 완전 관리형 제어 영역
Traffic Director는 Google Cloud에서 실행되는 관리형의 가용성이 높은 제어 영역 서비스입니다. 제어 영역을 설치하거나 업데이트할 필요가 없으므로 서비스 메시 인프라에서 관리할 구성요소가 하나 줄어듭니다.
지원되는 xDS 버전
Traffic Director는 오픈소스 xDS 제어 영역 API를 사용하여 Envoy 및 프록시리스 gRPC 클라이언트를 구성합니다. 이러한 클라이언트는 애플리케이션 코드를 대신하여 Traffic Director의 애플리케이션 네트워킹 기능을 제공합니다.
| 버전 | 지원 |
|---|---|
| xDS v2 | 일반 안정화 버전으로 출시되었습니다. 서비스 보안을 비롯한 특정 기능은 xDS v3에서만 사용할 수 있습니다. xDS v2 지원은 2024년 6월 20일에 종료됩니다. |
| xDS v3 | 일반 안정화 버전 |
메시 서비스를 실행하는 플랫폼
다음 플랫폼에서 애플리케이션을 실행하고 Traffic Director에서 구성한 글로벌 서비스 메시로 채택할 수 있습니다.
| 기능 | 지원됨 |
|---|---|
| Compute Engine 가상 머신(VM) 인스턴스 | ✔ |
| Google Kubernetes Engine(GKE) 컨테이너 인스턴스 | ✔ |
| Compute Engine 컨테이너 인스턴스의 Kubernetes | ✔ |
서비스 관리
Traffic Director에서 구성된 메시의 서비스는 다음의 이점을 누릴 수 있습니다.
서비스 검색 메시의 애플리케이션이 다른 애플리케이션에 도달하려는 경우 이름으로 해당 서비스를 호출할 수 있습니다.
백엔드 자동 확장. 애플리케이션 코드를 실행하는 인스턴스는 필요에 따라 동적으로 확장 또는 축소됩니다.
자동 엔드포인트 등록. 새 인스턴스가 생성되거나 삭제되면 서비스와 자동으로 연결됩니다.
| 기능 | 지원됨 |
|---|---|
| Compute Engine VM용 사이드카 프록시 자동 배포 | ✔ |
| GKE 포드용 사이드카 프록시 자동 삽입 | ✔ |
| 호스트 이름을 기반으로 서비스 검색 | ✔ |
| CPU 사용률을 기반으로 인스턴스 자동 확장 | ✔ |
| 트래픽 로드/제공 용량에 따른 인스턴스 자동 확장 (관리형 인스턴스 그룹의 Compute Engine VM 또는 MIG에만 해당) |
✔ |
| 구성 가능한 상태 확인 기반의 인스턴스 자동 복구 | ✔ |
| Compute Engine VM용 자동 엔드포인트 등록 | ✔ |
| GKE 컨테이너 인스턴스/포드의 자동 엔드포인트 등록 | ✔ |
| 서비스 디렉터리의 서비스를 백엔드 서비스에 바인딩 | ✔ |
| 엔드포인트를 프로그래매틱 방식으로 추가하거나 삭제하는 API | ✔ |
데이터 영역 트래픽의 엔드포인트
마이크로서비스는 데이터 영역을 사용하여 메시와 메시 외부의 서비스에 도달합니다. Traffic Director를 사용하면 애플리케이션 로직을 네트워킹 로직과 분리할 수 있으므로 애플리케이션에서는 데이터 영역(예시: 애플리케이션과 함께 실행되는 사이드카 프록시)에 요청을 보내기만 하면 됩니다. 그러면 데이터 영역이 올바른 엔드포인트로 요청을 전송합니다.
아래 테이블에서 메시에 있는 것으로 설명된 애플리케이션은 Traffic Director 관리 데이터 영역을 사용하여 다른 서비스와 통신합니다. 이러한 애플리케이션은 인-메시 서비스 및 메시 외부 서비스로 트래픽을 보낼 수 있습니다.
| 기능 | 지원됨 |
|---|---|
| 메시의 VM 기반 애플리케이션 | ✔ |
| 메시의 컨테이너 기반 애플리케이션 | ✔ |
| 메시 외부의 VM 기반 애플리케이션 | ✔ |
| 메시 외부의 컨테이너 기반 애플리케이션 | ✔ |
| 온프레미스 데이터 센터에서 실행되는 애플리케이션 | ✔ |
| 멀티 클라우드 환경의 애플리케이션 | ✔ |
| 서비스 디렉터리의 엔드포인트 | ✔ |
데이터 영역 토폴로지
서비스 메시 모델에서 애플리케이션은 데이터 영역을 사용하여 통신합니다. 이 데이터 영역은 애플리케이션과 함께 배포된 사이드카 프록시로 구성되어 있는 경우가 많습니다. Traffic Director는 유연하며 서비스 네트워킹 요구 사항에 맞는 데이터 영역 토폴로지를 지원합니다.
| 기능 | 지원됨 |
|---|---|
| 애플리케이션과 함께 실행되는 사이드카 프록시 | ✔ |
| 프록시리스 gRPC 애플리케이션 | ✔ |
| 메시의 두 애플리케이션 사이에 있는 중간 프록시 | ✔ |
| 메시 경계의 에지 프록시 | ✔ |
| 여러 리전의 여러 GKE 클러스터 또는 Compute Engine VM에 걸쳐 있는 메시 | ✔ |
프로그래매틱 API 기반 구성
모든 구성은 REST API와 대시보드를 통해 기본적으로 노출되므로 대규모 팀 전체의 변경사항을 자동화하고 변경사항을 프로그래매틱 방식으로 관리할 수 있습니다. 일부 기능은 Google Cloud 콘솔을 사용하여 구성할 수 없습니다.
| 기능 | 지원됨 |
|---|---|
| REST API | ✔ |
| Google Cloud Console | ✔ |
| Google Cloud CLI | ✔ |
| Cloud Deployment Manager | ✔ |
| Terraform 지원 | ✔ |
프록시리스 gRPC 애플리케이션을 통한 언어 지원
다음 프로그래밍 언어를 사용하여 Traffic Director와 함께 작동하는 프록시리스 gRPC 애플리케이션을 만들 수 있습니다. gRPC의 다양한 구현 및 버전에서 지원되는 서비스 메시 기능이 GitHub에 나열됩니다.
| 언어 | 지원됨 |
|---|---|
| 자바 | ✔ |
| Go | ✔ |
| C++ | ✔ |
| Python | ✔ |
| Ruby | ✔ |
| PHP | ✔ |
| 노드 | ✔ |
요청 프로토콜
애플리케이션은 Traffic Director 구성 데이터 영역을 사용하여 통신할 때 다음 요청 프로토콜을 사용할 수 있습니다.
| 기능 | 지원됨 |
|---|---|
| HTTP | ✔ |
| HTTPS | ✔ |
| HTTP/2 | ✔ |
| TCP | ✔ |
| gRPC | ✔ |
서비스 보안
Traffic Director는 다음 구성으로 서비스 보안을 지원합니다.
| 기능 | Envoy | gRPC |
|---|---|---|
| GKE 포드가 포함된 TLS | ✔ | ✔ |
| GKE 포드가 포함된 mTLS | ✔ | ✔ |
| 액세스 제어 및 승인 | ✔ | ✔ |
라우팅 및 트래픽 관리
Traffic Director는 데이터 영역을 통과하는 트래픽을 조정, 분할, 구성하는 데 사용할 수 있는 고급 트래픽 관리 정책을 지원합니다.
일부 고급 트래픽 관리 기능은 프록시리스 gRPC 서비스에서 사용할 수 없으며, 고급 트래픽 관리 기능도 대상 TCP 프록시 리소스에서 사용할 수 없습니다.
Traffic Director가 TCP(HTTP(S)가 아닌) 트래픽을 처리하는 경우 다음 기능은 지원되지 않습니다.
| 기능 | HTTP(S) 또는 gRPC 트래픽을 처리하도록 구성된 Envoy 프록시에서 지원됨 | 프록시리스 gRPC에서 지원됨 |
|---|---|---|
| 다음에서 서픽스/프리픽스/전체/정규식 일치에 기반한 HTTP/레이어 7 요청 라우팅: | ||
| • 호스트이름 | ✔ | ✔ |
| 경로 | ✔ | ✔ |
| 헤더 | ✔ | ✔ |
| 메서드 | ✔ | 해당 없음 |
| • 쿠키 | ✔ | ✔ |
| 요청 매개변수 | ✔ | 해당 없음 |
| 결함 주입 | ✔ | ✔ |
| 구성 가능한 제한 시간 | ✔ | 해당 없음 최대 스트림 시간을 참조하세요. |
| 재시도 | ✔ | ✔ 재시도 제한 시간 제외 |
| 리디렉션 | ✔ | |
| URI 재작성 | ✔ | |
| 요청/응답 헤더 변환 | ✔ | |
| 트래픽 분할 | ✔ | ✔ |
| 트래픽 미러링 | ✔ | |
| 이상점 감지 | ✔ | ✔ |
| 회로 차단 | ✔ | ✔ maxRequests만 해당 |
| 최대 스트림 지속 시간 | ✔ | ✔ |
부하 분산
서비스, 백엔드 그룹(인스턴스 그룹 또는 네트워크 엔드포인트 그룹), 개별 백엔드, 엔드포인트 수준에서 부하 분산을 위해 고급 부하 분산 메서드와 알고리즘을 구성할 수 있습니다. 자세한 내용은 백엔드 서비스 개요를 참조하세요.
| 기능 | HTTP(s), TCP 또는 gRPC 트래픽을 처리하도록 구성된 Envoy 프록시에서 지원됨 | 프록시리스 gRPC에서 지원됨 |
|---|---|---|
| 리전을 기준으로 백엔드(인스턴스 그룹 또는 네트워크 엔드포인트 그룹) 선택(백엔드 용량이 안정적인 가장 가까운 리전 선호) | ✔ | ✔ |
| 비율 기반(초당 요청 수) 분산 모드를 사용하는 백엔드 선택 | ✔ TCP(HTTP(S)가 아닌) 트래픽에서는 지원되지 않습니다. |
✔ |
| 사용률 기반 분산 모드를 기반으로 하는 백엔드 선택(Compute Engine 인스턴스 그룹의 VM만 해당) | ✔ | ✔ |
| 백엔드 당 구성 가능한 최대 용량(Compute Engine 및 GKE만 해당) | ✔ | ✔ |
구성 가능한 부하 분산 정책을 기반으로 하는 백엔드 선택 각 기본 제공 정책에 관한 자세한 내용은 |
|
|
서비스 복원력
Traffic Director는 서비스의 복원력을 향상시키는 기능을 지원합니다. 예를 들어 Traffic Director를 사용하여 블루/그린 배포 패턴, 카나리아 테스트 또는 회로 차단(Envoy, gRPC)을 구현할 수 있습니다.
| 기능 | HTTP(s), TCP 또는 gRPC 트래픽을 처리하도록 구성된 Envoy 프록시에서 지원됨 | 프록시리스 gRPC에서 지원됨 |
|---|---|---|
| 가중치 기반 트래픽 분할을 기반으로 한 서비스 선택 | ✔ | ✔ |
| 회로 차단 | ✔ | ✔ maxRequests만 해당 |
서비스 및 백엔드 용량 관리
Traffic Director가 서비스 및 백엔드 용량을 고려하여 서비스 백엔드 간에 트래픽을 최적으로 분산시킵니다. Traffic Director는 Google Cloud 인프라와 통합되어 용량 데이터를 자동으로 수집합니다. 용량을 수동으로 설정하고 구성할 수도 있습니다.
| 기능 | 지원됨 |
|---|---|
| 관리형 인스턴스 그룹(MIG)의 VM 인스턴스에 대한 백엔드 용량 및 사용률을 CPU 기반으로 자동 추적 | ✔ |
| 요청 비율에 따라 MIG 및 네트워크 엔드포인트 그룹(NEG)의 VM 및 컨테이너 인스턴스의 수동 용량 및 재정의 | ✔ |
| 수동 용량 드레이닝 | ✔ |
장애 조치
기업 워크로드는 서비스 업타임을 보장하기 위해 일반적으로 고가용성 배포에 의존합니다. Traffic Director는 멀티 영역/멀티 리전 반복을 사용 설정하여 이러한 유형의 배포를 지원합니다.
| 기능 | 지원됨 |
|---|---|
| 백엔드 용량이 정상인 동일한 리전 내의 다른 영역으로 자동 장애 조치 | ✔ |
| 정상 백엔드 용량이 있는 가장 가까운 리전으로 자동 장애 조치 | ✔ |
상태 확인
Traffic Director는 백엔드 상태를 확인하기 위해 중앙집중식 상태 확인을 지원합니다. 그러나 백엔드 서비스에 서비스 디렉터리 서비스의 서비스 결합이 포함된 경우 상태 점검을 설정할 수 없습니다.
자세한 내용은 상태 점검 개요를 참조하세요.
| 기능 | 지원됨 |
|---|---|
| gRPC 상태 확인 | ✔ |
| HTTP 상태 확인 | ✔ |
| HTTPS 상태 확인 | ✔ |
| HTTP/2 상태 확인 | ✔ |
| TCP 상태 확인 | ✔ |
구성 가능한 상태 확인:
|
✔ |
| 구성 가능한 요청 경로(HTTP, HTTPS, HTTP/2) | ✔ |
| 구성 가능한 요청 문자열 또는 경로(TCP 또는 SSL) | ✔ |
| 구성 가능한 예상 응답 문자열 | ✔ |
관측 가능성
관측 가능성 도구는 서비스 메시를 이해하는 데 도움이 되는 모니터링, 디버깅, 성능 정보를 제공합니다. 다음 기능은 기본적으로 제공되거나 데이터 영역에서 구성됩니다. 애플리케이션 코드는 이 관측 가능성 데이터를 생성하기 위해 어떤 특별한 작업도 수행할 필요가 없습니다.
서비스 상태 대시보드는 프록시리스 gRPC 서비스에서 사용할 수 있지만 데이터 영역 로깅 및 추적을 구성할 수 없습니다. Traffic Director는 gRPC 애플리케이션의 로깅 및 추적을 구성할 수 없습니다. 오픈소스 사이트에 제공되는 문제 해결 섹션 또는 gRPC 가이드의 안내에 따라 로깅 및 추적을 사용 설정할 수 있습니다. 예를 들어 프록시리스 gRPC 서비스에서 측정항목 수집 및 추적을 사용 설정하려면 Opencensus를 사용하면 됩니다.
| 기능 | 프록시에서 지원됨 | 프록시리스 gRPC 서비스에서 지원됨 |
|---|---|---|
| 서비스 상태 대시보드 | ✔ | ✔ |
| 데이터 영역 로깅 | ✔ | ✔ |
| 데이터 영역 추적 | ✔ | ✔ |
세션 어피니티
클라이언트-서버 통신에는 여러 연속 요청이 포함되는 경우가 많습니다. 이 경우 연속 클라이언트 요청을 동일한 백엔드 또는 서버로 라우팅하면 유용합니다. Traffic Director는 백엔드가 정상이고 용량이 있는 한 특정 클라이언트의 요청을 동일한 백엔드로 전송하도록 구성 가능한 옵션을 제공합니다. 자세한 내용은 백엔드 서비스 개요를 참조하세요.
| 기능 | HTTP(S) 프록시에서 지원됨 | TCP 프록시에서 지원됨 | 프록시리스 gRPC 서비스에서 지원됨 |
|---|---|---|---|
| 클라이언트 IP 주소 | ✔ | ✔ | |
| HTTP 쿠키 | ✔ | 해당 없음 | |
| HTTP 헤더 | ✔ | 해당 없음 | ✔ |
| 생성된 쿠키(첫 번째 요청 시 클라이언트 쿠키 설정) | ✔ | 해당 없음 |
네트워크 토폴로지
Traffic Director는 일반적인 Google Cloud 네트워크 토폴로지를 지원합니다.
| 기능 | 지원됨 |
|---|---|
| Google Cloud 프로젝트의 단일 네트워크 | ✔ |
| Google Cloud 프로젝트의 여러 메시 | ✔ |
| Google Cloud 프로젝트의 여러 게이트웨이 | ✔ |
| 공유 VPC(여러 Google Cloud 프로젝트에서 단일 네트워크 공유) | ✔ |
Traffic Director에서 공유 VPC가 지원되는 방식에 대한 자세한 설명은 제한사항을 참조하세요.
규정 준수
Traffic Director는 다음 표준을 준수합니다.
| 규정 준수 인증 | 지원됨 |
|---|---|
| HIPAA | ✔ |
| ISO 27001, ISO 27017, ISO 27018 | ✔ |
| SOC1, SOC2, SOC3 | ✔ |
| PCI DSS | ✔ |
다음 단계
- Traffic Director에 대한 자세한 내용은 Traffic Director 개요를 참조하세요.
- 프록시리스 gRPC 서비스의 사용 사례 및 아키텍처 패턴을 찾으려면 프록시리스 gRPC 서비스 개요를 참조하세요.