책너두 (도메인 주도 설계로 시작하는 마이크로서비스 개발) 8일차 (~66p)

요약

  • 애플리케이션 패턴에 대해 이해함.
    • UI 컴포지트 패턴 또는 마이크로 프런트엔드
    • 마이크로서비스 통신 패턴
    • 저장소 분리 패턴

메모

2.4.3 애플리케이션 패턴

  • 지금부터는 실제로 개발자가 구현해야 할 애플리케이션 영역으로 넘어와서 마이크로서비스 애플리케이션을 구성하기 위한 패턴을 살펴본다.
  • 먼저, 프런트엔드를 구성하기 위한 패턴은 어떻게 해야하는 가?
    • 프런트엔드가 한 덩어리 일 경우 과연 마이크로서비스 기반 시스템의 장점인 서비스의 독립적인 변경과 배포가 가능한가?
    • 불가능하다.
    • 이전의 백엔드가 모노리스였을 때 겪었던 문제를 프런트엔드의 모노리스 서비스도 동일하게 겪을 수밖에 없다.

UI 컴포지트 패턴 또는 마이크로 프런트엔드

  • 위 프런트엔드 모노리스의 해결 방안은 UI 컴포지트(Composite) 패턴마이크로 프런트엔드(Micro Frontend)라고 하는 패턴임.
    • 프런트엔드도 백엔드 마이크로서비스처럼 기능별로 분리하고 이를 조합하기 위한 프레임(frame) 형태의 부모 창을 통해 각 프런트엔드를 조합해서 동작하게 함.
    • 이 부모 서비스는 틀만 가지고 있고, 실제 각 기능 표현은 마이크로 프런트엔드 조각이 구현하게 함.
  • ex) p61 아마존닷컴 온라인 몰 사례 참고

마이크로서비스 통신 패턴

  • 프런트와 백엔드, 백엔드 간의 마이크로 서비스 호출에는 어떤 방법을 사용하는 가?
  • 동기 통신 방식
    • 클라이언트에서 서버 측에 존재하는 마이크로서비스 REST API 를 호출할 때 사용하는 기본 통신 방법임.
    • 다양한 클라이언트 채널 연계나 라우팅 및 로드 밸런싱을 원활하게 하기 위해 중간에 API 게이트웨이를 둘 수도 있음.
    • 클라이언트에서 백엔드 서비스 호출에는 동기 호출 방식을 사용함.
    • 백엔드 마이크로서비스 간의 호출도 맨 먼저 검토해야할 방법은 REST API 같은 동기식 호출임.
      • 하지만 호출을 받은 마이크로서비스에 장애가 생긴다면, 요청을 보낸 서비스는 반응이 올 때 까지 기다리게 되고, 반응이 오지 않으면 계속 기다리면서 재호출하게 됨.
      • 여러 서비스 간의 연계를 통해 업무를 처리하는 마이크로서비스 구조에서 이 같은 상황에서 장애가 연쇄적으로 발생할 수 있음.
      • 또, 서비스가 다른 서비스를 호출해서 얻은 정보를 이용해서 기능을 제공한다는 의미는 해당 서비스 간의 의존관계가 높다는 것임.
  • 비동기 통신 방식
    • 메시지 기반의 비동기 호출을 하면, 메시지를 보낸 다음, 응답을 기다리지 않고 다음 일을 처리함.
      • 물론 보낸 결과가 어떻게 됐는지 응답을 받지 않으므로 동기식처럼 완결성을 보장할 수 없음.
      • 이를 보장하기 위한 메커니즘으로 아파치 카프카, 래빗엠큐, 액티브엠큐와 같은 메시지 브로커를 활용한다.
        • 메시지 생산자는 메시지 브로커에 메시지를 전달하고 메시지를 받는 소비자는 메시지 브로커와 연결되어 메시지를 받는다.
        • 그런데 여러 서비스에서 전달한 메시지를 처리하는 메시지 브로커 자체에 부하가 생길 수 있음.
          • 이 경우, 메시지 브로커는 메시지 처리 규모에 따라 확장 가능함.
    • 메시지 브로커에 의해 중계되기 때문에 서로 통신하는 서비스들이 물리적으로 동일한 시스템에 위치할 필요가 없음.
      • 서로의 프로세스를 공유할 필요도 없음.
      • 동일한 시간대에 동시에 동작하지 않아도 됨.
    • 느슨한 연계를 지향하는 아키텍처임.

저장소 분리 패턴

  • 마이크로서비스를 독립적으로 수정 및 배포하기 위한 저장소 형태는 어떻게 구성해야 하는가?
  • 기존 모노리스 시스템의 저장소는 통합 저장소임.
    • 이러한 구조를 데이터 중심 애플리케이션이라 함.
    • 특정 관계형 데이터베이스 벤더에 구속되고 복잡해져 유지보수가 어려워짐
    • 성능 문제가 발생했을 때 SQL 구문 튜닝이나 저장소 증설(스케일 업)에 의존할 수밖에 없음.
  • 이를 보완할 수 있는 마이크로서비스 패턴인 저장소 분리 패턴을 살펴보자.
    • 각 마이크로서비스는 각각의 비즈니스를 처리하기 위한 데이터를 직접 소유해야 한다는 것을 의미함.
    • 정보 은닉
      • 자신이 소유한 데이터는 다른 서비스에 직접 노출하지 않고 각자가 공개한 API를 통해서만 접근할 수 있음.
    • 폴리글랏 저장소
      • 저장소가 격리돼 있기 때문에 각 저장소를 자율적으로 선택할 수 있음.
    • 영향도
      • 이 같은 제약이 데이터를 통한 변경의 파급효과를 줄여 서비스를 독립적으로 만듦.
  • 그러나, 마이크로서비스별로 기능을 분리하고 저장소를 격리함에 따라 이전에 생기지 않는 문제가 생김.
    • 즉, 여러 개의 분산된 서비스에 걸쳐 비즈니스 처리를 수행해야하는 경우 비즈니스 정합성 및 데이터 일관성을 어떻게 보장할 것인지에 대한 문제를 생각해야 함.

댓글

Designed by JB FACTORY