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와 함께 운영

위의 과정을 반복ApplicationModernizationStrategy

“Strangler Application”by Martin Fowler

Strangler Application Pattern in 11st - Hybrid MSA

WAR

Front/MobileWAS

WAR

Front/MobileWAS

RESTAPI

ZuulAPI Gateway

전시 API

Server

상품 API

Server

추천 API

Server

추천Service

XXXAPI

Server…

Eureka Server

Config Server

Admin Server

?

Challenges

Best Practice - Netflix OSS & Spring Cloud

Hystrix

Eureka

Ribbon

EvCache

Spectator

Archaius

….

Spring Cloud

Config

Stream

Sleuth

Contract

….….

Technical Background

Spring CloudBasic Component

Hystrix

Circuit Breaker

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() { URI uri = URI.create("http://172.32.1.22:8090/recommended"); String result = this.restTemplate.getForObject(uri, String.class); 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"); String result = this.restTemplate.getForObject(uri, String.class); return result; }

@HystrixCommand

public String anyMethodWithExternalDependency2() { URI uri = URI.create("http://172.32.1.22:8090/mainrecommend"); String result = this.restTemplate.getForObject(uri, String.class); return result; }

@HystrixCommand

Circuit Breaker는 어떤 단위로 생성되는가 ? - Default로 @HystrixCommand가 명시된 메소드 단위


Circuit의 단위 명시하기 - CommandKey

- “CommandKey”는 Circuit Breaker의 단위이며 여러개의 메소드를 같은 Key를 명시함으로써 하나의 Circuit을 사용하게 할 수 있다.

public String anyMethodWithExternalDependency1() { URI uri = URI.create("http://172.32.1.22:8090/recommended"); String result = this.restTemplate.getForObject(uri, String.class); return result; }

@HystrixCommand(commandKey = “ExtDep1”)

public String anyMethodWithExternalDependency2() { URI uri = URI.create("http://172.32.1.22:8090/mainrecommend"); String result = this.restTemplate.getForObject(uri, String.class); return result; }

@HystrixCommand(commandKey = “ExtDep1”)

- 즉, A 메소드와 B 메소드가 같은 Circuit Breaker를 사용한다면, A와 B의 에러 비율이 함께 통계내어지고, Circuit이 오픈되면 함께 차단된다.


public String anyMethodWithExternalDependency1() { URI uri = URI.create("http://172.32.1.22:8090/recommended"); String result = this.restTemplate.getForObject(uri, String.class); 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-2012

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

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

Ribbon

Client Load Balancer

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이 마음대로 구성 가능

Ribbo


단순한 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

Ribbo

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”

EurekaClient

Eureka Server

Service A ip1:8081

Service B

Service C

Service D

API Caller “가”

EurekaClient

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

EurekaClient

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

EurekaClientEurekaClient

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


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를 통해서 호출 실패 시 재시도


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/MobileWAS

WAR

Front/MobileWAS

RESTAPI ?

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/MobileWAS

WAR

Front/MobileWAS

RESTAPI

전시 API

Server

상품 API

Server

추천 API

Server

추천Service

XXXAPI

Server…

Eureka Server

Config Server

Admin Server

ZuulAPI Gateway

Hystrix + Eureka+ Ribbon

모든 Legacy Application으로 부터의 호출은 Zuul API Gateway를 통해서 호출

11st New Architecture - Internal Server to Server호출

WAR

Front/MobileWAS

RESTAPI

전시 API

Server

상품 API

Server

추천 API

Server

추천Service

XXXAPI

Server…

Eureka Server

Config Server

Admin Server

ZuulAPI Gateway


새롭게 분리된 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/MobileWAS

RESTAPI

전시 API

Server

상품 API

Server

추천 API

Server

추천Service

XXXAPI

Server…

Eureka Server

Config Server

Admin Server

ZuulAPI Gateway


Spring Cloud Feign


모든 내부 호출에도 Hystrix, Ribbon, Eureka를 적용하여 Server 간 직접 호출한다.

11st New Architecture - 외부 서버로의 호출

WAR

Front/MobileWAS

RESTAPI

전시 API

Server

상품 API

Server

추천 API

Server

추천Service

XXXAPI

Server…

Eureka Server

Config Server

Admin Server

ZuulAPI Gateway


페인

페인

신규 API 서버로 부터 기존의 외부 서버로의 호출

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

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

11st New Architecture - 외부 서버로의 호출

WAR

Front/MobileWAS

RESTAPI

전시 API

Server

상품 API

Server

추천 API

Server

추천Service

XXXAPI

Server…

Eureka Server

Config Server

Admin Server

ZuulAPI Gateway


페인

페인

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

EurekaServer

Client(Caller)

Server1

Server2

Server3

Server4

배포시스템

(Jarvis)1. 배포 대상 서버

Eureka 상태 변경 요청- Out Of Service

3. 서버 배포 및 재가동

Ribbo

Eurek

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

APIServer

Spring Cloud Config Client

GitRepo

APIServer


APIServer


Clone & Fetch

Config 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의 내부 상태 조회 / 제어

Project Vine

Lessons Learned

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이 호출되는지 확인하는 테스트

The End

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

Software

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