이 문서는 총 3부로 구성된 문서 중 세 번째 문서입니다. 하이브리드 및 멀티 클라우드 네트워킹 아키텍처 패턴에 대해 다룹니다. 하이브리드 및 멀티 클라우드 아키텍처에 사용할 수 있는 몇 가지 일반적인 보안 네트워크 아키텍처 패턴을 설명합니다. 이 문서에서는 이러한 네트워킹 패턴이 가장 적합한 시나리오를 설명하고 Google Cloud로 이를 구현하기 위한 권장사항을 제공합니다.
하이브리드 및 멀티 클라우드 아키텍처 패턴에 관한 문서 세트는 다음과 같이 구성됩니다.
- 하이브리드 및 멀티 클라우드 아키텍처 빌드: Google Cloud를 사용하여 하이브리드 및 멀티 클라우드 설정을 설계하기 위한 전략 계획을 논의합니다.
- 하이브리드 및 멀티 클라우드 아키텍처 패턴: 하이브리드 및 멀티 클라우드 전략의 일부로 채택할 일반적인 아키텍처 패턴을 논의합니다.
- 하이브리드 및 멀티 클라우드 보안 네트워킹 아키텍처 패턴: 네트워킹 관점에서 하이브리드 및 멀티 클라우드 네트워킹 아키텍처 패턴을 논의합니다.
성공적인 하이브리드 및 멀티 클라우드 아키텍처를 위해서는 비공개 컴퓨팅 환경을 Google Cloud에 안전하게 안정적으로 연결하는 것이 필수적입니다. 하이브리드 및 멀티 클라우드 설정을 위해 선택하는 하이브리드 네트워킹 연결 및 클라우드 네트워킹 아키텍처 패턴은 엔터프라이즈 워크로드의 고유한 요구사항을 충족해야 합니다. 또한 적용하려는 아키텍처 패턴에 적합해야 합니다. 각 설계를 조정해야 할 수도 있지만 청사진으로 사용할 수 있는 일반적인 패턴이 있습니다.
이 문서의 네트워킹 아키텍처 패턴을 Google Cloud의 시작 영역 설계의 대안으로 간주해서는 안 됩니다. 대신 다음 영역을 포함한 전체 Google Cloud 시작 영역 설계의 일부로 선택한 아키텍처 패턴을 설계하고 배포해야 합니다.
- ID
- 리소스 관리
- 보안
- 네트워킹
- 모니터링
애플리케이션마다 시작 영역 아키텍처의 일부로 통합된 다른 네트워킹 아키텍처 패턴을 사용할 수 있습니다. 멀티 클라우드 설정의 경우 모든 환경에서 시작 영역 설계의 일관성을 유지해야 합니다.
이 시리즈에는 다음 페이지가 포함되어 있습니다.
참여자
저자: 마르완 알 샤위 | 파트너 고객 엔지니어
기타 참여자:
- 사우드 알바제이 | 고객 엔지니어, 애플리케이션 현대화
- 안나 베렌버그 | 엔지니어링 연구원
- 마르코 페라리 | 클라우드 솔루션 설계자
- 빅터 모레노 | Cloud Networking 제품 관리자
- 요하네스 패싱 | 클라우드 솔루션 설계자
- 마크 슐라겐하우프 | 네트워킹 테크니컬 라이터
- 다니엘 스트레벨 | 애플리케이션 현대화 부문 EMEA 솔루션 책임자
- 아밋 윌리엄스 | 개발자 관계팀 엔지니어
아키텍처 패턴
이 시리즈의 문서에서는 Google Cloud와 다른 환경(온프레미스, 다른 클라우드 또는 둘 다)에 있는 애플리케이션 간의 필수 통신 모델을 기반으로 설계된 네트워킹 아키텍처 패턴을 설명합니다.
이러한 패턴은 다양한 애플리케이션의 특정 통신 및 보안 요구사항을 해결하기 위한 여러 네트워킹 패턴을 포함할 수 있는 전체 조직 방문 페이지 영역 아키텍처에 통합되어야 합니다.
이 시리즈의 문서에서는 각 아키텍처 패턴과 함께 사용할 수 있는 다양한 디자인 변형에 대해서도 설명합니다. 다음 네트워킹 패턴은 애플리케이션의 통신 및 보안 요구사항을 충족하는 데 도움이 될 수 있습니다.
미러링 패턴
미러링 패턴은 특정 기존 환경의 설계를 새 환경에 복제하는 것을 기반으로 합니다. 따라서 이 패턴은 주로 환경 하이브리드 패턴을 따르는 아키텍처에 적용됩니다. 이 패턴에서는 한 환경에서 개발 및 테스트 워크로드를 실행하고 다른 환경에서 스테이징 및 프로덕션 워크로드를 실행합니다.
미러링 패턴은 테스트 및 프로덕션 워크로드가 서로 직접 통신하지 않는다고 가정합니다. 그러나 두 워크로드 그룹을 일관된 방식으로 관리하고 배포할 수 있어야 합니다.
이 패턴을 사용하는 경우 다음 요구사항에 맞는 방식으로 두 컴퓨팅 환경을 연결합니다.
- 지속적 통합/지속적 배포(CI/CD)는 모든 컴퓨팅 환경 또는 특정 환경에서 워크로드를 배포하고 관리할 수 있습니다.
- 모니터링, 구성 관리, 기타 관리 시스템은 컴퓨팅 환경 전반에서 작동해야 합니다.
- 워크로드는 컴퓨팅 환경 간에 직접 통신할 수 없습니다. 필요한 경우 통신을 세분화하고 제어해야 합니다.
아키텍처
다음 아키텍처 다이어그램은 CI/CD, 모니터링, 구성 관리, 기타 관리 시스템, 워크로드 통신을 지원하는 이 패턴의 상위 수준 참조 아키텍처를 보여줍니다.
앞의 다이어그램에서 아키텍처에 대한 설명은 다음과 같습니다.
- 워크로드는 기능 환경(개발, 테스트, CI/CD, 관리 도구)에 따라 Google Cloud 측의 별도 VPC에 분산됩니다.
- 공유 VPC는 개발 및 테스트 워크로드에 사용됩니다. CI/CD 및 관리 도구에는 추가 VPC가 사용됩니다. 공유 VPC를 사용할 경우 다음과 같습니다.
- 애플리케이션은 환경 및 서비스 프로젝트별로 다른 팀에서 관리합니다.
- 호스트 프로젝트는 개발 및 테스트 환경 간의 네트워크 통신 및 보안 제어와 VPC 외부로의 네트워크 통신 및 보안 제어를 관리하고 제어합니다.
- CI/CD VPC는 비공개 컴퓨팅 환경에서 프로덕션 워크로드를 실행하는 네트워크에 연결됩니다.
- 방화벽 규칙은 허용된 트래픽만 허용합니다.
- 침입 방지 서비스(IPS)를 사용해서 설계 또는 라우팅을 변경하지 않고 위협 방지를 위해 심층 패킷 검사를 구현하는 Cloud Next Generation Firewall Enterprise를 사용할 수도 있습니다. Cloud Next Generation Firewall Enterprise는 패킷 가로채기 기술을 사용하여 구성된 위협 서명에 대해 워크로드를 투명하게 검사하는 Google 관리 영역 방화벽 엔드포인트를 만들어 작동합니다. 또한 위협으로부터 워크로드를 보호합니다.
- 내부 IP 주소를 사용하여 피어링된 VPC 간의 통신을 사용 설정합니다.
- 이 패턴의 피어링을 통해 CI/CD 및 관리 시스템은 개발 및 테스트 워크로드를 배포하고 관리할 수 있습니다.
- 다음 일반 권장사항을 고려하세요.
비즈니스 및 애플리케이션 요구사항을 충족하는 앞서 설명한 하이브리드 및 멀티 클라우드 네트워킹 연결 옵션 중 하나를 사용하여 이 CI/CD 연결을 설정합니다. 프로덕션 워크로드를 배포하고 관리할 수 있도록 이 연결은 여러 컴퓨팅 환경 간에 비공개 네트워크 도달성을 제공합니다. 모든 환경은 겹치지 않는 RFC 1918 IP 주소 공간을 사용해야 합니다.
개발 및 테스트 환경의 인스턴스에 인터넷 액세스가 필요한 경우 다음 옵션을 고려하세요.
- 동일한 공유 VPC 호스트 프로젝트 네트워크에 Cloud NAT를 배포할 수 있습니다. 동일한 공유 VPC 호스트 프로젝트 네트워크에 배포하면 인터넷에서 이러한 인스턴스에 직접 액세스하지 못하게 만들 수 있습니다.
- 아웃바운드 웹 트래픽의 경우 보안 웹 프록시를 사용할 수 있습니다. 프록시는 몇 가지 이점이 있습니다.
Google Cloud와 하이브리드 및 멀티 클라우드 환경에서 빌드, 테스트, 배포하는 데 도움이 되는 Google Cloud 도구 및 기능에 대한 자세한 내용은 Google Cloud의 DevOps 및 CI/CD 설명 블로그를 참조하세요.
변형
모든 통신 요구사항을 고려하면서 다양한 설계 요구사항을 충족하기 위해 미러링된 아키텍처 패턴에서는 다음 옵션을 제공하며 관련 설명은 다음 섹션에서 제공합니다.
환경당 공유 VPC
환경별 공유 VPC 설계 옵션을 사용하면 특정 조직 보안 요구사항을 충족하는 데 필요한 CI/CD 및 관리 도구를 비롯하여 환경 전반에서 애플리케이션 또는 서비스 수준을 분리할 수 있습니다. 이러한 요구사항은 여러 팀에서 관리해야 하는 다양한 서비스의 통신, 관리 도메인, 액세스 제어를 제한합니다.
이 설계는 서로 다른 환경 간에 네트워크 및 프로젝트 수준 격리를 제공하여 분리를 실현하므로 더 세분화된 커뮤니케이션과 Identity and Access Management(IAM) 액세스 제어가 가능합니다.
관리 및 운영 관점에서 이 설계는 환경 및 서비스 프로젝트별로 여러 팀에서 만든 애플리케이션과 워크로드를 유연하게 관리할 수 있도록 지원합니다. 다음과 같은 가능한 구조를 기반으로 네트워킹 운영팀에서 VPC 네트워킹 및 보안 기능을 프로비저닝하고 관리할 수 있습니다.
- 한 팀이 모든 환경에서 모든 호스트 프로젝트를 관리합니다.
- 각 팀은 각 환경에서 호스트 프로젝트를 관리합니다.
호스트 프로젝트 관리는 각 팀의 팀 구조, 보안 운영, 액세스 요구사항을 기준으로 결정해야 합니다. 이 설계 변형은 각 환경 시작 영역 설계 옵션의 공유 VPC 네트워크에 적용할 수 있습니다. 그러나 하이브리드 네트워크를 통한 통신을 비롯하여 여러 환경 간에 허용되는 통신을 정의하려면 미러링 패턴의 통신 요구사항을 고려해야 합니다.
다음 다이어그램과 같이 각 기본 환경에 공유 VPC 네트워크를 프로비저닝할 수도 있습니다.
중앙 집중식 애플리케이션 계층 방화벽
일부 시나리오에서는 보안 요구사항에 따라 애플리케이션 계층(레이어 7) 및 Cloud Next Generation Firewall의 기능을 능가하는 고급 방화벽 메커니즘을 사용한 심층 패킷 검사를 고려해야 할 수 있습니다. 조직의 보안 요구사항 및 표준을 충족하려면 네트워크 가상 어플라이언스(NVA)에 호스팅된 NGFW 어플라이언스를 사용하면 됩니다. 여러 Google Cloud 보안 파트너가 이 작업에 적합한 옵션을 제공합니다.
다음 다이어그램에 표시된 것처럼 여러 네트워크 인터페이스를 사용하여 가상 프라이빗 클라우드와 비공개 컴퓨팅 환경 간의 네트워크 경로에 NVA를 배치할 수 있습니다.
이 설계는 다음 다이어그램과 같이 여러 공유 VPC에서도 사용할 수도 있습니다.
이 설계의 NVA는 경계 보안 계층 역할을 합니다. 또한 인라인 트래픽 검사를 사용 설정하고 엄격한 액세스 제어 정책을 적용하기 위한 기반이 됩니다.
VPC 방화벽 규칙 및 침입 방지 서비스 기능을 포함하는 강력한 다층 보안 전략을 위해 East-West 및 North-South 트래픽 흐름 모두에 추가 트래픽 검사 및 보안 제어를 포함하세요.
허브 및 스포크 토폴로지
또 다른 설계 변형은 개발 및 다양한 테스트 단계에 별도의 VPC(공유 VPC 포함)를 사용하는 것입니다. 이 변형에서는 다음 다이어그램과 같이 모든 단계 환경이 허브 및 스포크 아키텍처의 CI/CD 및 관리 VPC에 연결됩니다. 각 환경에서 관리 도메인과 기능을 분리해야 하는 경우 이 옵션을 사용하세요. 허브 및 스포크 통신 모델은 다음 요구사항을 충족하는 데 도움이 됩니다.
- 애플리케이션이 모니터링, 구성 관리 도구, CI/CD, 인증과 같은 공통 서비스 집합에 액세스해야 합니다.
- 허브를 통해 중앙 집중식으로 인바운드 및 아웃바운드 트래픽에 공통 보안 정책 집합을 적용해야 합니다.
허브 및 스포크 설계 옵션에 관한 자세한 내용은 중앙 집중식 어플라이언스를 사용하는 허브 및 스포크 토폴로지 및 중앙 집중식 어플라이언스를 사용하지 않는 허브 및 스포크 토폴로지를 참조하세요.
위의 다이어그램과 같이 VPC 간 통신 및 하이브리드 연결은 모두 허브 VPC를 통과합니다. 이 패턴의 일부로 연결 요구사항에 맞게 허브 VPC에서 통신을 제어하고 제한할 수 있습니다.
허브 및 스포크 네트워크 아키텍처에 포함되는 Google Cloud의 (스포크 및 허브 VPC 간) 기본 연결 옵션은 다음과 같습니다.
- VPC 네트워크 피어링
- VPN
- 네트워크 가상 어플라이언스(NVA) 사용
- 다중 네트워크 인터페이스 사용
- Network Connectivity Center(NCC) 사용
설계 시 고려해야 할 옵션에 관한 자세한 내용은 허브 및 스포크 네트워크 아키텍처를 참조하세요. 스포크와 허브 VPC 간에 VPC 피어링을 통해 VPN을 선택하는 데 영향을 미치는 주요 요소는 트래픽 전달 가능성이 필요한 경우입니다. 트래픽 전이성은 스포크의 트래픽이 허브를 통해 다른 스포크에 도달할 수 있음을 의미합니다.
마이크로서비스 제로 트러스트 분산 아키텍처
하이브리드 및 멀티 클라우드 아키텍처에서는 프로덕션 환경을 개발 및 테스트 환경과 분리하는 등 기술 및 비즈니스 목표를 달성하기 위해 여러 클러스터가 필요할 수 있습니다. 따라서 네트워크 경계 보안 제어는 특히 특정 보안 요구사항을 준수해야 하는 경우에 중요합니다.
현재 클라우드 중심 분산 마이크로서비스 아키텍처의 보안 요구사항을 지원하는 것만으로는 충분하지 않으며 제로 트러스트 분산 아키텍처도 고려해야 합니다. 마이크로서비스 제로 트러스트 분산 아키텍처는 마이크로서비스 수준의 보안 정책 시행, 인증, 워크로드 아이덴티티로 마이크로서비스 아키텍처를 지원합니다. 트러스트는 ID 기반이며 각 서비스에 적용됩니다.
서비스 메시와 같은 분산 프록시 아키텍처를 사용하면 서비스가 호출자를 효과적으로 검증하고 각 요청에 대해 세분화된 액세스 제어 정책을 구현하여 더 안전하고 확장 가능한 마이크로서비스 환경을 지원할 수 있습니다. Cloud Service Mesh를 사용하면 Google Cloud 배포와 온프레미스 배포를 확장할 수 있는 공통 메시를 유연하게 사용할 수 있습니다. 메시는 승인 정책을 사용하여 서비스 간 통신을 보호합니다.
Kubernetes 클러스터 내의 경량형 Apigee API 게이트웨이 배포인 Envoy용 Apigee 어댑터를 이 아키텍처에 통합할 수도 있습니다. Envoy용 Apigee 어댑터는 클라우드 중심 애플리케이션용으로 설계된 오픈소스 에지 및 서비스 프록시입니다.
이 주제에 관한 자세한 내용은 다음 도움말을 참조하세요.
- 제로 트러스트 분산 아키텍처
- GKE Enterprise 하이브리드 환경
- Google에 연결
- 온프레미스 GKE Enterprise 클러스터를 Google Cloud 네트워크에 연결합니다.
- 멀티 클라우드 또는 하이브리드 메시 설정
- 환경과 클러스터 전반에 Cloud Service Mesh를 배포합니다.
미러링 패턴 권장사항
- 프로덕션 배포를 배포하거나 다시 구성하는 데 필요한 CI/CD 시스템은 가용성이 높아야 합니다. 즉, 모든 아키텍처 구성요소는 예상되는 수준의 시스템 가용성을 제공하도록 설계되어야 합니다. 자세한 내용은 Google Cloud 인프라 안정성을 참조하세요.
- 코드 업데이트와 같은 반복 프로세스의 구성 오류를 없애기 위해 빌드, 테스트, 배포를 표준화하려면 자동화가 필수입니다.
- 이 설계에서 중앙 집중식 NVA를 통합하려면 보안 액세스 제어 수준이 다른 여러 세그먼트를 통합해야 할 수 있습니다.
- NVA가 포함된 솔루션을 설계할 때는 모든 통신을 차단할 수 있는 단일 장애 지점을 방지하기 위해 NVA의 고가용성(HA)을 고려해야 합니다. NVA 공급업체에서 제공하는 HA 및 중복 설계와 구현 안내를 따르세요.
- VPC 피어링 또는 VPN을 통해 온프레미스 IP 경로를 개발 및 테스트 VPC로 내보내지 않으면 개발 및 테스트 환경에서 온프레미스 환경으로의 네트워크 도달성을 제한할 수 있습니다. 자세한 내용은 VPC 네트워크 피어링 커스텀 경로 교환을 참조하세요.
- Google API 액세스가 필요할 수 있는 비공개 IP 주소 지정이 사용되는 워크로드의 경우 VPC 네트워크 내에서 Private Service Connect 엔드포인트를 사용하여 Google API를 노출할 수 있습니다. 자세한 내용은 이 시리즈의 게이트 인그레스를 참조하세요.
- 하이브리드 및 멀티 클라우드 네트워킹 아키텍처 패턴에 대한 일반적인 권장사항을 참조하세요.
메시 패턴
메시 패턴은 하이브리드 네트워크 아키텍처 설정을 기반으로 합니다. 이 아키텍처는 여러 컴퓨팅 환경에 걸쳐 있습니다. 이러한 환경에서는 모든 시스템이 서로 통신할 수 있고 애플리케이션의 보안 요구사항을 기반으로 하는 단방향 통신으로 제한되지 않습니다. 이 네트워킹 패턴은 계층형 하이브리드, 파티션을 나눈 멀티 클라우드, 버스팅 아키텍처에 주로 적용됩니다. 또한 Google Cloud에서 재해 복구(DR) 환경을 프로비저닝하는 비즈니스 연속성 설계에 적용될 수 있습니다. 모든 경우에 다음 통신 요구사항에 맞는 방법으로 컴퓨팅 환경을 연결해야 합니다.
- 워크로드는 비공개 RFC 1918 IP 주소를 사용하여 환경 경계에서 서로 통신할 수 있습니다.
- 통신은 어느 쪽에서나 시작할 수 있습니다. 통신 모델의 사양은 이어지는 설계 옵션에서 논의하는 통신 모델과 같은 애플리케이션 및 보안 요구사항에 따라 달라질 수 있습니다.
- 사용하는 방화벽 규칙은 해당 패턴이 설계된 애플리케이션의 요구사항에 따라 특정 IP 주소 소스와 대상 사이의 트래픽을 허용해야 합니다. 이상적으로는 컴퓨팅 환경 사이에 그리고 환경 내에서 멀티 레이어 보안 접근 방법을 사용하여 미세 조정된 방식으로 트래픽 흐름을 제한할 수 있습니다.
아키텍처
다음 다이어그램은 메시 패턴의 상위 수준의 참조 아키텍처를 보여줍니다.
- 모든 환경은 겹치지 않는 RFC 1918 IP 주소 공간을 사용해야 합니다.
- Google Cloud 측에서는 단일 또는 다중 공유 VPC 또는 비공유 VPC에 워크로드를 배포할 수 있습니다. 이 패턴의 다른 가능한 설계 옵션은 이어지는 설계 변형을 참조하세요. VPC의 선택한 구조는 조직의 프로젝트 및 리소스 계층 구조 설계와 일치해야 합니다.
- Google Cloud의 VPC 네트워크는 다른 컴퓨팅 환경으로 확장됩니다. 이러한 환경은 온프레미스이거나 다른 클라우드에 있을 수 있습니다. 비즈니스 및 애플리케이션 요구사항을 충족하는 하이브리드 및 멀티 클라우드 네트워킹 연결 중 하나를 사용합니다.
소스 및 대상의 허용되는 IP 주소로만 통신을 제한합니다. 다음 기능을 사용하거나 조합합니다.
네트워크 경로에 배치된 차세대 방화벽(NGFW) 검사 기능을 사용하는 네트워크 가상 어플라이언스(NVA)
침입 방지 서비스(IPS)를 사용해서 네트워크 설계 또는 라우팅을 변경하지 않고 위협 방지를 위해 심층 패킷 검사를 구현하는 Cloud Next Generation Firewall Enterprise
변형
메시 아키텍처 패턴은 다른 설계 요구사항을 충족하기 위해 다른 접근 방법과 함께 조합할 수 있으며, 패턴의 통신 요구사항을 고려할 수 있습니다. 패턴 옵션에 대해서는 다음 섹션에서 설명합니다.
환경당 하나의 VPC
환경당 하나의 VPC 옵션을 고려할만한 일반적인 이유는 다음과 같습니다.
- 클라우드 환경에서는 조직의 리소스 계층 구조 설계에 맞게 VPC 네트워크와 리소스를 네트워크 수준에서 분리해야 합니다.
관리 도메인 분리가 필요하면 환경당 개별 프로젝트와 조합할 수도 있습니다.
- 공통 네트워크에서 네트워크 리소스를 중앙에서 관리하고 여러 환경 간에 네트워크 격리를 제공하기 위해서는 개발, 테스트, 프로덕션과 같이 Google Cloud에 있는 각 환경에 대한 공유 VPC를 사용합니다.
- 단일 VPC 또는 프로젝트의 VPC 할당량을 초과할 필요가 있을 수 있는 확장 요구사항
다음 다이어그램에 표시된 것처럼 환경당 하나의 VPC 설계에서는 각 VPC가 VPN 또는 여러 VLAN 연결이 포함된 Cloud Interconnect를 사용해서 온프레미스 환경 또는 다른 클라우드 환경과 직접 통합할 수 있습니다.
이전 다이어그램에 표시된 패턴은 랜딩 영역 허브 및 스포크 네트워크 토폴로지에 적용될 수 있습니다. 이 토폴로지에서는 단일(또는 다중) 하이브리드 연결을 모든 스포크 VPC와 공유할 수 있습니다. 하이브리드 연결과 기타 스포크 VPC를 모두 종료하기 위해 전송 VPC를 사용하여 공유됩니다. 또한 다음 섹션 "중앙화된 애플리케이션 레이어 방화벽 사용"에 설명된 대로 전송 VPC에서 차세대 방화벽을 지원하는 NVA(NGFW) 조사 기능을 추가하여 이 설계를 확장할 수 있습니다.
중앙 집중식 애플리케이션 레이어 방화벽 사용
기술 요구사항에 따라 애플리케이션 레이어(레이어 7) 및 클라우드 차세대 방화벽의 기능을 초과하는 고급 방화벽 기능과 함께 심층 패킷 검사를 고려해야 할 경우에는 NVA에서 호스팅되는 NGFW 어플라이언스를 사용할 수 있습니다. 하지만 이러한 NVA는 조직의 보안 요구를 충족해야 합니다. 이러한 메커니즘을 구현하기 위해서는 다음 다이어그램에 표시된 것처럼 중앙 집중식 NVA 방화벽을 통해 모든 교차 환경 트래픽을 전달하도록 토폴로지를 확장할 수 있습니다.
중앙 집중식 어플라이언스가 포함된 허브 및 스포크 토폴로지를 사용하여 랜딩 영역 설계에서 다음 다이어그램의 패턴을 적용할 수 있습니다.
이전 다이어그램에 표시된 것처럼 NVA는 경계 보안 레이어로 작동하며 인라인 트래픽 조사를 사용 설정하기 위한 기초로 사용됩니다. 또한 엄격한 액세스 제어 정책을 적용합니다. 동서 및 북남 트래픽 흐름을 모두 조사하기 위해서는 중앙 집중식 NVA 설계에 여러 수준의 보안 액세스 제어가 지원되는 다중 세그먼트가 포함될 수 있습니다.
마이크로서비스 제로 트러스트 분산 아키텍처
컨테이너화된 애플리케이션이 사용된 경우에는 미러링 패턴 섹션에서 논의된 마이크로서비스 제로 트러스트 분산 아키텍처를 이 아키텍처 패턴에도 적용할 수 있습니다.
이 패턴과 미러링 패턴 사이의 주요 차이점은 Google Cloud의 워크로드와 다른 환경 사이의 통신 모델을 어느 쪽에서든 시작할 수 있다는 것입니다. 서비스 메시를 사용해서 애플리케이션 요구사항과 보안 요구사항을 기반으로 트래픽을 제어하고 미세 조정해야 합니다.
메시 패턴 권장사항
- 다른 작업을 수행하기 전 리소스 계층 구조 설계와 프로젝트 및 VPC를 지원하는 데 필요한 설계를 결정합니다. 이렇게 하면 Google Cloud 프로젝트의 구조와 일치하는 최적의 네트워킹 아키텍처를 선택하는 데 도움이 됩니다.
- 비공개 컴퓨팅 환경 및 Google Cloud 내에서 Kubernetes를 사용할 때 제로 트러스트 분산 아키텍처를 사용합니다.
- 설계에서 중앙 집중식 NVA를 사용할 때는 다른 수준의 보안 액세스 제어와 트래픽 조사 정책을 사용해서 여러 세그먼트를 정의해야 합니다. 애플리케이션의 보안 요구사항을 기준으로 이러한 제어 및 정책을 정의합니다.
- NVA가 포함된 솔루션을 설계할 때는 모든 통신을 차단할 수 있는 단일 장애 지점을 방지하기 위해 NVA의 고가용성(HA)을 고려해야 합니다. NVA를 제공하는 Google Cloud 보안 공급업체에서 제공되는 HA 및 중복성 설계와 구현 안내를 따르세요.
- 향상된 개인 정보 보호, 데이터 무결성, 제어 통신 모델을 제공하려면 Apigee 및 엔드 투 엔드 mTLS가 포함된 Apigee Hybrid와 같은 API 게이트웨이를 사용해서 API를 통해 애플리케이션을 노출합니다. 또한 동일한 조직 리소스에서 공유 Apigee 지원 VPC를 사용할 수 있습니다.
- 솔루션 설계를 위해 공개 인터넷에 대한 Google Cloud 기반 애플리케이션 노출이 필요하면 인터넷 연결 애플리케이션 배포를 위한 네트워킹에서 논의하는 설계 권장사항을 고려하세요.
- 프로젝트에서 Google Cloud 서비스를 보호하고 데이터 무단 반출 위험을 줄이기 위해서는 VPC 서비스 제어를 사용하여 프로젝트 및 VPC 네트워크 수준에서 서비스 경계를 지정합니다. 또한 승인된 VPN 또는 Cloud Interconnect를 통해 하이브리드 환경으로 서비스 경계를 확장할 수 있습니다. 서비스 경계의 이점에 대한 자세한 내용은 VPC 서비스 제어 개요를 참조하세요.
- 하이브리드 및 멀티 클라우드 네트워킹 패턴에 대한 일반적인 권장사항을 참조하세요.
Google Cloud에서 호스팅되는 애플리케이션과 다른 환경의 애플리케이션 간에 더 엄격한 격리와 보다 미세 조정된 액세스를 적용하기 위해서는 이 시리즈의 다른 문서에서 논의하는 게이트 패턴 중 하나를 사용합니다.
게이트 패턴
게이트 적용 패턴은 다양한 환경 간에 노출된 특정 API 또는 엔드포인트를 기반으로 선택한 애플리케이션과 서비스를 세분화된 방식으로 노출하는 아키텍처를 기반으로 합니다. 이 가이드에서는 이 패턴을 세 가지 옵션으로 분류하며, 각 옵션은 특정 커뮤니케이션 모델에 따라 결정됩니다.
- 게이트 이그레스
게이트 이그레스 및 인그레스(양방향 게이트 처리)
이 가이드에서 앞서 언급한 바와 같이 여기에 설명된 네트워킹 아키텍처 패턴은 다양한 요구사항이 있는 다양한 애플리케이션에 맞게 조정할 수 있습니다. 다양한 애플리케이션의 구체적인 요구사항을 충족하기 위해 기본 방문 영역 아키텍처는 하나의 패턴 또는 패턴 조합을 동시에 통합할 수 있습니다. 선택한 아키텍처의 구체적인 배포는 각 게이트 패턴의 구체적인 통신 요구사항에 따라 결정됩니다.
이 시리즈에서는 각 게이트 패턴과 가능한 디자인 옵션을 설명합니다. 하지만 모든 게이트 패턴에 적용할 수 있는 일반적인 디자인 옵션 중 하나는 마이크로서비스 아키텍처를 사용하는 컨테이너화된 애플리케이션을 위한 제로 트러스트 분산 아키텍처입니다. 이 옵션은 Cloud Service Mesh, Apigee, Kubernetes 클러스터 내의 경량 Apigee 게이트웨이 배포인 Envoy용 Apigee 어댑터를 기반으로 합니다. Envoy용 Apigee 어댑터는 클라우드 우선 애플리케이션용으로 설계된 널리 사용되는 오픈소스 에지 및 서비스 프록시입니다. 이 아키텍처는 허용된 보안 서비스 간 통신과 서비스 수준에서 통신의 방향을 제어합니다. 선택한 패턴에 따라 서비스 수준에서 트래픽 통신 정책을 설계, 미세 조정, 적용할 수 있습니다.
게이트 패턴을 사용하면 침입 방지 서비스 (IPS)가 있는 Cloud Next Generation Firewall Enterprise를 구현하여 설계나 라우팅을 수정하지 않고도 위협 방지를 위한 심층 패킷 검사를 실행할 수 있습니다. 이러한 검사는 액세스하는 특정 애플리케이션, 통신 모델, 보안 요구사항에 따라 달라집니다. 보안 요구사항에 따라 Cloud Next Generation Firewall의 기능을 초과하는 고급 방화벽 메커니즘을 사용한 레이어 7 및 심층 패킷 검사가 필요한 경우 네트워크 가상 어플라이언스 (NVA)에 호스팅된 중앙 집중식 차세대 방화벽 (NGFW)을 사용할 수 있습니다. 여러 Google Cloud 보안 파트너는 보안 요구사항을 충족할 수 있는 NGFW 어플라이언스를 제공합니다. 이러한 게이트 패턴과 NVA를 통합하려면 네트워크 설계 내에 각각 고유한 액세스 제어 수준이 있는 여러 보안 영역을 도입해야 할 수 있습니다.
게이트 송신
게이트 적용 이그레스 네트워킹 패턴의 아키텍처는 온프레미스 환경 또는 다른 클라우드 환경의 일부 API를 Google Cloud에 배포된 워크로드에 노출하는 것을 기반으로 합니다. 온프레미스 환경이나 기타 클라우드 환경에서 공개 인터넷에 직접 노출하지 않고도 이를 실행할 수 있습니다. API 게이트웨이, 프록시 또는 기존 워크로드의 퍼사드 역할을 하는 부하 분산기를 통해 이러한 제한된 노출을 촉진할 수 있습니다. API 게이트웨이 기능을 경계 네트워크와 같은 원격 경계 네트워크 세그먼트에 배포할 수 있습니다.
게이트 이그레스 네트워킹 패턴은 주로 계층형 애플리케이션 아키텍처 패턴 및 파티션을 나눈 애플리케이션 아키텍처 패턴에 적용되지만 이에 국한되지는 않습니다. 내부 네트워크 내에 백엔드 워크로드를 배포할 때 게이트 처리된 이그레스 네트워킹을 사용하면 온프레미스 컴퓨팅 환경 내에서 더 높은 수준의 보안을 유지할 수 있습니다. 이 패턴을 사용하려면 다음 통신 요구 사항을 충족하는 방식으로 컴퓨팅 환경을 연결해야 합니다.
- Google Cloud에 배포하는 워크로드는 내부 IP 주소를 사용하여 애플리케이션을 노출하는 API 게이트웨이 또는 부하 분산기(또는 Private Service Connect 엔드포인트)와 통신할 수 있습니다.
- 비공개 컴퓨팅 환경의 다른 시스템은 Google Cloud 내에서 직접 연결할 수 없습니다.
- 비공개 컴퓨팅 환경에서 Google Cloud에 배포된 워크로드로의 통신은 허용되지 않습니다.
- 다른 환경의 비공개 API에 대한 트래픽은 Google Cloud 환경 내에서만 시작할 수 있습니다
이 가이드에서는 비공개 하이브리드 네트워크를 통해 연결된 하이브리드 및 멀티 클라우드 환경에 중점을 둡니다. 조직의 보안 요구사항이 허용하는 경우 공개 IP 주소가 있는 원격 대상 API에 대한 API 호출을 인터넷을 통해 직접 연결할 수 있습니다. 하지만 다음 보안 메커니즘을 고려해야 합니다.
- 전송 계층 보안(TLS)을 사용하는 API OAuth 2.0
- 비율 제한
- 위협 보호 정책
- API 레이어의 백엔드에 구성된 상호 TLS
- 양쪽에서 사전 정의된 API 소스 및 대상과의 통신만 허용되도록 구성된 IP 주소 허용 목록 필터링
API 프록시를 보호하려면 다음과 같은 기타 보안 측면을 고려하세요. 자세한 내용은 Apigee를 사용한 애플리케이션 및 API 보호 권장사항을 참고하세요.
아키텍처
다음 다이어그램은 이전 섹션에 나열된 커뮤니케이션 요구사항을 지원하는 참조 아키텍처를 보여줍니다.
데이터는 다음과 같이 위의 다이어그램을 통해 이동합니다.
- Google Cloud 측에서 워크로드를 가상 프라이빗 클라우드(VPC)에 배포할 수 있습니다. VPC는 단일 또는 다중(공유 또는 비공유)일 수 있습니다. 배포는 조직의 프로젝트 및 리소스 계층 구조 설계와 일치해야 합니다.
- Google Cloud 환경의 VPC 네트워크는 다른 컴퓨팅 환경으로 확장됩니다. 이러한 환경은 온프레미스이거나 다른 클라우드에 있을 수 있습니다. 내부 IP 주소를 사용하여 환경 간의 통신을 용이하게 하려면 적절한 하이브리드 및 멀티클라우드 네트워킹 연결을 사용하세요.
특정 VPC IP 주소에서 시작되어 원격 게이트웨이 또는 부하 분산기로 향하는 트래픽을 제한하려면 IP 주소 허용 목록 필터링을 사용하세요. 스테이트풀(Stateful) 방화벽 규칙을 사용하면 이러한 연결의 반환 트래픽이 허용됩니다. 다음 기능을 조합하여 통신을 보호하고 허용된 소스 및 대상 IP 주소로만 제한할 수 있습니다.
네트워크 경로에 배치된 차세대 방화벽(NGFW) 검사 기능을 사용하는 네트워크 가상 어플라이언스(NVA)
침입 방지 서비스(IPS)를 통해 위협 방지를 위한 심층 패킷 검사를 구현하는 Cloud Next Generation Firewall Enterprise
모든 환경은 겹치지 않는 RFC 1918 IP 주소 공간을 공유합니다.
변형
게이트 이그레스 아키텍처 패턴은 이 패턴의 통신 요구 사항을 여전히 고려하는 다양한 설계 요구 사항을 충족하기 위해 다른 접근 방식과 결합될 수 있습니다. 패턴은 다음 옵션을 제공합니다.
Google Cloud API 게이트웨이 및 글로벌 프런트엔드 사용
이러한 설계 접근 방식에서 API 노출과 관리는 Google Cloud 내에서 수행됩니다. 위의 다이어그램에서 볼 수 있듯이 API 플랫폼으로 Apigee를 구현하여 이를 달성할 수 있습니다. 원격 환경에 API 게이트웨이 또는 부하 분산기를 배포할지 여부는 특정 요구 사항과 현재 구성에 따라 달라집니다. Apigee는 연결을 프로비저닝하는 두 가지 옵션을 제공합니다.
- VPC 피어링 사용
- VPC 피어링 미사용
Google Cloud 전역 프런트엔드 기능인 Cloud Load Balancing, Cloud CDN(Cloud Interconnect를 통해 액세스 시) 및 Cross-Cloud Interconnect는 온프레미스 환경과 다른 클라우드 환경에 호스팅된 백엔드를 가진 애플리케이션에 대한 사용자의 액세스 속도를 향상시킵니다.
콘텐츠 전송 속도는 Google Cloud 접속 지점(PoP)에서 이러한 애플리케이션을 제공하여 최적활할 수 있습니다. 전 세계적으로 160개가 넘는 상호 연결 시설과 180개 이상의 인터넷 교환 시설에 Google Cloud PoP가 있습니다.
PoP가 Apigee와 Cloud CDN을 사용하여 고성능 API를 제공하는 데 어떻게 도움이 되는지 알아보려면, YouTube에서 Apigee 및 Cloud CDN을 사용하여 고성능 API 제공을 시청하세요.
- 지연 시간 감소
- 전 세계적으로 API를 호스팅합니다.
- 트래픽이 가장 많은 시기에 가용성을 높입니다.
위의 다이어그램에 표시된 설계 예시는 VPC 피어링이 없는 Private Service Connect를 기반으로 합니다.
이 설계의 Northbound 네트워크는 다음을 통해 설정됩니다.
- 클라이언트 요청이 종료되고 트래픽을 처리한 후 Private Service Connect 백엔드로 라우팅하는 부하 분산기(다이어그램의 LB)
- Private Service Connect 백엔드를 사용하면 Google Cloud 부하 분산기가 프로듀서 서비스 연결과 연결된 Private Service Connect 연결을 통해 Private Service Connect network endpoint groups(NEGs)를 사용하여 게시된 서비스(Apigee 런타임 인스턴스)에 고객 요청을 전송할 수 있습니다.
Southbound 네트워킹은 다음을 통해 설정됩니다.
- 고객 VPC의 내부 부하 분산기(다이어그램의 ILB)와 연결된 서비스 연결을 참조하는 Private Service Connect 엔드포인트
하이브리드 연결 네트워크 엔드포인트 그룹(하이브리드 연결 NEG)으로 ILB가 배포됩니다.
하이브리드 서비스는 VPN 또는 Cloud Interconnect와 같은 하이브리드 네트워크 연결을 통한 하이브리드 연결 NEG를 통해 액세스됩니다.
자세한 내용은 하이브리드 연결로 리전별 내부 프록시 네트워크 부하 분산기 설정 및Private Service Connect 배포 패턴을 참조하세요.
Private Service Connect를 사용하여 원격 서비스 노출
다음 시나리오에서 원격 서비스를 노출하려면 Private Service Connect 옵션을 사용하세요.
- API 플랫폼을 사용하고 있지 않거나 다음과 같은 이유로 VPC 네트워크를 외부 환경에 직접 연결하지 않으려는 경우:
- 보안 제한사항 또는 규정 준수 요구사항이 있습니다.
- 합병 및 인수 시나리오와 같이 IP 주소 범위가 겹치는 경우
- 기한이 짧더라도 환경에서 클라이언트, 애플리케이션, 서비스 간의 안전한 단방향 통신을 사용 설정하려는 경우
- 확장성이 뛰어난 멀티 테넌트 또는 단일 테넌트 서비스 모델을 제공하려면 다른 환경에 게시된 서비스에 연결하기 위해 서비스 제작자 VPC(전송 VPC)를 통해 여러 소비자 VPC에 대한 연결을 제공해야 할 수 있습니다.
API로 소비되는 애플리케이션에 Private Service Connect를 사용하면 게시된 애플리케이션의 내부 IP 주소가 제공되므로 지역 전반에서 비공개 네트워크 내부와 하이브리드 연결을 통해 안전하게 액세스할 수 있습니다. 이 추상화는 하이브리드 및 멀티 클라우드 연결 모델을 통해 다양한 클라우드 및 온프레미스 환경의 리소스를 통합하는 것을 용이하게 합니다. Private Service Connect를 사용하여 세분화된 액세스 제어로 서비스를 게시함으로써 온프레미스 환경 또는 다른 클라우드 환경에 있는 애플리케이션을 안전하게 노출하고 통합을 가속화할 수 있습니다. 이 경우 다음 옵션을 사용할 수 있습니다.
- 리전별 내부 프록시 네트워크 부하 분산기 또는 내부 애플리케이션 부하 분산기를 참조하는 서비스 연결입니다.
- 부하 분산기는 이 설계에서 전송 VPC로 작동하는 프로듀서 VPC에 하이브리드 네트워크 엔드포인트 그룹(하이브리드 연결 NEG)을 사용합니다.
앞의 다이어그램에서 애플리케이션의 VPC 네트워크에 있는 워크로드는 Private Service Connect 엔드포인트를 통해 온프레미스 환경 또는 다른 클라우드 환경에서 실행되는 하이브리드 서비스에 연결할 수 있습니다. 이는 다이어그램에 설명되어 있습니다. 단방향 통신을 위한 설계 옵션은 전송 VPC에 대한 피어링을 대신할 옵션을 제공합니다.
앞의 다이어그램에서 설계의 일부로 여러 개의 프런트엔드, 백엔드 또는 엔드포인트가 동일한 서비스 연결에 연결할 수 있으므로 여러 VPC 네트워크 또는 여러 소비자가 동일한 서비스에 액세스할 수 있습니다. 다음 다이어그램과 같이 애플리케이션이 여러 VPC에 액세스할 수 있도록 할 수 있습니다. 이러한 액세스 가능성은 IP 주소 범위가 겹치는 경우에도 여러 소비자 VPC에서 서비스가 소비되는 멀티 테넌트 서비스 시나리오에 유용할 수 있습니다.
IP 주소 중복은 다양한 환경에 있는 애플리케이션을 통합할 때 발생하는 가장 일반적인 문제 중 하나입니다. 다음 다이어그램의 Private Service Connect 연결은 IP 주소 중복 문제를 방지하는 데 도움이 됩니다. IP 주소 변환을 수행하기 위해 Cloud NAT 또는 NVA와 같은 추가 네트워킹 구성요소를 프로비저닝하거나 관리할 필요 없이 이를 수행합니다. 구성 예시는 Private Service Connect를 사용하여 하이브리드 서비스 게시를 참고하세요.
이 디자인에는 다음과 같은 이점이 있습니다.
- 잠재적인 공유 확장 종속성과 대규모 관리의 복잡성을 피할 수 있습니다.
- 세분화된 연결 제어를 제공하여 보안을 개선합니다.
- 서비스의 프로듀서와 소비자 및 원격 외부 환경 간의 IP 주소 조정을 줄입니다.
위의 다이어그램에 나온 설계 접근 방식은 Private Service Connect 옵션을 비롯하여 앞에서 설명한 네트워킹 설계 옵션을 사용하여 Apigee를 API 플랫폼으로 통합하도록 이후 단계에서 확장할 수 있습니다.
Private Service Connect 전역 액세스를 사용하여 다른 리전에서 Private Service Connect 엔드포인트에 액세스할 수 있습니다.
Private Service Connect 엔드포인트에 연결하는 클라이언트는 엔드포인트와 동일한 리전 또는 다른 리전에 있을 수 있습니다. 이 접근 방식은 여러 리전에서 호스팅되는 서비스 간에 고가용성을 제공하거나 다른 리전에서 단일 리전에서 제공되는 서비스에 액세스하는 데 사용할 수 있습니다. 다른 리전에서 호스팅되는 리소스에서 Private Service Connect 엔드포인트에 액세스하는 경우 전역 액세스 권한이 있는 엔드포인트를 대상으로 하는 트래픽에 리전 간 아웃바운드 요금이 적용됩니다.
권장사항
- Apigee 및 Apigee Hybrid를 API 플랫폼 솔루션으로 사용하면 여러 가지 이점이 있습니다. 보안 기능, 비율 제한, 할당량, 분석과 결합된 백엔드 서비스 API에 프록시 레이어와 추상화 또는 퍼사드를 제공합니다.
- 요구사항 및 아키텍처에 적용 가능한 경우 Kubernetes 아키텍처가 포함된 Apigee Hybrid 배포와 함께 Envoy용 Apigee 어댑터를 사용하세요.
- Google Cloud에서 VPC와 프로젝트 설계는 리소스 계층 구조와 보안 통신 모델 요구사항에 따라 결정되어야 합니다.
- API 게이트웨이가 있는 API를 사용하는 경우 IP 주소 허용 목록도 사용해야 합니다. 허용 목록은 다양한 환경에서 호스팅될 수 있는 API 소비자 및 API 게이트웨이의 특정 IP 주소 소스 및 대상으로 통신을 제한합니다.
- VPC 방화벽 규칙 또는 방화벽 정책을 사용하여 Private Service Connect 엔드포인트를 통해 Private Service Connect 리소스에 대한 액세스를 제어합니다.
- 애플리케이션 부하 분산기를 통해 애플리케이션이 외부에 노출되는 경우 DDoS 및 애플리케이션 계층 보안 위협으로부터 보호하기 위해 Google Cloud Armor를 추가 보안 레이어로 사용하는 것이 좋습니다.
인스턴스에 인터넷 액세스가 필요한 경우 애플리케이션(소비자) VPC에서 Cloud NAT를 사용하여 워크로드가 인터넷에 액세스하도록 허용합니다. 이렇게 하면 API 게이트웨이 또는 부하 분산기 뒤에 배포된 시스템에서 외부 공용 IP 주소로 VM 인스턴스를 할당하지 않아도 됩니다.
하이브리드 및 멀티 클라우드 네트워킹 패턴에 대한 일반적인 권장사항을 참조하세요.
게이트 수신
게이트 인그레스 패턴의 아키텍처는 Google Cloud에서 실행되는 워크로드의 선별된 API를 공개 인터넷에 노출하지 않고 비공개 컴퓨팅 환경에 노출하는 것을 기반으로 합니다. 이 패턴은 게이트 이그레스 패턴에 대응되며 에지 하이브리드, 단계식 하이브리드 및 분할 멀티 클라우드 시나리오에 매우 적합합니다.
게이트 이그레스 패턴과 마찬가지로 기존 워크로드 또는 서비스의 퍼사드 역할을 하는 API 게이트웨이 또는 부하 분산기를 통해 이러한 제한된 노출을 촉진할 수 있습니다. 이렇게 하면 다음과 같이 비공개 컴퓨팅 환경, 온프레미스 환경 또는 기타 클라우드 환경에서 액세스할 수 있습니다.
- 비공개 컴퓨팅 환경 또는 기타 서비스 환경에 배포하는 워크로드는 내부 IP 주소를 사용하여 API 게이트웨이 또는 부하 분산기와 통신할 수 있습니다. Google Cloud에 배포된 다른 시스템에는 연결할 수 없습니다.
- Google Cloud에서 비공개 컴퓨팅 환경 또는 다른 클라우드 환경으로의 통신은 허용되지 않습니다. 트래픽은 비공개 환경 또는 기타 클라우드 환경에서 Google Cloud의 API로만 시작됩니다.
아키텍처
다음 다이어그램은 게이트 인그레스 패턴의 요구사항을 충족하는 참조 아키텍처를 보여줍니다.
앞의 다이어그램에서 아키텍처에 대한 설명은 다음과 같습니다.
- Google Cloud 측면에서 워크로드를 애플리케이션 VPC(또는 여러 VPC)에 배포합니다.
- Google Cloud 환경 네트워크는 하이브리드 또는 멀티 클라우드 네트워크 연결을 사용하여 환경 간 통신을 용이하게 하여 다른 컴퓨팅 환경(온프레미스 또는 다른 클라우드)으로 확장됩니다.
- 원하는 경우 전송 VPC를 사용하여 다음을 수행할 수 있습니다.
- 애플리케이션 VPC 외부의 특정 API에 액세스할 수 있도록 추가적인 경계 보안 레이어를 제공합니다.
- 트래픽을 API의 IP 주소로 라우팅합니다. 일부 소스가 엔드포인트를 통해 특정 API에 액세스하지 못하도록 VPC 방화벽 규칙을 만들 수 있습니다.
- 네트워크 가상 어플라이언스(NVA)를 통합하여 전송 VPC에서 레이어 7 트래픽을 검사합니다.
- API 게이트웨이 또는 부하 분산기(프록시 또는 애플리케이션 부하 분산기)를 통해 API에 액세스하여 서비스 API에 대한 프록시 레이어와 추상화 레이어 또는 퍼사드를 제공합니다. 여러 API 게이트웨이 인스턴스에 트래픽을 분산해야 하는 경우 내부 패스 스루 네트워크 부하 분산기를 사용할 수 있습니다.
- Private Service Connect를 통해 부하 분산기를 사용하여 애플리케이션 또는 서비스를 노출함으로써 Private Service Connect 엔드포인트를 통해 게시된 서비스에 대한 제한적이고 세분화된 액세스를 제공합니다.
- 모든 환경은 겹치지 않는 RFC 1918 IP 주소 공간을 사용해야 합니다.
다음 다이어그램은 Apigee를 API 플랫폼으로 사용하는 이 패턴의 설계를 보여줍니다.
앞의 다이어그램에서 Apigee를 API 플랫폼으로 사용하면 게이트 인그레스 패턴을 사용 설정하기 위한 다음과 같은 특성 및 기능이 제공됩니다.
- 게이트웨이 또는 프록시 기능
- 보안 기능
- 비율 제한
- 분석
설계 시:
- Northbound 네트워킹 연결(다른 환경에서 들어오는 트래픽용)은 Apigee VPC와 연결된 애플리케이션 VPC의 Private Service Connect 엔드포인트를 통과합니다.
- 애플리케이션 VPC에서 내부 부하 분산기는 Apigee VPC에 제공되는 Private Service Connect 엔드포인트를 통해 애플리케이션 API를 노출하는 데 사용됩니다. 자세한 내용은 VPC 피어링이 사용 중지된 아키텍처를 참조하세요.
애플리케이션 VPC에서 방화벽 규칙과 트래픽 필터링을 구성합니다. 이렇게 하면 세밀하고 제어된 액세스가 제공됩니다. 또한 Private Service Connect 엔드포인트 및 API 게이트웨이를 통과하지 않고 시스템이 애플리케이션에 직접 도달하는 것을 방지하는 데 도움이 됩니다.
애플리케이션 VPC에 있는 백엔드 워크로드의 내부 IP 주소 서브넷 공지를 온프레미스 네트워크로 제한하여 Private Service Connect 엔드포인트 및 API 게이트웨이를 통과하지 않고 직접 연결할 수 없도록 할 수도 있습니다.
특정 보안 요구사항에는 하이브리드 연결 트래픽을 포함하여 애플리케이션 VPC 외부의 경계 보안 검사가 필요할 수 있습니다. 이러한 경우 전송 VPC를 통합하여 추가 보안 레이어를 구현할 수 있습니다. 여러 네트워크 인터페이스가 있는 차세대 방화벽(NGFW) NVA 또는 침입 방지 서비스(IPS)가 있는 Cloud Next Generation Firewall Enterprise와 같은 이러한 레이어는 다음 다이어그램에 설명된 것처럼 애플리케이션 VPC 외부에서 심층 패킷 검사를 수행합니다.
앞의 다이어그램에서 표시된 것처럼 다음과 같습니다.
- Northbound 네트워킹 연결(다른 환경에서 들어오는 트래픽)은 별도의 전송 VPC를 통해 Apigee VPC와 연결된 전송 VPC의 Private Service Connect 엔드포인트로 전달됩니다.
- 애플리케이션 VPC에서 내부 부하 분산기(다이어그램의 ILB)는 Apigee VPC의 Private Service Connect 엔드포인트를 통해 애플리케이션을 노출하는 데 사용됩니다.
다음 다이어그램과 같이 동일한 VPC 네트워크에서 여러 엔드포인트를 프로비저닝할 수 있습니다. 다양한 사용 사례를 다루기 위해 Cloud Router 및 VPC 방화벽 규칙을 사용하여 가능한 다양한 네트워크 경로를 제어할 수 있습니다. 예를 들어 여러 하이브리드 네트워킹 연결을 사용하여 온프레미스 네트워크를 GCP에 연결하는 경우 하나의 연결을 통해 온프레미스에서 특정 Google API 또는 게시된 서비스로 일부 트래픽을 보내고 다른 연결을 통해 나머지 트래픽을 보낼 수 있습니다. 또한 Private Service Connect 전역 액세스를 통해 장애 조치 옵션을 제공할 수 있습니다.
변형
게이트 인그레스 아키텍처 패턴을 다른 접근 방식과 결합하여 다양한 설계 요구사항을 충족하면서도 패턴의 통신 요구사항을 고려할 수 있습니다. 패턴은 다음 옵션을 제공합니다.
다른 환경에서 Google API에 액세스
공개 인터넷을 통해 트래픽을 전송하지 않고 Cloud Storage 또는 BigQuery와 같은 Google 서비스에 액세스해야 하는 시나리오를 위해 Private Service Connect가 솔루션을 제공합니다. 다음 다이어그램에 표시된 것처럼 Private Service Connect의 IP 주소를 사용하는 하이브리드 네트워크 연결을 통해 온프레미스 또는 기타 클라우드 환경에서 지원되는 Google API 및 서비스(Google 지도, Google Ads, Google Cloud 포함)에 연결할 수 있습니다. Private Service Connect 엔드포인트를 통해 Google API에 액세스하는 방법에 대한 자세한 내용은 엔드포인트를 통한 Google API 액세스를 참조하세요.
앞의 다이어그램에서 온프레미스 네트워크는 Cloud VPN 터널 또는 Cloud Interconnect VLAN 연결을 사용하여 전송(소비자) VPC 네트워크에 연결되어야 합니다.
Google API는 엔드포인트 또는 백엔드를 사용하여 액세스할 수 있습니다. 엔드포인트를 사용하면 Google API 번들을 타겟팅할 수 있습니다. 백엔드를 사용하면 특정 리전별 Google API를 타겟팅할 수 있습니다.
Private Service Connect를 사용하여 애플리케이션 백엔드를 다른 환경에 노출
단계식 하이브리드 패턴에서 강조한 특정 시나리오에서는 비공개 컴퓨팅 환경에서 프런트엔드를 유지하면서 Google Cloud에 백엔드를 배포해야 할 수도 있습니다. 이 방식은 일반적이지 않지만 기존 구성요소에 의존할 수 있는 중량형 모놀리식 프런트엔드를 다룰 때 적용할 수 있습니다. 또는 하이브리드 네트워크를 통해 Google Cloud에 호스팅된 백엔드에 연결해야 하는 온프레미스 및 기타 클라우드를 비롯한 여러 환경에서 분산 애플리케이션을 관리하는 경우가 더 일반적입니다.
이러한 아키텍처에서는 비공개 온프레미스 환경이나 기타 클라우드 환경의 로컬 API 게이트웨이나 부하 분산기를 사용하여 애플리케이션 프런트엔드를 공개 인터넷에 직접 노출할 수 있습니다. Google Cloud에서 Private Service Connect를 사용하면 다음 다이어그램과 같이 이상적으로는 사전 정의된 API를 사용하여 Private Service Connect 엔드포인트를 통해 노출되는 백엔드에 대한 비공개 연결이 용이해집니다.
이전 다이어그램의 설계에서는 Google Cloud의 관리 영역과 다른 환경에서 호스팅되는 런타임 영역으로 구성된 Apigee Hybrid 배포를 사용합니다. 온프레미스 환경이나 다른 클라우드 환경에서 지원되는 Kubernetes 플랫폼 중 하나의 분산 API 게이트웨이에 런타임 영역을 설치하고 관리할 수 있습니다. Google Cloud 및 기타 환경의 분산 워크로드에 대한 요구사항에 따라 Google Cloud 기반 Apigee를 Apigee Hybrid와 함께 사용할 수 있습니다. 자세한 내용은 분산 API 게이트웨이를 참조하세요.
허브 및 스포크 아키텍처를 사용하여 애플리케이션 백엔드를 다른 환경에 노출
일부 시나리오에서는 여러 VPC 네트워크에 걸쳐 Google Cloud에서 호스팅되는 애플리케이션 백엔드에서 API를 노출해야 할 수 있습니다. 다음 다이어그램과 같이 허브 VPC는 다양한 VPC(스포크)의 상호 연결 중심 역할을 하므로 비공개 하이브리드 연결을 통한 보안 통신이 가능합니다. 필요에 따라 Apigee Hybrid와 같은 다른 환경의 로컬 API 게이트웨이 기능을 사용하여 애플리케이션 프런트엔드가 호스팅되는 곳에서 클라이언트 요청을 로컬로 종료할 수 있습니다.
앞의 다이어그램에서 표시된 것처럼 다음과 같습니다.
- 추가적인 NGFW 레이어 7 검사 기능을 제공하기 위해 NGFW 기능을 갖춘 NVA는 선택적으로 설계에 통합됩니다. 특정 보안 요구사항 및 조직의 보안 정책 표준을 준수하기 위해 이러한 기능이 필요할 수 있습니다.
이 설계에서는 스포크 VPC에 VPC 간 직접 통신이 필요하지 않다고 가정합니다.
- 스포크 대 스포크 통신이 필요한 경우 NVA를 사용하여 이러한 커뮤니케이션을 용이하게 할 수 있습니다.
- 다양한 VPC에 서로 다른 백엔드가 있는 경우 Private Service Connect를 사용하여 이러한 백엔드를 Apigee VPC에 노출할 수 있습니다.
- 스포크 VPC와 허브 VPC 간의 Northbound 및 Southbound 연결에 VPC 피어링이 사용되는 경우 VPC 피어링을 통한 VPC 네트워킹의 전환 제한사항을 고려해야 합니다. 이러한 제한사항을 극복하기 위해 다음 옵션 중 하나를 사용할 수 있습니다.
다른 환경의 트래픽을 포함하여 트래픽 검사에 NVA가 필요한 경우 온프레미스 또는 다른 클라우드 환경에 대한 하이브리드 연결은 하이브리드 전송 VPC에서 종료되어야 합니다.
설계에 NVA가 포함되지 않은 경우 허브 VPC에서 하이브리드 연결을 종료할 수 있습니다.
Google Cloud Armor DDoS 보호 또는 WAF 추가와 같은 특정 부하 분산 기능 또는 보안 기능이 필요한 경우 외부 클라이언트 요청을 백엔드로 라우팅하기 전에 선택적으로 외부 VPC를 통해 경계에 외부 애플리케이션 부하 분산기를 배포할 수 있습니다.
권장사항
- 인터넷의 클라이언트 요청을 비공개 온프레미스 또는 기타 클라우드 환경에서 호스팅되는 프런트엔드에서 로컬로 수신해야 하는 경우 Apigee Hybrid를 API 게이트웨이 솔루션으로 사용하는 것이 좋습니다. 또한 이 접근 방식을 사용하면 API 플랫폼(Apigee)의 일관성을 유지하면서 솔루션을 완전히 Google Cloud 호스팅 환경으로 원활하게 마이그레이션할 수 있습니다.
- 요구사항 및 아키텍처에 적용 가능한 경우 Kubernetes 아키텍처가 포함된 Apigee Hybrid 배포와 함께 Envoy용 Apigee 어댑터를 사용하세요.
- Google Cloud의 VPC 및 프로젝트 설계는 이 가이드에 설명된 대로 리소스 계층 구조 및 보안 통신 모델 요구사항을 따라야 합니다.
- 전송 VPC를 이 설계에 통합하면 워크로드 VPC 외부의 추가적인 경계 보안 조치와 하이브리드 연결을 프로비저닝할 수 있는 유연성이 제공됩니다.
- Private Service Connect를 사용하여 하이브리드 연결 네트워크를 통해 엔드포인트의 내부 IP 주소로 온프레미스 환경 또는 기타 클라우드 환경에서 Google API 및 서비스에 액세스합니다. 자세한 내용은 온프레미스 호스트에서 엔드포인트 액세스를 참조하세요.
- 프로젝트에서 Google Cloud 서비스를 보호하고 데이터 무단 반출 위험을 줄이기 위해서는 VPC 서비스 제어를 사용하여 프로젝트 또는 VPC 네트워크 수준에서 서비스 경계를 지정합니다.
- 필요한 경우 VPN 또는 Cloud Interconnect를 통해 서비스 경계를 하이브리드 환경으로 확장할 수 있습니다. 서비스 경계의 이점에 대한 자세한 내용은 VPC 서비스 제어 개요를 참조하세요.
- VPC 방화벽 규칙 또는 방화벽 정책을 사용하여 Private Service Connect 엔드포인트를 통해 Private Service Connect 리소스에 대한 네트워크 수준의 액세스를 제어합니다. 예를 들어 애플리케이션(소비자) VPC의 아웃바운드 방화벽 규칙은 VM 인스턴스에서 엔드포인트의 IP 주소 또는 서브넷에 대한 액세스를 제한할 수 있습니다. 일반적인 VPC 방화벽 규칙에 대한 자세한 내용은 VPC 방화벽 규칙을 참조하세요.
- NVA가 포함된 솔루션을 설계할 때는 모든 통신을 차단할 수 있는 단일 장애 지점을 방지하기 위해 NVA의 고가용성(HA)을 고려해야 합니다. NVA 공급업체에서 제공하는 HA 및 중복 설계와 구현 안내를 따르세요.
- 경계 보안을 강화하고 해당 환경에 배포된 API 게이트웨이를 보호하기 위해 선택적으로 다른 컴퓨팅 환경(하이브리드 또는 기타 클라우드)에서 부하 분산 및 웹 애플리케이션 방화벽 메커니즘을 구현할 수 있습니다. 인터넷에 직접 연결된 경계 네트워크에서 이러한 옵션을 구현합니다.
- 인스턴스에 인터넷 액세스가 필요한 경우 애플리케이션 VPC에서 Cloud NAT를 사용하여 워크로드가 인터넷에 액세스할 수 있도록 허용합니다. 이렇게 하면 API 게이트웨이 또는 부하 분산기 뒤에 배포된 시스템에서 외부 공용 IP 주소로 VM 인스턴스를 할당하지 않아도 됩니다.
- 아웃바운드 웹 트래픽의 경우 보안 웹 프록시를 사용합니다. 프록시는 몇 가지 이점이 있습니다.
- 하이브리드 및 멀티 클라우드 네트워킹 패턴에 대한 일반적인 권장사항을 참조하세요.
게이트 이그레스 및 게이트 인그레스
게이트 이그레스 및 게이트 인그레스 패턴은 워크로드 간에 선택한 API를 양방향으로 사용해야 하는 시나리오에 게이트 이그레스와 게이트 인그레스를 조합하여 사용합니다. 워크로드는 Google Cloud, 비공개 온프레미스 환경 또는 기타 클라우드 환경에서 실행할 수 있습니다. 이 패턴에서는 API 게이트웨이, Private Service Connect 엔드포인트 또는 부하 분산기를 사용하여 특정 API를 노출하고 원하는 경우 인증, 승인, API 호출 감사를 제공할 수 있습니다.
이 패턴과 메시 네트워크 패턴의 주요 차이점은 양방향 API 사용 또는 특정 IP 주소 소스 및 대상과의 통신만 필요한 시나리오(예: Private Service Connect 엔드포인트를 통해 게시된 애플리케이션)에 적용된다는 점입니다. 통신은 노출된 API 또는 특정 IP 주소로 제한되므로 여러 환경의 네트워크가 설계에서 일치할 필요가 없습니다. 일반적으로 적용되는 시나리오에는 다음이 포함되나 이에 국한되지 않습니다.
- 합병 및 인수
- 파트너와의 애플리케이션 통합
- 자체 애플리케이션을 관리하고 여러 환경에 호스팅하는 여러 조직 단위와 조직의 애플리케이션 및 서비스 간의 통합
통신은 다음과 같이 작동합니다.
- Google Cloud에 배포하는 워크로드는 내부 IP 주소를 사용하여 API 게이트웨이 (또는 특정 대상 IP 주소)와 통신할 수 있습니다. 비공개 컴퓨팅 환경에 배포된 다른 시스템에는 연결할 수 없습니다.
- 반대로 다른 컴퓨팅 환경에 배포하는 워크로드는 내부 IP 주소를 사용하여 Google Cloud 측 API 게이트웨이 (또는 특정 게시된 엔드포인트 IP 주소)와 통신할 수 있습니다. Google Cloud에 배포된 다른 시스템에는 연결할 수 없습니다.
아키텍처
다음 다이어그램은 게이트 이그레스 및 게이트 인그레스 패턴의 참조 아키텍처를 보여줍니다.
위 다이어그램의 설계 접근 방식에는 다음과 같은 요소가 있습니다.
- Google Cloud 측에서는 워크로드를 인터넷에 직접 노출하지 않고 VPC (또는 공유 VPC)에 배포합니다.
- Google Cloud 환경 네트워크는 다른 컴퓨팅 환경으로 확장됩니다. 이러한 환경은 온프레미스이거나 다른 클라우드에 있을 수 있습니다. 환경을 확장하려면 적절한 하이브리드 및 멀티클라우드 연결 커뮤니케이션 패턴을 사용하여 환경 간에 통신을 용이하게 하여 내부 IP 주소를 사용할 수 있도록 합니다.
- 원하는 경우 특정 대상 IP 주소에 대한 액세스를 사용 설정하여 전송 VPC를 사용하여 애플리케이션 VPC 외부에 경계 보안 레이어를 추가할 수 있습니다.
- 전송 VPC에서 차세대 방화벽(NGFW)과 함께 Cloud 차세대 방화벽 또는 네트워크 가상 어플라이언스 (NVA)를 사용하여 트래픽을 검사하고 애플리케이션 VPC에 도달하기 전에 특정 소스에서 특정 API에 대한 액세스를 허용하거나 금지할 수 있습니다.
- API 게이트웨이 또는 부하 분산기를 통해 API에 액세스하여 프록시 레이어와 서비스 API의 추상화 또는 퍼사드를 제공해야 합니다.
- API로 소비되는 애플리케이션의 경우 Private Service Connect를 사용하여 게시된 애플리케이션의 내부 IP 주소를 제공할 수도 있습니다.
- 모든 환경은 겹치지 않는 RFC 1918 IP 주소 공간을 사용합니다.
이 패턴의 일반적인 적용은 애플리케이션 백엔드(또는 애플리케이션 백엔드의 하위 집합)를 Google Cloud에 배포하는 동시에 다른 백엔드 및 프런트엔드 구성요소를 온프레미스 환경 또는 다른 클라우드에 호스팅하는 것입니다(계층형 하이브리드 패턴 또는 파티션된 멀티클라우드 패턴). 애플리케이션이 발전하고 클라우드로 이전함에 따라 특정 클라우드 서비스에 대한 종속 항목과 환경설정이 자주 발생합니다.
이러한 종속 항목과 환경설정으로 인해 애플리케이션과 백엔드가 여러 클라우드 제공업체에 배포되는 경우가 있습니다. 또한 일부 애플리케이션은 온프레미스 환경과 여러 클라우드 환경에 배포된 리소스와 서비스의 조합으로 빌드될 수 있습니다.
분산 애플리케이션의 경우 외부 Cloud Load Balancing 하이브리드 및 멀티클라우드 연결의 기능을 사용하여 사용자 요청을 종료하고 다른 환경의 프런트엔드 또는 백엔드로 라우팅할 수 있습니다. 이 라우팅은 다음 다이어그램과 같이 하이브리드 네트워크 연결을 통해 이루어집니다. 이 통합을 통해 애플리케이션 구성요소를 여러 환경에 점진적으로 배포할 수 있습니다. Google Cloud에서 호스팅되는 프런트엔드에서 백엔드 서비스로의 요청은 내부 부하 분산기 (다이어그램의 ILB)에서 제공하는 기존 하이브리드 네트워크 연결을 통해 안전하게 통신합니다.
위 다이어그램의 Google Cloud 설계를 사용하면 다음과 같은 이점이 있습니다.
- 이 패턴의 통신 모델에 맞는 사전 정의된 API를 양쪽에서 사용하여 Google Cloud, 온프레미스, 기타 클라우드 환경 간의 양방향 통신을 용이하게 합니다.
- 분산된 애플리케이션 구성요소 (프런트엔드 또는 백엔드)로 인터넷 연결 애플리케이션용 글로벌 프런트엔드를 제공하고 다음 목표를 달성하려면 포인트 오브 프레시전 (PoP)에 배포된 Google Cloud의 고급 부하 분산 및 보안 기능을 사용하면 됩니다.
- 서버리스 관리형 서비스를 사용하여 자본 비용을 줄이고 운영을 간소화하세요.
- 속도와 지연 시간을 위해 전 세계 애플리케이션 백엔드에 대한 연결을 최적화합니다.
- Google Cloud Cross-Cloud Network를 사용하면 최적의 비공개 연결을 통해 애플리케이션 구성요소 간에 멀티클라우드 통신을 지원할 수 있습니다.
- Cloud CDN에 대한 액세스를 제공하여 수요가 많은 정적 콘텐츠를 캐시하고 전역 Cloud Load Balancing을 사용하는 애플리케이션의 애플리케이션 성능을 개선합니다.
- 전 세계에 분산된 웹 애플리케이션 방화벽 (WAF) 및 DDoS 완화 서비스를 제공하는 Google Cloud Armor 기능을 사용하여 인터넷 연결 애플리케이션의 전 세계 프런트엔드를 보호합니다.
- 원하는 경우 Private Service Connect를 설계로 통합할 수 있습니다. 이렇게 하면 공개 인터넷을 통과하지 않고도 다른 환경에서 Google Cloud 서비스 API 또는 게시된 서비스에 비공개로 세분화된 방식으로 액세스할 수 있습니다.
변형
게이트 이그레스 및 게이트 인그레스 아키텍처 패턴은 이 패턴의 통신 요구사항을 고려하면서 다양한 설계 요구사항을 충족하기 위해 다른 접근 방식과 결합될 수 있습니다. 패턴은 다음 옵션을 제공합니다.
- 분산 API 게이트웨이
- Private Service Connect를 사용한 양방향 API 통신
- Private Service Connect 엔드포인트 및 인터페이스를 사용한 양방향 통신
분산 API 게이트웨이
파티션된 멀티클라우드 패턴에 기반한 시나리오와 같이 애플리케이션 (또는 애플리케이션 구성요소)은 비공개 온프레미스 환경을 비롯한 여러 클라우드 환경에서 빌드할 수 있습니다. 일반적인 요구사항은 클라이언트 요청을 애플리케이션 프런트엔드로 라우팅하여 애플리케이션 (또는 프런트엔드 구성요소)이 호스팅되는 환경으로 직접 전달하는 것입니다. 이러한 종류의 통신에는 로컬 부하 분산기 또는 API 게이트웨이가 필요합니다. 이러한 애플리케이션과 구성요소에는 통합을 위한 특정 API 플랫폼 기능이 필요할 수도 있습니다.
다음 다이어그램은 Apigee 및 Apigee Hybrid가 각 환경에서 현지화된 API 게이트웨이를 사용하여 이러한 요구사항을 해결하도록 설계된 방식을 보여줍니다. API 플랫폼 관리는 Google Cloud에 중앙 집중화되어 있습니다. 이 설계는 사전 승인된 IP 주소 (타겟 및 대상 API 또는 Private Service Connect 엔드포인트 IP 주소)만 Google Cloud와 다른 환경 간에 통신할 수 있는 엄격한 액세스 제어 조치를 시행하는 데 도움이 됩니다.
다음 목록에서는 위 다이어그램에서 Apigee API 게이트웨이를 사용하는 두 가지 고유한 통신 경로를 설명합니다.
- 클라이언트 요청은 애플리케이션 (또는 프런트엔드 구성요소)을 호스팅하는 환경에서 애플리케이션 프런트엔드로 직접 도착합니다.
- 각 환경 내의 API 게이트웨이와 프록시는 여러 환경에서 다양한 방향으로 클라이언트 및 애플리케이션 API 요청을 처리합니다.
- Google Cloud의 API 게이트웨이 기능(Apigee)은 Google Cloud에 호스팅된 애플리케이션 (프런트엔드 또는 백엔드) 구성요소를 노출합니다.
- 다른 환경(하이브리드)의 API 게이트웨이 기능은 해당 환경에서 호스팅되는 애플리케이션 프런트엔드 (또는 백엔드) 구성요소를 노출합니다.
원하는 경우 전송 VPC를 사용하는 것이 좋습니다. 전송 VPC를 사용하면 문제를 분리하고 별도의 VPC 네트워크에서 보안 검사 및 하이브리드 연결을 실행할 수 있는 유연성을 제공할 수 있습니다. IP 주소 도달 가능성 관점에서 하이브리드 연결이 연결된 전송 VPC는 엔드 투 엔드 도달 가능성을 유지하기 위한 다음 요구사항을 용이하게 합니다.
- 대상 API의 IP 주소는 클라이언트/요청자가 호스팅되는 다른 환경에 광고되어야 합니다.
- 타겟 API와 통신해야 하는 호스트의 IP 주소는 타겟 API가 있는 환경(예: API 요청자(클라이언트)의 IP 주소)에 광고되어야 합니다. 부하 분산기, 프록시, Private Service Connect 엔드포인트 또는 NAT 인스턴스를 통해 통신이 발생하는 경우에는 예외입니다.
원격 환경에 대한 연결을 확장하기 위해 이 설계는 고객 경로 교환 기능이 있는 직접 VPC 피어링을 사용합니다. 이 설계를 사용하면 Google Cloud 애플리케이션 VPC 내에 호스팅된 워크로드에서 발생하는 특정 API 요청을 전송 VPC를 통해 라우팅할 수 있습니다. 또는 전송 VPC의 하이브리드 네트워크 엔드포인트 그룹 백엔드가 있는 부하 분산기와 연결된 애플리케이션 VPC의 Private Service Connect 엔드포인트를 사용할 수 있습니다. 이 설정은 다음 섹션인 Private Service Connect를 사용한 양방향 API 통신에 설명되어 있습니다.
Private Service Connect를 사용한 양방향 API 통신
기업이 API 게이트웨이 (예: Apigee)를 즉시 사용하지 않아도 되거나 나중에 추가하고 싶을 수 있습니다. 그러나 여러 환경에서 특정 애플리케이션 간의 통신 및 통합을 사용 설정해야 하는 비즈니스 요구사항이 있을 수 있습니다. 예를 들어 회사가 다른 회사를 인수한 경우 특정 애플리케이션을 해당 회사에 노출해야 할 수 있습니다. 관리자가 회사에 애플리케이션을 노출해야 할 수 있습니다. 두 회사 모두 서로 다른 환경 (Google Cloud, 온프레미스 또는 기타 클라우드)에 호스팅된 자체 워크로드를 보유하고 있을 수 있으며 IP 주소 중복을 방지해야 합니다. 이러한 경우 Private Service Connect를 사용하여 효과적인 커뮤니케이션을 지원할 수 있습니다.
API로 소비되는 애플리케이션의 경우 Private Service Connect를 사용하여 게시된 애플리케이션의 비공개 주소를 제공하여 리전 전반에서 하이브리드 연결을 통해 비공개 네트워크 내에서 안전하게 액세스할 수 있습니다. 이 추상화는 하이브리드 및 멀티 클라우드 연결 모델을 통해 다양한 클라우드 및 온프레미스 환경의 리소스를 통합하는 것을 용이하게 합니다. 또한 멀티 클라우드 및 온프레미스 환경에서 애플리케이션을 조합할 수 있습니다. 이를 통해 API 게이트웨이가 사용되지 않거나 사용 계획이 없는 보안 애플리케이션을 통합하는 등 다양한 통신 요구사항을 충족할 수 있습니다.
다음 다이어그램과 같이 Cloud Load Balancing과 함께 Private Service Connect를 사용하면 두 가지 고유한 통신 경로를 사용할 수 있습니다. 각 경로는 별도의 연결 목적으로 다른 방향에서 시작되며, 가능하면 API 호출을 통해 시작됩니다.
- 이 가이드에서 설명하는 Private Service Connect의 모든 설계 고려사항 및 권장사항이 이 설계에 적용됩니다.
- 추가 레이어 7 검사가 필요한 경우 전송 VPC에서 이 설계와 NVA를 통합할 수 있습니다.
- 이 디자인은 API 게이트웨이 유무와 관계없이 사용할 수 있습니다.
위의 다이어그램에 표시된 두 가지 연결 경로는 독립적인 연결을 나타내며 단일 연결 또는 흐름의 양방향 통신을 보여주지 않습니다.
Private Service Connect 엔드포인트 및 인터페이스를 사용한 양방향 통신
게이트 처리된 인그레스 패턴에서 설명한 대로 클라이언트-서비스 통신을 사용 설정하는 옵션 중 하나는 Private Service Connect 엔드포인트를 사용하여 프로듀서 VPC의 서비스를 소비자 VPC에 노출하는 것입니다. 이 연결은 하이브리드 연결을 통해 온프레미스 환경 또는 다른 클라우드 제공업체 환경으로 확장할 수 있습니다. 그러나 경우에 따라 호스팅된 서비스에 비공개 통신이 필요할 수도 있습니다.
소비자 VPC 내부 또는 외부에서 호스팅될 수 있는 데이터 소스에서 데이터를 검색하는 것과 같은 특정 서비스에 액세스하기 위해 이 비공개 통신은 애플리케이션 (프로듀서) VPC와 온프레미스 환경과 같은 원격 환경 간에 이루어질 수 있습니다.
이러한 시나리오에서 Private Service Connect 인터페이스를 사용하면 서비스 프로듀서 VM 인스턴스가 소비자의 네트워크에 액세스할 수 있습니다. 이는 생산자와 소비자 역할을 구분하면서 네트워크 인터페이스를 공유하여 이루어집니다. 소비자 VPC에 이 네트워크 인터페이스가 있으면 애플리케이션 VM은 프로듀서 VPC에 로컬로 있는 것처럼 소비자 리소스에 액세스할 수 있습니다.
Private Service Connect 인터페이스는 소비자 (전송) VPC에 연결된 네트워크 인터페이스입니다. Private Service Connect 인터페이스가 연결된 소비자 (전송) VPC에서 연결할 수 있는 외부 대상에 도달할 수 있습니다. 따라서 이 연결은 다음 다이어그램과 같이 온프레미스 환경과 같은 하이브리드 연결을 통해 외부 환경으로 확장될 수 있습니다.
소비자 VPC가 서드 파티 조직과 같은 외부 조직 또는 법인인 경우 일반적으로 소비자 VPC에서 Private Service Connect 인터페이스에 대한 통신을 보호할 수 없습니다. 이러한 시나리오에서는 Private Service Connect 인터페이스 VM의 게스트 OS에서 보안 정책을 정의할 수 있습니다. 자세한 내용은 Private Service Connect 인터페이스의 보안 구성을 참고하세요. 또는 조직의 보안 규정 준수 또는 표준을 준수하지 않는 경우 대체 접근 방식을 고려할 수 있습니다.
권장사항
인터넷의 클라이언트 요청을 비공개 온프레미스 또는 기타 클라우드 환경에서 호스팅되는 프런트엔드에서 로컬로 수신해야 하는 경우 Hybrid를 API 게이트웨이 솔루션으로 사용하는 것이 좋습니다.
- 또한 이 접근 방식을 사용하면 API 플랫폼 (Apigee)의 일관성을 유지하면서 솔루션을 완전히 Google Cloud 호스팅 환경으로 마이그레이션할 수 있습니다.
다른 환경이 장기 또는 영구 하이브리드 또는 멀티 클라우드 설정으로 구성된 경우 다른 환경으로의 대량 아웃바운드 데이터 전송에 대한 지연 시간을 최소화하고 비용을 최적화하려면 다음을 고려하세요.
- Cloud Interconnect 또는 Cross-Cloud Interconnect를 사용합니다.
- 적절한 환경에서 타겟팅된 프런트엔드에서 사용자 연결을 종료하려면 하이브리드를 사용하세요.
요구사항 및 아키텍처에 적용 가능한 경우 Kubernetes 아키텍처가 포함된 하이브리드 배포와 함께 Envoy용 Apigee 어댑터를 사용하세요.
연결 및 라우팅 경로를 설계하기 전에 먼저 원본 및 대상 환경과 함께 로컬 또는 원격 API 게이트웨이로 전달해야 하는 트래픽 또는 API 요청을 식별해야 합니다.
VPC 서비스 제어를 사용하여 프로젝트 또는 VPC 네트워크 수준에서 서비스 경계를 지정하여 프로젝트의 Google Cloud 서비스를 보호하고 데이터 무단 반출 위험을 완화하세요.
- 승인된 VPN 또는 Cloud Interconnect를 통해 하이브리드 환경으로 서비스 경계를 확장할 수 있습니다. 서비스 경계의 이점에 대한 자세한 내용은 VPC 서비스 제어 개요를 참조하세요.
Virtual Private Cloud (VPC) 방화벽 규칙 또는 방화벽 정책을 사용하여 Private Service Connect 엔드포인트를 통해 Private Service Connect 리소스에 대한 네트워크 수준의 액세스를 제어합니다. 예를 들어 애플리케이션(소비자) VPC의 아웃바운드 방화벽 규칙은 VM 인스턴스에서 엔드포인트의 IP 주소 또는 서브넷에 대한 액세스를 제한할 수 있습니다.
Private Service Connect 인터페이스를 사용할 때는 Private Service Connect 인터페이스의 보안을 구성하여 인터페이스와의 통신을 보호해야 합니다.
비공개 서브넷의 워크로드에 인터넷 액세스가 필요한 경우 Cloud NAT를 사용하여 워크로드에 외부 IP 주소를 할당하고 공개 인터넷에 노출하지 마세요.
하이브리드 및 멀티 클라우드 네트워킹 패턴에 대한 일반적인 권장사항을 참조하세요.
핸드오버 패턴
핸드오버 패턴을 사용하는 아키텍처에서는 Google Cloud가 제공하는 스토리지 서비스를 사용하여 비공개 컴퓨팅 환경을 Google Cloud의 프로젝트에 연결합니다. 이 패턴은 주로 다음과 같은 분석 하이브리드 멀티 클라우드 아키텍처 패턴을 따르는 설정에 적용됩니다.
- 비공개 컴퓨팅 환경 또는 다른 클라우드에서 실행 중인 워크로드가 공유 스토리지 위치에 데이터를 업로드합니다. 사용 사례에 따라 일괄적으로 또는 점차적으로 업로드될 수 있습니다.
- Google Cloud에 호스팅되는 워크로드 또는 기타 Google 서비스(예: 데이터 분석 및 인공지능 서비스)는 공유 스토리지 위치의 데이터를 소비하고 스트리밍 또는 일괄 처리 방식으로 이를 처리합니다.
아키텍처
다음 다이어그램은 핸드오버 패턴의 참조 아키텍처를 보여줍니다.
위의 아키텍처 다이어그램은 다음 워크플로를 보여줍니다.
- Google Cloud 측에서 워크로드를 애플리케이션 VPC에 배포합니다. 이러한 워크로드에는 데이터 처리, 분석, 분석 관련 프런트엔드 애플리케이션이 포함될 수 있습니다.
- 프런트엔드 애플리케이션을 사용자에게 안전하게 노출하려면 Cloud Load Balancing 또는 API Gateway를 사용하면 됩니다.
- Cloud Storage 버킷 또는 Pub/Sub 큐 집합은 비공개 컴퓨팅 환경에서 데이터를 업로드하고 Google Cloud에 배포된 워크로드에서 추가 처리할 수 있도록 이러한 데이터를 제공합니다. Identity and Access Management(IAM) 정책을 사용하여 신뢰할 수 있는 워크로드에 대한 액세스를 제한할 수 있습니다.
- VPC 서비스 제어를 사용하여 서비스에 대한 액세스를 제한하고 Google Cloud 서비스에서 발생하는 불필요한 데이터 무단 반출 위험을 최소화합니다.
- 이 아키텍처에서 Cloud Storage 버킷 또는 Pub/Sub과의 통신은 공개 네트워크를 통해 이루어지거나 VPN, Cloud Interconnect 또는 Cross-Cloud Interconnect를 사용하는 비공개 연결을 통해 이루어집니다. 일반적으로 연결 방법은 다음과 같은 여러 측면에 따라 결정됩니다.
- 예상 트래픽 양
- 임시 설정인지 영구 설정인지 여부
- 보안 및 규정 준수 요구사항
변형
Google API에 Private Service Connect 엔드포인트를 사용하는 게이트 인그레스 패턴에 설명된 설계 옵션도 이 패턴에 적용할 수 있습니다. 특히 Cloud Storage, BigQuery, 기타 Google 서비스 API에 대한 액세스를 제공합니다. 이 접근 방식을 사용하려면 VPN, Cloud Interconnect, Cross-Cloud Interconnect와 같은 하이브리드 및 멀티 클라우드 네트워크 연결을 통한 비공개 IP 주소 지정이 필요합니다.
권장사항
- Cloud Storage 버킷 및 Pub/Sub 주제에 대한 액세스를 잠급니다.
- 해당하는 경우 Google Cloud 솔루션 모음과 같은 클라우드 중심 통합 데이터 이동 솔루션을 사용하세요. 이러한 솔루션은 사용 사례 요구사항을 충족하기 위해 데이터를 효율적으로 이동, 통합, 변환하도록 설계되었습니다.
비용, 예상 전송 시간, 보안 등 데이터 전송 옵션에 영향을 미치는 다양한 요인을 평가합니다. 자세한 내용은 전송 옵션 평가를 참조하세요.
지연 시간을 최소화하고 공개 인터넷을 통한 대용량 데이터 전송 및 이동을 방지하려면 Google API용 가상 프라이빗 클라우드 내의 Private Service Connect 엔드포인트에 액세스하는 것을 비롯하여 Cloud Interconnect 또는 Cross-Cloud Interconnect를 사용하는 것이 좋습니다.
프로젝트에서 Google Cloud 서비스를 보호하고 데이터 무단 반출 위험을 완화하려면 VPC 서비스 제어를 사용하세요. 이러한 서비스 제어는 프로젝트 또는 VPC 네트워크 수준에서 서비스 경계를 지정할 수 있습니다.
- 승인된 VPN 또는 Cloud Interconnect를 통해 하이브리드 환경으로 서비스 경계를 확장할 수 있습니다. 서비스 경계의 이점에 대한 자세한 내용은 VPC 서비스 제어 개요를 참조하세요.
API 게이트웨이, 부하 분산기 또는 가상 네트워크 어플라이언스를 통해 VM 인스턴스에 호스팅되는 공개적으로 게시된 데이터 분석 워크로드와 통신합니다. 보안을 강화하고 인터넷에서 직접 이러한 인스턴스에 액세스할 수 없도록 하려면 이러한 통신 방법 중 하나를 사용하세요.
인터넷 액세스가 필요한 경우 동일한 VPC에서 Cloud NAT를 사용하여 인스턴스에서 공개 인터넷으로의 아웃바운드 트래픽을 처리할 수 있습니다.
하이브리드 및 멀티 클라우드 네트워킹 토폴로지에 대한 일반적인 권장사항을 참조하세요.
일반 권장사항
클라우드 ID, 리소스 계층 구조, 시작 영역 네트워크를 설계하고 온보딩할 때는 Google Cloud의 시작 영역 설계의 설계 권장사항과 엔터프라이즈 기반 청사진에서 다룬 Google Cloud 보안 권장사항을 고려합니다. 다음 문서를 바탕으로 선택한 설계를 검증합니다.
- VPC 설계에 관한 권장사항 및 참조 아키텍처
- Google Cloud 시작 영역의 리소스 계층 구조 결정
- Google Cloud 아키텍처 프레임워크: 보안, 개인 정보 보호, 규정 준수
다음 일반 권장사항도 고려합니다.
하이브리드 또는 멀티 클라우드 네트워크 연결 옵션을 선택할 때 SLA, 성능, 보안, 비용, 신뢰성, 대역폭과 같은 비즈니스 및 애플리케이션 요구사항을 고려합니다. 자세한 내용은 네트워크 연결 제품 선택 및 다른 클라우드 서비스 제공업체를 Google Cloud와 연결하는 패턴을 참조하세요.
적절하고 리소스 계층 구조 설계 요구사항에 맞는 경우 여러 VPC 대신 Google Cloud에서 공유 VPC를 사용합니다. 자세한 내용은 여러 VPC 네트워크 생성 여부 결정을 참조하세요.
계정 및 조직 계획의 권장사항을 따릅니다.
해당하는 경우 시스템이 환경 경계에서 안전하게 인증할 수 있도록 환경 간에 공통 ID를 설정합니다.
하이브리드 설정에서 애플리케이션을 안전하게 기업 사용자에게 노출하고 요구사항에 가장 적합한 방식을 선택하려면 권장 방법에 따라 Google Cloud를 ID 관리 시스템에 통합해야 합니다.
- 하이브리드 환경에서 직원 사용자를 인증하는 패턴도 참조하세요.
온프레미스 및 클라우드 환경을 설계할 때 초기에 처리하는 IPv6 및 서비스에서 지원할 계정을 고려합니다. 자세한 내용은 Google Cloud의 IPv6 소개를 참조하세요. 블로그가 작성될 때 지원되었던 서비스를 요약합니다.
VPC 방화벽 규칙을 설계, 배포, 관리할 때 다음을 수행할 수 있습니다.
- 방화벽 규칙이 VM에 적용되는 방식을 엄격하게 제어해야 하는 경우에는 네트워크 태그 기반 필터링보다 서비스 계정 기반 필터링을 우선 사용합니다.
- 한 번에 모두 업데이트할 수 있도록 여러 방화벽 규칙을 그룹화할 때 방화벽 정책을 사용합니다. 정책을 계층 구조를 만들 수도 있습니다. 계층식 방화벽 정책 사양과 세부정보는 계층식 방화벽 정책을 참조하세요.
- 특정 지리적 위치나 리전을 기반으로 외부 IPv4 및 외부 IPv6 트래픽을 필터링해야 하는 경우에는 방화벽 정책에서 위치정보 객체를 사용합니다.
- 알려진 악성 IP 주소와 같은 위협 인텔리전스 데이터나 퍼블릭 클라우드 IP 주소 범위를 기반으로 트래픽을 허용하거나 차단하여 네트워크를 보호해야 하는 경우 방화벽 정책 규칙의 위협 인텔리전스를 사용합니다. 예를 들어 서비스가 퍼블릭 클라우드와만 통신해야 하는 경우에는 특정 퍼블릭 클라우드 IP 주소 범위에서 트래픽을 허용할 수 있습니다. 자세한 내용은 방화벽 규칙 권장사항을 참조하세요.
항상 다음과 같은 추가 보안 레이어를 고려하여 멀티 레이어 보안 방식을 사용하여 클라우드 및 네트워크 보안을 설계해야 합니다.
이러한 추가 계층은 분석 및 방어를 위해 네트워크와 애플리케이션 계층에서 다양한 위협을 필터링, 검사, 모니터링하는 데 도움이 됩니다.
하이브리드 설정에서 DNS 변환을 수행할 위치를 결정할 때는 비공개 Google Cloud 환경과 온프레미스 환경에서 기존 DNS 서버가 호스팅하는 온프레미스 리소스에 권한 있는 DNS 시스템 2개를 사용하는 것이 좋습니다. 자세한 내용은 DNS 변환이 수행되는 위치 선택을 참조하십시오.
가능하면 항상 API 게이트웨이나 부하 분산기를 사용하여 API를 통해 애플리케이션을 노출합니다. Apigee와 같은 API 플랫폼을 사용하는 것이 좋습니다. Apigee는 보안 기능, 비율 제한, 할당량, 분석과 결합된 백엔드 서비스 API에서 추상화 또는 퍼사드 역할을 합니다.
API 플랫폼(게이트웨이 또는 프록시)과 애플리케이션 부하 분산기는 상호 배타적이지 않습니다. 경우에 따라 API 게이트웨이와 부하 분산기를 함께 사용하면 대규모 API 트래픽을 관리하고 배포할 수 있는 더욱 견고하고 안전한 솔루션이 제공될 수 있습니다. Cloud Load Balancing API 게이트웨이를 사용하면 다음을 달성할 수 있습니다.
Apigee와 Clod CDN을 통해 고성능 API를 제공하여 다음을 수행합니다.
- 지연 시간 감소
- API를 전역적으로 호스팅
트래픽 사용량이 가장 많은 시기에 가용성 향상
자세한 내용은 YouTube의 Apigee 및 Cloud CDN을 사용하여 고성능 API 제공을 시청하세요.
고급 트래픽 관리를 구현합니다.
Google Cloud Armor를 DDoS 보호, WAF, 네트워크 보안 서비스로 사용하여 API를 보호합니다.
여러 리전의 게이트웨이에서 효율적인 부하 분산을 관리합니다. 자세한 내용은 PSC 및 Apigee를 사용하여 API 보호 및 멀티 리전 장애 조치 구현을 시청하세요.
사용할 Cloud Load Balancing 제품을 결정하려면 먼저 부하 분산기가 처리해야 하는 트래픽 유형을 결정해야 합니다. 자세한 내용은 부하 분산기 선택을 참조하세요.
Cloud Load Balancing을 사용할 때 해당되는 경우 애플리케이션 용량 최적화 기능을 사용해야 합니다. 이렇게 하면 전역으로 분산된 애플리케이션에서 발생할 수 있는 일부 용량 문제를 해결하는 데 도움이 됩니다.
- 지연 시간에 대한 심층 분석은 부하 분산으로 애플리케이션 지연 최적화를 참조하세요.
Cloud VPN에서 환경 간에 트래픽을 암호화하는 동안에 Cloud Interconnect를 사용하면 Cloud Interconnect에서 MACsec 또는 HA VPN을 사용하여 연결 레이어에서 전송 중인 트래픽을 암호화해야 합니다. 자세한 내용은 Cloud Interconnect에서 트래픽을 암호화하려면 어떻게 해야 하나요?를 참조하세요.
- TLS를 사용한 서비스 레이어 암호화를 고려할 수도 있습니다. 자세한 내용은 전송 중 데이터 암호화에 대한 규정 준수 요건을 충족하는 방법 결정을 참조하세요.
단일 VPN 터널에서 지원할 수 있는 트래픽 볼륨보다 VPN 하이브리드 연결에서 더 많은 트래픽 볼륨이 필요한 경우에는 활성/활성 HA VPN 라우팅 옵션을 사용하는 것이 좋을 수 있습니다.
- 아웃바운드 데이터 전송 볼륨이 높은 장기 하이브리드 또는 멀티 클라우드 설정의 경우 Cloud Interconnect 또는 Cross-Cloud Interconnect를 사용하는 것이 좋습니다. 이러한 연결 옵션은 연결 성능을 최적화하는 데 도움이 되고 특정 조건을 충족하는 트래픽의 아웃바운드 데이터 전송 비용을 줄일 수 있습니다. 자세한 내용은 Cloud Interconnect 가격 책정을 참조하세요.
Google Cloud 리소스에 연결하고 Cloud Interconnect, 다이렉트 피어링 또는 이동통신사 피어링을 선택하려고 할 때는 Google Workspace 애플리케이션에 액세스할 필요가 없는 한 Cloud Interconnect를 사용하는 것이 좋습니다. 자세한 내용은 Cloud Interconnect와 다이렉트 피어링 및 Cloud Interconnect와 이동통신사 피어링의 기능을 비교해 보세요.
기존 RFC 1918 IP 주소 공간에서 클라우드 호스팅 시스템을 수용할 수 있는 충분한 IP 주소 공간을 허용합니다.
IP 주소 범위를 유지해야 하는 기술적 제한사항이 있는 경우 다음을 수행할 수 있습니다.
하이브리드 서브넷을 사용하여 내부 IP 주소를 Google Cloud에 마이그레이션하는 동안 온프레미스 워크로드에 같은 내부 IP 주소를 사용합니다.
사용자 IP 사용(BYOIP)을 사용하는 Google Cloud 리소스의 자체 공개 IPv4 주소를 Google에 프로비저닝하고 사용합니다.
솔루션을 설계할 때 Google Cloud 기반 애플리케이션을 공개 인터넷에 노출해야 하는 경우 인터넷 연결 애플리케이션 배포를 위한 네트워킹에 설명된 설계 권장사항을 고려합니다.
해당하는 경우 세밀한 방식으로 내부 IP 주소를 사용하여 Google API 또는 게시된 서비스에 비공개로 액세스하도록 Private Service Connect 엔드포인트를 사용하여 Google Cloud, 온프레미스 또는 하이브리드 연결을 사용하는 다른 클라우드의 워크로드를 허용합니다.
Private Service Connect를 사용할 때는 다음을 제어해야 합니다.
- Private Service Connect 리소스를 배포할 수 있는 사용자
- 소비자와 생산자 사이에서 연결 설정 가능 여부
- 이러한 연결에 액세스할 수 있는 네트워크 트래픽
자세한 내용은 Private Service Connect 보안을 참조하세요.
하이브리드 및 멀티 클라우드 아키텍처에서 강력한 클라우드 설정을 달성하려면 다음을 수행합니다.
- 다양한 환경에서 서로 다른 애플리케이션에 필요한 신뢰성 수준을 포괄적으로 평가합니다. 이렇게 하면 가용성 및 복원력 목표를 달성하는 데 도움이 됩니다.
- 클라우드 제공업체의 신뢰성 기능과 설계 원칙을 이해합니다. 자세한 내용은 Google Cloud 인프라 신뢰성을 참조하세요.
클라우드 네트워크 가시성과 모니터링은 신뢰할 수 있는 커뮤니케이션을 유지하는 데 필수입니다. Network Intelligence Center는 네트워크 가시성, 모니터링, 문제 해결을 위한 단일 콘솔을 제공합니다.
하이브리드 및 멀티 클라우드 보안 네트워킹 아키텍처 패턴: 다음 단계
- 이 문서에서 다룬 네트워킹 패턴을 사용하여 인지할 수 있는 일반적인 아키텍처 패턴에 대해 자세히 알아보세요.
- 하이브리드 및 멀티 클라우드에 접근하는 방법과 적절한 워크로드를 선택하는 방법을 알아보세요.
- 온프레미스 및 기타 클라우드 전반의 애플리케이션과 사용자에 맞게 최적화된 안전하며 개방적인 글로벌 네트워크 플랫폼인 Google Cloud 교차 클라우드 네트워크에 대해 자세히 알아보세요.
- Google Cloud의 워크로드를 위한 안정적인 인프라 설계: 리소스, 영역, 리전 수준에서 장애 발생 시 애플리케이션을 보호하는 데 도움이 되는 설계 안내입니다.
- Google Cloud에서 고가용성 아키텍처 설계에 대해 자세히 알아보려면 복원력이 우수하고 확장 가능한 앱 패턴을 확인하세요.
- 온프레미스/에지 환경에서 실행 중인 GKE Enterprise 클러스터를 Google Cloud 네트워크에 연결할 수 있는 가능한 연결 옵션과 일시적인 Google Cloud 연결 해제로 인한 영향에 대해 자세히 알아보세요.