클라우드 네이티브로의 전환을 위한 여정

클라우드 네이티브로의 전환을 위한 여정과 성공사례
JungIn Lee (Account Executive)
junlee@pivotal.io

Iteration Driven Innovation
In fact, the only way to successfully innovate is
to be prepared to iterate like crazy.
사실, 성공적으로 혁신할 수 있는 유일한 길은
미친듯이 반복할 수 있도록 준비하는 것 뿐이다
Innovation != Iteration

Iteration Driven Innovation을 위한 Key Questions
DevOps
Cloud Native
App
Org
/Process
Iteration
Driven
Innovation
코딩 시간 어떻게 늘리지?
언제든 배포하기?
운영은 누가하지?
팀 Balance 어떻게?
소통의 방식은?
방법론은?
왜 Cloud Native?
마이크로 서비스?
어떻게 시작하지?

DevOps의 유래
Patrick Debois
(데브옵스 창시자)
Andrew Clay Shafer
(현재 Pivotal 근무)
John Allspaw & Paul
Hammond
• 2008년 캐나다 토론토에서 열린 Agile
Conference에서 Agile
Infrastructure라는 주제로 발표
• 해당 발표에는 Patrick 외에는
들어오지 않아, 강연 취소
• 이후 Patrick 과 복도에서 만나 이야기
• Agile System Administration
구글 그룹 생성
• 2009년 O’Reilly Velocity
Conference에서 “10 deploys per Day:
Dev & Ops Cooperation at Flickr”
• 2009년 10월 벨기에에서 Patrick이
DevOpsDays 컨퍼런스 개최
• 2007년 벨기에 정부의 IDC 데이터
이관 프로젝트에 참여
• 테스팅 담당자로서, 개발 조직과 운영
조직 사이에서 힘들어함
• 문제 해결 방법에 대해 고민
• The History Of DevOps ( http://itrevolution.com/the-history-of-devops/ )
• The Origins of DevOps ( https://devops.com/the-origins-of-devops-whats-in-a-name/ )

DevOps가 풀려고 하는 Problems
개발 속도 및
S/W 변경 빈도
Ops
Sec
운영시스템의
안정성
Dev
S/W의 보안성
V2
S1
V1
”운영 안정성의
희생을 최소화하고
동시에 변경 빈도를
높일 수 있을까?”
Key Questions
변경 빈도를 높임으로써 발생하는 운영의 희생을 최소화하고, Dev와 Ops의 Tension의 허용치를 높이는데
목적을 둠

DevOps가 풀려고 하는 3가지 분야
개발 테스트/배포 운영
Request Delivery MaintainProduction
어떻게 하면 요구사항을 누구보다 빠르게 구현할 수 있을까?
개발자 생산성은 어떻게 증가할 수 있을까?
누가 어떤
방식으로 배포해야
하는가?
운영은 누가해야 하는가?
운영팀은 앞으로 무엇을 해야
하는가?
1 2 3
또한, 이 문제를 소프트웨어의 제품 개발에 있어서 3가지의 세부적인 파트로 나누어 바라보기 시작하였음

개발 단계의 문제점
Request Delivery
실제 가치에 기여하는 부분
실제 가치와는 상관 없는 부분
초기 환경
세팅
네트워크 설정
환경 Scale
기다리는 시간
실제로 코딩에 투자하는 시간은 30% 미만인 반면, 내부 조직에 요청하여 기다리거나, 로직 구현과 상관 없는
부분에 투자하는 시간이 존재
기다림
(~30%)
• 지원 조직 설득, 일정
조율 등을 위한
불필요한 미팅
• 이메일/티켓팅 등을
통한 신청
설정 구성
(~30%)
• 미들웨어 설정, 외부
서비스 연동 설정
• CI/CD 환경 구성,
공통 서비스설치
+

배포 단계의 문제점
당시 배포의 문제점
팀의 독립적
배포 불가
Human
Error
커뮤니케이
션 비용
• 릴리즈 관리 팀이 한주/한달에
한번 취합하여 한꺼번에 배포
• 일찍 개발을 완료하더라도,
정해진 날짜가 되어야 배포
• SSH 콘솔에 접근하거나,
Copy&Paste 등의 사람이 개입
필요
• 앱 이외의 설정이나
라이브러리가 변경되면 부서
간의 추가적 커뮤니케이션 비용
존재
이슈 사항
Dev
Team
1
Dev
Team
2
Dev
Team
3
릴리즈
관리 팀
운영 배포
팀
…
Module A
Module B
Module C
취합 전달
배포 롤백
또한, 배포 프로세스는 Silo의 분업형태로 이루어져 있었으며, 이는 개발 모듈의 독립적인 배포를 불가능하게
함과 동시에 에러, 커뮤니케이션 비용이 높아짐

운영 단계에서의 고려사항들
1단계(현재) 2단계 3단계(최종목표)
You build it
You run it
You support it
You build it
You run it
You support it
3단계로 갈 수록 개발팀에서 Operation을 수행할 수 있는 역량/팀과
이를 지원하는 기술 플랫폼이 필요함
You build it
You run it
You support it
3단계 Operation Model
개발팀
플랫폼 팀
Cloud 팀
API 제공
API 제공
피드백
피드백
개발팀의역할
“운영”의 측면에서는 3단계로의 변화를 지향하고 있었지만, 현실적으로 개발팀이 운영할 수 있는 역량과
기술적인 준비가 되어있지 않았음

플랫폼과 3단계 문제들
DevOps 개발팀을 지원하기 위해서는 새로운 Platform과 이를 제품으로 바라보는 “Platform Team”이
필요하다는 결론
Pivotal Cloud Foundry
API제공피드백 제공 API제공피드백 제공 API제공피드백 제공
vSphere
Azure &
Azure StackGoogle CloudAWSOpenstack
Dependency Marketplace MSA Config Pipeline Scaling
SLI/SLO
Monitoring
“D
evO
ps
Team
”
“Platform
Team
"

Balanced Platform Team
원칙에 기반한 “Platform as Product”의 실현을 위해 “Balanced Platform Team”이 반드시 필요함
”운영 안정성의
희생을
최소화하고
동시에 변경
빈도를 높일 수
있을까?”
Key Questions
자율성과 선택의 존중
(Independency, Polyglot)
+
D
evO
ps
Team
원칙에 기반한 개발/운영 환경 제공
(Platform as a Product)
Platform
Team
(SRE)

Pivotal Platform Dojo
Platform Dojo Team:
고객
TEAM
Product
Manager
Platform
Reliability
Engineer
Product
Manager
PCFS
Architect /
PRE
Platform
Reliability
Engineer
PCFS
Architect /
PRE피보탈
TEAM
The Balanced Platform Team
플랫폼 브랜딩
교육 및 내부 전파
셀프 서비스 기능 구현
3rd Party 연동
공통 플랫폼 서비스 구현
수요부서 니즈 파악
PlatformasProduct
PivotalO
ffering

구글의 SRE팀
개발
+
API를 이용한 셀프서비스
자동화
(34%)
새로운 플랫폼
기능 요소 개발
(33%)
Toil
(33%)
예) MySQL, RabbitmQ 설치
플랫폼 요소 업그레이드
플랫폼 자체의 업그레이드
스크립트 지양
매일매일 똑같이 하는 일들..
SRE 팀
In SRE, we want to spend time on long-term engineering project work instead of operational work.
Because the term operational work may be misinterpreted, we use a specific word: toil.
개발팀
플랫폼 팀으로 별도 분리 가능
특히, 구글에서는 이러한 방향을 구체적으로 실천하기 위해 SRE팀을 운영하고 있음

Tickets
Self Service!!!
넷플릭스 플랫폼 팀

DevOps
Cloud Native
App
Org
/Process
Iteration
Driven
Innovation
코딩 시간
어떻게 늘리지?
언제든 배포하기?
운영은 누가하지?
팀 Balance 어떻게?
소통의 방식은?
방법론은?
왜 Cloud Native?
마이크로 서비스?
어떻게 시작하지?

클라우드 네이티브 앱의 출현
기존
모놀리틱
App
(Big Java,
Big DB)
Iteration
Driven
Innovation
클라우드
Scale
API
Immut
able
CI/CD
Image
Contai
ner
Event
Driven
Cache Open
source
Self Services (Good) ??

모놀리틱 구조의 한계
D모듈 변경 시 A,B,C의 추가 테스트 필요
D모듈의 작은 변화도 전체 App의 배포를 요구
D모듈만 테스트하고는 릴리즈 할 수 없음
A,B,C,D모듈이 동시에 변경할 경우 엄청난 부가적인 작업이 필요
결론적으로 매우 느린 릴리즈 사이클이 형성
A 모듈이 집중적으로 많이 사용되는 경우에도
어쩔 수 없이 전체 App을 Scale 헤야 함
(메모리, Disk 등의 비효율성)
A 모듈이 문제가 생기면 장애가 나머지 모듈에도 영향을 줄 수 밖에
없음
모놀리틱 구조의 한계
B
A
D C
A
모듈
의존성 관계
Original
change
Overhead
synchronization
work
D모듈의변경A의Heat가
높을때..
기존 모놀리틱 앱 구조
클라우드 환경에 맞지 않는 모놀리틱 구조는 빠른 시장의 변화에 느리게 반응할 수 있음

12 Factor App의 출현
Iteration
Driven
Innovation
클라우드
Scale
API
Immut
able
CI/CD
Image
Contai
ner
Event
Driven
Cache Open
source
Self Services
More
Freq
Updates
12 Factor
App
(클라우드네
이티브)
Config
Ext.
API/
Port
Log
Strea
m
Statele
ssCI/CD
Depen
dency
MSA
Servic
es Code
Base

마이크로 서비스 아키텍처
21
C
F
B
G H
ED
A Microserv
ice
Microservice
Microserv
ice
Microserv
ice
Microserv
ice
Microserv
ice
Microservice
A
Microserv
ice
Microserv
ice
Microservice
B
C
Microserv
ice
Microservice
E
Microserv
ice
Microserv
ice
Microservice
D
Microserv
ice
Microserv
ice
Microservice
H
Microserv
ice
Microserv
ice
Microserv
ice
Microservice
G
Microserv
ice
Microservice
F
Interface
각각의 마이크로 서비스는
독립적으로 Scale-Out/In
First-in
First-out
(FIFO)
Queue
Publish-
Subscribe
(Pub-Sub)
Queue
Queues, Pub-Sub 등의
비동기성 큐를 통해
독립적으로 Auto-
Scale을 할 수 있는 환경
각각의 State
존재
약속된 API로
통신
더 나아가 Microservice 아키텍처를 통해 독립적인 팀의 의사결정을 극대화 할 수 있는 구조를 채택함

INVENTORY
Prod Release
Prod Release
Prod Release
CATALOG
Prod Release
Prod Release
Prod Release
REVIEWS
Prod Release
Prod Release
Prod Release
SHIPPING
Prod Release
Prod Release
Prod Release
더 나아가 Microservice 아키텍처를 통해 독립적인 팀의 의사결정을 극대화 할 수 있는 구조를 채택함
마이크로 서비스 아키텍처

Application Transformation
PivotalO
ffering
1
클라우드 네이티브로 전환해야
하는 5-10개 앱 선정 2
변환 프로젝트를 통해 피보탈과 함께 일하면서 몇
가지 앱을 전환하고 팀의 전문성을 키워 완성된
Cookbook 전달
App Tx (앱 트랜스포메이션) 서비스는 초기에 5-10개의 대상 앱을 선정하고, 6-10주의 기간동한 Pivotal과 함께
마이크로 서비스로 변환하는 프로젝트를 진행하게 됨
$$$$
Use ROI to Fund Cloud
Native Innovation
리플랫폼 모더나이즈 최적화
(People and Process)
Runs on PCF
마이크로 서비스 Application Transformation
Built for PCFRuns Well on PCF Runs Great on PCF
Cloud Native
New Software Initiatives

Event Storming
■ 모든 업무 도메인 전문가를 한 곳에 초빙해서,
도메인에서 발생하는 모든 Event를
오렌지 ”Sticky Note”로 나열
- 예) Order Submitted, Insurance Policy Rated
■ 목적: 그동안 서로 소통하지 않았던 사람들과
모여 소통의 장을 마련
■ 30명 넘는 인원이 한 장소에 모여서 워크샵
- 40% : 기술, 60%: 현업
Event Storming 과정을 통해 도메인을 Breakdown함

Business Domain Model
(2) Pick a Core Domain
(1) Bounded Context
실제 Bounded Context로 나뉜 부분 중 기술적 난이도와 사업적 영향도를 고려하여 하나의 Domain을 선택함

Cookbook
App Transformation의 결과로 다양한 패턴이 담긴 Cookbook(요리책)을 생성하며, 이를 향후 App
Transformation에 활용

2 pizza teams
Team의 사이즈와 Decision Making Process의 효율성

Balanced Team
성공에 대한 기준
이러한 고객의 문제를
풀어줌으로서 우리는 정말
가치있는 사업적인 결과를 낼 수
있는가?
이런 것들을 어떻게 계속적으로
측정할 것인가?
디자이너
개발자
제품
매니저(PM)
Product
Ownership
Will users like this?
유저들이 정말
좋아할까?
Can we build this?
우리는 이것을
계속적으로 빌드할 수
있나?
Will this help the
business?
정말 우리 비즈니스에
어떤 도움이 될까?
고객을 위한 바람직한
방향성
고객이 진짜 가지고 있는
어려움이 무엇인가? 우리가 맞게
개선하고 있는가?
그 어려움을 어떻게 풀 수 있는가?
고객은 정말 이 애플리케이션을
사랑할 것인가?
실현가능성
이 프로젝트를 성공적으로
수행하기 위해 필요한 기술적인
복잡성은 무엇인가?
변화에 가장 능동적인 개발
문화와 방법론을 만들기 위해서
어떤 부분을 바꿔야 하는가?
신속한 의사결정을 위한 수평적인 팀의 구조 (닭과 돼지, 디자이너의 역할)

Lean
기존 워터폴 방식
애자일 방식
(배움의 연속)
기존의 워터폴 방식의 점차 증가하는 Risk 대비 애자일 방식의 Lean 방식은 계속적으로 Risk를 관리할 수 있는
장점이 있음

Principles over Policies
You Build It, You Run It
You Support It
(Principles over Policies)

Lean
1 Week
또한 1주일 간격의 “배움과 반영”의 반복을 통해 경쟁자보다 신속하게 고객이 원하는 방향의 기능을 구현할 수
있음

Pair Activities
- 20%
+80%
Test
Coverage
>95%
More
Confidence
More
Frequent
Updates

Pair Acitivities
Pair
Rotate
Bus
Counts
(회복성)
집단
Ownership
Clear
Codes
(책임감)

Pivotal Labs
San Francisco Atlanta Berlin Boston Boulder Chicago
Dallas Denver Dublin London Los Angeles New York
Paris Palo Alto Seattle Singapore Sydney Tokyo
“일반적인 컨설팅과는 차별화된 접근 방법론”

DevOps
Cloud Native
App
Org
/Process
Iteration
Driven
Innovation
Platform as
Product
Journey
Application
Transformation
Journey
Application
Innovation
Journey

Dedicated Support Engineer
시작 an immersive experience with
Pivotal ideally at a Pivotal office
확장 delivery of the platform
with my team at my location
플랫폼 교육/프로모션
Use The Platform At Scale
Culture established, Pivotal ramps down
시작 delivering a new platform capability with
Pivotal at my location and/or a Pivotal office
플랫폼 역량 키우기 시작
Launch The Platform Capability
Build a balanced product team
체득 reliability practices in my team, with Pivotal’s
help
플랫폼의 확장
Extend The Platform
Launch more capabilities, cement culture + practices
체득 methodologies and practices within my
team, with Pivotal’s and/or Partner’s help at
my location
애플리케이션 변환을 위한 플랜 수립
Construct And Begin Enterprise
Application Transformation Plan
확장 performing methodologies and
practices with my team at my location
with help from a Partner(s)
Execute App Transformation Plan
Pivotal Platform Dojo
Pivotal Platform Reliability Engineering
Multiple App Transformation ProjectsApp Transformation Projects App Transformation Projects
Pivotal Platform Dojo Pivotal Platform Dojo
기존 앱을 리플랫폼 혹은
마이크로서비스로 분해
Replatform and Modernize Existing Applications
Platform as
Product
Journey
Application
Transformation
Journey
혁신 팀 구성 및 리더에 대한 교육
Establish Innovation Team
& Train New Leaders
Labs Projects On-site Delivery Pivotal Transition Team Services
New Innovation Team
New Innovation Team
New Innovation Team
혁신적인 방법론/문화에 대한 이해
Understand our Innovation Practices
& Culture (TDD, XP, UCD)
Application
Innovation
Journey

Case Studies
DevOps
Cloud Native
App
Org
/Process
Iteration
Driven
Innovation
국내 스타트업 업체 (5월) 국내 금융 지주사 (4월) 국내 핀테크 업체 (2월)
• 마이크로서비스 기반의 셀프서비스
개발 팀을 지원하기 위한 플랫폼 팀
구성
• DevOps 팀의 운영 부담을
경감시키기 위해 플랫폼 도입
• 앱 무중단 업그레이드, 패치, 보안 Fix
등이 가능한 플랫폼 자동화
• 내/외부 용도의 애플리케이션을
클라우드 네이티브 구조의
애플리케이션으로 변경
• Replatforming을 통해 클라우드
네이티브 앱으로 변경
• Labs 를 통해 개발 프로세스에
TDD 및 Pairing (XP) 등을 실제
적용함
• Project Team에서 Product
Team으로의 변화

September 24–27, 2018
Washington DC
Gaylord, National Harbor Discount Code
S1P200_Jlee
Register
Today &
Save!

클라우드 네이티브로의 전환을 위한 여정

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 클라우드 네이티브로의 전환을 위한 여정

Similaire à 클라우드 네이티브로의 전환을 위한 여정 (20)

Plus de VMware Tanzu Korea

Plus de VMware Tanzu Korea (20)

클라우드 네이티브로의 전환을 위한 여정