Amazon Web Services

[1]

Amazon Web Services. AWS라는 약어로도 불린다.
2012년 5월 11일부터 한국어 서비스를 시작했다.

1 개요

2006년 경부터 아마존닷컴에서 서비스 중인 클라우드 컴퓨팅 플랫폼으로, 아마존닷컴 쇼핑몰에서 추수감사절이나 크리스마스 같은 시즌마다 몰리는 트래픽을 감당하기 위해 왕창 증설해둔 서버들이 평소엔 남아도니, 이걸 밖에서 쓸 수 있는 서비스를 만들어 팔아보자는 의도로 시작했는데, 지금은 세계 1위의 클라우드 플랫폼이 되어버렸다.(...) 책이 다팔려서 빈 매대가 생기자 딴 가게에 매대를 임대할 생각을 한 아마존

이름대로 웹 서비스를 할 때 필요할 만한 온갖 서비스들을 제공하며, 서비스의 모든 기능을 API로 제어할 수 있다. 다시 말해 아마존의 모든 기능을 당신이 필요한 대로 자동화할 수 있다는 것으로, 가능한 얼마든지 사용량, 곧 비용을 줄이는 방식으로 최적화를 할 수 있다. 심지어 아마존에서도 이렇게 해서 비용 절감하는 걸 적극 권장한다! 물론 간편하게 AWS의 기능을 제어할 수 있는 웹 콘솔도 제공하는데, 이것조차 AWS에서 제공하는 API로만 되어 있다. 그래서 오히려 웹 콘솔에서 못하는데 API로 할 수 있는 것도 굉장히많다. API 호출은 기본적으로 HTTP나 SOAP로 이루어지며, Java나 Python, PHP, Ruby, .NET 등에서 쓸 수 있는 라이브러리 및 샘플 코드도 제공한다.# 일단 문서를 보자. 그리고 느끼자.(...)

힘들게 비싼 돈주고 서버 사고 IDC에 넣고 골치썩을 일 없이 쓴 만큼만 아마존에 내면 땡이기 때문에, 가진 게 아이디어하고 두뇌밖에 없는 실리콘 밸리 워너비 벤쳐기업들이 사업 시작할 때 가장 많이 쓰는 서비스가 되었다. 심지어 AWS 위에다가 클라우드 서비스를 재구성해서 다른 개발자나 기업한테 팔아먹는 식의 서비스까지 생겨날 정도가 되었으며, 개중에는 심지어 API는 있는데 AWS 웹 콘솔이 지원 안 하는 기능을 자기들이 콘솔로 만들어서 서비스하는 데까지 있다.(...) 작은 기업들만 쓰는 것도 아닌 게, 심지어 애플의 iCloud도 Microsoft Azure와 AWS 위에서 동작하는 것으로 유명하다. ?! 그리고 해외의 유명 대학에서는 연구를 위해 장비가 아닌 AWS나 Microsoft Azure를 쓰는 경우도 점차 늘고 있다.

국내에서는 스타트업 문화 자체가 약해서인지 인지도가 엄청 떨어지는 편이다. 심지어 AWS 얘기를 하면 "왜 서점회사가 그런 걸 하나요?" 하고 되묻는 경우도 있다고(...) 그래도 알게 모르게 쓰는 곳이 있다는 듯. 국내에선 수도권에 있는 IDC 하나면 대충 내수용 서비스에는 무리가 없다는 게 이유일지도 모른다. 국내에 아마존닷컴 데이터 센터가 없었다가 최근 스타트업 열풍 덕분인지 한국 수요가 급격히 늘었고, 여기에 대응해 AWS에서 2016년 서울에 Region을 설립하였다. 아마존 웹 서비스 한국 블로그

참고로 나무위키의 메일 서버가 이곳을 사용하고 있다.

2 제공하는 서비스

제공하는 서비스를 목록으로 정리하면 다음과 같다.

컴퓨트 카테고리

• EC2: 가상 서버 서비스
• EC2 Container Service: Docker 컨테이너로 구축하는 EC2 서비스
• Elastic Beanstalk: 웹 앱의 배포 및 관리 서비스
• Lambda: 이벤트가 발생하면 코드를 실행하는 서비스

스토리지 카테고리

• S3: 파일 스토리지 서비스. 정적 웹 서버 기능도 제공.
• CloudFront: 컨텐츠 배달 서비스(CDN)
• Elastic File System: 사용량에 따라 과금되는 블록 스토리지. NFS기반.
• Glacier: 백업 및 아카이브 서비스
• Snowball: 대규모 데이터 이동 서비스. 일종의 (하드디스크) 택배 서비스이다.
• Storage Gateway: 로컬(사무실 등)의 저장소와 AWS의 저장소를 동기화해주는 서비스.

데이터베이스 카테고리

• RDS: RDBMS서비스. MariaDB와 Oracle 등 유명한 데이터베이스를 제공한다.
• DynamoDB: NoSQL 데이터베이스. DocumentDB의 일종이다.
• ElastiCache: Memcached/Redis API를 제공하는 인-메모리 데이터베이스 서비스
• Redshift: 데이터 웨어하우징. 정말 엄청난(페타바이트 규모)의 데이터를 SQL로 다룰 때 사용한다. EMR은 아예 Hadoop이란 게 차이점.
• DMS: 데이터베이스 마이그레이션(이동) 서비스

네트워크 카테고리

• VPC: 가상 네트워크 구축 서비스. EC2 서버들간에 격리 구역을 만들 때 사용한다.
• Direct Connect: 고속 전용 네트워크 연결 서비스. 일종의 보장된 대역폭을 제공한다.
• Route 53: DNS서비스

개발 도구 카테고리

• CodeCommit: Git 리포지토리 서비스
• CodeDeploy: DevOps 서비스. 자동화된 코드 배포와 통합을 지원.
• CodePipeline: Release Software using Continuous Delivery

관리 도구 카테고리

• CloudWatch: 로그(Log) 관리 서비스. EC2, Lambda, S3 등 다른 서비스에서 발생하는 로그 기록을 통합 관리.
• CloudFormation: 클라우드 구성 배포 서비스. 위 서비스의 '조합' 템플릿을 입력해 클라우드 인프라 자체를 패키징한다. Elastic Beanstalk와 비슷한 서비스.
• CloudTrail: Track User Activity and API Usage
• Config: Track Resource Inventory and Changes
• OpsWorks: Automate Operation with Chef
• Service Catalog: Create and Use Standardized Products
• Trusted Advisor: 컨설팅 서비스. AWS서비스를 최적화하고 결함을 찾아내는 등의 서비스. 일종의 기술지원 서비스이다.

보안 및 인증 카테고리

• Identity & Access Management(IAM): 인증키 발급 서비스. 위의 서비스들을 연계해서 사용하기 위해 일종의 유저를 생성하는 서비스이다.
• Directory Service: Acticve Directory 서비스. LDAP서비스이다.
• Inspector: Analyze Application Security
• WAF: 웹 방화벽 서비스
• Certificate Manager: SSL 인증서 관리 서비스. HTTPS 보안 웹 서버나 커스텀 도메인으로 CloudFront 서비스를 사용할 때 여기서 인증서를 등록한다.

분석 및 통계 카테고리

• EMR: Hadoop 서비스
• Data Pipeline: Orchestration for Data-Driven Workflows
• Elasticsearch Service: 루씬(Lucene)기반 검색엔진 서비스. 자연어검색이나 전문검색(Full text search)가 필요할 때 사용한다.
• Kinesis: 실시간 스트림 데이터 분석 서비스.
• Machine Learning: Build Smart Applications Quickly and Easily

IoT 카테고리

• AWS IoT: MQTT, WebSocket등 사물인터넷용 인터페이스 제공 서비스. 통상적인 HTTP 요청이 아닌 것에 대한 API Gateway 서비스이다.

게임 개발 카테고리

• GameLift: 세션 기반 멀티플레이어 게임 개발 서비스

모바일 카테고리

• Mobile Hub: 모바일 앱 제작, 테스트, 모니터링 서비스
• Cognito: 인증 및 유저 데이터 동기화 서비스
• Device Farm: iOS 및 안드로이드용 애플리케이션(웹 앱 포함) 테스트 서비스
• Mobile Analysis: Collect, View and Export App Analysis
• SNS: 푸시 알림 서비스

애플리케이션 카테고리

• API Gateway: RESTful API 구축 및 관리 서비스. API Endpoint를 정의해 각각의 서비스에 연결할 수 있다. 일종의 URL기반 라우터
• AppStream: 저지연 애플리케이션 스트리밍 서비스. 일종의 라이브스트리밍 서비스이다.
• CloudSearch: 클라우드 기반 검색 엔진. Apache Solr기반인데 Solr이 Lucene기반으로 만들어져 있어 결과적으로 위의 ElasticSearch와 비슷하다. ElasticSearch에 비해 좀 더 사용하기 편리하고 규모가변성 있는 검색 시스템을 구축할 수 있다. 그러나 가격은 ElasticSearch에 비해 다소 비싸다.
• Elastic Transcoder: 동영상 변환(트랜스코딩) 서비스. 고화질 동영상의 저화질 버전을 생성하거나 다른 동영상 포맷으로 변환해준다. S3와 연계하여 사용.
• SES: 대량 이메일 발송 서비스.
• SQS: 메시지 큐 서비스. RabbitMQ나 ZeroMQ와 비슷한 일을 한다.
• SWF: Workflow Service for Coordinating Application Components

기업용 애플리케이션 카테고리

• WorkSpace: 가상 데스크톱 서비스
• WorkDocs: 문서 공유 서비스. 구글독스 비슷한 서비스이다.
• WorkMail: 기업용 이메일 서비스

2.1 Amazon Elastic Compute Cloud (EC2)

일종의 가상 서버. AWS에서 컴퓨팅 카테고리의 근간을 이루는 서비스이자 AWS에서 가장 많이 사용하는 서비스이다.

CPU 사용량 그런 거 없이 기본적으로 켜놓은 시간을 기준으로 과금하는 구조다. 다만 새 서버 인스턴스를 생성하고 프로그램 올리고 구동하는 게 전부 제공되는 API로 다 되기 때문에 Auto Scaling 서비스와 연계해서 트래픽이 몰리면 인스턴스를 자동으로 늘려서 대응하고 트래픽이 줄어들면 만들었던 인스턴스를 없애는 일을 할 수 있다. 성능별로 micro/small/large/xlarge 등으로 세분화되는데, 주의할 것은 성능 좋은 인스턴스를 쓸수록 그만큼 과금액이 기하급수적으로 늘어난다. 때문에 작은 서버 여러 대로 분산처리를 하는 것이 필수고, 고성능이 필요한 연산이 있으면 필요할 때만 잠깐씩 서버를 생성했다가 필요한 계산 끝내고 다시 없애버리는 식으로 사용시간을 아껴야 한다. 시간당 요금을 결재하는 방법부터 다양한 방식의 사용/과금법이 존재한다.

또한 고려할 점이 데이터 트래픽요금이다. 현재는 인터넷구간으로 월1GB까지 무료, 10TB까지는 GB당 0.09달러등으로 책정되어있다. 그러니 대용량 데이터용을 생각할때는 회선비용도 고려해야한다. 정적 콘텐츠 제공용으로는 S3+CloudFront, 대규모 데이터 이동시에는 Import/Export Snowball등의 다른 서비스를 사용해서 비용을 아끼자. AWS에서 EC2서비스는 제공하는 성능 대비 가장 비싼 서비스라고 생각해야 한다. 소규모에서는 EC2가 저렴하다가 대규모로 서비스가 발전하면 갑자기 확 비싸지는 게 EC2의 특징이다.

• 온디맨드 인스턴스 (On Demand)

사용한 만큼 과금된다. 단, 과금의 단위가 1시간 이기 때문에 1초를 사용해도 1시간 어치가 과금된다. 단점 아니냐고? 다른 회사의 호스팅 서비스는 1초를 사용하려 해도 1개월어치를 선불로 낸다. 이보다 더 짧은 주기로 과금을 제어하는 곳은 2016년 현재까지는 구글 컴퓨트 엔진밖엔 없다. 구글은 분 단위.

그리고 인스턴스(서버)를 켜 놓은 시간으로 과금되기 때문에 고성능 인스턴스를 켜 놓고 잊어버리면 월말에 어마어마한 요금 폭탄을 맞게 된다. 서버에 접속한 시간 기준이 아니라 켜 놓은 시간 기준이다. 따라서 안 쓰는 인스턴스는 반드시 Stop시켜야 한다.

Stop한 인스턴스도 EBS스토리지(인스턴스가 저장된 가상 디스크) 1GB당 0.1달러(SSD기준)를 매달 지불하므로 다시 켤 일이 없는 인스턴스는 Terminate시켜서 완전히 삭제하고 해당 인스턴스가 사용한 모든 EBS볼륨도 역시 지워줘야 한다. 보통 Terminate시키면 EBS볼륨도 자동으로 삭제되지만 옵션에서 이걸 막을 수 있게 돼 있으므로 확인은 필수.

그러나, 이런 번거로움을 감수할 만한 엄청난 매리트가 있으니 바로 가격. 제일 비싼 인스턴스인 m4.10xlarge가 시간당 약 2.5달러 내외로 이용할 수 있는데 이 놈의 스펙은 40코어 제온 CPU+160GB RAM이다. 오타가 아니다. 마흔 개의 제온 코어에 백 육십 기가바이트 램을 가진 서버를 시간당 3천원 정도 내고 쓸 수 있다! 그럼 제일 싼 t2.nano의 시간당 비용은? 0.0065달러... 한달내내 켜놔도(약 750시간) 약 5달러 낸다.

EBS볼륨은 유지한 상태로 인스턴스 타입을 바꾸는 게 가능하기 때문에 제일 싼 t2.nano인스턴스로 먼저 시스템을 구축하고 나서 정상 작동 여부를 테스트한 뒤 위의 고성능 인스턴스로 바꿔서 재부팅하는 방법으로 요금을 아낄 수 있다. 다른 구식 호스팅 서비스에서는 서버를 두 대를 결제해서 데이터를 복사하는 방법(데이터 마이그레이션)이 유일한데 이렇게 하면 서버 두 대의 한 달치 요금을 중복 결제하게 되어 오히려 요금이 늘어난다.

• 스팟 인스턴스 (Spot Instance)

현재 사용되고 있지 않은 EC2자원을 경매로 싸게 낙찰받아 이용할 수 있다. 자기보다 높은 가격을 부른 사람이 나타나면 약 2분의 유예 기간을 준 뒤 인스턴스가 내려간다. 가격이 애초에 저렴한 t2.micro같은 인스턴스는 이 플랜으로 이용할 수 없고 고성능 인스턴스만 경매 입찰을 할 수 있다.

언제 인스턴스가 내려가 버릴지 모르는 서비스인데 불안해서 어떻게 쓰냐 하고 생각할 수 있는데, 보통 스폿 인스턴스는 작업 결과를 S3버킷 같은 데 쌓는 방식으로 사용한다. 그러다가 인스턴스가 내려가 버리면 위의 온디맨드 인스턴스를 대신 켜서 하던 일 계속한다. 관리 비용이 증가하는 건 단점이지만 고성능 인스턴스의 스폿 경매 가격은 한가한 리전일 경우 반값 이하로 싼 경우가 많기 때문에 관리 비용을 충분히 상쇄하고도 남는다.

• 예약 인스턴스 (Reserved Instance)

사용할 기간(1년 혹은 3년)과 사용량(No/Partial/All Upfront)을 예약하면서 초기 선납비용을 내면, 시간당 사용료를 할인받는 방식. 완전 선납 플랜을 사용하는 경우 시간당 사용료가 0이 된다. 가장 작은 t2.nano 인스턴스의 1년 완전 선납 가격은 2015년 12월 현재 38달러. 이게 월간이 아니라 연간 사용액이다!

단, 이 예약 인스턴스는 '계약'의 형식이라 원칙적으로 환불이 안 되며 일단 결제하면 계약 기간동안 매월 할부 방식으로 정액으로 돈이 빠져나간다. 인스턴스를 꺼놨어도 이 돈은 계약 만료시까지 계속 청구된다. 윗 문단의 설명도 그렇고 AWS홈페이지의 설명도 저렇게 돼 있어서 마치 인스턴스를 꺼 놓으면 그 달은 결제 금액이 없는 것처럼 착각할 수 있는데 아니다. 청구서에는 매월 정액 요금이 빠져나간다. 단지 All Upfront는 일시불이고 No Upfront는 12개월 할부인 게 차이일 뿐. 원래 24시간 상시가동하는 인스턴스를 위해 있는 서비스이므로 인스턴스 사용 시간이 한 달에 300시간 미만(절반)이면 온디맨드 인스턴스를 사용하는 게 가격적으로 더 유리하다.

2.2 Amazon Simple Storage Service (S3)

쉽게 설명하면 일종의 저장 공간 무제한 웹하드 서비스이다. AWS서비스에서 EC2가 컴퓨팅 카테고리의 근간 기술인 것처럼 이 S3서비스는 스토리지 카테고리의 근간을 이룬다. 계산은 EC2에서, 저장은 S3에서 처리하는 식. 단 파일 단위 액세스만을 지원하고 블록 단위 액세스가 불가능하다. 따라서 EBS(Elastic Block Storage, 일종의 가상 디스크)를 대체하지 못한다.

무료 용량은 없고 저장 공간만큼 매월 비용을 지불해야 한다. 하지만 EC2의 EBS처럼 미리 얼마의 공간을 구매하는 형식이 아니라 사용한 만큼만 비용을 지불하는 구조이다. 비용은 저장하는 데이터의 크기, 액세스 요청 횟수, 데이터 반출(네트워크 아웃)용량 등으로 계산된다. 간단한 설정으로 정적 웹 서버를 만들 수 있다.

http와 https 둘 다 지원하므로 가급적 https를 통해 s3에 액세스하도록 하자. 단 https를 사용할 경우 URL에 제약이 걸린다. 예를 들어 my.bucket.s3.amazonaws.com 이라는 URL은 인증서 에러가 나서 https://s3-us-west-2.amazonaws.com/my.bucket 이라고 버킷 이름을 URL 뒤로 넘기면서 버킷의 리전(region)을 구체적으로 지정해야 한다. 이런 제약이 신경쓰이면 아래의 CloudFront 서비스를 사용해 커스텀 도메인을 연결하자.

S3서비스 때문에 요금 폭탄을 맞는 일은 거의 없다. 테라바이트 이상의 데이터를 S3에 업로드해야 그제야 달러 단위의 비용이 청구되기 시작하는데 개인이 그만한 데이터를 갖고 있는 것 자체가 힘들다. AWS의 악명(?)은 켜 놓고 잊어버린 EC2 서비스에서 발생한 것이다.

2.3 Amazon CloudFront

세계 어디서나 빠른 속도로 파일을 제공하도록 최적화하는 content delivery network(CDN) 서비스. 위의 S3와 연계하면 이미지 서비스의 극을 달릴 수 있다.
제공해야 하는 콘텐츠가 공개 콘텐츠이고 정적 콘텐츠이면 무료인 CloudFlare서비스가 있으므로 이쪽을 쓰는 게 유리하다. 나무위키의 콘텐츠 캐시도 클라우드플레어 서비스를 사용하고 있다. 이 서비스는 유료 콘텐츠를 제공할 때 비로소 빛을 발한다. 서명 URL이나 서명 쿠키를 사용해서 인증된 사용자에게만 콘텐츠를 배달하는 서비스를 할 수 있다.

꼭 파일 형태로 돼 있어야 서비스 가능한 것은 아니고 HTTP요청을 보냈을 때 응답이 거의 일정한 모든 서비스에 사용할 수 있다. 예를 들어 검색 쿼리가 포함된 HTTP GET 요청 등이다. 단 캐시 불일치 문제를 적극적으로 해결해주지 않으므로 동시성이 중요한 곳에서는 사용해선 안 된다.

2.4 Glacier

본격 백업 전용 스토리지. 얼핏 S3와 비슷해 보이지만 S3가 개별 스토리지를 "Bucket"이라고 부르는 데 비해 이쪽은 그걸 "Vault"라고 부른다. 고리짝 옛날옛적 테이프 백업 시스템 느낌으로 일단 데이터가 들어갈 때는 마음대로인데 나올때는 그렇지가 못하다. 그래서 애초에 이름 부터가 빙하 (...)다.

유저들이 데이터를 전송하면, 적당히 모아뒀다가, 적절한 시점에 데이터센터 어딘가에 있는 냉동(?) 서버들에 정리해넣은 다음, 해당 서버들에서 다시 냉동(?) 스토리지로 전 세계에서 엄청난 양의 백업 데이터를 꾹꾹 채워 놓고나면, 해당 서버와 스토리지를 전부 Mothball 해버린다.

이렇게 한참동안 방치(?) 하다가, 데이터 반출요청이 들어오면, 서버 전원을 켜서 파일 리스트를 보여주고, 요청한 데이터를 짱박아놓은 스토리지에서 긁어모은 다음, 다른 서버에 옮겨서 다운받을 수 있게 해 주는 식이다. 일단 파일 리스트를 보려면 서버 전원을 켜고 전기를 넣어야만 하기 때문에 파일 리스트 보는 데만도 돈을 받는다. 일단 백업해 놨다면 진짜 핵이라도 떨어지지 않은 이상 존재를 잊도록 하자. 대신, 1기가당 월 1센트 라는 놀라운 염가에 서비스된다. 한번 쳐박아두면 정말 폴아웃스러운 상황이 닥치지 않는 이상 꺼내지 않을 것들을 저장해 둘 때 유용하다.

보통 기업 사용자 외에 일반 사용자는 위의 S3 서비스와 연계해서 Glacier 서비스를 사용한다. API를 직접 사용해서 사용하기에는 상당히 번거롭기 때문이다. S3에서 라이프사이클 옵션에 '며칠 뒤 Glacier로 이동'이라는 게 있는데 이걸 설정해 주면 편리하게 Glacier를 이용할 수 있다.

2.5 Amazon Route 53

DNS 서비스. 다만 API는 제공하는데 콘솔에는 메뉴가 없어서 좀 귀찮다. 대신 이걸 제어해주는 서드파티 웹 서비스가 있다.

구입한 도메인을 AWS의 서비스에 연결할 때 사용한다. 도메인을 EC2인스턴스 또는 기타 AWS서비스와 연결하는데 꼭 Route53을 사용할 필요는 없지만 통합 관리가 가능한 장점이 있다. 다만 단순히 도메인을 IP에 연결할 목적이라면 무료 DNS업체들이 있으니 그쪽을 사용하는 게 가격적으로는 더 유리하다. 물론 로드밸런싱 등의 고급 DNS설정이 필요한 경우에는 AWS의 서비스가 저렴하다.

2.6 Lambda

일종의 앱 엔진. EC2에 올려서 서비스해야 하는 동적인 웹 서비스 부분을 여기에 올려두고 서비스할 수 있다. 꼭 웹이 아니더라도 S3에서의 트리거나 SQS에서의 메시지 수신 등 다양한 방법으로 Lambda서비스를 사용할 수 있다.

EC2에 비교해 장점은 Lambda는 해당 함수의 실행시간을 기준으로 과금한다는 것. 켜 놓은 시간이 아니다! 그래서 Lambda서비스는 사용을 안 하면 비용도 없다. 게다가 모든 고객에게(1년 체험 종료 고객 포함) 무료 용량을 제공한다. 개인 블로그 같은 매우 낮은 트래픽이 발생하는 웹 서비스를 구동할 경우 거의 무료에 가까운 가격으로 홈페이지를 운영할 수 있다. 다만 블로그 콘텐츠를 저장해야 하는 S3와 DynamoDB에서 요금이 발생하므로 완전 무료는 불가능하다. 그리고 사용 가능한 언어가 JavaScript, Python, Java 이 세 언어로 한정된다. PHP를 제공하지 않는 게 상당히 뼈아프다. PHP가 필요하면 구글 앱 엔진(GAE)을 사용할 수 있다.

저장 공간에서 비용이 발생하므로 이런 저장 공간을 무료로 제공하는 써드 파티 서비스(드롭박스 등)를 사용하면 완전무료로 운영하는 게 가능하다. 다만 S3 등의 서비스가 워낙 저렴해서 이런 식으로 비용을 줄이는 게 의미가 있을지는 미지수.

2.7 DynamoDB

MongoDB와 비슷한 NoSQL데이터베이스. 비슷한 서비스를 제공하는 Amazon RDS에 비해 가격이 매우 저렴하다. 다만 아주 소규모 데이터베이스가 필요한 경우 직접 EC2인스턴스에 MongoDB를 깔아서 운영하는 것보다 비싸질 수 있다. 참고로 1년 체험 기간 종료 고객을 포함한 모든 고객에게 25GB의 용량과 월간 2억 건 정도의 읽기/쓰기 요청에 대해서는 무료이다.

AWS에서 데이터베이스 카테고리를 대표하는 서비스이다. 다른 데이터베이스 서비스는 그냥 타사의 데이터베이스 기술을 EC2위에 얹어 놓은 것에 불과하지만 이 DynamoDB는 AWS에서 직접 지원하며 별도의 EC2인스턴스를 필요로 하지 않는다. 때문에 DynamoDB는 시간당이 아닌 사용량에 따라 과금된다.

또한 사용량이 늘어나면 자동으로 규모를 확장하고 사용량이 줄어들면 규모를 축소하는 기능이 있어서 따로 관리하지 않아도 탄력적으로 대응이 가능하다. 물론 수동으로 규모를 조정할 수도 있다.

밑의 RDS보다 다른 AWS 서비스와의 연동이 잘 된다. 예를 들어 SQS트리거라든지 Lambda연동 등.

RDBMS와 비교해 group by, order by, range query 기능이 많이 빈약하다. 보조 인덱스를 생성할 수 있고 정렬 키를 지정할 수도 있지만 인덱스 하나 추가할 때마다 비용이 청구되고 쿼리가 복잡해진다는 단점이 있다. 인덱스 복잡하게 설정하기 귀찮으면 DynamoDB의 데이터를 CloudSearch서비스와 연동시키는 방법이 있다. 이러면 적어도 '검색'하는 것은 자유롭게 할 수 있다. 다만 CloudSearch가 매달 최소 40달러 이상의 요금을 지불하므로(마이크로 검색 노드의 1개월치 요금) DynamoDB에서 테이블 풀-스캔으로 데이터를 검색하는 비용하고 비교를 잘 해야 한다. 사용자가 뭘 어떻게 검색할지 모르는 상황이라 온갖 필드에 인덱스를 주렁주렁 달아야 할 상황이라면 그 각각의 인덱스마다 비용이 청구되므로 CloudSearch가 더 저렴할 수 있다.

DynamoDB는 데이터를 샤딩(Sharding)해서 저장하는데 서로 다른 샤드에 대해서 order by를 사용할 수가 없다. 따라서 게시판 문서 데이터 같이 날짜를 기준으로 전체 레코드에 대해 order by를 할 일이 많은 데이터에 대해 DynamoDB를 사용하려면 일정 날짜 범위(일 단위를 예로 들면 20160603 이라는 '숫자')로 파티션 키(해시 키)를 생성하고 해당 해시 키의 정렬 키로 timestamp를 지정해서 쿼리하는 꼼수를 써야 한다. 이 '일별' 데이터는 같은 샤드에 저장되는 특징이 있기 때문에 년 단위 등 너무 큰 해시 키를 지정하면 DynamoDB의 성능이 크게 저하된다.

여기까지 보면 알겠지만 데이터의 '통계' 작업에는 DynamoDB가 적합하지 않다. 또한 사전에 계획하지 않은 검색 작업에도 취약하다. 데이터를 여러 기준으로 정렬하는 것도 RDBMS에 비해 아주 어렵다. 이런 게 자주 필요하면 밑의 RDS서비스를 사용하는 게 여러모로 낫다. 데이터가 특히 대용량이면 Redshift서비스를 사용해서 대규모 통계 연산을 처리할 수 있다. 극대규모 데이터는 EMR로 처리한다.

태그 검색 등 리스트에 대한 검색 작업을 처리해야 할 경우 CloudSearch를 사용하거나 자신이 직접 Reverse Index를 만들어야 한다. 다행히 DynamoDB에는 stream이라는 기능이 있어서 데이터가 변화할 때마다 Lambda함수를 호출하는 일을 할 수 있다.

2.8 RDS

MySQL과 비슷한 RDBMS서비스이다. EC2인스턴스 위에서 돌아가는 서비스이기 때문에 해당 EC2인스턴스의 시간당 요금을 지불한다. 데이터베이스 서비스 특성상 24시간 켜놔야 하므로 실험용으로 RDBMS를 사용하고자 할 경우 t2.nano인스턴스에 직접 MySQL을 깔아 쓰는 게 압도적으로 저렴하다. 이 서비스는 대용량 트래픽을 처리해야 하는 기업 사용자용이다. 혹 반드시 써야겠다면 예약 인스턴스를 구매하고 쓰도록 하자.

2.9 ElastiCache

인-메모리 데이터베이스 서비스이다. Memcached와 Redis 중 하나를 선택할 수 있다. 이것도 위의 RDS서비스와 마찬가지로 EC2인스턴스 위에서 돌아가는 것이라 시간당 요금을 내야 한다. Memcached를 선택하면 노드를 증설할수록 더 많은 사용자를 수용할 수 있고 Redis를 선택하면 노드를 증설할수록 더 빠른 응답과 강력한 안정성을 제공받을 수 있다. 보통 인-메모리 데이터베이스는 노드 하나만 써도 충분히 빠르고 안정성은 애초에 기대하지 않는 경우가 많아(안정성을 원하면 RDS나 DynamoDB를 쓴다) Memcached를 주로 선택한다.

이외에도 수많은 서비스들을 제공하며, 지원하는 서비스의 종류는 지금도 계속 늘어나고 있다.

3 배경

사족일지 모르지만 AWS가 왜 이런 무지막지한 규모의 API를 제공하게 되었냐면... 이미 아마존 자체가 이렇게 되어 있어서이다. 그러니까, 아마존닷컴 쇼핑서비스 자체가 AWS 위에서 돌아가고 있다는 소리다. 아마존의 창업자이자 CEO인 제프 베저스가 2002년 어느 날에 이런 메일을 사내에 돌렸다고 한다.

1. 모든 팀들은 데이터와 기능들을 서비스 인터페이스로 연결시켜라.
2. 팀들은 이 인터페이스를 통해서 연락해야 한다.
3. 다른 어떤 커뮤니케이션 방법도 허용되지 않는다. 직접 링크를 보내거나 다른 팀의 스토리지에 직접 엑세스 해서도 안 되며, 공유 메모리나 백도어 같은 것도 안 된다. 모든 커뮤니케이션은 네트워크를 통한 서비스 인터페이스로 이루어져야 한다.
4. 어떤 기술을 쓰든 상관없다. HTTP, Cobra, Pubsub, 독자 프로토콜...그건 상관없다. 베저스는 그런데 관심 없다.
5. 모든 서비스 인터페이스는 예외 없이 외부에서 이용 가능하게 만들어져야 한다. 그 말은 팀들은 외부 개발자들이 인터페이스를 이용할 수 있게 해야한다는 것이다. 예외는 없다.
6. 이를 실천하지 않는 사람은 누구든 해고될 것이다.
7. 읽어줘서 고맙다. 좋은 하루가 되길.

※ 출처: 스티브의 구글 플랫폼 폭언(http://eggry.egloos.com/3763434)

그래서 아마존 직원들은 열심히 아마존닷컴의 인프라를 서비스 지향 아키텍쳐로 갈아치웠다. 2006년까지. 어쩌겠어 짤리기 싫으면 해야지 자세한 내용은 출처 참조. 원 작성자인 스티비 예이그(Stevey Yegge)가 키워 기질이 다분하다는 걸 감안하고 읽자. 읽다보면 아마존도 까고 구글도 까고 MS도 까고 다 깐다는 걸 알 수 있다.

4 참조

• 아마존 웹 서비스를 다루는 기술
• 오픈튜토리얼즈에서도 동영상으로 설명되어있다.

5 국내 딜러

AWS의 비용 처리에 있어서 세금계산서가 필요한 경우 국내 딜러를 이용하면 된다.

• 메가존
• GS네오텍
• 한국호스트웨이

#!wiki style="border: 1px solid gray;padding:12px;border-top:5px solid #1266FF"
{{{+1  이 문서는 개편이 필요합니다.}}}

이 문서는 리그베다 위키에서의 수정 로그 삭제로 인해 과거 로그의 일부가 누락된 문서이며, 문서 개편이 필요합니다. 이에 대해 자세히 알고 싶으신 분은 나무위키:로그 누락 문서를 참조해 주세요. 또한 이 틀을 다실 때는, 문서 최하단에 분류:로그 누락 문서를 달아 주세요.

#!wiki style="border: 1px solid blue;padding:10px;border-top-width:8px"
로그가 누락된 본 문서의 기여자 내역은 [[2]]과 같습니다. 해당 페이지를 참조해 주세요.