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

Presentation on theme: "마이크로 서비스 아키텍처로 개발하기 안재우 Platform Architecture 팀 SK Planet."— Presentation transcript:

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

2 About me SK 플래닛 Platform Architecture 팀 전 NCSOFT 인프라플랫폼팀 전 닷넷엑스퍼트 수석컨설턴트

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

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

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

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

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

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

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

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

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

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

13 Scale Cube http://theartofscalability.com

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

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

16 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

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

18 장점 Technology Heterogeneity Resilience Scaling Ease of Deployment Organizational Alignment Composability Replaceability

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

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

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

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

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

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

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

26 클라이언트 - 서비스 간 통합 API Gateway Client A (Web) Client B (App) 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

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

28 Service Discovery Client/API Gateway MS-A LB MS-A MS-B LB Security Logging Version … … Security Logging Version … … Client/API Gateway MS-A HA Proxy MS-A MS-B HA Proxy Security Logging Version … … Security Logging Version … … Service Registry

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

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

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

32 Contract/API 의 설계 / 공유

33 API Workspace Product 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

34 진짜 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

35 네, 합니다. 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

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

37 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 clone wget remote machine MS-F Instance

38 Whitebase URL-based Router + Proxy Authentication Versioning Logging Routing Composition

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

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

41 MS-A MS-B MS-C MS-D Whitebase A UI B UI C UI D UI Content Router Content Router 변화 요약 - After Browser/ Client L4 Content Router Content Router A UI B UI C UI D UI API Gateway (Whitebase) 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 Service Registry Event Broker Config Service Config Service

42 변화 요약 BeforeNow or soonFuture ArchitectureMonolithic DB 공유형 통합 Micro-Services, VM 기반 Loosely-Coupled (API/Event) Container 기반 가상화 Self-Healing Application1 Web App9 UIs 14 Services 더욱 세분화 Data1 MySQL10 MySQL 2 Redis 1 ZooKeeper Maria DB PostgreSQL 또다른 NoSQL Tech StackJava 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

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

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

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

46 질문 / 피드백 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 )); }