source : http://www.opennaru.com/cloud/msa/ 마이크로서비스는 애플리케이션 구축을 위한 아키텍처 기반의 접근 방식입니다. 마이크로서비스를 전통적인 모놀리식(monolithic) 접근 방식과 구별 짓는 기준은 애플리케이션을 핵심 기능으로 세분화하는 방식입니다. 각 기능을 서비스라고 부르며, 독립적으로 구축하고 배포할 수 있습니다. 이는 개별 서비스가 다른 서비스에 부정적 영향을 주지 않으면서 작동(또는 장애가 발생)할 수 있음을 의미합니다.

1. Microservices Architecture

3. MSA 란?

4. Microservices Architecture - 특징

6. • 모노리스 아키텍처의 특징
• 견고함
• 표준화
• 단일 기술
Monolith Architecture

7. 모노리스 아키텍처의 장단점

8. Monolith vs. Microservices
Build Test Release
Build Test Release
Build Test Release
Build Test Release
Build Test Release
Build Test Release
Build Test Release
Monolithdevelopmentlifecycle Microservicedevelopmentlifecycle
developers app Deliverypipeline developers services Deliverypipeline
하나의 기능을 구현 하는데, 여러 개의 서비스를 조합하여 기능을 제공
예) 주문 하기 : 사용자 정보 조회, 상품 정보 조회, 신규 주문 생성

9. DevOps

10. 마이크로서비스 아키텍처 등장의 배경

12. Monolith Architecture Team

13. • 팀을 작게 나누고 병행 개발
Microservices Architecture Team

14. Quicker development

15. 3티어 아키텍처 – 2000년대

16. 4티어 아키텍처 – 2010년 이후

17. Microservices Anti-patterns

19. 마이크로서비스 장점

20. Microservices 9 가지 특징 (1/2)

21. Microservices 9 가지 특징 (2/2)

22. Microservices 특징

24. 마이크로서비스 아키텍처와 거버넌스

26. There’s no silver bullet.

27. • 변화의 경계선을 찾는다
• 모듈화는 변화의 경계선에 의해 일어난다
• 변화의 요인 (외부 / 내적)는 품질 특성에서 이해하기
• 기능뿐만 아니라 비 기능도 중시해야 한다
• 변화의 경계에 선을 긋는다
• 변화의 경계는 불분명하지만 선을 그릴 수 밖에 없다
• 도메인 경계를 유지한다
• 패키지 문제 또는 재 구축 문제
도메인 = 변화의 경계선

28. The 12 Factor App

29. The 12 Factor App (1/2)

30. The 12 Factor App (2/2)

31. 모노리스 아키텍처의 특징
¨ 견고함
¨ 표준화
¨ 단일 기술
Monolith Architecture

32. Monolith -> Microservices – Phase 1
호출 빈도가 높으며,
독립적으로 동작하는
모듈을 API 서비스로
독립

33. 모노리스에서 마이크로서비스로 전환 – Phase 2
동일한 조건으로
서비스 분할

34. 모노리스에서 마이크로서비스로 전환 – Phase 3
동일한 조건으로
서비스 분할

35. 모노리스에서 마이크로서비스로 전환 – Phase 4
비즈니스 관점에서
도메인을 정의하고
서비스를 분할하며,
독립적인 서비스로
구축

36. • 개선을 반복하여 최적의 마이크로 서비스를 제공
모노리스에서 마이크로서비스로 전환 – Phase 5

38. Coupang의 MSA 전환사례
https://medium.com/coupang-tech/%ED%96%89%EB%B3%B5%EC%9D%84-%EC%B0%BE%EA%B8%B0-%EC%9C%84%ED%95%9C-%EC%9A%B0%EB%A6%AC%EC%9D%98-
%EC%97%AC%EC%A0%95-94678fe9eb61
문제점
• 부분 장애가 전체 서비스 장애로 이어지는
경우가 있음
• 서비스를 부분적 Scale-out하기 어려움
• 서비스 변경이 어렵고, 수정시 영향도를
파악하기 어려움
• 작은 변경에도 많은 테스트가 필요함
• 조직이 성장할 수록 배포 대기시간이 비약적으로
증가함
기술 블로그에서 발췌/정리

39. Coupang의 MSA 전환사례
https://medium.com/coupang-tech/%ED%96%89%EB%B3%B5%EC%9D%84-%EC%B0%BE%EA%B8%B0-%EC%9C%84%ED%95%9C-%EC%9A%B0%EB%A6%AC%EC%9D%98-
%EC%97%AC%EC%A0%95-94678fe9eb61
장점
• 부분 장애가 전체 서비스 장애가 되지 않음
• 서비스를 부분적 Scale-out하기 쉬움
• 신기술 적용이 쉬움(각 팀별로 별도 진행)
• 각 팀별로 변경사항을 빠르게 적용할 수 있음
단점
• 테스트가 어렵다(다른 팀 API 테스트 필요)
• 장애 추적이 어렵다(비동기 처리시 더 어려움)
• 트랜잭션 관리가 어렵다.
• 담당자를 찾기 어렵다
기술 블로그에서 발췌/정리

40. 11번가의 MSA 전환사례
https://www.slideshare.net/balladofgale/spring-camp-2018-11-spring-cloud-msa-1
발표자료에서 발췌/정리
문제점
• 나의 과감한 수정은 전사 장애다 !
• 배포의 어려움
매주 목요일 밤샘 정기 배포/잦은 장애
• 새로운 기술 접할 기회 원천 봉쇄
Java 1.6, Spring Framework 2.x
• 느린 개발 환경
IDE를 띄우기도 어려움, 200만 라인의
공통코드
• 폭증하는 트래픽을 수년내 감당하기
어려움

41. 11번가의 MSA 전환사례
https://www.slideshare.net/balladofgale/spring-camp-2018-11-spring-cloud-msa-1
발표자료에서 발췌/정리

42. OOO사 OpenShift 환경의 MSA 애플리케이션 전환 사례
Red Hat Linux 6 Red Hat Linux 7.7
OpenShift 3.11
JDK 1.4 JDK 1.8
Legacy Framework Spring Boot/Cloud
JEUS 7 Tomcat 9
AS-IS TO-BE
주요 개선점
• 부하에 따라 서비스를 부분적으로 자동 Scale-
out할 수 있음(Auto Scaling)
• 컨테이너 환경으로 DevOps(CI/CD) 서비스 무중단
배포 환경 구성  업무별 빠른 자동 배포 환경
• Spring Boot / Spring Cloud(Netflix OSS) 등 최신
Framework 도입하여 MSA 환경 구축
• 운영환경과 동일한 개발/테스트 환경 구성
OpenShift 프로젝트로 구분하여 특정 노드에 구성
• APM 도입으로 API간의 연계 추적이 가능

43. OOO사 OpenShift 환경의 MSA 애플리케이션 전환 사례
frontend
Oracle
Database
Redis
Cluster
Openshift
Container Platform
프로젝트:
Infra-prod
(infra-dev, infra-test)
Rabbit
MQ
(config)
aggregator
front
-admin
gateway
(제휴사 API 호출)
business service (오토스케일링)
config
-server
#1 ~ #6
auth
backend
bill
member
manager
mobile
report
support
워커 노드
#1
워커 노드
#2
워커 노드
#3
워커 노드
#4
워커 노드
#5
마스터 노드
#1
마스터 노드
#2
마스터 노드
#3
Bastion
#1
aaa.war
컨테이너
(PROD)
bbb.war
컨테이너
(PROD)
ccc.war
컨테이너
(PROD)
ddd.war
컨테이너
(PROD)
eee.war
컨테이너
(TEST)
Persistent
Volumes
(NFS)
물리 구성
Spring CloudSpring Cloud
Spring Cloud

44. 건국대학교병원 – MSA 전환사례

45. 건국대학교병원 – MSA 전환사례

46. 건국대학교병원 – MSA 전환사례

47. 건국대학교병원 – MSA 전환사례
SPARC/PA-RISC/Power X86
물리서버 RHEV 4.0
HP-UX(11.23) Red Hat Linux(7.3)
JDK 1.4 JDK 1.8
JEUS 4.2 JBoss EAP 7
적
용
방
안
기
대
효
과
 인프라 (서버/OS/미들웨어) 를 단일 벤
더 지원
 각 부분별로 개방형 표준 환경으로 전환
 오픈 소스 프레임워크를 통한 개발
 라이선스 비용 없기 때문에 초기 도입
비용 절감
 특정 서버 벤더와 기술에 얽매이지 않는
환경
 Cost Performance 가 좋은 인프라를 선
택
 서비스 품질이 높은 개발/운영 업체 선
택
 운영 효율성 향상
 저비용 고효율 시스템 구축
J2EE 1.3 Java EE 1.8
AS-IS TO-BE

48. 건국대학교병원 – MSA 전환사례

49. 건국대학교병원 – MSA 전환사례

50. 건국대학교병원 - 전환사례

51. 건국대학교병원 - 전환사례

52. 건국대학교병원 - 전환사례

53. The Future of the Application Stack
- Kubernetes

55. 제품 / 서비스에 관한 문의
• 콜 센터 ：02-469-5426 ( 휴대폰 : 010-2243-3394 )
• 전자 메일：sales@opennaru.com