스프링으로 하는 마이크로서비스 구축 리뷰 (1) - 마이크로서비스 소개

마이크로서비스 정의

마이크로서비스는 아래의 두 가지 목표를 달성하고자 일체형 애플리케이션을 작은 컴포넌트로 나누는 것이다.

• 빠르게 개발해 지속적으로 배포할 수 있어야 한다.
• 수동 혹은 자동으로 쉽게 스케일링할 수 있어야 한다.

그렇다면 독자적인 작은 컴포넌트는 어떤 조건으로 나누어야 하는 것일까? 각각의 작은 컴포넌트는 독자적인 업그레이드와 스케일링이 가능해야한다. 그렇기위해선 다음과 같은 기준들을 충족해야한다.

• 아무것도 공유하지 않은 아키텍처를 유지해야 한다. 마이크로서비스는 데이터베이스의 데이터를 공유하지 않는다.
• 명확한 인터페이스를 통해서만 통신해야 한다. 동기 서비스를 사용하거나 API를 이용한 메시징 방식을 사용할 수 있는데, 이때 사용하는 메시지 형식은 버전 관리 전략에 따라 안정적으로 문서화되고 개선돼야 한다.
• 개별적인 런타임 프로세스로 배포해야 한다. 각 마이크로서비스 인스턴스는 도커 컨테이너와 같이 독립된 런타임 프로세스로 실행해야 한다.
• 마이크로서비스 인스턴스는 상태가 없다. 따라서 모든 마이크로서비스 인스턴스가 마이크로서비스로 들어오는 요청을 처리할 수 있다.

 

마이크로서비스의 장점과 단점

• 장점
  • 개별적으로 배포, 업그레이그가 가능하다.
  • 명확한 API를 사용해 기존 시스템과 통합이 용이하다.
  • 다른 컴포넌트와 종속성없이 스케일 아웃이 가능하다.
• 단점
  • 로드 밸런스 설정과 노드 설정을 수동으로 해야 하는 상황이라면?
  • 통신 시 발생한 오류가 플랫폼으로 전이된다. 이를 연쇄 장애(chain of failure)라고 한다.
  • 컴포넌트 인스턴스를 일관성 있게 최신 상태로 유지하는 작업에 반복적인 수작업이 발생, 품질 문제로 이어진다.
  • 플랫폼 상태를 모니터링 하기가 쉽지 않다.
  • 로그 관리도 일체형보다 어려워진다.

 

문제 해결을 위한 디자인 패턴

• 서비스검색
  • 클라이언트가 마이크로서비스와 그 인스턴스를 찾을 수 있게 만드는 패턴
  • 예: 쿠버네티스의 서비스와 리소스
• 에지 서버
  • 일부 서비스만 외부에 공개하고 그 외의 서비스는 숨기기 위한 패턴
  • 예: 쿠버네티스의 인그레스 컨트롤러
• 리액티브 마이크로서비스
  • 대용량 트래픽을 대응하기 위해 논블로킹 I/O를 사용하여 스레드 할당 없이 동기식 요청을 실행하는 패턴
  • 예: 스프링 리액터와 스프링 웹플럭스
• 구성 중앙화
  • 실행 중인 모든 마이크로서비스 인스턴스의 구성 정보를 한 눈에 확인하고 업데이트 되도록 하기 위한 패턴
  • 예: 쿠버네티스의 컨피그 맵과 시크릿
• 로그 분석 중앙화
  • 여러 나누어져 있는 컴포넌트의 로그를 효율적으로 관리하기 위한 패턴
  • 예: ELK 스택
• 분산 추적
  • 마이크로서비스 사이에 흐르는 요청 및 메세지를 효율적으로 추적하기 위한 패턴
  • 예: 스프링 클라우드 슬루스와 집킨
• 서킷 브레이커
  • 동기 방식 통신으로 인해 발생하는 연쇄 장애를 막기위한 패턴
  • 예: Resilience4J
• 제어 루프
  • 다수의 마이크로서비스 인스턴스의 장애를 자동으로 감지하여 대처하는 패턴
  • 예: 쿠버네티스의 컨트롤러 매니저
• 모니터링 및 경고 중앙화
  • 응답 시간, 하드웨어 자원 사용량 등의 문제를 효율적으로 찾기 위한 패턴
  • 예: 그라파나와 프로메테우스