Traffic Director 개요

Traffic Director는 애플리케이션 네트워킹을 위한 관리형 제어 영역입니다. Traffic Director를 사용하면 트래픽 관리 및 관찰 기능과 같은 고급 애플리케이션 네트워킹 기능을 갖춘 가용성이 높은 전역 서비스를 제공할 수 있습니다.

배포 시 서비스 및 마이크로서비스 수가 증가하면 일반적으로 다음과 같은 일반적인 애플리케이션 네트워킹 문제가 발생하기 시작합니다.

  • 서비스를 탄력적으로 설정하려면 어떻게 해야 하나요?
  • 서비스에 트래픽을 어떻게 전달하고 서비스가 서로 어떻게 알고 통신하나요?
  • 서비스가 서로 통신할 때 어떤 일이 일어나는지 어떻게 알 수 있나요?
  • 서비스 중단 없이 서비스를 업데이트하려면 어떻게 해야 하나요?
  • 이를 가능하게 하는 인프라를 관리하려면 어떻게 해야 하나요?
서비스는 서로 통신해야 합니다.
서비스는 서로 통신해야 합니다(확대하려면 클릭).

Traffic Director는 현대적인 서비스 기반 배포에서 이러한 유형의 문제를 해결하는 데 도움이 됩니다. 무엇보다 Google Cloud 관리형 인프라를 사용하므로 사용자가 인프라를 직접 관리할 필요 없이 동급 최고의 기능을 사용할 수 있습니다. Traffic Director가 애플리케이션 네트워킹 복잡성을 관리할 수 있도록 하면서 비즈니스 문제를 해결하는 배송 애플리케이션 코드를 중점적으로 설명합니다.

서비스 메시의 Traffic Director

애플리케이션 네트워킹 문제를 해결하기 위한 일반적인 패턴은 서비스 메시를 사용하는 것입니다. Traffic Director는 서비스 메시 및 필요에 맞는 다양한 배포 패턴을 지원합니다.

일반적인 서비스 메시
일반적인 서비스 메시(확대하려면 클릭)

일반적인 서비스 메시는 다음과 같습니다.

  • 서비스를 Kubernetes 클러스터에 배포합니다.
  • 각 서비스의 Pod에는 사이드카 프록시로 실행되는 전용 프록시(일반적으로 Envoy)가 있습니다.
  • 각 사이드카 프록시는 클러스터에 설치된 네트워킹 인프라 (제어 영역)와 통신합니다. 제어 영역은 사이드카 프록시에 서비스 메시의 서비스, 엔드포인트, 정책에 대하여 알려줍니다.
  • Pod가 요청을 전송하거나 수신하면 요청은 Pod의 사이드카 프록시로 이동합니다. 사이드카 프록시는 요청을 의도한 대상에게 보내는 등의 요청을 처리합니다.

이 문서의 다이어그램에서 6면의 분홍색 아이콘은 프록시를 나타냅니다. 제어 영역은 각 프록시에 연결되어 프록시가 요청을 처리하는 데 필요한 정보를 제공합니다. 상자 사이의 화살표는 트래픽 흐름을 나타냅니다. 예를 들어 Service A의 애플리케이션 코드는 요청을 전송합니다. 프록시는 요청을 처리하여 Service B에 전달합니다.

이 모델을 사용하면 애플리케이션 코드 밖으로 네트워킹 로직을 이동할 수 있습니다. 인프라에서 애플리케이션 네트워킹을 처리하도록 허용하면서 비즈니스 가치를 제공하는 데 집중할 수 있습니다.

Traffic Director의 차이점

Traffic Director는 해당 모델과 비슷하게 작동하지만 중요한 면에서 다릅니다. 모든 것은 Traffic Director가 Google Cloud 관리형 서비스라는 사실에서부터 시작됩니다. 설치하지 않고 클러스터에서 실행되지 않으며 이를 유지관리할 필요가 없습니다.

다음 다이어그램에서 Traffic Director는 제어 영역입니다. 이 Kubernetes 클러스터에는 Traffic Director로 연결된 사이드카 프록시를 각각 사용하는 네 개의 서비스가 있습니다. Traffic Director는 프록시가 요청을 라우팅하는 데 필요한 정보를 제공합니다. 예를 들어 Service A에 속하는 Pod의 애플리케이션 코드는 요청을 보냅니다. 이 Pod와 함께 실행되는 사이드카 프록시는 요청을 처리하고 Service B에 속하는 Pod로 라우팅합니다.

Traffic Director가 포함된 서비스 메시의 예시
Traffic Director가 포함된 서비스 메시의 예시(확대하려면 클릭)

서비스 메시를 벗어남

Traffic Director는 일반적인 서비스 메시보다 더 많은 유형의 배포를 지원합니다.

멀티 클러스터 Kubernetes

Traffic Director를 사용하면 Kubernetes 클러스터 전체에서 작동하는 애플리케이션 네트워킹을 가져올 수 있습니다. 다음 다이어그램에서 Traffic Director는 us-central1europe-west1에서 Kubernetes 클러스터의 제어 영역을 제공합니다. us-central1의 세 가지 서비스, europe-west1의 두 가지 서비스, 두 클러스터의 서비스 간에 요청이 라우팅될 수 있습니다.

Traffic Director가 포함된 멀티 클러스터 Kubernetes의 예시
Traffic Director가 포함된 멀티 클러스터 Kubernetes의 예시(확대하려면 클릭)

서비스 메시는 여러 Google Cloud 리전의 여러 Kubernetes 클러스터에서 확장될 수 있습니다. 한 클러스터의 서비스는 다른 클러스터의 서비스와 통신할 수 있습니다. 또한 여러 클러스터의 Pod로 구성된 서비스도 사용할 수 있습니다.

Traffic Director의 근접 기반 글로벌 부하 분산을 통해 Service B에 도착한 요청은 요청을 처리할 수 있는 가장 가까운 Pod로 이동합니다. 또한 장애 조치도 원활하게 이루어집니다. Pod가 다운되면 요청은 이 pod가 다른 Kubernetes 클러스터에 있더라도 요청에서 처리할 수 있는 다른 Pod로 자동으로 장애 조치됩니다.

가상 머신

Kubernetes가 점점 인기가 많아지고 있지만 가상 머신(VM)에 많은 워크로드가 배포됩니다. Traffic Director는 이러한 워크로드의 애플리케이션 네트워킹도 해결합니다. VM 기반 워크로드는 Kubernetes 기반 워크로드와 쉽게 상호 운용됩니다.

다음 다이어그램에서는 트래픽이 외부 HTTP(S) 부하 분산을 통해 배포에 들어갑니다. asia-southeast1의 Kubernetes 클러스터에 있는 Service Aeurope-west1의 VM에서 Service D로 라우팅됩니다.

Traffic Director가 포함된 VM 및 Kubernetes의 예시
Traffic Director가 포함된 VM 및 Kubernetes 예시(확대하려면 클릭)

Google은 Traffic Director로 VM 기반 워크로드를 설정할 수 있는 원활한 메커니즘을 제공합니다. Compute Engine VM 인스턴스 템플릿에 플래그만 추가하면 Google에서 인프라 설정을 처리합니다. 이 설정에는 애플리케이션 네트워킹 기능을 제공하는 프록시 설치 및 구성이 포함됩니다.

프록시 없는 gRPC

gRPC는 고성능 마이크로서비스를 작성하는 데 사용할 수 있는 기능이 풍부한 오픈소스 RPC 프레임워크입니다. Traffic Director를 사용하면 애플리케이션 네트워킹 기능(예: 서비스 검색, 부하 분산, 트래픽 관리)을 gRPC 애플리케이션에 손쉽게 가져올 수 있습니다. 자세한 내용은 Traffic Director 및 gRPC—서비스 메시용 프록시리스 서비스를 참조하세요.

다음 다이어그램에서 gRPC 애플리케이션은 한 리전의 Kubernetes 클러스터에 기반을 둔 서비스와 다른 리전의 VM에서 실행되는 서비스로 트래픽을 라우팅합니다. 이 중 두 가지 서비스에는 사이드카 프록시가 포함되고 다른 서비스는 프록시리스입니다.

Traffic Director가 포함된 프록시리스 gRPC 애플리케이션의 예시
Traffic Director가 포함된 프록시리스 gRPC 애플리케이션의 예시(확대하려면 클릭)

Traffic Director는 프록시리스 gRPC 서비스를 지원합니다. 이러한 서비스는 xDS API를 지원하는 오픈소스 gRPC 라이브러리의 최신 버전을 사용합니다. gRPC 애플리케이션은 Envoy가 사용하는 것과 동일한 xDS API를 사용하여 Traffic Director에 연결할 수 있습니다.

gRPC 라이브러리는 애플리케이션이 연결되면 서비스 검색, 부하 분산 및 트래픽 관리와 같은 애플리케이션 네트워킹 기능을 처리합니다. 이는 gRPC에서 기본적으로 발생하므로 서비스 프록시가 필요하지 않습니다. 따라서 프록시리스 gRPC 애플리케이션이라고 부릅니다.

인그레스 및 게이트웨이

많은 사용 사례의 경우 Traffic Director로 구성되지 않은 클라이언트에서 발생하는 트래픽을 처리해야 합니다. 예를 들어 공개 인터넷 트래픽을 마이크로서비스에 인그레스해야 할 수 있습니다. 또한 트래픽을 대상으로 보내기 전에 클라이언트의 트래픽을 처리하는 역방향 프록시로 부하 분산기를 구성할 수도 있습니다.

다음 다이어그램에서 외부 HTTP(S) 부하 분산기는 Kubernetes 클러스터의 서비스로 라우팅되는 트래픽을 가지고 외부 클라이언트에 대해 인그레스를 사용 설정합니다. 내부 HTTP(S) 부하 분산기는 내부 트래픽을 VM에서 실행되는 서비스로 라우팅합니다.

인그레스용 Cloud Load Balancing이 포함된 Traffic Director
인그레스용 Cloud Load Balancing이 포함된 Traffic Director(확대하려면 클릭)

Traffic Director는 Google Cloud Load Balancing과 협력하여 관리형 인그레스 환경을 제공합니다. 외부 또는 내부 부하 분산기를 설정한 후 부하 분산기가 트래픽을 마이크로서비스로 전송하도록 구성합니다. 위의 다이어그램에서 공개 인터넷 클라이언트는 외부 HTTP(S) 부하 분산을 통해 서비스에 도달합니다. Virtual Private Cloud (VPC) 네트워크에 있는 마이크로서비스와 같은 클라이언트는 내부 HTTP(S) 부하 분산을 사용하여 서비스에 연결합니다.

다음 다이어그램에서 europe-west1 리전의 VM은 프록시를 실행하지 않는 세가지 서비스의 게이트웨이 역할을 하는 프록시를 실행합니다. 외부 HTTP(S) 부하 분산기와 내부 HTTP(S) 부하 분산기의 트래픽은 모두 게이트웨이로 라우팅된 후 3개의 서비스로 라우팅됩니다.

게이트웨이를 구성하는 데 사용되는 Traffic Director
게이트웨이를 구성하는 데 사용되는 Traffic Director(확대하려면 클릭)

일부 사용 사례에서는 Traffic Director를 설정하여 게이트웨이를 구성해야 할 수 있습니다. 이 게이트웨이는 기본적으로 하나 이상의 VM에서 실행되는 전형적인 Envoy인 역방향 프록시로 수신 요청을 리슨하고 처리한 다음 대상으로 전송합니다. 대상은 모든 Google Cloud 리전 또는 Google Kubernetes Engine(GKE) 클러스터에 있을 수 있습니다. 하이브리드 연결을 사용하여 Google Cloud에서 연결할 수 있는 Google Cloud 외부의 대상일 수도 있습니다.

여러 환경

Google Cloud, 온프레미스, 다른 클라우드 또는 이 모든 부분 어디에 서비스를 제공하더라도 기본 애플리케이션 네트워킹 문제는 동일하게 유지됩니다. 이러한 서비스로 트래픽을 어떻게 가져오나요? 그리고 이러한 서비스가 서로 어떻게 통신하나요?

다음 다이어그램에서 Traffic Director는 Google Cloud에서 실행중인 서비스에서 다른 퍼블릭 클라우드에서 실행중인 Service G와 온프레미스에서 실행 중인 Service EService F로 트래픽을 라우팅합니다. Service A, Service B, Service C은 Envoy를 사이드카 프록시로 사용하고 Service D는 프록시리스 gRPC 서비스입니다.

환경 간 통신에 사용되는 Traffic Director
환경 간 통신에 사용되는 Traffic Director(확대하려면 클릭)

Traffic Director를 사용하면 Google Cloud 외부의 목적지로 요청을 보낼 수 있습니다. 이렇게 하면 Cloud Interconnect 또는 Cloud VPN을 사용하여 Google Cloud 내부의 서비스에서 다른 환경의 서비스 또는 게이트웨이로 트래픽을 비공개로 라우팅할 수 있습니다.

Traffic Director 설정

Traffic Director 설정은 다음 두 단계로 구성됩니다. 설정 프로세스를 완료하면 인프라가 애플리케이션 네트워킹을 처리하고 Traffic Director가 배포 변경사항을 기반으로 모든 것을 최신 상태로 유지합니다.

애플리케이션 배포

먼저 애플리케이션 코드를 컨테이너 또는 VM에 배포합니다. Google에서는 VM 인스턴스와 Pod에 애플리케이션 네트워킹 인프라(일반적으로 Envoy 프록시)를 쉽게 추가할 수 있는 메커니즘을 제공합니다. 이 인프라는 Traffic Director와 소통하고 서비스에 대해 학습하도록 설정되었습니다.

Traffic Director 구성

다음으로 전역 서비스를 구성하고 트래픽 처리 방법을 정의합니다. Traffic Director를 구성하려면 Google Cloud Console, gcloud 명령줄 도구, Traffic Director API 또는 Terraform과 같은 다른 도구를 사용해야 합니다.

이러한 단계를 완료하면 Traffic Director가 애플리케이션 네트워킹 인프라를 구성할 준비가 된 것입니다.

인프라에서 애플리케이션 네트워킹 처리

애플리케이션이 my-service로 요청을 전송하면 애플리케이션 네트워킹 인프라(예: Envoy 사이드카 프록시)는 Traffic Director로부터 받은 정보에 따라 요청을 처리합니다. 이렇게 하면 my-service 요청이 요청을 수신할 수 있는 애플리케이션 인스턴스로 원활하게 라우팅됩니다.

모니터링 및 지속적 업데이트

Traffic Director는 서비스를 구성하는 애플리케이션 인스턴스를 모니터링합니다. 이 모니터링을 통해 Traffic Director는 서비스가 정상인지 또는 새 Kubernetes Pod가 생성되는 경우와 같이 서비스 용량이 변경된 것을 확인할 수 있습니다. 이 정보를 기반으로 Traffic Director는 애플리케이션 네트워킹 인프라를 지속적으로 업데이트합니다.

특징

Traffic Director의 기능은 마이크로서비스에 애플리케이션 네트워킹 기능을 제공합니다. 몇 가지 주요 내용이 이 섹션에서 설명되어 있습니다.

완전 관리형 제어 영역, 상태 확인 및 부하 분산

인프라 관리가 아닌 비즈니스 가치를 제공하는 데 시간을 소비하고자 합니다. Traffic Director는 업타임 SLA를 갖춘 완전 관리형 솔루션이므로 인프라를 설치, 구성, 업데이트할 필요가 없습니다. Google이 상태 확인 및 글로벌 부하 분산에 사용하는 것과 동일한 인프라의 이점을 누릴 수 있습니다.

오픈소스 제품 기반 빌드

Traffic Director는 Envoy, Istio와 같은 오픈소스 프로젝트에 널리 사용되는 동일한 제어 영역(xDS) API를 사용합니다. 지원되는 API 버전을 보려면 xDS 제어 영역 API를 참조하세요.

사용 사례에 따라 Envoy 또는 gRPC와 같은 애플리케이션 네트워킹 기능을 제공하는 인프라도 오픈소스이므로 독점 인프라로 고정되는 것에 대해 걱정할 필요가 없습니다.

확장

Traffic Director는 일회성 애플리케이션 네트워킹 솔루션부터 수천 개의 서비스를 갖춘 대규모 서비스 메시 배포에 이르기까지 확장 요구사항을 충족하도록 빌드되었습니다.

엔드포인트 및 백엔드 서비스 검색 및 추적

애플리케이션이 my-service에 요청을 보내면 인프라가 원할하게 요청을 처리하고 올바른 대상으로 보냅니다. 애플리케이션은 IP 주소, 프로토콜 또는 기타 네트워킹 복잡성에 대해 아무 것도 알 필요가 없습니다.

글로벌 부하 분산 및 장애 조치

Traffic Director는 Google의 글로벌 부하 분산 및 상태 확인을 사용하여 백엔드 근접성, 상태, 용량을 기준으로 트래픽을 최적으로 조정합니다. 트래픽이 용량이 있는 정상 백엔드로 자동으로 장애 조치를 수행하여 서비스 가용성을 높입니다.

트래픽 관리

라우팅 및 요청 조작(호스트 이름, 경로, 헤더, 쿠키 등)을 포함한 고급 트래픽 관리를 통해 서비스 간 트래픽 흐름 방식을 확인할 수 있습니다. 또한 카나리아 배포를 위해 재시도, 리디렉션, 가중치 기반 트래픽 분할과 같은 작업을 적용할 수 있습니다. 결함 주입, 트래픽 미러링, 이상점 감지와 같은 고급 패턴을 사용하면 DevOps 사용 사례를 통해 복원력을 향상시킬 수 있습니다.

관찰 기능

애플리케이션 네트워킹 인프라는 Google Cloud 운영 제품군에서 중앙 집중식으로 집계할 수 있는 측정항목, 로그, trace와 같은 원격 분석 정보를 수집합니다. 이 정보가 수집된 후 유용한 정보를 얻고 알림을 만들어 문제가 발생하면 알림을 받을 수 있습니다.

다음 단계