GCP에서 VPC Peering을 구성하는 방법 (GCP VPC network Peering)

 

 

여러 개의 GCP VPC를 운영하다 보면 통신하고 있는 GCP VPC 간의 Latency가 만족스럽지 못하거나 보안상의 이유로 패킷이 Public으로 가지 못하도록 하고 싶을 경우가 있을 것입니다.

 

GCP VPC간의 통신을 하고자 하는데 왜 Public internet으로 패킷을 보내야 하지? 라는 의문이 들었던 적이 있었다면, VPC Peering을 통해 이 문제를 해결할 수 있습니다.

 

Peering이란 두 개의 단절된 Network 환경 간에 전송되는 Traffic을 Public으로 보내지 않고 곧바로 상대의 Network 환경으로 보내는 연결 방식입니다.

 

더 자세히는 Network간에 통상적인 Transit 전송을 이용하지 않고 IXP(Internet exchange point)를 이용한 전송을 사용함으로써 Provider의 간섭 없이 Traffic 교환을 하는 방식입니다. 

 

Peering을 구성할 시에는 서로의 Network를 수 많은 경로를 거치지 않고 곧바로 접속할 수 있기 떄문에 많은 이점을 누릴 수 있습니다. 그 이점들이란

 

1) Traffic이 Public internet을 지나지 않기 떄문에 Latency를 감소시킬 수 있습니다.

2) 마찬가지의 이유로 GCP에서 Public으로 나가는 Traffic에 부과되는 Egress 비용을 절감할 수 있습니다.

3) Private IP를 이용해 통신하기 때문에 Network 보안성을 높일 수 있습니다.

 

본 포스팅에서는 위의 이점들을 활용하기 위해 GCP의 Peering인 GCP network peering을 구성하는 방법에 대해서 알아봅니다.

 

 

1. Peering을 구성하기 전에 필요한 환경

 

 

본격적으로 VPC Peering을 구성하기 전에 점검해야 할 Network 환경이 있습니다.

 

VPC Peering은 각자의 Subnet 경로를 교환하기 때문에, 두 VPC Subnet의 IP address 범위가 겹쳐서는 안됩니다.

 

특별한 경우가 아니라면 GCP의 VPC 환경을 이용할 때 자동으로 생성된 Auto mode의 VPC를 사용하는 경우가 많기 때문에 위의 이유로 Peering 구성에 실패하는 경우가 많습니다.

 

위와 같이 두 VPC의 IP address range가 겹친다면 Peering을 구성할 수 없다.

 

Peering을 성공적으로 구성하려면 두 VPC 중 하나는 Auto Mode가 아닌 Custom Mode로 생성해 Peering할 VPC와 겹치지 않는 IP address 범위를 지정해야 합니다.

 

서로 다른 IP range를 사용하는 Subnet으로 구성해야 한다.

 

 

위와 같이 새로운 range의 IP address를 지정한 VPC를 구성했다면 Peering을 구성할 준비가 되었습니다.

 

주의해야 할 점이 있다면 Peering을 성공적으로 구성한 후에도 Subnet을 확장할 때 IP address range가 중복되서는 안된다는 것입니다.

 

위에서 언급했다시피 VPC Peering은 subnet 라우팅 경로를 교환하기 때문에 경로의 교환 중 IP range의 중복 시 VPC간 Traffic 라우팅에 혼동이 오기 때문입니다.

 

GCP Document 발췌, 이미 Peering된 VPC network라도 Subnet Ip address가 중복된다면 정상적인 통신이 이루어지지 않는다.

 

 

2. Peering 구성 방법

 

 

겹치지 않는 IP address range를 지정한 Custom mode의 VPC.

 

위의 글에서 언급한 주의사항을 준수한 환경이 준비되었다면 이제 VPC Peering을 구성할 수 있습니다.

 

본 포스팅에서는 GCP Project 생성 시 기본적으로 주어지는 default VPC와 직접 Ip address를 지정한 subnet으로 구성된 Custom mode VPC 간의 Peering을 시도하겠습니다.

 

 

GCP web console의 메뉴 -> Networking -> VPC network -> VPC network peering 순으로 진입.

 

VPC peering을 구성하기 위해 우선 Web console의 VCP network peering 탭으로 진입합니다.

 

진입하면 나오는 페이지에서 새로운 Peering 생성을 클릭해 VPC Peering 생성 페이지로 진입합니다.

 

VPC Peering 생성 페이지, 다양한 설정으로 구성할 수 있다.

 

VPC Peering 생성 페이지는 위와 같은 구조를 가지고 있습니다. 여기서 적절한 설정을 통해 VPC Peering을 생성할 수 있습니다.

 

빨간 박스의 가장 위부터 설정의 설명입니다.

 

1) Your VPC network : 지금 Peering을 구성하고 있는 환경의 VPC에서 Peering할 VPC를 선택합니다. 이번 경우에는 기본적으로 생성된 VPC를 사용하는 환경에서 Peering을 구성하고 있으므로 "default" VPC를 선택합니다.

 

2) Peered VPC network : 위에서 선택한 VPC와 Peering할 상대 VPC를 선택합니다. 현재 Project의 내/외부를 선택하고 VPC의 이름을 정확히 입력합니다.

 

3) Exchange custom routes : Custom routing 경로를 설정했을 시 그 경로를 내보낼지, 들여올지 선택하는 설정입니다. VPC tunnel이나 Interconnect를 위해 사용하는 custom routing 경로를 사용하고 있다면 이 설정을 통해 해당 경로를 공유할 수 있습니다.이번 경우에는 어떠한 custom routing 경로도 없으므로 체크를 둘 다 해제합니다.

 

위의 설정을 마치고 난후 생성 버튼을 누르면 VPC Peering 리스트에 생성한 Peering이 추가된 것을 볼 수 있습니다.

 

다만 Status가 노란색의 "inactive" 로 되어 있을 것입니다.

 

VPC Peering은 한 VPC 구성원이 아닌 양자가 Peering을 구성한 상태여야만 정상적으로 작동하기 때문입니다.

 

Peering할 상대 VPC 환경에서도 위와 같이 적절한 설정으로 VPC Peering을 생성하먼 Peering status가 active되며 Peering 통신을 할 수 있습니다.

 

두 VPC의 Peering이 정상적으로 생성되었다면 위와 같이 Status가 Active된다.

 

 

 

3. Peering으로 통신해보기

 

Peering을 성공적으로 구성했다면 이제 실제로 Private IP를 통해 통신할 수 있는지 테스트해봐야 합니다.

 

하지만 Peering을 구성한 직후 VM간 통신을 시도해보면 Traffic이 정상적으로 가지 않는 것을 알 수 있습니다.

 

아직 상대 IP address에서 오는 Traffic의 firewall allow rule을 설정하지 않았기 때문입니다.

 

Peering된 VPC 환경이라도 Firewall rule은 각자 개별적으로 적용되기 때문에 두 VPC 환경에서 Firewall 설정을 완료해야 합니다.

 

VPC Peering을 완료한 상태라도 Firewall allow rule을 설정해야 통신할 수 있다.

 

Firewall 설정을 마친 뒤 Peering된 두 VM간의 통신을 Test하기 위해 어떤 경로로 패킷을 전송하는지 보겠습니다.

 

아래는 Auto mode VPC 내부의 Internal IP:10.177.0.3 -> Custom mode VPC 내부의 Internal IP:10.178.15.198로 통신을 시도한 결과입니다.

 

traceroute를 통해 10.177.0.3 VM에서 10.178.15.198 VM으로 Traffic 경로를 분석한 결과, 하나의 홉(IXP)만 지난 뒤 바로 Traffic이 가는 것을 확인할 수 있다.

 

Peering이 구성되었으면 위처럼 상대 VM의 Internal IP를 목표로 Traffic을 보냈음에도 정상적으로 Traffic이 전송되는 것을 볼 수 있습니다.

 

더불어 Public internet 통과했다면 여러 개의 홉을 지나서 목표에 도달했을 Traffic이 단 하나의 IXP만을 지난 뒤 바로 상대 VM에 빠르게 도달하는 것을 알 수 있습니다. 

 

이처럼 Peering을 통해 Internal IP로 통신하면 Latency가 획기적으로 감소하게 되는 것은 물론, GCP가 Public egress에 부과하는 비용도 절감할 수 있습니다.

 

 

 

4. Load balancer를 이용한 Peering Traffic의 분산

 

지금까지 본 것처럼 정상적으로 Private IP를 통해 안전하고 빠른 Traffic 전송을 이룰 수 있었습니다.

 

하지만 VPC간의 통신에도 MIG(managed instance group)를 source, destination으로 한다면 Traffic을 분산할 필요가 있을 것입니다.

 

VPC Peering으로 연결된 두 VPC간의 Traffic Load balancing은 평소에 외부의 Traffic의 분산을 담당하던 External LB가 아닌 Internal LB가 할 수 있습니다.

 

이번 장에서는 Peering 환경에서 Internal LB를 이용해 Traffic 분산하는 법을 알아보겠습니다.

 

 

Internal LB를 이용한 Peering VPC Architecture, Firewall 설정에 유의해야 한다.

 

최종적인 Internal LB가 결합된 VPC Peering architecture는 위와 같습니다.

 

VPC B에서 A로 보내는 Traffic을 받아야 하는 상황이라면, VPC A에서 Internal LB를 생성한 뒤,(backend는 Traffic을 받을 MIG로 설정합니다)

 

VPC B는 Internal LB의 IP address로 Traffic을 전송합니다.

 

이론상 이렇게 하면 부하분산이 정상적으로 되어야 하지만 Internal LB에서 health check를 자꾸 failing하게 됩니다.

 

가장 중요한 것은, Firewall rule에서 Internal LB가 사용하는 Proxy subnet의 IP address range를 ALLOW해야 한다는 것입니다.

 

Internal LB는 부하분산에 사용할 LB만의 Proxy subnet을 별도로 할당받기 때문에,

 

Firewall에서 allow하지 않는다면 해당 subnet의 IP address range를 모두 거부하며 VM까지 Traffic이 도달하지 못하게 됩니다.

 

그래서 꼭 proxy subnet의 IP address range를 Firewall allow rule에 추가하고 health check가 정상적으로 이루어지는지 확인해야 합니다.

 

 

5. 최종적으로

 

Health check를 성공했다면 이제 정상적으로 Peering된 VPC간 부하분산이 이루어지게 됩니다.

 

이 구성을 사용할 경우 두 VPC간 통신은 안전하고, 빠를 뿐더러, Load balancer와 결합한 MIG의 이점까지 모두 사용할 수 있는 환경을 사용할 수 있습니다.

 

Peering은 다른 도메인, 조직, 프로젝트에 속하는 VPC에도 구성할 수 있으니 사실상 GCP Network 간의 통신에는 GCP netwrok peering을 이용하는 것이 가장 바람직합니다.

 

본 포스팅을 통해 GCP의 Network 환경을 더 지혜롭게 사용하고자 하는분들께 도움이 되었으면 합니다.