[MSA] 마이크로서비스 디자인 패턴

서비스 검색 Service discovery

문제

client가 마이크로서비스와 인스턴스를 찾을 수 있어야 한다. 인스턴스의 동적 IP 주소는 인스턴스가 시작될때 할당받아서 HTTP 기반 API를 호출하기 어려워진다.

 

해결

=> 사용 가능한 인스턴스와 서비스를 추적하는 새 컴포넌트(service discovery)를 추가한다.

 

- 방법 1: 클라이언트 측 라우팅으로 클라이언트가 서비스 검색 서비스를 이용해 요청을 보낼 만한 인스턴스를 찾게 한다.

 

- 방법 2: 서버 인프라에 리버스 프록시를 노출시켜 클라이언트를 대신해 적절한 인스턴스로 요청을 전달하게 한다.

 

ex. 넷플릭스 유레카, 넷플릭스 리본, 쿠버네티스 kube-proxy, 쿠버네티스 서비스 리소스

 

에지 서버 Edge server

문제

공개된 마이크로서비스는 공격으로부터 보호되어야 한다.

 

해결

=> 모든 요청이 거치는 시스템 환경에 Edge server를 추가한다.

=> Edge server는 요청을 검증하고 외부 요청을 허용하는 마이크로서비스로만 요청을 라우팅한다.

 

- Edge server는 리버스 프록시로 동작한다.

 

- 동적 로드 밸런싱 기능을 제공하기 위해 서비스 검색 컴포넌트와 통합될 수 있다.

 

ex. 스프링 클라우드, 스프링 시큐리티 OAuth, 쿠버네티스 Ingress Controller

 

리액티브 마이크로서비스 Reactive microservice

문제

Blocking I/O를 사용하면 동시 요청 수가 증가할 때 운영체제의 자원이 부족해 문제가 발생할 수 있다.

이런 상황은 지연을 유발하고, 다른 컴포넌트로의 연쇄 장애를 일으킨다.

 

해결

=> Non-Blocking I/O를 사용해 처리 결과를 기다리지 않게 해 스레드 사용량을 줄인다.

 

- 리액티브 프레임워크를 사용하면 Non-Blocking I/O에서 스레드 할당 없이도 동기식 요청을 실행할 수 있다.

 

- 탄력성 있게 설계하여 서비스가 중단되더라도 자가 치유를 통해 클라이언트가 서비스를 다시 사용할 수 있게 해야 한다.

 

ex. 스프링 Reactor, 스프링 WebFlux

 

구성 중앙화 central configuration

문제

모든 마이크로서비스 인스턴스의 정보를 한눈에 보기 어렵다.

 

해결

=> 구성 서버를 추가해 모든 마이크로서비스의 구성 정보를 저장하게 한다.

 

ex. 스프링 Config 서버, 쿠버네티스 ConfigMap, Secret

 

로그 분석 중앙화 centralized log analysis

문제

각 실행 환경에 로그 이벤트를 기록하면 전체 시스템 환경에서 발생하는 사건을 한눈에 보기 어렵다. 로그 파일이 분산되어 있어서 그렇다.

 

해결

=> 로그를 중앙화해 관리하는 컴포넌트를 추가한다.

 

- 로그 이벤트를 수집하고, 해석해서 중앙 데이터베이스에 저장한다.

 

ex. Elasticsearch, Kibana, Fluentd => 쿠버네티스에서 주로 사용한다.

 

분산 추적 distributed tracing

문제

외부 호출을 처리하는 동안 마이크로서비스 사이에서 흐르는 요청 및 메시지를 추적할 수 있어야 한다...

=> 여러 컴포넌트가 연관된 작업을 로깅하고자 할 때 추적이 어렵다.

 

해결

=> 관련된 모든 요청 및 로그 이벤트에 correlation ID를 넣어서 분류할 수 있게 한다.

 

ex. 스프링 클라우드 Sleuth, Zipkin, 이스티오 Jaeger

 

서킷 브레이커 circuit breaker

문제

마이크로서비스에서는 동기 통신으로 인한 연쇄 장애가 발생할 수 있다.

 

해결

=> 문제를 감지해 해당 서비스에 요청을 보내지 않도록 차단하는 서킷 브레이커를 추가한다.

 

 

 

- 문제가 감지되면 서킷을 열어 타임아웃을 무시하고 바로 실패하도록 한다.

 

- 반열림 서킷(half-open circuit)이라고 하는 장애 복구용 프로브(probe)를 사용한다. 프로브는 주기적으로 요청을 보내 서비스가 제대로 동작하는지 확인한다.

 

- 프로브가 서비스의 정상 동작을 감지하면 서킷을 닫아 요청을 받을 수 있게 한다.

 

ex. Resilience4j, Outlier detection

 

제어 루프 control loop

문제

인스턴스가 분산되어 있으면 중단된 인스턴스를 수동으로 감지하기 어렵다.

 

해결

=> 시스템 환경의 상태를 관찰하는 제어 루프 컴포넌트를 추가해 지정된 상태를 관찰하고 필요한 조치를 취한다.

 

ex. 컨테이너 기반 환경에서는 컨테이너 오케스트레이터를 사용해 제어 루프 패턴을 구현한다.

  -> 쿠버네티스 컨트롤러 매니저

 

모니터링 및 경고 중앙화 centralized monitioring and alarm

문제

분산된 인스턴스의 상태를 알기 어렵다.

 

해결

=> 모니터 컴포넌트를 추가해 서비스들의 상태를 한눈에 볼 수 있게 한다.

 

[출처] https://snoop-study.tistory.com/98