AWS Architecture

Contents

AWS 구조를 분석한다. 하지만 아마존에서 일해본 경험이 있는 것도 아니니 AWS 구조 자체를 명확히 분석한다라기 보다는, 드러나는 모습을 보고 이러한 구조를 가지고 있겠거니 라고 짐작하는 정도라고 보면 될 것 같다. 왜 이런걸 하느냐면 ? 클라우드 인프라에 대해서 깊이 생각해 보기 위해서다. 내 분석 결과가 정확한지 아닌지는 별로 중요하지 않다.

각 기능에 대해서는 대략 기술할 것이다. 기능에 대한 상세한 기술은 따로 위키페이지를 만들 계획이다. 별 관심없는 기능은 건너뛸 것이다.

AWS는 4단계의 계층 구조를 가진다. CNODE(Computing Node), MNODE(Management Node), SNODE(Storage Node), 네트워크 장비 등 물리적인 장비로 구성이 된다. 명확한 구조는 알 수 없지만 나름대로 예상해서 설계해볼 수는 있겠다. Cloud architecture에서 고민해봐야 겠다.

AWS는 전 세계를 대상으로 클라우드 서비스를 제공하는 글로벌 서비스로 원할한 서비스 제공을 위해서 주요 지역별로 물리적인 데이터 센터를 가지고 있다. 이 물리적인 데이터 센터를 Region이라고 한다.

2013년 12월 현재 9개의 region을 운용하고 있다.

안타깝게도 한국 region은 없어서 일본 tokyo리전을 이용해야 한다. 네트워크 지연이 100ms 정도로 꽤 큰편이라서 실시간성이 중요한 서비스에 사용하기에는 껄끄러운 면이 있다. 한국 region을 만들 계획은 없는 것 같다.

Region은 하나 이상의 Avaliability zone(이하 AV zone)으로 구성된다. AV zone은 Region을 구성하는 물리적인 네트워크 단위라고 보면 될 것 같다. 즉 하나의 region은 두 개이상의 분리된 물리적인 네트워크 단위로 구성된다는 의미다. 유저는 인스턴스를 AV zone에 분산해서 배치하는 것으로 가용성(avaliability)를 높일 수 있다. 하나의 AV zone에 물리적인 문제가 생기더라도 다른 AV zone을 이용해서 서비스를 계속할 수 있다.

웹서비스의 경우 인스턴스를 AV zone-1과 AV zone-2에 두고, ELB로 묶는 구성을 생각해 볼 수 있다.

컴퓨팅 서비스다. 하이퍼바이저위에서 core와 메모리를 할당해서 가상머신(VM)을 제공한다. 웹 인터페이스를 이용해서 필요한 자원(Core 갯수, 메모리 크기, 네트워크 서비스, 기타 할당하고픈 AWS 자원)을 설정하면 수분이내로 VM을 띄울 수 있다.

단지 VM만 띄우는 거라면, 가상화 기반의 서버호스팅과 그다지 다를바가 없을 것이다. EC2를 이용하면, 아마존의 다른 가상화 자원들을 사용할 수 있다. ELB, Auto scaling, 추가적인 Storage, 모니터링, SimpleDB와 RDB같은 데이터베이스, 검색엔진(SimpleSearch), 보안 등의 서비스가 그것이다.

EC2의 핵심은 "온디멘드"와 "탄력적인 자원 운용"일 것이다. 이 중 관심을 가질만한 기능은 "탄력적 자원 운용"일 것이다. EC2는 CloudWatch라는 모니터링 서비스를 제공하는데, 이 모니터링 서비스를 기반으로 Auto scaling이 기능한다. 즉 네트워크 트래픽, 디스크 I/O, CPU 사용율 등을 모니터링 하다가 사용자가 정한 값에 따라서 탄력적으로 VM의 갯수를 (자동으로)늘였다 줄였다 할 수 있다. 유저가 몰리면 그에 맞게 VM이 늘어나고, 유저가 줄어들면 VM도 따라서 줄어든다. 유저는 필요 할때, 필요한 만큼만 자원을 사용할 수 있다.

Elastic IP는 네트워크 서비스로 유저가 IP를 소유할 수 있다. 소유한 IP는 리전(Region) 내에서 자유롭게 attach, detach 할 수 있다. 자세한 내용은 EIP 분석문서를 참고하기 바란다.

오브젝트 스토리지로 객체(파일)을 저장하고 검색하고 꺼내기 위해서 사용한다. 각 객체는 버킷이라는 단위에 저장이 된다. 객체를 논리적으로 관리하기 위한 관리 단위라고 볼 수 있겠다. 오픈소스 진영의 swift와 비슷하다.

EC2, EBS 와 함께 가장 중요한 컴포넌트라 할만하다.

아마존의 전략은 "필요한 시간만큼 필요한 자원을 사용할 수 있게 한다" 라는 일관된 정책을 가지고 있는데, S3에서도 찾아볼 수 있다. S3는 객체에 대해서 99.999999999%의 내구성과 99.99% 가용성을 가지게 설계했다. 데이터를 완전하게 보관해주겠다라는 이야기인데, 그럴려면 비용이 증가한다. 어떤 데이터는 그다지 중요하지 않아서 굳이 비용을 들여서 순도 100%의 신뢰도를 필요로 하지 않을 수도 있다.

예를들어 동영상이나 이미지의 섬네일은 원본을 이용해서 재현할 수 있기 때문에, 그다지 중요한 데이터가 아니다. 이런 데이터는 RSS(낮은 중복 스토리지)옵션을 이용해서 저렴한 스토리지에 보관할 수 있다. 아마 비교적 저렴한 하드웨어에 복제수를 줄여서 비용을 낮춘 스토리지로 서비스 하지 싶다.

아마존 입장에서는 성능이 좀 떨어지는 장비들을 이용해서 돈을 벌 수 있어서 좋고, 고객들은 비용을 아낄 수 있어서 좋다.

2012년 8월현재 RSS가 일반 스토리지에 비해서 1GB당 약 25% 에서 최대 35% 정도 더 저렴하다.

데이터백업은 기업의 가장 큰 고민 중 하나일 것이다. 이 서비스를 이용하면, on-premises 데이터를 EBS snapshot 형태로 S3에 저장할 수 있다. 고객은 가용성을 높이기 위한 값비싼 투자 없이 99.99%(AWS의 주장이다)의 가용성을 가지는 백업 서비스를 받을 수 있다.

대량의 데이터 보관에 고민하는 기업이라면, 사용해볼만한 서비스인 것 같다. 개인적으로도 흥미가 가는 서비스인데, 시간을 내서 본격적으로 분석해 봐야 겠다.

Elastic Block Storage의 줄임말이다. VM에 블럭 스토리지를 제공한다. 탄력적인 볼륨의 제공을 위해서 로컬 스토리지가 아닌 원격 스토리지를 제공한다. 스토리지가 원격에 있기 때문에 네트워크로 연결만 되어 있다면, VM의 위치에 상관없이 볼륨을 붙일 수 있다. 볼륨 인터페이스로 iSCSI를 이용할 것으로 생각된다.

볼륨이 Cnode와 분리돼있기 때문에, Cnode의 문제로 VM이 죽더라도 다른 Cnode에서 VM 인스턴스를 띄우면 즉시 복구가 가능하다. 또한 스토리지 자원의 효율적인 사용이 가능하다. 예컨데, POD(lack)단위로 block storage를 두면, 스토리지 구성과 관리는 쉬워지는데 자원의 효율적인 사용이 힘들어진다. lack의 cpu 자원과 memory 자원이 충분한데 storage가 부족한 경우 cpu와 memory자원을 낭비하게 된다. 반대로 storage는 충분한데, cpu와 memory자원이 부족하다면 storage를 낭비하게 된다. EBS에서라면 이런 걱정 없이 효율적으로 storage를 사용할 수 있다.

문제는 어떻게 구성할 것인가 하는거다. 중앙 집중화된 스토리지를 만든 다음에 iSCSI 인터페이스만 제공하면 간단하게 구성할 수 있을 것 같지만 대역폭과 응답속도, 안정성 거기에 비용가지 고려해야 하기 때문에 많은 고민이 필요한 서비스다. 10000개의 VM이 스토리지에 요청을 보낸다고 생각해 보라.

클라우드 소프트웨어라면 당연히 EBS를 지원해야 할 것 같지만, cloudstack은 EBS 스타일의 스토리지를 지원하지 않고 있다(2012년 8월 현재). 클라우드스택은 cluster 단위로 스토리지를 관리하기 때문에, 클러스터들 끼리 스토리지를 공유할 수가 없다. 때문에 다른 클러스터로 VM을 마이그레이션이 쉽지 않다. - 볼륨을 복사해야 한다. !! -

EBS에 구현에 대한 기술적인 내용은 EBS architecture에서 자세히 다룰 계획이다. VPC를 이용하면 가상의 네트워크를 만들 수 있다. 즉 퍼블릭 클라우드 상에, 가상 네트워크를 구성해서 고객이 원하는 다양한 네트워크 토폴로지를 구성할 수 있다. 예를 들어 서브넷을 나눠서 서비스 VM은 DMZ에 두고, 보안에 민감한 데이터베이스 VM은 방화벽 너머에 두는 구성이 가능하다. 또한 가상 사설 네트워크(VPN)을 둘 수도 있다.

VPC 서비스를 구현하는 것은 도전이 될 수 있다.

Flat network 모드(L3 네트워크 모드라고 부르기도 하는)와 같이 L3 네트워크 토폴로지를 가지는 경우 결국 L3위에서 L2 네트워크를 구성해야 하는데, 네트워크 터널링과 같은 그다지 익숙하지 않은 기술을 기술을 사용해야 한다. 아예 처음부터 VLAN을 이용해서 L2 네트워크 모델로 구현할 수도 있는데, VLAN을 사용하면 유연함을 포기해야 한다. VLAN을 대체하는 다른 기술들을 사용할 수도 있는데, 역시 익숙한 기술이 아니라는 문제가 있다.

Cloudstack의 최신버전인 3.0.4에서는 openvswitch를 지원한다. openvswitch를 이용하면 L3 over L2 기능을 이용해서 - 다시 말해서 터널링 - VLAN을 대체할 수 있다. Cloudstack 3.0.4로 테스트를 해봐야 겠다. openvswich를 이용하면, availability zone 서비스 구현도 가능하다. 서로 다른 zone에 vm이 위치하더라도 L3 over L2로 같은 account의 vm을 묶어줄 수 있기 때문이다.

아예 VPC Zone을 따로 구성하는 간단한 방법이 있기는 하다. AWS역시 하나의 네트워크에 L3와 L2를 모두 두는 복잡한 방법대신, VPC Zone을 따로 구성한 것으로 추측한다. 이렇게 추측하는 이유는 다음과 같다.

AWS VPC 사용 메뉴얼을 보녀 "지역별로 AWS 계정당 최대 5개의 Amazon VPC를 생성할 수 있다"로 VPC 생성에 제한을 두고 있다. 한정된 VLAN 자원을 효율적으로 사용하려다 보니 이런 제한을 두는 것 아닌가하는 생각이 든다. "Amazon VPC당 최대 20개의 서브넷을 생성할 수 있다"라는 제한 역시 VLAN 자원을 아끼기 위함이 아닌가 싶다. "Amazon EC2 클러스터 인스턴스와 마이크로 인스턴스는 현재 VPC에서 사용할 수 없습니다"라는 제한도 있는데, L3 네트워크 토폴로지를 가지는 EC2 zone과 달리 VPC는 분리된 L2 네트워크 토폴로지 zone을 구성했기 때문으로 보인다.

VPC의 구현을 위해서는 GRE, STT, VxLAN등의 tunneling 프로토콜의 응용이 필요할 것 같다. 최근 (2012년 1월 8일 기준)Openvswitch는 GRE, STT, VxLAN을 모두 지원한다. tunneling 기술에 관한 자세한 내용은 tunneling에서 살펴볼 계획이다.

로드밸런싱 서비스다. 일반적으로 생각하는 로드밸런싱 서비스와의 차이점이라면 "온디멘드", "Auto-scaling"일 것이다. 중요한 기술은 "Auto-scaling"이다. 유저는 CloudWatch를 이용해서 LB 그룹의 네트워크, 디스크, Cpu, 메모리 자원을 모니터링 할 수 있는데, 이 모니터링 정보를 이용해서 Scale-in, Scale-out 조건을 정할 수 있다. 결국 ELB는 Auto-scaling + CloudWatch + LB 기술 셋의 조합이다.

ELB는 AWS ELB 분석문서에 자세히 정리했으니 참고바란다.

DNS 서비스다. AWS의 VM 인스턴스가 실행되면 Public IP와 Private IP 두개를 가진다. Private IP는 내부 통신을 위해서, Public IP는 인터넷 통신을 위해서 사용된다. 그런데 이들 IP 주소는 고정자원이 아니고 유동자원이다. VM reboot과 같은 상태변화에 따라서 IP가 바뀔 수 있다. 한정된 IP자원을 효율적으로 사용하기 위한 정책이다.

IP가 수시로 변경될 수 있으므로 AWS는 도메인이름을 제공한다. Private IP와 Public IP 모두가 변경될 수 있으므로 Public DNS, Private DNS 모두를 서비스한다.

어차피 DNS 서비스를 하고 있으니, 이를 유저 서비스로 전용하기 위한 기술적인 문제는 없는 셈이다.

RDS(Relation Database Service)는 RDBMS 서비스다. 클라우드에서 온디멘드로 관계형 데이터 베이스를 사용할 수 있다. Mysql, Oracle, Microsoft SQL등을 지원한다.

설치 및 설정 노력이 필요 없으며, 복제(리플리케이션), 패치, 백업등의 관리작업역시 최소한의 노력으로 수행할 수 있다.

RDS와 비교하자면 클라우드 분산환경에 적합하 데이터베이스 서비스라고 볼 수 있다. 인터넷 서비스가 발전함에 따라서 기존의 RDBMS로 처리하기에는 효율이 떨어지는 데이터가 늘어났다. 대량의 데이터를 빠른시간에 (비교적 저렴한 비용으로)처리하기 위해서 분산확장이 가능한 데이터베이스 시스템을 제공한다.

최근들어 주목 받고 있는 NoSQL 데이터베이스를 사용하고 있다.

개인적으로 관심이 가는 서비스다.

Storage gateway는 on-premises 소프트웨어 어플라이언스 즉, 설치형 소프트웨어 어플라이언스다. Storage gateway 서비스를 받으려면, 회사내에 소프트웨어 어플라이언스를 설치해야 한다는 점에서 다른 AWS 서비스와는 서비스 구조에 차이가 있다.

기업은 Storage gateway를 이용해서 기업의 데이터를 AWS의 S3에 백업할 수 있다. 변경된 데이터만 전송하는 증분 스냅샷 기능을 이용해서 효율적인 백업이 가능하다.

Copy-on-write 방식의 파일 시스템을 지원하는 소프트웨어 어플라이언스를 이용해서 개발가능 할 것으로 보인다. kvm의 qcow2 image 포맷의 경우 incremental snapshot 기능을 제공하므로, kvm와 qcow2 기반으로 서비스 설계가 가능 할 것 같다. 직접 설계/테스트를 해볼만한 주제다.

ElasticMapReduce 서비스가 있다. 막대햔 양의 데이터를 처리하기 위한 인프라다.

맵리듀스 그 자체로만으로 의미가 있긴 하겠지만 SQS, S3, SimpleDB, SimpleSearch등의 서비스와 하나로 묶였을 때 진정한 의미를 가진 서비스다. (S3에 저장된)대용량의 로그를 맵리듀스를 돌려서 simpledb에 넣은 다음, 색인 데이터를 만들어서 정보를 제공하는 식의 응용이 가능 하다.

지금은 관심이 없어서 패스.

Mechanical Turk 서비스가 있다. 꽤 독특한 서비스인데, 작업처리를 VM에 분산하는 대신 사람에게 분산하는 서비스다. 컴퓨터로는 처리가 곤란해서 사람이 작업을 해야 하는 경우에 유용한 서비스다.

예를 들자면 문서 번역작업이라든지, 멀티미디어 데이터 분류 같은 작업들이다. 이전에 음악 서비스쪽 일을 한 적이있는데, 음악에 대한 메타정보를 입력하는게 중요한 작업이었다. 이런 작업은 컴퓨터로는 할 수가 없기 때문에, 결국 사람을 고용해서 작업을 맡겼다. 이를테면 Mechanical Turk로 이런 류의 작업을 대행해 주겠다는 거다.

어떻게 보면, 일용직 근로자 사무소와 비슷한 개념의 서비스다. 별 서비스가 다 있다.

SQS(Simple Queue Service)가 있다. 메시징 인프라를 제공하는 서비스로 소프트웨어를 설치할 필요 없이 즉시 메시지 서비스를 이용할 수 있다.

무제한의 큐와 메시지를 만들수 있다. 큐에 저장되는 메시지는 개당 64kb까지 지워한다. 대게의 경우 충분한 크기인 것 같다. 분산환경에서 메시지를 전달하는 것을 목적으로 하고 있기 때문에, 동시 읽기와 전송 읽기 단위의 락 기능을 제공한다.

별로 관심이 없다.

별로 관심이 없다.

IAM(Identity and Access Management)서비스가 있다. 사용자의 AWS 서비스와 리소스에 대한 접근과 권한을 제어하는 서비스다. 새로운 사용자를 생성, 키, 암호 생성, 클라우드 서비스와 자원에 대한 접근/권한 관리가 가능하다.

단순한 인증 서비스가 아니다. AWS는 여러 단계의 계층 구조를 가지고 있으며, 각 계층 마다 다양한 클라우드 리소스가 있다. 이들 리소스는 API를 통해서 개인 유저에게 혹은 public 유저에게 서비스된다. 따라서 모든 리소스를 묶을 수 있는 인증/권한 프레임워크를 가지고 있어야 한다.

예를들어 cloudformation의 경우 VM, availability zone, storage, network service 기타 Saas 애플리케이션의 접근/권한을 통합수 있어야 하는데, IAM을 통해서 가능하다.

IAM의 account 관리 구조는 다음과 같다.

가장 기본단위는 user이고, user의 묶음인 group이 있다. AWS account는 하나 이상의 그룹을 가질 수 있다. 예컨데, 관리자 그룹, 개발자 그룹, 테스트 그룹등으로 나누어서 접근자원과 권한을 제어할 수 있다. 또한 유저는 하나 이상의 그룹에 포함될 수도 있다.

IAM은 유저와 그룹 관리를 위한 CLI 명령을 제공한다.

1. iam-usercreate : 유저를 만든다. 유저를 만들면 access key와 secret access key를 반환하는데, 이 키들을 이용해서 API를 호출할 수 있다.
2. iam-userlistbypath : 유저 목록 확인.
3. iam-groupcreate : 유저 그룹 생성.
4. iam-groupadduser : 그룹에 유저를 추가
5. iam-useraddpolicy : (자원에 대한 접근)정책에 유저를 추가한다.
6. iam-userlistpolicies : 정책 목록과 정보를 출력한다.
7. iam-useruploadpolicy : 정책에 유저를 추가한다. 정책을 파일로 만들어서 관리할 수 있다는 점이 iam-useraddpolicy의 차이점이다. 정책을 쉽게 파일로 만들 수 있도록 web ui를 제공한다.

모든 정보는 JSON 형식으로 입출력된다.

IAM으로 관리할 수 있는 자원은 EC2, RDS, S3, SimpleDB, SNS, SQS, VPC, Auto Scaling, Route 53, CloudFront, ElasticMapReduce, Elastic Load Balancing, CloudFormation, CloudWatch, Elastic Block Storage 등이다. 이들 자원에 대한 CRUD를 권한을 설정할 수 있다. 모든 자원에 대한 권한을 관리하기 때문에 좋은 구조를 설계할 필요가 있다.

CloudWatch호 Auto-scaling 서비스를 가능하게 해주는 중요한 서비스다. CPU, Memory, Disk I/O, Network Traffic, SQS 요청 수 등을 모니터링 하면서 조건을 만족하면 자동으로 scale-out, scale-in을 수행한다. 탄력적으로 서비스 상황에 대응할 수 있게 해주며, 꼭 필요한 만큼만 자원을 소모하도록 계획을 세울 수 있다.

동영상 처리 서비스를 하고 있다고 가정해 보자. 분산처리를 위해서 요청 메시지를 SQS로 보내고, 여러 개의 영상 처리 VM 인스턴스에서 메시지를 받아서 처리를 한다. 평소에 3개의 VM 인스턴스로 충분히 서비스를 했는데, 갑자기 영상 처리 요청이 증가한다. 그렇다면 VM 인스턴스의 CPU 점유율이 올라갈 것이다. 혹은 SQS 큐에 메시지가 쌓일 것이다. 이 정보를 모니터링 해서, VM 인스턴스를 늘려줄 수 있다.

AWS에서 제공하는 모니터링은 모니터링 자체 보다는 오토스케일링을 지원이 목적이다. 다음과 같은 한계가 있다.

• 매트릭이 제한된다 : EC2의 경우 기본 10개의 메트릭의 정보를 수집할 수 있다. 많은 것 같지만, 운영체제/애플리케이션 영역에서의 정보를 수집할 수 없기 때문에, 모니터링 시스템 구축에는 한계가 있다. 커스텀 매트릭을 추가할 수 있기는 한데, 이렇게 할 거면 그냥 새로 만드는게 낫다.
• 수집 주기 제한 : 보통 1분, 5분의 수집주기를 가지는데.. 매트릭에 따라서 (주기를 짧게 하려하면) 추가 비용이 들어간다거나 아예 주기를 변경할 수 없거나 하는 등. 설정이 유연하지 않다.
• API 호출 제한 : API를 무한대로 호출할 수 있는게 아니다. API 호출 제한이 걸려있는데, 호출 제한 값을 초과할 것 같으면 AWS와 따로 협상을 해야 한다. 비용 추가 여부를 떠나서 부담이다.
• 이벤트 알람 설정 제한 : AWS의 이벤트 알람 설정의 목적은 오토스케일링을 위한 거다. 본격 모니터링 시스템을 구축하기에는 한참이나 부족하다.
• 어차피 시스템을 개발해야 한다. : AWS의 cloudwatch를 이용해서 구축한다고 하더라도, 이벤트 알람 정책의 적용, 주기적인 매트릭 수집, 데이터베이스로의 적재, 모니터링 결과를 관찰하기 위한 대쉬보드 개발 등등을 개발해야 한다. 어차피 개발할 거라면, 제한적인 AWS cloudwatch를 이용하느니, 새로만드는게 깔끔하다.

개인적으로 zabbix를 이용해서 모티터링 환경을 구축한 경험이 있다.

CloudFormation 서비스가 있다. CloudFormation은 자동으로 소프트웨어를 배포하기 위한 서비스다. 이 서비스를 이용하면 운영체제와 서비스 소프트웨어, 설정파일, 패키지 관리기능까지 포함하는 인터넷 서비스를 배포할 수 있다. 예를 들어 wordpress를 배포한다고 가정해 보자. 먼저 APM(Apache + PHP + Mysql)을 설치해야 한다. 다음 wordpress를 다운로드 받아서 설치한 다음, 메뉴얼을 보면서 설정값을 변경해야 한다. 비숙련자에게는 어려운 과정이며, 숙련자라고 할지라도 귀찮은 과정이다.

CloudFormation을 이용하면 몇 가지 매개변수(데이터베이스 패스워드나 서비스 포트 번호)같은 것을 입력해주는 정도로 즉시 wordpress 서비스를 할 수 있다. 또한 아마존의 여러 서비스들까지 함께 묶어서 템플릿을 만들 수 있다. wordpress 템플릿을 만들 때, availability zone 선택, ELB, RDS, Auto-scaling등 아마존의 서비스를 연동할 수 있다.

웹 서비스를 쉽게 전개하기를 원하는 일반 사용자와 더불어, 자신의 서비스를 개발하기 원하는 개발자까지를 끌어들일 수 있는 서비스다. 클라우드 생태계를 만들어 준다는 측면에서 가장 중요한 서비스 라고 생각한다.. 클라우드 서비스를 프로그래밍하기 위한 툴과 라이브러리들을 제공한다. AWS의 API와 SDK, 라이브러리는 이미 업계 표준의 대우를 받고 있다. 클라우드 소프트웨어 회사나 개발자들은 AWS의 API와 SDK를 이용해서, 클라우드 소프트웨어를 개발하고 이를 배포할 수 있다. 이러한 모든 작업이 온디멘드 방식으로 이루어진다. 데이터베이스가 필요하다면 RDS와 SimpleDB를 사용하면 된다. SQS를 이용해서 메시지 처리를 위한 백엔드를 만들고 Elastic MapReduce를 이용해서 처리하고 SimpleSearch를 이용한 검색 서비스를 만들 수 있다. 배포는 CloudFormation을 이용한다. Scaling을 걱정할 필요도 없다. 이러한 인프라를 직접 개발하고 그 위에 서비스를 올린다고 생각해보라. 많은 startup 회사들이 아마존을 이용하는 이유다.

1. 탄력적인 용량 설계
2. 온디멘드
3. 불필요한 초기 투자비 제거
4. 필요한 만큼의 자원 사용. 쓴만큼 지불
5. 자동화된 전개와 재사용

아마존의 인프라와 서비스들은 위의 조건을 만족하기 위한 결과라고 판단된다. 클라우드의 기준이라고 보면 되겠다.

제레미 리프킨은 나는 소유한다 그러므로 존재한다라는 산업시대의 명제가 나는 접속한다 그러므로 존재한다로 바뀔거라고 예언했다. 소유의 시대에서 접속의 시대로 패러다임의 전환이 일어난다는 얘기다. 그리고 그의 예언은 이루어졌다.

IT 분야에서의 소유에서의 접속으로의 패러다임이 실현된게 클라우드라고 볼 수 있을 것이다. 그렇다고 해서, 소유에 대한 욕구와 필요가 사라져서 모든 자원이 클라우드로 옮겨가는 그런일을 발생하지 않을 것이다. 소유에 대한 욕구와 필요는 앞으로도 계속 있을 것이다. 다만 IT 자원의 많은 부분이 클라우드화 되고, 사용자는 접속의 형태로 자원을 사용하게 될 것이다.

물론 비용을 아낄 수 있다. 하지만 비용만으로 접근하면 굳이 클라우드를 사용할 필요는 없다. 클라우드의 핵심은 서비스 변화에 적극적으로 적응할 수 있다는데 있다. 자원은 클라우드의 그것을 빌려다 쓰면 된다. 비용 혹은 VM의 전개속도만 생각한다면, 글쎄 아마 호스팅비용에 있어서 별차이 없지 싶다. 전개속도 ? 호스팅의 가상화 제품을 사용하면 5분안에 VM 인스턴스를 띄울 수 있다. 서버호스팅도 1시간 안에 끝낼 수 있다.

클라우드에서 빌려쓰는 자원을 CPU와 메모리로 한정한다면, 호스팅과 차별점이 없다. 하지만 지금의 퍼블릭 클라우드는 네트워크 서비스, 스토리지 서비스, Monitering, Auto-scaling 같은 인프라 서비스, CloudFormation, SQS, MapReduce, CloudSearch, RDS, SimpleDB와 같은 Saas, Paas를 함께 서비스 함으로서, 호스팅과 차별할 수 있다.

클라우드 서비스라는 것이 사용하기가 애매모호한 측면이 있다. 예컨데 SimpleDB나 MapReduce, Queue 서비스에 수요가 얼마나 있을까 하는 거다. 서비스 제공자 입장에서 말하자면 수요를 예측해서 서비스를 개발할 수 있을 것인가 하는 문제다.

내 생각에 클라우드는 서비스 수요를 예측해서 서비스를 개발하는 방식으로의 접근은 힘들 것 같다. 수요를 만들 수 밖에 없다. "우리 이러이러한 서비스 있는데, 잘 사용하면 이러이러 한 가치를 얻을 수 있을거야" 이런식의 접근이다. 아마존만 봐도 이런식으로 접근을 해서 시장을 선도하고 있다. 만약 아마존이 수요를 예측해서 서비스를 만들려고 생각했었다면, 지금의 AWS는 없었을 것이다. 수요자체가 없었으니까.

뭐.. 마케팅 마인드로의 접근 같은 거다. NoSQL 서비스를 하는데, 만들어 놓고 NoSQL을 마케팅하는 거다. NoSQL 앞으로 필요합니다. 써보시겠습니까 ? 써보려고 하니 까다롭지 ? AWS에서는 원클릭으로 가능 합니다.

넓게 본다면 클라우드 자체가 하나의 서비스들이다. 따라서 클라우드에서 서비스하는 여러 가지 서비스들은 서로 유기적으로 엮일 수 있어야 한다.

예컨데 동영상 서비스를 한다고 가정해보자. 유저가 올린 고용량의 동영상을 저용량 데이터로 바꿔서 스트리밍을 하는 서비스다. 유튜브와 같은 종류의 서비스라고 생각하면 되겠다.

AWS위에서 대략 아래와 같은 방식으로 작동할 것이다.

1. 유저의 동영상(이하 데이터)을 업로드 한다.
2. 데이터는 S3에 저장된다.
3. 데이터의 메타정보는 SimpleDB에 저장된다.
4. 데이터의 위치와 메타 정보를 SQS를 이용해서 Queue에 보낸다.
5. 데이터를 처리할 몇 개의 VM들이 있다. 이 VM들은 Queue에서 요청을 꺼내와서 처리한다.
6. CloudWatch는 SQS의 Queue를 모니터링 한다.
7. 유저 요청이 늘어나서 Queue에 서비스 관리자가 정한 개수 이상의 메시지가 쌓이면, Auto-scaling 서비스를 이용해서 데이터 처리 VM의 인스턴스를 늘려서 늘어난 유저 요청에 대응한다.
8. SimpleSearch는 SimpleDB의 메타정보를 읽어와서 색인파일을 만든다.
9. 유저의 피드백 정보들(동영상에 대한 댓글, 평가, 선호도 등...)은 SimpleDB에 쌓인다.
10. MapReduce를 이용해서 유저의 피드백 정보를 분석해서 새로운 정보를 만든다.

SQS, SimpleDB, CloudWatch, MapReduce, Auto-scaling가 모두 연결되어 있음을 알 수 있다. 여기에 이들 자원을 제어할 수 있는 API, SDK, 개발 툴들이 제공되면 개발자 생태계까지 완성된다.