Cloud Studying
Micro Service Architecture
김도형 류영수 유효균 이영수 장경주
발표 이영수
SWMaestro 7기 미래기술스터딩

Micro Service Architecture

MSA란
• 서비스를 기능별로 작게 쪼개는 서버 아키텍쳐의 디자인 패턴
• 하나의 서비스는 한가지 일에 초점을 맞춤
• API로 다른 서비스와 연계

장단점
• 빠른 복구
• Scaling
• 서비스 확장 용이
• 대규모 장애 확률 감소
• 협업 용이
• 복잡함
• 트렌젝션 관리 어려움
• 다중 테스트
• 소규모 장애 확률 증가

MSA의 구현 방법을 알아보자
목표

1. 기능별로 서비스 어플리케이션 구분
2. 서비스 이미지 개발
3. 클라이언트에서 필요한 서비스 선택
4. 인스턴스 선택 / 관리
구현 과정

1. 기능별로 서비스 어플리케이션 구분
2. 서비스 이미지 개발
3. 클라이언트에서 필요한 서비스 선택
4. 인스턴스 선택 / 관리
구현 과정

1. 기능별로 서비스 어플리케이션 구분
2. 서비스 이미지 개발
3. 클라이언트에서 필요한 서비스 선택
4. 인스턴스 선택 / 관리
구현 과정

• 서비스 애플리케이션은 수십, 수백여개의 서비스들로 구성
• 각 서비스는 적절한 CPU, memory, I/O 리소스를 제공받아야
하고 배포는 빠르고 효율적이어야 함
배포 방법
1. 서버마다 전체 서비스를 띄움
2. 서비스를 VM위에 띄움
3. 서비스를 Container위에 띄움
서비스 이미지 개발

Deploy service per Server
장점
• 배포속도, 서비스 시작속도 빠름
단점
• CPU, 메모리를 한 서비스 인스턴스가 모두 사용하는 문제
User
Service
Trip
Service
Payment
Service
Server 1
192.168.0.1
User
Service
Trip
Service
Payment
Service
Server 2
192.168.0.2

Deploy service in VM
장점
• 서비스별로 고정된 자원을 사용
• 클라우드 인프라 기능 활용 가능
단점
• 자원 사용 비 효율적 (VM자체의 자원 낭비)
• VM 관리의 어려움
Service 1
VM
Service 1
VM
Service 1
VM
Service 1
VM image

Deploy service in Container
Docker 등의 Container 기술을 활용하여 서비스를 개발
Service 1
Container
Service 1
image
장점
• VM의 장점을 거의 포함
• VM보다 가벼움
단점
• 인프라는 VM보다 비 성숙함
Service 1
Container
Service 1
Container

1. 기능별로 서비스 어플리케이션 구분
2. 서비스 이미지 개발
3. 클라이언트에서 필요한 서비스 선택
4. 인스턴스 선택 / 관리
구현 과정

클라이언트에서 각 서비스에 요청을 따로 보내야 하는가?
많은 요청은 비 효율적이며 클라이언트 코드가 복잡해짐

API Gateway
Inter-process
Communication

API Gateway
• 내부 시스템 아키텍쳐를 캡슐화해서
클라이언트에 적합한 API를 제공
• 비동기, 논블로킹 I/O를 지원하는 플랫폼으로 개발
• Netty, Vertx, Node.js, Nginx, etc..
• 통신 규격 다양화 (내/외부용 효율적인 방법 선택)
• Auto-scaling, ip-address 변경에 대응
• 서비스 오류 핸들링 ex) Netflix Hystrix

Inter-process Communication
• 서비스-클라이언트, 서비스-서비스간 통신 구현
• 비동기적(message-based) / 동기적(request) 구현방법 선택
• HTTP REST / Thrift 프로토콜
• 서비스 오류 핸들링

1. 기능별로 서비스 어플리케이션 구분
2. 서비스 이미지 개발
3. 클라이언트에서 필요한 서비스 선택
4. 인스턴스 선택 / 관리
구현 과정

인스턴스들은 Auto-Scaling, 장애 등으로 인해 IP주소 등이 변화
Service Discovery
하나의 서비스는 가상화되어 여러 인스턴스로 실행됨
어떤 인스턴스에 접속해야 하는가?

Discovery Pattern
Service 1
Instance A
Service 1
Instance B
Service 1
Instance C
10.4.3.1:6001
10.4.3.7:6002
10.4.3.9:6003
Service Registry
각 서비스는 Service Registry에 자신의 상태를 전달
Service Registry는 가용한 인스턴스의 목록을 갖고있음

Discovery Pattern
Client-side
Discovery Pattern
Server-side
Discovery Pattern

Client-side Discovery Pattern
Client
1
2

Client-side Discovery Pattern
• 클라이언트에서 Service Registry를 통해
가용한 인스턴스 목록을 받아옴
• 클라이언트에서 가용한 인스턴스에 직접 연결
장점
• 지능적인 클라이언트 개발 가능
단점
• 클라이언트 코드 복잡, 로직 복잡

Server-side Discovery Pattern
Client

Server-side Discovery Pattern
• Load Balancer가 존재
• 클라이언트에서 요청을 보내면 Load Balancer가 Service Registry
와 연동하여 요청을 적절한 서비스 인스턴스로 전달
장점
• Discovery의 세부적인 부분이 클라이언트로부터 분리됨
단점
• 서버측 시스템(Load Balancer)이 안정적이어야 함
ex) AWS Elastic Load Balancer

추가: Third-party Registration Pattern
Instance A
Instance B
Instance C
Service
Registry
Service
Registry
Instance A Registrar
Health check

1. 기능별로 서비스 어플리케이션 구분
2. 서비스 이미지 개발
3. 클라이언트에서 필요한 서비스 선택
4. 인스턴스 선택 / 관리
구현 과정

• Nginx consul, Netflix Eureka 등의 오픈소스 활용
• AWS Lambda API등 이용
활용할 수 있는 것

• https://www.nginx.com/blog/introduction-to-microservices
• http://readme.skplanet.com/?p=10700
• http://www.slideshare.net/andrewdohyunjung/msa-43702981
참고 자료