마이크로서비스 아키텍처의 이해 - 부산대 소프트웨어 공학 연구실 강의 자료

부산대 소프트웨어공학 연구실
김대호
마이크로서비스 아키텍처 이해

오늘 얘기할 주제는
● 마이크로서비스란
◆ 마이크로서비스 배경
◆ 마이크로서비스 정의
● 기존 서비스 비교 및 특징
◆ vs 모놀리식
◆ vs SOA(Service Oriented Architecture)
● 마이크로서비스로의 전환 사례
◆ 넷플릭스
◆ SK 플래닛
◆ Samsung Connect
◆ Vingle
!2

소개
● 김대호
◆ 부산대학교 소프트웨어 공학 연구실 (2017~)
◆ 경남 한국전력공사 “전기 위험 신고” 앱 개발 및 유지보수 (2016)
◆ 창원대 지역과학기술진흥센터 강사 - Unity3D, C# (2016)
◆ 창원시 스마트 모바일 앱 지원센터 보조강사 – IOS, Android (2015~2016)
!3

극한직업 (영화)
!4
● 줄거리
◆ 마약 밀거래 현장 수사 하기 위해(?) 근처의
치킨집을 인수하여 잠복 수사하는 내용
◆ 의도치않게 잘되는 장사.. 체인점까지 확장함

● 작은 가게에서 시작
◆ 재료 구매, 손질까지 배달까지 병행
◆ 새 메뉴 개발 및 적극적인 피드백
◆ 순조로운 출발
치킨집 창업
!5
● 후라이드 치킨
● 양념 치킨
● 간장 치킨
● 왕갈비통닭(신메뉴)
● …
치킨집
고객
● 재료 구매
● 재료 손질 및 튀기기
● 치킨 배달
● 메뉴 개발 및 피드백
주문 및 배송
(평균 일 5~7건)
피드백
OO치킨

● 금새 대박 난 가게
◆ 피드백 반영 및 신메뉴 대박.. 주문수 급증
◆ 늘어난 고객층 그리고 늘어나는 컴플레인
치킨집 창업
!6
고객
● 재료 구매
● 치킨 배달
● 메뉴 개발 및 피드백 피드백 급증
● 양념 치킨
● 간장 치킨
● …
주문 및 배송
(평균 일 200건 이상)
OO치킨
치킨집

● 늘어나는 사장님의 고민
◆ 크게 맛과 배송 관련이 다수
◆ 혼자서 부여된 너무 많은 업무
◆ 피드백 반영 느려짐.. 배달 느림.. 악순환
◆ 해결하기 위한 변화가 필요
치킨집 창업
!7
● 양념 치킨
● 간장 치킨
● …
치킨집
고객
주문 및 배송
(평균 일 200건)
배송이 너무
느리다
맛이 예전 맛이
아니다.
양이 너무 작다
달다, 짜다
● 재료 구매
● 치킨 배달
oo치킨

● 해결책 : 서비스의 분업화!
◆ 본점에서 재료를 구입
◆ 분점 or 사람은 손질 및 튀기기
◆ 배달기사를 통해 고객에게 배송
치킨집 창업
!8
고객
배송
치킨집 분점 or 사람
치킨집 본점 배달 기사
레시피 제공
● 재료 구매
● 손질 및 튀기기
OO치킨 OO점
OO치킨
피드백
● 치킨 배달

마이크로서비스란
!9
● 마이크로서비스 등장 배경
◆ (전통적인) 시스템 개발 방식
◆ 클라이언트-서버-DB 3-계층 또는 단일 구조 형태
◆ 단일 언어와 및 프레임워크 사용
◆ 하나의 서버를 두고 기능을 한 곳에 개발하여 한번
에 배포
◆ 모든 서비스들이 단단하게 짜여진 구조를 모놀리식
아키텍처 라고 불림
모놀리식 구조

● 모놀리식 아키텍처의 장단점
!10
사소한 변경에도
전체 배포가 필요함
로컬 환경에서의
서비스 별 테스트 관리가 편함
중앙 집중 개발 및 통제
새로운 언어 및 프레임워크를
적용하기 힘듬
갈수록 복잡해지는 코드 구조
초기 개발이 쉬움

!11
● 점점 커지는 문제들
◆ 코드 규모가 커지면서 발생하는 복잡성 증가
◆ 중앙 집중 관리에 대한 한계
◆ 작은 서비스 변경에 따른 전체 배포 및 다른 서비스에 영향
◆ 새로운 서비스, 기능 추가에 대한 두려움
규모가 커지면서 발생하는 문제(복잡성, 배포 및 관리)를 해결할 수 있는
솔루션 필요
서비스 단위로 분리 한다면?

!12
● 마이크로서비스로의 전환!
◆ 서비스 단위로 고려함
◆ (DB 계층까지) 서비스 단위로 분리한 뒤 독립적인 구성
◆ 서비스간 통신을 지원하기 위한 API Gateway, 프로토콜 정의
◆ 대규모 분산 관리 서비스 구성
모놀리식 구조 마이크로서비스 구조

!13
● 마이크로서비스의 정의
◆ “service-oriented architecture composed of loosely coupled
elements that have bounded contexts”
◆ 애플리케이션 서비스 단위로 구성되며
◆ 느슨한 결합으로 통신하고 (API)
◆ 다른 서비스에 영향을 주지않고 독립적으로 업데이트 가능한 구조
Adrian Cockcroft (VP of Cloud Architecture @
AWS, former Cloud Architect at Netflix), 2014

!14
● 마이크로서비스의 크기?
◆ Two Pizza Team(최대 10명)을 넘지 않도록 서비스 규모를 산정
◆ 배포(Develop)와 운영(Operation) 등 모두 책임지며 자율적인 팀 문화
(=DevOps Team!)
Two Pizza Team

!15
● 사실 마이크로서비스는 최신 용어가 아니다
◆ 2014년 소프트웨어 아키텍트인 Martinfowler가 자신의 블로그에서 정리
한 글이 마이크로서비스에 대한 시초
◆ 기존 모놀리식 구조의 한계를 극복하기 위한 서비스 단위의 분산 시스템
설계 개념
Martinfowler: Microservice, https://
martinfowler.com/articles/microservices.html

!16
● 왜 마이크로서비스로 가는가?
◆ 클라우드 서비스의 보급 확산 및 컨테이너 엔진의 발달
◆ 물리머신의 서비스 별 스케일링의 한계 (ex 매학기 수강신청)
◆ 클라우드 서비스를 이용하여 물리머신 서버의 한계를 극복함
◆ 클라우드 환경에서 효율적으로 관리하기 위한 아키텍처가 필요
(=마이크로서비스)

!17
● 배포 기술(컨테이너 엔진)의 발전
◆ 가상 머신(VM, Virtual Machine)은 하드웨어 계층에서 가상화를 진행
하여 리소스를 관리함
◆ VM은 이미지가 무겁고 서비스 애플리케이션의 변경 및 배포하는데 걸리
는 소요시간이 오래걸림
◆ 반면에 컨테이너 엔진은 호스트 OS의 커널위에서 가상화를 진행하여
VM 보다 오버헤드가 적고 빠르게 실행되며 무엇보다 가벼움

!18
● Cloud + Container + DevOps
◆ 마이크로서비스의 개념과 DevOps, Container 기술을 접목하여 빠르고
민첩한 애플리케이션 개발 및 배포 가능
◆ 이러한 기반을 발전하여 Cloud 서비스로 제공하는 것이 “Serverless
Computing”
How Cloud Native Apps Unlock Rapid Software Delivery On
Your Private Cloud, https://www.datrium.com/blog/cloud-native-
apps-unlock-rapid-software-delivery-private-cloud/

!19
● 서버리스 컴퓨팅 (Serverless, Function as a Service)
◆ 클라우드 서비스는 이미 마이크로서비스보다 더 세분화된 함수(Function)
단위의 마이크로서비스인 서버리스 컴퓨팅 서비스를 제공하고 있음
◆ 클라우드 환경에서 함수단위의 코드를 올리면 내부 물리 장치에 대한 스케
일을 고려할 필요없이 애플리케이션이 동작함

기존 서비스와 비교 및 특징
!20
● vs 모놀리식 아키텍처
Pivotal, Microservice: Deliver Scalable Software
Faster, https://pivotal.io/kr/microservices
모놀리식 아키텍처 마이크로서비스 아키텍처
광범위한 범위 : 하나로 패키징된 서비스들을 전체
적으로 보고 해결함
서비스 단위 집중 : 하나의 서비스 단위로 집중하여
개발 이는 특정 도메인을 타겟을 지정하여 독립적인
구성 가능
단단한 결합 : 절차적인 함수를 호출하여 복잡하게
짜여져 있으며 의존성이 강함
느슨한 결합 : 서비스 간의 API 통신 서로 영향을 주
어서는 안됨
정해진 일정에 따른 전달 : 주기적인 일정에 따라서
애플리케이션을 개발하고 배포를 진행함 이는 분기
또는 년 단위가 될 수 있음
지속적 전달 : 변화에 빠르게 대응하며 지속적이고
빠른 배포를 지원함
개발 및 운영 팀 분리 : 모든 서비스를 개발하는 개
발팀과 개발된 서비스를 배포하는 운영팀으로 분류
됨
서비스 별 독립적인 팀(DevOps) : 서비스 팀별로
모든 책임을 가지는 팀을 구성하여 개발 및 업데이
트를 수행함
프로세스 중심 및 중앙 집중형 지향 분산형 시스템 지향

!21
● vs SOA (Service Oriented Architecture)
◆ 마이크로서비스 이전에 등장한 근본이 되는 개념
◆ ESB(Enterprise Service Bus)를 통해 프로토콜(SOAP, XML)을 이용한
서비스 간 통신
◆ ESB에 너무 치중된 역할.. 배보다 배꼽이 크다
◆ 다소 무거운 프로토콜(Stateful) 서비스간 높은 의존성 발생 → 실패
IBM, SOA and web service, https://www.ibm.com/
developerworks/library/ws-esbtesting/index.html

!22
● vs SOA (Service Oriented Architecture)
◆ “서비스 단위 중심” 관점에서 SOA와 차이점이 없다
◆ 마이크로서비스는 SOA의 일부
◆ ESB 기능을 최대한 가볍게 구현하여 API처리에만 집중하는 API Gateway
사용
◆ XML, SOAP 프로토콜을 Stateless한 REST API 형태로 변경
◆ 따라서 마이크로서비스를 구성하기 위한 중요한 요소로는 “잘 정의된 API”
가 필요함
The Venn of Microservices,
https://blog.akana.com/the-venn-of-microservices/

!23
● 마이크로서비스 : API Gateway
◆ 마이크로서비스와 함께 많이 쓰이는 용어
◆ 주 역할은 구성된 마이크로서비스의 API 연결 EndPoint 통합하고 조율
◆ 서비스간 다른 프로토콜을 변환해주며 SOA의 ESB와 마찬가지로
Orchestration(API 통합 관리) 기능을 지원함
◆ 추가로 공통 로직 처리(보안, 로깅), Service Discovery, Circuit breaker
Circuit Breakers and Microservices Architecture, https://
techblog.constantcontact.com/software-development/circuit-
breakers-and-microservices/
Pattern: API Gateway / Backend for Front-End,
https://microservices.io/patterns/apigateway.html
API Gateway Pattern Circuit Breaker

!24
● 그러나 마이크로서비스가 만능은 아니다
◆ 모놀리식 시스템에서 발생하는 문제를 해결할 수 있지만 그만큼 고려해야할
사항들이 있다
◆ 대표적인 경우가 데이터 무결성, 일관성인 트랙잭션 처리 이슈
◆ 서비스 단위로(데이터 까지) 독립적으로 구성된 마이크로서비스들 간 중복
연결된 데이터가 존재할 수밖에없다
◆ 해당 데이터 스키마에 대한 변경이 있는 경우 모든 서비스에서 변경 내용이
반영되어야 한다
Microsoft, Designing microservices: Data considerations
, https://docs.microsoft.com/ko-kr/azure/architecture/
microservices/data-considerations

마이크로서비스에서 데이터 고려 사항
!25
● 해결 방법
◆ 애플리케이션 설계 단계에서 서비스 별 묶는 트랜잭션 시나리오 자체를 없다
는 가정으로 마이크로서비스를 구성한다
● 사실, 마이크로서비스는 엔터프라이즈 시스템 보다는 대규모 처리의 B2C
형 서비스에 적합하기 때문
● 아키텍처 스타일이 트랜잭션을 중요시 하는 시나리오에는 적합하지 않다
◆ 복합 서비스(Composite service)를 만들어서 하나의 API 형태로 제공
● 두개의 서비스를 네이티브 프로토콜을 이용해서 구현한뒤 이를 API 형태
로 노출함
● 기존 SOA에서 많이 사용하던 방식이나 이 방법의 경우 마이크로서비스
가 tightly copuled하게 구성되며 마이크로서비스 독립성에 위반, 즉 권
장하지 않음
◆

마이크로서비스에서 데이터 고려 사항
!26
● 해결 방법
◆ 트렌잭션 실패시 보상 트랜잭션(Compensating transaction)을 애플리케
이션으로 처리함
● 예를 들어 은행 이체 시나리오에서 돈을 다른 계좌로 송금하다 에러가 난 경우
보상 트랜잭션을 이용해 원래 계좌로 다시 입금하는 일종의 에러 처리 로직을
구현함
Compensating transaction

마이크로서비스에서 추가로 고려 사항
!27
● 성능
◆ 기존 모놀리식 서비스 간 호출은 function call 방식(call-by-reference)
를 이용함
◆ 마이크로서비스 간 호출은 비교적 가벼운 형태의 REST API를 이용함 이
는 네트워크 오버헤드가 발생할 수 있음
● 테스팅 및 운영
◆ 개별적인 서비스들이 분리되어 있으며 이들은 독립적으로 다른 개발 형태
(언어, 프레임워크)로 되어있음
◆ 여러 서비스에 걸처 테스트 및 운영해야할 대상 기술의 수가 늘어남

마이크로서비스로의 전환 사례
!28
● 클라우드 기반 마이크로서비스 아키텍처 패턴
◆ 인스턴스 기반 (EC2 Instances) : Netflix, SK Planet
◆ 컨테이너 기반 (ECS) : Samsung Connect
◆ 서버리스 기반 (Lambda) : Vingle
윤석착, 마이크로서비스 기반 클라우드 아키텍처 구성
모범 사례, https://www.slideshare.net/awskorea/
microservices-architecuture-on-aws

!29
● Netflix 마이크로서비스 전환 사례
윤석착, 마이크로서비스 기반 클라우드 아키텍처 구성
모범 사례, https://www.slideshare.net/awskorea/
microservices-architecuture-on-aws

!30
● Netflix 마이크로서비스 전환 사례
Josh Evans, Mastering Chaos A Netflix Guide to
Microservices, QCon SF 2016

Netflix 마이크로서비스로의 전환 사례
!31
● 오픈소스활동을 통한 서비스간 인터페이스 이슈 해결 (Netflix OSS)
◆ 휴트릭스(Hystrix)
● Circuit Breaker : 외부 마이크로서비스가 일시적인
오류가 날 경우 조기에 해당 서비스를 차단(Fail
Fast)하여 오류 확대를 방지 및 자기 서비스를 보호
● Fallback : Circuit이 오픈된 경우 또는 Exception
이 발생하였을 때 실행 캐시로 응답을 미리 만들어서
제공함
◆ 리본(Ribbon)
● Client Side Load Balencer : 여러 서버 인스턴스
와 연결된 API Gateway의 부하를 분산을 지원
◆ 유레카(Eureka)
● Dynamic Service Discovery : 서비스 인스턴스를
추가할 시 동적으로 Ribbon+Hystrix에 반영

!32
● 11번가 (SK Planet) 마이크로서비스 전환 사례
◆ Strangler Application Parttern
Spring Cloud 기반 Micro Services로의 전환 개발 사례
https://readme.skplanet.com/?p=13782

!33
● 11번가 (SK Planet) 마이크로서비스 전환 사례
◆ 가장 작고 독립적인 서비스로 부터 마이그레이션 진행
◆ 모놀리식 서비스와 신규 서비스 사이 원활한 API 처리를 위해 Zuul과 같은
API Gateway 모듈이 필요
◆ 각 서비스별로 폴백 테스트 및 인프라 자동화 관리 필수
Spring Cloud 기반 Micro Services로의 전환 개발 사례
https://readme.skplanet.com/?p=13782

!34
● 마이크로서비스 전환 아키텍처 : 컨테이너 기반

!35
● Samsung Connect 컨테이너 기반 마이크로서비스 사례
장수백(삼성전자), Samsung Connect 마이크로서비스
도입 사례, AWS Summit 2016

!36
● Samsung Connect 마이크로서비스 아키텍처

!37
● Samsung Connect 컨테이너 기반 관리

!38
● 마이크로서비스 전환 아키텍처 : 서버리스 기반

!39
● Vingle 서버리스 마이크로서비스 구현 사례
이상현(빙글), Vingle의 AWS 기반 서버리스 마이크로서
비스 구현 사례

!40
● Vingle 기존 서비스 및 인프라 구조

!41
● Vingle 서버리스 마이크로서비스 테스트 - 스팸 필터

!42
● Vingle 서버리스 마이크로서비스에서 배운 경험
◆ 새롭게 추가할 내용/변경이 필요한 기능 부터 분리
● 잘 돌아가고 있는 기능을 마이크로서비스로 변경시 문제가 발생할
확률이 큼
● 리스크가 작은 것부터 천천히 진행
◆ Business Domain 단위 서비스 구성
● Feed, Notification
◆ 서비스 문서화, 특히 REST API 경우 적극적인 문서화 필요

정리
!43
● 마이크로서비스 전환시 우선순위
◆ 우선 우리가 동작하는 서비스가 정말 마이크로서비스가 필요한지
확인해야함
◆ 사례에서 설명한것 처럼 전환시 리스크가 적은 서비스 부터 하나씩
마이그레이션 진행
◆ 새로운 서비스 또는 변경이 자주 발생하는 서비스 부터
◆ 기존 잘 유지되는 서비스는 맨 나중에
● 마이크로서비스 전환하기 위한 사전작업
◆ 데이터 관리 (무결성, 일관성) 고려
◆ 조직문화 개선

마이크로서비스 아키텍처의 이해 - 부산대 소프트웨어 공학 연구실 강의 자료

More Related Content

Similar to 마이크로서비스 아키텍처의 이해 - 부산대 소프트웨어 공학 연구실 강의 자료

마이크로서비스 아키텍처의 이해 - 부산대 소프트웨어 공학 연구실 강의 자료