클라우드 비용 최적화 로드맵 #5 - 네트워크의 단가를 최적화하는 법

여는 말

안녕하세요. SK텔레콤 최준승입니다. 오늘은 연재 다섯 번째 시간입니다. 단가 편으로는 세 번째 시간이고요. 오늘의 주제는 네트워크의 단가를 최적화하는 법입니다. 지난 회차는 분량 조절에 실패했기 때문에 이번 회차는 핵심 메시지 위주로 간결하게 진행하겠습니다.

클라우드 환경의 네트워크 비용은 컴퓨팅이나 스토리지의 비용에 비해 관리하기가 어렵습니다. 어려운 이유는 크게 3가지 정도가 있는데요. 첫 번째, 기본적으로 네트워크 구간별 단가 구조가 복잡합니다. 두 번째는 네트워크 구간을 구성하는 주체(Server, Storage, Gateway, Edge 등)가 On-Premise에 비해 다양한 위치에 분산되어 있습니다. 이것이 복잡한 단가 구조와 결합해서 현재 네트워크 비용을 파악하는 난이도를 높이게 되고요. 특히 Multi-Account 환경이거나 VPC별로 연동 구간이 복잡한 경우 CUR 데이터로부터 완벽한 비용 가시성을 확보하기 쉽지 않습니다. 세 번째는 On-Premise와 비교되는 특성은 아니고, 외부향으로 열려있는 서비스가 공통적으로 갖고 있는 문제인데요. Ingress/Egress 같은 네트워크 구간의 사용량이 가변적이라는 점입니다. 구간별 단가는 고정되어 있지만 사용량이 가변적이기 때문에, 전체 비용을 정확하게 예측하기 어렵습니다. 상대적으로 저렴하지 않은 클라우드 네트워크 단가를 감안하면, 갑자기 서비스의 규모가 급증했을 때 비용의 증가폭이 예상보다 클 수 있습니다.

오늘의 주제는 네트워크의 "단가"를 최적화하는 법입니다. 그래서 먼저 AWS 기준으로 구간별 네트워크 단가 구조부터 알아볼 것이고요. 각 구간별로 경로를 어떤 식으로 재설계하여 단가를 최적화할 수 있는지 예시 기반으로 설명해 드리겠습니다. 그리고 전체 비용 데이터로부터 네트워크 비용을 어떻게 작은 단위로 구분해서 볼 수 있는지도 틈틈이 팁을 드려 보겠습니다.

클라우드의 Network 과금 정책은 복잡하다

• 출처: https://www.duckbillgroup.com/blog/understanding-data-transfer-in-aws/

위 그림은 어떤 회사에서 그린 AWS의 네트워크 단가 표입니다. 다양한 유형의 객체들(EC2, RDS, S3 등)이 다양한 위치(Same AZ, Inter-AZ, Inter-Region, Internet 등)에서 다양한 구간(Same VPC, Inter-VPC, VPN, D/X, Peering 등)을 거쳐 통신할 수 있습니다. 여기서 자원 / 위치 / 구간의 조합에 따라 GB당 네트워크 단가가 달라집니다. 이것을 좀 더 단순한 레벨로 추상화 시키기 위해 아래처럼 그림을 그려봤습니다.

일단 AWS 환경에 하나의 Region이 있습니다. 그리고 Region 안에는 복수의 AZ가 있습니다. 이 AZ는 IDC와 비슷한 개념입니다. AZ 간에는 기반 인프라를 공유하지 않으며 상호 독립적으로 구성되어 있습니다. VPC는 복수의 AZ에 걸쳐 만들 수 있습니다. VPC Subnet은 하나의 AZ 안에 구성됩니다. AWS에 익숙한 분들이시라면 모두 이미 아는 내용들입니다.

이 그림을 바탕으로 각종 AWS 서비스 객체를 여기저기 옮겨가면서 오늘 이야기를 풀어보려고 합니다. 객체 간의 위치에 따라 해당 네트워크 구간이 유료인지 무료인지, 유료라면 단가는 어떻게 다른지, 그 단가를 최소화하기 위해서 어떤 대안들이 있는지를 크게 3가지 상황으로 나눠서 설명하겠습니다.

Case1. VPC 내부 통신

첫 번째 Case는 VPC 내부 통신입니다. 설명 편의상 해당 VPC는 2개의 AZ에 걸쳐 서브넷을 구성했다고 가정하겠습니다. 위 그림처럼 AB와 AC 두 개의 구간이 있다고 할 때, 어느 구간이 유료이고 어느 구간이 무료일까요? 앞서 AZ가 IDC와 비슷한 개념이라는 말이 힌트입니다.

맞습니다. AB 구간은 무료이고, AC 구간은 유료입니다. 즉, 동일 AZ 간 통신은 기본적으로 무료입니다. 동일한 Region이라고 해도 타 AZ 간 통신은 유료입니다. 왜냐하면 서로 다른 IDC에 위치한 객체 간 통신이기 때문입니다. A와 C 입장에서 "각각" Ingress/Egress 비용이 과금됩니다. 물론 일부 예외도 있습니다. RDS 같은 DB 계열 서비스에서 동일 클러스터 간 데이터 복제에 사용되는 Inter-AZ 통신은 과금하지 않습니다.

네트워크 단가를 고려하면 동일 AZ 간 통신은 지향하고 타 AZ 간 통신은 지양하는 것이 정답입니다. 하지만 이것은 기본적인 원칙일 뿐, 이것을 실현하는 방법은 좀 더 복잡합니다. 서비스 가용성이나 다른 가치를 동시에 고려해야 하기 때문입니다. 오늘은 이런 복합적인 고려가 필요한 몇 가지 상황을 살펴보도록 하겠습니다. 참고로 이번 단락에서는 철저히 VPC 내부 통신을 기준으로만 설명하겠습니다.

첫 번째 상황은 NAT Gateway의 배치 건입니다. NAT Gateway의 시간(Hour) 비용이 아까웠던 최 모 씨는 1개의 AZ에만 NAT Gateway를 배치하기로 합니다. 1번 AZ에 전체 장애가 날 경우 NAT Gateway를 거치는 Egress 트래픽에 문제가 생길 것이라는 지적사항이 있었지만 무시했습니다. 해당 구간은 직접적인 서비스와는 무관한 관리 영역(패치 파일 다운로드 등)의 트래픽이었기 때문입니다. 하지만 몇 달 뒤 네트워크 비용을 확인해 보니 타 AZ 간 트래픽 요금이 크게 늘어난 것을 확인했습니다. 또 그중 대부분은 타 AZ 간 EC2 - NAT G/W 간 통신임을 알게 되었습니다.

이 경우에는 어떤 대안이 있을까요? 간단합니다. 위와 같이 2번 AZ에 NAT G/W를 추가적으로 구성하고, EC2가 구성된 Subnet에는 동일 AZ의 NAT Gateway로 라우팅 되도록 각각 설정하면 됩니다. 이때 추가되는 비용은 2번 NAT G/W 시간(Hours) 비용입니다. NAT G/W에서 부과되는 Processing 비용은 분산되므로 결국 총합은 동일합니다. 예를 들어 NAT G/W의 시간(Hours) 추가 비용이 월 $50이고, 조정을 통해 절감한 Inter-AZ 비용이 월 $950라면 결과적으로 월 $900를 절감할 수 있게 됩니다.

두 번째 상황도 비슷한 상황인데요. ElastiCache 노드의 배치 건입니다. 아래 그림처럼 ElastiCache를 단일 노드로 구성했다고 가정해 보겠습니다.

이 경우에도 ElastiCache 노드가 하나기 때문에, 캐시 노드 1개의 비용만 지불하면 되는 장점이 있습니다. 처음에는 네트워크 비용도 크게 이슈가 없었으나, 서비스 사용자 수가 점점 늘어남에 따라 캐시 노드에서 읽어가는 읽기 부하도 동시에 증가했습니다. 이에 비례하여 타 AZ에 위치한 EC2(B)와 ElastiCache 노드 간 트래픽 비용도 늘어났습니다.

이를 해결하기 위해 2번 AZ에 읽기 전용 복제본을 추가 구성하였습니다. 이때 늘어난 비용과 줄어든 비용은 어떻게 될까요? 늘어난 항목은 1) Read Replica의 노드 비용입니다. 줄어든 항목은 2) 타 AZ 간 읽기에 소요된 트래픽 비용입니다. 타 AZ 간 쓰기에 소요된 비용은 변함이 없습니다. 더불어 Primary 노드와 Read Replica 간 복제에 소요되는 비용은 무료이므로 전체 비용에 가산되지 않습니다. 결국 2)의 절감분이 1)의 증가분보다 클 경우, Read Replica 추가 구성안은 비용 측면에서 정답이 됩니다. 물론 가용성이나 성능 측면에서도 추가적인 이점이 있을 수 있겠네요.

이외에도 AZ 간 트래픽을 최소화하는 다양한 전략들이 있습니다. 예를 들어 상호 통신이 많은 컴포넌트들을 의도적으로 동일한 AZ에 배치한다거나, k8s 환경에서 Topology Aware Hint 같은 기능을 적용하여 동일 AZ에 위치한 Pod와 통신하도록 유도할 수 있습니다. 개발/스테이지처럼 AZ 레벨의 가용성을 고려할 필요 없는 환경에서 모든 객체를 하나의 AZ로 몰아넣는 방안도 고려해 볼 만합니다. 다만 Multi-Account 환경에서 복수의 VPC 간 연동 구간이 있는 경우 동일한 AZ를 식별하는데 약간의 수고(?)가 필요할 수도 있습니다.

이때 가장 중요한 시작점은 현재 과금을 제대로 이해하는 것입니다. 예를 들어 AWS의 CUR 데이터 기준으로 UsageType 중 [Region]-DataTransfer-Regional-Bytes 항목을 보면 해당 Region의 AZ 간 통신 비용을 확인할 수 있습니다. 위 참고 그림과 같이 해당 항목을 필터링 기준으로 설정한 후에, Operation이나 Name Tag 값 기준으로 구분해서 보면 좀 더 높은 가시성을 확보할 수 있습니다. 물론 비용 데이터 외에도 VPC Flow Log나 다른 모니터링 솔루션을 통해 구간별 트래픽량을 산정할 수도 있습니다. 결국 중요한 것은 과금이 발생할 만한 구간을 데이터를 통해 인지하고, 기술적인 장단점을 함께 고려해서 개선사항을 시뮬레이션하고, 실제 반영 후에 해당 비용이 줄었는지를 정확하게 비교할 수 있어야 합니다.

Case2. VPC 내-외부 통신

두 번째 Case는 VPC 내-외부 통신입니다. 이번 Case에서 다룰 부분은 인터넷 구간은 제외하고 동일 Region 내에서 VPC 내-외부를 오가는 AWS 서비스 간 통신으로 범위를 제한하겠습니다. 예를 들어 VPC 내에 있는 EC2와 VPC 외에 있는 S3 같은 서비스 간 통신이 해당됩니다. 참고로 S3와 비슷한 영역에 위치한 서비스는 DynamoDB, Kinesis, ECR, SNS 등이 있습니다.

먼저 일반적인 Public Subnet의 구성과 Private Subnet의 구성을 살펴보겠습니다. EC2에서 S3에 객체를 업로드한다거나 EC2에서 DynamoDB의 Table 값을 읽어들인다거나 할 때, 위 두 가지 구성 모두 통신이 가능합니다. 다만 비용 관점에서는 차이가 있습니다. 좌측 Public 구성은 Internet G/W를 통해서 데이터를 주고받으며 별도의 비용이 발생하지 않습니다. 우측 Private 구성은 NAT G/W를 통해서 데이터를 주고받으며, 2가지 항목에서 과금이 발생합니다. 하나는 NAT G/W의 시간(Hourly) 비용, 다른 하나는 NAT G/W를 통과하는 트래픽에 대한 처리(Processing) 비용입니다. 그럼 비용만 생각하면 무조건 좌측 구성이 좋겠네요? 맞습니다. 하지만 우리는 보안도 동시에 고려해야 하기 때문에 EC2를 Private한 영역으로 격리시키려면 우측 구성이 필요합니다.

그러던 어느 날, 비용을 모니터링하던 박 모 씨는 EC2와 S3 간 트래픽이 크게 증가하고 있음을 확인했습니다. 해당 EC2는 일반적인 Private Subnet에 위치하고 있었기 때문에 NAT G/W의 처리(Processing) 비용이 동시에 증가했습니다. 이를 해결하기 위해 아래와 같은 구성을 검토하였습니다.

좌측은 일반적인 NAT G/W 구성, 우측은 Gateway 유형의 VPC Endpoint 구성입니다. 박 모 씨는 S3용 Gateway Endpoint를 구성하여 연결하였습니다. 참고로 Gateway 유형의 Endpoint는 시간(Hourly) 비용은 있지만, 처리(Processing) 비용은 무료입니다. 따라서 EC2와 S3 간 트래픽이 많을 경우, 우측 구성은 보안 구성을 해치지 않으면서도 네트워크 비용을 크게 절감할 수 있습니다.

하지만 새로운 문제가 생겼습니다. 이번엔 EC2에서 ECR의 이미지를 주고받는 과정에서 다량의 트래픽이 발생했는데요. 문제는 ECR의 경우 Gateway 유형의 Endpoint를 지원하지 않습니다. 그래서 이를 해결하기 위해 아래와 같은 구성을 검토하였습니다.

좌측은 Gateway 유형의 Endpoint 구성, 우측은 Interface 유형의 Endpoint 구성입니다. 두 가지 구성은 몇 가지 차이점이 있는데요. 우선 좌측은 S3나 DynamoDB 같은 서비스만 제한적으로 지원합니다. 과금은 앞에서 말씀드린 것처럼 Endpoint에 대한 시간 비용은 있지만 처리 비용은 없습니다. 우측은 일단 AWS 대부분의 서비스와의 연결을 지원합니다. 다만 비용 관점에서 시간 비용에 덧붙여 처리(Processing) 비용을 받습니다. 물론 이 처리 비용의 단가는 NAT Gateway의 처리 비용보다는 저렴합니다. 따라서 EC2와 ECR Repo 간 데이터를 주고받을 때 발생하는 비용이 크다면, Interface 유형의 Endpoint를 구성하는 것이 NAT Gateway 구성보다 비용상 이점이 있습니다.

이쯤에서 한 가지 더 고려할 것이 있는데요. 위에서 말씀드린 상황들이 따로따로 분리된 것이 아닌 종합적으로 중복되는 상황이라는 것입니다. 그래서 완성된 Private Subnet의 최종 구성은 아래와 같습니다.

위 그림에서는 비용이 발생하는 영역을 구분해서 볼까요? 시간 비용이 발생하는 객체는 Hourly Charge로 표시했고, 처리 비용이 발생하는 구간은 빨간색 화살표로 표시했습니다. 위 구성의 경우 라우팅 우선순위에 따라서 1) EC2와 S3와의 통신은 Gateway 유형의 Endpoint를 2) EC2와 ECR과의 통신은 Interface 유형의 Endpoint를 3) 기타 Public 구간의 객체와는 NAT G/W를 거쳐 트래픽이 자동 분배됩니다. 비용 관점에서 통신하는 대상에 따라 더 낮은 네트워크 단가의 구간을 적용받는 셈이죠. 서울 리전 단가를 포함하여 연동 구간별 비용 항목을 정리하면 다음과 같습니다.

사실 이 구간을 어떻게 구성하는지는 정답이 없습니다. 위에서 말씀드린 예시는 그냥 하나의 상황이고요. 앞서 권장했던 Interface 유형의 VPC Endpoint도 서비스별로 개수가 늘어남에 따라 Hourly 비용이 비례 증가합니다. 따라서 경유하는 트래픽의 양이 많지 않다면 공용 NAT Gateway를 거치도록 하는 것이 유리할 수도 있습니다. 극단적으로는 반드시 Private Subnet에 위치해야 하는 보안 요건이 없다면, 아예 Public Subnet에 배치하여 AWS 서비스 간 트래픽 비용을 없애버릴 수도 있습니다. 결국 기술과 비용 관점에서 종합적인 고려가 필요한데요. 각 연동 구간의 기술적 제약사항, 각 구간별 트래픽량, 보안 필수요건, 과금 구조에 대한 이해를 바탕으로 가안의 정답지를 만들고 시뮬레이션 하는 과정을 각자의 환경에 맞게 수행해야 합니다.

Case3. 연동망 및 인터넷 구간 통신

세 번째 Case는 연동망 및 인터넷 구간 통신입니다. 연동망은 On-Premise 구간과 연결하는 Site-to-Site VPN이나 Direct Connect 같은 전용망을 뜻하고요. 인터넷 구간 통신은 외부 Public망과 연결된 Client들과 오가는 트래픽을 떠올리시면 됩니다. 해당 구간에서 네트워크 단가가 어떻게 달라지는지 경우의 수에 따라 비교해 보려고 합니다.

먼저 On-Premise와의 연동망입니다. 크게 S2S VPN과 Direct Connect 두 가지를 고려할 수 있는데요. 이 부분은 사실 보안 컴플라이언스 요건 등이 메인 선택 기준으로 작용하는 경우가 많습니다. 그럼에도 불구하고 비용 또한 고려하지 않을 수 없는데요. 연동망의 총비용은 Direct Connect의 대역폭(Capacity)이나 관련 연동 구간(Transit Gateway 등) 구성 등에 따라 달라집니다. 이를 모두 다룰 수는 없기 때문에 오늘은 단가 차원에서 두 가지 방식의 과금 항목만 간략하게 비교해 보겠습니다.

S2S VPN 구성입니다. S2S VPN은 2가지 항목에서 비용이 과금됩니다. 하나는 VPN Connection의 시간(Hour) 항목인데요. VPN Connection 연결 수에 시간 단가를 곱해서 산출되는 값입니다. 다른 하나는 DTO(Data Transfer Out) 항목입니다. 이것은 일반적으로 EC2나 S3에서 나가는 DTO 단가와 동일하게 과금됩니다. S2S VPN은 종단 간에서 네트워크 패킷이 암/복호화 되는 것일 뿐, 물리적으로 패킷이 오고 가는 것 자체는 동일한 메커니즘이기 때문입니다. 따라서 AWS 쪽으로 인입되는 Data Transfer In 구간이 무료인 것도 동일합니다.

이번에는 Direct Connect 구성입니다. Direct Connect의 과금 항목은 Port 구성에 대한 항목과 DTO 항목이 있습니다. 먼저 Port 구성(및 유지)에 대한 비용이 시간 단위로 과금됩니다. 이 항목의 단가는 Port 타입(Dedicated, Hosted)과 대역폭(Capacity)에 따라 크게 달라집니다. 이 구간을 통과하는 트래픽의 경우 Data Transfer In 항목이 무료고 Data Transfer Out 항목이 유료인 것은 S2S VPN과 동일합니다. 다만 DTO에 대한 단가는 서로 다릅니다. 서울 리전 기준으로 단가를 비교해 보면 아래와 같습니다.

단가 표를 보면 AWS 환경에서 On-Premise로 넘어가는 트래픽이 많으면 많을수록 Direct Connect가 유리합니다. DTO에 대한 GB 단가가 S2S VPN에 비해 낮기 때문입니다. 따라서 단순히 DTO 비용으로만 보면 AWS 환경에서 Internet G/W를 통해서 나가거나 또는 S2S VPN 구간을 통해서 나가는 것에 비해, Direct Connect 구성은 경쟁력이 있습니다. 다만 대역폭이 크면 클수록 Port 시간 비용이 크기 때문에 DTO 절감분이 상쇄되는 것을 감안해야 하고요. 반면 연동망에 큰 대역폭이 필요하지 않고, DTO 트래픽량이 미미하며, 초기 구성을 빠르게 하고 싶은 경우에는 S2S VPN이 유리합니다.

다음 주제인 인터넷 구간 통신으로 넘어가 보겠습니다. 여러분들이 넷플릭스 같은 서비스를 제공하고 있고, AWS에서 동영상 형태의 콘텐츠를 Serving 하는 환경을 상상해 보겠습니다. 예를 들어 영화 한 편의 콘텐츠 사이즈가 5GB라면, 10,000명의 사용자가 이것을 풀로 시청할 경우 AWS 환경에서 Data Transfer Out 크기는 50TB가 됩니다. 여기에 일반적인 AWS 단가를 곱해보니 트래픽 비용만 500만 원이 넘습니다. 이것을 낮출 방법은 없을까요? 물론 있습니다.

답은 CloudFront를 사용하여 중간에 CDN 계층을 구성하는 것입니다. 1) Client가 ELB나 S3에 직접 요청해서 데이터를 가져갈 때보다 2) 중간에 CloudFront 배포를 구성하고 Client가 CloudFront로부터 데이터를 가져가는 것이 GB 당 단가가 더 쌉니다. 2)가 1)보다 싸다고 말하려면 약간의 부연 설명이 필요한데요. 일단 AWS가 공시하고 있는 List Price는 계단식 단가 구간에 따라 2)가 1)보다 비싼 경우도 있습니다. 다만 CloudFront 사용량이 많은 사용자는 대부분 트래픽 약정(또는 약정을 체결한 MSP)을 활용하기 때문에, 보통은 2)가 1)에 비해 DTO 단가를 50% 이상 저렴하게 사용하는 경우가 많습니다.

CloudFront 같은 CDN 계층을 활용하는 경우, 네트워크 단가를 낮추는 것 외에 추가적인 이점도 있습니다. 일단 Edge에서 캐싱 메커니즘을 통해 Client와 가까운 곳에서 응답하기 때문에 사용자 경험이 향상됩니다. 원본(Origin) 부하가 줄어들기 때문에 서비스하는 EC2 클러스터 등을 더 낮은 사양으로 관리할 수도 있습니다. 이것은 컴퓨팅 영역의 단가를 낮추는 부가적인 효과로 환산할 수 있습니다. 트래픽 비용도 아끼고, 사용자 경험도 향상되고, 원본 부하까지 줄어든다니 일석삼조네요. 이처럼 모든 비용 최적화 활동이 Trade-off를 감수해야만 하는 것은 아닙니다. 비용을 최적화하는 동시에 다른 새로운 개선점을 얻게 되는 경우도 많습니다.

마지막으로 비용 데이터에서 Data Transfer Out 과금을 확인하는 방법을 살펴보겠습니다. AWS의 CUR 데이터에서는 UsageType 중 [Region]-DataTransfer-Out-Bytes 항목을 필터링해서 보시면 됩니다. 여기서 Region은 트래픽이 나가는 Source Region의 위치를 의미합니다. 좀 더 세부적인 단위로 나눠 보시려면 Name Tag나 ProductCode를 Group 조건으로 설정해 보시는 것을 권장합니다.

마치며

이제 정리할 시간입니다. 네트워크의 단가를 낮추는 방법은 결국 단가가 높은 구간을 단가가 낮은 구간으로 전환하는 것입니다. 오늘은 이 내용을 크게 3개의 케이스로 나눠서 살펴봤습니다. 요약하면 다음과 같습니다.

이번 편에서 아쉽게 커버하지 못한 주제도 있습니다. Multi-Account, Multi-VPC 환경에서 Transit Gateway가 연계된 복잡한 연동 구성이나, VPC Endpoint와 NAT Gateway의 중앙화 기법 등은 난이도상 다루는 내용에서 제외했습니다. 24년 초에 시작된 IPv4 주소값의 과금이나 IPv6로의 전환 이슈도 다루지 않았습니다. 오늘 살펴본 내용을 기반으로 먼저 전체적인 과금 메커니즘을 이해하신 후에, 좀 더 특수한 영역은 개별 환경에 맞게 관련 자료를 찾아보시는 것을 권장해 드립니다.

이번 회차로 단가편 3회차가 모두 끝났습니다. 다음부터는 사용량 관점에서 컴퓨팅, 스토리지, 네트워크의 비용을 줄이는 방법을 순차적으로 알아볼 예정입니다. 단가로 접근하는 방식은 클라우드의 과금 체계를 제대로 이해하는 것에서 시작하는 반면, 사용량으로 접근하는 방식은 관리적인 측면에서 실제 (자동화된 방식으로) 절대적인 사용량을 어떻게 줄일지를 고민해야 하는 경우가 많습니다. 과연 어떤 방법들이 있는지는 다음 6회차 글에서 살펴보시죠. 그럼 끝!

 

▶ 더 읽어보기

• 클라우드 비용 최적화 로드맵 #1 - 연재를 시작하며
• 클라우드 비용 최적화 로드맵 #2 - 비용을 자세히 보기 위한 준비
• 클라우드 비용 최적화 로드맵 #3 - 컴퓨팅의 단가를 최적화하는 법
• 클라우드 비용 최적화 로드맵 #4 - 스토리지의 단가를 최적화하는 법

▶ 최준승 님 / Cloud Architect 팀 / jsch@sk.com