서비스 디렉터리와 Traffic Director 통합
이 문서에서는 Traffic Director에 서비스 디렉터리의 서비스 레지스트리를 사용하는 방법에 대한 개요를 제공합니다. 이를 통해 Traffic Director가 트래픽을 라우팅할 수 있고 서비스 디렉터리에 등록된 서비스에 트래픽 정책을 적용할 수 있습니다. 이 문서는 애플리케이션을 Google Cloud의 다른 서비스와 통합하길 원하는 Traffic Director 개발자를 대상으로 합니다.
서비스 디렉터리는 이름, 위치, 속성을 포함하여 등록된 네트워크 서비스에 대한 정보가 저장된 서비스 레지스트리입니다. 서비스를 자동으로 등록하여 모든 세부정보를 캡처할 수 있고, 인프라에 관계없이 모든 서비스를 등록할 수 있습니다.
레지스트리는 Google Cloud 서비스뿐만 아니라 온프레미스 또는 다른 퍼블릭 클라우드에서 실행되는 하이브리드 서비스를 포함할 수 있습니다. 이 문서의 정보를 효과적으로 이해하기 위해서는 서비스 디렉터리 작업의 기본 사항을 숙지하는 것이 좋습니다.
Traffic Director와 함께 서비스 디렉터리의 서비스 레지스트리를 사용하는 경우, 통합하면 서비스 레지스트리의 서비스를 메시의 애플리케이션과 Traffic Director에서 구성한 게이트웨이에서 사용할 수 있습니다. Traffic Director와 서비스 디렉터리의 통합은 Envoy, 프록시리스 gRPC, 내부 패스 스루 네트워크 부하 분산기와 서비스 디렉터리 통합, 내부 애플리케이션 부하 분산기, L4 Private Service Connect에서 지원됩니다.
서비스를 통합하려면 서비스를 서비스 디렉터리에 등록한 후 서비스를 Traffic Director 백엔드 서비스에 바인딩합니다. 결합이 설정된 다음 Traffic Director가 서비스 디렉터리에 쿼리를 수행하여 등록된 서비스 및 서비스 연결 방법에 대한 정보를 얻습니다. Traffic Director도 서비스에 대한 모든 변경사항을 추적합니다. 통합을 사용하면 서비스 메시 및 자체 관리형 게이트웨이가 트래픽을 이러한 서비스에 전송할 수 있습니다. 또한 고급 트래픽 관리 정책과 같이 Traffic Director에서 구성하는 정책을 적용할 수 있습니다.
이 통합을 사용할 때 서비스 결합은 서비스 자체에 사용되는 백엔드 유형에 관계없이 백엔드로 작동합니다. 백엔드 유형에 관계없이 Traffic Director가 서비스로 트래픽을 전송할 수 있기 때문에 통합은 Traffic Director 배포를 단순화합니다.
서비스가 서비스 디렉터리에 등록되면 필요한 서비스에 액세스하기 위해 인스턴스 그룹이나 다른 유형의 네트워크 엔드포인트 그룹(NEG)을 구성할 필요가 없습니다. Google Kubernetes Engine, 내부 부하 분산기, Private Service Connect를 서비스 디렉터리에 자동으로 등록하여 이러한 서비스에 대한 Traffic Director 액세스를 더 간소화할 수 있습니다.
통합에 사용되는 리소스
Traffic Director와 서비스 디렉터리 사이의 통합에는 다음 리소스가 사용됩니다.
서비스 디렉터리 서비스
서비스 디렉터리는 서비스 레지스트리입니다. 서비스 디렉터리를 사용하면 Google Cloud 또는 다른 환경(예: 온프레미스 데이터 센터) 기반의 서비스를 포함하여 여러 유형의 서비스를 등록할 수 있습니다. 각 서비스는 고유한 이름 및 하나 이상의 서비스 엔드포인트로 구성됩니다. 서비스 엔드포인트는 주소, 포트, 속성, 메타데이터로 구성됩니다. 엔드포인트가 0개면 서비스로 트래픽을 라우팅할 수 없습니다.
서비스 결합
서비스 결합은 서비스 디렉터리 서비스의 정규화된 도메인 이름(FQDN)을 포함하는 리소스입니다. 예를 들어 projects/test-proj/locations/us-east1/namespaces/test-namespace/services/test-service는 서비스 디렉터리 서비스의 FQDN입니다.
백엔드 서비스
백엔드 서비스는 관리형 인스턴스 그룹과 같은 백엔드를 포함하여 백엔드 서비스가 트래픽을 라우팅하는 Traffic Director에 대한 정보를 제공하는 구성 리소스입니다. 서비스 결합을 참조하는 백엔드 서비스는 백엔드를 가질 수 없습니다. 서비스 디렉터리와 Traffic Director 통합을 사용하려면 서비스 결합을 참조하는 새 백엔드 서비스를 만들어야 합니다.
백엔드 서비스는 여러 서비스 결합을 가질 수 있습니다. 이 구성은 동일 애플리케이션의 리전 배포가 있는 경우에 유용합니다. 각 리전 배포를 서비스 디렉터리의 리전 인스턴스에 리전 서비스 1 및 리전 서비스 2로 등록할 수 있습니다. 그런 후 두 가지 서비스 결합을 사용하여 이러한 각 리전 서비스 디렉터리 서비스를 동일한 백엔드 서비스와 연결할 수 있습니다. 전역 서비스 결합 1은 A 리전의 리전 서비스 1과 연결되고 전역 서비스 결합 2는 B 리전의 리전 서비스 2와 연결됩니다.
사용 사례
Traffic Director 배포를 서비스 디렉터리와 통합하면 다른 팀 또는 조직에서 소유하거나 게시하는 서비스를 사용하는 경우에 유용한 새 사용 사례를 활용할 수 있습니다.
Traffic Director에 기존 서비스 제공
서비스 디렉터리는 GKE, 내부 패스 스루 네트워크 부하 분산기, 내부 애플리케이션 부하 분산기와 같은 Google Cloud 제품과 통합됩니다. 서비스 제작자는 GKE 서비스 또는 부하 분산기를 만들 때 이를 서비스 디렉터리에 등록합니다.
서비스가 서비스 디렉터리에 등록된 다음에는 이 서비스와 통신하도록 Traffic Director를 구성할 수 있습니다. 그런 후 Traffic Director 클라이언트가 내부 패스 스루 네트워크 부하 분산기 및 내부 애플리케이션 부하 분산기 뒤에 실행되는 서비스와 통신할 수 있습니다.
서비스 제작자 및 소비자 사이의 조정 개선
대기업은 여러 개의 독립적인 개발자 팀을 갖고 있습니다. 이러한 팀은 공유 서비스로 제공되는 기능을 많은 팀이 사용할 수 있도록 서비스를 다른 팀에 제공합니다. 이로 인해 팀 간 종속 항목이 발생합니다. 이러한 종속 항목에 따라 팀이 자신의 업무 결과를 공유할 수 있지만 그로 인해 조정 오버헤드도 발생합니다.
서비스 디렉터리를 사용할 때 한 팀(제작자)은 다른 팀 또는 조직(소비자)에 제공하려는 서비스를 등록합니다. 제작자는 이 서비스에 대한 참조를 소비자와 공유합니다. 소비자는 이 참조를 사용해서 서비스 디렉터리에서 제작자의 서비스를 조회하고 서비스 엔드포인트를 검색할 수 있습니다. 예를 들어 엔드포인트는 제작자 서비스가 트래픽을 수신하도록 예상되는 가상 IP 주소(VIP)일 수 있습니다.
Traffic Director를 서비스 디렉터리와 통합하면 서비스 디렉터리 서비스를 Traffic Director 백엔드 서비스에 결합하여 프로세스를 자동화할 수 있으며, 다음과 같은 이점이 있습니다.
- Traffic Director는 이를 서비스 디렉터리에서 동기화하여 서비스 엔드포인트를 자동으로 확인합니다. 서비스 디렉터리 서비스의 엔드포인트가 업데이트되었으면 Traffic Director가 이러한 변경사항을 자동으로 동기화합니다.
- Traffic Director에서 제한 시간과 같은 여러 라우팅 및 트래픽 관리 정책을 설정할 수 있습니다. 이러한 정책을 사용하면 애플리케이션이 서비스 디렉터리 서비스에 대해 요청을 제기하는 방식을 세밀하게 조정할 수 있습니다. Traffic Director에서 라우팅 및 트래픽 관리에 대한 자세한 내용은 고급 트래픽 관리를 참조하세요.
- Traffic Director는 근접성 기반의 부하 분산과 같은 트래픽 관리 기능을 사용하여 왕복시간 최소화와 같이 애플리케이션에서 엔드포인트로의 트래픽 전달을 최적화합니다.
소비자인 사용자가 Traffic Director를 사용하여 백엔드 서비스를 서비스 디렉터리 서비스에 연결하면 팀 간 조정 오버헤드가 줄어듭니다.
Payments서비스를 이름별로 연결합니다.Traffic Director는
Payments서비스에 대한 정보를 해당 클라이언트와 공유합니다.- 예를 들어 서비스 메시에서 실행되는 사이드카 프록시는 이제 서비스에 연결할 수 있는 엔드포인트(예:
10.0.0.1:80)를 인식합니다.
- 예를 들어 서비스 메시에서 실행되는 사이드카 프록시는 이제 서비스에 연결할 수 있는 엔드포인트(예:
사용자 또는 사용자 애플리케이션이 외부 서비스의 엔드포인트에 대해 아무 것도 알 필요 없이 애플리케이션이 이름으로 이 서비스를 호출할 수 있습니다. 다이어그램에서 서비스는
Payments서비스입니다.서비스 제작자가 외부 서비스를 업데이트하면(예: 엔드포인트 변경) Traffic Director가 업데이트를 선택하여 클라이언트와 원활하게 공유합니다.
인그레스 지점을 사용하여 경계 내에서 서비스 액세스
팀은 VPC 서비스 제어 경계 내에서 서비스 모음을 그룹화하고 단일 인그레스 지점을 통해 이러한 서비스를 노출할 수 있습니다. 이 인그레스 지점을 서비스 디렉터리에 등록하고 경계 내에서 서비스에 액세스하려는 사용자에게 제공할 수 있습니다. VPC 서비스 제어 경계에 대한 자세한 내용은 서비스 경계 세부정보 및 구성을 참조하세요.
예를 들어 한 팀에서 클러스터의 Kubernetes 서비스 모음으로 요청을 분산하는 내부 애플리케이션 부하 분산기를 사용하여 인그레스 게이트웨이를 만든다고 가정해보세요. 이 인그레스 게이트웨이는 서비스 디렉터리에 서비스로 자동으로 등록됩니다. Kubernetes 서비스에 액세스하려는 소비자는 서비스 디렉터리에서 이 인그레이스 게이트웨이를 조회할 수 있습니다. 그런 후 소비자가 게이트웨이를 통해 경계 내의 서비스에 액세스하도록 Traffic Director 메시를 구성할 수 있습니다.
도메인 간 서비스 연결
다른 도메인에 연결이 필요한 서비스가 있을 수 있습니다.
조직 간 서비스 연결
Google API(예: Cloud SQL) 또는 타사 관리형 서비스와 같은 다른 조직에서 소유한 서비스에 액세스해야 할 수 있습니다.
서비스 디렉터리는 Private Service Connect를 지원합니다. 네트워크에 Private Service Connect 엔드포인트를 만들 때 서비스 디렉터리에 엔드포인트를 서비스로 등록할 수 있습니다. 그런 후 이 서비스를 Traffic Director에 연결하여 Envoy 및 gRPC 클라이언트와 같은 메시 클라이언트와 Apigee와 같은 자체 관리형 게이트웨이가 이러한 서비스를 호출하도록 할 수 있습니다.
Cloud Storage를 사용하는 앞의 예시는 Private Service Connect에서 Virtual Private Cloud 네트워크의 엔드포인트를 사용하여 Google API를 호출하는 방법을 보여줍니다.
VPC 네트워크 간 서비스 연결
일부 회사는 Google Cloud 배포를 진행하는 동안 여러 VPC 네트워크를 사용합니다. 이러한 경우 한 VPC 네트워크의 서비스가 다른 VPC 네트워크의 서비스에 액세스해야 할 수 있습니다. 다른 VPC 네트워크의 서비스에 액세스하도록 VPC 피어링을 구성할 수 있지만 이렇게 하면 피어링된 네트워크 사이에 IP 주소 범위가 겹칠 때 상황이 복잡해질 수 있습니다.
Private Service Connect는 단일 IP:port 엔드포인트를 사용하여 한 VPC 네트워크의 서비스가 다른 VPC 네트워크의 서비스에 안전하게 비공개로 액세스할 수 있게 합니다.
도메인 간 추가 예시
이전의 두 예시는 도메인 간 액세스가 필요할 수 있는 사례를 보여주지만 이것 외에도 다른 추가 예시가 많습니다. 예를 들어 두 Google Cloud 리전의 교차점에 게이트웨이를 만들 수 있습니다. 한 리전의 서비스가 이 게이트웨이를 통해 다른 리전의 서비스에 연결할 수 있습니다. 서비스 디렉터리에서 게이트웨이를 서비스로 등록한 후 이 문서에 설명된 대로 Traffic Director에 게이트웨이를 사용합니다.
서비스가 액세스될 때의 정책 적용
Traffic Director는 정책을 사용하여 구성 가능한 고급 트래픽 관리와 같은 기능을 지원합니다. 예를 들어 클라이언트가 특정 백엔드 서비스로 요청을 전송할 때마다 트래픽이 보조 백엔드 서비스로도 전송되도록 트래픽 미러링 정책을 설정할 수 있습니다.
서비스 디렉터리 서비스를 Traffic Director 백엔드 서비스로 결합할 때는 Traffic Director에서 이러한 유형의 정책을 구성할 수 있습니다. 사이드카 프록시, 미들 또는 에지 프록시, 프록시리스 클라이언트는 이러한 정책을 확인하고 적용합니다.
예를 들면 다음과 같습니다.
- 가중치 기반 트래픽 분할(예: 두 서비스 디렉터리 서비스 간)
- 트래픽 미러링(예: 감사 서비스에)
users 서비스에 대한 요청이 audit 서비스에 미러링됩니다(확대하려면 클릭).Traffic Director 및 기존 클라이언트 지원
Traffic Director가 조직에 배포되더라도 Traffic Director를 사용하지 않는 클라이언트가 있을 수 있습니다. 예를 들어 서비스 메시에 포함되지 않는 가상 머신의 서비스에 액세스해야 할 수 있습니다.
서비스 디렉터리 서비스를 Traffic Director 백엔드 서비스에 결합할 때는 Traffic Director의 클라이언트가 자동으로 해당 서비스에 대한 최신 정보를 가져옵니다. Traffic Director를 사용하지 않는 클라이언트는 서비스 디렉터리에서 서비스 정보를 조회하고 사용할 수 있습니다.
제한사항
Traffic Director에서는 서비스 디렉터리 통합의 FQDN NEG(INTERNET_FQDN_PORT NEG)를 지원하지 않습니다.
다음 단계
- 통합 설정 알아보기
- 이 통합과의 관측 가능성에 대한 자세한 내용은 관측 가능성 및 서비스 디렉터리 디버깅을 참조하세요.