View
140
Download
1
Category
Preview:
Citation preview
Cloud StudyingMicro 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, 메모리를 한 서비스 인스턴스가 모두 사용하는 문제
UserService
TripService
PaymentService
Server 1192.168.0.1
UserService
TripService
PaymentService
Server 2192.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 ContainerDocker 등의 Container 기술을 활용하여 서비스를 개발
Service 1
Container
Service 1
image
장점• VM 의 장점을 거의 포함• VM 보다 가벼움
단점• 인프라는 VM 보다 비 성숙함
Service 1
Container
Service 1
Container
1. 기능별로 서비스 어플리케이션 구분2. 서비스 이미지 개발3. 클라이언트에서 필요한 서비스 선택4. 인스턴스 선택 / 관리
구현 과정
클라이언트에서 각 서비스에 요청을 따로 보내야 하는가 ?
많은 요청은 비 효율적이며 클라이언트 코드가 복잡해짐
API Gateway
Inter-process Communi-
cation
API Gateway• 내부 시스템 아키텍쳐를 캡슐화해서
클라이언트에 적합한 API 를 제공• 비동기 , 논블로킹 I/O 를 지원하는 플랫폼으로 개발
• Netty, Vertx, Node.js, Nginx, etc..
• 통신 규격 다양화 ( 내 / 외부용 효율적인 방법 선택 )
• Auto-scaling, ip-address 변경에 대응• 서비스 오류 핸들링 ex) Netflix Hystrix
Inter-process Communica-tion
• 서비스 - 클라이언트 , 서비스 - 서비스간 통신 구현• 비동기적 (message-based) / 동기적 (request) 구현방법 선택• HTTP REST / Thrift 프로토콜• 서비스 오류 핸들링
1. 기능별로 서비스 어플리케이션 구분2. 서비스 이미지 개발3. 클라이언트에서 필요한 서비스 선택4. 인스턴스 선택 / 관리
구현 과정
인스턴스들은 Auto-Scaling, 장애 등으로 인해 IP 주소 등이 변화
Service Discovery
하나의 서비스는 가상화되어 여러 인스턴스로 실행됨
어떤 인스턴스에 접속해야 하는가 ?
Discovery Pattern
Service 1Instance A
Service 1Instance B
Service 1Instance C
10.4.3.1:6001
10.4.3.7:6002
10.4.3.9:6003
Service Registry
heartbeat
각 서비스는 Service Registry 에 자신의 상태를 전달Service Registry 는 가용한 인스턴스의 목록을 갖고있음
heartbeat
heartbeat
Discovery Pattern
Client-sideDiscovery Pattern
Server-sideDiscovery Pattern
Client-side Discovery Pat-tern
Client
1
2
Client-side Discovery Pat-tern
• 클라이언트에서 Service Registry 를 통해가용한 인스턴스 목록을 받아옴• 클라이언트에서 가용한 인스턴스에 직접 연결
장점• 지능적인 클라이언트 개발 가능단점• 클라이언트 코드 복잡 , 로직 복잡
Server-side Discovery Pat-tern
Client
Server-side Discovery Pat-tern
• 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 Reg-istry
heartbeat
heartbeat
heartbeat
Service Reg-istry
Instance A RegistrarHealth check
Register
(insta
nce A)
unRegister
()
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
참고 자료
Recommended