11st Legacy Application의 Spring Cloud 기반 MicroServices로 전환 개발 사례

11st Legacy Application의 Spring Cloud
기반 MicroServices로 전환 개발 사례
Platform 개발단

Tech Infra 개발 본부

개발혁신팀 윤용성

이 발표의 목적은…
Spring Cloud의 가장 핵심이 되는 개념을 정확하게
이해
Spring Cloud의 주요 요소를 당장 자신의 Project
에 적용하기 위한 동기 부여
Spring Cloud 기반의 MSA로 전환 시 고려사항 공유

Project Vine
11st Legacy Application 개선 Project

Strangler Application Pattern
열대 우림 지역의 Stranger Vine에서 유래

Legacy 교살 전략

새로운 Application 은 독립된 API 서버로

Legacy와 함께 운영

위의 과정을 반복
Application
Modernization
Strategy
“Strangler Application”
by Martin Fowler

Strangler Application Pattern in 11st - Hybrid MSA
WAR
Front/Mobile
WAS
WAR
Front/Mobile
WAS
REST 
API
Zuul
API Gateway
전시
API
Server
상품
API
Server
추천
API
Server
추천
Service
XXX
API
Server
…
Eureka Server
Config Server
Admin Server
?

Best Practice - Netflix OSS & Spring Cloud
Hystrix
Eureka
Ribbon
EvCache
Spectator
Archaius
….
Spring Cloud
Config
Stream
Sleuth
Contract
….….

Technical Background

Spring Cloud

Basic Component

Hystrix - Circuit Breaker
public String anyMethodWithExternalDependency() {
URI uri = URI.create("http://172.32.1.22:8090/recommended");
String result = this.restTemplate.getForObject(uri, String.class);
return result;
}
@HystrixCommand
Hystrix 적용하기
위의 메소드를 호출할 때 벌어지는 일
- 이 메소드 호출을 'Intercept' 하여 “대신” 실행 - 대신 ??
- 실행된 결과의 성공 / 실패 (Exception) 여부를 기록하고 “통계”를 낸다. -
통계 ??
- 실행 결과 “통계”에 따라 Circuit Open 여부를 판단하고 필요한 “조치”를 취
한다. 조치 ??

Circuit Open ??
- Circuit이 오픈된 Method는 (주어진 시간동안) 호출이 “제한”되며, “즉시”
에러를 반환한다.
Why ?
- 특정 메소드에서의 지연 (주로 외부 연동에서의 지연)이 시스템 전체의 Resource
를 (Thread, Memory등)를 모두 소모하여 시스템 전체의 장애를 유발한다.
- 특정 외부 시스템에서 계속 에러를 발생 시킨다면, 지속적인 호출이 에러 상
황을 더욱 악화 시킨다.
So !
- 장애를 유발하는 (외부) 시스템에 대한 연동을 조기에 차단 (Fail Fast) 시킴
으로서 나의 시스템을 보호한다.
기본 설정
- 10초동안 20개 이상의 호출이 발생 했을때 50% 이상의 호출에서 에러가 발
생하면 Circuit Open

public String anyMethodWithExternalDependency() {
return result;
}
@HystrixCommand
이제 이 메소드가 호출된다면 ?
- 이 메소드는 'Intercept' 되어 별도의 Hystrix Thread Pool에서 “대신” 실행 된다.
- 메소드 내부에서 발생한 Exception의 횟수는 Circuit Breaker 내에서 통계
가 내어진다.
- Circuit Open 조건에 도달하면 Circuit이 Open되어 호출이 차단 된다.
* 가장 기본적인 Circuit Breaker 개념 적용 완료 !

- 기본 설정으로는 유사한 일을 하는 두개의 메소드가 별도의 Circuit Breaker를
갖게된다.

public String anyMethodWithExternalDependency1() {
URI uri = URI.create("http://172.32.1.22:8090/recommend");
return result;
}
@HystrixCommand
URI uri = URI.create("http://172.32.1.22:8090/mainrecommend");
return result;
}
@HystrixCommand
Circuit Breaker는 어떤 단위로 생성되는가 ?
- Default로 @HystrixCommand가 명시된 메소드 단위

Circuit의 단위 명시하기 - CommandKey
- “CommandKey”는 Circuit Breaker의 단위이며 여러개의 메소드를 같은
Key를 명시함으로써 하나의 Circuit을 사용하게 할 수 있다.
return result;
}
@HystrixCommand(commandKey = “ExtDep1”)
URI uri = URI.create("http://172.32.1.22:8090/mainrecommend");
return result;
}
@HystrixCommand(commandKey = “ExtDep1”)
- 즉, A 메소드와 B 메소드가 같은 Circuit Breaker를 사용한다면, A
와 B의 에러 비율이 함께 통계내어지고, Circuit이 오픈되면 함께 차
단된다.

return result;
}
public String recommendFallback() {
return “<미리 준비된 상품 목록>”;
}
@HystrixCommand(commandKey = “ExtDep1”, fallbackMethod=“recommendFallback”)
Hystrix의 또 하나의 중요한 개념 - Fallback
- Fallback method는 Circuit이 오픈된 경우 혹은 Exception이 발생한 경우
대신 호출될 Method.

- 오류 발생시 Exception 대신 응답할 Default 구현을 넣는다.

오랫동안 응답이 없는 메소드에 대한 처리 방법은 ?
- 특정 메소드의 총 소요시간에 대한 Timeout을 직접 관리/예측하는 것은 매우 힘들다

- ex) Socket Connect/Read Timeout, JDBC Timeout, 3rd Party 라이브러디
등
- 설정하지 않으면 default 1,000ms

- 물론 이경우에도 Fallback이 있다면 Fallback을 수행
Hystrix에서는 Circuit Breaker별로 Timeout 설정 가능
- 해당 메소드가 설정된 시간안에 안 끝나면 Timeout으로 인한 Exception 자
동 발생

연동

System A
Thread Pool
A

(20 threads)
Thread Pool
B

(10 threads)
Thread Pool
C

(15 threads)
Circuit
Breaker A
Circuit
Breaker B
Circuit
Breaker C
Circuit
Breaker D
Circuit
Breaker F
연동

System B
연동

System C
User Request
Hystrix를 쓴다는 것의 또다른 의미
- Hystrix를 통해 실행한다는 것은 별도의 Thread Pool에서 내 Code를 실행
한다는 것

- 각 Circuit Breaker는 한 개의 Thread Pool과 연동

- 하나의 ThreadPool을 여러 개의 Circuit Breaker가 공유할 수 있다.

각 Circuit Breaker가 사용할 Thread Pool의 지정
- 내 시스템의 Resource가 다양한 기능(서비스)들을 위해 골고루 분배 될
수 있도록..
- 어느 하나 외부 Dependency (외부 연동 시스템)의 문제 발생시 그 영
향으로 부터 시스템의 다른 요소를 보호 - Isolation
- ThreadPoolKey (혹은 CommandGroupKey) 속성으로 지정

- 각 Thread Pool 별로 Max Thread 지정
Thread Pool을 사용하는 의미
* Hystrix는 Thread Isolation이 아닌 Semaphore 방식의 Isolation도
제공합니다. (옵션)

소스 : https://medium.com/netflix-techblog/fault-tolerance-in-a-high-volume-distributed-system-91ab4faae74a
가정

각 서버 별 가용성 : 99.99%

30개의 Dependency 존재
99.99% ^ 30 = 99.7%
Uptime = 1달 기준 2시
간
인용 : https://speakerdeck.com/benjchristensen/performance-and-fault-tolerance-for-the-netflix-api-august-201

Server Side Load Balancer (with L4 Switch)
Client

(Caller)
Server1
Server2
Server3
Server4
L4
Switc
h
- 일반적인 L4 Switch 기반의 Load Balancing

- Client는 L4의 주소만 알고 있음

- L4 Switch는 Server의 목록을 알고 있음 (Server Side Load Balancer)
- H/W Server Side Load Balancer 단점 (장점도 있지만..)

- H/W가 필요 (비용↑, 유연성↓)

- 서버 목록의 추가를 위해서는 설정 필요 (자동화 어려움)

- Load Balancing Scheme이 한정적 (Round Robin, Sticky)

Client Side Load Balancer - Ribbon
Client

(Caller)
Server1
Server2
Server3
Server4
- Client (API Caller)에 탑재되는 S/W 모듈

- 주어진 서버 목록에 대해서 Load Balancing을 수행함
- Ribbon의 장점 (단점도 있지만… )

- H/W가 필요 없이 S/W로만 가능 (비용↓, 유연성↑)

- 서버 목록의 동적 변경이 자유로움

- Load Balancing Scheme이 마음대로 구성 가능
R

i

b

b

o

단순한 Load Balancer ?
ServerList - Load Balancing의 대상이될 Server 목록 결정
- 1) Configuration을 통해 직접 목록 설정

- 2) Discovery 기반으로 Runtime에 획득한 서버 목록 사용
IRule - 트래픽을 보낼 서버를 선택
- 1) Simple Round Robbin

- 2) Response Time Weighted - 서버별 응답 시간에 따라 트래픽 양 조절

- 3) Availability Filter

- 최근 3번 연속 에러를 발생시킨 서버를 Load Balancing 대상에서 일정시
간 동안 제외 시킴

단순한 Load Balancer ?
IPing - 주기적으로 호출하여 해당 서버의 Aliveness를 검사
- 1) 특정 URL 호출

- 2) Discovery 기반 - Discovery 서버에 UP 상태로 등록되어 있는지 조사

- Ping에 실패한 서버는 임시로 Load Balancing 대상에서 제외

ServerList, IRule, IPing 등 Ribbon의 주요 기능은 다양하게 설
정이 가능하며, 직접 구현하여 넣는 것도 가능

Ribbon의 또 하나의 중요한 기능 - Retry
Client

(Caller)
Server1
Server2
Server3
Server4
R

i

b

b

o

O
선택된 대상으로의 호출 실패 시 정해진 횟수 만큼의 Retry 설정 가능

- 같은 서버 재시도 횟수, 다른 서버 재시도 횟수 설정

- Exception 발생 경우 뿐만 아니라 재시도 할 HTTP Status 지정
가능

How to Use
- 다양한 사용 방법이 존재…..

- 직접 API 호출하여 대상 서버/포트 획득 후 사용
다양한 Http Client 및 Server에 이미 내장되어 있음
- Spring `RestTemplate`

- @LoadBalanced RestTemplate

- Spring Cloud Feign Client

- Declarative Http Client

- Ribbon이 내장되어 있음

- Zuul API Gateway

- Ribbon이 내장되어 있음

Eureka

Dynamic Service Discovery

MSA를 적용한다고 하나의 서버를 여러개의 API 서버로 분할했는데…

- 수많은 API 서버의 IP Address와 Port 번호는 어떻게 Caller에게 전달하
지 ?

- L4도 없이 Client Load Balancer를 사용하는데, 각 Ribbon 설정에 언제
서버 주소와 포트 번호를 설정하지 ?
서버 분할 후 고민…
“서버가 새롭게 투입되면 그것을 감지하여 목록에 자동으로 추가되고,
서버가 종료되면 자동으로 목록에서 삭제하기 위한 방법은 없을까 ?”
“API를 호출하는 쪽에서도 상대방 주소(들)을 알 필요 없이 이름 만으
로 호출하게 할 수는 없을까 ? ”

Dynamic Service Discovery - Eureka
API Server “A”
Eureka

Client
Eureka Server
Service A ip1:8081
Service B
Service C
Service D
API Caller “가”
Eureka

Client
0. Eureka를 사용할 모든 Server에 Eureka Client 탑재
주기적으로 Fetch
②
2. Eureka Client는 주기적으로 Service별 IP 목록을
Fetch 보관
서버 시작시 - 등록 / 종료시 - 제거
IP주소:port:”Service A”
①
1. 서버 가동시 자신의 정보(ip/port/서비스명)을
Eureka Server에 등록 (반대로 종료시 삭제)
③
Eureka에 획득한 주소로 호
출
3. API 호출시 서비스 이름 (Service A)를 사용하여 해당
서버 목록 획득 후 호출

API Server “A” - instance #1
Eureka

Client
Eureka Server
Service A ip1:8081 ip2:8081 ip3:8081
Service B
Service C
Service D
서버 시작시 - 등록 / 종료시 - 제거
IP주소:port:”Service A”
API Server “A” - instance #2/3/4/5/6
Eureka

Client
Eureka

Client
Eureka

Client
Eureka

Client
Eureka

Client 서버 인스턴스 추가 / 제거시 별도의 설정 작업 없이 가능

Eureka Server 만들기 / Eureka Client 탑재하기
@EnableEurekaServer
@SpringBootApplication
public class EurekaServiceApplication {
public static void main(String[] args) {
SpringApplication.run(EurekaServiceApplication.class);
}
}
- Eureka + Ribbon의 결합 시 Ribbon의 LoadBalancing 서버 목록을
Eureka를 통해서 공급
@EnableEurekaClient
@SpringBootApplication
public class EurekaServiceApplication {
public static void main(String[] args) {
SpringApplication.run(EurekaServiceApplication.class);
}
}
* dependency 추가 및 추가 설정 필요

Hystrix + Ribbon + Eureka
1. Server간의 호출은 Hystrix를 적용한다.
- 장애시 Circuit Open을 통한 장애 전파 차단
- Fallback을 통해 응답 오류시 대체 응답 제공
- Timeout을 통해 최대 응답 가능 시간 제어
- Thread Pool 분리를 통한 Isolation 제공
2. Server간의 Load Balancing은 Ribbon을 적용한다.
- L4 구성 없이 복수 서버로의 Load Balancing 쉽게 가능
- IRule에 의해서 에러 발생 서버를 Load Balancing 대상에서 임시 제거
- IPing을 통해서 서버의 Aliveness에 따라 트래픽 유입 결정
- Retry를 통해서 호출 실패 시 재시도

Hystrix + Ribbon + Eureka
3. Server의 주소는 Eureka를 통해서 획득한다.
- 서버 인스턴스 추가 / 삭제시 Ribbon + Eureka에 의해 자동 반영
- 서버 Down시 Eureka Server가 해당 상태를 반영함으로써 목록에서 제거
“Hystrix + Ribbon + Eureka`를 함께 사용함으로써…

- MSA 환경에서의 서버간의 복잡한 호출 관계로 발생할 수 있는
서비스 안정성 문제를 최대한 해결

- 인프라 구성의 단순화

11st Legacy Application 개선 프로젝트

Project Vine

다시 본론으로…

Strangler Application Pattern in 11st - Hybrid MSA
WAR
Front/Mobile
WAS
WAR
Front/Mobile
WAS
REST 
API
?

WAR
Front/
WAR
Front/
?
첫번째 고민

- Legacy Application에서 새로 만들어진 수많은 API 서버들을 어떻게
호출할까 ?

- Old S/W Stack, 대단위 수정 배포의 Risk 등으로 Eureka, Ribbon
등을 Legacy Application에 직접 탑재하는 것이 어려움
11st New Architecture - Legacy로 부터의 호출

WAR
Front/
WAR
Front/
?
두번째 고민

- 모든 API 서버들에 들어갈 공통된 기능을 구현할 곳과, 전체 API
호출을 통제할 곳이 필요해
“전체 API Server들의 맨 앞단에 API Gateway의 도입으로 해결 가
능”
11st New Architecture - Legacy로 부터의 호출

API Gateway - Spring Cloud Zuul의 도입
- API의 외부 노출을 위한 Endpoint로서의 역할

- URL별로 Mapping된 Server 군으로 API 호출을 Forward
- 일반적인 API Gateway와 유사 - ? Box 만이 특별한 점

API Gateway - Zuul
1. HystrixCommand
1. Zuul의 모든 API 요청은 HystrixCommand로 구성되어 전달된다.

- 각 API 경로 (서버군) 별로 Circuit Breaker 생성

- 하나의 서버군이 장애를 일으켜도 다른 서버군의 서비스에는 영향이 없다.

- CircuitBreaker / ThreadPool의 다양한 속성을 통해 서비스 별 속성에
맞는 설정 가능
Service “A” Servers

API Gateway - Zuul
1. HystrixCommand
2. API를 전달할 서버의 목록을 갖고 Ribbon을 통해 Load-Balancing을 수행한
다.

- 주어진 서버 목록들을 Round-Robin으로 호출

- 연속 에러 발생 서버는 목록에서 임시 제거

- Coding을 통해 Load Balancing 방식 Customize 가능

2. Ribbon

API Gateway - Zuul
1. HystrixCommand
3. Eureka Client를 사용하여 주어진 URL의 호출을 전달할 “서버 리스트”를 찾는다.

- Zuul에는 Eureka Client가 내장

- 각 URL에 Mapping된 서비스 명을 찾아서 Eureka Server를 통해 목록을 조회
한다.

- 조회된 서버 목록을 `Ribbon` 클라이언트에게 전달한다.

2. Ribbon
3. Eureka Client

API Gateway - Zuul
1. HystrixCommand
4. Eureka + Ribbon에 의해서 결정된 Server 주소로 HTTP 요청

- Apache Http Client가 기본 사용

- OKHttp Client 사용 가능
2. Ribbon
3. Eureka Client
4. Http Client

API Gateway - Zuul
1. HystrixCommand
5. 선택된 첫 서버로의 호출이 실패할 경우 Ribbon에 의해서 자동으로 Retry 수행

- Retry 수행 조건

- Http Client에서 Exception 발생 (IOException)

- 설정된 HTTP 응답코드 반환 (ex 503)
2. Ribbon
3. Eureka Client
4. Http Client
5. Retry By Ribbon

API Gateway - Zuul
1. HystrixCommand
Zuul의 모든 호출은….
2. Ribbon
3. Eureka Client
4. Http Client
5. Retry By Ribbon
- HystrixCommand로 실행되므로 Circuit Breaker를 통해

- 장애시 Fail Fast 및 Fallback 수행 가능
- Ribbon + Eureka 조합을 통해

- 현재 서비스가 가능한 서버의 목록을 자동으로 수신 및 상태에 따른 목록 제
- Ribbon의 Retry 기능을 통해

- 동일한 종류의 서버들로의 자동 재시도가 가능

11st New Architecture with Zuul API Gateway
WAR
Front/Mobile
WAS
WAR
Front/Mobile
WAS
REST 
API
전시
API
Server
상품
API
Server
추천
API
Server
추천
Service
XXX
API
Server
…
Eureka Server
Config Server
Admin Server
Zuul
API Gateway
Hystrix + Eureka
+ Ribbon
모든 Legacy Application으로 부터의 호출은 Zuul API
Gateway를 통해서 호출

11st New Architecture - Internal Server to Server호출
WAR
Front/Mobile
WAS
REST 
API
전시
API
Server
상품
API
Server
추천
API
Server
추천
Service
XXX
API
Server
…
Eureka Server
Config Server
Admin Server
Zuul
API Gateway
Hystrix + Eureka
+ Ribbon
새롭게 분리된 API 서버간에도 많은 호출이 필요하다.

- Hystrix, Ribbon, Eureka를 내부 호출 안에서도 적용할 필요
가 있다.

11st New Architecture - Internal Server to Server호출
내부 API 서버간에 Hystrix + Ribbon + Eureka를 적용하는 방법

1. Hystrix + Ribbon + Eureka를 직접 사용

2. @LoadBalanced RestTemplate + Hystrix Wrapping
3. Spring Cloud Feign을 사용하는 방법

Spring Cloud Feign
Declarative Http Client

- Java Interface + Spring MVC Annotation 선언 만으로
HTTP 호출을 위한 HTTP Client Bean을 자동 생성

- Open Feign기반의 Spring Cloud 확장
Hystrix + Eureka + Ribbon 연동 기능 내장

- 간단한 설정만으로 Hystrix, Ribbon, Eureka 적용이 가능

- 즉, HTTP 호출에 다음의 기능들이 자동으로 적용 가능

- 예) Circuit Open, Timeout, Fallback, Thread Pool
Isolation, Load Balancing, Dynamic Service Discovery

11st New Architecture with Spring Cloud Feign
WAR
Front/Mobile
WAS
REST 
API
전시
API
Server
상품
API
Server
추천
API
Server
추천
Service
XXX
API
Server
…
Eureka Server
Config Server
Admin Server
Zuul
API Gateway
Hystrix + Eureka
+ Ribbon
Spring Cloud Feign
Hystrix + Eureka
+ Ribbon
모든 내부 호출에도 Hystrix, Ribbon, Eureka를 적용하여
Server 간 직접 호출한다.

11st New Architecture - 외부 서버로의 호출
WAR
Front/Mobile
WAS
REST 
API
전시
API
Server
상품
API
Server
추천
API
Server
추천
Service
XXX
API
Server
…
Eureka Server
Config Server
Admin Server
Zuul
API Gateway
Hystrix + Eureka
+ Ribbon
페
인
페
인
신규 API 서버로 부터 기존의 외부 서버로의 호출

- 기존 외부 서버는 Eureka Client가 탑재 되어 있지 않으므로 Eureka를 통한 서
버 주소 획득은 어려움

- Hystrix + Ribbon의 조합만 사용 (실제 구현은 Spring Cloud Feign을 통해
Eureka만 disable해서 사용)

11st New Architecture - 외부 서버로의 호출
WAR
Front/Mobile
WAS
REST 
API
전시
API
Server
상품
API
Server
추천
API
Server
추천
Service
XXX
API
Server
…
Eureka Server
Config Server
Admin Server
Zuul
API Gateway
Hystrix + Eureka
+ Ribbon
페
인
페
인
Hystrix + Ribbon
신규 API 서버에서 외부 서버로의 호출은 Hystrix + Ribbon 조
합을 사용한다.

11st Architecture TF

Project Vine - Platform Management

기존 L4 기반의 Zero Downtime Deployment
Client

(Caller)
Server1
Server2
Server3
Server4
L4
Switc
h
배포시스
템

(Jarvis)
1. 배포 대상 서버 L4 Out 명령
2. 서버 배포 및 재가동
3. L4 In 명령

11st New Architecture -

Spring Cloud 기반의 Zero Downtime Deployment
Eureka

Server
Client

(Caller)
Server1
Server2
Server3
Server4
배포시스
템

(Jarvis)
1. 배포 대상 서버

Eureka 상태 변경 요청

- Out Of Service
3. 서버 배포 및 재가동
R

i

b

b

o

E

u

r

e

k

4. 서버 재가동시 Eureka 상태

원상 복구 - UP
2. 주기적인 Eureka

상태 정보 동기화
현재는 Jarvis의 명령어를 통해 Eureka에 Manually 명령을 내리게
구성되어있지만, 올해 내 Eureka-Aware하게 배포 시스템 개선 예정

11st New Architecture -

Spring Cloud 기반의 Zero Downtime Deployment
그러나 실제 Eureka의 상태 변경이 API를 호출하는 쪽에 까지
반영되는데는 시간이 필요함

1. Eureka Server의 응답 Cache

2. Eureka Client의 주기적 동기화 주기

3. Ribbon의 내부 Cache 갱신 주기
* 위의 세가지 옵션에 대한 “주의깊은” 조정 과 이해가 필요

11st New Architecture - Config 관리
기존의 Configuration 관리

- Application Config

- 주로 War안에 Properties 파일 포함

- 개발자가 관리

- WAS Config

- 해당 시스템의 디렉토리에 존재

- Infra Engineer가 관리
Project Vine에서의 Config 관리 문제

- Spring Boot 기반의 Embedded Tomcat 사용

- 따라서, WAS(Tomcat) Config가 War 안에 같이 포함

- 담당 Infra Engineer가 이를 수정하기 위해서는
Repository에 Clone / 수정 / 빌드 / 배포를 다시해야 한
다 ?

11st New Architecture with Spring Cloud Config
Spring Cloud Config
- Git 기반으로 Config 파일들을 관리

- Config Client를 탑재한 서버들은 가동 시 Config Server
에 접속하여 관련된 모든 Config를 내려받아 적용
Spring Cloud
Config
Server
API 
Server
Spring Cloud
Config Client
Git

Repo
API 
Server
Spring Cloud
Config Client
API 
Server
Spring Cloud
Config Client
Clone & Fetch
Config

FileConfig

FileConfig

FileConfig

FileConfig

FileConfig

FileConfig

FileConfig

FileConfig

FileConfig

File

11st New Architecture with Spring Cloud Config
Spring Cloud Config + Git 기반으로 Config 관리의 장점
- Config 의 수정 내용이 Git History로 남는다.

- 누가 / 언제 / 왜 이 Property를 고쳤는지를 확인하는 것이 서
버 문제 발생시 제일 어려운 점
- Embedded WAS를 사용하는 경우도 Infra Engineer들이 설정 변
경이 용이하다.

- Application 소스 Repo의 수정이 아닌 Config 전용 Repo의 수정

- 재빌드 없이 적용 가능
- Config 변경에 관한 Pull Request 및 Review가 가능하다.

- Config 변경 사항을 Pull Request로 생성

- 동료/리더 들의 Review를 통해 오류 방지

- Infra Engineer 와 개발자간 상호 협력

11st New Architecture - Monitoring
기존의 Monitoring Infra 이외의 추가 적인 Monitoring 요건 발생
Hystrix Monitoring

- Hystrix의 상태가 시스템 전체적으로 제일 중요한 모니터링
요소가 됨

- 각 Circuit Breaker의 통계 및 상태

- 각 Thread Pool의 통계 및 상태
Netflix Turbine을 통해 Hystrix Dashboard 구성 가능

11st New Architecture - Monitoring
Spring Boot Application의 각 상태 정보 조회 및
제어

- Spring Boot Admin Server을 통해 각 API
Server의 Actuator를 통한 정보 획득 및 제어
가능
- Spring Boot Admin Server를 자체로 확장 (진행중)

- Eureka의 세부 상태 조회 / 제어

- Zuul의 내부 상태 조회 / 제어

Lessons Learned
“Open Source를 100% 신뢰하지는 말것”
Documentation은 부실할 수 있으며,

Bug가 다수 존재할 수 있으며,

심지어 Bug가 발견되어도 아무도 급하게 Bug를 수정해
주지 않는다.
Source 보는 것을 두려워 하지 않으며, 확인이 필요한 중
요한 기능은 꼭 소스코드를 확인하라

Github의 Issues / Pull Request를 자주 확인하라

Lessons Learned
“Test, Test, Test”
Open Source의 현재 동작하던 기능이 Version Up과 함
께 사라지거나 다르게 동작할 수 있다.

Property는 쉽게 추가되거나 삭제될 수 있다.

대부분의 경우 우리는 이러한 변화를 인지하지 못한다.
Open Source를 통해 사용하는 주요 기능에 대해서
Integration 테스트를 작성하여 Version Up 이후에도 여전
히 원하는 대로 동작하는지 확인하라
ex) 틀린 주소를 주입하고 우리의 Fallback이 호출되는
지 확인하는 테스트

11st Legacy Application의 Spring Cloud 기반 MicroServices로 전환 개발 사례

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (11)

Similar to 11st Legacy Application의 Spring Cloud 기반 MicroServices로 전환 개발 사례

Similar to 11st Legacy Application의 Spring Cloud 기반 MicroServices로 전환 개발 사례 (20)

11st Legacy Application의 Spring Cloud 기반 MicroServices로 전환 개발 사례