VPC Peering?
AWS, MS Azure, Google Cloud... 퍼블릭 클라우드를 사용해보셨다면
한번 쯤은 들어보셨을 VPC 피어링에 대해 이야기해보고자 합니다.
VPC 피어링이 무엇인지, 어떻게 동작하는지, 그리고 VPC 피어링 사용 시 발생할 수 있는
복잡한 문제들을 네트워크 옵저버빌리티를 통해 해결해나가는 방법에 대해서요.
VPC 피어링은 두 개 이상의 VPC들을 안전하게 연결하는 기술입니다.
AWS에 따르면, VPC 피어링은 "사설 IPv4/IPv6 주소를 사용하여 2개의 VPC 간 트래픽을 라우팅할 수 있도록 2개의 VPC를 잇는 네트워크 연결"입니다.
VPC 피어링으로 연결되면 양쪽 VPC들의 모든 인스턴스들은 마치 동일한 네트워크에 있는 것처럼 서로 통신할 수 있습니다. (ex. 재택근무 시 ERP, 그룹웨어 접속을 위해 VPN을 사용하는 것과 유사합니다)
멀티클라우드 시대가 되어 클라우드의 네트워크 구성도 복잡해짐에 따라, 보안과 성능 관점에서 VPC 피어링을 많이들 사용하곤 합니다.
하지만 VPC 피어링이 많아질수록 관리가 어려워지고, 스파게티 코드와 같은 네트워크 구성 때문에 잠재적인 네트워크 성능 문제들이 발현되기 시작합니다. 😰
결국 위와 같은 문제를 방지하기 위해 VPC 피어링 또한 모니터링해야 할 주요 대상으로 자리하게 되었습니다.
VPC 피어링은 어떻게 동작하는가? (다수의 VPC 연결하기)
VPC(Virtual Private Cloud)는 AWS와 같은 퍼블릭 클라우드 안에서 특정 사용자를 위해 가상으로 격리된 네트워크를 제공해줍니다.
VPC를 사용하면 인터넷을 통하지 않으면서도 애플리케이션 리소스를 퍼블릭 클라우드 안에서 호스팅할 수 있습니다. 따라서 VPC는 퍼블릭 클라우드 안에 사용자 만의 프라이빗한 네트워크를 제공해주는 것이죠. 사용자는 VPC 내부에서만 워크로드가 실행되도록 함으로써 애플리케이션에 대한 보안성을 강화합니다.
모든 워크로드가 1개 클라우드 내에서 실행되는 경우, VPC도 1개만 사용하여 프라이빗 네트워크를 구성하고 필요한 리소스들을 모두 호스팅할 수 있습니다.
하지만 2개 이상의 클라우드를 사용하고 (멀티클라우드) 각 클라우드에 VPC를 설정한 경우에는 어떻게 해야 할까요? AWS와 Azure를 동시에 사용한다면?
이때 VPC 피어링이 등장합니다.
우리는 VPC 피어링을 통해 다수의 클라우드, 다수의 VPC를 Private하게 연결할 수 있게 됩니다. 보안이 취약해질 수 있는, 상대적으로 딜레이가 높은 인터넷을 사용하지 않죠.
클라우드 간 VPC 피어링을 설정하면 서로 다른 퍼블릭 클라우드에서 실행 중인 여러개의 리소스들이 마치 동일한 클라우드에서, 동일한 사설 네트워크에서 호스팅되고 있는 것처럼 서로 통신할 수 있습니다.
VPC 피어링을 사용하는 이유
1. 보안 강화
VPC 피어링의 가장 크고 확실한 장점은 보안입니다.
VPC 피어링이 없다면 다수의 클라우드에서 실행되는 워크로드는 인터넷을 통해 통신해야 합니다.
인터넷을 통해 다이렉트로 통신한다는 것은 데이터 유출 가능성을 크게 증가시킬 수 있기에 사이버 보안의 기본 사항으로 금기하는 통신 방법입니다.
그러나 VPC 피어링을 사용하면 VPC 간 사설 네트워크 통신이 되어 인터넷에 노출되지 않도록 하죠.
(LAN 통신을 하는 것과 비슷합니다)
2. 네트워크 지연시간(Latency) 감소
VPC 피어링은 인터넷을 통해 트래픽을 라우팅할 필요가 없으므로 네트워크 Latency를 크게 줄일 수 있습니다. 따라서 VPC 피어링을 사용하면 네트워크 성능이 많이 향상될 수 있습니다.
(핸드폰에서 사진을 보낼 때 카카오톡이 아이폰 AirDrop 보다 느린 이유도 이와 같은 원리입니다)
3. 네트워크 비용 절감
퍼블릭 클라우드 제공업체는 인터넷을 통해 전송하는 데이터보다,
VPC 피어링을 통해 전송하는 데이터에 대해 더 낮은 요금을 부과하는 경우가 많습니다.
그래서 VPC 피어링을 사용하면 클라우드에서 발생하는 트래픽 요금을 절감할 수 있습니다.
VPC 피어링의 한계점
1. Connection 수 제한
CSP(Cloud Service Provider)는 개별 VPC마다 VPC 피어링 수에 제한을 두고 있습니다.
AWS의 경우, 기본 할당량은 50 Connection이고, 125개까지 확장할 수 있다고 합니다.
2. CIDR Block 중복 불가
IPv4/IPv6 CIDR Block이 같거나 일부분이 겹치는 VPC끼리는 VPC 피어링 사용이 불가합니다.
3. 피어링 된 트래픽의 트랜짓 불가
VPC 피어링은 트래픽 Transit을 지원하지 않으므로 피어링 된 다른 VPC를 통해 트래픽을 라우팅할 수 없습니다. 따라서 연결이 필요한 모든 VPC들을 1대1로 연결하고 VPC 피어링으로 거미줄 같은 네트워크 Mesh를 구성해야 합니다.
4. Edge-to-Edge 라우팅 불가
트래픽 트랜짓이 불가하기에 생기는 한계점입니다. 1번 VPC의 리소스는 2번 VPC의 IGW, NAT GW, S2S VPN, Direct connect, GW Endpoint 모두 사용할 수 없습니다.
5. Multi-region VPC 피어링 제약
서로 다른 Region에 있는 VPC 간 피어링을 사용하게 되면,
Security Group에서 Peer VPC의 Security Group을 참조하거나,
데이터 전송 시 Jumbo Frame(MTU 최대 9001 byte)을 사용할 수 없는 등 제한 사항들이 있습니다.
또 Peer VPC의 Private host name을 Private IP 주소로 확인하려면 DNS 추가 옵션을 설정해야만 합니다.
6. IPv6 제한
EC2-Classic에서는 IPv6가 지원되지 않기에, IPv6를 활용한 VPC 피어링 또한 불가합니다.
VPC 피어링과 네트워크 옵저버빌리티
VPC 피어링은 클라우드 네트워킹의 보안성과 성능을 향상시키는 데 도움이 될 수 있습니다.
하지만 동시에 네트워크 아키텍처를 또 한번 복잡하게 만듭니다.
그래서 IT팀은 네트워크 옵저버빌리티를 통해 이런 복잡성을 관리할 수 있어야 합니다!
그래야 VPC 피어링 문제로 인해 네트워크가 다운되거나 성능이 저하되지 않을 수 있으니까요.
VPC 피어링은 피어링 Mesh와 같은 매우 복잡한 네트워크 아키텍처를 구성하기 때문에, 잠재적인 이슈가 다수 발생할 수 있고, 문제의 원인을 정확히 파악하는 데에도 수 많은 시간을 쏟아야 할 수 있습니다.
예를 들어 VPC 피어링과 같이 라우팅 테이블을 수동으로 변경하게 되면, 트래픽이 최적의 경로를 찾지 못하는 라우팅 문제로 이어질 수 있습니다.
이때 클라우드 A에서 네트워크 서비스 성능이 저하될 시 클라우드 A의 VPC와 더불어,
피어링이 맺어진 클라우드 B의 VPC까지도 네트워크 성능 저하를 경험하게 될 수 있습니다.
문제를 더욱 복잡하게 만드는 것은 사용자가 VPC 피어링 성능을 추적하고 관리할 수 있도록 지원하는 CSP 자체적인 기능이 거의 없다는 점입니다.
(Cloudwatch..? 흠..)
CSP들은 고객이 클라우드에서 실행하는 네트워크 리소스의 성능만 관리할 수 있도록 지원하는데 집중합니다.
예를 들어, AWS 서비스들은 Azure에서 실행 중인 Peer VPC의 문제를 해결하는 데 거의 아무런 도움이 되지 않습니다. AWS는 AWS에서 실행되는 VPC의 성능만 추적하기 때문이죠.
즉, VPC 피어링을 사용하게 되면 그 복잡성으로 인해 발생하는 모든 잠재적인 문제들을 관리해야 하는 부담이 생기게 됩니다.
하지만 네트워크 옵저버빌리티 플랫폼은 그 부담을 덜어드립니다.
네트워크 옵저버빌리티는 VPC Flowlog와 같은 네트워킹 데이터를 수집한 다음, 다양한 데이터와 연계하고, 유저의 비즈니스에 적합한 Context를 부여하여 모든 VPC의 네트워킹에 대한 가시성을 통해 네트워크 분석, 리포팅, 데이터에 의거한 의사결정까지 제공하니까요.
네트워크 옵저버빌리티 솔루션 Kentik의 경우 AWS, MS Azure, GCP, OCI, IBM Cloud까지 지원하여 멀티클라우드의 VPC 간 네트워킹 관리에 있어 완전히 새로운 경험을 선사합니다.
좀 더 자세히 말해볼까요.
네트워크 옵저버빌리티는 VPC를 호스팅하는 모든 클라우드의 Flow log, Latency metrics, Synthetic test 등 다양한 데이터를 분석하여 VPC 피어링 관점에서 발생할 수 있는 네트워킹 이슈들을 식별하고 이해한 다음, 해결할 수 있게 돕습니다.
이로써 사용자는 VPC 피어링 이슈의 원인이 되는 클라우드가 어디인지, 구성에 문제는 없는지 추적할 수 있겠죠.
네트워크 옵저버빌리티를 활용하면 VPC 피어링의 이점을 완벽하게 사용할 수 있게 됩니다.
VPC 피어링을 통해 보안, 비용, 성능 모든 부분에서 효율성을 높이되
VPC 피어링의 복잡성으로 인한 문제들은 네트워크 옵저비빌리티를 통해 해결하는 거죠.
마치며
읽어주셔서 감사합니다.
네트워킹 기술과 시장에 대한 소통, 언제나 환영합니다! 🙌
Coffee chat 신청하기
메모 남겨주시면 간단한 커피챗을 통해 저희 팀의 경험을 공유해드릴게요 😊
에어키는 네트워크 옵저버빌리티 플랫폼, kentik의 파트너로 활동하고 있습니다.
문의처 - 에어키 MSP팀 김상휘 프로 (shkim0730@airquay.com, +82-10-2914-9400)
이 글은 kentik의 kentipedia 문서의 번역/수정본이며 오역이 있을 수 있습니다. (출처)
