AWS, cloud, Netflix ...
얼마전 AWS architecture 교육을 갔다왔습니다.
Partner사들을 위주로 한 교육을 갔다왔구요 문외한이었던 저는 가서 이게 정말 된다고? 하는 체험을 하고 왔습니다. 2010년 Hadoop하던 생각도 나더군요. 아마존에서 썼다고 하는게 단골멘트 였거든요.
AWS(Amazon Warehouse Service)도 역시 fault tolerant한 서비스입니다.
인스턴스에 문제가 생기면 새로운 인스턴스를 올려 문제를 해결하는 구조이며
기본 architecture 개념은 이중화, loose coupling입니다.
auto scaling을 이용해 부하가 있을 때는 수평적 확장이 가능하며 scale in/out 모두 제공합니다.
Amazon서비스에대한 상세 소개는 aws.amazon.com/ko/솔루션명에 정말 교재보다 잘 나와있더라구요.
여기서 확인하시면 됩니다.
교육 중에 흥미로웠던 것은 Netflix의 chaos monkey입니다.
chaos monkey는 장애상황을 대비해 항상 장애상황을 만들어보는 넷플릭스 오픈소스 소프트웨어 인데요,
IBM에서도 갖다 쓸만큼 괜찮은 오픈소스인가봅니다.
DR훈련을 자동으로 하고있는 셈이지요.(고릴라도 있다더군요! 센터DR쯤 될까요?)
클라우드에 알맞은 architecture로 구성을 하고, 그 cloud의 최대 장점을 극대화하는 시스템입니다.
Netflix는 AWS가 오즈의 마법사의 오즈에 비유되며 아주 새롭게 기존 지식과 노하우는 통하지 않는다고 말합니다. (원문링크 : http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html)
(클라우드는 그런구조가 아니다, 이중화 해야한다 아무리 말해도 돈없다며 안해놓고 정기PM을 못하게 하는 고객도 있는데... Netflix는 아름다운 고객이네요..... 그런데 클라우드를 쓰려면 이정도는 해줘야 될 것 같습니다.)
모니터링이나 어플리케이션 관점에서 보면 클라우드 관점이 되면 모니터링 툴이나 인프라 서비스 어플리케이션도 역변의 시대가 올 것 같습니다.
역시 오즈로 가야 하니까요.
모니터링은 사용자가 어플리케이션을 무리없이 이용할 수 있는 관점에서만 동작합니다.
사용자가 원하는 것은 빠르게 끊김없이 서비스를 이용하는 것입니다.
서비스는 fault tolerant한 구조로 이중화, loose coupling 되어 있다고 가정합니다.
AWS로 하면 active-active로 N중화 되어 있는 EC2인스턴스가 죽으면 재빨리 동일한 조건의 인스턴스 하나 재생산해서 올리면 됩니다. loose coupling되어 있어 SQS를 이용해서 서비스 영향이 미미하다고 하죠. 기존에 standby로 h/w를 별로도 구비해놓고 변경 시에 그때그때 동일하게 변경해두어야 했던 것과는 비용과 에포트면에서 확연히 차이가 납니다. 어떤게 더 빠르게 대응할 수 있느냐는 기존 standby가 더 빠르다고 할 수 있겠으나 n중화 되어 있으면 문제되지 않지요.
여기서 모니터링 포인트는 인스턴스 문제 시 정상적으로 새로 생겼냐 정도 입니다.
M1. 인스턴스가 죽는지 모니터링 하다가 죽었을 때 fail over 됐는지 확인
서버에 memory가 80%이상이면 서비스가 현저히 느려지는 시스템이 있습니다.
그렇다면 memory가 72%일 때 EC2인스턴스를 하나 더 생성하고, 30%이하일 때는 인스턴스를 줄이는 형식으로 AWS Auto Scaling을 설정합니다.
여기서 모니터링 포인트는 memory 사용률과 정상적으로 auto scaling되었나 입니다.
M2. 특정 trigger 사용률을 모니터링하여 임계값도달 시 auto scaling 됐는지 확인. 복합 trigger도 제공.
클라우드의 비용에 대한 기본 개념은 쓴만큼 지불한다입니다. 쓴 만큼 비용을 부과하기 위해서는 사용량에 대한 모니터링도 필요합니다.
M3. 사용량 모니터리오
AWS에서는 아래와 같이 사용량을 모니터링 하며 사용량 별 비용을 제공합니다.
- ELB(Elastic Load Balancing) : 시간당, 대역폭 당 비용 발생
- EIP(Elastic IP) : EC2에 할당되지 않으면 비용발생, 100번 재할당마다 비용 발생
- CloudWatch : 세부모니터링, 커스텀 측정치에대한 비용 발생
- S3, S3 RRS, Clacier : 저장량, 1천 요청당, 데이터 전송 1GB당 비용 발생
- RDS : 옵션으로 Provisioned IOPS 제공, 지역 밖 데이터 전송, 예약 결제 모델 제공
- DynamoDB : Provision IOPS용량 10단위 쓰기, 50단위 읽기 당 비용, 색인 스토리지 1GB당 비용, 데이터 전송량 1GB당 비용, 예약 결제 모델 제공
- R53(Route 53) : 호스팅 Zone 장, 표준 쿼리 1백만 건당, 지연 시간 기반 쿼리 1백만 건당, AWS 내 동작 여부 확인에 비용
- CloudFron : 밖으로 나가는 대역폭 1GB당, 1만 요청당, 엣리 로케이션 별 요금
- SQS : API 호출 1백만 건당
- SNS : HTTP, 이메일 알림 1십만 건당, SMS 알림 1백건 당
- SES : 이메일 1천 통당
클라우드에서 모니터링의 관점은 과금을 위해 필요한 지표인지, fail over나 scale in-out에 필요한 지표인지가 기준이 됩니다.
이제 모니터링의 관점으로 모니터링 항목을 파악했으니 클라우드에서 제공해야하는 서비스에 대해 알아보겠습니다.
클라우드라서 해줘야 하는 서비스가 있습니다. 배포&변경관리.
배포 및 변경이 있더라도 fail over, auto scaling을 해줘야 하니까요.
관리도구 상에서 배포와 변경이 일어나야 합니다.
S1. 배포 및 변경을 제공한 툴에서 하는 정책 제공
요즘 화두가 된 DR도 클라우드에서라면 더욱 저렴한 비용으로 제공 할 수 있겠지요.
카오스 몽키나 카오스 고릴라같이 DR테스트 서비스도 제공함이 좋습니다.
S2. DR & DR 테스트
클라우드 최대 장점 중에 하나인 Scale in-out이 되는 와중에 데이터는 손실이 없어야 합니다.
스토리지 데이터가 손상되지 않도록, 손상되더라도 복구 가능하도록 해야겠지요.
S3. 스토리지 확장 및 데이터 보관 정책 제공.
AWS에서는 아래와 같은 스토리지 옵션을 제공합니다.
- 블록스토리지 : 인스턴스 스토리지, Amazon EBS
- 객체 스토리지 : Amazon S3, Amazon Glacier, Amazon CloudFront
- 동기화 볼륨 : AWS Storage Gateway
- 관계형 데이터베이스 : Amazon RDS
- NoSQL 데이터베이스 : Amazon DynamoDB
- 인 메모리 캐시 : ElastiCache
- 콘텐츠 캐시 : Amazon CloudFront
저장이 불필요 할경우 휘발성인 EC2 인스턴스 스토리지, 기존 하드디스크처럼 사용 할 경우는 EBS, 데이터 내구성이 필요 할 경우 S3, 아카이빙이 필요할 경우에는 Glacier를 사용합니다.
글의 초반에 클라우드 아키텍쳐로 이루어져 있다는 가정하에 시작했습니다. 그러나 현실은 잘 돌아가는 애플리케이션을 클라우드에 이점에 적합하도록 당장 바꿔주는 고객은 없겠지요
그래인지 클라우드를 개발자 입장에서 쓰기 쉽게 만드는 것을 가장 우선순위에 두는 경우도 있구요. 당장 바꿀 수 없다면 최소한 기존의 것을 대체하여 바꾸기 쉽도록 서비스를 제공해야 합니다
AWS에 특화된 각종 어플리케이션도 loose coupling을 돕고 운영 상 필요한 서비스를 제공합니다.
S4. 클라우드 아키텍쳐와 클라우드 운영을 도울 애플리케이션 서비스를 제공
참고로 AWS 어플리케이션 서비스는 아래와 같습니다
- Amazon SQS(Simple Queue Service) : 컴퓨터간 메시지 이동 시 호스팅 큐를 제공. 자동화된 워크풀로우 구축 지원
- Amazon SNS(Simple Notification Service) : 클라우드에서 알림을 쉽게 설정, 운영, 전송 지원(CloudWatch 이벤트 발생 시 메일 전송, 큐로 전송)
- Amazon SES(Simple Email Service) : 대용량 트랜잭션 이메일 전송
- Amzaon SWF(Simple Workflow Service) : 애플리케이션 처리 단계 조정 및 분산 실행 상태 관리, Decider(결정로직)와 Activity Worker(실제 작업 수행) 작성 필요
- Amazon CloudSearch : 클라우드 종합 관리형 검색 서비스
클라우드로 넘어가는 것을 netflix에서 말한 것과 같이회오리 바람이 오즈로 데려다 놓은 것으로 생각하고 기존과 다르게 그 기술의 최대 이점을 살리는 노력이 필요할 것 같습니다.
