이 문서는 Cross-Cloud Network를 위한 설계 가이드 시리즈의 일부입니다.
이 시리즈는 다음 문서로 구성됩니다.
- 분산형 애플리케이션을 위한 교차 클라우드 네트워크
- 교차 클라우드 네트워크의 분산형 애플리케이션에 대한 네트워크 세분화 및 연결
- 교차 클라우드 네트워크의 분산 애플리케이션을 위한 서비스 네트워킹(이 문서)
- Cross-Cloud Network의 분산 애플리케이션을 위한 네트워크 보안
이 문서에서는 선택하거나 생성한 구성요소 서비스 집합에서 애플리케이션을 어셈블하는 방법을 설명합니다. 단계를 따르기 전에 문서를 한 번 전체적으로 읽어보는 것이 좋습니다.
이 문서에서는 다음 결정에 대해 안내합니다.
- 개별 서비스를 직접 만들지 아니면 서드 파티 서비스를 사용하는지 여부
- 서비스를 전역적으로 사용할 수 있는지 또는 리전별로 사용할 수 있는지 여부
- 서비스가 온프레미스에서 소비되는지, 다른 클라우드에서 소비되는지, 아니면 둘 다 아닌지
- 공유 서비스 VPC를 통해 서비스 엔드포인트에 액세스하는지 아니면 모든 관련 애플리케이션 VPC를 통해 엔드포인트를 배포하는지
이 문서에서는 다음 단계를 안내합니다.
- 애플리케이션이 전역인지 리전인지 결정
- 서드 파티 관리형 서비스 선택 또는 자체 서비스 생성 및 게시
- 공유 또는 전용 모드를 사용하여 서비스 엔드포인트에 대한 비공개 액세스 설정
- 전역 또는 리전 원형과 일치하도록 서비스를 애플리케이션으로 조합
개발자는 교차 클라우드 네트워크의 서비스 네트워킹 레이어를 정의합니다. 이 단계에서 관리자는 이 문서에 설명된 서비스 네트워킹 옵션에 유연성을 사용할 수 있게 해주는 교차 클라우드 네트워크용 연결 레이어를 설계했습니다. 경우에 따라 제한된 교차 VPC 전이성으로 인한 제약 조건이 있습니다. 이러한 제약 조건이 설계 결정에 영향을 미칠 수 있는 경우 이에 대해 설명합니다.
애플리케이션이 리전인지 전역인지 결정
만들려는 애플리케이션의 고객에게 리전 또는 전역 배포 원형이 필요한지 확인합니다. 리전의 영역에 부하를 분산하여 리전 복원력을 달성할 수 있습니다. 여러 리전에 부하를 분산하여 전역 복원력을 달성할 수 있습니다.
원형 선택 시 다음 요소를 고려하세요.
- 애플리케이션의 가용성 요구사항
- 애플리케이션이 사용되는 위치
- 비용
자세한 내용은 Google Cloud 배포 아키타입을 참고하세요.
이 설계 가이드에서는 다음 배포 아키타입을 지원하는 방법을 설명합니다.
교차 클라우드 분산형 애플리케이션에서는 해당 애플리케이션의 여러 서비스가 서로 다른 클라우드 서비스 제공업체(CSP) 또는 비공개 데이터 센터에서 제공될 수 있습니다. 일관된 복원력 구조를 보장하려면 서로 다른 CSP에서 호스팅되는 서비스를 지리적으로 가까운 CSP 데이터 센터에 배치하세요.
다음 다이어그램은 클라우드 간에 분산되고 서로 다른 애플리케이션 서비스가 서로 다른 CSP에 배포되는 전역 애플리케이션 스택을 보여줍니다. 각 글로벌 애플리케이션 서비스에는 동일한 CSP의 여러 리전에 워크로드 인스턴스가 있습니다.
애플리케이션 서비스 정의 및 액세스
애플리케이션을 조립하려면 기존 서드 파티 관리형 서비스를 사용하거나, 자체 애플리케이션 서비스를 만들고 호스팅하거나, 이 두 서비스를 조합하여 사용할 수 있습니다.
기존 서드 파티 관리형 서비스 사용
애플리케이션에 사용할 수 있는 서드 파티 관리형 서비스를 결정합니다. 리전 서비스 또는 전역 서비스로 구성된 서비스를 확인합니다. 또한 각 서비스에서 지원하는 비공개 액세스 옵션을 확인합니다.
사용할 수 있는 관리형 서비스를 알면 만들 서비스도 결정할 수 있습니다.
애플리케이션 서비스 만들기 및 액세스
각 서비스는 단일 엔드포인트 또는 엔드포인트 그룹으로 액세스할 수 있는 하나 이상의 워크로드 인스턴스에 의해 호스팅됩니다.
애플리케이션 서비스의 일반적인 패턴은 다음 다이어그램에 표시되어 있습니다. 애플리케이션 서비스는 워크로드 인스턴스 모음에 배포됩니다. (이 경우 워크로드 인스턴스는 Compute Engine VM, Google Kubernetes Engine (GKE) 클러스터 또는 코드를 실행하는 기타 백엔드일 수 있습니다.) 워크로드 인스턴스는 부하 분산기와 연결된 백엔드 집합으로 구성됩니다.
다음 다이어그램은 백엔드 집합이 있는 일반적인 부하 분산기를 보여줍니다.
선택한 부하 분산을 달성하고 장애 조치를 자동화하기 위해 이러한 엔드포인트 그룹은 프런트엔드 부하 분산기를 사용합니다. 관리형 인스턴스 그룹(MIG)을 사용하면 부하 분산기의 백엔드를 형성하는 엔드포인트를 자동 확장하여 서비스 용량을 탄력적으로 늘리거나 줄일 수 있습니다. 또한 애플리케이션 서비스의 요구사항에 따라 부하 분산기는 인증, TLS 종료, 기타 연결 관련 서비스도 제공할 수 있습니다.
서비스 범위 결정(리전 또는 전역)
서비스에 리전 또는 전역 복원력이 필요한지, 지원할 수 있는지 결정합니다. 리전 소프트웨어 서비스는 리전 지연 시간 예산 내에서 동기화되도록 설계할 수 있습니다. 글로벌 애플리케이션 서비스는 리전에 분산된 노드 간 동기식 장애 조치를 지원할 수 있습니다. 애플리케이션이 전역인 경우 이를 지원하는 서비스도 전역이기를 원할 수 있습니다. 하지만 서비스에서 장애 조치를 지원하기 위해 인스턴스 간 동기화가 필요한 경우 리전 간 지연 시간을 고려해야 합니다. 이 경우 동일한 리전 또는 인접한 리전에서 중복을 지원하는 리전 서비스를 사용하여 장애 조치를 위한 지연 시간이 짧은 동기화를 지원해야 할 수 있습니다.
Cloud Load Balancing은 단일 리전 내에 호스팅되거나 여러 리전에 분산된 엔드포인트를 지원합니다. 따라서 전역, 리전 또는 하이브리드 서비스 레이어에 대응하는 전역 고객 대면 레이어를 만들 수 있습니다. 서비스 배포를 선택하여 동적 네트워크 장애 조치(또는 리전 간 부하 분산)가 애플리케이션 로직의 복원력 상태 및 기능과 일치하도록 합니다.
다음 다이어그램은 리전별 부하 분산기로 빌드된 전역 서비스가 다른 리전의 백엔드에 도달하여 리전 간 자동 장애 조치를 제공하는 방법을 보여줍니다. 이 예에서 애플리케이션 로직은 전역적이며 선택한 백엔드는 리전 간 동기화를 지원합니다. 각 부하 분산기는 기본적으로 로컬 리전으로 요청을 전송하지만 원격 리전으로 장애 조치할 수 있습니다.
- 전역 백엔드는 하나 이상의 부하 분산기가 액세스하는 리전 백엔드의 모음입니다.
- 백엔드는 전역이지만 각 부하 분산기의 프런트엔드는 리전입니다.
- 이 아키텍처 패턴에서 부하 분산기는 기본적으로 리전 내에서만 트래픽을 분산하지만, 로컬 리전의 리소스를 사용할 수 없는 경우 다른 리전으로 트래픽을 분산할 수도 있습니다.
- 각각 다른 리전에서 액세스할 수 있고 다른 리전의 백엔드에 도달할 수 있는 리전 부하 분산기 프런트엔드 집합이 집계된 전역 서비스를 형성합니다.
- 전역 애플리케이션 스택 설계에서 설명한 대로 전역 애플리케이션 스택을 조합하려면 DNS 라우팅 및 상태 점검을 사용하여 프런트엔드의 리전 간 장애 조치를 수행할 수 있습니다.
- 부하 분산기 프런트엔드는 전역 액세스를 사용하여 다른 리전에서 자체적으로 액세스할 수 있습니다(다이어그램에 표시되지 않음).
이 동일한 패턴을 사용하여 전역 장애 조치로 게시된 서비스를 포함할 수 있습니다. 다음 다이어그램은 전역 백엔드를 사용하는 게시된 서비스를 보여줍니다.
다이어그램에서 게시된 서비스에는 프로듀서 환경에 구현된 전역 장애 조치가 있습니다. 소비자 환경에 전역 장애 조치를 추가하면 소비자 부하 분산 인프라의 리전 장애에 대한 복원력이 지원됩니다. 서비스의 리전 간 장애 조치는 서비스 애플리케이션 로직과 서비스 프로듀서의 부하 분산 설계 모두에서 구현되어야 합니다. 다른 메커니즘은 서비스 프로듀서가 구현할 수 있습니다.
사용할 Cloud Load Balancing 제품을 결정하려면 먼저 부하 분산기가 처리해야 하는 트래픽 유형을 결정해야 합니다. 다음 일반 규칙을 고려하세요.
- HTTP(S) 트래픽에는 애플리케이션 부하 분산기를 사용합니다.
- HTTP(S)가 아닌 TCP 트래픽에는 프록시 네트워크 부하 분산기를 사용합니다. 이 프록시 부하 분산기는 TLS 오프로드도 지원합니다.
- 패스 스루 네트워크 부하 분산기를 사용하여 헤더에서 클라이언트 소스 IP 주소를 보존하거나 UDP, ESP, ICMP와 같은 추가 프로토콜을 지원합니다.
사용 사례에 가장 적합한 부하 분산기를 선택하는 방법에 관한 자세한 안내는 부하 분산기 선택을 참고하세요.
서버리스 백엔드가 있는 서비스
서버리스 백엔드를 사용하여 서비스를 정의할 수 있습니다. 생산자 환경의 백엔드는 부하 분산기의 백엔드로 서버리스 NEG로 구성할 수 있습니다. 이 서비스는 프로듀서 부하 분산기의 프런트엔드와 연결된 서비스 연결을 만들어 Private Service Connect를 사용하여 게시할 수 있습니다. 게시된 서비스는 Private Service Connect 엔드포인트 또는 Private Service Connect 백엔드를 통해 사용할 수 있습니다. 서비스에 제작자가 시작한 연결이 필요한 경우 서버리스 VPC 액세스 커넥터를 사용하여 Cloud Run, App Engine 표준, Cloud Run Functions 환경에서 패킷을 VPC 네트워크에 있는 리소스의 내부 IPv4 주소로 전송할 수 있습니다. 서버리스 VPC 액세스에서는 패킷을 선택한 VPC 네트워크에 연결된 다른 네트워크로 전송할 수 있습니다.
비공개로 서비스에 액세스하는 방법
애플리케이션은 Google에서 제공하는 관리형 서비스, 조직의 외부 공급업체 또는 동종 앱 그룹에서 제공하는 서드 파티 서비스, 팀이 개발하는 서비스로 구성될 수 있습니다. 이러한 서비스 중 일부는 공개 IP 주소를 사용하여 인터넷을 통해 액세스할 수 있습니다. 이 섹션에서는 비공개 네트워크를 사용하여 이러한 서비스에 액세스하는 데 사용할 수 있는 방법을 설명합니다. 다음과 같은 서비스 유형이 있습니다.
- Google 공개 API
- Google 서버리스 API
- Google에서 게시한 관리형 서비스
- 공급업체 및 동종업체에서 게시한 관리형 서비스
- 게시된 서비스
다음 섹션을 읽을 때 이러한 옵션을 염두에 두세요. 서비스를 할당하는 방식에 따라 설명된 비공개 액세스 옵션을 하나 이상 사용할 수 있습니다.
서비스를 조합, 게시, 관리하는 조직(또는 조직 내 그룹)을 서비스 프로듀서라고 합니다. 사용자와 애플리케이션을 서비스 소비자라고 합니다.
일부 관리형 서비스는 비공개 서비스 액세스를 통해서만 게시됩니다. 내부 연결 및 VPC 네트워킹에 권장된 네트워크 설계는 비공개 서비스 액세스 및 Private Service Connect로 게시된 서비스를 수용합니다.
서비스에 비공개로 액세스하는 옵션에 대한 개요는 서비스 비공개 액세스 옵션을 참고하세요.
가능하면 Private Service Connect를 사용하여 관리형 서비스에 연결하는 것이 좋습니다. Private Service Connect 배포 패턴에 대한 자세한 내용은 Private Service Connect 배포 패턴을 참고하세요.
Private Service Connect에는 두 가지 유형이 있으며, 다양한 서비스를 다음 유형 중 하나로 게시할 수 있습니다.
Private Service Connect 엔드포인트로 게시된 서비스는 다른 워크로드에서 직접 사용할 수 있습니다. 서비스는 서비스 생산자가 프로비저닝한 인증 및 복원력을 사용합니다. 서비스 인증 및 복원력을 추가로 제어하려면 Private Service Connect 백엔드를 사용하여 소비자 네트워크에서 인증 및 복원력을 위한 부하 분산 계층을 추가하면 됩니다.
다음 다이어그램은 Private Service Connect 엔드포인트를 통해 액세스되는 서비스를 보여줍니다.
다이어그램은 다음 패턴을 보여줍니다.
- Private Service Connect 엔드포인트는 소비자 VPC에 배포되어 VM과 GKE 노드에서 프로듀서 서비스를 사용할 수 있도록 합니다.
- 소비자 네트워크와 프로듀서 네트워크가 모두 동일한 리전에 배포되어야 합니다.
위 다이어그램은 엔드포인트를 리전 리소스로 보여줍니다. 전역 액세스로 인해 다른 리전에서 엔드포인트에 연결할 수 있습니다.
배포 패턴에 대한 자세한 내용은 Private Service Connect 배포 패턴을 참고하세요.
Private Service Connect 백엔드는 Private Service Connect 네트워크 엔드포인트 그룹(NEG) 백엔드로 구성된 부하 분산기를 사용합니다. 지원되는 부하 분산기 목록은 Private Service Connect 백엔드 정보를 참고하세요.
Private Service Connect 백엔드를 사용하면 다음과 같은 백엔드 구성을 만들 수 있습니다.
- 관리형 서비스 앞의 고객 소유 도메인 및 인증서
- 다른 리전의 관리형 서비스 간 소비자 제어 장애 조치
- 관리형 서비스의 중앙 집중식 보안 구성 및 액세스 제어
다음 다이어그램에서 전역 부하 분산기는 서비스 제공업체와의 통신을 설정하는 백엔드로 Private Service Connect NEG를 사용합니다. 추가 네트워킹 구성이 필요하지 않으며 데이터는 Google의 SDN 패브릭을 통해 전송됩니다.
대부분의 서비스는 소비자가 시작하는 연결을 위해 설계되었습니다. 서비스가 프로듀서에서 연결을 시작해야 하는 경우 Private Service Connect 인터페이스를 사용합니다.
비공개 서비스 액세스 또는 Private Service Connect를 배포할 때 중요한 고려사항은 전이성입니다. Private Service Connect 소비자 액세스 포인트는 Network Connectivity Center를 통해 연결할 수 있습니다. 게시된 서비스는 Private Service Connect 또는 비공개 서비스 액세스 소비자 액세스 포인트의 VPC 네트워크 피어링 연결을 통해 연결될 수 없습니다. 모든 서비스 소비자 액세스 포인트에 대한 VPC 간 전이성이 없는 경우 VPC 토폴로지에서 서비스 액세스 서브넷 또는 엔드포인트의 위치에 따라 네트워크를 공유 서비스 배포용으로 설계할지 전용 서비스 배포용으로 설계할지를 결정합니다.
HA VPN 및 고객 관리 프록시와 같은 옵션은 VPC 간 전환 통신을 허용하는 방법을 제공합니다.
Private Service Connect 엔드포인트는 VPC 네트워크 피어링을 통해 연결할 수 없습니다. 이러한 유형의 연결이 필요한 경우 다음 다이어그램과 같이 내부 부하 분산기와 Private Service Connect NEG를 백엔드로 배포합니다.
Private Service Connect 엔드포인트 및 백엔드를 사용하여 Google API에 비공개로 액세스할 수 있습니다. 일반적으로 엔드포인트 사용이 권장됩니다. Google API 생산자가 복원력과 인증서 기반 인증을 제공하기 때문입니다.
서비스에 액세스해야 하는 모든 VPC에 Private Service Connect 엔드포인트를 만듭니다. 소비자 IP 주소는 비공개 전역 IP 주소이므로 다음 다이어그램과 같이 여러 VPC에 엔드포인트 인스턴스가 있는 경우에도 각 서비스에 단일 DNS 매핑이 필요합니다.
게시된 서비스의 소비 패턴 정의
게시된 서비스는 VPC 네트워크, 다른 VPC 네트워크, 온프레미스 데이터 센터, 클라우드 등 다양한 위치에서 실행될 수 있습니다. 서비스 워크로드가 실행되는 위치와 관계없이 애플리케이션은 다음 중 하나와 같은 액세스 포인트를 사용하여 이러한 서비스를 사용합니다.
- 비공개 서비스 액세스 서브넷의 IP 주소
- Private Service Connect 엔드포인트
- Private Service Connect NEG를 사용하는 부하 분산기의 VIP
소비자 액세스 포인트는 여러 네트워크에서 공유하거나 단일 네트워크 전용으로 사용할 수 있습니다. 조직에서 소비자 서비스 액세스 포인트 생성 작업을 각 애플리케이션 그룹에 위임하는지 아니면 통합된 방식으로 서비스에 대한 액세스를 관리하는지에 따라 공유 또는 전용 소비자 액세스 포인트를 만들지 결정합니다.
서비스 액세스 관리에는 다음 활동이 포함됩니다.
- 액세스 포인트 만들기
- 적절한 유형의 연결 가능성이 있는 VPC인 서비스 액세스 VPC에 액세스 포인트를 배포합니다.
- DNS에 소비자 액세스 포인트의 IP 주소 및 URL 등록
- 소비자 액세스 포인트 앞에 부하 분산을 추가할 때 소비자 공간에서 서비스의 보안 인증서와 복원력 관리
일부 조직에서는 서비스 액세스 관리를 중앙팀에 할당하는 것이 가능할 수 있지만, 다른 조직은 각 소비자 또는 애플리케이션팀에 더 높은 독립성을 제공하도록 구조화될 수 있습니다. 전용 모드에서 작동하면 일부 요소가 복제됩니다. 예를 들어 각 애플리케이션 그룹별로 서비스가 여러 DNS 이름으로 등록되고 여러 TLS 인증서 집합을 관리합니다.
교차 클라우드 네트워크의 분산형 애플리케이션에 대한 네트워크 세분화 및 연결에 설명된 VPC 설계는 공유 또는 전용 모드로 서비스 액세스 포인트를 배포하기 위한 연결 가능성을 지원합니다. 공유 소비자 액세스 포인트는 서비스 액세스 VPC에 배포되며, 다른 VPC 또는 외부 네트워크에서 액세스할 수 있습니다. 전용 소비자 액세스 포인트는 애플리케이션 VPC에 배포되며 해당 애플리케이션 VPC 내의 리소스에서만 액세스할 수 있습니다.
서비스 액세스 VPC와 애플리케이션 VPC의 주요 차이점은 서비스 액세스 VPC가 지원하는 서비스 액세스 지점 전환 연결입니다. 서비스 액세스 VPC는 소비자 액세스 포인트를 호스팅하는 데만 사용되지 않습니다. VPC는 애플리케이션 리소스와 공유 소비자 액세스 포인트를 호스팅할 수 있습니다. 이 경우 VPC는 서비스 VPC로 구성되고 처리되어야 합니다.
공유 관리형 서비스 액세스
Private Service Connect를 비롯한 모든 서비스 소비 방법의 경우 다음 작업을 수행해야 합니다.
- 서비스 VPC에 서비스 소비자 액세스 포인트를 배포합니다. 서비스 VPC는 다른 VPC에 대한 전환 도달 가능성이 있습니다.
- 서비스 액세스 VPC가 HA VPN에 연결된 경우 HA VPN을 통해 다른 네트워크와 피어링하는 Cloud Router에서 소비자 액세스 포인트의 서브넷을 커스텀 경로 공지로 공지합니다. Google API의 경우 API의 호스트 IP 주소를 광고합니다.
- 비공개 서비스 액세스 서브넷을 허용하도록 멀티 클라우드 방화벽 규칙을 업데이트합니다.
특히 비공개 서비스 액세스의 경우 다음 추가 요구사항을 충족할 수 있는지 확인하세요.
- 커스텀 경로를 서비스 제작자의 네트워크로 내보내기. 자세한 내용은 온프레미스 호스트는 서비스 제작자의 네트워크와 통신할 수 없습니다를 참고하세요.
- 애플리케이션 VPC로 비공개 서비스 액세스 서브넷을 허용하는 인그레스 방화벽 규칙 만들기
- 서비스 VPC로 비공개 서비스 액세스 서브넷을 허용하는 인그레스 방화벽 규칙 만들기
서버리스 서비스 액세스의 경우 다음 요구사항을 충족할 수 있는지 확인하세요.
- 액세스 커넥터에는 전용 /28 일반 서브넷이 필요합니다.
- Cloud Router가 기본적으로 일반 서브넷 공지
- VPC 내의 모든 VPC 액세스 서브넷을 허용하는 인그레스 방화벽 규칙 만들기
- VPC 액세스 커넥터 서브넷을 허용하도록 멀티 클라우드 방화벽 규칙 업데이트
- 애플리케이션 VPC로 비공개 서비스 액세스 서브넷을 허용하는 인그레스 방화벽 규칙 만들기
전용 관리형 서비스 액세스
다음 작업을 수행해야 합니다.
- 액세스가 필요한 각 애플리케이션 VPC에서 서비스의 전달 규칙을 배포하여 액세스 포인트를 만듭니다.
- 비공개 서비스 액세스의 경우 애플리케이션 VPC로 비공개 서비스 액세스 서브넷을 허용하는 인그레스 방화벽 규칙을 만듭니다.
서버리스 서비스 액세스의 경우 다음 요구사항을 충족할 수 있는지 확인하세요.
- 액세스 커넥터에는 전용 /28 일반 서브넷이 필요합니다.
- 애플리케이션 VPC 내에서 VPC 액세스 커넥터 서브넷을 허용하는 인그레스 방화벽 규칙 만들기
애플리케이션 스택 어셈블
이 섹션에서는 리전 또는 전역 애플리케이션 스택을 어셈블하는 방법을 설명합니다.
리전 애플리케이션 스택 설계
애플리케이션이 리전 또는 멀티 리전 배포 원형을 따르는 경우 리전 애플리케이션 스택을 사용합니다. 리전 애플리케이션 스택은 리전 애플리케이션 서비스 레이어의 연결로 생각할 수 있습니다. 예를 들어 동일한 리전의 애플리케이션 레이어와 통신하고, 이 레이어가 다시 동일한 리전의 데이터베이스 레이어와 통신하는 리전 웹 서비스 레이어는 리전 애플리케이션 스택입니다.
각 리전 애플리케이션 서비스 레이어는 부하 분산기를 사용하여 해당 리전의 레이어 엔드포인트 간에 트래픽을 분산합니다. 안정성은 리전의 3개 이상의 영역에 백엔드 리소스를 분산하여 달성됩니다.
다른 CSP 또는 온프레미스 데이터 센터의 애플리케이션 서비스 레이어는 외부 네트워크의 동일한 리전에 배포해야 합니다. 또한 게시된 서비스를 스택의 리전에서 사용할 수 있도록 합니다. 리전 내에서 애플리케이션 스택을 정렬하려면 애플리케이션 서비스 레이어 URL이 특정 부하 분산기 프런트엔드 리전 IP 주소로 확인되어야 합니다. 이러한 DNS 매핑은 각 애플리케이션 서비스의 관련 DNS 영역에 등록됩니다.
다음 다이어그램은 활성-대기 복원력을 갖춘 리전 스택을 보여줍니다.
애플리케이션 스택의 전체 인스턴스가 여러 클라우드 데이터 센터의 각 리전에 배포됩니다. 애플리케이션 서비스 레이어에서 리전 장애가 발생하면 다른 리전의 스택이 전체 애플리케이션 전송을 대신 수행합니다. 이 장애 조치는 다양한 애플리케이션 서비스 레이어의 대역 외 모니터링에 대한 응답으로 실행됩니다.
서비스 레이어 중 하나에 장애가 보고되면 애플리케이션의 프런트엔드가 백업 스택에 다시 고정됩니다. 애플리케이션의 각 레이어가 동일한 리전 내에서 연결을 유지하도록 DNS의 리전 IP 주소 스택을 반영하는 리전 이름 레코드 집합을 참조하도록 애플리케이션이 작성됩니다.
전역 애플리케이션 스택 설계
애플리케이션이 전역 애플리케이션 배포 원형을 따르는 경우 각 애플리케이션 서비스 레이어에는 여러 리전의 백엔드가 포함됩니다. 여러 리전에 백엔드를 포함하면 단일 리전을 넘어 애플리케이션 서비스 레이어의 복원력 풀이 확장되고 자동 장애 조치 감지 및 재수렴이 가능해집니다.
다음 다이어그램은 전역 애플리케이션 스택을 보여줍니다.
위의 다이어그램은 다음 구성요소로 조합된 전역 애플리케이션을 보여줍니다.
- 부하 분산기 프런트엔드가 있는 온프레미스 데이터 센터에서 실행되는 서비스 부하 분산기 액세스 포인트는 전송 VPC에서 Cloud Interconnect를 통해 연결할 수 있습니다.
- 전송 VPC는 외부 데이터 센터와 애플리케이션 VPC 간의 하이브리드 연결을 호스팅합니다.
- 워크로드 인스턴스에서 실행되는 핵심 애플리케이션을 호스팅하는 애플리케이션 VPC입니다. 이러한 워크로드 인스턴스는 부하 분산기 뒤에 있습니다. 부하 분산기는 네트워크의 모든 리전에서 연결할 수 있으며 네트워크의 모든 리전에서 백엔드에 연결할 수 있습니다.
- 서드 파티 VPC와 같은 다른 위치에서 실행되는 서비스의 액세스 포인트를 호스팅하는 서비스 VPC입니다. 이러한 서비스 액세스 포인트는 서비스 VPC와 전송 VPC 간의 HA VPN 연결을 통해 연결할 수 있습니다.
- 다른 조직 또는 다른 위치에서 실행되는 기본 조직 및 애플리케이션에서 호스팅하는 서비스 프로듀서 VPC입니다. 서비스 VPC에서 호스팅되는 리전 부하 분산기에 전역 백엔드로 배포된 Private Service Connect 백엔드를 통해 관련 서비스에 연결할 수 있습니다. 리전별 부하 분산기는 다른 모든 리전에서 연결할 수 있습니다.
생성된 애플리케이션을 인터넷에서 연결할 수 있도록 하려면 애플리케이션 VPC의 애플리케이션 워크로드를 가리키는 전역 외부 애플리케이션 부하 분산기를 추가하면 됩니다(다이어그램에는 표시되지 않음).
전역 애플리케이션 스택을 지원하기 위해 각 애플리케이션 레이어에 전역 백엔드를 사용했습니다. 이를 통해 한 리전의 모든 백엔드 엔드포인트 장애로부터 복구할 수 있습니다. 각 리전에는 각 애플리케이션 서비스 계층의 리전 부하 분산기 프런트엔드가 있습니다. 리전 장애 조치가 발생하면 내부 리전 부하 분산기 프런트엔드는 전역 액세스를 사용하므로 리전 간에 연결할 수 있습니다. 애플리케이션 스택이 전역이므로 DNS 위치정보 라우팅 정책을 사용하여 특정 요청 또는 흐름에 가장 적합한 리전 프런트엔드를 선택합니다. 프런트엔드 오류가 발생할 경우 DNS 상태 점검을 사용하여 한 프런트엔드에서 다른 프런트엔드로의 장애 조치를 자동화할 수 있습니다.
Private Service Connect 백엔드를 사용하여 게시된 서비스는 Private Service Connect 전역 액세스의 이점을 얻을 수 있습니다. 이 기능을 사용하면 Private Service Connect 백엔드에 모든 리전에서 연결할 수 있으며 애플리케이션 서비스 레이어 장애로 인한 중단을 줄일 수 있습니다. 즉, 서비스 범위 결정 - 리전 또는 전역에 설명된 대로 Private Service Connect 백엔드를 전역 백엔드로 활용할 수 있습니다.
외부 네트워크에서 호스팅되는 서비스에 대한 비공개 액세스 제공
다른 네트워크에서 호스팅되는 서비스의 로컬 액세스 포인트를 게시할 수 있습니다. 이러한 경우 하이브리드 NEG를 사용하여 내부 리전 TCP 프록시 부하 분산기를 사용할 수 있습니다. 다음 다이어그램과 같이 온프레미스 또는 다른 클라우드 환경에서 호스팅되는 서비스 프로듀서를 만들어 VPC 네트워크의 서비스 소비자 (클라이언트)가 사용할 수 있습니다.
부하 분산기를 호스팅하는 VPC 네트워크가 아닌 다른 VPC 네트워크에서 하이브리드 서비스를 사용할 수 있게 하려면 Private Service Connect를 사용하여 서비스를 게시하면 됩니다. 내부 리전 TCP 프록시 부하 분산기 앞에 서비스 연결을 배치하면 다른 VPC 네트워크의 클라이언트가 온프레미스 또는 다른 클라우드 환경에서 실행되는 하이브리드 서비스에 도달할 수 있습니다.
크로스 클라우드 환경에서 하이브리드 NEG를 사용하면 애플리케이션 간 보안 통신이 가능합니다.
다른 조직에서 애플리케이션 서비스를 게시하는 경우 하이브리드 NEG를 사용하여 해당 서비스의 비공개 액세스 추상화를 확장합니다. 다음 다이어그램은 이 시나리오를 보여줍니다.
위 다이어그램에서 애플리케이션 서비스 레이어는 회색으로 표시되지 않은 다이어그램 부분에서 강조 표시된 인접 CSP에서 완전히 구성됩니다. 하이브리드 부하 분산기는 Private Service Connect 서비스 연결과 함께Google Cloud내에서 비공개 소비를 위한 외부 애플리케이션 서비스를 게시하는 메커니즘으로 사용됩니다. 하이브리드 NEG 및 Private Service Connect 서비스 연결을 사용하는 하이브리드 부하 분산기는 서비스 프로듀서 프로젝트의 일부인 VPC에 있습니다. 이 서비스 프로듀서 프로젝트는 프로듀서 조직 또는 프로젝트의 관리 범위 내에 있어 공통 전송 서비스와 별개이므로 일반적으로 전송 VPC와 다른 VPC일 수 있습니다. 프로듀서 VPC는 VPC 피어링 또는 HA VPN을 소비자 VPC (다이어그램의 서비스 공유 VPC)에 연결할 필요가 없습니다.
서비스 액세스 중앙 집중화
서비스 액세스를 VPC 네트워크로 중앙 집중화하고 다른 애플리케이션 네트워크에서 액세스할 수 있습니다. 다음 다이어그램은 액세스 포인트의 중앙 집중화를 지원하는 일반적인 패턴을 보여줍니다.
다음 다이어그램은 전용 서비스 VPC에서 액세스하는 모든 서비스를 보여줍니다.
서비스가 애플리케이션 부하 분산기를 사용하여 프런트엔드로 제공되면 서비스마다 다른 부하 분산기를 사용하는 대신 URL 맵을 사용하여 서로 다른 서비스 백엔드의 트래픽을 조정함으로써 더 적은 수의 부하 분산기로 통합할 수 있습니다. 원칙적으로 애플리케이션 스택은 단일 애플리케이션 부하 분산기와 서비스 백엔드, 적절한 URL 매핑을 사용하여 완전히 구성할 수 있습니다.
이 구현에서는 대부분의 백엔드 유형에 대해 VPC 전체에서 하이브리드 NEG를 사용해야 합니다. 예외는 Private Service Connect를 사용한 Google Cloud L7 부하 분산기의 명시적 연결에 설명된 Private Service Connect NEG 또는 백엔드입니다.
VPC 전체에서 하이브리드 NEG를 사용하면 백엔드에 대한 자동 복구 및 자동 확장이 수행되지 않는 단점이 있습니다. 게시된 서비스에는 이미 자동 확장 기능을 제공하는 프로듀서 테넌트의 부하 분산기가 있습니다. 따라서 하이브리드 NEG의 제한사항은 게시에서 소비되는 것이 아니라 기본적으로 구성되는 서비스 레이어의 부하 분산 기능을 중앙화하는 경우에만 적용됩니다.
이 서비스 네트워킹 패턴을 사용할 때는 서비스가 추가 부하 분산 계층을 통해 사용된다는 점에 유의하세요.
Private Service Connect 서비스 엔드포인트는 Network Connectivity Center 스포크 VPC 간에 연결할 수 있습니다.
중앙 집중식 모드는 서비스의 소비자 측에 부하 분산 레이어를 추가합니다. 이 모드를 사용하는 경우 소비자 프로젝트에서 인증서, 복원력, 추가 DNS 매핑도 관리해야 합니다.
기타 고려사항
이 섹션에는 이 문서에서 명시적으로 다루지 않는 일반적인 제품 및 서비스에 대한 고려사항이 포함되어 있습니다.
GKE 컨트롤 플레인 고려사항
GKE 컨트롤 플레인은 VPC 네트워크 피어링을 통해 고객의 VPC에 연결된 Google 관리 테넌트 프로젝트에 배포됩니다. VPC 네트워크 피어링은 전환되지 않으므로 허브 및 스포크 VPC 피어링 네트워킹 토폴로지를 통해 컨트롤 플레인과 직접 통신할 수 없습니다.
중앙 집중식 또는 분산식과 같은 GKE 설계 옵션을 고려할 때는 멀티 클라우드 소스에서 컨트롤 플레인에 직접 액세스하는 것이 중요합니다. GKE가 중앙 집중식 VPC에 배포된 경우 여러 클라우드 및Google Cloud내에서 컨트롤 플레인에 대한 액세스를 사용할 수 있습니다. 하지만 GKE가 분산된 VPC에 배포된 경우 컨트롤 플레인과 직접 통신할 수 없습니다. 조직 요구사항에 따라 분산된 설계 패턴을 채택하는 것 외에도 GKE 컨트롤 플레인에 대한 액세스가 필요한 경우 네트워크 관리자는 프록시 역할을 하는 연결 에이전트를 배포하여 GKE 컨트롤 플레인에 대한 비전환 피어링 제한을 극복할 수 있습니다.
보안 - VPC 서비스 제어
민감한 정보가 포함된 워크로드의 경우, VPC 서비스 제어를 사용하면 Google 관리형 서비스의 VPC 리소스 주위에 서비스 경계를 구성하고 경계 범위 간의 데이터 이동을 제어할 수 있습니다. VPC 서비스 제어를 사용하면 프로젝트와 온프레미스 네트워크를 단일 경계로 그룹화하여 Google 관리형 서비스를 통한 데이터 액세스를 차단할 수 있습니다. VPC 서비스 제어의 인그레스 및 이그레스 규칙을 사용하면 서로 다른 서비스 경계에 있는 프로젝트와 서비스가 통신하도록 할 수 있습니다(경계 내부에 없는 VPC 네트워크 포함).
권장되는 배포 아키텍처, 종합적인 온보딩 프로세스, 운영 권장사항은 기업용 VPC 서비스 제어 권장사항 및 Security Foundations 청사진을 참조하세요.
API/서비스용 DNS
서비스 프로듀서는 Private Service Connect를 사용하여 서비스를 게시할 수 있습니다. 서비스 프로듀서는 필요할 경우 서비스와 연결하도록 DNS 도메인 이름을 구성할 수 있습니다. 도메인 이름이 구성되고 서비스 소비자가 해당 서비스를 타겟팅하는 엔드포인트를 생성하면 Private Service Connect 및 서비스 디렉터리가 서비스 소비자의 VPC 네트워크에 있는 비공개 DNS 영역의 서비스에 대한 DNS 항목을 자동으로 만듭니다.
다음 단계
- 교차 클라우드 네트워크 애플리케이션용 네트워크 보안을 설계합니다.
- 이 설계 가이드에서 사용되는 Google Cloud 제품에 대해 자세히 알아보세요.
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.
참여자
저자:
- 빅터 모레노 | Cloud Networking 제품 관리자
- Ghaleb Al-habian | 네트워크 전문가
- Deepak Michael | 네트워킹 전문 고객 엔지니어
- Osvaldo Costa | 네트워킹 전문 고객 엔지니어
- Jonathan Almaleh | 직원 기술 솔루션 컨설턴트
기타 참여자:
- Zach Seils | 네트워킹 전문가
- Christopher Abraham | 네트워킹 전문가 고객 엔지니어
- Emanuele Mazza | 네트워킹 제품 전문가
- Aurélien Legrand | 전략적 클라우드 엔지니어
- Eric Yu | 네트워킹 전문가 고객 엔지니어
- 저자: 쿠마르 다나고팔 | 크로스 프로덕트 솔루션 개발자
- 마크 슐라겐하우프 | 네트워킹 테크니컬 라이터
- 마르완 알 샤위 | 파트너 고객 엔지니어
- Ammett Williams | 개발자 관계 엔지니어