Cloud Computing On Demand

CDN 의 핵심은 두가지입니다. 하나는 캐싱을 통한 사용자와 서버간의 거리 단축이고, 다른 하나는 사용자와 캐싱 서버 (=엣지 서버) 간의 거리를 줄여 불확실한 구간을 최소화 하는 것입니다. 이 두가지는 표현이 조금 다르고 추구하는 바가 달라보이기는 하지만 결국 <사용자의 지연 Latency 를 최소화 한다> 라는 공통된 목적을 가지고 있습니다. 

때문에 많은 CDN 벤더들은 계층형 캐시를 사용할 수 있는 방법을 제공하고 있습니다. AWS 에서 CloudFront 제품의 기능으로 새롭게 출시한 Origin Shild 도 계층형 캐시 기능이라고 보면 거의 맞습니다. 이름에서 느껴지는 것처럼 원본 (=Origin Server) 입장에서 봤을 때 제한적인 IP 에서만 접근이 이루어진다는 보안 관점의 효과를 제외하면 2차 캐시라고 봐도 무방합니다. 

AWS CloudFront 가 제공하는 계층형 캐시

AWS 의 CloudFront 는 컴퓨팅 자원들과는 조금 다른 리전을 기반으로 합니다. Edge Location 이라고 불리우는 이 리전들은 CloudFront 엣지 서버들과 Route53 의 자원들을 중심으로 일부 제품 기능을 수행하는 서버들이 위치한 리전입니다. CloudFront 로 일컫어지는 AWS 의 CDN 제품을 생각해보면 사용자로부터 1-hop 거리에 있는 캐시 서버가 동작하고 있는 리전이기도 합니다. 

일반적으로 이러한 Child Cache 서버들은 댓수가 많기 때문에 상대적으로 캐시 효율이 떨어질 수 있습니다. 캐시의 기본은 요청을 집중시키는 것이기 때문에 넓은 지역에 퍼져 사용자들로부터 적은 지연을 확보하는 것과 반비례 관계에 있습니다. 이를 보완하기 위해 AWS 의 CloudFront 가 제공하는 것이 REC, Regional Edge Cache 로 불리우는 상위 캐시 레이어입니다. 

AWS 에서 종종 봤을 위의 그림을 보면 Edge Location, 즉 사용자 접점의 캐시가 배치된 리전은 가능한 넓은 지역에 퍼져 있는 것을 볼 수 있습니다. 반면 오렌지색 원으로 표현된 Regional Edge Cache, 즉 상위 레이어의 캐시 혹은 2차 캐시는 특정 지역 (=보통 컴퓨팅 리전과 일치합니다) 에만 배치되어 있는 것을 볼 수 있습니다. 

일반적으로 Edge Location 에 비하여 REC 의 서버들은 스토리지 공간이나 컴퓨팅 파워가 더 우수한 것으로 알려져 있습니다. 요청들이 원본 서버로 전달되기 전에 한번 거쳐가는 레이어이기 때문에 더 여유로운 장비를 배치하는 것이 당연합니다. 이처럼 계층형 캐시를 제공함으로써 CloudFront 는 1) 원본으로 전달되는 요청을 줄이고, 2) AWS 네트워크 내에서 가능한 트랜잭션을 처리함으로써 사용자 입장에서 더 좋은 컨텐츠 전송 지연 경험을 해주도록 설계가 되어 있습니다. 

Origin Shield 도 REC다!?

이러한 CloudFront 의 구성에서 Origin Shield 는 어떤 차이를 가지고 있는걸까요? 결론을 먼저 이야기하면 Origin Shiled 도 REC 의 일부입니다. REC 는 앞서 보신 그림에서 나타난 것처럼 Edge Location 보다는 Pop이 적지만 여전히 여러 곳에 퍼져 있습니다. 이들 중 원본 서버에서 가까운 혹은 선호하는 REC 리전을 지정해 줌으로써 1) 사용자는 자신에게서 가까운 Edge Location 으로 접근, 2) Edge Location 은 캐시 효율을 위해 REC 에 접근, 3) REC 는 (도메인에 따라) Origin Shield 역할로 지정된 REC 에 다시 한 번 접근함으로써 캐시 효율을 높이고 원본 서버에게 제한적인 대역에서의 접근을 보장할 수 있게 됩니다. 

결국 Origin Shield 도 REC 라는 것이 여기에서의 한줄 요약입니다. 당연히 캐시 효율은 높아질 수 있고 원본에서는 접근하는 대역을 제한 함으로써 보안적인 효용을 얻을 수 있게 됩니다. 사실 REC 는 사용자가 사용 유무를 제어할 수 없다는 것이 한계였고, 상황에 따라서는 (보통은 no-store 성격의 컨텐츠 전송시) Edge Location 이 REC 를 경유하지 않는 경우가 발생하곤 했습니다만 Origin Shield 를 이용할 경우 지정된 REC 를 언제든 경유한다는 장점이 생기게 됩니다.

비용 계산은 어떻게 될까?

그렇다면 비용 계산은 어떻게 되는 걸까요? AWS 를 사용하면 참 편리하고 좋은 것들이 많지만 늘 걱정되는게 비용이기 때문에 비용은 확실하게 확인하고 넘어갈 필요가 있습니다. Origin Shiled 는 기본적으로 REC 이기 때문에 기존의 REC 의 가격 정책과 마찬가지로 과금을 안하는 것이 기본입니다. 다만, REC 가 요청량, 전송량 모두에 대해 별도 과금이 없는 것과 달리 Origin Shield 경유시 요청량에 대한 과금이 발생합니다. (전송량 단위의 과금은 없습니다)

AWS 의 가격 테이블을 확인해보면 어떤 리전에 위치한 REC 를 사용하는가에 따라 위의 테이블에 나온 것과 같은 요청량 기반의 과금을 하게 됩니다. 테이블에 나와 있는 가격은 1만개의 요청당 요금이기 때문에 사용중인 도메인에서 발생하는 원본으로의 요청이 얼마나 되는가가 과금에 영향을 주게 됩니다. 

여기서 또 중요하게 봐야 할 비용 관련 부분은 Origin Shield 로 지정된 리전이 2차 캐시 레이어로 활용되었는가? 하는 부분입니다. 앞서 언급드린 것처럼 Origin Shield 리전도 REC 이기 때문에, Edge Location 이 직접 Origin Shield 로 지정된 리전을 접근한 경우는 증분 레이어 Incremental Layer 로 인정하지 않아 과금되지 않습니다. 다만 다른 REC 를 경유해서 Origin Shield 로 지정된 리전에 접근했을 경우만 증분 레이어로 보고, 요청량을 카운트하여 과금하게 됩니다 

위의 설명에 나온 것처럼 1) 동적인 컨텐츠, 2) 캐시 컨텐츠 유무에 따라 과금 요청량 카운트는 또 달라집니다. 동적인 컨텐츠는 캐시되지 않기 때문에 언제나 Origin Shield 를 경유해서 원본으로 전송됩니다. 이 요청들은 모두 과금 대상 요청이 됩니다. 반면 캐시 가능한 컨텐츠의 계산은 조금 다릅니다. <캐시 가능한 요청수 x (1-캐시히트율) x REC 에서 Origin Shield 를 통해 원본으로 전송된 비율 x Origin Shield 과금 기준> 계산을 통해 과금 대상 요청량을 산정하게 됩니다. 

언제 쓰는게 유리할까?

AWS 는 과금 정책이 늘 복잡합니다. 이번에 공개된 CloudFront 의 Origin Shield 역시 마찬가지입니다. 그렇지만 CDN 좀 써본 분이라면 아시겠습니다만 2차 캐시의 효과는 요청량이 어느정도 된다면 가성비가 훌륭한편에 속합니다. CloudFront 에서도 2차 캐시를 잘 활용하고 싶다면 Origin Shield 를 써야할 것 같은데, 과연 언제 쓰는게 유리한걸까요?

첫번째 케이스로 실제 비용 청구를 따져보긴 힘들겠지만, 사용자의 경험 관점에서 1) 원본 서버가 위치한 지역에 대다수의 사용자가 위치해있고, 2) 일부 해당 지역외 사용자들이 서비스를 종종 이용할 때가 비용을 적게 들이면서도 효과를 볼 수 있는 대표적인 사례가 될 것 같습니다. 1) 에 해당하는 사용자들은 대부분 Origin Shield 레이어를 증분 레이어로 쓰지 않을거라 비용 추가 부담이 적을 겁니다. 2)에 대당하는 사용자들은 약간의 비용 기여(?)를 하겠지만 REC - Origin 구간의 네트워크에서 발생하는 불확실성을 줄여준고 캐시 효율을 높이는 관점에서 사용에 대한 의미가 있을거라 생각합니다.

이런 대표적인 시나리오에서는 확실히 써주는 것이 좋을거라 봅니다만 그 외의 케이스들에서는 일부 트래픽의 적용 등을 통해 검증이 필요합니다. 아시겠지만 모든 케이스에 두루 적용되는 솔루션은 현실 세계에서는 거의 없기 때문이겠지요. 새롭게 런칭된 AWS CloudFront 의 Origin Shield 기능을 통해 사용자 경험을 향상시키는 계기를 만들어 보시기 바랍니다.

Facebook 에서 CDN 과 관련한 이야기를 나눌 그룹을 만들어 운영하고 있습니다. 여러 CDN 벤더의 엔지니어들이 참여하고 계시기 때문에 많은 인사이트와 흥미로운 지식들을 얻어가실 수 있습니다. 

* 이 글은 BrianMadden 이 본인의 홈페이지 (http://www.brianmadden.com) 에 올린 " Is VDI more green than traditional desktops? And if so, does it matter? " 글을 간단하게 요약 / 번역한 글입니다. 의역이 일부 있을 수 있으며, 정확하지 않은 표현이 있을 수 있으니 감안하시고 보시기 바랍니다.

1. "그린"이란 무엇인가?

"그린" 이라는 단어는 "가상화"와 마찬가지로 누가 사용하냐에 따라 의미가 달라질 수 있는 상당히 트렌디한 전문용어이다. 지구 환경에 대해서 무언가 좋은 일을 한다는 컨셉은 참 좋지만, 제대로 이해하지 못한 상태에서 막연하게 우리가 하는 일이 "도움을 준다"라고 느끼는 것은 아닌가 싶다. 많은 사람들이 한가지 관점에서만 "그린"을 하다보니 때때로 상황이 더욱 나빠진다는 것을 알아차리지 못하는 것 같기도 하다. 예로, 환경을 위해서 종이 가방을 사용하는 것보다 오래된 비닐 봉지를 사용하는 것이 훨씬 더 "그린" 한 일이다.

완전한 "그린"이 언제쯤 우리의 데스크탑 환경에 들어올 수 있을지 잘 모르겠다. 하지만 몇년전 열렸던 Citrix의 iForum 행사에서 마크 템플턴(Citrix)이 "씨트릭스의 기술은 직원들이 재택근무를 할 수 있게 해줌으로써 회사가 "그린"화 되는 것을 도와주고 있다" 라고 했던 것을 기억하고 있다.

이러한 컨셉은 "그린"이라는 큰 그림을 두고 볼 때 참 진부한 예일 뿐이다. 물론 그렇게 하는 것은 회사 입장에서는 최소한의 공간만을 마련하면 되는 것이기 때문에 비용이 싸게 먹히는 방법이다. 그러나 전체 시스템 입장에서 보면, 큰 빌딩에 모든 직원을 몰아넣고 냉난방 하는 것이 개개의 직원들이 자신의 집에서 냉난방을 하는 것보다 훨씬 효과적인 방법이다.

2. 전력 소비에 대한 이해

IT 에서 이야기되는 "그린"의 대부분은 전력 소비를 줄이는 것에 대한 것들이다. 맞는 말이다. 그리고 대부분 전력 소비를 줄이는 것이 일반적으로 좋은 것이라고 생각하고 있다.

문제는 대부분의 사람들이 어떻게 전력이 소비되는지 제대로 이해하지 못하고 있으며 어떻게 절약할 수 있는지도 모르고 있다는 것이다. 가장 큰 오해는 IT 장치들의 최대 소비전력을 그 장치가 늘 소비하는 전력으로 이해한다는 것이다. 예를 들면 "400W 의 데스크탑 파워 서플라이를 하나 끄는 것은 100W 짜리 백열 전구를 끄는 것과 같다" 식의 이야기가 그런 것이다. 틀린 이야기다. 400W 짜리 데스크탑 파워 서플라이는, 최대 전력 소모량이 그렇게 된다는 이야기지 언제나 400W의 전력을 소모한다는 이야기가 아니다. 실 소모전력은 얼마나 많은 드라이브를 연결했고 어떤 주변장치를 연결했으며 CPU 가 얼마나 열심히 작업을 하고 있느냐에 달려있는 것이다.

3. VDI 가 전력을 아껴주는가?

CitrixLive 웹케스트에서 저와 Rick, Shawn, Steve Greenberg는 내년에 있을 Synergy 행사에서 VDI의 그린 임팩트에 대한 세션을 제안하기로 했다. 우리가 생각하고 있는 주제들은,

- 윈도우7 PC로 다양한 작업을 동시에 수행하고 있는 최신의 데스크탑 컴퓨터가 소비하는 전력은 얼마나 될까?
- 이 PC와 동일한 작업을 수행하는 가상머신 기반(VDI)의 씬 클라이언트 단말기가 소모하는 전력?
- 데이터 센터의 블레이드 서버, 오래된 데스크탑, 오래된 씬 클라이언트 단말기는 어떨까?

기본적으로 우리는 몇가지 실험을 진행할 것이고 VDI 환경이 정말로 절약할 수 있는 전력이 얼마나 되는지 계산해 보고, 단지 데스크탑이 소모하는 전력을 데이터 센터가 소모하는 수준인지도 확인해 볼 것이다. 이를 위해서 다양한 벤더가 생산하고 있는 여러 모델을 이용해서 실험이 진행해 볼 것이다.

친환경에 관한 또다른 재미있는 점은, 우리가 더 친환경적인 솔루션을 찾는것이 그렇게 중요한 일인가 하는 점이다. 까놓고 얘기해서, 누가 신경쓰기는 하느냐는 말이다. 만약 그린 컴퓨팅이 비용 절약의 관점에서 전력 소모를 줄여준다면, 많은 회사들이 움직이기 시작할 것이다. (당연히 친환경을 위해서가 아니라 그들의 주머니에서 나가는 돈을 아껴주기 때문이다! 사실 많은 회사들은 그린이든 갈색이든, 보라색이든, 돈만 아낄 수 있다면 뭐든 할것이다) 몇몇 기업들은 친환경으로 가는 것이 사람들에게 쿨하게 보일 수 있고 매출 증대로 이어질 수 있을거라고 생각할지도 모르겠다. 결론적으로, 기업들은 친환경을 신경쓰는 것이 아니다. 단지 판매를 늘릴 수 있는 방법인지 아닌지만 신경쓰는 것이다.

자, IT 세계에서 살고 있는 우리에게 그린 컴퓨팅이 정말 중요한 것일까? 아마도 아닐것이다. 지출을 줄이거나 이윤을 높이는 것에만 관심이 있을 것이다.

문제는 많은 IT 부서들은 전력 소모를 줄이는 것이 자신들의 예산과 관계 없다고 생각하는 것이다. 전력을 아낀다고 이득을 얻는게 하나도 없다는 것이다. 솔직히 말해서 이런거에 관심이 있을만한 곳은 전력 소모량이 최대치에 가까워진 데이터 센터라던가 전력 소모량을 어떻게든 줄여서 필요한 컴퓨팅 파워를 더 이끌어 내려는 부서 정도일 것이다. 하지만 이런 내용들은 서버 서버 가용성에 관한 이야기지 그린에 관한 이야기는 아니다

5. 돈에 관한 빅뱅?

VDI 가 아주 친환경 적이라는 것이 증명된다 한들, 그게 꼭 해야만 하는 가치가 있는 것일까? 그린 컴퓨팅을 위해서 얼마나 많은 돈을 투자할 수 있겠는가? 더 나은 지출처가 있지 않을까?

미국의 에너지 부문 장관인 Stephen Chu 는 모든 집의 지붕, 외벽을 흰색 페인트로 칠하면 11년간 도로에서 차를 없애는 것과 같은 탄소 배출량 감소 효과를 가져올 것이라는 조금은 황당하게 들릴지도 모르는 이야기를 했다. 이 이야기는 작은 변화가 에너지 절약에 큰 도움을 줄지도 모른다는 것을 시사해 준다. 예를 들어, 아주 매력적이고 새로운 VDI 시스템을 구매하는 대신, 모든 데스크탑과 노트북의 화면 절전 기능을 10분으로 맞추고, 30분동안 PC가 유휴상태로 머물면 대기모드로 들어가도록 하는 것이 더 많은 전력을 아끼는데 도움이 되는 것은 아닐까?

물론 어떤 기업도 그린 컴퓨팅만을 위해서 VDI 시스템을 구매하고 구축하는 것은 아니다. 많은 기업들이 어떤 아키텍쳐를 구성하거나 새로운 시스템을 구매할때 감안하는 하나의 필수 요소일 뿐이다.

완벽한 친환경 시스템의 구축이 여러분이 다니고 있는 회사의 IT 부서에 중요한 영향을 주는가? 여러분이 전기세를 내는가? 그냥 친환경이라서 하는 것인가? VDI가 더 친환경적인지 아닌지 고민은 해보았는가? 이러한 이슈에 대해 뭔가 더 고민해야만 하는 것일까?

- NoPD -