SK플래닛_README_마이크로서비스 아키텍처로 개발하기

1. 마이크로 서비스 아키텍처로
개발하기
안재우
Platform Architecture팀

2. 오늘 얘기할 내용은
• 마이크로 서비스 아키텍처란?
• 장단점은?
• 무엇이 필요하고, 어떤 점을 고려해야
하는지?
• 우리는 어떻게 하고 있는지?

3. WAS
전통적인 Web App 아키텍처
Browser/
Client
WAR
UI
A Service
A Repository
Database
A

4. WAS
WAS
이중화/로드밸런싱
Browser/
Client
WAR
UI
A Service
A Repository
Database
Load
balancer A

5. WAS
WAS
기능 추가
Browser/
Client
WAR
UI
A Service
A Repository
Database
Load
balancer AB Service
B Repository
B

6. 시스템 연계/통합
WAS
WAS
Browser/
Client
WAR
UI
A Service
A Repository
Database
Load
balancer AB Service
B Repository
B
D System
C System

7. 시스템 연계/통합
WAS
WAS
Browser/
Client
WAR
UI
A Service
A Repository
Database
Load
balancer AB Service
B Repository
B
E System D System
F SystemC System
G System

8. 문제점
• 코드가 너무 커져서 유지보수하기 힘들어요.
• 시스템을 분리하고 싶어요.
• DB를 분리하고 싶어요.
• 연계 시스템이 변경된대요.
• 연계 시스템이 장애나서 우리 서비스도 장애예요.
• 사소한 수정인데도 전체 배포를 하고, QA를 거쳐야
해요.
• 새로운 걸 추가하는 건 상관없는데, 기존
로직/데이터를 변경하면 무슨 문제가 생길지
몰라요.
• 저희도 새로운 버전/기술을 써보고 싶은데…

9. 가면 갈수록
• 뭔가 바꾸는게 두려워진다.
• 개발자들이 구닥다리 기술의 족쇄에서
벗어나지 못하고, 기술 격차는 계속
벌어진다.
• 모든 것은 ‘차세대’가 해결해야 줄 것이다.
(정말?)

10. 나랑 상관없는 상상 속 단어들
Domain Driven
Design
Continuous
Delivery
On-demand
Virtualization
Elastic,
Scalable,
Resilience
Polyglot
Programming
Infrastructure
Automation
Agile
Development
Reusability
Self-government
Team

11. 마이크로 서비스 아키텍처의 배경
Domain Driven
Design
Continuous
Delivery
On-demand
Virtualization
Elastic,
Scalable,
Resilience
Polyglot
Programming
Infrastructure
Automation
Agile
Development
Reusability
Self-government
Team

12. Scale Cube
http://theartofscalability.com

13. Y축 확장
WAS
WAR
UI
A Service
A Repository
Database
AB Service
B Repository
B

14. Y축 확장
Database
A
WAS
WAR
UI
A Service
A Repository
WAS
WAR
B Service
B Repository
Database
B

15. Database
WAS
WAS
WAS
B UI
A UI
Y축 확장 + X축/Z축 확장
Database
A
WAS
WAR
A UI
A Service
A Repository
WAR
B Service
B Repository
Database
B1
B UI
Database
B2

16. 마이크로 서비스란?
• 작고(small)
• API로 다른 서비스와 연계하며(communicate
with APIs)
• 자율적이며(autonomous)
• 한 가지 일을 잘하는데 초점을 맞춘
서비스(focused on doing one thing well)

17. 장점
• Technology Heterogeneity
• Resilience
• Scaling
• Ease of Deployment
• Organizational Alignment
• Composability
• Replaceability

18. 단점
• Complexity
• Multiple Database & Transaction Management
• Complicated Test
• Require Automation for Deploy/Operation
• Hard to develop features span multiple
services

19. 이거 SOA 얘기 아니에요?
• 비슷하지만, 달라요.
• SOA는 개념 상으로는 잘못되지 않았어요.
• 다만 방식이 잘못되었을 뿐이죠.
– SOAP Protocol
– WS-*
– Vendor-Driven
– ESB가 모든 걸 다 해결해줄 거라는 잘못된 믿음
(그렇게 선전했던 나쁜 XX)

20. MSA는
• Vendor Driven -> Service Company Driven
• 오픈테크놀로지 기반
• SOAP/XML vs. REST/JSON
• ‘스펙 먼저’가 아닌 ‘현실에서 검증된
Practice들’의 모음
• Agile 개념과의 결합
• Cloud 환경의 활용

21. 야채샐러드하고요,
피자 1개,
햄버거 2개,
생크림케이크 주세요.
피자랑 샐러드는 같이 주세요.
햄버거 1개는 마요네즈
빼주세요. 케이크에는 딸기
토핑을 추가해주세고요.
<SOAP 주문서>
<서빙 테이블=3 주문번호=1234>
<서빙 1>
<동시에>
<주문 1>야채샐러드, 수량 1</주문 1>
<주문 2>피자<Convert>Pizza</Convert></주문 2>
</동시에>
</서빙 1>
<서빙 2>
<주문 3>햄버거2(1개는 마요네즈제외)</주문 3>
</서빙 2>
<서빙 3>
<주문 4>생크림케이크<토핑><딸기>/토핑></주문 4>
</서빙 3>
</서빙>
</SOAP 주문서>
SOA with ESB
샐러드용
주문서
햄버거용
주문서
피자용
주문서
케이크용
주문서

22. Event
Broker
orderReceived
readyToServe
orderServed
GET /vendors/bakery/menu/cakes?q=strawberry+topping
GET /menus
POST /orders
[
{ vendor : “pizzaria”, items : [ { item : “피자”, count : 1 } ] },
{ vendor : “salad”, items : [ { item : “샐러드”, count : 1 } ] }
]
POST /vendors/burger/orders
[
items : [
{ item : “햄버거”, count : 1 } ,
{ item : “햄버거”, count : 1 , option : “마요네즈 제외” }
] },
]
POST /vendors/bakery/orders
[
items : [
{ item : “생크림케이크”, count : 1 , option : “딸기토핑” }
] },
]
MSA with API Gateway

23. 마이크로 서비스 모델링
• Domain Driven Design
• Bounded Context
• Contract-First(API-First) Design
• Decomposed database
• Event-Driven Architecture

24. 모델링/구현 Tip
• API를 먼저 정의하라.
• API를 REST API Maturity Level 2 이상이 되도록
강제화하라.
• API 문서를 유지하라(예: Swagger)
• ORM을 활용하라
• DB에 너무 의존하지 마라
• 도메인 내부에서만 의미있는 값을 외부에 노출하는
것을 지양하라
• 마이크로 서비스가 별다른 설정 없이 바로
기동가능하게 하라
(예: Java의 경우, Spring Boot + Embedded WAS 활용)

25. 클라이언트-서비스 간 통합
Client A
(Web)
Client B
(App)
MS-A
MS-ALB
MS-A
MS-BLB
MS-A
MS-CLB
MS-A
MS-DLB
Security
Logging
Version
…
Security
Logging
Version
…
Security
Logging
Version
…
Security
Logging
Version
…

26. 클라이언트-서비스 간 통합
API Gateway
Client A
(Web)
Client B
(App)
MS-A
MS-A
MS-A
MS-B
MS-A
MS-C
MS-A
MS-D
Security
Logging
Version
…

27. 클라이언트-서비스 간 통합
API GatewayClient A
(Web)
Client B
(App)
MS-A
MS-A
MS-A
MS-B
MS-A
MS-C
MS-A
MS-D
Security
Logging
Version
…
API Gateway
Security
Logging
Version
…
LB
API Gateway
Security
Logging
Version
…
API Gateway
Security
Logging
Version
…
LB

28. 서비스 간 통신
Service A Service B
HTTP Request/Response
Event
(Message)
Broker
Publish Event
Service C
Service D
Subscribe Event

29. Service Discovery
Client/API
Gateway
MS-A
MS-ALB
MS-A
MS-BLB
Security
Logging
Version
…
Security
Logging
Version
…
Client/API
Gateway
MS-A
MS-A
HA
Proxy
MS-A
MS-B
HA
Proxy
Security
Logging
Version
…
Security
Logging
Version
…
Service
Registry

30. Blue/Green Deployment
http://martinfowler.com/bliki/BlueGreenDeployment.html

31. MSA를 선택한 이유
Frontend/Backend 분리 회사의 Engineer Tech Tree와 동기화
코드 양이 커지고,
중복코드가 발생
코드의 양을 줄여서 누구나 쉽게 파악하도록
팀 전체의 Project Working Group별 Product
시스템 간 연계 증대 API 기반의 Contract 관리를 강제화
새로운 기술에 대한
도입 욕구
Micro-Service 단위로 구현에 자율성 부여
(Polyglot)
재사용성 향상 및
지속적인 발전
Micro-Service 단위의 재사용, 자유로운 리팩토링
회사 인프라의 뒷받침
On-Premise Cloud, CI와 연계된 배포 자동화(Jarvis), 향후
Docker와 같은 Container 기술과 연계

32. 어떻게 개발하나요?
Backend 개발자Frontend 개발자
UserStory 검토
Contract/API 설계
Frontend 개발 Backend 개발
Mock/Unit Test Unit Test
API 연동 Load Test
UserStory 종료

33. Contract/API의 설계/공유

34. Contract/API의 설계/공유
Product
API
API
Product
dev
draft
release
Design APIs
Publish/Change APIs
API Provider
API Consumer
(stakeholder)
API Consumer (public)
Review / Share
draft spec
Explore & Test APIs

35. 진짜 Polyglot을 하나요?
Java 1.6
Tomcat 6
Spring 3.x + XML Conf.
Spring MVC
MyBatis
Maven
기존 시스템들의 Backend
Web Application
Presentation
Controller
Business
Data Access
JSP
Sitemesh
JQuery
기존 시스템들의 Frontend
MySQL

36. 네, 합니다.
Java 1.7 / Tomcat 7
Spring 4.x + Java Conf.
Spring Data JPA
Java 1.8 / Embedded Tomcat
Spring Boot
Spring Data JPA
Node.js
Express
MySQL
Redis
RabbitMQ
Groovy
Go
ASP.NET 5
Vert.x
Others…
PlanetSpace
(File Storage)
Frontend
HTML
CSS
Angular.js
Bootstrap
Less
Grunt
Bower
Karma
향후
실험(?)
후보들 Other…
ZooKeeper

37. 개발 환경의 문제
• 개발하다 보면, 여러 개의
마이크로서비스들을 구동시켜야 하는
경우가 많다.
• 마이크로서비스마다 설정/기동방식이
상이한 경우, 다소 괴롭다.
• 구동된 마이크로 서비스들을 위한 API
Gateway를 빠르게 설정하기
• git clone/pull하는 것도 일이다.

38. Whitebase
Developer’s Machine
Whitebase
jar/js
(file system)
MS-A
Instance
git
jar/js
(file system)
MS-B
Instance
Artifact
repository
jar/js
(file system)
MS-C
Instance
Local docker
MS-D
Instance
Docker
Image
Registry
remote docker
MS-E
Instance
HA Proxy HA Proxy
clone
wget
remote machine
MS-F
Instance

39. Whitebase
• URL-based Router + Proxy
Authentication
Versioning
Logging
Routing
Composition

40. MS-A Container
Whitebase + Service Discovery + Inter-Service Call
Whitebase
UI
UI
MS-A
HA Proxy
HA Proxy
HA Proxy
Service
Registry
Service Agent
MS-A Container
MS-A HA Proxy
Service Agent
MS-B Container
MS-B
Service Agent
MS-B Container
MS-B
Service Agent

41. Monolithic
Web App
(WAS)
Web
변화 요약 - Before
Monolithic
Java Web App
(WAS)
Browser/
Client
“Big”
Database
(MySQL)
L4L4 Web
File
Storage
A B
C D
UI

42. MS-A
MS-B
MS-C
MS-D
Whitebase
A UI
B UI
C UI
D UI
Content
Router
변화 요약 - After
Browser/
Client
L4L4
Content
Router
A UI
B UI
C UI
D UI
API
Gateway
(Whitebase)
MS-A
(Java)
DB
(MySQL)
MS-B
(Nodejs)
MS-C
(Nodejs)
MS-D
(Java)
DB
(MySQL)
Redis
(MySQL)
File
Storage
DB
(MySQL)
Service
Registry
Event Broker
Config
Service

43. 변화 요약
Before Now or soon Future
Architecture Monolithic
DB 공유형 통합
Micro-Services, VM 기반
Loosely-Coupled (API/Event)
Container 기반 가상화
Self-Healing
Application 1 Web App 9 UIs
14 Services
더욱 세분화
Data 1 MySQL 10 MySQL
2 Redis
1 ZooKeeper
Maria DB
PostgreSQL
또다른 NoSQL
Tech Stack Java 1.6/Tomcat 6
Spring 3.x
MyBatis
MySQL
Java 1.7/1.8, Embedded Tomcat
Spring 4.x/Spring Boot
Spring Data JPA
MySQL
Node.js
Redis
RabbitMQ
다른 Java Framework
다른 언어/플랫폼
기타 OnDemand
SVN/Git
CI (Jenkins)
수동 배포
Scrum/Sprint 기반
Git with Feature Branch Model
CI (Jenkins)
Jarvis를 사용한 자동 배포
Docker 인프라 연계
Blue/Green Deployment
Continuous Deployment
A/B Testing

44. MSA로 진행하며 얻은 것
• 팀원들이 다루는 기술 범위가 크게 확장
• 최신 기술의 도입/실험에 부담이 없음
• 팀원 간의 경험 공유 활성화
• API 디자인 능력 향상
• 향후 변화/확장에 대해서도 아키텍처적 변화
없이 대응이 가능
• 높은 재활용성/조합 지원
• 향후 사내/대외 오픈소스화가 가능할 듯한
솔루션들

45. MSA로 진행 시의 단점
• 초기 개발 시에는 개발 시간이 많이 소요됨
• MSA로 원활하게 개발하기 위한 기반
구성요소와 인프라 준비가 필요함
• 기존 개발 방식이 편하다고 주장하는
사람들로부터의 저항
• 서비스 간 연계 시 협의가 필요
• 여러 서비스에 걸치는 기능의 경우, 주체가
애매한 경우가 생김

46. 제언
• 갑자기 한번에 MSA로 넘어가는 것은 쉽지
않은 작업입니다.
• 기존 시스템에서 분할이 가능한 항목을 하나씩
분할해가거나, 신규 개발되는 기능을 하나씩
마이크로 서비스로 분리하여 추가해가는 것이
좋습니다.
• MSA는 만능이 아니며, 조직 문화(점진적 발전,
구성원들의 Skill-up에 대한 관심과 투자)가
뒷받침해줘야 합니다. 조직 문화가 선행되지
않으면 차라리 시도하지 않는 것이 좋습니다.

47. 질문/피드백
var you = {};
if (you.like||you.dislike||you.suggest||you.request)
{
var id = "jaewoo.ahn";
var domain = "sk.com";
mail.send(String.format("{0}@{1}", id, domain ));
}