1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
박철수 | 솔루션즈 아키텍트
2016년 11월
AWS 클라우드로
내 서비스 무한대로
확장하기

2. 자, 어떻게 쉽고 안전하게
확장할 수 있을까요?

3. 어디서부터 시작
해야 할지
모르겠습니다!

5. 엄청난 양의 읽어야 할
것들

6. 우리가 시작할
곳이 아닙니다!
엄청난 양의 읽어야 할
것들

7. 오토 스케일링은…
하나의 도구이면서 우리의
목적지입니다

8. 그리고 모든 것을 해결해주는
도깨비 방망이는 아닙니다.

9. 처음에 필요한 것은?

10. 몇 가지 기본 지식…

11. EU (프랑크푸르트)
US-WEST (오레곤)
EU (아일랜드)
ASIA PACIFIC
(도쿄)
US-WEST (캘리포니아)
SOUTH AMERICA
(상 파울로)
US-EAST (버지니아)
AWS GOVCLOUD (US)
ASIA PACIFIC
(시드니)
ASIA PACIFIC
(싱가포르)
CHINA (베이징)
ASIA PACIFIC
(서울)
14 리전
리전은 전 세계에 분산된 물리적 위치로서 각 리전은 완전히 독립 구성되어 있다
글로벌 인프라
ASIA PACIFIC
(문바이)
US-EAST (오하이오)

12. US-WEST (오레곤)
EU (아일랜드)
ASIA PACIFIC
(도쿄)
US-WEST (캘리포니아)
US-EAST (버지니아)
AWS GOVCLOUD (US)
ASIA PACIFIC
(시드니)
ASIA PACIFIC
(싱가포르)
CHINA (베이징)
EU (프랑크푸르트)
ASIA PACIFIC
(서울)
가용 영역들은 서로 다른 별개의 위치에 존재하고, 다른 가용 영역에서의 장애와 완전히 분리될 수 있도록 설계되어 있다. 리전 내의
다른 가용 영역에 짧은 대기 시간으로 네트워크 연결을 제공하며, 별도의 가용 영역에서 인스턴스를 시작하면 하나의 가용 영역
전체에 영향을 미치는 실패(그것이 발생할 가능성은 거의 없지만)에서 응용 프로그램을 보호 할 수 있다
SOUTH AMERICA
(상 파울로)
14 리전
38 가용 영역
글로벌 인프라
ASIA PACIFIC
(문바이)
US-EAST (오하이오)

13. 14 리전
38 가용 영역
63 엣지 로케이션
엣지 로케이션은 DNS 서비스인 Amazon Route 53과 CDN 서비스인 Amazon CloudFront 그리고 웹 애플리케이션 방화벽 서비스인
AWS WAF 서비스를 지원한다
글로벌 인프라

14. 고객 및 기술
지원
영업 지원
고객지원
프로페셔널
컨설팅
교육 및
인증
보안 및
빌링
시스템
파트너
생태계
솔루션
아키텍트
엔터프라이즈
가상
데스크톱
기업용 공유
도구
기업용
이메일
백업 및 복구
글로벌 리전
(Region)
가용 영역
(AZ)
콘텐츠 배포
지점(Edges)
인프라
핵심 서비스
컴퓨팅
가상머신, 자동확장, 부하분산,
컨테이너, 클라우드 기능
스토리지
오브젝트, 블록, 파일,
아카이브, Import/Export
데이터베이스
관계형, NoSQL, 캐싱,
마이그레이션
네트워킹
VPC, DX, DNS
콘텐츠 배포
(CDN)
하이브리드
환경
데이터 백업
통합 앱
개발 환경
전용 회선
연결
통합 인증
통합 리소스
관리
네트워크
통합
서비스
접근 제어
사용자
인증 관리
암호 키 관리
및 저장
모니터링
로그
기업 자원
설정 및 보고
리소스 사용량
및 감사
보안 및 규정 준수
기업 내
규정 준수
웹 방화벽
비지니
스 앱
비지니스
인텔리전스 데이터베이스
DevOps
도구
네트워킹보안 스토리지
IoT
규칙 엔진
디바이스
섀도
디바이스
SDK
레지스트리
디바이스
게이트웨이
개발 및 운영 도구모바일 서비스앱 서비스데이터 분석
데이터웨어
하우스
하둡/Spark
실시간 데이터
저장
머신 러닝
Elasticsearch
서비스
알람 및 큐
서비스
워크 플로우
풀-텍스트
검색
Email 전송
동영상 변환
원 클릭 앱 개발
모바일 인증
디바이스 동기화
모바일 앱 테스트
푸시 알림
DevOps 리소스 관리
앱 생명주기 관리
도구
컨테이너 서비스
클라우드 함수
리소스 템플릿
API
게이트웨이
실시간 데이터
분석
비지니스
인텔리전스
모바일 분석
모바일 허브
마켓 플레이스
AWS 클라우드의 다양하고 폭넓은 서비스

15. 비지니스 요구 사항에 맞는
70여개 이상의 서비스 조립을 통해 유연한 활용 가능
AWS 클라우드의 다양하고 폭넓은 서비스
AWS 활용 = 빌딩 블록 조립

17. 이제 시작해볼까요?

18. 첫 사용자
바로
여러분!

19. 첫날! 첫 사용자 1명
Amazon Route 53
단일 Elastic IP
단일 EC2 인스턴스
• 하나의 인스턴스에 모든 스택 구성
• 웹 서버
• 데이터베이스
• 관리 도구
• 기타 ... EC2
인스턴스
Elastic IP
사용자
Amazon
Route 53

20. 수직적 스케일 업(Scale-Up)
• 가장 쉬운 접근 방법
• 좀 더 높은 CPU 인스턴스
• 좀 더 높은 메모리 인스턴스
• 좀 더 높은 스토리지 인스턴스
• 좀 더 높은 I/O 인스턴스
• 쉽게 인스턴스 크기 변경
• 결국에는 한계 용량에 도달
1 vCPU
1 GiB 메모리
$0.02/시간
t2.micro
m4.2xlarge
8 vCPU
32 GiB 메모리
$0.66/시간
c4.8xlarge
32 vCPU
60 GiB 메모리
$1.91/시간
“곧, 더 큰 인스턴스 필요!”

21. 첫날! 첫 사용자 1명
문제점
• 페일오버 없음
• 이중화 없음
“한 바구니에 계란을
모두 담지 말자!” EC2
인스턴스
Elastic IP
사용자
Amazon
Route 53
X

22. 사용자 >1

23. 사용자 > 1
먼저, 기능에 따라
인스턴스의 역할을 나눈다!
• 웹 서버용 인스턴스
• DB용 인스턴스
• 데이터베이스 서비스
이용?
웹
인스턴스
데이터베이스
인스턴스
Elastic IP
사용자
Amazon
Route 53

24. 직접 운영 관리형 서비스 선택
Amazon EC2
직접 설치
원하는 데이터
베이스를 선택
하여 운영
라이선스/백업
등 직접 운영
데이터베이스 선택 사항
Amazon RDS
MySQL
Microsoft SQL
Oracle
PostgreSQL
MariaDB
Amazon Aurora
라이선스/백업등
선택적 제공
Amazon
DynamoDB
SSD 스토리지기반
NoSQL 서비스
빠른 처리속도
중단없는 확장성 및
관리 필요 없음
Amazon
Redshift
대용량 병렬
페타바이트급
데이터웨어 서비스
빠르고 강력한
확장성 제공

25. Amazon Aurora를 추천합니다!
 MySQL 호환 및 5배 성능 향상
 자동 스토리지 확장 (최대 64TB)
 자동 장애 감지 및 복구
 Amazon S3에 지속 증분 백업
 1/10 비용으로 상용 DB 급 성능
 3곳의 가용 영역에 6본의 복제
 서울 리전 사용 가능 (3월 31일)
데이터 플랜
로깅 + 스토리지
SQL
트랜잭션
캐싱
Amazon S3

26. 사용자 >100

27. 사용자 >100
웹
인스턴스
Elastic IP
RDS DB
인스턴스
사용자
Amazon
Route 53
먼저, 기능에 따라
인스턴스의 역할을 나눈다!
• 웹 서버용 인스턴스
• DB용 인스턴스
• 편리한 DB 운영을
위해 Amazon RDS
이용

28. 사용자 >1,000

29. 사용자 >1,000 ?
만약 웹 서버나 DB
인스턴스에 문제가
생긴다면?
• 이중화 없음
• 페일오버 없음 웹
인스턴스
Elastic IP
RDS DB
인스턴스
X
사용자
Amazon
Route 53

30. 사용자 >1,000+
Elastic Load Balancing
확장성 높은 부하 분산 서비스
Multi-AZ 서버 구성
가용 영역을 통한 고가용성 확보
데이터베이스 이중화
RDS의 기본-예비 복제본을 Multi-
AZ에 구성
웹
인스턴스
RDS DB 인스턴스
기본 복제본 (Multi-AZ)
가용 영역 #1 가용 영역 #2
웹
인스턴스
RDS DB 인스턴스 예비
복제본 (Multi-AZ)
Elastic Load
Balancing
사용자
Amazon
Route 53

31. Elastic Load Balancing
• 고가용성
• 1 – 65,535
• 헬스 체크
• 세션 유지(stickiness)
• SSL 오프로드
• 모니터링
• 로깅
애플리케이션
부하 분산기
클래식
부하 분산기

32. 수평적
수직적

33. 사용자 >100,000

34. 사용자 > 10,000 -100,000+
RDS DB 인스턴스
기본 복제본 (Multi-AZ)
가용 영역 #1 가용 영역 #2
RDS DB 인스턴스
예비 복제본 (Multi-AZ)
Elastic Load
Balancing
RDS DB
인스턴스 읽기
전용 복제본
RDS DB
인스턴스 읽기
전용 복제본
RDS DB
인스턴스 읽기
전용 복제본
RDS DB
인스턴스 읽기
전용 복제본
웹
인스턴스
웹
인스턴스
웹
인스턴스
웹
인스턴스
웹
인스턴스
웹
인스턴스
웹
인스턴스
웹
인스턴스
사용자
Amazon
Route 53

35. 성능과 효율성을 높일 수 있는
고급 아키텍처

36. 부하를 낮추자!
• 추천: 부하 테스트관련 AWS블로그(http://bit.ly/LoadTestingOnAWS)

37. 웹
인스턴스
RDS DB 인스턴스
기본 복제본 (Multi-AZ)
가용 영역
Elastic Load
Balancing
정적 콘텐츠를 Amazon
S3와 CloudFront로
이전하자!
• 정적 파일(CSS/JS 파일,
사용자 업로드 이미지 및
비디오 등)
• 다운로드 파일 배포
• 백업 및 로그
• 무제한 저장소 및 콘텐츠
배포 네트워크 활용 가능
주위로 일부 부하 이동하기
사용자
Amazon
Route 53
Amazon
CloudFront
Amazon S3

38. Amazon Simple Storage Service (S3)
• 오브젝트 기반 스토리지
• 높은 내구성
• 정적 자산에 최적
• 무한 확장성
• 오브젝트
• 최대 5 TB 오브젝트 크기
• 선택적 암호화

39. Amazon CloudFront
• 보다 빠른 전달을 위한 캐시된
콘텐츠
• 오리진에 낮은 부하
• 정적 및 동적 콘텐츠 지원
• 비디오 스트리밍
• 사용자 정의 SSL 인증서
• 낮은 TTL (0초)
• AWS 최적화

40. 웹
인스턴스
RDS DB 인스턴스
기본 복제본 (Multi-AZ)
가용 영역
Elastic Load
Balancing
Amazon S3
ElastiCache
DynamoDB
사용자
Amazon
Route 53
Amazon
CloudFront
Amazon DynomoDB와
ElasticCache 활용
• 자주 사용되는 세션/상태
정보는 DynamoDB 사용
• 인 메모리 기반 캐시 서비스
(Memcached, Redis)를
이용하여 DB 캐싱
주위로 일부 부하 이동하기

41. Amazon DynamoDB도 추천합니다!
• 손 쉬운 관리형 NoSQL 서비스
• 읽기 및 쓰기 용량 제어 가능
• 프로비저닝한 용량 만큼만 과금
• 무제한 스토리지 제공
• 일관된 응답시간 – 한 자리수 밀리초
• JSON 도큐먼트 지원

42. Amazon Elasticache
• 인-메모리 관리형 캐시 서비스
• Memcached 및 Redis 지원
• 기존 오픈 소스 기반 API 지원
• 자가-치유 기능 (장애 인스턴스 교체)
• 하나에서 다수 노드로 확장
• 한 자리수 밀리초 속도

43. 동적 콘텐츠에 대해서도
Amazon CloudFront 활용
웹
인스턴스
RDS DB 인스턴스
기본 복제본 (Multi-AZ)
가용 영역
Elastic Load
Balancing
Amazon S3
ElastiCache
DynamoDB
User
Amazon
Route 53
Amazon
CloudFront
주위로 일부 부하 이동하기응답시간
서버부하
응답시간
서버
부하
응답시간
서버
부하
No CDN 정적 콘텐츠를
위한 CDN
정적 및 동적
콘텐츠를 위한
CDN

44. 이제 웹 계층이 훨씬 더
가벼워졌습니다.
자! 처음에 보았던 주제에
대해서 다시 이야기 해보시죠!

45. 오토 스케일링

46. 컴퓨트 클러스터 크기를 자동 재조정
최소/최대 풀 크기 정의
CloudWatch 메트릭을 통한 확장 구동
온-디맨드 또는 스팟 인스턴스
aws autoscaling create-auto-scaling-group
--auto-scaling-group-name MyGroup
--launch-configuration-name MyConfig
--min-size 4
--max-size 200
--availability-zones ap-northeast-2c, ap-northeast-2a
오토스케일링

47. 일요일 월요일 화요일 수요일 목요일 금요일 토요일
Amazon.com의 전형적인 주간 트래픽

48. Amazon.com의 전형적인 주간 트래픽
프로비저닝된 용량
일요일 월요일 화요일 수요일 목요일 금요일 토요일

49. 11월
Amazon.com의 11월 트래픽

50. 11월
Amazon.com의 11월 트래픽
프로비저닝된 용량

51. Amazon.com의 11월 트래픽
76%
24%
프로비저닝된 용량
11월

52. Amazon.com의 11월 트래픽
11월

53. 오토스케일링으로
이것을 할 수 있습니다!

54. 사용자 >500,000

55. 사용자 > 50만+
Availability Zone
Amazon
Route 53
사용자
Amazon S3
Amazon
CloudFront
Availability Zone
ELB
Balancer
DynamoDB
RDS DB
인스턴스 읽기
전용 복제본
웹
인스턴스
웹
인스턴스
웹
인스턴스
ElastiCache RDS DB
인스턴스 읽기
전용 복제본
웹
인스턴스
웹
인스턴스
웹
인스턴스
ElastiCacheRDS DB 인스턴스
예비 복제본 (Multi-
AZ)
RDS DB 인스턴스
기본 복제본 (Multi-
AZ)

56. 자동화를 하자!

57. 애플리케이션 개발
앱 배포 관리
모니터링
캐싱
Web | DB | API
가상 서버
여러분이 필요한 것만 집중합시다!
AWS

58. 모니터링구축배포테스트빌드코딩
AWS Elastic Beanstalk
AWS OpsWorks
AWS
CloudFormation
AWS
CodePipeline
AWS
CodeCommit
AWS
CloudWatch
AWS
CodeDeploy
편리성
인프라 및 애플리케이션 배포 자동화

59. 웹/앱 계층을 분해해서
추가로 더 개선할 수
있습니다!

60. 마이크로서비스
(Microservice)
들어 보셨나요?

61. 마이크로서비스
• 내부 서비스를 작게 분리하여
느슨하게 결합
• 작은 서비스간 인터랙션
결합제거 (decoupling) 후,
API로 통신
• 클라우드 기반으로 확장성 및
증설을 염두하여 기능 개발

62. 느슨한 결합 = 승리!
바퀴를 재개발하지 말자!
• 이메일
• 큐잉
• 트랜스코딩
• 검색
• 데이터베이스
• 모니터링
• 계측
• 로깅
• 컴퓨트
Amazon
CloudSearch
Amazon SQSAmazon SNS
Amazon Elastic
Transcoder
Amazon SWFAmazon SES
AWS Lambda

63. 사용자 > 1,000,000

64. 사용자 >1,000,000+
1백만+에 도달한다는 것은 앞서 보셨던 것들을 요구합니다:
• Multi-AZ
• 계층 간에 Elastic Load Balancing
• 오토 스케일링
• 마이크로 서비스
• 똑똑하게 콘텐츠 제공 (Amazon S3/CloudFront )
• DB 캐싱
• 오토 스케일하는 계층의 세션 상태 끄기

65. RDS DB 인스턴스
기본 복제본 (Multi-AZ)
가용 영역
Elastic Load
Balancer
RDS DB
인스턴스 읽기
전용 복제본
RDS DB
인스턴스 읽기
전용 복제본
웹
인스턴스
웹
인스턴스
웹
인스턴스
웹
인스턴스
DynamoDB
Amazon SQS
ElastiCache
작업자
인스턴스
작업자
인스턴스
Amazon
CloudWatch
사내 앱
인스턴스
사내 앱
인스턴스
사용자
Amazon
Route 53
Amazon
CloudFront
사용자: 100만+
Amazon S3
Amazon SES
Lambda

66. 다음 큰 단계

67. 사용자 > 10,000,000

68. 사용자 >500만 – 1천만
데이터베이스의 쓰기 마스터 노드 상에 경쟁 이슈가
잠재적으로 발생할 수 있다.
이 문제를 해결할 수 있을까요?
• 연합(Federation) — 기능 기반의 다중 DB 분리
• 샤딩(Sharding) — 다중 호스트로 하나의 데이터 집합 분리
• 몇 가지 기능을 다른 유형의 DB로 이동 (NoSQL, 그래프)

69. 데이터베이스 연합
• 데이터베이스를 기능 및 목적에 따라 분리
• 하지만, 데이터베이스간 교차-함수 쿼리가 어려움
• 기본적으로, 샤딩/NoSQL을 지연
• 거대한 단일 함수 및 테이블에는 도움 안 됨
포럼 DB
사용자 DB
제품 DB

70. 수평적 확장: 샤딩
• 함수나 키 영역에 의한 샤드
• 확장에 실질적인 제한 없음
• 애플리케이션 계층 복잡도 심화
• 운영 복잡성 및 전문성
• RDBMS 또는 NoSQL
사용자 ShardID
002345 A
002346 B
002347 C
002348 B
002349 A
CBA

71. NoSQL로 이전
• 연합 방법과 유사
• NoSQL이 필요한지, SQL이 필요한지 고민해보기!
• DynamoDB와 같은 관리형 서비스를 활용
사용 사례:
• 리더보드/득점표
• 클릭스트림 및 로그 데이터의 빠른 인입
• 임시 데이터 (예: 장바구니)
• “핫” 테이블
• 메타 데이터 / 검색 테이블
DynamoDB

72. 앞선 모든 것을 함께 구성하면
쉽게 1천백만+ 사용자를
처리할 수 있습니다!

73. 무한대를 향해…

74. 사용자 >1천백만을 넘어서…
• 애플리케이션을 더 미세하게 조정
• 더 많은 마이크로서비스 기능 및 역할
• 다중-가용영역에서 다중-리전으로 이전
• 가능하면 커스텀 솔루션 구축 시작
• 전체 스택에 대한 깊은 분석

75. 다음 단계?
읽을 만한 자료!
aws.amazon.com/documentation
aws.amazon.com/architecture
aws.amazon.com/start-ups
AWS 시작하기:
aws.amazon.com/free/

76. Thank you!
감사합니다