1. DS Plus Tek
Solution Business Div.
Microservice Overview
마이크로서비스 개요
Yun Younghun| Deputy General Manager2017-08-16-월
2. * summary
내용구성
Application
Service
1. Monolithic에서 Microservice로의 전환 Microservice Components
2. API Gateway
3. Service Discovery
4. Load Balancing
5. Messaging
6. Monitoring
7. Deployment
8. PaaS
Platform
서비스 간 호출 관리
Single & Large Codebase
High Cost Resource
Single Point of Failure
Long Deployement Cycle
no Clear Ownership
서비스 등록관리 자동화
서비스 간 부하분산
서비스 간 메세징 및 이벤트 처리
서비스 운영관리 및 분석
빌드/테스트/릴리즈/배포 자동화
Split to Micro Services
Row Cost Resource
Fault Isolation
Loosely-Coupled
Focused on doing one thing well
Platform as a Service를 이용한 Mircroservice 구성
1younghun.yun | 2017 | material for study purpose
3. 목 차
1. Microservice
2. API Gateway
3. Service Discovery
4. Load Balancing
5. Messaging
6. Monitoring
7. Deployment
8. PaaS
2
4. Microservice
Monolithic: 초기구성
Client
RDB
- Monolithic: 내부적으로 모듈화되지 않은, 단일 프로그램으로 구성된 Application 구성을 의미
- 서비스 개발/배포/복제의 복잡도가 낮아서 다루기 쉬움
Application
HTML JavaScript MVC
Service Service
Data Access
WAS
3younghun.yun | 2017 | material for study purpose
5. Microservice
Monolithic: 다중화 구성 및 부하 분산
- 서비스의 수평적 확장으로 다중화 구성 및 부하 분산 (Load Balancing)
- 기존 대비, 배포/운영관리 및 고비용 리소스 필요
Client
RDB
외부연계시스템 외부연계시스템 외부연계시스템
LoadBalancer
WAS
4younghun.yun | 2017 | material for study purpose
6. 특정 요건으로 서비스/기능 추가
Microservice
Monolithic: 서비스 확장에 따른 복잡성 증가
시간
고객요청으로 서비스/기능 추가
담당자변경 내부/외부 시스템 연계 추가초기구성
Application
Service
Application
Service
Application
Service
- 서비스의 지속적인 확장에 따라, 개발/배포/운영관리 복잡성 증가
5younghun.yun | 2017 | material for study purpose
7. App AppApp
Microservice
Monolithic to Microservice
- 기존의 대단위 서비스를 기능/모듈 기준의 작은 서비스 단위로 분리
- 각 마이크로 서비스 범위와 연계된 소단위 데이터베이스로 구성
App: Monolithic
Service
Database
Load
Balancer
App
Client
Shopping
DB
Account
Service
Shopping
Service
Catalog
Service
Customer
Service
API
Gateway
Account
Service
Shopping
Service
Catalog
Service
Customer
Service
Load
Balancer
Client
Account
DB
Catalog
DB
Customer
DB
6younghun.yun | 2017 | material for study purpose
9. Microservice
Microservice CONS
- 서비스 아키텍처 복잡도 증가
> 기존 대비 시스템을 구성하는 서비스 수 증가
- 테스트/배포/운영관리 대상 증가
> 서비스 세분화로 유지관리 포인트 증가
- 서비스 간 호출/응답 오버헤드 증가
> 각 서비스는 API를 이용하여 통신
- 장애 및 이슈에 대한 추적/디버깅 어려움
> 연동된 타 서비스에서 발생한 이슈의 추척/디버깅 필요
transaction
increases
increased apps
management
complex
architecture
simple
architecture
8younghun.yun | 2017 | material for study purpose
10. Microservice
Microservice PROS = Why Microservice
- 개발 및 배포에 대한 반영속도 향상
> 각 서비스의 범위를 한정하여 개발/반영 단순화
- 각 서비스마다 상이한 환경구성 가능
> 서로 다른 프레임워크/툴 도입의 제한 없음
> 각 서비스에 적절한 Language/DB 적용 가능
- 일부 장애로 인한 전체 시스템로의 영향범위 축소
> 전체 시스템 장애로 이어지는 위험요소 감소
> 자동복구 기능 적용 시, 최적의 운영관리 가능
- 리소스 효율 향상
> 필요한 경우 특정 서비스만 증설/축소
focused on doing
one thing well
loosely-coupled fault isolation
massive, solid,
uniform whole
fault effects to
the whole system
tightly-coupled
9younghun.yun | 2017 | material for study purpose
11. 목 차
1. Microservice
2. API Gateway
3. Service Discovery
4. Load Balancing
5. Messaging
6. Monitoring
7. Deployment
8. PaaS
10
12. API Gateway
communicate with APIs
- 각 마이크로 서비스 간 API를 통해 통신
> 경량화된 JSON/REST 기반의 최소기능 처리
- 서비스 다중화 및 확장에 따라 복잡도는 더욱 증가
> API Gateway를 적용하여 API End-Point 단일화
API
Gateway
{ }
...
API { }
...
API { }
...
API { }
...
API { }
...
API { }
...
API { }
...
API { }
...
API
각 서비스 간 호출 복잡도 증가
API
End-Point 단일화
API Gateway 적용
11younghun.yun | 2017 | material for study purpose
13. ...
{API}
...
{API}
...
{API}
...
{API}
API Gateway
API Gateway 적용
- API 호출 관리
> 라우팅 및 로드밸런싱 역할 가능
- API 로그 수집
> 로그 분석 및 미터링/차징 기능 적용
- 인증 서버와의 연동
> API 토큰 발급으로 인증 및 권한처리 가능
- API 표준 정책 적용
> 각 서비스는 비즈니스 로직 구현에 집중
API
Gateway
...
{API}
...
{API}
...
{API}
...
{API}
호출에 대한 분산 처리
로그 분석 및 활용
인증 및 권한 관리
비즈니스 로직 개발에 집중
12younghun.yun | 2017 | material for study purpose
14. API Gateway
Solutions: API Gateway
- Zuul
- KONG - APIGee-Tyk
> Netflix OSS
> Backend application으로의 요청을 처리하는 front door
> dynamic routing, monitoring, security 및 인증 기능으로 구성 가능
> 일종의 필터 역할로, 일정주기마다 필터설정을 로드하여 적용
13younghun.yun | 2017 | material for study purpose
16. 목 차
1. Microservice
2. API Gateway
3. Service Discovery
4. Load Balancing
5. Messaging
6. Monitoring
7. Deployment
8. PaaS
15
17. Service Discovery
- Microservice = 작은 단위의 수 많은 서비스로 구성
- 서비스 신규 추가 및 기존 확장 등 동적변경 가능 (Cloud/VM)
- 각 서비스의 관리 및 로드밸런싱을 위한 등록 및 설정 필수
> Service-Discovery 매카니즘 사용
> Configuration → 서비스 설정 변경
> Health Check → 서비스 상태 모니터링
> 수 많은 서비스를 수동으로 운영할 것인가?
> 서비스 관리 자동화 구현으로 운영 편의성 최적화
→ Service Registry 또는 Service Discovery
Service Management
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
신규 서비스 추가
기존 서비스 확장
수동으로 운영?
서비스 관리
Service Registry
담당자
...
{API}
16younghun.yun | 2017 | material for study purpose
18. Service Discovery
Service Discovery
- 각 서비스의 위치에 Registry Client 구성
> Registry Client = Discovery Agent
- Registry Client 내 Registry Server 정보 설정
> Registry Server에 각 서비스를 등록(register)
- Client-side 로드밸런싱이 구성되어 있는 경우,
신규추가 서비스는 Registry Server에 등록 후
타 서비스로 직접 요청 가능
Service
Registry
register()
Registry
Client
Registry
Client
Registry
Client
Registry
Client
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
Registry
Client
Registry
Client
Registry
Client
Registry
Client
Registry
Client
...
{API}
③ API Gateway를 거치지 않고
해당 서비스로 직접 요청
① 등록 (register)
② 각 서비스의
위치정보 전달
신규추가 서비스
Load
Balancer
17younghun.yun | 2017 | material for study purpose
19. Service Discovery
Solutions: Service Discovery
- Zookeeper
- Eureka
- etcd- Consul
> Netflix OSS
> REST 기반의 서비스 간 로드밸런싱 역할
> 서버를 통해 모든 클라이언트들에게 각 서비스의 위치정보 전달
> DNA+LoadBalancer 대비, 빠른 속도의 서비스-인 및 서비스-아웃 가능
18younghun.yun | 2017 | material for study purpose
20. 목 차
1. Microservice
2. API Gateway
3. Service Discovery
4. Load Balancing
5. Messaging
6. Monitoring
7. Deployment
8. PaaS
19
21. Load Balancing
Server-side Load Balancing
- Client의 요청을 Server에서 각 서비스로 로드밸런싱
- LoadBalancer 또는 Gateway에서 부하를 분산 처리
Client
API
Gateway
LoadBalancer
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API} Server
ServerClient
Service Service
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
Client
20younghun.yun | 2017 | material for study purpose
22. Service
Load Balancing
Client-side Load Balancing
- Server를 거치지 않고, Client에서 각 서비스로 직접 요청
> Server-side Load Balancing 대비, 부하 감소 및 병목현상 완화 가능
Client
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
Client
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
Service
Service
Client
Load
Balancer
Load
Balancer
Load
Balancer
Load
Balancer
Load
Balancer
Load
Balancer
Load
Balancer
Load
Balancer
21younghun.yun | 2017 | material for study purpose
23. Load Balancing
Solutions: Client-side Load Balancing
- Ribbon
- Curator
> Netflix OSS
> Fault tolerance & Built-in failure resiliency
> 비동기 및 반응형 모델에서의 다양한 프로토콜 지원 (HTTP, TCP, UDP)
> Service Discovery OSS(Eureka) 연동으로 서비스 간 부하 분산처리 구성
> Apache ZooKeeper를 활용한 Java client library
> vs ZooKeeper default
→ 서버에 문제 발생가 발생하면 다른 서버로 자동 재접속 처리 가능
22younghun.yun | 2017 | material for study purpose
24. 목 차
1. Microservice
2. API Gateway
3. Service Discovery
4. Load Balancing
5. Messaging
6. Monitoring
7. Deployment
8. PaaS
23
25. Messaging
REST vs Messaging
- REST API: 사전 정의된 형식에 따라 request/response 수행, 동기화 방식
- Messaging: 비동기 방식의 메세지 처리로 Load Balancing, Service Discovery 가능
send
messaging busPublisher/
Producer/
Provider
Subscriber/
Consumer
Server
Client
Client
Subscriber/
Consumer
...
{API}{API}
...
{API}
...
{API}
RESTful API
Messaging
- Synchronous (default)
- 사전 정의된 타입/포맷 형식
- Load Balancing > 별도 인프라 또는 S/W LB 사용
- Service Discovery > DNS 또는 Registry 사용
- API 호출/응답 실패 시, 재시도 로직 구현 필요
- Asynchronous
- 사용자 지정 방식의 메세지 형식 가능
- 로드밸런싱 > Messaging 내 구현 가능
- Service Discovery > Messaging 내 구현 가능
- 메세지 저장 및 수신확인으로 메세지 전달 보장
- Target Service 인스턴스 추가 용이
...
{API}
...
{API}
...
{API}
24younghun.yun | 2017 | material for study purpose
26. Messaging
Service Broker
Queue γ
Provider A
Provider B
Provider C
Queue α
Queue β
Consumer α
Consumer β1
Consumer β2
Consumer β3
Service Broker
- Consumer에게 Event/Message를 전달하며, Mediating 및 Orchestration/Coordination 기능으로 동작
- 서비스 간 비동기 방식으로 통신하며, 서비스 간 결합/의존을 약화하여 업무 구성의 유연성 증가
Service A
Controller Service
Broker
App
Env.
App
Env.
Service
Back-end
Service
Instance
Service
Instance
provision
bind
unbind
deprovision
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
...
{API}
Service B
...
{API}
25younghun.yun | 2017 | material for study purpose
27. Messaging
Solutions: Service Broker
- Kafka
- RabbitMQ - NATS
> 분산처리 메세징 시스템
> Producer와 Consumer 사이의 메세지 전달
> 모니터링, 이벤트 체크 및 로그통합 시스템 구축 가능
> 빅데이터 스트림 및 배치 프로세스와 연동하여 메세지 변환 가능
26younghun.yun | 2017 | material for study purpose
28. 목 차
1. Microservice
2. API Gateway
3. Service Discovery
4. Load Balancing
5. Messaging
6. Monitoring
7. Deployment
8. PaaS
27
29. Monitoring
Microservice Monitoring
- Microservice 적용 > 시스템 구성 서비스의 세분화
> 모니터링 포인트 수 증가 = 운영관리의 복잡성 증가
> 시스템의 각 서비스 및 API 단위의 모니터링 필요
Load Balancers
Application Servers
Database & Replica
Service
Broker
Service
Registry ServerDatabase
UIUI
Service Service
Server
ServiceServiceService
Service
Broker
Database Server
시스템 지표
모니터링
서비스 및
프로세스 관리
이벤트/장애
알림 및 경고
이슈/트러블
추적 및 분석
28younghun.yun | 2017 | material for study purpose
30. Monitoring
Microservice Monitoring
- 무겁지 않은 + 한 눈에 확인할 수 있는 + 자동화된 모니터링 필요
> 시스템 모니터링 주요 지표
> 서비스 및 프로세스 관리
> 이벤트/장애 알림 및 경고
> 이슈/트러블 추적 및 분석
시스템 지표 모니터링
CPU Usage/Idle
Memory Usage/Idle
Network I/O Usage
Disk Usage/Idle
...
서비스 및 프로세스 관리
인스턴스/시스템 관리
Application 서비스 관리
API 및 Messaging 체크
Transaction 관리
Performance 체크
...
이벤트/장애 알림 및 경고
...
이슈/트러블 추적 및 분석
...
29younghun.yun | 2017 | material for study purpose
32. Monitoring
Logging
- 시스템의 각 구성요소를 구분하는 고유ID 및 표준시간 등의 공통기준을 포함하여 로그 구성
- 다수의 위치에서 발생하는 로그를, 전체적으로 수집가능한 Collector/Aggregation 필요
Provider A
Provider B
Service Broker
Consumer α
Consumer β
Consumer γ
Log Collector
31younghun.yun | 2017 | material for study purpose
34. Monitoring
Circuit Breaker
- 특정 서비스에서 오류 발생 시, 해당 서비스를 차단
> 해당 오류로 인한 타 서비스의 연쇄적인 장애발생 방지
> 오류 발생한 서비스에 대한 자동복구 가능 시, 운영관리 효율 향상
Service A
health check ♥: success
Circuit Closed
Service B2
Service B3
Service B1
33younghun.yun | 2017 | material for study purpose
36. 목 차
1. Microservice
2. API Gateway
3. Service Discovery
4. Load Balancing
5. Messaging
6. Monitoring
7. Deployment
8. PaaS
35
37. Deployment
Deployment Process
DEV STG PROD
Local
개발
테스트
링킹컴파일 빌드 배포
Build/Deploy
Repository
Source Repo. Binary Repo.
테스트/모니터링
설계
Service Design
- 배포 프로세스의 최적화 및 자동화 필요
> 품질 및 운영 관리, 서비스 반영속도 향상 가능
Integration / Deployment
프로세스 단계별 자동화 파이프라인 구성 > CI/CD
36younghun.yun | 2017 | material for study purpose
38. Deployment
CI/CD: Jenkins
- Continuous Integration, 수동 배포 및 완전 자동 배포 설정 가능 > Continuous Deploy
- 1200 개 이상의 플러그인 적용 가능 > 추가기능 적용 및 확장성 우수
SourceCode / Commit Build / Config Scan / Test Release Deploy
Commit Build Test Deploy
Continuous Integration/Deploy
Release
Development Deployment
- Complex Delivery Pipelines
- Delivery of App and Config
- Robust and Highly Available
37younghun.yun | 2017 | material for study purpose
39. Deployment
CI/CD: Concourse
- 릴리즈 / 테스트 / 빌드 파이프라인을 자유롭게 작성
- Stand alone binary / BOSH를 통한 클러스터 배포 등의 방법을 사용 가능
Simple & Scalable
- 간단한 서술형식의 설정 파일로
파이프라인 정의 가능
- 설정 파일은 주요 3가지 컨셉으
로 구성
Streamlined UI
- 진행과정 및 이슈발생 포인트를
손쉽게 확인 가능한 UI 제공
- 파이프라인의 입력값 조정 가능
- 모든 task는 별개의 컨테이너 및
개별 의존성을 가지고 동작
- Fly CLI 제공
Dependable Results Integrations
- 외부 서비스 및 사용자 정의
리소스를 사용하여 파이프라인
확장 가능
38younghun.yun | 2017 | material for study purpose
40. Deployment
VM vs Container
Server
Host OS
Hypervisor
Guest
OS
Guest
OS
Guest
OS
Bins/Libs Bins/LibsBins/Libs
APP APP APP
Server
Host OS
Container Engine
Bins/Libs Bins/LibsBins/Libs
APP APP APP
- VM: Host OS 위의 Guest OS를 가상화하여 Application 동작
- Container: 가상의 Guest OS 없이 Host OS의 kernel을 공유할 수 있는 Container Engine으로 Application 동작
VM
> VM과 비교하여 좀 더 Application 중심으로 설계
> VM보다 작은 단위이며, 처리에 필요한 리소스도 적음
> 간단하고 빠르며 효율적으로 Application 실행 가능
Virtual Machine Container
Virtualization
Isolation
Container
39younghun.yun | 2017 | material for study purpose
41. LXCLXC
Deployment
LXC: Linux Container
LXC
Bins/Libs Bins/LibsBins/Libs
APP APP APP
Container
Host OS: Linux kernel
Server: Hardware네트워크메모리 디스크CPU
cgroups namespaces
- PROS
> Application 시작/종료 속도 향상
> 사용 리소스 적음: 리소스 활용도 증가
> 오버헤드 감소
- CONS
> Host OS에 종속적
> 컨테이너별 kernel 분리 불가능
40younghun.yun | 2017 | material for study purpose
42. Deployment
Docker
- (v0.8기준) LXC 기반으로 Application SendBox를 자동생성
- 프로그램, 소스 코드, 컴파일된 실행파일을 Read-Only 형태의 Docker Image로 push/pull
Docker Host Docker RegistryDocker Client
docker build
docker pull
docker run
Containers
Docker Daeamon
Images
Docker ImageBins/Libs
APPS
Host OS
Docker Engine
Server
Docker Image
Docker Architecture
41younghun.yun | 2017 | material for study purpose
43. Deployment
BOSH
- 분산된 시스템의 Release, Deployment, Life Cycle 관리 및 모니터링 가능
- 수백개의 VM 및 Deploy 관리가 가능하며, 모니터링과 장애복구 및 DownTime 최소화된 업데이트 가능.
Agent
Agent
NATS
Registry
BlobStroeHealth
Monitor
Postgres
DB
Director
VM
VM
CLI
CPI
IaaS
API
Deployment "A" VMs
Deployment "B" VMs
BOSH Director
Director managed resources
BOSH CLI
Infra/Iaas Resources
42younghun.yun | 2017 | material for study purpose
44. Deployment
BOSH Deployment Process & Features
- Deploy Process
BOSH
Orchestration
Configuration
Management
Release
- Name
Jobs
- Software packages
- Config templates
- Scripts
Stemcell
- Base OS
- BOSH agent
Deployment Manifest
- Release name/version
- #VMs, job params
- Stemcells to use
Deployed Environment Virtual Machine
- Configuration
- Software package
Virtual Machine
- Configuration
- Software package
Virtual Machine
- Configuration
- Software package
Virtual Machine
- Configuration
- Software package
- 백업 & 복구
- Cross Cloud 지원
- 모니터링 & 경고알림
- Networking
- Rolling 업데이트
- Storage 관리
- Provisioning
- Templating
- Job Consistency
- 패키징
- 장비 업데이트
- Discovery
- Interdependency
- Lifecycle 관리
- Features
43younghun.yun | 2017 | material for study purpose
45. Deployment
Kubernetes
- Kubernetes(k8s): Container Orchestration Tool
- 여러 Host(Node)를 그룹화하여 클러스터로 구성
- Container 기준으로 아래 기능 수행 가능
> 배포(deployment)
> 확장(scaling)
> 복제(replication)
> 롤링 업데이트(rolling update)
> 롤백(rollback)
> 자동복구(auto-restart)
Master Node
Controller
kubectl
Scheduler
Distributed
Storage
kubelet
POD
Proxy
Docker
POD
44younghun.yun | 2017 | material for study purpose
46. 목 차
1. Microservice
2. API Gateway
3. Service Discovery
4. Load Balancing
5. Messaging
6. Monitoring
7. Deployment
8. PaaS
45
47. PaaS
Microservice 구성
Developers
- Microservice를 어떻게 구성할 것인가?
더 많은 담당인력으로 구성운영관리할 것인가?
플랫폼 자체로 구성
Platform
많은 구성요소로 서비스/배포/모니터링/운영관리 구성
개발/테스트
46younghun.yun | 2017 | material for study purpose
48. PaaS
Platform as a Service
- 빌드/릴리즈/배포/모니터링/운영관리 등을 플랫폼화하여 구성하고, Application 구성만을 집중하여 관리
Application
Runtimes
Security & Integration
Databases
Servers
Virtualizations
Server Hardware
Storage
Networking
on-premise
managementscope
Application
Runtimes
Security & Integration
Databases
Servers
Virtualizations
Server Hardware
Storage
Networking
Iaas
managementscope
Application
Runtimes
Security & Integration
Databases
Servers
Virtualizations
Server Hardware
Storage
Networking
PaaS
managementscope
Application
Runtimes
Security & Integration
Databases
Servers
Virtualizations
Server Hardware
Storage
Networking
SaaS
47younghun.yun | 2017 | material for study purpose
49. PaaS
CloudFoundry
- Multiple Cloud Application PaaS, OSS
- Application 빌드/배포/운영관리 등의 모든 구성을 플랫폼 서비스로 자동화 > 개발 후 push app 실행하면 반영까지 완료
Developers
Cloud
Controller
Router
Health
Manager
NATS
(message bus)
c
Containerization
WardenDEA
Droplet
Execution
Agent
Staging Apps
Running Apps
DEA Pool
Push App
App Deploy
48younghun.yun | 2017 | material for study purpose
50. PaaS
CloudFoundry Commercial
- Pivotal Cloud Foundry
- IBM Blumix - PaaS-TA
> CloudFoundry ownership
> 다양한 Infrastructure 지원: AWS, Azure, vSphere, OpenStack
> General Electric, Citi Bank 등의 고객사에 Microservice/PaaS 도입
> Market place를 이용한 수 많은 compoment 제공 및 적용 가능
49younghun.yun | 2017 | material for study purpose
51. 50
* wrap up
내용요약
younghun.yun | 2017 | material for study purpose
Router
NATS
Cloud
Controller
Cloud
Controller
Database
Health
Manager
Blobs
User Account &
Authentication
User Account &
Authentication
Collector
Syslog
Aggregator
VM
ServerDirectory
Server
Container
DEA
Microservice
Developers
Users/Customers
requests
PROS
CONS