System Compleat.

AWS architecture blog

Techs


(younjin.jeong@gmail.com, 정윤진) 


Amazon Web Services 에서는 AWS 뿐 아니라 다양한 환경에서의 아키텍팅에 대한 가이드를 위해 블로그를 운영하고 있습니다. 보통 https://aws.typepad.com 으로 대표되는 Jeff Barr와 각 국가에서 개별적 언어로 번역되는 공식 블로그와는 성향이 조금 다릅니다. 


페이지 주소는 

http://www.awsarchitectureblog.com/ 


Route53 과 같은 DNS 서비스가 어떻게 고가용성으로 구동되는지, 어떻게 보다 효율이 좋은 어플리케이션을 설계 할 수 있는지 AWS에서의 샘플 및 AWS의 서비스 구조등을 통해 가이드 되어 있으므로 여가시간에 한번씩 읽어보시면 재미있지 않을까 합니다. 이를테면, 기능의 소개보다는 '어떻게 하면' 이 주제라고 보면 맞을것 같아요. 



블로그질 수년째 하면서 존댓말 써보긴 처음이네요. 

뭐 아무튼, 나라도 나도 다사다난 언만진찬 하지만, 


PEACE! 


아래는 공식 블로그에 대한 소개임돠. 


Welcome to the AWS Architecture Blog

26 Mar 2014 in Announcements | Permalink

At Amazon Web Services we have the great fortune to work on many interesting large-scale distributed systems, as well as the privilege to observe our customers achieve audacious goals. Many highly available services, web sites, and business systems have been built on top of Amazon Web Services.

This new blog, the AWS Architecture blog, will dive a little deeper than our documentation or announcements and provide further information and technical details for customers interested in building more highly available applications and services on top of Amazon Web Services.

We’ll be disharing posts from many AWS team members covering areas including, but not limited to:

  • High availability configurations for using AWS services
  • Relentless and creative testing
  • Architecture best practices for Amazon Web Services
  • Deployment and operational best practises
  • Comprehensive and speedy monitoring
  • Compartmentalization and fault isolation
  • To get future posts, please check back often or subscribe to our blog using the RSS feed button at the top of the page or our twitter account (@AWSArchitecture).

If you have requests to cover specific topics, please let us know in the comments.


(younjin.jeong@gmail.com, 정윤진) 

Hypervisor, Container and docker.io

Techs



(younjin.jeong@gmail.com, 정윤진) 


수 년전에 일했던 회사중에서 아파치를 하나의 리눅스 머신에서 다양한 사용자 권한으로 수행하도록 모듈을 만들고 소스를 수정하여 서비스를 구현했던적이 있다. 기본적으로 단일 서비스 및 단일 기업을 위한 웹 사이트를 구성하는 경우에는 www-user 또는 httpd 와 같이 root 대신 적절한 사용자 레벨의 권한을 부여하여 서비스하는 것이 일반적이지만, 서로 관계가 없는 다양한 사용자들을 하나의 시스템에 수용하고자 하는 경우에는 이야기가 좀 다르다. 





위의 경우에서는 운영체제에서 지원하는 사용자관리 및 이에따른 보안 모델을 제공하며 이는 매우 오래된 역사를 가진 유닉스 System V 모델을 따르는 경우가 많다. 따라서 각 사용자의 프로세스는 구획되고 구분되며, Semaphore, Shared memory, Message pipeline, Named pipe 등의 IPC method 를 통해 서로 데이터를 참조하도록 구성하지 않는 경우라면 참조가 불가능하기 때문에 서로 다른 사용자의 권한으로 동일한 웹 서버 daemon 을 구동하는것은 그에 필요한 오버헤드만큼이나 하나의 시스템에서 높은 보안성을 가지도록 구성 할 수 있다.


새로운 시대는 더 빠른 프로세서에 대한 요구에 부합한 하드웨어들을 양산해 내게 되었으며 이로인해 다양한 OS 와 플랫폼, 그리고 어플리케이션들이 등장하게 되었는데, 이들 중 가장 그 영향력이 큰 부분중 하나는 바로 가상화 기술이다. 가상화라고 하면 보통 하나의 OS 위에 다른 OS 를 추가로 설치할 수 있는 환경으로 이해하는 경우가 많다. 가상화에 대해 조금 더 살펴보자면, 네트워크, 프로세서 및 메모리와 같은 리소스를 관리하여 게스트 OS 들에게 할당하고 인식하게 하는 기술이다. 이는 "하나의 시스템에서 여러개의 운영체제를 구동하고 싶다" 라는 요구에 의해 개발되고 발전해 왔다. 


최근에 거대하게 발전하고 있는 클라우드의 컴퓨팅 관련 서비스들은 가상화 기술을 기반으로 하고 있다. 하드웨어들은 넘쳐 흐르는 충분한 성능을 가지고 있고, 가상화가 가져다 주는 힘은 이제 단일 호스트에서 여러개의 OS 를 구동하는 것 이상으로 파워풀하다. 기존의 하나의 시스템 기반이었던 가상화 기술이 특정 하드웨어의 세트 단위로 클러스터링하거나, 사용자의 가상 리소스들 간의 고립된 네트워크 및 스토리지를 제공하는 별도의 기술이 투여 된 것이 대부분 클라우드 사업자의 컴퓨팅 관련 서비스들이라고 볼 수 있다. 


목적을 되새겨 보면, 결국 필요한 것은 "내가 실행한 어플리케이션이 정상적으로, 또한 높은 보안성으로 구동되면 된다" 라는 간단한 요구사항을 가진다. 이는 처음에 이야기했던 서로 다른 사용자의 아파치 프로세스가 유닉스의 서로 다른 사용자 권한으로 실행할 때의 요구사항과 유사하다. 하나의 시스템에서 동작하지만, 너와 나의 프로세스는 별개이며 관리하는 입장에서도 한명의 사용자 프로세스에 문제가 발생하더라도 전체 아파치의 문제로 전파되지 않기 때문에 운영과 관리측면에서도 매우 유용하다. 



가상화 또는 가상화 된 플랫폼을 기반으로 클라우드 공급자 및 3rd party 사업자들은 컨테이너 서비스를 만들어내기 시작했다. 대표적인 예가 AWS의 Elastic Beanstalk, 또는 Heroku 와 같은 서비스로 볼 수있는데, 바로 개발자들은 소스코드만 가지고 있다면 원하는 환경을 그대로 배포하여 서비스 할 수 있도록 지원하고 있는데, 이러한 서비스를 보통 컨테이너라고 부르는 경우가 많다. 컨테이너가 연상하는 기능이 바로 그렇듯이, 프레임웍이 같다면 규모는 다를지언정 그 구조가 다르지는 않기 때문에 마치 내용물은 다르지만 운반이 간편한 컨테이너와 같은 장점을 서비스에 부여하는 것이 가능하다. 


만약 이를 아파치 뿐만 아니라 다른 모든 다양한 어플리케이션에도 적용하고자 한다면 어떨까.




올 초에 이 오픈소스 프로젝트에 대해 접할 기회가 있어서 몇번 블로그에 소개하고자 했지만 여건이 나지 않았는데, 조금 살펴보니 이미 국내의 일부 블로그 포스팅에서 이를 언급하고 있고 홈페이지도 처음에 비하면 어마무지하게 좋아졌기 때문에 별도로 설치 가이드와 같은 내용을 옮길 필요는 없어 보인다. 

언제나 무언가를 사용하고 테스트 해 보고자 할때 목적이 있어야 하는데, docker.io 가 제공하는 컨테이너에 대해 개인적으로 pros 와 cons 를 나눠보면 아래와 같지 않을까. 

Pros 
- 현재까지 사용되고 있는 Hypervisor 기반의 가상화는 게스트 OS에 물리적 자원을 논리적으로 분할하여 할당하고 OS 위에 OS 를 구동하는 형태로 구성되는것과 달리 docker 는 별도의 구획된 OS가 없기 때문에 훨씬 가볍게 동작한다. 
- 이는 대단위의 클라우드와 유사한 인프라를 구성하는 경우에도 SDN 이나 별도의 네트워크 및 스토리지에 대한 전통적인 OS기반의 무언가가 필요 없기 때문에 목적에만 맞다면 기존 가상화 클러스터대비 높은 비용 효율성을 이룩할 수 있다. 
- 어플리케이션의 개발과 배포를 편리하고도 빠르게 처리 할 수 있다. 

Cons 
- 아직 빡시게 개발중이다. 
- Hypervisor 기반의 클라우드가 그래왔듯 docker 역시 사용자에 대한 구획을 대규모로 분산된 인프라에서 관리 및 구현 할 필요가 있어보인다. 
- 서비스 및 목적에 따라서는 OS 레벨의 Hypervisor 가 필요한 경우가 아직까지는 더 많이 있다. 
- 누군가 이를 PaaS 와 같은 형태의 서비스로 제작하려 한다면, Context switching 및 기타 공유 자원에 대한 부하를 급증시키는 어플리케이션에 대해 서로 다른 성능의 플랫폼으로 이전해 주거나 분산 및 확장해 주는 별도의 구조에 대해 생각 할 필요가 있다.


docker.io 는 AWS의 EC2 환경에서 손쉽게 돌려볼 수도 있다. 
http://docs.docker.io/en/latest/installation/amazon/ 


아래는 docker.io 에서 배포하고있는 슬라이드. 




새로운 무언가를 대할때는 언제나 즐거운 느낌이다. 
이를 배우고 학습하며 테스트하는데 아직 즐거워 할 수 있는 스스로에게 안도감을 느끼게 되는것은 이전보다 젊지 않아서일까. 

무언가를 직접 해 보기 전에 필요한 정보는 언제나 구글에 있다. 다만, 시도 후에 발생하는 문제와 그 해결은 있을수도, 없을수도 있으므로 검색을 먼저 먼저. 


http://docker.io


(younjin.jeong@gmail.com, 정윤진) 

쿼드 콥터와 수학 모델

Techs


(younjin.jeong@gmail.com, 정윤진)


놀이가 놀이로만 끝나지 않는 경우를 종종 목도하곤 한다. 

아래의 TED 에서 발표된 연구 결과가 그러한데, 오픈 하드웨어 플랫폼과 수학/물리 모델의 RC 장난감에의 반영이 얼만큼 놀라운 일이 될 수 있는지를 보여준다. 





여기에 필요한 각종 센서와 그 센서들의 높은 감도 그리고 이를 실시간으로 처리해야 하는 센서 네트워킹과 프로세싱의 결합은 좋은 연구 대상이 되지 않을까 한다. 그리고, 이 물리적으로 실제 동작하는 하드웨어와 소프트웨어의 결합이 미래의 컴퓨팅에 새로운 하나의 거대한 분야가 되지 않을까? 이 영상을 보고 당장 상상 가능한 디바이스가 어떤것들인지는 모르겠지만, 적어도 각자의 머릿속에 한개만 떠오르지는 않을 거다. 


언제나, 상상을 현실로 만드는 사람들이 있음에 오늘도 놀란다. 



(younjin.jeong@gmail.com, 정윤진) 





웹 서비스의 해외 진출 시 고려 사항

Techs


(younjin.jeong@gmail.com, 정윤진) 

최근 풍요로운 모바일 및 웹 시장을 바탕으로 글로벌 진출 시도를 하는 기업 및 서비스가 많아지고 있다. 이들 서비스 중 일부는 국내에서의 성공을 바탕으로 누적된 자본을 사용하여 진출 시도를 하려는 경우와, 기획 초기 단계부터 애초에 국내 시장만을 대상으로 하지 않고 글로벌 서비스를 준비하는 경우 등 서비스의 종류에 따라 그 사례가 다양하게 존재한다. 서비스가 성공한다는 가정 하에 국내에서만 성공했을 때와 글로벌에서 성공 했을 때의 매출 규모는 상식적인 수준에서 당연히 글로벌이 훨씬 유리 할 수 밖에 없다. 

Image from: http://www.technologyreview.com/photoessay/511791/smartphones-are-eating-the-world/


하지만 지난날의 글로벌 서비스를 위해서는 수많은 자본의 투자가 필요해야 했다. 이는 당연히 서비스 종류별로 사전에 염두해 두어야 할 서비스 대상 지역의 관련 법규를 기반으로 한 적절한 구성과 e-commerce 비지니스와 같은 경우 물류를 위한 창고 및 배송을 위한 현지 업체들과의 파이프 라인 등 쉽사리 엄두가 나지 않는 것들, 그리고 진행하려면 a부터 z 까지 모두 비용이 소요되는 그래서 큰 규모의 기업들만이 시도 할 수 있었던 것이 당연시 되었다. 

이들 중 일부 사항들은 현재 전산으로 대체 할 수 있으며 이 대체를 위해 글로벌 지향의 서비스를 사용하게 되면 상당한 비용을 절약 할 수 있다. 오늘의 포스팅은 바로 어떠한 부분을 염두해 두어야 하는지, 또 보다 좋은 고객 경험과 초기 인프라 자원 투자 비용을 어떻게 줄일 수 있는지에 대한 내용을 중점으로 한다. 물론, 여기에 소개되는 내용을 즉각 사업에 반영하여 초래되는 위험을 바라고 쓰는 글이 아니므로 하나의 의견 정도로 찬찬히 살펴보면 어떨까 한다. 

Image from: http://www.welovedates.com/blog/2013/06/how-to-flirt-on-instagram/


최근의 거의 대부분의 글로벌 비지니스는 웹을 기반으로 한다. 웹의 특성상 서비스 대상 지역에서 네트워크 적으로 가까운 곳에 위치 할 수록 빠른 응답시간을 보장 받으며 이로 인해 고객이 물건을 구매하거나 게임을 즐기거나 또는 컨텐츠를 감상하는데 있어 보다 좋은 서비스 품질을 경험 할 가능성을 높일 수 있다. 당연히 필자가 EMS 나 Paypal 과 같은 배송 결재 시스템 및 서비스에 대한 전문가가 아니라 인프라 관련 업을 하는 사람이므로 이 인프라에 대한 논의를 주축으로 삼도록 한다. 


글로벌 서비스를 시작하겠다고 결심하면 인프라를 준비하는데 보통 다음의 세가지 방법 중 하나를 선택하게 된다. 

1. 사업 대상 지역에 설비 구축 
2. 기존 영업관계 및 이미 사이트가 구축 되어 있는 국내의 데이터 센터와 ISP 를 사용 
3. 글로벌 public cloud 사업자를 이용 



이 세가지 방법은 당연하게도 다음과 같은 부가적 요소가 따르게 된다. 

a. 1번의 방법은 시간과 비용 그리고 인력의 소모가 최대가 된다. 따라서 구현을 위한 비용(시간포함), 즉 투자 비용이 상당하다. 
b. 2번의 방법은 1번 보다는 저렴 할 수 있지만 네트워크 지연으로 인한 서비스 품질이 문제가 된다. 따라서 고객의 서비스 경험 수준이 낮을 가능성이 높다. 
c. 3번의 방법은 학습해야 할 내용이 많다. 아울러 사업자간 어떤 서비스를 제공 하는지 확인이 필요하기도 하다. 



국내 굴지의 대기업인 경우라면 모르되, 보통 b와 c의 방법을 고려하게 되는 경우가 대다수라 할 수 있다. 일반적인 웹 형태의 서비스인 경우를 기준으로, 결정을 위해서 필요한 1차적인 주요 선택지는 다음과 같은 내용이 될 수 있다. 

1. 컨텐츠 전송을 위한 속도 및 비용 
2. 사업 대상지역에 사용 가능한 서버 리소스 및 비용 
3. 데이터베이스 및 스토리지 비용 



이를 조금 더 해부 해 보면, 다음과 같은 리스트를 얻을 수 있다. 

1. 컨텐츠 전송을 위한 속도 및 비용 

- CDN 서비스 제공 여부
- CDN 서비스 제공 지역 및 가격
- CDN 서비스 약정 또는 그와 유사한 계약 필요 여부
- 데이터 트래픽 발생 비용
- 각 지역에 인접한 DNS 서비스 제공 여부
- DNS 서비스에서 제공하는 기능 - 예외 상황 발생시 서비스 운용에 대한 제어권 확득 방법  


2. 사업 대상지역에 사용 가능한 서버 리소스 및 비용 

- 미주, 유럽, 아시아등 지역에서 리소스 준비 시간 
- 서비스 유입 증가로 인한 새로운 리소스 조달 시간 
- 서비스 유입 하락으로 인한 기존 리소스 감축 및 이에 따른 비용 
- 과금의 단위에 따른 비용 절감 방안 존재 여부 
- 별도의 운영 인력 필요 여부 
- 로드 밸런서와 같은 부가 기능 지원 여부 


3. 데이터베이스 및 스토리지 비용 

- 지원하는 데이터베이스의 종류 
- 각 데이터베이스의 가격 
- 데이터베이스 백업, 복구, 확장에 대한 지원 범위 
- 저장 가능한 스토리지의 크기 (확장)
- 데이터베이스 및 스토리지 준비에 필요한 시간 


4. 기타요소 

- 캐시 서비스 
- 검색 서비스
- 데이터 마이닝을 위한 서비스 
- 로그의 장기 보관을 위한 서비스 


일반적으로 대부분의 웹 서비스는 다음과 같은 과정으로 컨텐츠를 공급한다. 

DNS query > Page access > Get contents from ...

Image from: http://en.wikipedia.org/wiki/Domain_Name_System


따라서 1차적으로 만약 네임서버 서비스가 한국에 존재하는 경우 모든 글로벌 사용자는 한국으로의 트래픽 유입이 필요하다. 아니, 모든 사용자라 하는 경우에는 어폐가 있으므로 글로벌 각 지역의 recursive 로 동작하는 사용자 네임서버들은 모두 최초 1회는 한국에 위치한 네임서버로의 lookup 이 필요하다. 만약 여기에 짧은 서비스 downtime 을 위해 도메인에 대한 TTL 을 낮게 설정한 경우라면, 한국의 네임서버를 hit 하게 될 빈도는 더욱 높아지게 된다. 

이 말은 즉, 해외에 위치한 사용자가 페이지 접속 이전에 도메인 조회를 위해 상당한 시간을 허비해야 하는 것을 의미하며 여기에 낭비된 시간 만큼 첫 페이지에 대한 접속 시간은 증가하게 된다. 최근에는 이 첫 페이지에 들어가는 도메인이 1개인 경우가 매우 드문데, 별도의 reverse-proxy 를 사용하여 도메인을 통일한 경우가 아니라면 대부분 컨텐츠 전송을 위한 별도의 static 과 같은 추가 도메인을 사용하는 경우가 대부분이며 역시 이 도메인이 많을 수록 사용자는 지연을 경험하게 될 가능성이 높아진다. 

이것은 일반적인 상황이며, 만약 많은 사람이 걱정하는 한국의 국제망 트래픽의 포화 또는 이와 준하는 장애 상황이 발생하는 경우는 어떨까. 이러한 경우에는 조금 더 상황이 심각해져, DNS lookup 에 timeout 이 발생 할 가능성이 높아진다. 이 말은 곧 도메인 조회가 불가능한 상황을 말하며 도메인 조회가 불가능하다는 것은 아예 사이트에 접근이 불가능 해 진다는 말이 된다. 

아무리 사이트를 고객과 가까운 해외에 직접 구축하게 되더라도 네임서버가 한국에 있다면 이것은 상당한 지연시간을 야기하며 짧은 TTL 을 가지도록 설계 한 경우라면 더욱 더 크리티컬한 상황을 만들 수 있게 된다. 


결론적으로 글로벌 서비스를 위해서는 적어도 각 사용자에 가까운 지역에서 마치 CDN 처럼 DNS anycast 와 같은 방법을 통해 가장 근거리에 있는 네임서버 질의를 제공하는 서비스를 사용 할 필요가 있으며, 이는 서비스에 대한 사용자 지연시간을 줄이는 가장 첫 걸음이 될 것이다. 


Image from: http://blog.mailermailer.com/behind-the-scenes/improve-your-newsletter-reading-experience-with-faster-images


두번째로는 페이지에 접근하는 시간 및 페이지 정보 즉, html 을 구성하는데 필요한 서버에 대한 접근 또는 index.html 및 .js .jpg 와 같은 컨텐츠의 직접 전송이 얼마나 빠를 것인가 하는 부분이다. 당연하게 네트워크라는 것은 결국 위성을 제외하면 대륙과 대륙을 연결하는데 광섬유 케이블이나 구리선을 사용하게 마련이며 이 선의 길이가 길면 길수록, 거쳐가는 네트워크 장치가 많으면 많을수록 지연시간이 증가한다. 

이로인해 우리는 일반적으로 CDN 이라는 서비스를 사용하게 되는데, 고객과 가까이 있는 서버에 이런 컨텐츠를 캐싱 해 두고 그 서버로 고객을 유도 함으로서 보다 빠른 서비스 경험을 갖도록 하는 것이다. 고객과 가까운 지역의 위치 판별에는 다양한 방법이 사용되는데, 기본적으로는 IP 기반의 지리적 위치에 근거 하거나 고객이 사용하는 브라우저의 언어, 네트워크 기술로는 geocast 와 같은 방법이 사용되곤 한다. http://en.wikipedia.org/wiki/Geocast  

이 CDN 서비스를 사용함으로서 얻어지는 효용은 상당히 많으며 이미 오랜 기간에 걸쳐 검증되었기 때문에 별도의 추가 설명은 필요가 없지만, 중요한 것은 가격이다. 대부분의 CDN 서비스는 사전 계약을 필수로 하며, 필요한 때에 원하는 지역에 사용하기 위해서는 소정의 제약 조건이 필요한 경우가 대부분이다. 이 제약 조건들은 마치 약정과 같이 계약과 사용량에 대한 고정이 필요한 경우가 대부분이므로 사전에 잘 알아보고 적용하는 것이 필요하다. 




세번째로 데이터의 처리와 전송에 대한 부분이다. 이 부분이 바로 성능과 비용을 결정하는 지점이 된다. 이 부분은 기존의 인프라를 운용하며 적용 해 왔던 컨셉과 클라우드를 도입하게 되는 경우 고려해야 하는 컨셉이 상충되는 지점이기도 하다. 왜 그런지는 다음의 흐름을 생각 해 보도록 하자. 



Image from: http://www.greenm3.com/gdcblog/2009/12/8/amazon-web-services-economics-center-comparing-awscloud-comp.html


1. 기존 데이터 센터에 서버를 구축 하는 경우: 결과적으로 필요 수량 이상의 자원을 투입하는 것이 risk 및 무정지 운영에 중요 

- 사용자 유입량을 예측 + 20% 정도의 마진을 적용 하여 필요 리소스 규모 산정. 스펙, 수량 등 
- 서비스 증설 시점을 마크. 이 마크 지점에 도달하면 필요한 리소스를 추가 구매, 증설 
- 서비스에 대한 폭발적 요구 증가 대비 불가 - 하드웨어 배송, 국내 최소 3주  해외 최소 1.5개월 이상 
- 서비스에 대한 유입량이 기대에 못미치는 경우 투자비용 회수가 거의 불가능 
- 상당한 투자비용, 서비스 성공 또는 실패 하더라도 현재와 같은 모바일 중심의 폭발적 트래픽 증가에는 손실이 예상 

하지만 서비스의 성공/실패는 아무도 예측 불가능하며, 이 말은 즉 유입 트래픽에 대해 예측 하는 것 자체가 어불 성설이 된다. 
예측을 하는것이 불가능 하다면 초기 투자 비용을 넣는 것이 무의미 하며, 유입된 사용자 만큼의 비용을 지불하는 구조가 더욱 매력적일 수 있다는 개념을 정립하는 것이 필요하다. 

만약, 필요한 서버가 5분이면 조달 되고, 업그레이드 역시 10분내에 가능하며 다 쓰고 나면 렌트카 처럼 반납 할 수 있는 서비스가 있다면 어떨까. 



Image from: http://www.greenm3.com/gdcblog/2009/12/8/amazon-web-services-economics-center-comparing-awscloud-comp.html



2. 글로벌 public cloud 사업자를 사용하는 경우: 

- 필요한 서버를 5분내에 조달 할 수 있으므로 트래픽 유입이 증가하게 되면 그저 필요한 수량 만큼 늘리면 된다. (scale-out) 
- 필요 없으면 반납이 가능하므로 트래픽 유입이 줄어들면 필요 없는 수량만큼 줄이면 된다. (scale-in) 
- 사용한 서버의 "시간" 만큼만 지불하면 된다. 
- 서비스 사용량의 폭발적인 증가시 유입량에 따른 유연한 응대가 가능하다. 
- 서비스가 실패하게 되면 모두 종료하여 비용을 더 이상 지불 하지 않는다. 
- 사용한 만큼 지불한다는 말은 사용하기 전에는 낼 돈이 없다는 말과 같다. 즉, 투자비용이 없다. 
- 원하는 지역에 수시간 내로 동일한 형태로 배포가 가능하다. 


국내/국외를 막론하고 사업을 추진하기 위해서는 "예산"을 편성해야 하므로 2번의 방법은 종전의 업무 방식과 맞지 않는다. 하지만 이성적으로 생각해 보면 전기세와 같은 가변적인 금액을 기업에서는 지금도 처리하고 있다. 전화비, 전기세, 수도세 및 기타 가변적인 금액들. 기본적으로 사용한 만큼 지불하는 구조를 가질 수 있는 인프라에 대한 지불 구조를 도입하게 되면 종전의 예측 불가능한 것에 대한 억지 예측을 통해 모자르거나 부족한 부분이 발생할 여지를 없앨 수 있으므로 기업입장에서는 비용 관리에 매우 효율적이다. 

요새 사장님 타고다니실 의전 차량을 누가 구매하나. 리스하지. 



성능에 있어서는, scale-up 은 언제나 한계가 있다. 아무리 대기업이라도 수퍼돔이나 크레이를 들이는 것은 쉬운 의사결정도 아니거니와 비용도 만만치 않다. 최근의 서비스 전체 성능 개선은 '분산' 에서 이루어 지는 것이며, 서비스의 각 구성요소를 얼마나 잘 분산 했느냐에 따라 효과적인 장애 대응과 높은 수준의 서비스 성능을 구가 할 수 있는 것이다. 아울러 여기에 분산이 고정된 수량으로 획일적이지 않고, 유입량에 따라 그 크기를 조절 할 수 있다면 또 이렇게 조절하는 것이 비용과 직결되어 있다는 것을 인지 하는 순간 수퍼돔을 사용 할 서비스는 줄어든다. 




하여, 국내 기존 사업자와 global cloud 서비스 공급자간의 의사 결정 사항에서의 결론은 이제 다음과 같다. 

a. 두가지의 개념을 각각 적재 적소에 적용 했을때 과연 어떤것이 저렴하냐. 
b. 각 클라우드 서비스 공급자 중 그러면 어떤 서비스를 사용해야 할 것이냐. - 종량제를 하면서 성능 좋고 서비스 많은 공급자? 



서비스를 운용할 때 경험은 정말로 매우 중요하다. 경험있는 개발자와 기술자는 없어서는 안될 매우 중요한 자원이며 이들은 서비스에 지대한 공헌을 해 왔다. 하지만 최근에는 이들의 경험이 오히려 기업의 비용 절감에 방해가 되는 경우를 적지 않게 본다. 어쩌면, 어떤 기업은 이러한 비용을 절감해야 할 필요가 없을지도 모른다. 누군가는 이런 흐름이 필요없는 공부를 만들어 내고 종전에 지키고 있던 자리를 위협하고 있다고 느낄지도 모르겠다. 하지만 새로운 것에 대한 배척 보다는 이를 받아 들이고, 기존의 것과 대비하여 어떤 부분이 좋고 나쁜지를 판단하되 올바른 척도를 가지는 것이 중요하다고 생각한다. 경험을 새로운 것을 배우는데 사용하고, 그를 통해 더 나는 경험을 재창조 하는 것. 

이미 수많은 스타트업은 위의 내용에 대해 너무나 잘 알고 있으며, 글로벌을 향한 도전의 중심에 있다. 간혹 해외 서비스라 사용을 못하겠다거나 하는 이상한 애국심을 만나곤 하는데, 그럼 Linux 나 Windows, BSD, Oracle, 또 기타 다양한 하드웨어 벤더들은 왜 사용한다는 말인가. 그런 소리 할거면 커널 개발 트리에 공헌이라도 좀 하던가... 


길게 썼지만 어쨌든 핵심은 국내에서도 저렴한 비용으로 시작된 좋은 아이디어가 인스타그램이나 페이스북, 트위터 같은 서비스로 성장 하는 것이 아닌가 한다. 성공의 발판으로 삼는 도구는, 무조건 나에게 좋은 것이어야 하기 때문에 위에 길게 써놓은 흐름을 기준으로 여러분에게도 좋은 것이 무엇인지를 생각 해 보면 좋겠다. 그를 통해 대박나는 서비스가 사방에서 봇물 터지듯 터지기를 바라마지 않으며. 




Image from: http://www.businessweek.com/articles/2013-01-11/a-distributed-denial-of-service-attack-isnt-an-act-of-civil-disobedience



다 써놓고 보니 뭔가 산으로 간 것 같은 느낌. 

(>ㅇ_ㅇ)> 

(younjin.jeong@gmail.com, 정윤진) 

A podcast about Cloud & DevOps

Techs


(younjin.jeong@gmail.com, 정윤진)


AWS의 Kingsley Wood 에 의해 공개된 팟캐스트의 링크입니다. 클라우드 컴퓨팅의 여러가지 사용 예와 DevOps 에 대한 주제로 이야기 되네요. 


"

In this episode our discussion revolves around the impact of Cloud Computing on Innovation. AWS's Kingsley Wood shared with us a number of examples of the innovative ideas leveraging on Cloud. We also talked about DevOps and the future of Cloud in Asia. Enjoy and comment please.

"


http://asiacloud.org/index.php/2012-07-17-08-33-19/podcasts 



http://ec.libsyn.com/p/c/6/d/c6db7b8f0470c11d/Kingsley_Wood_Interview_Edited_V3.2.mp3?d13a76d516d9dec20c3d276ce028ed5089ab1ce3dae902ea1d01cf8e33d8c1583a47&c_id=6156527 







(younjin.jeong@gmail.com, 정윤진)