마이크로 서비스 애플리케이션의 아키텍처 정리

마이크로 서비스 인 액션 3장을 읽고 정리해보았습니다.

아키텍처

좋은 아키텍처란 변경이 쉬운 소프트웨어다. 모놀리식 애플리케이션에서는 아키텍처가 애플리케이션 자체의 경계로 제한된다. 반면에 마이크로 서비스 애플리케이션에서는 크기와 범위 측면에서 계속 진화하는 것에 대해 계획을 세운다. 마이크로 서비스는 다른 마이크로 서비스들과 함께 개발, 배포, 실행할 수 있는 환경에 존재한다. 아키텍처는 이런 전체환경을 포함해야 한다.

마이크로 서비스 애플리케이션을 위한 4계층 모델은 다음과 같다.

플랫폼

개발, 운영, 배포를 지원하는 도구와 인프라스트럭처를 제공한다. 튼튼한 플랫폼 계층은 전체적인 구현 비용을 절감하고 전반적인 안전성을 개선하며 신속한 서비스 개발을 가능하게 한다.

• 로드밸런서, 가상머신 같은 기본적인 인프라스트럭처를 포함해 서비스가 실행되는 배포 환경
• 서비스 운영을 관측하기 위한 로깅과 모니터링
• 새로운 서비스와 버전을 테스트하기 위한 일관되고 반복적인 파이프라인
• 네트워크 제어, 보안 등 안전한 운영을 위한 지원
• 서비스 상호작용을 지원하는 커미뉴케이션 채널과 서비스 디스커버리

서비스

플랫폼 위에 서비스 간의 상호 협력을 통해 비즈니스, 기술적 역량을 제공한다.

• 비즈니스 역량
  • 가치를 창출하고 비즈니스 목표를 만족하기 위해 조직이 수행하는 것.
• 기술적 역량
  • 공유된 기술적 기능을 구현해 다른 서비스를 지원한다.

경계

클라이언트가 경계를 통해 애플리케이션과 상호작용한다. 내부의 복잡도와 변경을 추상화해 제공한다. 또한 서비스 계층 내에서 도메인을 분리하기 위해 경계 계층을 사용할 수 있다.

• API 게이트웨이
  • 서비스지향 백엔드에 대해 단일 클라이언트 유입 지점을 제공한다.
  • 요청을 하위 서비스에 전달하고 응답을 변환한다.
• 프런트엔드를 위한 백엔드(BFF, Backends For Frontends)
  • API 게이트웨이 접근 방식의 변형이다. API 게이트웨이가 여러 애플리케이션의 구성 지점으로 작동하면 점점 더 많은 책임을 지기 시작한다.
  • BFF는 각 클라이언트 유형을 위해 API 게이트웨이를 사용한다.
  • 게이트웨이가 더욱 작고 간단해져서 개발에 집중할 수 있게 된다.
• 컨슈머-주도 게이트웨이
  • 여러 API를 개발하는 대신 컨슈머가 필요한 응답의 형태를 정의할 수 있게 해주는 Super set API를 구축한느 것이다.
  • GraphQL을 사용하면 이것이 가능하다.

클라이언트

웹사이트, 모바일 앱 같은 클라이언트 애플리케이션을 말하는데 마이크로 서비스 백엔드와 상호작용한다. 사용자에게 애플리케이션의 인터페이스를 제공한다.

• 모놀리식 프런트엔드
  • 일반적인 접근방식
• 마이크로 프런트엔드
  • 웹 어플리케이션에서 최근 부상하는 추세.
  • 독립적인 패키지로 배포할 때 조합될 수 있는 구성요소로 UI를 제공하는 것이다.

커뮤니케이션

마이크로 서비스는 서로 커뮤니케이션 한다. 요청을 주고받기 위해 결정한 방법이 애플리케이션의 형태를 결정하게 된다.

동기식 메시지

다음 작업을 시작하기 전에 현재 작업의 결과 또는 성공/실패를 아는 시나리오에 적합하다.

• 단점
  • 서비스가 반드시 협력자를 알아야 하므로 서비스 간에 단단한 결합이 생긴다.
  • 강력한 브로드캐스트 모델 또는 게시-구독 모델이 없어서 병렬 작ㅇ버을 수행하는데 제약이 있다.
  • 응답을 기다리는 동안 코드 수행을 멈춘다. 스레드 또는 프로세스 기반 서버 모델에서 이 모델은 용량을 고갈시키고 장애를 전파시킬 수 있다.
  • 과도한 동기식 메시지 사용은 깊은 의존성 체인을 만들어서 전반적인 호출 경로의 장애 가능성을 증가시킬 수 있다.

비동기식 메시지

이벤트를 선언해서 새로운 요구사항을 다루도록 시스템을 쉽게 확장할 수 있다. 새로운 서비스는 기존 서비스를 변경하지 기존 이벤트를 사용해 만들 수 있다. 이 스타일은 서비스 간의 좀 더 유연한 발전을 가능하게 하고 느슨한 결합을 생성한다. 일반적으로 비동기메시징은 이벤트를 수신하고 이벤트 컨슈머에게 전달하는 독립적인 구성요소인 커뮤니케이션 브로커를 요구한다. 종종 이벤트 백본이라고 불리기도 한다. 브로커로 사요용되는 일반적인 도구에는 카프카, 래빗엠큐, 레디스가 있다.

• 단점
  • 비동기식 상호작용은 전체적인 시스템의 행동이 명확하게 일련의 연속성을 따지 않기 때문에 추론하기 더욱 어렵다.
  • 시스템의 행동이 점점 더 예측하기 어려우므로 발생된 사건을 추적할 수 있는 모니터링 시스템에 투자해야 한다.

가장 일반적인 2가지 이벤트 기반 패턴은 Job queue와 Publish-Subscribe패턴이 있따.

• Job queue
  • 워커가 Queue에서 일감을 꺼내 실행한다.
  • 일감은 운용하는 워커의 수에 상관없이 한 번만 처리된다.
• Public-Subscribe
  • 임의의 리스너를 위해 이벤트를 발생시킨다. 이벤트를 수신한 모든 리스너는 이벤트에 따라 적절하게 행동한다.
  • 서비스가 이벤트를 발행하고 누가 이를 처리하는지 관리하지 않는 경우에 이상적인 패턴이다.

서비스 디스커버리

서비스는 커뮤니케이션하기 위해 서로를 발견해야 한다. 플랫폼 계층이 이를 제공한다. 가장 기초적인 방법은 로드 밸런서를 활용하는 것이다. 좀 더복잡한 시나리오에는 한계가 있어 더 집노된 방식은 컨설과 같은 레지스트리를 이용하는 것이다.

Sources

• 마이크로 서비스 인 액션 - 모건 부르스, 파울로 페레이라