하이브리드 및 다중 클라우드 네트워크 토폴로지 | 솔루션 | Google Cloud
이 문서는 하이브리드 및 다중 클라우드 배포, 아키텍처 패턴, 네트워크 토폴로지를 다루는 여러 부분으로 구성된 시리즈의 세 번째 부분입니다. 이 문서에서는 하이브리드 및 다중 클라우드 설정에 사용할 수 있는 일반적인 네트워크 토폴로지를 살펴봅니다. 이러한 토폴로지가 가장 적합한 시나리오와 아키텍처 패턴을 설명하고 Google Cloud Platform(GCP)을 사용하여 구현하기 위한 권장사항을 제공합니다.
하이브리드 및 다중 클라우드 네트워크 토폴로지(이 문서)
사설 컴퓨팅 환경을 안전하고 안정적인 방식으로 GCP에 연결하는 것은 성공적인 하이브리드 또는 다중 클라우드 배포를 위한 핵심입니다. 하이브리드 및 다중 클라우드 설정을 위해 선택하는 네트워크 토폴로지는 엔터프라이즈 작업 부하의 고유한 요구사항을 충족하고 적용하려는 아키텍처 패턴에 적합해야 합니다. 각 토폴로지에서 조정이 필요할 수는 있지만 청사진으로 사용할 수 있는 일반적인 토폴로지가 있습니다.
미러링 토폴로지는 클라우드 컴퓨팅 환경과 사설 컴퓨팅 환경이 상호 미러링되는 개념입니다. 이 토폴로지는 스테이징 및 프로덕션 작업 부하를 다른 환경에서 실행하면서 개발 및 테스트 작업 부하를 하나의 환경에서 실행하는 환경 하이브리드 패턴을 따르는 설정에 주로 적용됩니다.
테스트 및 프로덕션 작업 부하는 서로 직접 통신하지 않아야 합니다. 그러나 두 작업 부하 그룹을 일관된 방식으로 관리하고 배포할 수 있어야 합니다. 따라서 다음 요구사항을 충족하는 방식으로 두 컴퓨팅 환경을 연결합니다.
지속적 통합/지속적 배포(CI/CD) 및 관리 시스템이 컴퓨팅 환경 전반에서 작업 부하를 배포 및 관리할 수 있습니다.
모니터링 및 기타 관리 도구가 컴퓨팅 환경 전반에서 작동합니다.
작업 부하는 컴퓨팅 환경 간에 통신 할 수 없습니다.
다음 다이어그램은 이러한 요구사항을 충족하는 참조 아키텍처를 보여줍니다.
GCP에서는 두 개의 개별 가상 사설 클라우드(VPC)를 사용합니다. 하나는 개발 및 테스트 작업 부하를 위한 공유 VPC, 다른 하나는 모든 CI/CD 및 관리 도구를 위한 VPC입니다. 두 VPC는 피어링되어 내부 IP 주소를 사용하는 VPC 간 통신을 허용합니다. CI/CD 및 관리 시스템은 피어링을 통해 개발 및 테스트 작업 부하를 배포 및 관리할 수 있습니다.
또한 CI/CD VPC를 사설 컴퓨팅 환경에서 프로덕션 작업을 실행하는 네트워크에 연결합니다. 이 연결은 Cloud Interconnect 또는 Cloud VPN을 사용하여 설정합니다. 이 연결을 통해 프로덕션 작업 부하를 배포 및 관리할 수 있습니다.
VPC 피어링은 전이되지 않으므로 프로덕션 작업 부하와 개발 및 테스트 작업 부하는 서로 통신할 수 없습니다.
모든 환경은 겹치지 않는 공통 RFC 1918 IP 주소 공간을 공유합니다.
이 토폴로지의 변형으로, 개발 및 다양한 테스트 단계에서 모두 CI/CD VPC와 피어링되는 별도의 VPC를 사용할 수 있습니다.
VM 기반 작업 부하를 실행하는 경우 각 환경에서 배포 수행 작업을 맡는 CI 에이전트를 실행하는 것이 유리할 수 있습니다. CI 시스템의 기능에 따라 에이전트를 사용하면 환경 간의 통신을 더 엄격하게 차단하고 상호 통신할 수 있도록 허용되는 시스템을 세부적으로 제어할 수 있습니다.
다음 다이어그램에서 이와 같은 변형을 볼 수 있습니다.
Kubernetes 작업 부하를 배타적으로 실행하는 경우 두 VPC를 피어링할 필요가 없을 수 있습니다. Google Kubernetes Engine(GKE) 제어 영역은 공용이므로 마스터 승인 네트워크 기능 및 RBAC를 사용하여 사용자의 CI 시스템만 배포를 수행하도록 허용할 수 있습니다. 다음 다이어그램은 이 토폴로지를 보여줍니다.
프로덕션 배포를 배포 또는 다시 구성하는 데 필요한 모든 CI/CD 시스템이 높은 가용성을 갖추도록 배포되었는지 확인합니다. 또한 중복 가상 사설망(VPN) 또는 상호 연결 링크를 사용하여 가용성을 높이는 방법을 고려합니다.
개발 및 테스트 VPC의 VM 인스턴스가 공개 IP 주소를 갖도록 구성하여 이러한 인스턴스가 인터넷에 직접 액세스 할 수 있도록 합니다. 그렇지 않은 경우 동일한 VPC에 NAT 게이트웨이를 배포하여 송신 트래픽을 처리합니다.
공개 네트워크를 사용하려면 사설 Google 액세스를 사용하여 VPC 작업 부하와 Google API 간의 통신을 방지합니다.
또한 하이브리드 및 다중 클라우드 네트워킹 토폴로지에 적용되는 일반 권장사항도 고려합니다.
메시 토폴로지 개념은 모든 시스템이 서로 통신할 수 있는, 여러 컴퓨팅 환경에 걸친 평면적인 네트워크를 구축하는 것입니다. 이 토폴로지는 계층형, 파티션, 또는 버스팅 설정에 주로 적용되며, 이를 위해서는 다음 요구사항을 충족하도록 컴퓨팅 환경을 연결해야 합니다.
작업 부하가 사설 RFC 1918 IP 주소 공간을 사용하여 UDP 또는 TCP를 통해 환경 경계를 넘어 서로 통신할 수 있어야 합니다.
방화벽 규칙을 사용하여 컴퓨팅 환경 사이와 컴퓨팅 환경 내의 트래픽 흐름을 세밀하게 제한할 수 있습니다.
GCP 측에서 작업 부하를 하나의 공유 VPC에 배포합니다.
Cloud Interconnect 또는 Cloud VPN을 사용하여 사설 컴퓨팅 환경의 네트워크에 VPC를 연결합니다. 이 설정은 사설 IP 주소를 사용하여 환경 간의 통신이 가능하도록 합니다.
Cloud Router를 사용하여 환경 간에 동적으로 경로를 교환합니다.
추가 심층 패킷 검사 또는 GCP 방화벽 규칙의 기능을 초월하는 기타 고급 방화벽 메커니즘을 구현할 수 있습니다. 이러한 메커니즘을 구현하려면 다음 다이어그램에서 볼 수 있듯이 방화벽 어플라이언스를 통해 모든 환경 간 트래픽을 전달하도록 토폴로지를 확장할 수 있습니다.
전용 전송 VPC와 사설 컴퓨팅 환경의 VLAN 간에 VPN 또는 상호 연결 링크를 설정합니다.
방화벽 어플라이언스를 실행하는 VM을 사용하여 전송 VPC와 애플리케이션 VPC 간에 연결을 설정합니다. 이러한 VM을 IP 전달용으로 구성합니다. VM은 여러 가지 네트워킹 인터페이스를 사용합니다. 하나는 전송 VPC에 연결되고, 다른 하나는 애플리케이션 VPC에 연결됩니다.
방화벽 어플라이언스는 애플리케이션 VPC에 배포되는 VM 인스턴스의 NAT 게이트웨이 역할도 할 수 있습니다. 이 게이트웨이는 이러한 인스턴스가 공개 IP 주소 없이 인터넷에 액세스할 수 있도록 합니다.
클라우드와 사설 컴퓨팅 환경을 더 엄격히 격리하려면 게이트 토폴로지를 사용하는 편이 더 나을 수 있습니다.
사설 컴퓨팅 환경 내에서 Kubernetes를 사용하는 경우 Open Service Broker를 사용하여 Google 플랫폼 서비스 및 리소스를 통합된 방식으로 프로비저닝합니다..
게이트 송신
게이트 송신 토폴로지의 개념은 사설 컴퓨팅 환경의 선택된 API를 공개 인터넷에 노출하지 않고 GCP에 배포되는 작업 부하에 노출하는 것입니다. 기존 작업 부하의 외관 역할을 하는 API 게이트웨이를 통해 이러한 제한된 노출을 촉진할 수 있습니다. 게이트웨이를 DMZ에 배포하고, 실제 작업 부하는 사설 컴퓨팅 환경 내의 더 안전한 전용 네트워크에 배포합니다.
게이트 송신은 계층형 설정에 주로 적용되며, 이를 위해서는 다음 요구사항을 충족하도록 컴퓨팅 환경을 연결해야 합니다.
GCP에 배포하는 작업 부하는 사설 IP 주소를 사용하여 API 게이트웨이와 통신할 수 있습니다. 사설 컴퓨팅 환경의 다른 시스템은 GCP 내에서 도달할 수 없습니다.
사설 컴퓨팅 환경에서 GCP에 배포된 작업 부하로의 통신은 허용되지 않습니다.
GCP 측에서 작업 부하를 공유 VPC에 배포합니다.
Cloud Interconnect 또는 Cloud VPN을 사용하여 VPC를 사설 컴퓨팅 환경의 DMZ에 연결해서 API 게이트웨이 호출을 허용합니다.
VPC로 들어오는 연결을 방화벽 규칙을 사용하여 차단합니다.
필요에 따라 Cloud Router를 사용하여 환경 간에 동적으로 경로를 교환합니다.
인터넷에 액세스하려면 애플리케이션 VPC에 배포하는 VM 인스턴스에 외부 IP 주소가 있어야 합니다. 이러한 외부 주소 설정 과정을 피하려면 다음 다이어그램에서 볼 수 있듯이 NAT 게이트웨이를 동일한 VPC에 배포하면 됩니다.
Apigee Edge for Private Cloud를 API 게이트웨이 솔루션으로 사용하는 방법이 있습니다.
NAT 게이트웨이가 단일 장애점이 되지 않도록 하려면 여러 게이트웨이를 배포하고 ECMP 라우팅을 사용하여 트래픽을 분산합니다.
게이트 수신
게이트 수신 토폴로지의 개념은 GCP에서 실행 중인 작업 부하의 선택된 API를 공개 인터넷에 노출하지 않고 사설 컴퓨팅 환경에 노출하는 것입니다. 이 토폴로지는 게이트 송신 시나리오에 대응하며 에지 하이브리드 시나리오에 적합합니다.
다음과 같이 사설 컴퓨팅 환경 액세스가 가능하도록 설정한 API 게이트웨이를 통해 선택된 API를 노출합니다.
사설 컴퓨팅 환경에 배포하는 작업 부하는 사설 IP 주소를 사용하여 API 게이트웨이와 통신할 수 있습니다. GCP에 배포된 다른 시스템에는 도달할 수 없습니다.
GCP에서 사설 컴퓨팅 환경으로의 통신은 허용되지 않습니다.
GCP 측에서 작업 부하를 애플리케이션 VPC에 배포합니다.
전용 전송 VPC와 사설 컴퓨팅 환경 간에 Cloud Interconnect 또는 Cloud VPN 연결을 설정합니다.
API 게이트웨이를 실행하는 VM을 사용하여 전송 VPC와 애플리케이션 VPC 간에 연결을 설정합니다. 이러한 VM은 두 개의 네트워킹 인터페이스를 사용합니다. 하나는 전송 VPC에 연결되고 다른 하나는 애플리케이션 VPC에 연결됩니다. 여러 API 게이트웨이 인스턴스로 트래픽을 분산하려면 전송 VPC에 내부 부하 분산기를 구성합니다.
애플리케이션 VPC에 NAT 게이트웨이를 배포하여 작업 부하에서 인터넷에 액세스하도록 허용합니다. 이 게이트웨이를 사용하면 API 게이트웨이 뒤에 배포되는 시스템에서는 바람직하지 않은 외부 IP 주소를 VM 인스턴스에 갖출 필요가 없습니다.
필요에 따라 Cloud Router를 사용하여 환경 간에 동적으로 경로를 교환할 수 있습니다.
게이트 수신 및 송신
게이트 수신 및 송신을 결합하면 GCP 및 사설 컴퓨팅 환경에서 실행되는 작업 부하 간에 선택된 API를 양방향으로 사용할 수 있습니다. 양쪽에서 API 게이트웨이를 사용하여 선택한 API를 노출하고 선택적으로 호출을 인증, 승인, 감사합니다.
API 통신은 다음과 같이 작동합니다.
GCP에 배포하는 작업 부하는 사설 IP 주소를 사용하여 API 게이트웨이와 통신할 수 있습니다. 사설 컴퓨팅 환경에 배포된 다른 시스템에는 도달할 수 없습니다.
반대로 사설 컴퓨팅 환경에 배포하는 작업 부하는 사설 IP 주소를 사용하여 GCP 측 API 게이트웨이와 통신할 수 있습니다. GCP에 배포된 다른 시스템에는 도달할 수 없습니다.
다음 다이어그램은 게이트 수신 및 송신 토폴로지의 참조 아키텍처를 보여줍니다.
GCP 측에서 작업 부하를 공유 VPC에 배포하고 인터넷에는 노출하지 않습니다.
또한 두 VPC에 연결되는 NAT 게이트웨이 역할을 하는 VM 인스턴스를 사용합니다. 이러한 인스턴스는 작업 부하에서 인터넷에 액세스하고 사설 컴퓨팅 환경에서 실행 중인 API 게이트웨이와 통신하도록 허용합니다.
핸드오버 토폴로지의 개념은 GCP가 제공하는 저장소 서비스를 사용하여 사설 컴퓨팅 환경을 GCP의 프로젝트에 연결하는 것입니다. 이 토폴로지는 분석 패턴을 따르는 설정에 주로 적용됩니다. 각 항목의 의미는 다음과 같습니다.
사설 컴퓨팅 환경에서 실행 중인 작업 부하는 공유 저장공간 위치에 데이터를 업로드합니다. 사용 사례에 따라 업로드는 대량으로 수행되거나 작은 메시지로 수행될 수 있습니다.
그러면 GCP에 호스팅되는 작업 부하는 이러한 위치의 데이터를 소비하고 스트리밍 또는 일괄 처리 방식으로 처리합니다.
다음 다이어그램은 핸드오버 토폴로지의 참조 아키텍처를 보여줍니다.
GCP 측에서 작업 부하를 애플리케이션 VPC에 배포합니다. 이러한 작업 부하에는 데이터 처리, 분석, 분석 관련 프런트엔드 애플리케이션이 포함될 수 있습니다.
프런트엔드 애플리케이션을 기업 사용자에게 안전하게 노출하려면 Cloud Identity-Aware Proxy를 사용할 수 있습니다.
Cloud Storage 버킷 또는 Cloud Pub/Sub 대기열 집합을 사용하여 사설 컴퓨팅 환경의 데이터를 업로드하고 GCP에 배포된 작업 부하에서 부가적인 처리를 위해 이러한 데이터를 사용할 수 있도록 합니다. IAM 정책을 사용하여 신뢰할 수 있는 작업 부하로 액세스를 제한할 수 있습니다.
환경 간에 사설 네트워크 연결이 없으므로 RFC 1918 IP 주소 공간이 환경 간에 겹칠 수 있습니다.
참고: 이 아키텍처에서 Cloud Storage 버킷 또는 Cloud Pub/Sub과의 통신은 Cloud VPN 또는 Cloud Interconnect가 아닌 공개 네트워크를 통해 수행됩니다.
Cloud Storage 버킷 및 Cloud Pub/Sub 항목 액세스를 잠급니다. 또한 Cloud Storage 버킷의 액세스 제어 및 보안 관리에 대한 권장사항에 따릅니다.
지연을 줄이고 공개 인터넷을 통한 데이터 전달을 방지하려면 직접 피어링 또는 이동통신사 피어링을 사용하는 것이 좋습니다.
Cloud Storage 또는 Cloud Pub/Sub 위치에 대한 액세스를 특정 IP 주소 범위로 제한하려면 VPC 서비스 제어를 사용합니다.
VPC의 VM 인스턴스에 공개 IP 주소를 부여하여 직접 인터넷에 액세스할 수 있도록 합니다. 그렇지 않은 경우 동일한 VPC에 NAT 게이트웨이를 배포하여 송신 트래픽을 처리합니다.
하이브리드 및 다중 클라우드 네트워킹 토폴로지의 권장사항
Google Cloud Platform 측에서 공유 VPC를 활용하세요. 공유 VPC는 여러 Google Cloud Platform 프로젝트에서 사용할 수 있으므로 많은 수의 개별 VPC를 유지할 필요가 없습니다. 또한 공유 VPC를 사용하면 피어링 구성, 서브넷, 방화벽 규칙, 권한을 중앙에서 관리할 수 있습니다.
방화벽 규칙을 관리하는 경우 네트워크 태그 기반 필터링보다 서비스 계정 기반 필터링을 우선 사용하세요.
개별 작업 부하를 상호 격리하기 위해 VPC를 사용하는 것은 피해야 합니다. 대신 서브넷 및 방화벽 규칙을 사용하세요. GKE를 사용하는 경우 네트워크 정책을 사용하여 이 접근 방법을 보완할 수 있습니다.
Cloud VPN은 환경 간 트래픽이 암호화되도록 하지만 Cloud Interconnect는 그렇지 않습니다. 작업 부하 간 통신을 보호하려면 전송 레이어 보안(TLS)을 사용하여 보호하는 것이 좋습니다.
대용량 VPN 생성을 위한 권장사항에 따르세요.
기존 RFC 1918 IP 주소 공간에서 모든 클라우드 호스팅 시스템을 수용하기 위한 충분한 주소 공간을 허용하세요.
GKE를 사용하는 경우 사설 클러스터를 사용하는 것이 좋으며, 네트워크 크기 요구사항에 유의해야 합니다.
외부 IP 주소가 할당되지 않은 GCP에서 실행 중인 VM 인스턴스가 Google 서비스에 액세스하도록 허용하려면 사설 Google 액세스를 사용하세요.
이 문서에서 다룬 네트워크 토폴로지를 사용하여 인지할 수 있는 일반적인 아키텍처 패턴에 대해 알아보세요.
하이브리드 및 다중 클라우드에 접근하는 방법과 적절한 작업 부하를 선택하는 방법을 알아보세요.