Chris Choi's Blog

AWS 클라우드로 천만 명이 쓰는 서비스 만들기

with 4 comments

Naver D2 Startup Factory에서 ‘AWS 클라우드로 천만 명이 쓰는 서비스 만들기’라는 주제로 윤석찬님의 강연이 열렸습니다. AWS의 진면목을 제대로 들어볼 수 있는 자리였습니다. 강연 내용을 전해 드립니다.[1]

 

AWS 클라우드로 천만 명이 쓰는 서비스 만들기_Image 0.jpg

[Image 1]

 

(제가 덧붙인 내용은 Italic으로 표시했습니다.)

 

Region, AZ

AWS의 ‘Region’은 일종의 Data center의 묶음으로 생각하시면 됩니다. 일반적인 Data center와 다른 점은 가상화 서버들이 모여 있다는 점입니다. 수요가 있을 때마다 서버에서 가상화 해 Resource를 제공합니다. 따라서 한 Region에 존재하는 서버의 대수 자체는 큰 의미가 없습니다.

전세계에 12개의 Region이 퍼져 있습니다. 그 중 다섯 개가 아시아에 있습니다. 1월 7일에 드디어 서울에 Region이 생겼습니다.

 

AWS 클라우드로 천만 명이 쓰는 서비스 만들기_Image 1.png

[Image 1. AWS Global Infrastructure 출처: Amazon Web Services]

 

각 Region은 두 개 이상의 AZ Availability Zone 을 갖고 있습니다. 미국의 Virginia에는 5개의 AZ가 있습니다. AZ는 가용 영역으로, 흔히 말하는 Data center입니다. 서울 어딘가에도 두 개의 Data center가 있으며, 가상화 장비가 들어가 있습니다. 아무리 서비스를 잘 구성하더라도 Data center가 번개나 정전, 토네이도 등의 이유로 가용하지 않다면 서비스는 다운됩니다. 그런 문제를 해결하기 위해 전통적인 IT 환경에서는 두 개의 Data center에 같은 서버를 둡니다. HA High Availability 를 제공하기 위함이며, 대신 엄청난 비용이 듭니다. AWS Cloud에서는 하나의 Region을 물리적으로 나눠 둔 것이 AZ입니다. AWS에서는 Region이 하나의 Network처럼 보이기 때문에, 가상 자원을 손쉽게 Multi AZ로 구성해 서비스를 이용할 수 있습니다. 따라서 AWS를 사용한다는 것은 기본적으로 고가용성을 보장 받는 것입니다. Data center의 다운을 걱정할 필요가 없습니다.

 

AWS 시작하기

AWS의 강점 중 하나는 다양한 Service Catalog입니다. 거의 대부분의 업무를 수행할 수 있다고 보시면 됩니다.

 

AWS 클라우드로 천만 명이 쓰는 서비스 만들기_Image 2.png

[Image 3. AWS Service Catalog 출처: Amazon Web Services]

 

보통 서버를 추가할 때 발주해서 들여놓는 데 한 달은 소요됩니다. AWS는 관리 Console이나 API를 사용하는 Command 하나로 가상 서버를 수 분 내에 띄울 수 있습니다. 사용자가 원하는 시점에 원하는 구조로 시작할 수 있습니다.

Supercell, Yelp, Dropbox 등 유명한 Startup들이 AWS를 사용하고 있습니다. 북미 Traffic의 30% 이상을 차지하는 Netflix도 AWS를 사용하고 있습니다. AWS를 사용하는 것이 비즈니스에 유리하다고 판단했기 때문입니다.

 

[Link 1. “Video Streaming 새로운 질서, Netflix 그리는 미래]

처음으로 할 일은 EC2 Instance를 구성하는 것입니다. AWS는‘Route 53’이라는 DNS 서비도 제공합니다. (Route 53은 DNS를 운영하는 Bind의 통신 포트에서 따온 것입니다.) Route 53을 권장하는 이유는, Domain 관리 외에 Load balancing, Health check, Latency check 등을 지원하기 때문입니다.

 

Instance Type

EC2 Elastic Compute Cloud 의 Instance type은 서른 아홉 가지의 이를 만큼 다양합니다. Instance type은 Instance family, Instance generation, Instance size로 구분됩니다. ‘c4.large’의 예를 들면, ‘c’는 Instance family의 한 종류로서 ‘Compute-Optimized’, 즉 CPU 처리 속도에 우선을 두는 Instance입니다. ‘c’는 ‘3’과 ‘4’의 두 가지 Instance generation을 갖고 있습니다. Instance size는 ‘large’, ‘xlarge’, ‘2xlarge’ 등으로 구분됩니다.

‘g2.8xlarge’는 가상 CPU가 32장, GPU가 4장인 Instance type입니다. Virginia 기준으로 한 시간에 2.6달러입니다. 알파고를 상정해 50대의 g2.8xlarge를 띄우면 가상 CPU가 1,600개, GUP가 200개가 됩니다. 한 시간에 130달러면 알파고 수준의 시스템을 사용할 수 있습니다.

모든 가상 자원들은 API로 구성되어 있으며, 다음과 같이 Command으로 호출할 수 있습니다.

=========================================================================

[AWS 기동]

ec2-run-instances ami-978d91fe  -n 50  –instance-type g2.8xlarge  –region us-east-1

[AWS 중지]

ec2-stop-instances i-10a64379

=========================================================================

 

사용자가 증가해도 간단한 Scale-up을 통해  CPU와 Memory를 올릴 수 있습니다. 기존의 Data center에게는 쉽지 않은 일입니다. 물리적 장비에 CPU, Memory를 올리는 것은 간단하지 않습니다. 서버를 구매해 넣어야 합니다. 그러나 Cloud는 매우 쉽습니다. Instance type을 변경하고 Rebooting만 하면 됩니다.

Instance Type은 업무나 서비스, Work load에 맞게 선택해야 합니다. T2의 가격이 상대적으로 낮습니다. CPU 사용량이 대체로 일정한 경우 저렴하게 사용할 수 있습니다. 단, T2는 CPU 사용량이 더 필요하면 주어진 Credit에서 차감합니다. 따라서 평상시에 일정하다가 일시적인 사용량이 많은 경우에만 유효합니다.

 

Database

이슈가 발생했을 때 Web Server의 문제인지 DB의 문제인지 인지가 어려울 수 있습니다. Architecture변경을 통해 기능 별로 Instance의 역할을 나누도록 합니다. 가상 서버에 DB를 직접 설치할 수도 있고, RDS를 이용해 RDB 관리 서비스를 사용할 수도 있습니다. RDS는 Backup도 해 주므로 DB 서버 관리가 필요 없습니다. NoSQL 서비스인 DynamoDB, DW를 위한 Redshift 등의 선택지도 있습니다.

Aurora DB MySQL Tuning 만든 Database입니다. Amazon 분산 Storage 강하므로, MySQL 분산 Storage 개조해 기존 MySQL 비해 성능을 5 이상 개선했습니다.

요즘은 NoSQL의 인기가 높습니다. RDB와 NoSQL 간에 고민할 때가 있습니다. 처음부터 꼭  NoSQL을 선택할 필요는 없습니다. RDB는 여전히 개발자와 Community가 많으며, 거의 대부분의 Work load에 최적화 되어 있습니다. 일반적인 Application은 읽기가 많고 쓰기가 적은데, 이런 경우는 고민 없이 RDB를 사용해도 괜찮습니다.

읽기보다 쓰기가 많다면 NoSQL을 고려해 볼 수 있습니다. AWS는 DynamoDB라는 NoSQL 서비스를 제공합니다. DynamoDB의 유래는 Amazon 쇼핑몰입니다. 사용자들이 온라인 쇼핑을 할 때 대부분 상품을 검색하고 살펴보다가, 그 중 소수의 상품만이 주문으로 연결됩니다. 즉, RDB로 서비스가 가능하다는 의미입니다. 그러나 장바구니는 반대입니다. 장바구니에 이것 저것 추가하거나 삭제하지만 잘 보지는 않습니다. RDB로 서비스가 안 됩니다. 이를 위해 2000년대 초반에 Key-Value Store를 사용했으며, DynamoDB의 탄생으로 이어졌습니다.

DynamoDB가 다른 NoSQL 서비스와 다른 점이 있습니다. 대부분의 NoSQL 서비스는 Read와 Write의 회수가 비슷하거나 Write의 회수가 많을 때 좋은 성능을 보입니다. Read가 많은 서비스를 돌리면 RDB보다 성능이 떨어질 수 있습니다. 이에 비해 DynamoDB는 Read와 Write의 비율을 조정할 수 있습니다.

 

Instance 부하 방지와 성능 향상

Scale up을 했는데도 문제는 발생할 수 있습니다. 이 때는 서버를 늘려, 즉 Scale out을 통해 Work load를 분산해야 합니다. 그리고 Load balancing을 위해 Elastic Load Balancer 를 앞에 둘 수 있습니다. 기존 무리 환경에서 L4 Switch와 비슷한 기능을 합니다. 다만, ELB는 소프트웨어적으로 동작하며, 스스로 확장 (Scale out) 하는 장점이 있습니다. Database도 Active-Standby로 구성해 가용성을 높일 수 있습니다.

서버의 Work load가 높아지면 시간 당 과금액이 높아집니다. 그 중에서도 서버의 File I/O Control의 비용이 높아집니다. Image, Javascript 등 정적 File들은 서버에 존재하면 부하가 됩니다. 되도록 Application만 남기고 나머지 File들은 밖으로 꺼내서S3에 두는 것도 방법입니다.

S3 Simple Storage Service 는 Dropbox처럼 파일을 올리면 URL을 줍니다. URL로 파일에 접근합니다. 매년 100%씩 성장하고 있습니다. S3의 유래가 재미있습니다. Amazon은 초기에 책과 더불어 DVD를 많이 판매했습니다. 영화 정보를 제공하기 위해 Amazon은 IMDb (http://www.imdb.com/) 와 연동했습니다.  Black Friday 등의 연휴 기간에 Amazon에 사용자가 몰리자 IMDb가 견디지 못하고 서버가 죽었습니다. IMDb 측에서 서비스를 끊으라고 요청을 받기도 했습니다. 역으로 Amazon이 Storage를 제공할 것을 제안했습니다. Image와 Javascript를 Storage에 올려 부하를 줄이라는 것이었습니다. 그것이 S3의 시초입니다. S3의 첫 고객이 IMDb인 셈입니다.

S3는 Web hosting 기능도 지원합니다. Web server를 설치하지 않아도 이벤트 페이지 같은 간단한 페이지들을 돌릴 수 있습니다.

물리적 장비는 1TB라 해도 실제로 사용할 수 있는 용량은 작기 마련입니다. S3는 사용한 만큼만 이용료를 지불하면 됩니다. EC2보다 S3가 더 기본이 되는 서비스입니다.

CloudFront를 통해 Edge에 컨텐츠 등 정적 File을 배포할 수 있습니다. CDN을 사용하면 Response time과 서버의 Work load를 줄일 수 있습니다. EC2를 사용하는 것보다 비용이 적게 듭니다. 접속 시 비용이 과금 되기 때문입니다. 서버에는 Application만 남아 서버가 가벼워집니다.

RDB로 조회수를 관리하면 서버가 죽을 수 있습니다. 이럴 때는 ElasticCache를 사용할 수 있습니다. ElastiCache는 Memcached와 Redis를 지원합니다. Memory에 조회수를 빠르게 추가하며, 조회 수가 천 번 가량 증가하는 순간 DB에 조회수를 업데이트 합니다.[2]

 

Auto Scaling

어느 정도 Architecture가 구성이 되고 서버의 Load가 줄면 Auto Scaling을 고려해 볼 수 있습니다. CPU 사용량, Network traffic 등이 증가하면 서버를 붙일 수 있습니다. Image file을 그대로 붙일 수 있으며, 사용량이 감소하면 붙였던 순서대로 떼어낼 수 있습니다. Cloud의 꽃이라 할 수 있습니다. 단, 모든 서비스에 Auto Scaling이 필요한 것은 아닙니다. 소규모 사용자는 굳이 도입할 필요가 없습니다.

Auto Scaling은 거대한 Instance를 사용할 필요가 없습니다. 그렇게 하면 낭비 요소가 있으므로, 작은 규모의 Instance를 사용해 낭비 요소를 줄여야 합니다. 국내에서 Auto Scaling을 잘 사용하는 곳은 디스패치입니다. 평소에는 수 대의 Instance를 사용하다가, 강모 변호사 기사 때 70대, 장기하와 아이유 기사 때 50대의 Instance를 사용했습니다. Instance Type도 M3에서 T2로 최적화 했습니다.

Java, Node.js 등 Application의 종류는 계속 다양해지고 있습니다. 그러나 한 서버에 여러 종류의 Application을 설치하는 것은 쉽지 않습니다. 서비스를 API, Microservice 단위로 나눠 Docker Container 서비스를 사용해 여러 가지 Application을 설치할 수 있습니다.

EC2 서버에도 Docker Container 사용할 있습니다. 과거에는 서버에 여러 종류의 Application 사용하지 못했습니다. 장비 하나에 하나의 OS 설치되어 있기 때문입니다. AWS 서버 대에 여러 OS 올라갈 있습니다. 이는 여러 종류의 Application 올릴 있다는 의미입니다. Node.js, Java JDK, Python Django 서버에 배포될 있습니다. 이를 통해 Docker Container 효율적으로 사용할 있습니다.

Cloud 발전 방향은 서비스를 최적화 유휴 Resource 줄여 가는 것입니다. 이런 측면에서 Docker Container AWS 도움이 됩니다. 다른 장점은 서비스 배포 소요되는 시간이 짧아진다는 것입니다.

S3를 사용하면 서버 설치 없이 서비스를 사용할 수도 있습니다. Lambda를 사용하면 서버를 사용하지 않아도 간단한 Function을 수행할 수 있습니다. 예를 들어 이미지 서비스를 하는 회사는 이미지 섬네일을 올릴 때 특정 Function을 Javascript나 Python으로 구현해 S3에서 수행해 이미지를 저장하도록 할 수 있습니다. 기능이 수행되는 시간만 과금되므로, EC2에 비해 가격 효율적입니다.

EC2가 제공되면서 수 주가 걸리던 서버의 추가가 몇 분 내에 가능해졌습니다. Docker Container는 이를 수 초 내에 가능하게 했습니다. 심지어 Lambda는 Millisecond 수준입니다. 이것이 변화의 모습입니다.

 

EC2 Pricing

약정은 On-Demand보다 40~70% 저렴합니다. Instance Type을 잘 조합하면 AWS를 저렴하게 사용할 수 있습니다. 낮 시간에는 On-Demand로, 밤 시간에는 Reserved로 사용하면 저렴하게 사용할 수 있습니다.

음악 Streaming 서비스인 비트는 Reserved Instance를 사용하지 않습니다. 대신 필요한 Instance의 90%는 Spot Instance를 사용하고, 나머지는 On-Demand Instance를 사용합니다. AWS는 아무리 효율적으로 사용해도 유효 자원이 남습니다. Spot Instance는 경매 방식을 취합니다. 가격이 안정적이지 않기 때문에 한 두 시간에 마칠 수 있는 Big Data 분석 등의 Work load에 맞습니다.

가격이 Instance의 조절은 Auto Scaling이 해 줍니다. Spot Instance가 일정 이상 사용되면 On-Demand Instance가 추가되도록 하고, Spot Instance가 확보되면 On-Demand Instance를 줄이는 식입니다. 잘 활용하면 비용의 80% 이상을 줄일 수 있습니다. 단, Spot Instance의 단점은 서비스의 가용성과 가용 시간이 정해진 것이 아니라는 점입니다.

 

(마침 윤석찬님 강연 다음 회사 강연에서 비트의 CTO 정민영님의 AWS  관련 강연이 있었습니다.)

 

[Link 2. “Cloud 관한 비트의 선택, Amazon Web Services”]

 

일정 수준에 이르르면 관리의 필요성이 높아집니다. 가상화는 모든 자원을 Programming화 할 수 있다는 의미이므로, Coding에서부터 배포, Monitoring까지 자동화와 모니터링이 가능해집니다. 이를 위해 CodeCommit, CodePipeline, CodeDeploy 등을 활용할 수 있습니다. 동일한 Application을 만들고 싶을 때는 CloudFormation을 이용해 JSON 기반으로 Import와 Export를 할 수 있습니다. CloudFormation을 이용해 EC2에 직접 올릴 수도 있지만, Elastic Beanstalk를 사용하면 설정 몇 번으로 Auto Scaling, RDS, Load Balancing 등을 쉽게 사용할 수 있습니다. 가상 서버에 직접 Monitoring 도구를 설치하지 않아도 CloudWatch를 사용하면 Monitoring 통계 정보를 수집할 수 있습니다.

 

Microservice

Amazon 웹사이트는 상품 검색, 장바구니 등 여러 서비스로 이루어져 있습니다. 서비스들을 작게 구성하고 작은 팀들이 운영합니다. 각 서비스는 API로 구성되어 있습니다. AWS도 70여 개 서비스를 제공하고 있으며, 각 팀이 자율적으로 운영하고 있습니다. 이것이 ‘Microservice’입니다. Netflix도 동영상 검색, Play, 추천 등 기능들을 나눠 관리하고 있습니다.

 

AWS 클라우드로 천만 명이 쓰는 서비스 만들기_Image 4.png

[Image 4 출처: Netflix Tech Blog]

 

AWS는 Microservice 구현을 위한 Bulding block을 제공합니다. EC2 Container Service, Lambda, Simple Queue Service 등을 사용할 수 있습니다. Simple Queue Service는 EC2보다 먼저 만들어졌습니다. 서비스를 API화 해 연동에 사용되는데, 외부 비즈니스 제휴가 많은 Amazon의 사업 특성 상 서비스를 안정적으로 유지하고 API Call을 순차적으로 처리해야 하는 요구가 높았습니다. 이처럼 Amazon에서 내부적으로 사용되면서 검증이 된 서비스들이 AWS 발전한 것입니다.

 

Leadership Principle

Amazon에는 14개의 ‘Leadership Principle’이 있습니다. 그 중 하나가 ‘Learn and Be Curious’입니다.

 

‘Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them.’

 

배우지 않으면 살아 남지 못하는 것이 Tech 업계입니다. 새로운 기술과 트렌드에 호기심을 갖고 꾸준히 배우며 교류하시기 바랍니다.

 

[1] 강연 자료는 Link를 참고하세요.

[2] 다음의 아고라 게시판 사례를 하나 말씀해 주셨습니다. 아고라는 RDB를 사용하고 있었는데, 촛불 시위로 게시물 수와 조회수가 급증해 서버가 죽는 상황이 발생했습니다. Memory에 조회수를 저장하다가 Application이 죽었습니다. 순간적으로 조회수가 떨어져 누군가 게시물을 조작하는 것은 아닌가 하는 의심을 받기도 했습니다.

Advertisements

Written by Chris Choi

March 27, 2016 at 11:58 pm

Posted in IT

Tagged with ,

4 Responses

Subscribe to comments with RSS.

  1. […] AWS 클라우드로 천만 명이 쓰는 서비스 만들기 […]

  2. […] 2016년: AWS로 클라우드 천만 명이 쓰는 서비스 만들기 […]

  3. […] Naver D2 Startup Factory 특강 참석: 윤석찬님 […]

    2016 | Chris Choi's Blog

    September 15, 2016 at 12:57 pm

  4. […] ‘AWS 클라우드로 천만 명이 쓰는 서비스 만들기’ […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: