Cloud Computing On Demand

AWS 를 사용하면서 가장 많이 나오는 요금은 무엇일까?

어떤 자원을 어떤 형태로 사용하느냐에 따라 달라지겠지만

일반적인 웹 서비스라고 가정했을 때 

역시 가장 큰 비용을 차지하는 것은 네트워크 전송요금이다

AWS 의 과금체계는 깨알같다

컴퓨팅과 같은 상품도 당연히 그러하지만

데이터 전송과 관련한 요금은 더욱 깨알같다

Region 내의 데이터 전송만 생각해봐도 케이스가 정말 많다

같은 Region 내에서의 전송은 무료인가?

같은 Region 내에서 가용성 영역이 다르면 유료인가?

ELB 가 앞단에 있다면 요금은?

ELB 에 물린 서버가 크로스 존이면 또 다른가?

EC2 가 직접 응답하는 것과 ELB 경유 응답의 가격 차이는? 등등...

이걸 한장에 정리해 놓은 그림이 바로 아래의 그림이다.

그림의 출처는 https://github.com/open-guides/og-aws#aws-data-transfer-costs

Cost Explorer 에서 과금 내역을 살펴보면서

DataTransfer 관련한 요금이 많이 나오고 있다면

어느 항목에서 요금이 많이 청구되는지 꼭 분석하자

그리고 그 요금을 낮출 방법을 찾아봐야 한다.

상황에 따라서는 요금을 낮추기 위해 데이터의 플로우 변경이 필요할 수도 있다.

개발된 산출물의 변경 개발이 필요할 수도 있다.

그래도 하자. 그래야... 한다.. ㅎㅎ

•  모든 전송 요금은 Region 단위로 과금
  • ELB - EC2 구조를 사용하더라도 Region 전송 비용을 과금함
  • Operation 이 두가지가 잡히는데 어떤 것이 실제 과금에 사용되는 지는 잘 모르겠음

• ELB 는 그럼에도 전송량에 독립적이지는 않음
  • ELB 는 Processed Byte 기준으로 LCU 를 계산하여 단위 요금에 곱하여 과금
  • LCU 는 ELB 타입별로 (ALB, NLB, CLB) 측정 대상 데이터가 상이함

• Direct Connect 도 전송량 단위로 과금함
  • 두가지 항목이 있고 과금 여부는 아래와 같음
    • #region명#-#DX_region명#-DataXfer-In : 비과금 (AWS 소스 Region 입장에서 Inbound)
    • #region명#-#DX_region명#-DataXfer-Out : 과금 (AWS 소스 Region 입장에서 Outbound)

• NLB 의 동작 방식에 따른 과금 변경
  • NLB 의 Target 을 Instance ID 로 지정 : DSR 로 동작 (EC2 Outbound 요금)
  • NLB 의 Target 을 IP 로 지정 : Proxy 로 동작 (ELB Outbound 요금)
  • 참고 :  https://blog.leedoing.com/116

• GS Neotek 에서 과금 항목을 잘 정리한 데이터 : https://wisen.co.kr/pages/blog/blog-detail.html?idx=4329

세계적으로 클라우드 서비스를 제공하는 사업자들은 무척 많습니다. 각 사업자들은 각자의 컨셉과 목표를 가지고 클라우드 서비스를 만들고 제공하고 있는데요 아마존의 AWS, 마이크로소프트의 애져(Azure) 등이 대표적입니다. 아마존의 경우 인프라스트럭쳐(IaaS)에 대한 가상화와 클라우드화를 기치로 내걸고 사업을 시작하여 지속적으로 플랫폼의 영역(PaaS)으로 올라오는 중이며 마이크로소프트의 경우 개발자들이 보다 쉽게 개발된 서비스와 코드를 사용자에게 제공할 수 있도록 플랫폼에서 시작하여 인프라스트럭쳐의 영역으로 내려오는 전략을 가져가고 있습니다.

마이크로소프트는 자사의 제품들을 전반적으로 실물 제품에서 가상의 제품, 클라우드화를 지속적으로 진행하고 있기 때문에 이의 연장선상에서 애져의 시장 전략을 가져가고 있습니다. 엊그제 진행된 애져컨(Azure Con)의 키노트에서 마이크로소프트가 꿈꾸는 클라우드 서비스와 방향성을 볼 수 있는 좋은 내용들이 무척 많이 나왔습니다. 그 중에서도 가장 눈에 띄는 것은 아무래도 컨텐츠 전송 부문에서의 협력을 글로벌 CDN 1위 사업자인 아카마이(Akamai)와 한다는 발표가 아닐까 싶습니다.

키노트 세션이었기 때문에 기존의 CDN 을 유지하면서 아카마이의 글로벌 foot-print 를 활용하는 전략인지 아니면 기존의 협력관계였던 EdgeCast 와의 관계를 청산하고 아카마이를 전면에 내세우는 것인지는 자세히 소개되지 않았습니다. 다만 올해 하반기 까지는 제한적으로 고객들을 선별하여 애져 플랫폼 및 상품들과 아카마이를 통한 CDN 을 구현하는 작업을 진행하는 것으로 보이며 일반 고객들이 쓸 수 있는 GA (General Availability)는 내년 초가 되어야 할 것으로 보입니다.

마이크로소프트와 아카마이는 9월 29일 화요일 나란히 이러한 협력관계가 시작되었음을 알리는 공식 블로그 포스팅을 공개했습니다. 클라우드 환경으로 컴퓨팅 자원을 제공하는 회사들, 그 회사들의 서비스를 이용하는 고객들의 공통적인 고민은 "어떻게 글로벌 엔드유저들에게 전송을 빠르게 할 수 있을 것인가?" 입니다. 컴퓨팅 자원을 여러 리전(Region)에 나누어 서비스 하는 것은 쉬운 접근이겠지만 이들의 관리와 형상 유지, 라스트 마일(Last Mile)구간에서 발생하는 속도 이슈에 대한 해결은 쉽지 않은 문제입니다.

이를 위해서 아마존은 클라우드 프론트(Cloud Front)라는 자체 CDN 서비스를 제공하고 애져는 CDN 사업자와의 제휴를 통해 이를 해결하는 비즈니스 모델을 가지고 있습니다. 어떤 접근이 맞고 틀리는지, 혹은 더 좋고 나쁜지는 상황에 따라 다르겠지만 마이크로소프트 애져가 글로벌 1위 사업자인 아카마이와 제휴하여 서비스를 제공하는 것이 더 나은 모델이지 않나 하는 생각이 듭니다.

대규모의 사용자 트레픽을 소화하기 위해서는 고민해야 할 것들이 많습니다. 서비스 오리진(Origin) 인프라의 유연함과 적절한 스토리지(Storage)을 확보해야 하는 것은 물론이고 갑작스런 사용자 폭주에 대비하여 충분한 대역폭(Bandwidth)도 갖추어야 합니다. 큰 규모의 기업이라면 그나마 이러한 준비를 하기 위한 투자(CapEx)가 가능하겠지만 작은 규모의 기업(SMB, SOHO)이나 스타트업(Start-up)이라면 열악한 인프라를 이용하여 서비스를 시작하는 경우가 많습니다.

하지만 충분한 재원을 이용하여 인프라를 증식(?)하는 방법은 한계가 있습니다. 가장 단적인 예는 "충분한 대역폭" 에서 찾을 수 있습니다. 갑작스런 서비스의 인기몰이나 이슈가 생겼을 때 폭주하는 사용자 트레픽은 그 규모를 가늠하기가 힘듭니다. 또한 일시적으로 발생하는 이런 스파이크(Spike)를 대비한다고 평상시에 이용되지 않는 대역폭을 계약하여 사용하는 것은 운영 비용(OpEx) 관점에서 효과적이지 않습니다. 그렇다면 이런 문제는 어떻게 해결할 수 있는 것일까요?

흔히 컨텐츠 전송 네트워크(Content Delivery Network, CDN)이라 불리우는 서비스들이 그 해답이 될 수 있습니다. 글로벌 1위 사업자인 아카마이(Akamai)를 비롯하여 최근에는 아마존(Amazon)이나 마이크로소프트 애져(Azure) 등 클라우드 서비스들도 필수적으로 CDN 서비스를 제공하고 있습니다. CDN 전문 사업자들 뿐만 아니라 클라우드 인프라를 제공하는 사업자들까지 CDN 상품을 내놓고 있다는 것은 인프라와 전송 네트워크의 조합이 대규모의 사용자 트레픽을 소화하기 위해서 필수라는 의미로 해석해도 크게 틀리지 않다는 이야기입니다.

아카마이는 최근 마이리틀텔레비전의 컨셉으로 마이리틀CDN 이라는 인터렉티브 세션을 운영하고 있습니다. 다음주 화요일인 9월 22일 오후에 한시간동안 CDN 의 기본적인 동작 원리와 어떻게 활용하면 도움이 될지에 대한 프로그램이 방송될 예정이라고 합니다. CDN 서비스를 제공하는 사업자들 별로 저마다의 특징과 차별화 포인트를 가지고 있지만 기저에 깔려 있는 기본적인 스킴은 어느정도 비슷하기 때문에 CDN 에 대한 기본적인 소양을 쌓고 글로벌에서 성공할 미래의 내 서비스를 위해 지식의 폭을 넓힐 수 있는 기회가 될 수 있을거란 생각이 듭니다!