5월 17일 서울COEX에서 열린 AWS Summit Seoul 2016에서 김필중 솔루션즈 아키텍트 님이 발표하신 "AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안" 발표자료입니다.

1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
김필중 | 솔루션즈 아키텍트
2016. 05. 17
AWS 기반의 마이크로서비스 아키텍처

2. 마이크로서비스

3. 마이크로서비스 트렌드: 검색

4. 마이크로서비스 트렌드: 구인
Source: indeed

5. 누가 마이크로서비스를 사용하고 있나?

6. 이 세션에서 다룰 내용
• 마이크로서비스가 무엇인지
• 기존 서비스와는 어떤 차이가 있는지
• 마이크로서비스 디자인과 고려사항
• AWS 와 마이크로서비스

7. 마이크로서비스?
“are small, independent processes that communicate
with each other to form complex applications which utilize
language-agnostic APIs. These services are small building blocks,
highly decoupled and focused on doing a small task,
facilitating a modular approach to system-building.
The microservices architectural style is becoming the standard for
building continuously deployed systems.” - Wikipedia

8. 마이크로서비스?
“are small, independent processes that communicate
with each other to form complex applications which utilize
language-agnostic APIs. These services are small building blocks,
highly decoupled and focused on doing a small task,
facilitating a modular approach to system-building.
The microservices architectural style is becoming the standard for
building continuously deployed systems.” - Wikipedia
작은 빌딩 블록들
높은 비결합성 작은 작업을 수행
모듈식의 접근
디자인 스타일

9. Amazon
서비스 구조도
Netflix

10. Monolithic vs. SOA vs. Microservices
SOA
거친 입자
Microservices
고운 입자
Monolithic
하나의 입자

11. Monolithic 아키텍처
Order UI User UI
Shipping
UI
Order
Service
User
Service
Shipping
Service
Data
Access

12. Monolithic 아키텍처 - 확장

13. 마이크로서비스 아키텍처
Order UI User UI
Shipping
UI
Order
Service
User
Service
Shipping
Service

14. 마이크로서비스 아키텍처 - 확장
Order UI User UI UI
Order
Service
Service
Shipping
Service
Order UI
Order UI
User UI UIShipping
UI
Order
ServiceOrder
Service
Service
Service
Service
Service
User
Service
Shipping
Service

15. Monolithic 아키텍처에서 발견할 수 있는 것들
• 복잡한 코드와 관리의 어려움
• Bottleneck 이 될 수 있는 배포
• 변경의 두려움
• 부족한 주인의식
• 연쇄 실패
• 확장의 어려움

16. Monolithic 아키텍처에서 발견할 수 있는 것들
• 복잡한 코드와 관리의 어려움
• Bottleneck 이 될 수 있는 배포
• 변경의 두려움
• 부족한 주인의식
• 연쇄 실패
• 확장의 어려움
하나의 패키지에 모든 컴포넌트들
포함

17. Monolithic 아키텍처에서 발견할 수 있는 것들
• 복잡한 코드와 관리의 어려움
• Bottleneck 이 될 수 있는 배포
• 변경의 두려움
• 부족한 주인의식
• 연쇄 실패
• 확장의 어려움
Dev 테스트
종속성
Staging 배포
Q&A
Production 배포

18. Monolithic 아키텍처에서 발견할 수 있는 것들
• 복잡한 코드와 관리의 어려움
• Bottleneck 이 될 수 있는 배포
• 변경의 두려움
• 부족한 주인의식
• 연쇄 실패
• 확장의 어려움
비지니스 요구사항을 해결하는
새로운 프레임워크, 서비스 등장
하나의 변경
=> 다양한 Side effect

19. Monolithic 아키텍처에서 발견할 수 있는 것들
• 복잡한 코드와 관리의 어려움
• Bottleneck 이 될 수 있는 배포
• 변경의 두려움
• 부족한 주인의식
• 연쇄 실패
• 확장의 어려움
그거 할 시간 없어요, 그런건 QA 가
해야죠.
데이터베이스가 어떻게 작동하는지
알 필요 없죠,
그건 DBA 가 하는거니까요.
코딩 끝났어요, 이제 OPS 가 항상
작동하게(HA) 할 거에요.

20. Monolithic 아키텍처에서 발견할 수 있는 것들
• 복잡한 코드와 관리의 어려움
• Bottleneck 이 될 수 있는 배포
• 변경의 두려움
• 부족한 주인의식
• 연쇄 실패
• 확장의 어려움
하나의 실패
=> 시스템 전체의 실패를 야기

21. Monolithic 아키텍처에서 발견할 수 있는 것들
• 복잡한 코드와 관리의 어려움
• Bottleneck 이 될 수 있는 배포
• 변경의 두려움
• 부족한 주인의식
• 연쇄 실패
• 확장의 어려움
기능 추가는
다양한 부서간의 의사소통을 요구
=> 늦어지는 업데이트

22. 마이크로서비스로 얻을 수 있는 것들
• 서로 다른 서비스들은 서로 다른 언어로 개발 가능
• 쉬운 integration 과 automatic deployment
• 쉽게 이해하고 수정가능한 코드들 => 새로운 팀원의 생산성 향상
• 최근 기술을 비교적 쉽게 도입
• 빠른 서비스 시작 속도와 빠른 배포
• 기능 추가시 해당 서비스만 수정 및 배포 할 수 있음

23. 마이크로서비스 아키텍처 특징
Do one
thing well
Independent
Decentralized
Black Box
Polyglot
You build it, you run it

24. 잦은 오해

25. Agile, 12-Factor App, Docker, Dropwizard,
SpringBoot, Play, Ratpack, …
마이크로서비스
!=

26. 무엇이 필요할까?

27. 아키텍처와 팀 조직
organizations which design
systems….are constrained to
produce designs which are copies
of the communication structures of
these organizations
- Conway’s law
Source: http://www.melconway.com/Home/Committees_Paper.html

28. 아키텍처와 팀 조직
organizations which design
systems….are constrained to
produce designs which are copies
of the communication structures of
these organizations
- Conway’s law
전형적인 3-tier 시스템
데이터 저장은 파일로 충분,
상호작용은 CLI 로 충분
SQL DB
Javascript/CSS
C#
UI Business DB
Source: http://www.melconway.com/Home/Committees_Paper.html

29. 아키텍처와 팀 조직
organizations which design
systems….are constrained to
produce designs which are copies
of the communication structures of
these organizations
- Conway’s law
아키텍처
팀 조직
Source: http://www.melconway.com/Home/Committees_Paper.html

30. 그럼 어떤 팀 조직이 필요할까?

31. CoC and Hay Day
were each developed by
teams of just five developers
Source: http://www.wired.co.uk/news/archive/2013-11/13/ilkka-paananen-interview
Small independent cells is where
the company name comes from
We say
‘get big by thinking small’
Ilkka Paananen
CEO of Supercell

32. 4명 / 유닛6~8명 / 팀
선호 팀 크기
source: wikipedia

33. 커뮤니케이션 링크
J. Richard Hackman
n (n-1)
2
n = 팀 크기 0
200
400
600
800
1000
1200
1400
0 5 10 15 20 30 50
링크
# of people
Source: Designing Products People Love: How Great Designers Create Successful Products

34. 12 / 664 / 6
팀 크기와 커뮤니케이션 채널
6 / 15
Source: http://chrisnielsen.ws/how-big-teams-choose-to-fail/

35. Jeff Bezos
CEO of Amazon.com
Once at an Amazon offsite, managers had the
reasonable-sounding suggestion that
employees should be increasing communication
with each other.
To their surprise, founder and CEO Jeff Bezos stood
up and announced,
“No, communication is terrible!”

36. 마이크로 서비스 아키텍처
- 디자인과 고려사항

37. 실시간 멀티플레이 게임
- 탱크 슈팅 게임

38. 지역 선택과 접속
게임 플레이

39. 요구사항
• 가능한 적은 관리 포인트
• 다양한 분석이 가능하여야 함
• 게임 기능
• 유저는 특정 Area 에 접속하여, 그 Area 에 접속한 다른 유저들과 게임 플레이
• 일정 수의 Bot 이 있어 다른 유저가 없더라도 게임이 가능
• 아이템 구매가 가능
• 랭킹을 볼 수 있음

40. 요구사항
• 가능한 적은 관리 포인트
• 다양한 분석이 가능하여야 함
• 게임 기능
• 유저는 특정 Area 에 접속하여, 그 Area 에 접속한 다른 유저들과 게임 플레이
• 일정 수의 Bot 이 있어 다른 유저가 없더라도 게임이 가능
• 아이템 구매가 가능
• 랭킹을 볼 수 있음
AnalyticsRankingItemGameArea
… AWS
Lambda
…

41. 마이크로서비스 아키텍처의 고려사항
• 리소스와 상태 관리
• 모니터링
• 서비스 Discovery
• 배포

42. 마이크로서비스 아키텍처의 고려사항
• 리소스와 상태 관리
• 모니터링
• 서비스 Discovery
• 배포

43. 서비스에 적합한 컨테이너
• 간단하게 모델링이 가능
• 애플리케이션 종류, 언어 종류 상관 없음
• 이미지 그 자체가 버전
• 테스트와 배포시 같은 이미지를 사용
• Stateless 서버를 통해 변경의 위험을 줄임

44. Server
Guest OS
Bins/Libs Bins/Libs
App2App1
명확한 하나의 호스트 관리

45. 힘든 호스트들의 관리
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
AZ 1 AZ 2
AZ 3

46. Amazon EC2 Container Service

47. 리소스 관리: Amazon EC2 Container Service
Elastic Load Balancing
Amazon Elastic Block Store
Amazon Virtual Private Cloud
AWS Identity and Access Management
AWS CloudTrail
AWS와 함께 사용되도록 설계
애플리케이션들
배치 작업들
복수의 스케줄러들
유연한 컨테이너 배치
실행시킬 것 없음
완전한 상태
제어와 모니터링
확장
크기 상관 없는 클러스터 관리

48. 잠깐, 리소스 관리가 꼭 필요할까?

49. No server is easier to manage
than ‘no server’
Werner Vogels
CTO, Amazon.com

50. 리소스 관리: AWS Lambda
서버 없는, 이벤트 처리 방식의 컴퓨팅 서비스
Lambda = 서버 없는 마이크로서비스
• 인프라 없이 코드를 실행
• 제한없는 확장
• 완전 자동화된 관리

51. Localytics 사례
Analytics
processing
service
(enriches data)
Elastic Load
Balancing
Amazon SQS
Analytics
DB
Microservice
Internet
HTTP
endpoint
마이크로서비스가
추가될 때 메인 서비스 업데이트가 필요

52. Localytics 사례
HTTP
endpoint
Analytics
processing
service
(enriches data)
Elastic Load
Balancing
Amazon SQS
Analytics
DB
Microservice
Internet
Microservice
Microservice
Amazon
Kinesis
Amazon
Lambda
Kinesis 와 Lambda로
언제든 필요한 서비스를 개발 및 추가가 가능

53. 마이크로서비스 아키텍처의 고려사항
• 리소스와 상태 관리
• 모니터링
• 서비스 Discovery
• 배포

54. 모니터링: Amazon CloudWatch
• 1분 주기로 metric 데이터가 집계되고, 2주간 보관
• 이용 가능한 metric: CPUReservation,
MemoryReservation, CPUUtilization, MemoryUtilization
• 이용 가능한 dimension: ClusterName, ServiceName

55. 모니터링: Amazon CloudWatch

56. 모니터링: Amazon CloudWatch
# Edit crontab
> crontab -e
# Add command to report disk space utilization to CloudWatch every five minutes
*/5 * * * * <path_to>/mon-put-instance-data.pl --disk-space-util--disk-space-used --disk-space-avail--disk-path=/ --from-cron
디스크 공간 등의 추가적인 metric 을 모니터링하기 위해
CloudWatch 모니터링 스크립트를 사용

57. 모니터링: Datadog 와 Amazon ECS

58. 모니터링: Sysdig Cloud 와 Amazon ECS

59. 마이크로서비스 아키텍처의 고려사항
• 리소스와 상태 관리
• 모니터링
• 서비스 Discovery
• 배포

60. 서비스 Discovery: ECS 서비스와 Route 53
• Route 53 의 Private Hosted Zone 활용
• DHCP Options Sets 으로 호스트의 Search Path 설정
• ECS 서비스를 ELB 와 함께 설정
• 각각의 ELB 에 CNAME 을 생성

61. 서비스 Discovery: ECS 서비스와 Route 53
Task
Task TaskTask
ECS
service
Application
router, e.g.
NGINX
Internal ELB with
CNAME, e.g.
api.example.com
Route 53 private
zone, e.g.
example.com

62. 서비스 Discovery: Weaveworks

64. 서비스 Discovery: Consul
ECSCluster
consul-server
ECS Instance
consul-agent
registrator
ECS Instance
Back end 1
Back end 2
consul-agent
registrator
ECS Instance
Front end
ECSCluster

65. 서비스 Discovery: 기타
• Zookeepr
• Doozer
• Etcd
• Airbnb 의 SmartStack
• Netflex 의 Eureka
• NSQ
• Serf
• SkyDNS
• …

66. 마이크로서비스 아키텍처의 고려사항
• 리소스와 상태 관리
• 모니터링
• 서비스 Discovery
• 배포

67. 배포: 라이프사이클
개발자 배포 파이프라인마이크로서비스
build pipeline
build pipeline
build pipeline
build pipeline
build pipeline
build pipeline
build pipeline
build pipeline
build pipeline
build pipeline
build pipeline
build pipeline
build pipeline
build pipeline
build pipeline

68. ECS 의 스케줄링 컨테이너
배치 작업
ECS Task 스케줄러
Task 를 한번 실행
배치 작업
RunTask (랜덤)
StartTask (배치)
Long-running 애플리케이션
ECS 서비스 스케줄러
상태 관리
스케일 업 / 다운
가용영역 인지

69. 스케줄링 컨테이너: Long-running 애플리케이션
Blue-Green 배포
• 두개의 ECS 서비스 정의
• 각 서비스는 ELB 와 연동
• Route 53 의 가중치 라우팅
정책으로 두개의 ELB 에 각 100%,
0% 로 설정
• Blue, Green 서비스에 배포 및
가중치 변경
TaskTask
Route 53
record set
with
weighted
routing
policy
0%
100%

70. 배포: AWS Lambda 배포
코드 완료!
Lambda 함수
업데이트

71. 배포: Vingle 사례
Opsworks
(Background)
Route 53
OpsWorks
(Service)
CloudWatch S3SNS
RDS
ElastiCache DynamoDB
RedShift
Elastic Load
BalancingUsers

72. 배포: Vingle 사례
로컬 개발 Docker빌드 스테이징
테스트
프로덕션
배포
로컬 개발 테스트
(5분)
스테이징
(20분)
테스트
프로덕션
(20분)
배포
Container 이용 이전과 이후

73. 배포: Vingle 사례
배포
OpsWorks EC2
Booting
(1분)
Container Deliver
(1분)
Opsworks에 정의된 Ruby On Rails App
On service
(2분)

74. 배포: ECS CI/CD 파트너

75. 배포: Shippable 을 활용한 ECS CD

76. 아키텍처
Amazon
API
Gateway
Login
Service
workers
Elastic
Load
Balancing
Proxy
Service
Game
Service
Item
Service
Area
Service Users Area
Elasticsearch
Service
Game
Search
Service
Dynamo Streams
users
Dynamo Streams
Dynamo Streams
Item
Dynamo Streams
Amazon
Route 53
ELB
ELB
Ranking
Service

77. 아키텍처
Amazon
API
Gateway
Login
Service
workers
Elastic
Load
Balancing
Proxy
Service
Game
Service
Item
Service
Area
Service Users Area
Elasticsearch
Service
Game
Search
Service
Dynamo Streams
users
Dynamo Streams
Dynamo Streams
Item
Dynamo Streams
Amazon
Route 53
ELB
ELB
Ranking
Service
Amazon ECS
Container

78. 아키텍처
Amazon
API
Gateway
Login
Service
workers
Elastic
Load
Balancing
Proxy
Service
Game
Service
Item
Service
Area
Service Users Area
Elasticsearch
Service
Game
Search
Service
Dynamo Streams
users
Dynamo Streams
Dynamo Streams
Item
Dynamo Streams
Amazon
Route 53
ELB
ELB
Ranking
Service
Serverless
API Gateway AWS Lambda

79. 아키텍처
Amazon
API
Gateway
Login
Service
workers
Elastic
Load
Balancing
Proxy
Service
Game
Service
Item
Service
Area
Service Users Area
Elasticsearch
Service
Game
Search
Service
Dynamo Streams
users
Dynamo Streams
Dynamo Streams
Item
Dynamo Streams
Amazon
Route 53
ELB
ELB
Ranking
Service
Databases
Amazon DynamoDB

80. 아키텍처
Amazon
API
Gateway
Login
Service
workers
Elastic
Load
Balancing
Proxy
Service
Game
Service
Item
Service
Area
Service Users Area
Elasticsearch
Service
Game
Search
Service
Dynamo Streams
users
Dynamo Streams
Dynamo Streams
Item
Dynamo Streams
Amazon
Route 53
ELB
ELB
Ranking
Service
Analytics
Amazon Elasticsearch

81. 아키텍처
Amazon
API
Gateway
Login
Service
workers
Elastic
Load
Balancing
Proxy
Service
Game
Service
Item
Service
Area
Service Users Area
Elasticsearch
Service
Game
Search
Service
Dynamo Streams
users
Dynamo Streams
Dynamo Streams
Item
Dynamo Streams
Amazon
Route 53
ELB
ELB
Ranking
ServiceAutomation & Deployment
CloudFormation
CodePipelineOpsworks
Elastic Beanstalk

82. 정리
• 혁신과 속도를 위한 마이크로서비스
• 트레이드오프와 새로운 도전
• 자동화는 복잡함에 대한 해결책
• 관리 오버헤드를 줄이기 위해 클라우드 기반의
툴들
• 노 서버 = 노 오버헤드
• 변화의 위험은 툴과 문화로 줄일 수 있습니다!

83. AWS 와 마이크로서비스

84. AWS 와 마이크로서비스: 자동화
Infrastructure automation techniques have evolved
enormously over the last few years
- the evolution of the cloud and AWS in particular has
reduced the operational complexity of building, deploying
and operating microservices.
– Martin Fowler
Source: http://martinfowler.com/articles/microservices.html

85. AWS 와 마이크로서비스: Polyglot - 스토리지
FS
Blocks
Static
Assets
Meta
Data
Temp
Files
Data
Blobs
Event
Logs
Search
Indices
Struct.
Data
Back-
Ups
Amazon S3Amazon EBS
Amazon GlacierEphemeral
EC2 Storage CloudFront
DynamoDBAmazon RDS Amazon
CloudSearch
Amazon
Kinesis

86. AWS 와 마이크로서비스: Polyglot - 언어
• Java
• Python
• Ruby
• .NET
• PHP
• Javascript
• Node.js
• iOS
• Android

87. AWS 와 마이크로서비스: Polyglot - OS
• Amazon Linux
• Redhat
• SUSE
• Open BSD
• CentOS
• Debian
• Ubuntu
• Windows Server 2003
• Windows Server 2008
• Windows Server 2012

88. AWS 와 마이크로서비스
• 필요한 만큼만 리소스를 사용 (On Demand Resources)
• 관리형 서비스 (Managed Services)
• 모든 서비스는 프로그래머블 (Programmable Services)
• IaC (Infrastructure as code)
• 내장된 기능들
• 모니터링, 보안, 로깅, …
• 확장성, 가용성, …
• 서버없는 아키텍처

89. 여러분의 피드백을 기다립니다!
https://www.awssummit.co.kr
모바일 페이지에 접속하셔서, 지금 세션 평가에
참여하시면, 행사 후 기념품을 드립니다.
#AWSSummit 해시태그로 소셜 미디어에 여러분의
행사 소감을 올려주세요.
발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜
채널로 곧 공유될 예정입니다.