최근 IT 시장은 ‘클라우드 네이티브’ 라는 컨셉을 적극적으로 받아들이면서 혁신의 속도를 높이기 위해 여러가지 노력을 기울이고 있습니다. 본 세션에서는 ‘클라우드 네이티브’ 를 이루는 4가지 요소인 DevOps, CICD, Container, MSA 를 간략하게 살펴보고 MSA 가 나머지 클라우드 네이티브 3 요소와 어떻게 상호작용하여 고객 여러분의 비즈니스에 도움이 되는지 알아봅니다. 그리고 MSA 로 이행하기 위한 조직면에서의 요건과 기술 면에서의 요건을 살펴봅니다.

1. 클라우드 네이티브 IT를 위한 4가지 요소와 상관관계 -
DevOps, CI/CD, Container, 그리고 MSA
Woosang Lee
AE, Pivotal Korea

2. Agenda
■ 클라우드 네이티브 4요소
■ MSA 장점과 필요 사항들
■ 사례 소개

3. 킅라우드 네이티브 4요소

4. Maximize
Customer
Learning
Time to Value à 0
Optimizing Time to Value
Idea Production
Minimize
Competitive
Entry
Adapt To
Market Shifts
Adrian Cockcroft
VP, Cloud Architecture
Am azon W eb Services
Previously Netflix Cloud Architect

5. 클라우드 네이티브란?
Cloud-native is an approach to building and running applications that exploits the
advantages of the cloud computing delivery model. .. While today public
cloud impacts the thinking about infrastructure investment for virtually every
industry, a cloud-like delivery model isn’t exclusive to public environments. ..
When companies build and operate applications in a cloud-native fashion, they
bring new ideas to market faster and respond sooner to customer demands.
1) 클라우드 컴퓨팅의 장점을 적극적으로 활용하는 모델
2) 개발 생산성 및 IT 속도를 극대화하는게 궁극적인 목적
https://pivotal.io/kr/cloud-native

6. 클라우드 네이티브란?
https://aws.amazon.com/ko/blogs/architecture/wordpress-best-practices-on-aws/
클라우드 적용을 넘어서서
클라우드 네이티브로 IT 혁신
1. Lift & Shift (변화 없음)
2. Containerize (인프라 변화)
3. Cloud Native (인프라 + 개발 변화)

7. 1. DevOps 를 통한 App 서비스 개선 속도의
증가
2. CI/CD 를 통한 개발-운영간 업무 속도의 증가
3. 마이크로서비스를 통한 서비스 안정성과
스케일링 용이성 개선
4. 컨테이너를 통한 IT 유연성 개선
클라우드 네이티브란?
https://pivotal.io/kr/cloud-native

8. 클라우드 네이티브란?
Coding Test QA Staging In-prodSecurity
DevOps 를 통한 App 서비스 개선 속도의 증가

9. 클라우드 네이티브란?
DevOps 를 통한 App 서비스 개선 속도의 증가
Coding Test QA Staging In-prodSecurity
CUSTOMER FACING APP TEAM
SWArch
SWDev
Client SWDev
Ops
CapPlan
Biz An
ProdMgmt
DataArch
LEGACY SERVICE TEAMCUSTOMER FACING APP TEAM
SWArch
SWDev
Client SWDev
Ops
CapPlan
Biz An
ProdMgmt
DataArch
SWArch
SWDev
Client SWDev
Ops
CapPlan
Biz An
ProdMgmt
DataArch

10. 클라우드 네이티브란?
Coding Test QA Staging In-prodSecurity
CI/CD 를 통한 개발-운영 간 업무 속도의 증가

11. 클라우드 네이티브란?
Coding Test QA Staging In-prodSecurity
CI/CD 를 통한 개발-운영 간 업무 속도의 증가
도구를 활용하여 CI/CD 그 자체가 일이 되지 않도록
시각화, 자동화, 프로세스 단순화가 핵심

12. 클라우드 네이티브란?
Coding Test QA Staging In-prodSecurity
마이크로서비스를 통한 서비스 안정성과 스케일링 용이성 개선
BIG
Monolith
App

13. 클라우드 네이티브란?
마이크로서비스를 통한 서비스 안정성과 스케일링 용이성 개선
서비스 컴포넌트 (모듈) 1~n번까지 개별 개발 및 배포 구조
서비스 컴포넌트 1
서비스 컴포넌트 2
서비스 컴포넌트 3
서비스 컴포넌트 n

14. 클라우드 네이티브란?
컨테이너를 통한 IT 유연성 개선
컨테이너
● OS 자원 공유
● MB 단위의 작은 이미지 단위
● 부팅 시간 단축
● 소결합 구조(Stateless) 에 적합
● App 이식성 우수
● IT 자원 효율
가상 서버 (VM)
● 개별 OS 가 강요됨
● GB 단위의 큰 이미지 단위
● 부팅 시간 오래 걸림
● 밀결합 구조 (Stateful) App 많음
● App 이식성 좋지 않음
● IT 자원 비효율 (상대적)

15. 클라우드 네이티브란?
개발 생산성 및 IT 속도 극대화
Coding Test QA Staging In-prodSecurity
Coding Test QA Staging In-prodSecurity
Coding Test QA Staging In-prodSecurity
컨테이너를 활용한 경량
구조의 App 개발을 위한
조직 (문화), 도구, 기술

16. 클라우드 네이티브란?
Amazon 23,000 /
Google 5,500 /
Netflix 500 /
Facebook 1 /
Twitter 3 /
Typical Enterprise 9 +
얼마나 자주 배포하느냐는 문제가 아니며
기술/사업 면에서 서비스 컴포넌트 별로 배포가 필요하다고 판단될 때
즉시 배포할 수 있는 환경이 마련되어 있어야 함

17. 클라우드 네이티브 4 단계 모델 (MSA 중심)
각 단계 특성
클라우드 네이티브
(Cloud Native)
• 마이크로 서비스 구조 사용과 원칙 준수
• API 기반의 소프트웨어 아키텍쳐
클라우드 심화
(Cloud Resilient)
• 장애를 고려한 IT 디자인
• 개별 애플리케이션의 장애가 전체 서비스에 영향을 주지 않는 디자인
• 적극적인 장애 테스트- 커버리지 90% 이상을 추구
• 모니터링, 메트릭들을 플랫폼 차원에서 중앙화된 형태로 지원
• 퍼블릭/프라이빗 클라우드를 아우르는 스케일 전략
클라우드 친화
(Cloud Friendly)
• 마이크로서비스의 12원칙 고려
• 수평적 확장이 가능한 구조
• 플랫폼 차원에서 HA 구조를 지원 – 애플리케이션 차원 HA
클라우드 준비
(Cloud Ready)
• App 에서 파일 시스템 제거, 혹은 오브젝트 스토리지 도입
• 독립 실행형 애플리케이션 준비
• 플랫폼이 네트워크를 제어

18. MSA 장점과 필요 사항들

19. 기존 모노리스의 한계
19
B
A
D C
A
서비스 모듈
상호 의존성
Original
change
Overhead
synchronization
work
‘D’ 개별 모듈에
변경 발생시
인접 서비스에
영향
‘A’ 모듈에만
트래픽이
발생해도
모든 서비스
모듈에 영향
D 모듈에 업데이트가 생기면 나머지 A, B, C 등
인접 모듈들 역시 업데이트해야 한다
개별 모듈의 작은 변화에도 전체 App 을 다시
빌드해야한다
모든 변화를 모아서 대규모의 전체 테스트를
진행하지 않는다면 릴리즈할 수 없다
A, B, C, D 의 동시 업데이트는 매우 힘든 작업이며
많은 리소스가 투입된다
결국, 릴리즈 사이클이 매우 길어지게 된다
A 모듈의 인프라 크기만 커지면 되는 상황에서도
전체 App 의 인프라를 키워야 하는 상황이 온다
A 모듈의 서비스가 중지되면 모든 App 에 영향을
끼친다
한계점들

20. 20
C
F
B
G H
ED
A
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
Microservice
A
Microservice
Microservice
Microservice
B
C
Microservice
Microservice
E
Microservice
Microservice
Microservice
D
Microservice
Microservice
Microservice
H
Microservice
Microservice
Microservice
Microservice
G
Microservice
Microservice
F
인터페이스
개별 마이크로 서비스
단위로 스케일 아웃 및
인
First-inFirst-out
(FIFO)
Queue
Publish-Subscribe
(Pub-Sub)
Queue
Pub-Sub 구조의 큐잉으로
동작하며 큐 대기열의 길이
등으로 오토 스케일링
MSA 개별
스테이터스 유지
API 호출로 상호 통신
모노리스에서 MSA 로

21. D 모듈에 업데이트가 생기면 나머지 A, B, C 등
인접 모듈들 역시 업데이트해야 한다
개별 모듈의 작은 변화에도 전체 App 을 다시
빌드해야한다
모든 변화를 모아서 대규모의 전체 테스트를
진행하지 않는다면 릴리즈할 수 없다
A, B, C, D 의 동시 업데이트는 매우 힘든 작업이며
많은 리소스가 투입된다
결국, 릴리즈 사이클이 매우 길어지게 된다
A 모듈의 인프라 크기만 커지면 되는 상황에서도
전체 App 의 인프라를 키워야 하는 상황이 온다
A 모듈의 서비스가 중지되면 모든 App 에 영향을
끼친다
더 빠른
업데이트
개별적인
확장성
장애 확산
방지
전체적인
퍼포먼스 향상
개별 MSA 팀은 각각의 릴리즈, 피드백 주기를
가진다. 각 서비스는 API 로 통신하여 개별
업데이트에 영향을 받지 않는다
각 MSA 서비스 별로 독립된 인프라 확장, 축소를
진행할 수 있다
장애를 개별 서비스 레벨로
고립시킬 수 있으며 해당 장애의
루트 코즈 분석이 용이해진다
작은 서비스 컴포넌트 단위로 즉각 반응하므로
전체적인 성능 향상에 도움이 된다
모노리스의 한계점들 MSA 의 장점들
모노리스에서 MSA 로
기술 최적화
각 용도, 서비스 별로 최적화된 기술 스택을 MSA
모듈 단위로 선택해서 사용할 수 있다
모듈 재사용
각 MSA 모듈에서 쓰이는 코드들은 재사용이
가능한 형태로 타 MSA 팀에 공유되고 이는 곧
개발자 생산성으로 이어진다
App 유지보수
단순화
각 MSA 모듈들은 작은 형태로 운영되기 떄문에
개발자가 교체되거나 시간이 가더라도 손쉽게
코드를 유지보수 할 수 있다

22. 더 빠른
업데이트
개별적인
확장성
장애 확산
방지
전체적인
퍼포먼스 향상
MSA 의 장점들
모노리스에서 MSA 로
기술 최적화
모듈 재사용
테스트,
디버깅 단순화
최대한의
자동화
서비스 안정성
플랫폼의 도입
올바른 MSA
구조 정립
MSA 구조에서는 개별 인스턴스의 수가 필연적으로 증가하기 때문에 IaaS 자원
및 SW 배포, 업그레이드, 테스트 등 IT 프로세스의 자동화가 필수이다
각 MSA 모듈 별로 빠른 업데이트를 하면서도 서비스는 무중단으로 유지시킬 수
있는 플랫폼 및 도구의 도입이 필요하다
MSA 구조에서 증가되는 인스턴스의 갯수는 곧 관리 포인트의 증가를
의미하므로 개별 인스턴스의 생명주기를 관장하는 플랫폼의 도입이 필수적이다
비즈니스 로직, 비즈니스 프로세스에 부합하는 MSA 구조를 정립함으로써
사용자 및 사업부에서 요구하는 업데이트를 각 MSA 팀에서 지원하도록 한다
MSA 도입과 함께 조직에서 선행되어야 할 사항
개발자 역량
강화
개발자들은 교육, On the Job Training 등을 통해 스프링 부트, 스프링
클라우드와 같은 MSA 친화적인 개발 프레임워크에 익숙해져야 한다
플랫폼 팀
구축
기업의 표준 기술을 정의하고 레퍼런스 아키텍쳐를 개발하는 등 기술 파편화를
방지하고 플랫폼 자체를 하나의 소프트웨어로 보고 유지보수해나갈 플랫폼 팀이
구축되어야 한다
개발자 업무
scope 감소
각 개발자는 계속 빨라지는 MSA 모듈 업데이트 주기를 지속시키기 위해, DB,
OS, WAS, Library 등 의존성 관리에 시간을 낭비하지 않아야 한다

23. Pivotal Offering
최대한의
자동화
서비스 안정성
플랫폼의 도입
올바른 MSA
구조 정립
조직 선행 사항
개발자 역량
강화
플랫폼 팀
구축
개발자 업무
scope 감소
엔터프라이즈 급 서비스 안정성과 보안을 보장하면서도
개발자 생산성을 크게 향상 시킬수 있는 플랫폼 서비스.
PCF 2.0
Pivotal Labs
AppTX service
실제 고객이 사용중인 App 을 통해 실리콘 밸리의
프로세스와 문화, 그리고 최신의 개발 방법론을 Pair
Programming 을 통해서 전수. 기존 코드 변화의 정도가 높음
실제 고객이 사용중인 App 을 통해 클라우드 네이티브 MSA
애플리케이션으로 변화하는 여정을 도와주는 프로그램.
기존 코드 변화의 정도가 약함.
Tracker/Spring/Concourse
Labs, AppTX 등 서비스와 정기적인 교육을 통해
알맞는 도구들의 사용법을 학습.

24. Embedded OS
(W in d o w s & L in u x )
NSX-T
CPI (15 methods)
v1
v2
v3 ...
CVEs
ProductUpdates
Ja v a | .N E T | N o d e JS
Pivotal Application
Service(PAS)
Application Code & Frameworks
B u ild p a c k s | S p r in g B o o t | S p r in g C lo u d |
S te e lto e
E la s tic | P a c k a g e d S o ftw a r e | S p a r k
Pivotal Container
Service(PKS)
> c f p u s h > k u b e c tl r u n
기 존 모 노 리 스 App 을
구 동
M SA 구 조 App 에
최 적 화
v S p h e r e
A z u r e &
A z u r e S ta c kG o o g le C lo u dA W SO p e n s ta c k
Pivotal
Network
“3Rs”
Github
C o n c o u r s e
C o n c o u r s e
Pivotal Services
Marketplace
Pivotal and
PartnerProducts
Continuous
delivery
PublicCloud
Services
Customer
Managed
Services
OpenServiceBrokerAPI
Repair— C V E s
Repave Rotate— C r e d h u b
MSA 개발/운영 클라우드 플랫폼 모델 예시

25. 자동화/커스텀 사이에서..
Infrastructure aaS
Embedded OS
OS Image
Runtime Layer
Service Brokerage
Application Layer
플랫폼을
통해
자동화!
개발자는
실제
개발만!
Embedded OS
OS Image
Runtime Layer
Service Brokerage
Application Layer
자동화
영역
개발자의
개발 외
업무
Embedded OS
OS Image
Runtime Layer
Service Brokerage
Application Layer
Infrastructure (VM) Infrastructure (VM) Infrastructure (VM)
자동화
영역
개발자의
개발 외
업무
Container aaSPlatform aaS
자동화
영역
개발자의
개발 외
업무

26. DedicatedSupportEngineer
시작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 AndBeginEnterprise
ApplicationTransformationPlan
확장performing methodologies and
practices with my team at my location with
help from a Partner(s)
ExecuteAppTransformationPlan
ExecuteAppTransformationPlan
ExecuteAppTransformationPlan
Pivotal PlatformDojo
Pivotal PlatformReliabilityEngineering
MultipleAppTransformationProjectsAppTransformationProjects AppTransformationProjects
Pivotal PlatformDojo Pivotal PlatformDojo
기존앱을리플랫폼혹은
마이크로서비스로분해
Replatform and Modernize Existing Applications
Platform as
Product
Journey
Application
Transformation
Journey
혁신팀구성및리더에대한교육
EstablishInnovationTeam
&TrainNewLeaders
LabsProjects On-siteDelivery Pivotal TransitionTeamServices
NewInnovationTeam
NewInnovationTeam
NewInnovationTeam
혁신적인방법론/문화에대한이해
Understand our Innovation Practices
& Culture (TDD, XP, UCD)
Application
Innovation
Journey

27. 해외 사례 소개

28. 피보탈은 자동차 업계의 선두그룹 대부분과 소프트웨어 개발 문화를 혁신하고 있음

29. 자동차 업계의 급격한 변화

30. https://www.manufacturingglobal.com/lean-
manufacturing/volkswagen-and-pivotal-set-strategic-partnership-
berlin

31. “O ur IT experts in our labs in Berlin and M unich work the Silicon Valley way, we have brought the Valley to Volkswagen. Pivotal is supporting our
experts with over 20 experts from San Francisco and Boulder, Colorado, and is training them in new software developm ent m ethods. O ur aim is to
firm ly anchor these skills and workstyles in the G roup and in G erm any. In the m edium term , there will be m ore than 600 program m ers, data scientists,
design thinking experts and cloud architects working in our labs in Berlin, M unich and San Francisco”
- Volkswagen G roup CIO Dr. M artin Hofm ann
“베를린과 뮌헨에 위치한 폭스바겐 랩스의 IT 전문가들은 실리콘밸리의 방식으로 일합니다. 실리콘 밸리를
폭스바겐으로 그대로 옮겨왔다고 할 수 있죠. 미국 등에서 온 피보탈의 전문가들이 우리를 돕고 있으며.
소프트웨어를 개발하는 새로운 방법을 가르쳐주고 있습니다. 우리의 목표는 이를 완전히 습득하는 것입니다.
그 중간 과정으로 우리는 600명 이상의 개발자, 데이터 사이언티스트, 디자이너, 그리고 클라우드
아키텍트를 우리의 베를린, 뮌헨, 샌프란시스코 랩스에 보유하게 될 것입니다.”
- Volkswagen Group CIO Dr. Martin Hofmann
http://telematicsnews.info/2016/03/23/volkswagen-and-pivotal-plan-new-connected-services-ma7237/
Volkswagen Digital:Lab and Pivotal plan new connected services

32. 폭스바겐 그룹의 성과 : 사용중인 프라이빗/퍼블릭 클라우드를 안정적으로,
안전하게 계속 확장시킬 수 있었음.

33. 폭스바겐 그룹의 성과 : 그룹 IT 센터를 이용하여 공용 인프라스트럭쳐 위에
비즈니스 도메인 기반의 플랫폼을 제작/도입할 수 있었음.

34. 폭스바겐 그룹의 성과 :
실리콘 밸리의 문화와 일하는 방식을 성공적으로 적용할 수 있었음.

35. 폭스바겐 그룹의 성과 :
독일, 미국 등 세계 각 지역에 LAB을 세우고 새로운 서비스를 제작

37. 고맙습니다.
이우상
woolee@pivotal.io // 010 2035 2412