01. 마이크로서비스 소개
마이크로서비스 소개#
- 마이크로서비스가 모든 문제를 해결하는 해결책은 아니다.
독립된 소프트웨어 컴포넌트의 장점#
MSA에서의 각 컴포넌트는 독립적으로 배포, 업그레이드할 수 있다.
다른 컴포넌트와 상관 없이 여러 인스턴스로
Scale-Out할 수 있다. (앞단에 보통 LB를 둔다.)
독립된 소프트웨어 컴포넌트의 단점#
컴포넌트의 새 인스턴스를 추가하면 수동으로 로드밸런서를 구성하고 새 노드를 수동으로 설정해주어야한다. ( k8s service )
다른 시스템에서 문제가 발생할 경우 오류가 전이된다. 이런 현상을
Chain of Failure라고 부른다. ( Circuit Breaker )각 컴포넌트들의 최신화를 위한 많은 유지보수 비용이 들어간다. ( 개발자 많이 뽑으셈 )
모니터링이 더 어렵다. ( Grafana )
분산된 여러 컴포넌트에서의 로그 파일을 수집하고 로그 컴포넌트를 상호 연결시키는 것이 어렵다. ( EFK )
마이크로서비스의 정의#
빠르게 개발해 지속적으로 배포할 수 있어야 한다.
수동 혹은 자동으로 쉽게 스케일링할 수 있어야 한다.
MSA에서 각 컴포넌트는 아무것도 공유하지 않는 아키텍처를 유지해야한다. 즉 MSA의 각 컴포넌트들은 DB를 공유하지 않는다.
명확한 인터페이스를 통해서만 통신한다. 동기식 서비스를 사용하거나, API를 이용한 메시징 방식을 사용할 수 있는데, 버전 관리 전략에 따라 문서화되어야한다.
런타임으로 배포되어야 한다.
MSA 인스턴스는 Stateless 해야한다. 모든 마이크로서비스 인스턴스가 마이크로서비스로 들어오는 요청을 처리할 수 있다.
마이크로서비스의 문제#
동기식 통신을 사용하는 다수의 소형 컴포넌트들은
Chain of Failure를 일으킬 수 있다.다수의 소형 컴포넌트를 최신 상태로 유지하는건 어렵다. (아 개발자 많이 뽑으라고 ㅋㅋ)
로그를 수집하고 분석하기가 어렵다.
하드웨어 자원 사용량 분석도 어렵다.
소형 컴포넌트들을 수동으로 관리하는건 비용이 많이 들고 오류도 발생하기 쉽다.
MSA 디자인 패턴#
디자인 패턴은 오래된 개념이다. 특정 상황에 발생하는 문제에 대해 재사용 가능한 해결책을 정리한 것이다.
Service Discovery
Edge Server
Reactive Microservice
Central Configuration
Centralized Log Analysis
Distributed Tracing
Circuit Breaker
Control Loop
Centralized Monitoring And Alarm
Service Discovery#
- Service Discovery 패턴은 다음과 같은 문제점과 솔루션이 존재한다.
선행 문제점#
- 클라이언트가 MSA와 그 인스턴스를 찾을 수 있어야한다.
Service Discovery의 해결책#
- 보통은 서버측에서
Reverse Proxy를 노출시켜서 클라이언트의 요청을 처리할 적절한 인스턴스로 요청을 전달한다.
Edge Server#
- Edge Server 패턴은 다음과 같은 문제점과 솔루션이 존재한다.
선행 문제점#
MSA의 컴포넌트는 일부만 외부에 공개하고 그 외의 MSA는 외부에서 접근하지 못하도록 숨기는게 일반적이다.
그 이유는 악의적인 클라이언트의 요청으로부터 보호하기 위함이다.
Edge Server의 해결책#
- 모든 요청이 거치는 새 컴포넌트 (Edge Server)를 추가한다.
Reactive Microservice#
- Reactive Microservice 패턴은 다음과 같은 문제점과 솔루션이 존재한다.
선행 문제점#
- 블로킹 I/O 기반의 API를 사용하면 동시 요청 수가 증가하거나 요청과 관련된 컴포넌트가 증가하면 OS의 가용 쓰레드가 부족해 응답 시간이 늦어지거나 서버가 중단될 수 있다.
Reactive Microservice의 해결책#
- 논블로킹 I/O를 사용해 DB나 다른 MSA가 처리하기를 기다리는 동안 스레드가 할당되지 않게 한다.
Central Configuration#
- Central Configuration 패턴은 다음과 같은 문제점과 솔루션이 존재한다.
선행 문제점#
- 애플리케이션은 일반적으로 환경 변수나 설정 파일에 담긴 구성 정보와 함께 배포되는데 이를 한눈에 보려면 어떻게 해야하나?
Central Configuration의 해결책#
- 모든 MSA의 구성 정보를 저장하는 새 컴포넌트를 추가한다.(?)
Central Configuration에 대한 여담#
- 이 문제는 실제 우리 회사에서도 있는데, 실제 배포된 서비스에서 배포된
application.properties를 확인하고 싶은데 방법이 없음. 어떻게 하면 좋으려나? ( API로 만들어놔야 하나..? )
Centralized Log Analysis#
- Centralized Log Analysis 패턴은 다음과 같은 문제점과 솔루션이 존재한다.
선행 문제점#
- 로컬 머신에 애플리케이션의 로그가 쌓이는데 이를 어떻게 관리해야하나?
Centralized Log Analysis의 해결책#
- 중앙화된 로그 관리 컴포넌트를 개발한다.
Distributed Tracing#
- Distributed Tracing 패턴은 다음과 같은 문제점과 솔루션이 존재한다.
선행 문제점#
- 외부 호출을 처리하는 동안 MSA 내부에 흐르는 요청 및 메시지를 추적할 수 있어야 한다.
Distributed Tracing의 해결책#
- 요청과 메시지에 대한
Correlation ID를 넣어야하고 모든 로그 이벤트에 이 ID가 있어야한다.
Circuit Breaker#
- Circuit Breaker 패턴은 다음과 같은 문제점과 솔루션이 존재한다.
선행 문제점#
동기 방식으로 상호 통신하는 MSA는 연쇄 장애가 발생할 여지가 있다.
하나의 MSA가 응답하지 않으면 MSA의 클라이언트에게 응답하지 않게 된다.
Circuit Breaker의 해결책#
서비스에 문제가 감지되면 시간 초과를 무시하고 바로 실패하도록 서킷을 연다.
half-open-circuit반열림 서킷이라고도 하는 장애 복구형probe를 사용한다. 즉 서비스가 정상 동작하는지 주기적으로 요청을 보낸다.프로브가 서비스의 정상 동작을 감지하면 서킷을 닫는다.
이런 기능은 시스템 환경을 탄력적으로 만들어 자가 치유를 가능케 하는 매우 중요한 기능이다.
Control Loop#
- Control Loop 패턴은 다음과 같은 문제점과 솔루션이 존재한다.
선행 문제점#
- 다수의 MSA에서는 중단되거나 지연된 인스턴스를 수동으로 감지하고 대처하는 것이 어렵다.
Control Loop의 해결책#
- MSA 컴포넌트들의 상태를 관찰하는 새 컴포넌트인
Control Loop를 시스템 환경에 추가하여 관찰하게 한다.
Centralized Monitoring And Alarm#
- Centralized Monitoring And Alarm 패턴은 다음과 같은 문제점과 솔루션이 존재한다.
선행 문제점#
응답 시간이나 하드웨어 자원 사용량이 지나치게 높은 경우 문제의 근본 원인을 찾는 것이 매우 어렵다.
MSA별 하드웨어 자원 사용량을 분석할 수 있어야 한다.
Centralized Monitoring And Alarm의 해결책#
- 인스턴스가 사용하는 자원에 대한
Metric을 수집하는 새로운 컴포넌트를 시스템 환경에 추가한다.
Reference#
스프링으로 하는 마이크로서비스 구축