Google Cloud 랜딩존 네트워크 아키텍처

1. 목적 및 활용 방법

구글 클라우드 기반의 랜딩존을 구축할 때, 네트워크 거버넌스 요구사항을 충족하기 위한 아키텍처를 제안합니다. 구글 클라우드의 랜딩존과 그것의 네트워크 아키텍처는 다음의 문서에 기술된 내용에 기반하여 구축하게 됩니다.

• Security foundations blueprint | Google Cloud (한국어)
• Landing zone design in Google Cloud (한국어)
• Best practices and reference architectures for VPC design (한국어)
• Centralized network appliances on Google Cloud | Cloud Architecture Center (한국어)

이 글에서는 위의 문서에 기술된 내용을 기반으로 하되, 국가별 규정이나 산업별 표준에 따라 추가적으로 필요한 요구사항 그리고 다수의 고객들이 이러한 요구를 만족하기 위해 채용하고 있는 공통적인 네트워크 아키텍처들을 상세히 기술함으로써, 기존 문서들의 부족한 부분들을 보완하고 있습니다. 단, 실제 구축에 필요한 상세한 구성이나 구현 방법을 제시하는 대신, 다양한 요구사항과 기업의 환경에 맞게 사용할 수 있는 공통적인 아키텍처를 제시하는데 초점을 맞추었습니다. 따라서, 실제 구축은 구글의 PSO(Professional Service Organization)나 MSP(Managed Service Partner)의 전문가들과 상의하면서 진행하기를 권고합니다.

이 문서의 구조와 활용하는 방법은 다음과 같습니다.

• 먼저 각자 필요로 하는 요구사항에 대해 구체적으로 파악 및 정의합니다.
• 챕터 2: 이 글에서 사용하는 각종 용어들에 설명으로 이미 익숙하다면 지나가도 됩니다.
• 챕터 3: 도출한 요구사항에 따라 의사 결정 트리에 따른 각각의 구현 방안의 특징을 확인합니다.
• 챕터 4: 최종적으로 여러 아키텍처 유형 중에서 각자의 요구사항에 맞는 것을 선택합니다.

이 문서에서 VPC 간의 연결은 가장 기본적인 방법인 VPC Peering이나 VPN을 우선적으로 사용할 것입니다. 다만, 최근에 등장한 Private Service Connect(또는 PSC)를 사용하면 VPC 간 연결에 유연성을 높일 수 있으므로, 문서의 마지막에 VPC Peering이나 VPN의 대안으로 사용할 수 있는 아키텍처에 대해 설명할 것입니다. 따라서 위의 과정에 다음의 선택 사항이 추가됩니다.

• 챕터 5: PSC를 통해 선택한 아키텍처에서 유연성을 개선할 부분이 있다면 해당 부분을 PSC로 변경합니다.

2. 기본적인 기술 개념 및 용어 정의

이 글에서는 기본적으로 구글 클라우드와 네트워크, 보안 분야에서 사용되는 다양한 용어를 사용하고 있습니다. 해당 용어들은 표준화된 경우가 많지만 업계에서 통상 사용하는 관습적인 경우도 있어 이들 간의 혼선을 막기 위해 이 글에서 자주 사용하는 용어와 개념 그리고 차이점에 대해서 설명합니다.

용어 정의

DMZ or Untrusted VPC
외부(인터넷) 네트워크 환경과 직접 연결된 환경을 DMZ(Demilitarized Zone) 구간이라고 말하는 경우가 있습니다. 외부에서 들어오는 트래픽이 먼저 DMZ 구간에서 받아 위험한 침입을 필터링 하고 안전한 트래픽만을 내부 시스템으로 보내는다는 의미에서 이 용어를 사용합니다. 구글 클라우드 네트워크 아키텍처에서는 아래 문서에 Untrusted VPC로 언급이 되어 있습니다.

• Centralized network appliances on Google Cloud | Cloud Architecture Center 

명시적으로 Untrusted 혹은 DMZ에 대해 의미가 설명되어 있지 않지만, 의미상 외부 인터넷에서 들어오는 트래픽을 직접 내부 Trusted VPC에 연결하지 않고 중간에서 중계하는 역할을 합니다. 여기서는 중계 과정에 가상 네트워크 장비(Virtual Network Appliance)가 배치되어 있는데, 이것의 역할은 다음과 같습니다.

• 외부 트래픽을 연결 종료(termination)
• L7 트래픽에 대한 침입 탐지 및 방어
• 최종 목적지인 Trusted VPC로 안전한 트래픽을 라우팅

Virtual Network Appliance
라우팅, 로드밸런싱 등 네트워크 기능을 담당하는 소프트웨어를 가상의 컴퓨팅 자원인, VM(Virtual Machine)에서 동작시키는 장비를 말합니다. 이 글에서 언급되는 Virtual Network Appliance는 그 중에서도 차세대 방화벽이라고 말하는 NGFW(Next Generation Firewall)를 가리키고 있습니다. 기존의 방화벽이 L4 레벨에서 IP 패킷 차원이나 포트 단위의 공격을 방어하는 역할을 한데 반해, NGFW는 L7 레이어에서 애플리케이션 패킷의 내용에 기반한 공격까지도 방어하는 일종의 WAF(Web Application Firewall) 기능과 IPS(Intrusion Prevention System), IDS(Intrusion Detection System), 그리고 네트워크 간 라우팅의 역할까지도 같이하는 복합적인 기능을 하는 장비입니다.

Private Service Connect
특정 클라이언트로부터 특정 서비스에 대한 액세스를 가능하게 하는 서비스입니다. 아래 그림처럼 VPC Peering의 경우에는 두 VPC 간에 서로 라우팅으로 연결하고 라우팅 테이블을 서로 교환하기 때문에 해당 VPC 내에 있는 모든 Endpoint 간에 통신이 가능합니다. 반면 PSC(Private Service Connect)는 VPC에 있는 특정 Endpoint(예: Cloud SQL, Compute Engine)에 대한 특정 클라이언트의 액세스를 연결하는 기능을 합니다. 특히 VPC Peering은 기본적으로 양방향 통신인 반면, PSC는 단방향 연결입니다. 즉, Consumer 역할을 하는 클라이언트에서 Producer 역할을 하는 특정 서비스로의 단방향 연결만 가능하고, 양방향 연결이 필요하다면 명시적으로 별도의 PSC 연결을 만들어야 합니다.

PSC에 대한 상세 설명과 그것을 사용한 아키텍처에 대해서는 챕터 5에서 보다 상세하고 설명합니다.

LB Frontend, Backend, Forwarding rule
구글 클라우드의 로드밸런서는 다음과 같은 구조를 가지고 있습니다. 왼쪽에서 트래픽이 들어오면 처음에는 Frontend에서 받습니다. Frontend는 트래픽이 인입하는 지점(URL 혹은 IP, Port. 예: 10.10.10.1:8888)을 가지고 있고, 수신한 트래픽을 실제 서비스를 담당하는 백엔드로 규칙에 따라 포워딩하는 Forwarding rule을 가지고 있습니다. Backend service는 실제 트래픽을 담당하는 백엔드(예: Instance Group, CDN: Content Delivery Network)를 관리하는 역할을 합니다. 백엔드가 살아 있는지(health check), 백엔드가 트래픽을 충분히 처리할 수 있는지 등을 관리하고 조절합니다.

Instance Group
구글 클라우드의 여러 VM들을 하나의 논리적인 단위로 통합한 것입니다. 동일한 역할을 하는 VM들을 하나로 묶어 관리함으로써 이들 간의 로드밸런싱, 스케일링(scale-in, scale-out), 서비스 가능 여부 검사(health-check) 등을 일괄 수행합니다. 주로 애플리케이션 서비스를 VM으로 만들어 로드밸런서의 백엔드로 많이 사용됩니다.

NLB(Network Load Balancer)
구글 클라우드에서 로드밸런서를 생성할 때, 다음과 같은 메뉴를 통해 생성되는 Layer 4, IP 레이어의 로드밸런서를 의미합니다. NLB는 크게 TCP(SSL 포함) 프로토콜을 처리하는 TCP NLB와, UDP 프로토콜을 처리하는 UDP NLB가 있습니다. NLB의 프론트엔드는 L4 레이어의 IP와 Port로 이루집니다.

ALB(Application Load Balancer)
구글 클라우드에서 로드밸런서를 생성할 때 다음과 같은 메뉴를 통해 생성되는 Layer 7, 애플리케이션(HTTP, HTTPS 등) 레이어의 로드밸런서를 의미합니다.

애플리케이션 레이어는 HTTP 프로토콜에서 사용하는 URL, Protocol, URL Path 등을 사용하여, 이것의 프론트엔드는 다음과 같은 방식으로 결정됩니다. IP(Host), Port 뿐만 아니라 뒤에 따라오는 URL Path에 의해서 포워딩 규칙(forwarding rule)이 결정되며, 그에 매핑된 Backend service로 트래픽을 전달합니다.

예: http://10.10.10.1:80/svc1/resource1
예: https://10.10.10.2:443/svc2/resource2 

3. 구글 클라우드 네트워크 아키텍처 의사 결정 트리

다음은 각자 필요로 하는 요구사항을 구체화하기 위한 의사 결정 트리입니다.

각각의 의사 결정 과정에 대해 상세히 알아보면 다음과 같습니다.

(1) Untrusted(DMZ) VPC와 Trusted(Internal) VPC의 관리 주체가 다릅니까?

챕터 2의 용어 정의에서 설명했듯이 DMZ(또는 Untrusted)는 외부 트래픽이 인입되는 네트워크를 의미합니다. 이 DMZ 네트워크와 내부 서비스 VPC를 분리해야 하는지 판단합니다. 여기서 중요한 의사 결정 요소는,

외부 트래픽을 처리하는 VPC(통상 DMZ 또는 Untrusted VPC라고 함)와 내부 서비스 트래픽을 처리하는 VPC를 분리해서 “관리” 해야 하는가

입니다. 특히 분리해서 “관리” 하는 부분을 어느 수준까지의 분리로 보느냐도 중요한데,

두 개를 별개의 VPC로 분리만 하면 될지, 또는 해당 VPC를 관리하는 관리자(클라우드의 IAM 계정)가 달라야 하는가

결정해야 합니다. 구글 클라우드에서 VPC를 분리하는 것은 동일한 프로젝트 내에서도 가능하지만, VPC를 관리하는 관리자(IAM 계정)가 달라야 한다면 프로젝트를 분리해서 각각의 VPC를 배치해야 합니다.

일반적으로 VPC나 프로젝트를 분리하면 분리할 수록 관리해야할 컴포넌트의 개수가 많아지고 관리 주체가 달라지기 때문에 복잡도가 올라갑니다. 따라서 특별한 보안적 요구사항이나 업계의 규정이 없다면 동일한 프로젝트나 동일한 VPC를 사용하는 것이 유리합니다. 다만, 업계의 보안 규정상 분리를 해야 한다면 상황에 맞게 적절한 수준(프로젝트 또는 VPC)에서 분리를 합니다.

아래는 세 가지 경우를 다이어그램으로 표현한 것입니다. 이 문서에서는 단일 프로젝트와 프로젝트를 복수로 분리하는 경우를 명시적으로 구분하여 설명할 것입니다. 하지만 단일 프로젝트 내에서의 VPC 분리 여부는 가능하면 단순한 방안(단일 VPC 구조)을 제시하고, 꼭 필요한 경우만 분리하는 방안(VPC를 분리하고 각각을 VPC Peering, VPN 등으로 연결)에 대해 설명할 것입니다.

(2) 온프레미스 또는 다른 클라우드 네트워크 연결이 필요합니까?

구글 클라우드 내에서의 네트워크 트래픽만을 처리하는 것이 아닌 외부의 네트워크 즉, 온프레미스나 다른 클라우드에 연결하기 위해서는 interconnect나 VPN을 구성하여 해당 네트워크에 연결하는 구성이 필요합니다. 둘 중 하나라도 필요하면 선택해야 할 의사 결정 요소입니다. 다만, 물리적인 구성이나 용량 등에서 차이는 있지만 실제 아키텍처적인 동작에서는 거의 유사하므로 이 글에서는 Interconnect를 사용한 온프레미스 연결을 가정하고 설명합니다.

(3) 가상 네트워크 어플라이언스를 사용하는 VPC 간 레이어 7 트래픽 검사가 필요합니까?

여기서 말하는 가상 어플라이언스는 L7 차세대 방화벽(NGFW)를 의미하며, 주요한 용도는 DMZ VPC에서 들어온 트래픽을 내부 VPC로 바로 보내지 않고 안전한지 검사를 하여 위험한 요청을 제외한 안전한 트래픽만을 전달하는 것입니다.

업무의 종류나 업계의 규정에 따라 구글 클라우드가 제공하는 로드밸런서와 그것이 제공하는 웹방화벽(WAF)만으로 요구사항을 준수할 수 있는 경우도 있지만, 그렇지 않은 경우에는 이 의사 결정 요소를 선택해야 합니다.

참고로 NGFW는 구글 클라우드에서는 마켓플레이스를 통해서 배포하거나 별도의 3rd Party 업체의 제품을 Virtual Appliance 형태로 설치를 해야 합니다. NGFW는 트래픽의 안정성을 검사하는 기능과 함께 트래픽 자체를 목적지 VPC를 다음 Hop으로 전달하는 기능도 가지고 있습니다.

(4) 인프라를 관리하는 중앙 집중식 네트워크/보안 팀이 있습니까?

이 의사 결정 요소는 궁극적으로 구글 클라우드가 제공하는 공유 VPC(Shared VPC)와 관련이 있습니다. 공유 VPC는 다음과 같이 실제 워크로드를 처리하는 서비스 프로젝트들은 각자의 VPC를 가지지 않고, 대신 호스트 프로젝트가 가지고 있는 공유 VPC에서 서브넷(subnet)을 할당받아 사용하는 방식을 의미합니다.

따라서 공유 VPC를 사용하게 되면 다음과 같은 특징이 있습니다.

• 우선 호스트 프로젝트에서 전사 서비스 프로젝트들의 네트워크를 관리하는 중앙 집중식 네트워크 및 보안 관리자(또는 팀)가 있어야 합니다.
• 서비스 프로젝트를 운영하는 팀에서는 네트워크 구성(외부 연결, 온프레미스 연결, IP 할당 등)에 대해 크게 고민할 필요 없습니다.
• 로드밸런서의 경우 실제로 동작은 Host Project에 속한 Shared VPC에서 이루어지지만, 구성이나 백엔드 서비스(에: VM) 매핑 등은 Service Project에서 하여 네트워크 관리와 서비스 관리를 분리할 수 있는 장점이 있습니다.
• 호스트 프로젝트가 제공하는 단일한 공유 VPC를 각 서비스 프로젝트가 공유하므로 서비스 간의 트래픽이 기본적으로 연결(라우팅)이 됩니다. 서비스 간에 트래픽을 차단하기 위해서는 방화벽 구성을 통해 서비스넷 간 통신을 차단해야 합니다.

(5) VPC 간 연결하는 방법 Peering과 VPN의 차이

VPC를 호스팅하는 프로젝트가 분리되거나 VPC가 분리된 경우에는 두 네트워크를 연결하는 방법이 필요합니다. VPC 간 연결하는 방법인 VPC Peering과 VPN의 가장 큰 차이는 Transitive Peering이 되는가 여부입니다. VPC Peering은 Transitive Peering이 불가능한 반면, VPN은 가능합니다. Transitive Peering이란, 두 VPC 간의 연결을 통해 제 3의 VPC와 연결도 지원할 수 있는 기능입니다. 상세한 차이점에 대해서 살펴보겠습니다.

아래 그림과 같이 공유 VPC A(일반 VPC인 경우에도 동일)와 VPC B, C를 각각 연결한다고 가정해봅시다. VPC B는 Peering을 통해서 연결하고, VPC C는 VPN을 통해서 연결합니다. 이 때 VPC B, C 내에서 동작하는 Compute Engine B와 C는 각각 VPC A 내에서 동작하는 Compute Engine 1, 2와 통신이 가능합니다. VPC Peering이 양쪽 VPC의 라우팅 테이블을 교환하기 때문입니다.

여기서 VPC A에 배포된 Cloud SQL과 같은 Managed Service가 있다고 가정해 봅니다. Cloud SQL은 관리형 인스턴스를 숨겨진 Managed VPC에 배포하고 그것을 서비스를 운영하는 주 VPC에 Peering을 통해서 연결합니다. 이 경우 VPC B 입장에서 Cloud SQL은 VPC A를 통해서 바로 연결되는 것이 아니라, VPC B - VPC A - Managed VPC 간 이중 Peering을 통해서 연결되어야 합니다. 이 경우 Peering은 Transitive Peering이 되지 않으므로 VPC B에서 온 트래픽이 Managed VPC로 전달되지 않습니다.

반면, VPC C는 VPC A와 VPN으로 연결되어 있고 이 경우에는 VPC C에서 보낸 트래픽을 VPC C - VPC A 간의 VPN을 거쳐 VPC A - Managed VPC 간의 Peering을 통해서 전달됩니다..

따라서 VPC 간 연결을 위한 의사 결정 시, 이러한 Transitive Peering 기능이 필요한 경우에는 VPN을 사용해야 합니다. 특히, Cloud SQL, Memory Store 등과 같은 관리형 서비스들은 이러한 Managed VPC 형태를 하고 있고, 이러한 서비스들을 다른 VPC에서 연결해야 한다면 반드시 VPN을 사용해야 합니다..

만약, Peering을 통해서 Transitive Peering 요구사항을 해결하려면, 중간의 VPC A에 Proxy 역할을 할 수 있는 컴포넌트를 넣어 VPC B와 Managed VPC 사이 통신을 중계해야 합니다. Proxy 역할을 할 수 있는 컴포넌트로는 Compute Engine VM, Private Service Connect(PSC) 또는 NGFW 등이 있습니다. NGFW에 대해서는 3-(3)에 설명되어 있고 PSC에 대해서는 챕터 5에서 설명합니다.

(6) 외부 인터넷 SSL Termination을 LB에서 해야 하는가?

3-(1)과 3-(3)에서 각각 Untrusted VPC(외부 트래픽이 인입되는 네트워크)와 해당 트래픽에 대한 L7 레이어 검사를 위한 가상 어플라이언스 장비에 대한 언급을 하였습니다. 이 때, 두 가지 고려사항이 필요합니다.

첫 번째는, 외부에서 인입되는 트래픽이 HTTPS 혹은 SSL일 경우, 내부로 전달할 때 경로 상의 어느 지점에서는 SSL 트래픽을 일반 Plain Text 트래픽으로 변경하는 SSL Termination이 일어나야 합니다. SSL Termination을 위해서는 클라이언트가 보낸 SSL 트래픽을 디코딩할 수 있는 인증서가 필요합니다. SSL Termination을 트래픽이 인입되는 최초의 로드밸런서에서 하려면, 해당 로드밸런서에 인증서가 설치되어 있어야 합니다. 만약 최초 로드밸런서가 아닌 내부의 어느 지점에서 하려면, 해당 지점에 인증서가 설치되어야 합니다. 반면 해당 지점 앞 단계에서는 트래픽의 내용이 암호화 되어 있기 때문에 해당 내용을 볼 수 없고 단지 백엔드로 전달(pass-through)하는 역할만 하게 됩니다.

두 번째로 고려할 사항은 가상 어플라이언스를 VM에 배포하고 그것을 Instance Group으로 구성하여 로드밸런서의 백엔드(LB Backend)로 지정해야 합니다. 이 때, 가상 어플라이언스는 고가용성을 생각하여 복수로 구성을 하는 것이 권장됩니다. 구글 클라우드의 로드밸런서는 백엔드로 사용하는 Instance Group을 복수로 구성하여 그것들을 Active/Active 방식으로 사용할지 Active/Standby 방식으로 사용할지 결정해야 합니다. 사용하는 가상 어플라이언스가 두 가지 모두 지원한다면 선택이 자유롭지만, Active/Standby 방식만 지원한다면 로드밸런서의 종류가 NLB(Network Load Balancer)로 제한됩니다.

다음은 SSL Termination이 최초의 로드밸런서에서 일어나고, 가상 네트워크 어플라이언스에 대한 Instance Group은 Active/Active 형태로 구성된 경우입니다. 빨간색 선이 SSL 트래픽을 나타내고 검은색 선은 SSL Termination 이후 Plain Text 트래픽을 나타낸다. 여기서 사용된 구글 클라우드의 로드밸런서 ALB(Application Load Balancer, L7)입니다. Global HTTP/HTTPS 요청을 처리할 수 있는 GLB(Global LB)나 Regional ALB 등이 여기에 속합니다. 네트워크 어플라이언스가 Active/Active 구성을 지원한다면 아래와 같은 형태의 구성이 권장됩니다.

다음은 Instance Group을 Active/Standby 형태로 구성하는 경우입니다. 구글 클라우드에서 Instance Group을 Active/Standby 형태로 구성하여 로드밸런서의 백엔드로 사용하려면 NLB(Network Load Balancer)가 사용되어야 합니다. NLB의 백엔드에는 복수의 Instance Group을 연결하여 하나는 Primary로 지정하여 Active 모드로 동작하게 하고, 여기에 문제가 생기면 Failover로 지정한 Standby 모드의 Instance Group을 Active로 변경하여 그것을 통해 트래픽을 처리하게 할 수 있습니다. 다만, 이렇게 사용하기 위해서는 NLB가 Proxy 방식이 아닌 Pass-through 모드로 동작해야 하며, 이 경우 SSL Termination을 하는 것이 불가능합니다. Pass-through 모드는 말 그대로 들어온 TCP 트래픽을 그대로 백엔드로 전달하는 역할만 합니다.

4. 단일 프로젝트 아키텍처

(1) 단일 프로젝트 - Untrusted, Trusted VPC 간 동일 거버넌스 체계

다음과 같은 요구사항에 대해 관리 주체가 동일한 경우입니다.

Untrusted(DMZ) VPC와 Trusted(Internal) VPC의 관리 주체가 다릅니까?

이 경우에는 단일 Host Project에서 VPC를 구성하고 그것을 각 서비스 프로젝트에서 가져다 사용합니다. 가장 큰 특징은 인터넷에서 트래픽이 인입되는 DMZ VPC와 실제 워크로드를 처리하는 서비스 프로젝트가 단일한 VPC 및 단일한 프로젝트에 속한 경우입니다. 이 경우의 특징은 다음과 같습니다.

• 외부 트래픽을 처리하기 위한 로드밸런서와 서비스 프로젝트 네트워크가 하나의 VPC에 구성되며, 동일한 관리 주체가 관리합니다.
• 따라서 네트워크팀이 크지 않아 동일한 사람이나 팀이 담당해야 하는 경우 관리 오버헤드를 감소할 수 있습니다.
• 반대로 외부 트래픽과 서비스 프로젝트를 분리해서 관리해야 한다면 사용할 수 없는 방법입니다.
• 외부 트래픽 네트워크를 통해 들어오는 침입은 로드밸런서에 Cloud Armor를 구성하여 방어합니다.

주: GLB는 특정 VPC에 속하지 않으며, 동일 프로젝트 내 모든 VPC의 Instance Group, NEG 또는 다른 프로젝트의 서비스를 PSC 를 통해 backend로 연결해서 요청을 전달할 수 있음.

이 구성에서 추가적으로 고려해야 하는 요구사항은 다음과 같습니다.

• 온프레미스 또는 다른 클라우드 네트워크 연결이 필요합니까?
• 가상 네트워크 어플라이언스를 사용하는 VPC 간 레이어 7 트래픽 검사가 필요합니까?

(2) 단일 프로젝트 - 하이브리드(온프레미스 또는 다른 클라우드) 네트워크 구성

3-(2)에서 언급한 것처럼 Interconnect를 사용한 온프레미스 연결을 가정하고 설명합니다. Interconnect를 통해서 구글 클라우드 VPC와 온프레미스 네트워크 연결할 경우, 3-(4) 요구사항처럼 공유 VPC에서 일괄 연결할 수도 있고 별도의 VPC를 분리하여 연결하는 방법 중에서 선택이 가능합니다.

다음은 단일한 공유 VPC에 온프레미스 네트워크를 연결한 경우입니다. 온프레미스 자원은 Interconnect를 통해 구글 클라우드의 VPC에 연결되어 있고 거기에 연결 또는 포함되어 있는 모든 자원(여기서는 Compute Engine, Cloud SQL)에 접근할 수 있습니다. 반대의 연결도 마찬가지입니다. 이 경우의 특징은 다음과 같습니다.

• 온프레미스 연결 네트워크 연결까지 모든 네트워크에 대한 관리를 하나의 팀에서 합니다.
• Cloud SQL과 같은 Managed Service에 대한 연결도 가능합니다.

만약 관리 주체의 차이¹로 온프레미스 연결을 별도의 VPC를 통해서 해야 한다면, 해당 VPC와 서비스 VPC 사이의 연결에 3-(5)에 언급된 Peering이나 VPN 중에서 하나의 방법을 사용해야 합니다. 특히 Transitive Peering 요구사항이 있다면 반드시 해당 섹션에 언급된 대로 VPN을 사용하거나 Proxy 기능이 같이 구현된 Peering을 사용해야 합니다. 다음은 온프레미스에 연결하는 VPC가 서비스용 공유 VPC A와 분리된 상태를 나타낸 다이어그램으로, Peering으로 연결한 VPC B와 VPN으로 연결한 VPC C를 동시에 표현한 것입니다.VPC Peering을 사용한 Location B의 경우 Transitive Peering이 되지 않기 때문에 온프레미스에서 보내는 요청이 VPC B를 거쳐 VPC A에는 도달하지만, Managed Service가 위치한 Managed VPC까지는 요청이 전달되지 않습니다. VPN을 사용한 Location C의 경우에는 온프레미스 요청이 VPC C와 VPC A를 거쳐 Managed VPC까지 전달됩니다.

이러한 단일 프로젝트 아키텍처에서, GLB를 통해서 들어오는 인터넷 트래픽을 직접 온프레미스에 있는 서비스로 보내야 한다면 아래와 같이 Hybrid NEG를 GLB의 Backend로 하여(VPC 연결 방법에 상관 없이) 연결할 수 있습니다. 상세한 내용은 아래 문서를 참고하면 됩니다.

• Hybrid connectivity network endpoint groups overview | Load Balancing | Google Cloud
• Set up a global external Application Load Balancer with hybrid connectivity 

또 한 가지 고려해야 할 부분은 온프레미스와 연결하는 전용선(Interconnect)에 대한 이중화입니다. 일정 수준 SLA를 보장하기 위해서는 회선의 이중화와 함께 물리적인 연결 지역(region 또는 zone)에 대한 이중화도 해야 합니다. 이 글에서는 해당 부분을 구현하는 방법이나 아키텍처에 대한 자세한 언급은 하지 않을 것이며, 상세한 내용은 다음 문서들을 참고하기 바랍니다.

• Networking | Security foundations | Google Cloud
• Topology for production-level applications overview | Cloud Interconnect 
• Topology for non-critical applications overview | Cloud Interconnect

(3) 단일 프로젝트 - 가상 네트워크 어플라이언스를 사용하는 VPC 간 레이어 7 트래픽 검사

DMZ(Untrusted) VPC와 내부 서비스 VPC 및 온프레미스와의 연결 사이에 가상 네트워크 장비(Virtual Appliance)를 두어 L7 레이어의 트래픽을 검사, 방어 및 라우팅을 하도록 구성하는 것입니다. 이는 DMZ와 내부 네트워크를 분리하는 것이 주 목적으로, 각 VPC 네트워크 사이의 트래픽 전달은 가상 네트워크 장비(NGFW)가 수행합니다.

아래 그림은 단일 프로젝트에서 여러 개의 VPC를 분리하여 NGFW를 구성한 아키텍처입니다. VPC는 각각 외부 트래픽을 처리하기 위한 DMZ VPC, 내부 서비스 용 Shared VPC 그리고 온프레미스 연결을 위한 Hub VPC가 있습니다. 여기서 NGFW는 세 개의 VPC 중간에 위치하여 각 VPC 간의 L7 트래픽을 검사하고 제어하게 됩니다. 구글 클라우드의 Compute VM은 각각의 NIC을 VPC에 할당할 수 있습니다. 따라서 VM에 배포된 NGFW 가상 네트워크 장비는 각 VPC 별로 별도의 NIC를 할당해서 연결하였습니다. NGFW는 High Availability를 위해 복수의 인스턴스를 구성할 수 있으며, 이 경우에는 Instance Group를 사용해서 VM 들을 논리적으로 그룹핑해야 합니다.

위의 그림에서 각 트래픽의 흐름을 살펴보면,

(1)번은 인터넷에서 들어온 트래픽이 서비스 프로젝트의 애플리케이션에 전달되는 과정입니다. 인터넷 트래픽은 GLB의 Frontend를 통해 수신하며, GLB의 Backend인 NGFW를 통해서 Shared VPC로 전달됩니다. 여기서 애플리케이션은 Compute Engine에서 동작 중이며 그것들은 ILB를 통해 연결됩니다. SSL Termination은 GLB에서 발생하게 됩니다.

(2)번은 온프레미스에서 들어오는 트래픽이 서비스 프로젝트로 전달되는 과정입니다. Hub VPC에서는 ILB를 통해서 NGFW Instance Group에 요청이 전달되고, 여기서부터는 (1)과 마찬가지로 NGFW에 의해 Shared VPC를 거쳐 Service Project로 전달됩니다.

인터넷에서 들어온 트래픽이 클라우드 내의 서비스 대신 온프레미스로 전달되는 과정입니다. NGFW는 외부 트래픽을 Hub VPC로 보내고 여기서는 ILB의 Backend에 연결된 Hybrid NEG를 통해 온프레미스로 연결됩니다. 반대로 Service Project에서 온프레미스로 연결하는 과정은 Compute Engine ⇒ Shared VPC의 ILB ⇒ NGFW Instance Group ⇒ Hub VPC ⇒ 온프레미스 과정이 됩니다.

(3)번은 온프레미스에서 클라우드 내부 Shared VPC에 배포된 Managed Service에 트래픽이 전달되는 과정입니다. 앞서 단일 VPC나 VPN을 통해 VPC가 분리된 경우 트래픽을 전달하는 경우를 살펴 보았는데, 여기서는 NGFW가 온프레미스의 트래픽을 Managed VPC로 전달하는 역할을 합니다. 이 때, NGFW는 1번 NIC가 Shared VPC 내에서 동작하고 있기 때문에 Shared VPC에 VPC Peering으로 연결된 Managed Service에 문제 없이 트래픽을 전달할 수 있습니다.

만약 여기서 3-(6)에 언급된 의사 판단 과정 중에서 SSL 가상 어플라이언스를 Active/Standby 형태로 이중화를 하려면 아래와 같이 GLB를 NLB로 바꿔야 합니다. GLB를 NLB로 변경한 경우, 트래픽을 살펴보면,

(1)번에서 인터넷 트래픽은 NLB의 Frontend를 통해 수신하며, NLB의 Backend인 가상 네트워크 장비(NGFW)의 Instance Group을 통해 Shared VPC로 전달됩니다. SSL Termination은 NGFW에서 발생하게 됩니다.

(2), (3)번은 위에서 설명한 GLB인 경우와 동일합니다.

(4)  프로젝트 분리 - Untrusted, Trusted VPC 간 다른 거버넌스 체계

다음과 같은 요구사항에 대해 관리 주체가 다른 경우입니다.

Untrusted(DMZ) VPC와 Trusted(Internal) VPC의 관리 주체가 다릅니까?

이 경우에는 외부에서 트래픽이 유입되는 DMZ(Untrusted) VPC와 서비스를 위한 Host Shared VPC가 별도의 프로젝트에서 동작합니다. 3-(1)에 언급한 것처럼 하나의 프로젝트에 VPC를 다르게 구성해도 동일한 IAM의 계정과 권한을 공유하기 때문에, 관리자는 프로젝트에 속한 모든 VPC 네트워크를 접근하고 변경할 수 있는 권한을 가지게 됩니다. 하지만 프로젝트가 분리된 이 아키텍처에서는 각각에 VPC를 다음과 같이 배치하였습니다.

• Hub 프로젝트에 DMZ VPC (다른 프로젝트의 VPC 연결을 위한 Transit VPC 포함)
• Host Project에 Service 프로젝트를 위한 Shared VPC
• Hybrid 프로젝트에 온프레미스 연결을 위한 Hybrid VPC

따라서 각 VPC는 서로 다른 IAM 계정과 권한을 사용할 수 있고, 서로 다른 관리자를 각각의 VPC에 배정할 수 있습니다.

이러한 아키텍처는 주로 금융업처럼 업계의 보안 규정이 특수한 요구사항(예: 망분리)을 충족해야 하는 경우에 사용합니다. 특히 해당 보안 규정에서는 3-(3)에 언급된 것처럼, 외부 트래픽이 들어오는 DMZ VPC와 서비스를 처리하는 내부 서비스 VPC 사이에 L7 트래픽을 검사하는 요구사항도 포함되어 있습니다. 따라서 이 글에서 기본적으로 프로젝트를 분리한 요건에서는 VPC 사이에 가상 네트워크 어플라이언스(NGFW)가 배포하는 아키텍처를 제시할 것입니다. 혹시 네트워크 어플라이언스가 불필요한 경우가 있다면 4-(1)에 제시된 내용들을 참고하여 구성하기 바랍니다.

본 아키텍처는 단일 아키텍처를 채택한 4-(3)과 유사하지만 다음과 같은 차이 및 특징들이 있습니다.

• 기본적으로 관리자를 분리해야 하는 네트워크(VPC)는 서로 다른 프로젝트에 배치합니다.
• 가상 네트워크 어플라이언스가 여러 VPC에 동시에 연결(실제로는 각 VPC를 NIC로 지정)이 되고 그들 사이에 트래픽을 전달할 수 있지만, 프로젝트가 분리되어 있는 VPC에 트래픽을 전달하기 위해서는 3-(5)에 언급된 VPC 간 연결을 위한 방안(VPC Peering 또는 VPN)이 필요합니다. (Transit VPC와 대상 VPC 사이)

(5)  프로젝트 분리 - VPC Peering을 이용한 VPC 간 연결

아래는 Hub, Hybrid, Service 프로젝트(VPC) 간 연결을 VPC Peering을 사용한 아키텍처입니다.

각 VPC 간 통신 과정에 대해 살펴봅니다.

DMZ VPC(인터넷 트래픽) to Host Shared VPC(Service Project)

• 인터넷 ⇒ External NLB(DMZ VPC) ⇒ Virtual Appliance(Instance Group) ⇒ Transit VPC ⇒ VPC Peering ⇒ Host Shared VPC ⇒ Service Project의 Compute Engine VM

인터넷으로 들어온 트래픽은 DMZ VPC의 External NLB를 통해 가상 네트워크 어플라이언스가 들어 있는 Instance Group을 호출합니다. 3-(6)에 언급한 것처럼 NLB를 사용하게 되면 SSL Termination은 네트워크 어플라이언스에서 해야 합니다. 어플라이언스는 트래픽을 nic1이 속한 Transit VPC에 VPC Peering으로 연결된 Host Shared VPC로 트래픽을 보낼 수 있습니다. 그러면 Service Project의 Compute Engine은 Shared VPC에 배포되어 있으므로 트래픽을 바로 받을 수 있습니다.

Hybrid VPC(온프레미스) to Host Shared VPC(Service Project)

• 온프레미스 ⇒ Interconnect ⇒ Hybrid VPC ⇒ Internal NLB ⇒ Virtual Appliance(Instance Group) ⇒ Transit VPC ⇒ VPC Peering ⇒ Host Shared VPC ⇒ Service Project의 Compute Engine VM

온프레미스에서 보낸 트래픽은 Interconnect를 통해 Hybrid VPC에 도착합니다. Hybrid VPC와 Hub 프로젝트의 Transit VPC와 VPC Peering으로 연결되어 있으므로 트래픽이 전달되어 가상 네트워크 어플라이언스로 전달됩니다. 그 이후 과정은 인터넷 트래픽과 마찬가지 과정을 거쳐 Compute Engine에 전달됩니다. 반대로 Service Project에서 보낸 요청도 온프레미스에 전달이 가능합니다.

다만, 온프레미스에서 Managed Service에 접속하기 위해서는 Transit VPC의 요청이 VPC Peering을 통해 전달된 Host Shared VPC에서 다시 Peering을 통해 전달되어야 하지만, 그것은 3-(5)에 언급한 것처럼 불가능합니다. 따라서 이러한 요구사항을 위해서는 VPN을 사용하거나 5장에서 설명할 PSC를 사용해야 합니다.

위에서 제시했던 아키텍처는 DMZ, Service와 함께 온프레미스 연결을 위한 Hybrid VPC도 별도의 프로젝트에서 관리했다. 하지만 만약 동일한 관리자가 DMZ와 Hybrid VPC를 관리한다면 아래와 같이 Hybrid VPC를 Hub Project 안에 넣을 수 있습니다. VPC 간 통신 기능에는 차이가 없습니다.

(6)  프로젝트 분리 - VPN을 이용한 VPC 간 연결

4-(5)에서 제시한 아키텍처에서 VPC 간 연결 방법을 3-(5)에 제시한 방법 중에서 VPN을 사용한 경우입니다. 4-(5)에서는 온프레미스 요청이 Managed Service에 전달될 수 없었으나, 여기서는 Transitive Peering이 가능한 VPN을 사용했기 때문에 전달이 가능합니다.

(7) 구글 클라우드 Public Web Page에 제시된 아키텍처에 대한 추가 설명

본 문서는 최대한 구글 클라우드의 웹페이지에 언급된 개념, 방법, 용어 등을 그대로 사용하였습니다. 다만, 업종별로 상이한 요건이나 국가별 규정에 따른 추가적인 요건을 만족할 수 있게 다음 부분을 추가하였습니다.

• 거버넌스 체계 분리를 위한 프로젝트의 분리
• Virtual Network Appliance(NGFW)에 대한 구현 방법 상세화
• Transitive VPC 구현을 위한 방안으로 VPC Peering, VPN, PSC에 대한 차이점 설명

5. Private Service Connect 사용

PSC(Private Service Connect)에 대한 상세한 설명은 다음 문서를 참고하기 바랍니다.

Private Service Connect | VPC | Google Cloud (한국어)

PSC는 기본적으로 VPC 내부에 있는 서비스를 외부에서 액세스할 수 있게 연결 지점(endpoint)을 제공하는 서비스입니다.통상은 Cloud SQL 등과 같은 관리형 서비스를 VPC 외부에서 액세스할 수 있게 할 때 사용할 수 있지만, 다음과 같은 다양한 서비스들을 지원하고 있습니다.

• Google APIs
• Google services (관리형 서비스. 예: Cloud SQL)
• Third-party services (예: 마켓플레이스 솔루션)
• Intra-org services (사용자 제작 애플리케이션. 예: VM에서 운영하는 HTTP 서버)

위의 그림에서 Producer VPC에 있는 다양한 서비스들을 Consumer VPC에서 액세스할 수 있게 하는데, Consumer 입장에서는 Endpoint를 보고 호출하고 이 요청은 PSC를 통해 대상 서비스에 전달됩니다. 이 때, VPC는 반드시 동일한 프로젝트나 조직(organization)이 아니어도 상관 없습니다..

이러한 특성으로 인해 VPC Peering이 제공하고 있는 다른 VPC 간 통신 기능을 구현할 수도 있습니다. 하지만, PSC는 VPC Peering과 달리 VPC의 모든 트래픽을 전달하는 것이 아니라 특정 서비스를 명시적으로 지정하여 해당 서비스와의 단방향 통신만 가능합니다. 4-(5)나 4-(6) 섹션에서 언급한 VPC 간 통신에 PSC를 적용한다면, 명시적으로 Producer VPC(Host VPC)의 특정 서비스(예: Instance Group, GKE 서비스)를 VPC Peering이나 VPN 구성 없이 Untrusted VPC나 온프레미스에서 호출할 수도 있습니다. 다음 그림은 VPC Peering과 PSC와의 차이를 설명한 것입니다.

다음은 VPC Peering 대신 PSC를 사용하여 Service Project에 위치한 Managed Service를 Endpoint로 연결한 아키텍처입니다. 이와 같이 구성하면 4-(5) 섹션에서 VPC 간 연결 방법에 제시된 Peering이나 VPN 대신 PSC를 사용할 수 있습니다. 다만, PSC는 앞에서도 말한 것처럼 단방향 연결이고 명시적으로 특정 서비스에 대한 연결을 만들고 관리해야하는 번거로움이 있음을 감안해야 합니다. 그럼에도 불구하고 VPC 간 Transitive Peering이 필요한 경우 하나의 대안이 될 수 있습니다.

6. 3rd Party NGFW(Virtual Network Appliance) 구성

구글 클라우드에서는 마켓플레이스를 통해 다양한 3rd Party NGFW(Virtual Network Appliance)를 선택할 수 있습니다. 이 중에 Palo Alto의 구글 클라우드 배포 아키텍처는 다음 문서에 잘 나와 있으니 참고하기 바랍니다.