MSA로 전향한 11번가의 사례

 

📌Hystrix

netfilx가 만든 fault tolerance library로 주로 장애 전파 방지와 resilience 기능을 한다.

🎨적용 방법

1. Hystrix annotation 사용 - hystrix javanic, spring cloud netfix에 포함되어 있음

@HystrixCommand
public String anyMethod() {
}

1. Hystrix command 상속

pulbic class SampleCommand extends HystrixCommand<String> {
@Override
protected String run() {}
}

hystrix command를 호출할 때 벌어지는 일

1. 메소드를 intercept하여 대신 실행한다 - thread isolation
2. 메소드 실행 결과 성공 혹은 실패 발생 여부를 인스턴스 단위로 기록하고 통계낸다. 통계에 따라 circuit open 여부를 결정한다. - circuit breaker
3. 실패한 경우 사용자가 제공한 메소드를 대신 실행한다 - fallback
4. 특정 시간동안 메소드가 종료되지 않는 경우 exception을 발생한다 - timeout

😲기능적 관점에서 본 Hystrix의 주요 4가지 기능

Circuit Breaker

hystrix.command.<commandKey>. //circuitbreaker 선언 

metrics.rollingStats.timeInMilliseconds - Default 10초
circuitBreaker.requestVolumeThreshold - Default 20개
circuitBreaker.errorThresholdPercentage - Default 50%
circuitBreaker.sleepWindowInMilliseconds - Default 5초

hystrix command breaker는 한 프로세스 내에서 주어진 CommandKey 단위로 통계를 내고 동작한다.

10초 동안 20개 이상의 호출이 발생한 경우, 50%이상의 에러가 발생하면 5초간 호출 차단(circuit open)

일정 시간(10초) 경과 후에 단 한 개의 요청에 대해서 호출을 허용하며(Half open), 이 호출이 성공하면 → Circuit Close(호출 허용)

Fallback

fallback으로 지정된 메소드는 다음 경우에 원본 메소드를 대신 실행한다.

1. circuit open
2. any exception(HystrixBadRequestException 제외)
3. Semaphore/ ThreadPoolRejection
4. Timeout

@HystrixCommand(commandKey = "ExtDep1", fallbackMethod="recommendFallback")
//추천 서버 호출
public String anyMethod() {}
//미리 준비된 상품 목록
public String recommendFallback(){return "<미리 준비된 상품 목록>"}

🧨 exception 터지는 메소드를 찾기 어려울 수 있음. 비상식적으로 응답이 빠르다면 본 메소드(anyMethod)가 제대로 작동하는지 로깅해 볼 것.

🧨HystrixBadRequestException : 이 오류는 fallback을 실행하지 않으며 circuit open을 위한 통계에도 집계되지 않는다. 잘못된 파라미터 전달과 같은 method caller의 실수의 경우 이 예외를 사용한다. 만약 다른 예외로 처리한다면 circuit breaker 통계에 집계되어 circuit open이 되거나 fallback이 실행되어 개발 과정에 오류를 인지할지 못 할 수 있다.

Timeout

hystrix에서는 circuit breaker 단위로 설정할 수 있다.

metrics.rollingStats.timeInMilliseconds - Default 1초

보통은 1초 미만으로 응답이 와야 하지만, ui로직이 복잡하거나 등의 이유로 조금 더 늘려도 좋다.

Isolation

최대 개수 초과 시 semaphore rejection(fallback) 발생한다.

두 가지 isolation 방식을 단위 별로 지정 가능

semaphore

circuit breaker 1개당 1개의 semaphore 생성하고, command를 호출한 caller Thread에서 fallback 메소드를 실행한다. 🧨timeout이 제 시간에 발생하지 못한다는 단점이.. 이것은 스래드로 해결 가능

thread(default)

circuit breaker 별로 사용할 thread pool 지정(ThreadPoolKey)

command를 호출한 thread가 아닌, thread pool에서 fallback 메소드 실행.

---

📌Ribbon

netflix가 만든 software load balancer를 내장한 RPC library

-Client Load Balancer with HTTP Client

API콜러들에 자동으로 ribbon client가 붙게 되면, 인프라의 도움 없이도 다수의 서버 목록을 호출할 수 있다.

하지만 스프링 클라우드에서는 ribbon 클라이언트를 사용자가 직접 사용하지 않음! 스프링 클라우드에는 http 통신이 필요한 요소가 내장되어 있음. (api gateway, feign, restTemplate(@LoadBalanced))

---

📌Eureka

netflix가 만든 dynamic service discovery

-등록: 서버가 자신의 서비스 이름과 IP 주소, 포트를 등록

-조회: 서비스 이름을 갖고 서버 목록을 조회

Ribbon과 연동해 서버 목록을 조회할 수 있다.

Server 시작 시 eureka 서버에 자동으로 자신의 상태 등록

주기적 heartbeat으로 eureka server에 자신이 살아있음을 알림

server 종료 시 eureka 서버에 자신의 상태 변경 혹은 자신의 목록 삭제

eureka 상에 등록된 이름은 “spring.application.name”

Ribbon + Eureka in Spring cloud?

하나의 서버에는 eureka client 와 ribbon client가 함께 설정되면 spring cloud는 다음의 ribbon bean을 대체 (서버의 목록을 설정으로 명시하는 대신, eureka를 통해서 look up해옴)

1. serverList<Server>→ 변경: DiscoverEnableNIWSServerList
2. -기본: ConfigurationBasedServerList
3. IPing→ 변경: NIWSDiscoveryPing
4. -기본: DummyPing

🎈 API Gateway

msa 환경에서 api gateway의 필요성

1. single endpoint 제공
2. api 공통 로직 구현 - logging, authentication, authorization
3. traffic control - api quota, throttling

🔍문제 직면!

100% 자체 개발한 api gateway를 두고 spring cloud zuul을 도입해야 할까?

→yes!

이유 : 서버의 모든 호출은 hystrix command가 감싸서 호출한다. 그 안에는 ribbon client가 존재. 그 안에서 eureka client를 통해서 실제 서버를 호출한다.

api gateway를 사용해 endpoint 관리를 하지 않아도 되고, service에 오류가 나도 내 게이트 웨이는 죽지 않을 최후의 보루가 생긴다. circuit breaker와 isolation이 내 zuul의 한 군이 죽더라도 격리 시켜주기 때문이다. spring cloud zuul 에서 hystrix isolation은 semaphore을 기본으로 한다.

---

🎃장애 시나리오

hystrix, eureka, ribbon을 사용한 우리 system은 어느 정도 resilience 한 거야?

---

🎈 Spring Cloud Sleuth - Logging

spring cloud sleuth 사용 시 application 로그에 trace Id(uuid)가 함께 출력

with Zipkin !

hystrix with turbin !

MSA로 전향한 11번가의 사례

📌Hystrix

netfilx가 만든 fault tolerance library로 주로 장애 전파 방지와 resilience 기능을 한다.

🎨적용 방법

1. Hystrix annotation 사용 - hystrix javanic, spring cloud netfix에 포함되어 있음

@HystrixCommand
public String anyMethod() {
}

1. Hystrix command 상속

pulbic class SampleCommand extends HystrixCommand<String> {
@Override
protected String run() {}
}

hystrix command를 호출할 때 벌어지는 일

1. 메소드를 intercept하여 대신 실행한다 - thread isolation
2. 메소드 실행 결과 성공 혹은 실패 발생 여부를 인스턴스 단위로 기록하고 통계낸다. 통계에 따라 circuit open 여부를 결정한다. - circuit breaker
3. 실패한 경우 사용자가 제공한 메소드를 대신 실행한다 - fallback
4. 특정 시간동안 메소드가 종료되지 않는 경우 exception을 발생한다 - timeout

😲기능적 관점에서 본 Hystrix의 주요 4가지 기능

Circuit Breaker

hystrix.command.<commandKey>. //circuitbreaker 선언 

metrics.rollingStats.timeInMilliseconds - Default 10초
circuitBreaker.requestVolumeThreshold - Default 20개
circuitBreaker.errorThresholdPercentage - Default 50%
circuitBreaker.sleepWindowInMilliseconds - Default 5초

hystrix command breaker는 한 프로세스 내에서 주어진 CommandKey 단위로 통계를 내고 동작한다.

10초 동안 20개 이상의 호출이 발생한 경우, 50%이상의 에러가 발생하면 5초간 호출 차단(circuit open)

일정 시간(10초) 경과 후에 단 한 개의 요청에 대해서 호출을 허용하며(Half open), 이 호출이 성공하면 → Circuit Close(호출 허용)

Fallback

fallback으로 지정된 메소드는 다음 경우에 원본 메소드를 대신 실행한다.

1. circuit open
2. any exception(HystrixBadRequestException 제외)
3. Semaphore/ ThreadPoolRejection
4. Timeout

@HystrixCommand(commandKey = "ExtDep1", fallbackMethod="recommendFallback")
//추천 서버 호출
public String anyMethod() {}
//미리 준비된 상품 목록
public String recommendFallback(){return "<미리 준비된 상품 목록>"}

🧨 exception 터지는 메소드를 찾기 어려울 수 있음. 비상식적으로 응답이 빠르다면 본 메소드(anyMethod)가 제대로 작동하는지 로깅해 볼 것.

🧨HystrixBadRequestException : 이 오류는 fallback을 실행하지 않으며 circuit open을 위한 통계에도 집계되지 않는다. 잘못된 파라미터 전달과 같은 method caller의 실수의 경우 이 예외를 사용한다. 만약 다른 예외로 처리한다면 circuit breaker 통계에 집계되어 circuit open이 되거나 fallback이 실행되어 개발 과정에 오류를 인지할지 못 할 수 있다.

Timeout

hystrix에서는 circuit breaker 단위로 설정할 수 있다.

metrics.rollingStats.timeInMilliseconds - Default 1초

보통은 1초 미만으로 응답이 와야 하지만, ui로직이 복잡하거나 등의 이유로 조금 더 늘려도 좋다.

Isolation

최대 개수 초과 시 semaphore rejection(fallback) 발생한다.

두 가지 isolation 방식을 단위 별로 지정 가능

semaphore

circuit breaker 1개당 1개의 semaphore 생성하고, command를 호출한 caller Thread에서 fallback 메소드를 실행한다. 🧨timeout이 제 시간에 발생하지 못한다는 단점이.. 이것은 스래드로 해결 가능

thread(default)

circuit breaker 별로 사용할 thread pool 지정(ThreadPoolKey)

command를 호출한 thread가 아닌, thread pool에서 fallback 메소드 실행.

---

📌Ribbon

netflix가 만든 software load balancer를 내장한 RPC library

-Client Load Balancer with HTTP Client

API콜러들에 자동으로 ribbon client가 붙게 되면, 인프라의 도움 없이도 다수의 서버 목록을 호출할 수 있다.

하지만 스프링 클라우드에서는 ribbon 클라이언트를 사용자가 직접 사용하지 않음! 스프링 클라우드에는 http 통신이 필요한 요소가 내장되어 있음. (api gateway, feign, restTemplate(@LoadBalanced))

---

📌Eureka

netflix가 만든 dynamic service discovery

-등록: 서버가 자신의 서비스 이름과 IP 주소, 포트를 등록

-조회: 서비스 이름을 갖고 서버 목록을 조회

Ribbon과 연동해 서버 목록을 조회할 수 있다.

Server 시작 시 eureka 서버에 자동으로 자신의 상태 등록

주기적 heartbeat으로 eureka server에 자신이 살아있음을 알림

server 종료 시 eureka 서버에 자신의 상태 변경 혹은 자신의 목록 삭제

eureka 상에 등록된 이름은 “spring.application.name”

Ribbon + Eureka in Spring cloud?

하나의 서버에는 eureka client 와 ribbon client가 함께 설정되면 spring cloud는 다음의 ribbon bean을 대체 (서버의 목록을 설정으로 명시하는 대신, eureka를 통해서 look up해옴)

1. serverList<Server>→ 변경: DiscoverEnableNIWSServerList
2. -기본: ConfigurationBasedServerList
3. IPing→ 변경: NIWSDiscoveryPing
4. -기본: DummyPing

🎈 API Gateway

msa 환경에서 api gateway의 필요성

1. single endpoint 제공
2. api 공통 로직 구현 - logging, authentication, authorization
3. traffic control - api quota, throttling

🔍문제 직면!

100% 자체 개발한 api gateway를 두고 spring cloud zuul을 도입해야 할까?

→yes!

이유 : 서버의 모든 호출은 hystrix command가 감싸서 호출한다. 그 안에는 ribbon client가 존재. 그 안에서 eureka client를 통해서 실제 서버를 호출한다.

api gateway를 사용해 endpoint 관리를 하지 않아도 되고, service에 오류가 나도 내 게이트 웨이는 죽지 않을 최후의 보루가 생긴다. circuit breaker와 isolation이 내 zuul의 한 군이 죽더라도 격리 시켜주기 때문이다. spring cloud zuul 에서 hystrix isolation은 semaphore을 기본으로 한다.

---

🎃장애 시나리오

hystrix, eureka, ribbon을 사용한 우리 system은 어느 정도 resilience 한 거야?

---

🎈 Spring Cloud Sleuth - Logging

spring cloud sleuth 사용 시 application 로그에 trace Id(uuid)가 함께 출력

with Zipkin !

hystrix with turbin !

MSA로 전향한 11번가의 사례

📌Hystrix

netfilx가 만든 fault tolerance library로 주로 장애 전파 방지와 resilience 기능을 한다.

🎨적용 방법

1. Hystrix annotation 사용 - hystrix javanic, spring cloud netfix에 포함되어 있음

@HystrixCommand
public String anyMethod() {
}

1. Hystrix command 상속

pulbic class SampleCommand extends HystrixCommand<String> {
@Override
protected String run() {}
}

hystrix command를 호출할 때 벌어지는 일

1. 메소드를 intercept하여 대신 실행한다 - thread isolation
2. 메소드 실행 결과 성공 혹은 실패 발생 여부를 인스턴스 단위로 기록하고 통계낸다. 통계에 따라 circuit open 여부를 결정한다. - circuit breaker
3. 실패한 경우 사용자가 제공한 메소드를 대신 실행한다 - fallback
4. 특정 시간동안 메소드가 종료되지 않는 경우 exception을 발생한다 - timeout

😲기능적 관점에서 본 Hystrix의 주요 4가지 기능

Circuit Breaker

hystrix.command.<commandKey>. //circuitbreaker 선언 

metrics.rollingStats.timeInMilliseconds - Default 10초
circuitBreaker.requestVolumeThreshold - Default 20개
circuitBreaker.errorThresholdPercentage - Default 50%
circuitBreaker.sleepWindowInMilliseconds - Default 5초

hystrix command breaker는 한 프로세스 내에서 주어진 CommandKey 단위로 통계를 내고 동작한다.

10초 동안 20개 이상의 호출이 발생한 경우, 50%이상의 에러가 발생하면 5초간 호출 차단(circuit open)

일정 시간(10초) 경과 후에 단 한 개의 요청에 대해서 호출을 허용하며(Half open), 이 호출이 성공하면 → Circuit Close(호출 허용)

Fallback

fallback으로 지정된 메소드는 다음 경우에 원본 메소드를 대신 실행한다.

1. circuit open
2. any exception(HystrixBadRequestException 제외)
3. Semaphore/ ThreadPoolRejection
4. Timeout

@HystrixCommand(commandKey = "ExtDep1", fallbackMethod="recommendFallback")
//추천 서버 호출
public String anyMethod() {}
//미리 준비된 상품 목록
public String recommendFallback(){return "<미리 준비된 상품 목록>"}

🧨 exception 터지는 메소드를 찾기 어려울 수 있음. 비상식적으로 응답이 빠르다면 본 메소드(anyMethod)가 제대로 작동하는지 로깅해 볼 것.

🧨HystrixBadRequestException : 이 오류는 fallback을 실행하지 않으며 circuit open을 위한 통계에도 집계되지 않는다. 잘못된 파라미터 전달과 같은 method caller의 실수의 경우 이 예외를 사용한다. 만약 다른 예외로 처리한다면 circuit breaker 통계에 집계되어 circuit open이 되거나 fallback이 실행되어 개발 과정에 오류를 인지할지 못 할 수 있다.

Timeout

hystrix에서는 circuit breaker 단위로 설정할 수 있다.

metrics.rollingStats.timeInMilliseconds - Default 1초

보통은 1초 미만으로 응답이 와야 하지만, ui로직이 복잡하거나 등의 이유로 조금 더 늘려도 좋다.

Isolation

최대 개수 초과 시 semaphore rejection(fallback) 발생한다.

두 가지 isolation 방식을 단위 별로 지정 가능

semaphore

circuit breaker 1개당 1개의 semaphore 생성하고, command를 호출한 caller Thread에서 fallback 메소드를 실행한다. 🧨timeout이 제 시간에 발생하지 못한다는 단점이.. 이것은 스래드로 해결 가능

thread(default)

circuit breaker 별로 사용할 thread pool 지정(ThreadPoolKey)

command를 호출한 thread가 아닌, thread pool에서 fallback 메소드 실행.

---

📌Ribbon

netflix가 만든 software load balancer를 내장한 RPC library

-Client Load Balancer with HTTP Client

API콜러들에 자동으로 ribbon client가 붙게 되면, 인프라의 도움 없이도 다수의 서버 목록을 호출할 수 있다.

하지만 스프링 클라우드에서는 ribbon 클라이언트를 사용자가 직접 사용하지 않음! 스프링 클라우드에는 http 통신이 필요한 요소가 내장되어 있음. (api gateway, feign, restTemplate(@LoadBalanced))

---

📌Eureka

netflix가 만든 dynamic service discovery

-등록: 서버가 자신의 서비스 이름과 IP 주소, 포트를 등록

-조회: 서비스 이름을 갖고 서버 목록을 조회

Ribbon과 연동해 서버 목록을 조회할 수 있다.

Server 시작 시 eureka 서버에 자동으로 자신의 상태 등록

주기적 heartbeat으로 eureka server에 자신이 살아있음을 알림

server 종료 시 eureka 서버에 자신의 상태 변경 혹은 자신의 목록 삭제

eureka 상에 등록된 이름은 “spring.application.name”

Ribbon + Eureka in Spring cloud?

하나의 서버에는 eureka client 와 ribbon client가 함께 설정되면 spring cloud는 다음의 ribbon bean을 대체 (서버의 목록을 설정으로 명시하는 대신, eureka를 통해서 look up해옴)

1. serverList<Server>→ 변경: DiscoverEnableNIWSServerList
2. -기본: ConfigurationBasedServerList
3. IPing→ 변경: NIWSDiscoveryPing
4. -기본: DummyPing

🎈 API Gateway

msa 환경에서 api gateway의 필요성

1. single endpoint 제공
2. api 공통 로직 구현 - logging, authentication, authorization
3. traffic control - api quota, throttling

🔍문제 직면!

100% 자체 개발한 api gateway를 두고 spring cloud zuul을 도입해야 할까?

→yes!

이유 : 서버의 모든 호출은 hystrix command가 감싸서 호출한다. 그 안에는 ribbon client가 존재. 그 안에서 eureka client를 통해서 실제 서버를 호출한다.

api gateway를 사용해 endpoint 관리를 하지 않아도 되고, service에 오류가 나도 내 게이트 웨이는 죽지 않을 최후의 보루가 생긴다. circuit breaker와 isolation이 내 zuul의 한 군이 죽더라도 격리 시켜주기 때문이다. spring cloud zuul 에서 hystrix isolation은 semaphore을 기본으로 한다.

---

🎃장애 시나리오

hystrix, eureka, ribbon을 사용한 우리 system은 어느 정도 resilience 한 거야?

---

🎈 Spring Cloud Sleuth - Logging

spring cloud sleuth 사용 시 application 로그에 trace Id(uuid)가 함께 출력

with Zipkin !

hystrix with turbin !

MSA로 전향한 11번가의 사례

📌Hystrix

netfilx가 만든 fault tolerance library로 주로 장애 전파 방지와 resilience 기능을 한다.

🎨적용 방법

1. Hystrix annotation 사용 - hystrix javanic, spring cloud netfix에 포함되어 있음

@HystrixCommand
public String anyMethod() {
}

1. Hystrix command 상속

pulbic class SampleCommand extends HystrixCommand<String> {
@Override
protected String run() {}
}

hystrix command를 호출할 때 벌어지는 일

1. 메소드를 intercept하여 대신 실행한다 - thread isolation
2. 메소드 실행 결과 성공 혹은 실패 발생 여부를 인스턴스 단위로 기록하고 통계낸다. 통계에 따라 circuit open 여부를 결정한다. - circuit breaker
3. 실패한 경우 사용자가 제공한 메소드를 대신 실행한다 - fallback
4. 특정 시간동안 메소드가 종료되지 않는 경우 exception을 발생한다 - timeout

😲기능적 관점에서 본 Hystrix의 주요 4가지 기능

Circuit Breaker

hystrix.command.<commandKey>. //circuitbreaker 선언 

metrics.rollingStats.timeInMilliseconds - Default 10초
circuitBreaker.requestVolumeThreshold - Default 20개
circuitBreaker.errorThresholdPercentage - Default 50%
circuitBreaker.sleepWindowInMilliseconds - Default 5초

hystrix command breaker는 한 프로세스 내에서 주어진 CommandKey 단위로 통계를 내고 동작한다.

10초 동안 20개 이상의 호출이 발생한 경우, 50%이상의 에러가 발생하면 5초간 호출 차단(circuit open)

일정 시간(10초) 경과 후에 단 한 개의 요청에 대해서 호출을 허용하며(Half open), 이 호출이 성공하면 → Circuit Close(호출 허용)

Fallback

fallback으로 지정된 메소드는 다음 경우에 원본 메소드를 대신 실행한다.

1. circuit open
2. any exception(HystrixBadRequestException 제외)
3. Semaphore/ ThreadPoolRejection
4. Timeout

@HystrixCommand(commandKey = "ExtDep1", fallbackMethod="recommendFallback")
//추천 서버 호출
public String anyMethod() {}
//미리 준비된 상품 목록
public String recommendFallback(){return "<미리 준비된 상품 목록>"}

🧨 exception 터지는 메소드를 찾기 어려울 수 있음. 비상식적으로 응답이 빠르다면 본 메소드(anyMethod)가 제대로 작동하는지 로깅해 볼 것.

🧨HystrixBadRequestException : 이 오류는 fallback을 실행하지 않으며 circuit open을 위한 통계에도 집계되지 않는다. 잘못된 파라미터 전달과 같은 method caller의 실수의 경우 이 예외를 사용한다. 만약 다른 예외로 처리한다면 circuit breaker 통계에 집계되어 circuit open이 되거나 fallback이 실행되어 개발 과정에 오류를 인지할지 못 할 수 있다.

Timeout

hystrix에서는 circuit breaker 단위로 설정할 수 있다.

metrics.rollingStats.timeInMilliseconds - Default 1초

보통은 1초 미만으로 응답이 와야 하지만, ui로직이 복잡하거나 등의 이유로 조금 더 늘려도 좋다.

Isolation

최대 개수 초과 시 semaphore rejection(fallback) 발생한다.

두 가지 isolation 방식을 단위 별로 지정 가능

semaphore

circuit breaker 1개당 1개의 semaphore 생성하고, command를 호출한 caller Thread에서 fallback 메소드를 실행한다. 🧨timeout이 제 시간에 발생하지 못한다는 단점이.. 이것은 스래드로 해결 가능

thread(default)

circuit breaker 별로 사용할 thread pool 지정(ThreadPoolKey)

command를 호출한 thread가 아닌, thread pool에서 fallback 메소드 실행.

---

📌Ribbon

netflix가 만든 software load balancer를 내장한 RPC library

-Client Load Balancer with HTTP Client

API콜러들에 자동으로 ribbon client가 붙게 되면, 인프라의 도움 없이도 다수의 서버 목록을 호출할 수 있다.

하지만 스프링 클라우드에서는 ribbon 클라이언트를 사용자가 직접 사용하지 않음! 스프링 클라우드에는 http 통신이 필요한 요소가 내장되어 있음. (api gateway, feign, restTemplate(@LoadBalanced))

---

📌Eureka

netflix가 만든 dynamic service discovery

-등록: 서버가 자신의 서비스 이름과 IP 주소, 포트를 등록

-조회: 서비스 이름을 갖고 서버 목록을 조회

Ribbon과 연동해 서버 목록을 조회할 수 있다.

Server 시작 시 eureka 서버에 자동으로 자신의 상태 등록

주기적 heartbeat으로 eureka server에 자신이 살아있음을 알림

server 종료 시 eureka 서버에 자신의 상태 변경 혹은 자신의 목록 삭제

eureka 상에 등록된 이름은 “spring.application.name”

Ribbon + Eureka in Spring cloud?

하나의 서버에는 eureka client 와 ribbon client가 함께 설정되면 spring cloud는 다음의 ribbon bean을 대체 (서버의 목록을 설정으로 명시하는 대신, eureka를 통해서 look up해옴)

1. serverList<Server>→ 변경: DiscoverEnableNIWSServerList
2. -기본: ConfigurationBasedServerList
3. IPing→ 변경: NIWSDiscoveryPing
4. -기본: DummyPing

🎈 API Gateway

msa 환경에서 api gateway의 필요성

1. single endpoint 제공
2. api 공통 로직 구현 - logging, authentication, authorization
3. traffic control - api quota, throttling

🔍문제 직면!

100% 자체 개발한 api gateway를 두고 spring cloud zuul을 도입해야 할까?

→yes!

이유 : 서버의 모든 호출은 hystrix command가 감싸서 호출한다. 그 안에는 ribbon client가 존재. 그 안에서 eureka client를 통해서 실제 서버를 호출한다.

api gateway를 사용해 endpoint 관리를 하지 않아도 되고, service에 오류가 나도 내 게이트 웨이는 죽지 않을 최후의 보루가 생긴다. circuit breaker와 isolation이 내 zuul의 한 군이 죽더라도 격리 시켜주기 때문이다. spring cloud zuul 에서 hystrix isolation은 semaphore을 기본으로 한다.

---

🎃장애 시나리오

hystrix, eureka, ribbon을 사용한 우리 system은 어느 정도 resilience 한 거야?

---

🎈 Spring Cloud Sleuth - Logging

spring cloud sleuth 사용 시 application 로그에 trace Id(uuid)가 함께 출력

with Zipkin !

hystrix with turbin !

MSA로 전향한 11번가의 사례

📌Hystrix

netfilx가 만든 fault tolerance library로 주로 장애 전파 방지와 resilience 기능을 한다.

🎨적용 방법

1. Hystrix annotation 사용 - hystrix javanic, spring cloud netfix에 포함되어 있음

@HystrixCommand
public String anyMethod() {
}

1. Hystrix command 상속

pulbic class SampleCommand extends HystrixCommand<String> {
@Override
protected String run() {}
}

hystrix command를 호출할 때 벌어지는 일

1. 메소드를 intercept하여 대신 실행한다 - thread isolation
2. 메소드 실행 결과 성공 혹은 실패 발생 여부를 인스턴스 단위로 기록하고 통계낸다. 통계에 따라 circuit open 여부를 결정한다. - circuit breaker
3. 실패한 경우 사용자가 제공한 메소드를 대신 실행한다 - fallback
4. 특정 시간동안 메소드가 종료되지 않는 경우 exception을 발생한다 - timeout

😲기능적 관점에서 본 Hystrix의 주요 4가지 기능

Circuit Breaker

hystrix.command.<commandKey>. //circuitbreaker 선언 

metrics.rollingStats.timeInMilliseconds - Default 10초
circuitBreaker.requestVolumeThreshold - Default 20개
circuitBreaker.errorThresholdPercentage - Default 50%
circuitBreaker.sleepWindowInMilliseconds - Default 5초

hystrix command breaker는 한 프로세스 내에서 주어진 CommandKey 단위로 통계를 내고 동작한다.

10초 동안 20개 이상의 호출이 발생한 경우, 50%이상의 에러가 발생하면 5초간 호출 차단(circuit open)

일정 시간(10초) 경과 후에 단 한 개의 요청에 대해서 호출을 허용하며(Half open), 이 호출이 성공하면 → Circuit Close(호출 허용)

Fallback

fallback으로 지정된 메소드는 다음 경우에 원본 메소드를 대신 실행한다.

1. circuit open
2. any exception(HystrixBadRequestException 제외)
3. Semaphore/ ThreadPoolRejection
4. Timeout

@HystrixCommand(commandKey = "ExtDep1", fallbackMethod="recommendFallback")
//추천 서버 호출
public String anyMethod() {}
//미리 준비된 상품 목록
public String recommendFallback(){return "<미리 준비된 상품 목록>"}

🧨 exception 터지는 메소드를 찾기 어려울 수 있음. 비상식적으로 응답이 빠르다면 본 메소드(anyMethod)가 제대로 작동하는지 로깅해 볼 것.

🧨HystrixBadRequestException : 이 오류는 fallback을 실행하지 않으며 circuit open을 위한 통계에도 집계되지 않는다. 잘못된 파라미터 전달과 같은 method caller의 실수의 경우 이 예외를 사용한다. 만약 다른 예외로 처리한다면 circuit breaker 통계에 집계되어 circuit open이 되거나 fallback이 실행되어 개발 과정에 오류를 인지할지 못 할 수 있다.

Timeout

hystrix에서는 circuit breaker 단위로 설정할 수 있다.

metrics.rollingStats.timeInMilliseconds - Default 1초

보통은 1초 미만으로 응답이 와야 하지만, ui로직이 복잡하거나 등의 이유로 조금 더 늘려도 좋다.

Isolation

최대 개수 초과 시 semaphore rejection(fallback) 발생한다.

두 가지 isolation 방식을 단위 별로 지정 가능

semaphore

circuit breaker 1개당 1개의 semaphore 생성하고, command를 호출한 caller Thread에서 fallback 메소드를 실행한다. 🧨timeout이 제 시간에 발생하지 못한다는 단점이.. 이것은 스래드로 해결 가능

thread(default)

circuit breaker 별로 사용할 thread pool 지정(ThreadPoolKey)

command를 호출한 thread가 아닌, thread pool에서 fallback 메소드 실행.

---

📌Ribbon

netflix가 만든 software load balancer를 내장한 RPC library

-Client Load Balancer with HTTP Client

API콜러들에 자동으로 ribbon client가 붙게 되면, 인프라의 도움 없이도 다수의 서버 목록을 호출할 수 있다.

하지만 스프링 클라우드에서는 ribbon 클라이언트를 사용자가 직접 사용하지 않음! 스프링 클라우드에는 http 통신이 필요한 요소가 내장되어 있음. (api gateway, feign, restTemplate(@LoadBalanced))

---

📌Eureka

netflix가 만든 dynamic service discovery

-등록: 서버가 자신의 서비스 이름과 IP 주소, 포트를 등록

-조회: 서비스 이름을 갖고 서버 목록을 조회

Ribbon과 연동해 서버 목록을 조회할 수 있다.

Server 시작 시 eureka 서버에 자동으로 자신의 상태 등록

주기적 heartbeat으로 eureka server에 자신이 살아있음을 알림

server 종료 시 eureka 서버에 자신의 상태 변경 혹은 자신의 목록 삭제

eureka 상에 등록된 이름은 “spring.application.name”

Ribbon + Eureka in Spring cloud?

하나의 서버에는 eureka client 와 ribbon client가 함께 설정되면 spring cloud는 다음의 ribbon bean을 대체 (서버의 목록을 설정으로 명시하는 대신, eureka를 통해서 look up해옴)

1. serverList<Server>→ 변경: DiscoverEnableNIWSServerList
2. -기본: ConfigurationBasedServerList
3. IPing→ 변경: NIWSDiscoveryPing
4. -기본: DummyPing

🎈 API Gateway

msa 환경에서 api gateway의 필요성

1. single endpoint 제공
2. api 공통 로직 구현 - logging, authentication, authorization
3. traffic control - api quota, throttling

🔍문제 직면!

100% 자체 개발한 api gateway를 두고 spring cloud zuul을 도입해야 할까?

→yes!

이유 : 서버의 모든 호출은 hystrix command가 감싸서 호출한다. 그 안에는 ribbon client가 존재. 그 안에서 eureka client를 통해서 실제 서버를 호출한다.

api gateway를 사용해 endpoint 관리를 하지 않아도 되고, service에 오류가 나도 내 게이트 웨이는 죽지 않을 최후의 보루가 생긴다. circuit breaker와 isolation이 내 zuul의 한 군이 죽더라도 격리 시켜주기 때문이다. spring cloud zuul 에서 hystrix isolation은 semaphore을 기본으로 한다.

---

🎃장애 시나리오

hystrix, eureka, ribbon을 사용한 우리 system은 어느 정도 resilience 한 거야?

---

🎈 Spring Cloud Sleuth - Logging

spring cloud sleuth 사용 시 application 로그에 trace Id(uuid)가 함께 출력

with Zipkin !

hystrix with turbin !

MSA로 전향한 11번가의 사례

📌Hystrix

netfilx가 만든 fault tolerance library로 주로 장애 전파 방지와 resilience 기능을 한다.

🎨적용 방법

1. Hystrix annotation 사용 - hystrix javanic, spring cloud netfix에 포함되어 있음

@HystrixCommand
public String anyMethod() {
}

1. Hystrix command 상속

pulbic class SampleCommand extends HystrixCommand<String> {
@Override
protected String run() {}
}

hystrix command를 호출할 때 벌어지는 일

1. 메소드를 intercept하여 대신 실행한다 - thread isolation
2. 메소드 실행 결과 성공 혹은 실패 발생 여부를 인스턴스 단위로 기록하고 통계낸다. 통계에 따라 circuit open 여부를 결정한다. - circuit breaker
3. 실패한 경우 사용자가 제공한 메소드를 대신 실행한다 - fallback
4. 특정 시간동안 메소드가 종료되지 않는 경우 exception을 발생한다 - timeout

😲기능적 관점에서 본 Hystrix의 주요 4가지 기능

Circuit Breaker

hystrix.command.<commandKey>. //circuitbreaker 선언 

metrics.rollingStats.timeInMilliseconds - Default 10초
circuitBreaker.requestVolumeThreshold - Default 20개
circuitBreaker.errorThresholdPercentage - Default 50%
circuitBreaker.sleepWindowInMilliseconds - Default 5초

hystrix command breaker는 한 프로세스 내에서 주어진 CommandKey 단위로 통계를 내고 동작한다.

10초 동안 20개 이상의 호출이 발생한 경우, 50%이상의 에러가 발생하면 5초간 호출 차단(circuit open)

일정 시간(10초) 경과 후에 단 한 개의 요청에 대해서 호출을 허용하며(Half open), 이 호출이 성공하면 → Circuit Close(호출 허용)

Fallback

fallback으로 지정된 메소드는 다음 경우에 원본 메소드를 대신 실행한다.

1. circuit open
2. any exception(HystrixBadRequestException 제외)
3. Semaphore/ ThreadPoolRejection
4. Timeout

@HystrixCommand(commandKey = "ExtDep1", fallbackMethod="recommendFallback")
//추천 서버 호출
public String anyMethod() {}
//미리 준비된 상품 목록
public String recommendFallback(){return "<미리 준비된 상품 목록>"}

🧨 exception 터지는 메소드를 찾기 어려울 수 있음. 비상식적으로 응답이 빠르다면 본 메소드(anyMethod)가 제대로 작동하는지 로깅해 볼 것.

🧨HystrixBadRequestException : 이 오류는 fallback을 실행하지 않으며 circuit open을 위한 통계에도 집계되지 않는다. 잘못된 파라미터 전달과 같은 method caller의 실수의 경우 이 예외를 사용한다. 만약 다른 예외로 처리한다면 circuit breaker 통계에 집계되어 circuit open이 되거나 fallback이 실행되어 개발 과정에 오류를 인지할지 못 할 수 있다.

Timeout

hystrix에서는 circuit breaker 단위로 설정할 수 있다.

metrics.rollingStats.timeInMilliseconds - Default 1초

보통은 1초 미만으로 응답이 와야 하지만, ui로직이 복잡하거나 등의 이유로 조금 더 늘려도 좋다.

Isolation

최대 개수 초과 시 semaphore rejection(fallback) 발생한다.

두 가지 isolation 방식을 단위 별로 지정 가능

semaphore

circuit breaker 1개당 1개의 semaphore 생성하고, command를 호출한 caller Thread에서 fallback 메소드를 실행한다. 🧨timeout이 제 시간에 발생하지 못한다는 단점이.. 이것은 스래드로 해결 가능

thread(default)

circuit breaker 별로 사용할 thread pool 지정(ThreadPoolKey)

command를 호출한 thread가 아닌, thread pool에서 fallback 메소드 실행.

---

📌Ribbon

netflix가 만든 software load balancer를 내장한 RPC library

-Client Load Balancer with HTTP Client

API콜러들에 자동으로 ribbon client가 붙게 되면, 인프라의 도움 없이도 다수의 서버 목록을 호출할 수 있다.

하지만 스프링 클라우드에서는 ribbon 클라이언트를 사용자가 직접 사용하지 않음! 스프링 클라우드에는 http 통신이 필요한 요소가 내장되어 있음. (api gateway, feign, restTemplate(@LoadBalanced))

---

📌Eureka

netflix가 만든 dynamic service discovery

-등록: 서버가 자신의 서비스 이름과 IP 주소, 포트를 등록

-조회: 서비스 이름을 갖고 서버 목록을 조회

Ribbon과 연동해 서버 목록을 조회할 수 있다.

Server 시작 시 eureka 서버에 자동으로 자신의 상태 등록

주기적 heartbeat으로 eureka server에 자신이 살아있음을 알림

server 종료 시 eureka 서버에 자신의 상태 변경 혹은 자신의 목록 삭제

eureka 상에 등록된 이름은 “spring.application.name”

Ribbon + Eureka in Spring cloud?

하나의 서버에는 eureka client 와 ribbon client가 함께 설정되면 spring cloud는 다음의 ribbon bean을 대체 (서버의 목록을 설정으로 명시하는 대신, eureka를 통해서 look up해옴)

1. serverList<Server>→ 변경: DiscoverEnableNIWSServerList
2. -기본: ConfigurationBasedServerList
3. IPing→ 변경: NIWSDiscoveryPing
4. -기본: DummyPing

🎈 API Gateway

msa 환경에서 api gateway의 필요성

1. single endpoint 제공
2. api 공통 로직 구현 - logging, authentication, authorization
3. traffic control - api quota, throttling

🔍문제 직면!

100% 자체 개발한 api gateway를 두고 spring cloud zuul을 도입해야 할까?

→yes!

이유 : 서버의 모든 호출은 hystrix command가 감싸서 호출한다. 그 안에는 ribbon client가 존재. 그 안에서 eureka client를 통해서 실제 서버를 호출한다.

api gateway를 사용해 endpoint 관리를 하지 않아도 되고, service에 오류가 나도 내 게이트 웨이는 죽지 않을 최후의 보루가 생긴다. circuit breaker와 isolation이 내 zuul의 한 군이 죽더라도 격리 시켜주기 때문이다. spring cloud zuul 에서 hystrix isolation은 semaphore을 기본으로 한다.

---

🎃장애 시나리오

hystrix, eureka, ribbon을 사용한 우리 system은 어느 정도 resilience 한 거야?

---

🎈 Spring Cloud Sleuth - Logging

spring cloud sleuth 사용 시 application 로그에 trace Id(uuid)가 함께 출력

with Zipkin !

hystrix with turbin !