이 문서는 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 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를 배포할 때 중요한 고려사항은 전환성입니다. 게시된 서비스는 일반적으로 VPC 네트워크 피어링 연결 또는 Network Connectivity Center를 통해 연결할 수 없습니다. VPC 토폴로지에서 서비스 액세스 서브넷 또는 엔드포인트의 위치에 따라 네트워크를 공유 서비스 배포용으로 설계할지 전용 서비스 배포용으로 설계할지를 결정합니다.
HA VPN 및 고객 관리 프록시와 같은 옵션은 VPC 간 전환 통신을 허용하는 방법을 제공합니다.
Private Service Connect 엔드포인트는 VPC 네트워크 피어링을 통해 연결할 수 없습니다. 이 유형의 연결이 필요하면 다음 다이어그램과 같이 내부 부하 분산기와 Private Service Connect NEG를 백엔드로 배포합니다.
Google API는 Private Service Connect 엔드포인트 및 백엔드를 사용하여 비공개로 액세스할 수 있습니다. Google API 제작자가 복원력과 인증서 기반 인증을 제공하므로 일반적으로 엔드포인트를 사용하는 것이 좋습니다.
서비스에 액세스해야 하는 모든 VPC에서 Private Service Connect 엔드포인트를 만듭니다. 소비자 IP 주소는 비공개 전역 IP 주소이므로 다음 다이어그램에 표시된 것처럼 여러 VPC에 엔드포인트 인스턴스가 있더라도 각 서비스에 대해 단일 DNS 매핑이 필요합니다.
서비스 소비 패턴 정의
서비스는 VPC 네트워크, 다른 VPC 네트워크, 온프레미스 데이터 센터, 클라우드 등 다양한 위치에서 실행할 수 있습니다. 서비스 워크로드가 실행되는 위치에 관계없이 애플리케이션은 다음 중 하나와 같은 액세스 포인트를 사용하여 이러한 서비스를 사용합니다.
- 비공개 서비스 액세스 서브넷의 IP 주소
- Private Service Connect 엔드포인트
- Private Service Connect NEG를 사용하는 부하 분산기의 VIP
소비자 액세스 포인트는 네트워크 간에 공유되거나 단일 네트워크 전용으로 사용될 수 있습니다. 조직에서 소비자 서비스 액세스 포인트 만들기 작업을 각 애플리케이션 그룹에 위임하거나 통합된 방식으로 서비스에 대한 액세스를 관리하는지 여부에 따라 공유 또는 전용 소비자 액세스 포인트를 만들지 결정합니다.
서비스 액세스 관리에는 다음 활동이 포함됩니다.
- 액세스 포인트 만들기
- 적절한 유형의 연결 가능성이 있는 VPC에 액세스 포인트 배포
- DNS에서 소비자 액세스 포인트의 IP 주소 및 URL 등록
- 소비자 액세스 포인트 앞에 부하 분산을 추가할 때 소비자 공간의 서비스에 대한 보안 인증서 및 복원력 관리
일부 조직에서는 서비스 액세스 관리를 중앙팀에 할당하는 것이 가능할 수 있지만, 다른 조직은 각 소비자 또는 애플리케이션팀에 더 높은 독립성을 제공하도록 구조화될 수 있습니다. 전용 모드에서 작업할 때는 일부 요소가 복제됩니다. 예를 들어 각 애플리케이션 그룹별로 서비스가 여러 DNS 이름으로 등록되고 여러 TLS 인증서 집합을 관리합니다.
교차 클라우드 네트워크의 분산형 애플리케이션에 대한 네트워크 세분화 및 연결에 설명된 VPC 설계는 공유 또는 전용 모드로 서비스 액세스 포인트를 배포하기 위한 연결 가능성을 지원합니다. 공유 소비자 액세스 포인트는 다른 VPC 또는 외부 네트워크에서 액세스할 수 있는 서비스 VPC에 배포됩니다. 전용 소비자 액세스 포인트는 해당 애플리케이션 VPC 내의 리소스에서만 액세스할 수 있는 애플리케이션 VPC에 배포됩니다.
서비스 VPC와 애플리케이션 VPC의 주요 차이점은 서비스 VPC가 지원하는 서비스 액세스 지점 전환 연결입니다. 서비스 VPC는 소비자 액세스 포인트 호스팅으로 제한되지 않습니다. VPC는 공유 소비자 액세스 포인트와 애플리케이션 리소스를 호스팅할 수 있습니다. 이러한 경우 VPC를 서비스 VPC로 구성하고 처리해야 합니다.
공유 관리형 서비스 액세스
Private Service Connect를 포함한 모든 서비스 소비 메서드에 대해 다음 태스크를 수행해야 합니다.
- 서비스 VPC에 서비스 소비자 액세스 포인트를 배포합니다. 서비스 VPC는 다른 VPC로 전환 연결이 가능합니다.
- 소비자 액세스 포인트의 서브넷을 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에 완전히 구성되어 있으며, 다이어그램에서 비활성화되지 않은 부분에 강조표시됩니다. 하이브리드 부하 분산기는 Google Cloud 내에서 비공개 소비를 위해 외부 애플리케이션 서비스를 게시하는 메커니즘으로 Private Service Connect 서비스 연결과 함께 사용됩니다. 하이브리드 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의 제한사항은 게시에서 소비되는 것이 아니라 기본적으로 구성되는 서비스 레이어의 부하 분산 기능을 중앙화하는 경우에만 적용됩니다.
이 서비스 네트워킹 패턴을 사용하는 경우 서비스가 추가 부하 분산 레이어를 통해 소비된다는 점을 기억하세요.
프록시 부하 분산을 사용하면 VPC 전반에서 Network Connectivity Center 스포크 VPC 연결의 확장성 이점을 누리면서 프록시 부하 분산기를 통해 게시된 서비스에 전환 연결을 제공할 수 있습니다.
Private Service Connect 서비스 엔드포인트 및 비공개 서비스 액세스용 전달 규칙은 Network Connectivity Center 스포크 VPC 간에 연결할 수 없습니다. 마찬가지로 동적 경로가 Network Connectivity Center를 통해 전파되지 않으므로 하이브리드 연결(Cloud Interconnect 또는 HA-VPN) 이면의 네트워크는 Network Connectivity Center 스포크 VPC에서 연결할 수 없습니다.
이러한 연결성 부족 문제는 하이브리드 NEG로 처리되는 비전환 리소스로 프록시 부하 분산기를 배포하여 해결할 수 있습니다. 따라서 서비스 프론트엔드와 하이브리드 연결을 통해 접근할 수 있는 워크로드 앞에 프록시 부하 분산기를 배포할 수 있습니다.
부하 분산기 프록시 프런트엔드는 Network Connectivity Center 스포크 VPC에 전파되는 VPC 서브넷에 배포됩니다. 이 전파를 사용하면 프록시 부하 분산기를 통해 비전환 리소스의 Network Connectivity Center를 통해 연결할 수 있습니다.
중앙 집중식 모드는 서비스의 소비자 측에 부하 분산 레이어를 추가합니다. 이 모드를 사용할 때는 소비자 프로젝트에서 인증서, 복원력, 추가 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 제품을 자세히 알아보세요.
- 방화벽 NVA 배포 방법은 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 | 개발자 관계 엔지니어