Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
김필중 | 솔루션즈 아키텍트
2016. 05. 17
AWS 기반의 마이크로서비스 아키텍처
마이크로서비스
마이크로서비스 트렌드: 검색
마이크로서비스 트렌드: 구인
Source: indeed
누가 마이크로서비스를 사용하고 있나?
이 세션에서 다룰 내용
• 마이크로서비스가 무엇인지
• 기존 서비스와는 어떤 차이가 있는지
• 마이크로서비스 디자인과 고려사항
• AWS 와 마이크로서비스
마이크로서비스?
“are small, independent processes that communicate
with each other to form complex applications which utilize
lan...
마이크로서비스?
“are small, independent processes that communicate
with each other to form complex applications which utilize
lan...
Amazon
서비스 구조도
Netflix
Monolithic vs. SOA vs. Microservices
SOA
거친 입자
Microservices
고운 입자
Monolithic
하나의 입자
Monolithic 아키텍처
Order UI User UI
Shipping
UI
Order
Service
User
Service
Shipping
Service
Data
Access
Monolithic 아키텍처 - 확장
마이크로서비스 아키텍처
Order UI User UI
Shipping
UI
Order
Service
User
Service
Shipping
Service
마이크로서비스 아키텍처 - 확장
Order UI User UI UI
Order
Service
Service
Shipping
Service
Order UI
Order UI
User UI UIShipping
UI
Order...
Monolithic 아키텍처에서 발견할 수 있는 것들
• 복잡한 코드와 관리의 어려움
• Bottleneck 이 될 수 있는 배포
• 변경의 두려움
• 부족한 주인의식
• 연쇄 실패
• 확장의 어려움
Monolithic 아키텍처에서 발견할 수 있는 것들
• 복잡한 코드와 관리의 어려움
• Bottleneck 이 될 수 있는 배포
• 변경의 두려움
• 부족한 주인의식
• 연쇄 실패
• 확장의 어려움
하나의 패키지에 모...
Monolithic 아키텍처에서 발견할 수 있는 것들
• 복잡한 코드와 관리의 어려움
• Bottleneck 이 될 수 있는 배포
• 변경의 두려움
• 부족한 주인의식
• 연쇄 실패
• 확장의 어려움
Dev 테스트
종속...
Monolithic 아키텍처에서 발견할 수 있는 것들
• 복잡한 코드와 관리의 어려움
• Bottleneck 이 될 수 있는 배포
• 변경의 두려움
• 부족한 주인의식
• 연쇄 실패
• 확장의 어려움
비지니스 요구사항을...
Monolithic 아키텍처에서 발견할 수 있는 것들
• 복잡한 코드와 관리의 어려움
• Bottleneck 이 될 수 있는 배포
• 변경의 두려움
• 부족한 주인의식
• 연쇄 실패
• 확장의 어려움
그거 할 시간 없어...
Monolithic 아키텍처에서 발견할 수 있는 것들
• 복잡한 코드와 관리의 어려움
• Bottleneck 이 될 수 있는 배포
• 변경의 두려움
• 부족한 주인의식
• 연쇄 실패
• 확장의 어려움
하나의 실패
=> ...
Monolithic 아키텍처에서 발견할 수 있는 것들
• 복잡한 코드와 관리의 어려움
• Bottleneck 이 될 수 있는 배포
• 변경의 두려움
• 부족한 주인의식
• 연쇄 실패
• 확장의 어려움
기능 추가는
다양한...
마이크로서비스로 얻을 수 있는 것들
• 서로 다른 서비스들은 서로 다른 언어로 개발 가능
• 쉬운 integration 과 automatic deployment
• 쉽게 이해하고 수정가능한 코드들 => 새로운 팀원의 생...
마이크로서비스 아키텍처 특징
Do one
thing well
Independent
Decentralized
Black Box
Polyglot
You build it, you run it
잦은 오해
Agile, 12-Factor App, Docker, Dropwizard,
SpringBoot, Play, Ratpack, …
마이크로서비스
!=
무엇이 필요할까?
아키텍처와 팀 조직
organizations which design
systems….are constrained to
produce designs which are copies
of the communication st...
아키텍처와 팀 조직
organizations which design
systems….are constrained to
produce designs which are copies
of the communication st...
아키텍처와 팀 조직
organizations which design
systems….are constrained to
produce designs which are copies
of the communication st...
그럼 어떤 팀 조직이 필요할까?
CoC and Hay Day
were each developed by
teams of just five developers
Source: http://www.wired.co.uk/news/archive/2013-11/1...
4명 / 유닛6~8명 / 팀
선호 팀 크기
source: wikipedia
커뮤니케이션 링크
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:...
12 / 664 / 6
팀 크기와 커뮤니케이션 채널
6 / 15
Source: http://chrisnielsen.ws/how-big-teams-choose-to-fail/
Jeff Bezos
CEO of Amazon.com
Once at an Amazon offsite, managers had the
reasonable-sounding suggestion that
employees sho...
마이크로 서비스 아키텍처
- 디자인과 고려사항
실시간 멀티플레이 게임
- 탱크 슈팅 게임
지역 선택과 접속
게임 플레이
요구사항
• 가능한 적은 관리 포인트
• 다양한 분석이 가능하여야 함
• 게임 기능
• 유저는 특정 Area 에 접속하여, 그 Area 에 접속한 다른 유저들과 게임 플레이
• 일정 수의 Bot 이 있어 다른 유저가 없...
요구사항
• 가능한 적은 관리 포인트
• 다양한 분석이 가능하여야 함
• 게임 기능
• 유저는 특정 Area 에 접속하여, 그 Area 에 접속한 다른 유저들과 게임 플레이
• 일정 수의 Bot 이 있어 다른 유저가 없...
마이크로서비스 아키텍처의 고려사항
• 리소스와 상태 관리
• 모니터링
• 서비스 Discovery
• 배포
마이크로서비스 아키텍처의 고려사항
• 리소스와 상태 관리
• 모니터링
• 서비스 Discovery
• 배포
서비스에 적합한 컨테이너
• 간단하게 모델링이 가능
• 애플리케이션 종류, 언어 종류 상관 없음
• 이미지 그 자체가 버전
• 테스트와 배포시 같은 이미지를 사용
• Stateless 서버를 통해 변경의 위험을 줄임
Server
Guest OS
Bins/Libs Bins/Libs
App2App1
명확한 하나의 호스트 관리
힘든 호스트들의 관리
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest O...
Amazon EC2 Container Service
리소스 관리: Amazon EC2 Container Service
Elastic Load Balancing
Amazon Elastic Block Store
Amazon Virtual Private Cloud
AWS Id...
잠깐, 리소스 관리가 꼭 필요할까?
No server is easier to manage
than ‘no server’
Werner Vogels
CTO, Amazon.com
리소스 관리: AWS Lambda
서버 없는, 이벤트 처리 방식의 컴퓨팅 서비스
Lambda = 서버 없는 마이크로서비스
• 인프라 없이 코드를 실행
• 제한없는 확장
• 완전 자동화된 관리
Localytics 사례
Analytics
processing
service
(enriches data)
Elastic Load
Balancing
Amazon SQS
Analytics
DB
Microservice
Int...
Localytics 사례
HTTP
endpoint
Analytics
processing
service
(enriches data)
Elastic Load
Balancing
Amazon SQS
Analytics
DB
Mi...
마이크로서비스 아키텍처의 고려사항
• 리소스와 상태 관리
• 모니터링
• 서비스 Discovery
• 배포
모니터링: Amazon CloudWatch
• 1분 주기로 metric 데이터가 집계되고, 2주간 보관
• 이용 가능한 metric: CPUReservation,
MemoryReservation, CPUUtilizati...
모니터링: Amazon CloudWatch
모니터링: Amazon CloudWatch
# Edit crontab
> crontab -e
# Add command to report disk space utilization to CloudWatch every fiv...
모니터링: Datadog 와 Amazon ECS
모니터링: Sysdig Cloud 와 Amazon ECS
마이크로서비스 아키텍처의 고려사항
• 리소스와 상태 관리
• 모니터링
• 서비스 Discovery
• 배포
서비스 Discovery: ECS 서비스와 Route 53
• Route 53 의 Private Hosted Zone 활용
• DHCP Options Sets 으로 호스트의 Search Path 설정
• ECS 서비스를...
서비스 Discovery: ECS 서비스와 Route 53
Task
Task TaskTask
ECS
service
Application
router, e.g.
NGINX
Internal ELB with
CNAME, e....
서비스 Discovery: Weaveworks
서비스 Discovery: Consul
ECSCluster
consul-server
ECS Instance
consul-agent
registrator
ECS Instance
Back end 1
Back end 2
co...
서비스 Discovery: 기타
• Zookeepr
• Doozer
• Etcd
• Airbnb 의 SmartStack
• Netflex 의 Eureka
• NSQ
• Serf
• SkyDNS
• …
마이크로서비스 아키텍처의 고려사항
• 리소스와 상태 관리
• 모니터링
• 서비스 Discovery
• 배포
배포: 라이프사이클
개발자 배포 파이프라인마이크로서비스
build pipeline
build pipeline
build pipeline
build pipeline
build pipeline
build pipeline
b...
ECS 의 스케줄링 컨테이너
배치 작업
ECS Task 스케줄러
Task 를 한번 실행
배치 작업
RunTask (랜덤)
StartTask (배치)
Long-running 애플리케이션
ECS 서비스 스케줄러
상태 관리
...
스케줄링 컨테이너: Long-running 애플리케이션
Blue-Green 배포
• 두개의 ECS 서비스 정의
• 각 서비스는 ELB 와 연동
• Route 53 의 가중치 라우팅
정책으로 두개의 ELB 에 각 100%...
배포: AWS Lambda 배포
코드 완료!
Lambda 함수
업데이트
배포: Vingle 사례
Opsworks
(Background)
Route 53
OpsWorks
(Service)
CloudWatch S3SNS
RDS
ElastiCache DynamoDB
RedShift
Elastic...
배포: Vingle 사례
로컬 개발 Docker빌드 스테이징
테스트
프로덕션
배포
로컬 개발 테스트
(5분)
스테이징
(20분)
테스트
프로덕션
(20분)
배포
Container 이용 이전과 이후
배포: Vingle 사례
배포
OpsWorks EC2
Booting
(1분)
Container Deliver
(1분)
Opsworks에 정의된 Ruby On Rails App
On service
(2분)
배포: ECS CI/CD 파트너
배포: Shippable 을 활용한 ECS CD
아키텍처
Amazon
API
Gateway
Login
Service
workers
Elastic
Load
Balancing
Proxy
Service
Game
Service
Item
Service
Area
Service ...
아키텍처
Amazon
API
Gateway
Login
Service
workers
Elastic
Load
Balancing
Proxy
Service
Game
Service
Item
Service
Area
Service ...
아키텍처
Amazon
API
Gateway
Login
Service
workers
Elastic
Load
Balancing
Proxy
Service
Game
Service
Item
Service
Area
Service ...
아키텍처
Amazon
API
Gateway
Login
Service
workers
Elastic
Load
Balancing
Proxy
Service
Game
Service
Item
Service
Area
Service ...
아키텍처
Amazon
API
Gateway
Login
Service
workers
Elastic
Load
Balancing
Proxy
Service
Game
Service
Item
Service
Area
Service ...
아키텍처
Amazon
API
Gateway
Login
Service
workers
Elastic
Load
Balancing
Proxy
Service
Game
Service
Item
Service
Area
Service ...
정리
• 혁신과 속도를 위한 마이크로서비스
• 트레이드오프와 새로운 도전
• 자동화는 복잡함에 대한 해결책
• 관리 오버헤드를 줄이기 위해 클라우드 기반의
툴들
• 노 서버 = 노 오버헤드
• 변화의 위험은 툴과 문화로...
AWS 와 마이크로서비스
AWS 와 마이크로서비스: 자동화
Infrastructure automation techniques have evolved
enormously over the last few years
- the evolution of...
AWS 와 마이크로서비스: Polyglot - 스토리지
FS
Blocks
Static
Assets
Meta
Data
Temp
Files
Data
Blobs
Event
Logs
Search
Indices
Struct.
D...
AWS 와 마이크로서비스: Polyglot - 언어
• Java
• Python
• Ruby
• .NET
• PHP
• Javascript
• Node.js
• iOS
• Android
AWS 와 마이크로서비스: Polyglot - OS
• Amazon Linux
• Redhat
• SUSE
• Open BSD
• CentOS
• Debian
• Ubuntu
• Windows Server 2003
• ...
AWS 와 마이크로서비스
• 필요한 만큼만 리소스를 사용 (On Demand Resources)
• 관리형 서비스 (Managed Services)
• 모든 서비스는 프로그래머블 (Programmable Services...
여러분의 피드백을 기다립니다!
https://www.awssummit.co.kr
모바일 페이지에 접속하셔서, 지금 세션 평가에
참여하시면, 행사 후 기념품을 드립니다.
#AWSSummit 해시태그로 소셜 미디어에 여러분...
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20
Upcoming SlideShare
Loading in …5
×

AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20

5,258 views

Published on

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

Published in: Technology
  • heal from broken heart" Love spell from dr.Unity brought my husband back" I'm so excited my husband is back after he left me for another woman" After 12years of marriage, me and my husband has been into one quarrel or the other until he finally left me and moved to California to be with another woman. I felt my life was over and my kids thought they would never see their father again. i tried to be strong just for the kids but i could not control the pains that torments my heart, my heart was filled with sorrows and pains because i was really in love with my husband. Every day and night i think of him and always wish he could come back to me, I was really worried and i needed help, so i searched for help online and I came across a website that suggested that Dr Unity can help get ex back fast. So, I felt I should give him a try. I contacted him and he told me what to do and i did it then he did a Love spell for me. 11hours later, my husband really called me and told me that he miss me and the kids so much, So Amazing!! So that was how he came back that same day,with lots of love and joy,and he apologized for his mistake,and for the pain he caused me and the kids. Then from that day,our Marriage was now stronger than how it were before, All thanks to Dr Unity. he is so powerful and i decided to share my story on the internet that Dr.Unity is real spell caster who i will always pray to live long to help his children in the time of trouble, if you are here and you need your ex lover back or save your marriage fast. Do not cry anymore, contact Dr.Unity now. Here’s his contact,Email him at: Unityspelltemple@gmail.com or Call/WhatsApp him: +2348055361568 ,website:https://unityspelltemples.blogspot.com ,your kindness will never be forgotten.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

AWS 기반의 마이크로 서비스 아키텍쳐 구현 방안 :: 김필중 :: AWS Summit Seoul 20

  1. 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 김필중 | 솔루션즈 아키텍트 2016. 05. 17 AWS 기반의 마이크로서비스 아키텍처
  2. 2. 마이크로서비스
  3. 3. 마이크로서비스 트렌드: 검색
  4. 4. 마이크로서비스 트렌드: 구인 Source: indeed
  5. 5. 누가 마이크로서비스를 사용하고 있나?
  6. 6. 이 세션에서 다룰 내용 • 마이크로서비스가 무엇인지 • 기존 서비스와는 어떤 차이가 있는지 • 마이크로서비스 디자인과 고려사항 • AWS 와 마이크로서비스
  7. 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. 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. 9. Amazon 서비스 구조도 Netflix
  10. 10. Monolithic vs. SOA vs. Microservices SOA 거친 입자 Microservices 고운 입자 Monolithic 하나의 입자
  11. 11. Monolithic 아키텍처 Order UI User UI Shipping UI Order Service User Service Shipping Service Data Access
  12. 12. Monolithic 아키텍처 - 확장
  13. 13. 마이크로서비스 아키텍처 Order UI User UI Shipping UI Order Service User Service Shipping Service
  14. 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. 15. Monolithic 아키텍처에서 발견할 수 있는 것들 • 복잡한 코드와 관리의 어려움 • Bottleneck 이 될 수 있는 배포 • 변경의 두려움 • 부족한 주인의식 • 연쇄 실패 • 확장의 어려움
  16. 16. Monolithic 아키텍처에서 발견할 수 있는 것들 • 복잡한 코드와 관리의 어려움 • Bottleneck 이 될 수 있는 배포 • 변경의 두려움 • 부족한 주인의식 • 연쇄 실패 • 확장의 어려움 하나의 패키지에 모든 컴포넌트들 포함
  17. 17. Monolithic 아키텍처에서 발견할 수 있는 것들 • 복잡한 코드와 관리의 어려움 • Bottleneck 이 될 수 있는 배포 • 변경의 두려움 • 부족한 주인의식 • 연쇄 실패 • 확장의 어려움 Dev 테스트 종속성 Staging 배포 Q&A Production 배포
  18. 18. Monolithic 아키텍처에서 발견할 수 있는 것들 • 복잡한 코드와 관리의 어려움 • Bottleneck 이 될 수 있는 배포 • 변경의 두려움 • 부족한 주인의식 • 연쇄 실패 • 확장의 어려움 비지니스 요구사항을 해결하는 새로운 프레임워크, 서비스 등장 하나의 변경 => 다양한 Side effect
  19. 19. Monolithic 아키텍처에서 발견할 수 있는 것들 • 복잡한 코드와 관리의 어려움 • Bottleneck 이 될 수 있는 배포 • 변경의 두려움 • 부족한 주인의식 • 연쇄 실패 • 확장의 어려움 그거 할 시간 없어요, 그런건 QA 가 해야죠. 데이터베이스가 어떻게 작동하는지 알 필요 없죠, 그건 DBA 가 하는거니까요. 코딩 끝났어요, 이제 OPS 가 항상 작동하게(HA) 할 거에요.
  20. 20. Monolithic 아키텍처에서 발견할 수 있는 것들 • 복잡한 코드와 관리의 어려움 • Bottleneck 이 될 수 있는 배포 • 변경의 두려움 • 부족한 주인의식 • 연쇄 실패 • 확장의 어려움 하나의 실패 => 시스템 전체의 실패를 야기
  21. 21. Monolithic 아키텍처에서 발견할 수 있는 것들 • 복잡한 코드와 관리의 어려움 • Bottleneck 이 될 수 있는 배포 • 변경의 두려움 • 부족한 주인의식 • 연쇄 실패 • 확장의 어려움 기능 추가는 다양한 부서간의 의사소통을 요구 => 늦어지는 업데이트
  22. 22. 마이크로서비스로 얻을 수 있는 것들 • 서로 다른 서비스들은 서로 다른 언어로 개발 가능 • 쉬운 integration 과 automatic deployment • 쉽게 이해하고 수정가능한 코드들 => 새로운 팀원의 생산성 향상 • 최근 기술을 비교적 쉽게 도입 • 빠른 서비스 시작 속도와 빠른 배포 • 기능 추가시 해당 서비스만 수정 및 배포 할 수 있음
  23. 23. 마이크로서비스 아키텍처 특징 Do one thing well Independent Decentralized Black Box Polyglot You build it, you run it
  24. 24. 잦은 오해
  25. 25. Agile, 12-Factor App, Docker, Dropwizard, SpringBoot, Play, Ratpack, … 마이크로서비스 !=
  26. 26. 무엇이 필요할까?
  27. 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. 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. 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. 30. 그럼 어떤 팀 조직이 필요할까?
  31. 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. 32. 4명 / 유닛6~8명 / 팀 선호 팀 크기 source: wikipedia
  33. 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. 34. 12 / 664 / 6 팀 크기와 커뮤니케이션 채널 6 / 15 Source: http://chrisnielsen.ws/how-big-teams-choose-to-fail/
  35. 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. 36. 마이크로 서비스 아키텍처 - 디자인과 고려사항
  37. 37. 실시간 멀티플레이 게임 - 탱크 슈팅 게임
  38. 38. 지역 선택과 접속 게임 플레이
  39. 39. 요구사항 • 가능한 적은 관리 포인트 • 다양한 분석이 가능하여야 함 • 게임 기능 • 유저는 특정 Area 에 접속하여, 그 Area 에 접속한 다른 유저들과 게임 플레이 • 일정 수의 Bot 이 있어 다른 유저가 없더라도 게임이 가능 • 아이템 구매가 가능 • 랭킹을 볼 수 있음
  40. 40. 요구사항 • 가능한 적은 관리 포인트 • 다양한 분석이 가능하여야 함 • 게임 기능 • 유저는 특정 Area 에 접속하여, 그 Area 에 접속한 다른 유저들과 게임 플레이 • 일정 수의 Bot 이 있어 다른 유저가 없더라도 게임이 가능 • 아이템 구매가 가능 • 랭킹을 볼 수 있음 AnalyticsRankingItemGameArea … AWS Lambda …
  41. 41. 마이크로서비스 아키텍처의 고려사항 • 리소스와 상태 관리 • 모니터링 • 서비스 Discovery • 배포
  42. 42. 마이크로서비스 아키텍처의 고려사항 • 리소스와 상태 관리 • 모니터링 • 서비스 Discovery • 배포
  43. 43. 서비스에 적합한 컨테이너 • 간단하게 모델링이 가능 • 애플리케이션 종류, 언어 종류 상관 없음 • 이미지 그 자체가 버전 • 테스트와 배포시 같은 이미지를 사용 • Stateless 서버를 통해 변경의 위험을 줄임
  44. 44. Server Guest OS Bins/Libs Bins/Libs App2App1 명확한 하나의 호스트 관리
  45. 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. 46. Amazon EC2 Container Service
  47. 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. 48. 잠깐, 리소스 관리가 꼭 필요할까?
  49. 49. No server is easier to manage than ‘no server’ Werner Vogels CTO, Amazon.com
  50. 50. 리소스 관리: AWS Lambda 서버 없는, 이벤트 처리 방식의 컴퓨팅 서비스 Lambda = 서버 없는 마이크로서비스 • 인프라 없이 코드를 실행 • 제한없는 확장 • 완전 자동화된 관리
  51. 51. Localytics 사례 Analytics processing service (enriches data) Elastic Load Balancing Amazon SQS Analytics DB Microservice Internet HTTP endpoint 마이크로서비스가 추가될 때 메인 서비스 업데이트가 필요
  52. 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. 53. 마이크로서비스 아키텍처의 고려사항 • 리소스와 상태 관리 • 모니터링 • 서비스 Discovery • 배포
  54. 54. 모니터링: Amazon CloudWatch • 1분 주기로 metric 데이터가 집계되고, 2주간 보관 • 이용 가능한 metric: CPUReservation, MemoryReservation, CPUUtilization, MemoryUtilization • 이용 가능한 dimension: ClusterName, ServiceName
  55. 55. 모니터링: Amazon CloudWatch
  56. 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. 57. 모니터링: Datadog 와 Amazon ECS
  58. 58. 모니터링: Sysdig Cloud 와 Amazon ECS
  59. 59. 마이크로서비스 아키텍처의 고려사항 • 리소스와 상태 관리 • 모니터링 • 서비스 Discovery • 배포
  60. 60. 서비스 Discovery: ECS 서비스와 Route 53 • Route 53 의 Private Hosted Zone 활용 • DHCP Options Sets 으로 호스트의 Search Path 설정 • ECS 서비스를 ELB 와 함께 설정 • 각각의 ELB 에 CNAME 을 생성
  61. 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. 62. 서비스 Discovery: Weaveworks
  63. 63. 서비스 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
  64. 64. 서비스 Discovery: 기타 • Zookeepr • Doozer • Etcd • Airbnb 의 SmartStack • Netflex 의 Eureka • NSQ • Serf • SkyDNS • …
  65. 65. 마이크로서비스 아키텍처의 고려사항 • 리소스와 상태 관리 • 모니터링 • 서비스 Discovery • 배포
  66. 66. 배포: 라이프사이클 개발자 배포 파이프라인마이크로서비스 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
  67. 67. ECS 의 스케줄링 컨테이너 배치 작업 ECS Task 스케줄러 Task 를 한번 실행 배치 작업 RunTask (랜덤) StartTask (배치) Long-running 애플리케이션 ECS 서비스 스케줄러 상태 관리 스케일 업 / 다운 가용영역 인지
  68. 68. 스케줄링 컨테이너: Long-running 애플리케이션 Blue-Green 배포 • 두개의 ECS 서비스 정의 • 각 서비스는 ELB 와 연동 • Route 53 의 가중치 라우팅 정책으로 두개의 ELB 에 각 100%, 0% 로 설정 • Blue, Green 서비스에 배포 및 가중치 변경 TaskTask Route 53 record set with weighted routing policy 0% 100%
  69. 69. 배포: AWS Lambda 배포 코드 완료! Lambda 함수 업데이트
  70. 70. 배포: Vingle 사례 Opsworks (Background) Route 53 OpsWorks (Service) CloudWatch S3SNS RDS ElastiCache DynamoDB RedShift Elastic Load BalancingUsers
  71. 71. 배포: Vingle 사례 로컬 개발 Docker빌드 스테이징 테스트 프로덕션 배포 로컬 개발 테스트 (5분) 스테이징 (20분) 테스트 프로덕션 (20분) 배포 Container 이용 이전과 이후
  72. 72. 배포: Vingle 사례 배포 OpsWorks EC2 Booting (1분) Container Deliver (1분) Opsworks에 정의된 Ruby On Rails App On service (2분)
  73. 73. 배포: ECS CI/CD 파트너
  74. 74. 배포: Shippable 을 활용한 ECS CD
  75. 75. 아키텍처 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
  76. 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 Amazon ECS Container
  77. 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 Serverless API Gateway AWS Lambda
  78. 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 Databases Amazon DynamoDB
  79. 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 Analytics Amazon Elasticsearch
  80. 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 ServiceAutomation & Deployment CloudFormation CodePipelineOpsworks Elastic Beanstalk
  81. 81. 정리 • 혁신과 속도를 위한 마이크로서비스 • 트레이드오프와 새로운 도전 • 자동화는 복잡함에 대한 해결책 • 관리 오버헤드를 줄이기 위해 클라우드 기반의 툴들 • 노 서버 = 노 오버헤드 • 변화의 위험은 툴과 문화로 줄일 수 있습니다!
  82. 82. AWS 와 마이크로서비스
  83. 83. 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
  84. 84. 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
  85. 85. AWS 와 마이크로서비스: Polyglot - 언어 • Java • Python • Ruby • .NET • PHP • Javascript • Node.js • iOS • Android
  86. 86. AWS 와 마이크로서비스: Polyglot - OS • Amazon Linux • Redhat • SUSE • Open BSD • CentOS • Debian • Ubuntu • Windows Server 2003 • Windows Server 2008 • Windows Server 2012
  87. 87. AWS 와 마이크로서비스 • 필요한 만큼만 리소스를 사용 (On Demand Resources) • 관리형 서비스 (Managed Services) • 모든 서비스는 프로그래머블 (Programmable Services) • IaC (Infrastructure as code) • 내장된 기능들 • 모니터링, 보안, 로깅, … • 확장성, 가용성, … • 서버없는 아키텍처
  88. 88. 여러분의 피드백을 기다립니다! https://www.awssummit.co.kr 모바일 페이지에 접속하셔서, 지금 세션 평가에 참여하시면, 행사 후 기념품을 드립니다. #AWSSummit 해시태그로 소셜 미디어에 여러분의 행사 소감을 올려주세요. 발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜 채널로 곧 공유될 예정입니다.

×