아마존은 기존에 자신들의 인프라 운영의 Know-How를 한단계 발전시켜 또 다른 비즈니스 모델을 생성해내었다. 바로 아마존 웹서비스이다. SDK를 활용하여 개발을 해본사람, 웹서비스를 이용하여 개발을 해 본 사람은 아주 쉽게 아마존의 인프라를 사용하여 새로운 자신들의 비즈니스 적용 시킬 수 있도록 하였다. 물론 유료다!!
국내의 닷컴들은 현재 각종 서비스들의 API를 오픈하고 있지만 인프라에 접근은 아직 미비 하며, 반내로 국내 IDC 사업자들은 인프라의 접근은 아직은 오프라인적으로 되거나 KT-ICS처럼 거의 70%이상의 커스토마이징을 요구하는 Closed-SDK형태 이다. 이런 상황에서 아마존의 웹서비스는 내눈에 확들어 왔다!
그러면 아마존 웹서비스를 좀더 자세히 살펴 보자!
아마존 웹서비스 내역
o Amazon E-Commerce Service(ECS) : 아마존의 제품을 SP의 사이트를 통해 판매 가능하게 하고 이때 생기는 수익의 10%를 공유
o Amazon Elastic Compute Cloud(EC2) : WCS와 비슷하나 수동으로 웹 컴퓨팅파워를 다이나믹하게 사용 가능하게 하는 서비스
(세컨드라이프 클라이언트 프로그램 다운로드)
o Amazon Flexible Payments Service(FPS) : 사람과 컴퓨터, 컴퓨터와 컴퓨터, 사람과 사람 사이에 돈의 흐름을 관리해주는 웹 서비스, 신용카드 이용, 에스크로 서비스, 도토리처럼 중간 매체를 사용하는 서비스 까지 개발 가능함, 전달되는 돈의 량에 따라 과금
o Amazon Mechanical Turk(MTurk) : 사람의 손을 타야 되는 서비스를 건당 작업료를 지불 할 수 있도록 할 수 있는 서비스
(음성파일을 텍스트로 변화하는 서비스, 이미지를 보고 수작업으로 태깅을 하는 서비스)
o Amazon Simple Storage Service(S3) : 아주 간단하게 스토리지를 사용하는 서비스, 스토리지는 월 130원/GB, 트래픽 월 150원/GB, API 호출회수는 월 9월/만 건
(한컴의 오픈 오피스가 이 서비스를 이용 중)
o Amazon Simple Queue Service(SQS) : 256K의 메시지를 Queuing 할 수 있는 서비스, 만 건당 천원, 트래픽 요금 별도
o Alexa Web Services : Alexa의 웹 페이지 등급 서비스를 검색, 웹 페이지 이미지, 순위 등을 웹 서비스 형태로 제공
아마존 웹 서비스에 대한 ZD-Net의 기사 내용
웹 서비스를 막 시작하려는 단계에서 우선 필요한 것은 아이디어를 구체화하는 작업일 것이다. 그러나 사용자의 attention 을 얻고 사용자에게 유용한 서비스를 제공하기 위해 화면을 설계하고 여러 가지 장치들을 구성하는 일과 실제 웹 서비스를 제공하는 것 사이에는 매우 큰 간극이 존재한다. 바로 시스템을 꾸미고 확장성 및 가용성을 확보하고 시스템을 운영하는 작업 등이 필요하다.
웹 시스템의 확장성에서 문제되는 부분은, 필요한 시스템 용량이 시간에 따라 매우 가변적이어서 불과 몇 개월 사이에 두 배 이상의 용량이 필요할 수 있으며, 충분한 용량을 확보하더라도 평균 70% 의 용량은 그냥 대기 상태에 있게 된다는 점이다.
아마존은 이러한 문제들을 해결하는 서비스들을 제공한다(라고 광고한다). 아마존 웹 서비스는 크게 EC2/S3/SQS 세 가지로 구성되어 있으며 이를 통해 가상화된 서버/스토리지/메시징 서비스를 제공한다. 메시징에 대해서는 약간의 설명이 필요한데, 간단히 얘기하면 메시지를 생성하는 Producer 와 소비하는 Consumer 가 있고 이 둘 사이에서 안정적인 메시지 배달을 보장해주는 것이 메시징 시스템의 역할이다.
AWS 에서는 서버/스토리지/메시징 아키텍처를 구축하고 용량을 추가하거나 제거하는 작업 등이 웹 인터페이스를 통해 이루어지도록 자동화되어 있으며 거의 실시간으로 추가/제거 작업이 일어난다. 이를 통해 AWS 는 매우 높은 수준의 Utilization, Scalability, Availability 를 보장하는 시스템 인프라 서비스를 제공한다.
AWS 를 사용하여 웹 서비스를 하고 있는 GigaVox 사 관계자의 설명(또는 광고)에 따르면 (GigaVox 는 많은 사람들이 알고 있는 IT Conversations (http://www.itconversations.com) 의 모회사이다) IT Conversations 아키텍처에서 웹서버와 데이터베이스는 직접 GigaVox 가 운영하지만 스토리지와 mp3 다운로드는 EC2/S3/SQS 를 사용하도록 되어 있다. 그래서 GigaVox 는 서비스 시작에 필요한 시간을 줄일 수 있었고, 시스템 인프라 운영에 들어가는 노력과 비용을 줄일 수 있었으며 가변적으로 용량을 늘이거나 줄일 수 있는 있었다고 한다.
현실적으로 스타트업 컴패니가 높은 가용성을 보장하며 서비스 규모의 확장에 바로 대응할 수 있는 시스템 인프라를 꾸미고 운영하는 것은 매우 힘들기 때문에 AWS 는 아마존과 스타트업 컴패니가 서로 Win-Win 할 수 있는 서비스라고 할 수 있을 것이다.
추가 참고자료 : http://www.veracious.info/378
SQS에 대해서만 좀더 살펴보면...
SQS는 다양한 시스템 간의 메세지를 전달하는 중계 역할을 할 수 있다.
일례로 외국 같은경우 의료 EDI시스템을 운영할때 EDI의 기본적인 메세지를 SQS를 활용하자는 의견이 있다.
이는 SQS가 가지는 중립성과 보안성, 확장성 등 때문이다. 물론 아마존의 모든 웹 서비스가 가지는 특성중에 하나지만 단순하고 직관적인 인터페이스 또한 큰 장점으로 작용한다.
SQS의 특성을 좀더 자세히 살펴 보면 우선 큐는 이론상으로 무한대로 확장가능 하며, 보관 할 수 있는 메세지 또한 무한대이다. 하나의 메세지는 256K를 넘을 수 없으며, 검색 가능한 메세지 일 경우 약 8K로 한정된다. 한 사용자 큐를 사용하고 있으면 Lock상태가 되고 사용이 끝나면 Lock이 자동으로 풀린다. 물론 Lock을 거는 시간 또한 설정이 가능하고, Lock을 걸지 않을 수도 있다. 메세지는 기본적으로 추가, 읽기, 삭제 의 3가지 기능만 가진다. 모든 메세지는 저장된지 15일까지 보관되며 그 이후에는 자동으로 삭제 되어진다. 메세지를 읽기했을때는 저장한 순서대로 나오는 것이 원칙이며 그렇지 않을 수도 있다. 모든 메세지는 하나의 서버에 보관되는 것이 아니라 다수의 서버와 다수의 노드에 복사되어 보관되어 진다. 이를 통해 HA를 보장한다.
GIGAVOX라는 곳에서 AWS를 사용한 예 : http://www.gigavox.com/platform/technology
여러 자료를 보며 느낌점!!!
쩝!!! 우리는 왜 몬하는거야 ㅠㅠ;;;
(0) 
(0)Posted by akiss4u
