1. Amazon & AWS의 Microservices와 DevOps
그리고 지속적 혁신에 대하여
정우진 이사
2017. 09
2. 최근 아마존닷컴 혁신 현황 (2017 H1)
음성인식 가상 비서
2014년 런칭이후
지속적 혁신
현재 1만개 이상의
서비스 연계됨
이미지 인식 코디 서비스
머신러닝 기반
개인에게 맞는 코디
의류 추천 서비스
음성인식+디스플레이
이미지/텍스트/비디오
고도화된 음성인식
서비스 제공
온라인 현금 충전 서비스
(오프라인매장 사용 가능)
Meal Kit (즉석 식사)
간편하게 요리, 한 끼 식사
분량 손질 된 식재료 배송
Stickers
가상환경 기반
제품 배치/매칭
서비스(모바일
카메라 이미지
앱을 통해)
Dash의 Wand 버전
음성/이미지 인식으로
주문 및 배송 서비스
지속적 혁신/진화
다양한 서비스로 확대
고객 중심 및 편의 혁신
최신 AI 등 기술 적용
계속해서 기존
서비스개선/신규 서비스 런칭
MSA/DevOps 효과
Cash, Stickers 등 커머스를
중심으로 다양한 부문으로
AWS
디지털 혁신
가속화
고객의 요구/ 고객의
입장에서 새로운 혁신 발굴
외부 혁신 기술 적극 수용
AWS를 통한 시간/비용절감
Package x-ray
주문한 상품을
포장상태에서
내부의 상품을
확인해 주는 서비스
3. X-Ray Platform은 X-Ray 데이터 게시 및 연계를 위한 서비스 집합체
Amazon Dash의 지속적 진화
어디서 필요한 제품을
원클릭으로 바로 주문/배송
First Open 2nd Improvement
Do it Yourself
고객의 비즈니스에
Dash형 IoT 직접 구현
바코드 인식 + 음성 인식을
통한 NUI로 확대
3rd innovation!
4.
5. ALEXA AND THE VOICE REVOLUTION
Uber를 부르는 것부터 요리 팁에 이르기까지 Amazon의 Alexa는 앱과 상호
작용하는 방법을 변화시키고 있습니다.
“Alexa, ask My Chef
what’s expiring.”
“Alexa, ask Uber to
request a ride.”
“Alexa, ask Fitbit how
I slept last night.
“Alexa, what’s in the
news?”
“Alexa, ask the bartender,
what's in a Tom Collins?”
“Alexa, tell Tide I have
a juice stain.”
6. THE ALEXA ECOSYSTEM
Create
Great Content:
ASK is how you connect
to your consumer
A L E X A
V O I C E
S E R V I C E
Unparalleled
Distribution:
AVS allow your content
to be everywhere
Automated Speech
Recognition (ASR)
&
Natural Language
Understanding (NLU)
A L E X A
S K I L L S
K I T
Alexa에 Skill을 추가하는 간단한
셀프 서비스 API 도구, 문서 및 코드
샘플 모음. 클라우드를 통한 조명
제어 등 Alexa를 학습하고, 스마트
홈 기술 API를 Alexa 기술 장비에
새로 추가 사용 가능
음성인식을 갖춘 마이크와
스피커 디바이스가 있다면
ASK를 활용하여 Alexa를
연계하여 서비스 제공
Supported by two powerful offerings
7. AI 스피커 ‘아마존 에코’, 미국 시장 점유율 70% 확보
AI스피커활성이용자수올해3억5600만명 –작년대비2배증가
AI스피커미국시장점유율
알렉사기반스킬1만개돌파–반년사이6천개증가
아마존'에코'
70%
구글'구글홈'
24%
기타
6%
0
2000
4000
6000
8000
6월 7월 8월 9월 10월 11월 12월 1월
[알렉사 스킬 개수] [알렉사 스킬 카테고리별 분포]
- 아마존 ‘에코(Echo)’ – 70.6%
- 구글 ‘구글 홈(Google Home)’ – 23.8%
- 기타 – 5.6%
8.
9.
10.
11.
12. The world’s most advanced shopping technology
Amazon Go는 체크 아웃(결재)이 필요 없는 새로운 종류의 상점.
세계에서 가장 진보 된 쇼핑 기술을 개발.
줄을 서서 기다릴 필요가 없는 Just Walk Out 쇼핑 경험
단순히 Amazon Go 앱을 사용하여 상점에 입장, 원하는 제품을 가져 와서
바로 줄설 필요가 없고 결재 없이 바로 나가는Go.
컴퓨터 비전, 센서 퓨전 및 딥러닝과 같은
자율 주행 차량에 사용되는 것과 동일한 유형의 기술
Just Walk Out Technology는 선반에서 제품을 가져 오거나
선반으로 반품 할 때 이를 자동으로 감지하고 가상 카트에서 제품을 추적.
쇼핑을 마친 후에는 잠시 후 고객의 Amazon 계정에 청구서 전송.
시작하려면 무엇이 필요합니까?
Amazon 계정, 지원되는 스마트 폰 및 무료 Amazon Go 앱만 있으면 됨
13. Learn From Amazon, Execute at AWS
아마존을 통해 혁신을 배우고, 아마존웹서비스에서 혁신을 실행
Digital Business
Digital
Innovation
Digital
Transformation
14. 아마존의 디지털 트랜스 포메이션
데이터를 비즈니스 가치로 전환하고 데이터를
자산화하여 플랫폼 서비스로 만드는 것
1. 아키텍처
MicroServices
3. 메커니즘
DevOps&CI/CD
2. 방법론
Agile(Scrum)
15. disrupted
“클라우드 컴퓨팅”을 활용한 비즈니스 모델의 혁신
파괴적 혁신 (Disruption) 을 통한 비즈니스 모델의 증가
Hospitality Insurance Devices TradingMedia
16. “디지털 트랜스포메이션“ 가속화
민첩성 Agility, Time to Market 유연성 flexibility 지속성 sustainability
“ M any of our customer s ar e tr ansfor ming their w or lds as w ell.”
W e r n e r Vo g e l s
A m a z o n W e b S e r v i c e s , C TO
17. 인프라 관리에
드는 부담 감소
실험 및 혁신에
리소스 투자 가능
신규 비즈니스
구현에 집중
핵심 비즈니스에 역량 집중
On-Premises
$ Millions Nearly $0
실패
= 막대한 비용 손실
잦은 실험적
시도 불가
혁신 시도에 대한
부담이 큰 환경
혁신을 촉진하는 환경
실패하더라도 적은
비용 / 시간만 손실
잦은 실험적 시도
Vs.
Cloud
기획 및 계획에서
실험과 테스트로
비즈니스 가능성과
혁신적 비즈니스
실행력 제고
19. IT를 바라보는 시각의 전환
과거 현재
거액의 투자가 수반되는 프로젝트를
통해 IT 구축
관리 및 유지보수 위주, 최신 기술
도입을 위해 지속적으로 재투자
느리고 경직된 인프라
운영을 위해 거액 투자
신규 기능 및 최신 기술이 자동으로
Update
고품질의 Managed Service
경쟁우위로서의 민첩성 확보를 위한
확장성 있고, 유연한 핵심 자원
22. Microservices at Amazon.com (Mobile App)
아마존 프라임
고객 차별화
최근 관심
상품에 대한
추천
모바일 화면에
최적화된 최소
상품 게시
이미지
검색
제품 브랜드
이미지 태그
관련 상품
리스트
음성인식
제어
Where’s my
package?
내가 주문한
상품에 대한
상태 화면
23. Microservices의 유래
마이크로서비스는 Microservices는 새로운 용어지만, 개념은 10여년 전 부터
있어 왔던 개념이며, 기존 애플리케이션 현대적인 기술을 통합 가능하게 하거나
또는 이전과 완전 다른 새로운 어플리케이션으로 오직 HTML링크와 공유
데이터 베이스를 통해 결합하는 새로운 접근 방법으로 2008년 부터 본격화됨
When
Who
What
CAP
2006년 JAOO 컨퍼런스
JAva Object Oriented 소프트웨어 개발 컨퍼런스, 최근 GOTO로 변경
Amazon 총괄CTO
워너 보겔스 Werner Vogels
NoSQL의 기반이 되는 CAP이론과 자체 데이터베이스를 갖고
서비스를 개발하고 운영하는 작은 팀 – 마이크로서비스 아키텍처와 데브옵스
분산 시스템에서 일관성(Consistency), 가용성(Availability),
파티션 허용(Partitions Tolerance) 이 세개 속성을 모두 가지는
것은 불가능 하다
24. Why Microservices for Amazon.com?
아마존에서 마이크로서비스가 필요했던 이유는 무엇보다 지속적이고 신속하게
개별 서비스를 혁신하고, 기존 서비스에서 새로운 기술 기반의 서비스를 개발 및
통합하기 위해서 새로운 아키텍처와 방식이 요구되었음
강력한
모듈화
의존성 최소화
독립적인 확장
대체성
쉬운 교체 가능성
레거시
애플리케이션
기존 어플리케이션
에서 추가 개발
기술의
자유로운 선택
기술 제약 없이
새로운 기술 도입
지속적인
운영환경 배포
서비스별 신속/지속
업데이트
지속 가능한
개발
마이크로서비스
적시 출시
시장 출시 기간 단축
25. Agile coding in enterprise IT: Code small and local
http://usblogs.pwc.com/emerging-technology/agile-coding-in-enterprise-it-code-small-and-local/
26. 마이크로서비스란? Micro-service anatomy
Micro-service = Service-oriented architecture + “small” public API
Micro-service
Software Modules
(application, libraries, etc)
Data Store
(eg, DynamoDB, RDS,
Cache, S3)
Public API
addProductDetails(ProductId id, ProductDetails details)
removeProductDetails(ProductId id)
getProductDetails(ProductId id) : ProductDetails
27. 마이크로서비스는 라이브러리가 아닌 단지 서비스일 뿐
Product Details
software library
Product Details
micro-service
getProductDetails()
• A new version of a micro-service is immediately noticed by its dependent micro-services
• Micro-services relying on libraries will have to be rebuilt and re-deployed upon a new version of the library
28. 마이크로서비스 개발팀은 기존 보다 작은 단위로 구성
2-pizza Amazon Development Teams
“Pick customer orders” Team
2-pizza team
(typically 4-8 people)
Micro-service
Warehouse employee using
micro-service via web interface
29. 마이크로서비스는 다른 퍼블릭 API 상호 의존하는 방식
Micro-service Micro-service
public API
public API
30. Web of Micro-services
Store products in the warehouse
Pick products for customers Report defects
Track shipments
Product Details
32. Legacy eCommerce Application Modernize
기존 어플리케이션은 한 통으로 구성되어 전체적으로만 배포(업데이트)할 수
있으며, 기능이 변경될 때마다 전체 어플리케이션이 다시 배포돼야 했다. 여기에
eCommerce는 백엔드에 회계나 물류 같은 다른 시스템도 함께 작동됨(의존)
제품
검색팀
고객
관리팀
주문
처리팀
배포테스트개발
단일
어플리케
이션
• 느린 지속적인 전달 개발/운영 배포 환경
• 각 개발팀간 병렬 작업의 복잡한 (상호 의존)
• 테스트 동안 병목(오류 해결)너무 긴 업데이트 시간
33. Legacy eCommerce Application Modernize
새로운 기능을 신속히 개발하고 더불어 여러 기능을 동시에 작업하는 능력이
비즈니스의 성공에 있어 매우 중요함. 더 빠르게 많은 기능을 개발할 수 있는
마이크로서비스 환경으로 전환
제품
검색팀
고객
관리팀
주문
처리팀
• 새로운 기능의 신속하고 독립적인 개발
• 테스트 병목 해결 및 품질 향상, 지속적 업데이트 가능
배포테스트개발
배포테스트개발
배포테스트개발
34. Amazon은 오랜 시간동안 Microservices를 활용 및 고도화
아마존은 새로운 기능을 웹사이트에 빠르고 쉽게 구현하고, 2006년 클라우드
플랫폼을 제시하고 소프트웨어를 개발하는 방법과 아키텍처를 제공함. 또한
운영 전문가와 개발자로 구성된 팀을 갖는 데브옵스를 도입. 이러한 접근 방법은
클라우드 환경에서 서버들의 수동적인 구축으로는 실현할 수 없는 자동화된
방법으로 대규모 개발을 하는 것을 의미함. 마이크로서비스의 필수 요소
애플리케이션은 서로 다른 서비스로 분할
각 사이트는 웹사이트의 일부를 제공 (예, 검색을 위한 서비스, 추천을 위한 또 다른 서비스가 있음)
결국 개별 서비스는 UI에서 함께 제공
항상 하나의 팀이 하나의 서비스에 대한 책임을 갖음. 팀은 서비스의 운영뿐 아니라 새로운
서비스의 개발도 담당. (여러 개의 서비스를 담당할 수도 있음)
클라우드 플랫폼. 모든 서비스에 대한 공통 기반으로 작동.
이외에 다른 표준은 없고, 각 팀은 기술의 선택이 매우 자유로움.
35. DB
DB
Architectural Approaches
Client-Server
Multi-tier with web, application
and database tiers
Microservices
Messaging-oriented middleware
Client Server
Mobile/Web
Clients
Web
Tier
Application
Tier DB
Mobile/Web
Clients
Service
Service
Service
Publisher Subscriber
Seeing a big shift towards…
DB
40. Microservices 아키텍처 유형
단일 페이지 앱을 갖는 마이크로서비스 하나의 단일 페이지 앱을 공유하는
마이크로서비스의 밀접한 통합
프론트엔드 서버를 이용한 통합
단일
페이지앱
로직
REST
마이크로서비스
단일
페이지앱
로직
REST
마이크로서비스
링크
모듈
로직
마이크로서비스
모듈
로직
마이크로서비스
단일 페이지 앱
마이크로서비스의 사용자
인터페이스에 대한 강력한
통합이 필요한 경우
완전히 분리되며 독립적인
서비스간의 연계를 위한 구성
강력한 통합은 어려움
프론트엔드 서버
CSS, 자바스크립트
HTML
코드조각
로직
마이크로서비스
HTML
코드조각
로직
마이크로서비스
강력한 통합을 위한 대안
서로 독립적으로 생산환경에
적용 가능(예, 자바포틀릿)
42. 비즈니스 모델의 변화
권한 부여
유연성 / 적응력
LOCK IN
효율성
소유
저비용
클라우드 컴퓨팅이 촉발한 새로운 IT Paradigm에서 비롯된
비즈니스의 근원적 변화
다양한 형태의 소비
한계 비용 Zero
고객
프로세스
자원
비용
43. Lean Enterprise - 전통적 기업 경영 방식과의 차이
Source: http://www.stratfordmanagers.com/2014/08/product-innovation/
비즈니스 플랜,
정교한 계획 수립
“경영진의 큰 그림”
개발, 직관
Waterfall (순차적 진행, 특정
단계 도달 시 변경 불가)
회계
예외적으로 발생하는 일
측정, 목표 소요시간
Traditional
비즈니스 모델, 실험적 시도
반복적 설계, 고객 피드백
Agile (빠른 개발, 반복적 변경)
도입, 비용
예상된 일, 발전을 위한 중추
가능한 빠르게, 방향성
Lean
전략
신제품 개발
IT 개발
성과 측정
실패
속도
44. Tools & Technology
개발/테스트 혁신을 위해 탄력성 및 온-디맨드 레버리지
수명주기 관리 및 운영을 자동화, 간소화
모든 것을 추적: 분석 및 인사이트 도출을 위한 지표, 데이터
적정 영역에는 상이한 비용 모델 적용
Lean Dev & Test
Lean IT Operations (DevOps)
Lean Analytics
Lean Architectures
45. 1. Lean Dev & Test
빠른 프로토타이핑 및 혁신
실제 환경에서 실험 – 실제 운영환경을 완벽하게 재현
시간제로 악영향 없이 반복 수정 – 빠르고, 저렴하게 실패
+ C
+ V
46. 2. Lean Operations
“DevOps는 ITIL에 대한
프로세스 개선과 같은 것”
CloudTrail Identity & Access
Management
Security Groups
보안, 컴플라이언스 확보 ITSM Framework 충족
47. 3. Lean Analytics
“빅데이터 분석을 하지 않은 기업들은
귀머거리에 장님이며,
고속도로의 사슴처럼 웹에서 헤매게 될 것이다.”
Geoffrey Moore,
Author of “Crossing the Chasm”
고비용 & CAPEX
복잡
장시간 소요
온- 프레미스
저비용 & OPEX
간결과 및 자동화
명백한 시간절감 효과
vs
AWS
48. 3. Lean Analytics
Networking
VPC
Direct
Connect ELB Route53
Storage
S3 EBS Glacier
Storage
GatewayEC2
Compute
WorkSpaces
Elastic
MapReduce
Data Pipeline
호스티드 Hadoop
framework
AWS 서비스와 온-
프레미스 간 데이터
이동
Redshift
페타바이트
스케일의 데이터
웨어하우스 서비스
Kinesis
대규모 스케일
상에서 스트리밍
데이터 실시간
분석
전혀 관리가 필요 없는
빠르고 예측 가능한
성능을 보유
DynamoDB
51. Lean Finance
Humble, Molesky, O’Reilly, Lean Enterprise: How High Performance Organizations Innovate At Scale
연속적 배포
고객
서비스 데스크운영 관리
Cross-
Functional
Product
Teams
Cloud Competency Center
Cloud
= 제품/서비스 전체에 대한
가치 파악 가능
처음부터 끝까지 제품/서비스를 중심으로 생각!!!
52. Lean Governance, Risk & Compliance (GRC)
• 최근 조직들이 직면하는 가장
큰 리스크는?
You build the wrong thing
(불필요한 곳에 자원 투입)
Humble, Molesky, O’Reilly, Lean Enterprise: How High Performance Organizations Innovate At Scale
Lean Enterprise LoopEnterprise Loop
현 관리체계의 허점은? 의미 없는 프로세스 반복은 중단
53. Lean Governance, Risk & Compliance (GRC)
…다수의 GRC 프로세스가 Lean 규칙에 위배
현 관리체계의 문제점
대형화된 조직
낭비
수 많은 체크사항들
비용 과다 소요
리스크 관리 실효성 저하
54. Organizational Alignment
경영진:
리더십, 비전, 사내 소통, 비즈니스 목표
인접 부서:
재무, 인사, 리스크 및 사업부 의사결정자와 협업
정보보안 및 컴플라이언스 부서:
정책 및 절차 변경사항 소통 및 승인 획득
IT 부서:
Gap분석, 변화관리, 클라우드 전문성 보유자 발탁
IT 담당자:
비전에 대한 공감대 형성 및 도전의식 고취
이해관계자 유형 별 소통 방안
57. 기존 On-premise 환경 경직된 IT인프라 상에서 개발이 끝나면 장기간 운영 체계로 전환되지만
클라우드를 도입하면서 지속적인 개발 및 업데이트로 사실상 개발과 운영이 통합 환경 전환
Dev Ops – Lean Enterprise로 전환
개발자 고객
개발 테스트 배포
계획 모니터링
Delivery Pipeline
Feedback Loop
소프트웨어 개발 사이클
DevOps
=
소프트웨어 개발 사이클을
빠르게 수행하기 위한 효율성
DevOps는 배포 및 피드백 절차를
빠른 속도로 무한대 반복 가능
58. 58
기존 개발 방식 vs. 애자일 개발
워터폴형 개발 애자일 개발
요건
설계
코딩
단위
테스트
종합
테스트
릴리즈
처음에 요건을 미리
모두 정하고 나서
개발
릴리즈
릴리즈
릴리즈
릴리즈
비즈니스 상의
중요도에 따라 요건의
우선 순위를 정해, 그에
따라 필요한 기능을
순차적으로 개발
반복(이터레이션)
1
반복2
반복3
반복4
59. 59
DevOps
모든 기능 완성 시 까지 이용 불가
느린 릴리즈 사이클
- 버그 수정, 기능 추가에 시간 소요
- 사용자 만족도 저하
릴리즈 직후
버그 등으로
일시적 기능
저하
초기에 기능은 적으나, 바로
이점 활용 가능
빠른 릴리즈 사이클
- 즉각적 오류 수정 및 기능 추가
- 사용자 만족도 향상
개발 운용
신속
대응
안정
가동
개발 운용
개발과 운용의 일체 운영
기존의 개발 방식 DevOps
60. Deploying More Frequently Lowers Risk
Smaller Effort
“Minimized Risk”
Frequent Release Events:
“Agile Methodology”
Time
Change
Rare Release Events:
“Waterfall Methodology”
Larger Effort
“Increased Risk”
Time
Change
61. Evolution of DevOps from Agile (through AWS)
Provision Configure Orchestrate Deploy Report Monitor
DevOps
• Continuous Integration
• Continuous Deployment
• IT Automation
• Application Management
Business Case
Requirem
ents
Use Case Features Plan
Go to
market
Business
Design Code Refactor Unit Test Bug Fix Deploy
Developers
(application)
IT Operations
(infrastructure)
Agile
Development
• Iterative development
• Scrum, sprints, stories
• Velocity
Business
Agility
IT
Agility
62. DevOps Principles
Collaboration -협업
Breakdown the barriers –장벽 구체화
Work as one team end to end –팀으로 끝에서
끝까지 일하기
Treat Infrastructure as code – 코드 인프라로 처리
Support business and IT agility –IT민첩성 기반의
비즈니스 지원
Automate everything – 모든 것 자동화
Test everything – 모든 테스트
Measure & monitor everything -모든 것
측정/모니터링
No more MANUAL HACKING
• Infrastructure treated like app source code
• Maintained in version control
• Application management includes both:
Application Source Code
and Infrastructure as Code
Overview of DevOps on AWS
Introduction to DevOps on AWS v1.0
63. Continuous Integration / Deployment & Automation
Version Control
Build/
Compile
Code
Dev
Unit Test
App Code
IT Ops
DR Env
Test Env
Prod Env
Dev Env
Application
Write
App Code
Infrastructure
CloudFormation
tar, war, zip
yum, rpmDeploy
App
Package
Application
Deploy application
only
Deploy infrastructure
only
AMI
Build
AMIs
Validate
Templates
Write
Infra Code
Deploy
Infras
Automate
Deployment
Artifact Repository
Overview of DevOps on AWS
Introduction to DevOps on AWS v1.0
