마이크로서비스 아키텍처 구축 : 2장 마이크로서비스 모델링 방법

2.2 올바른 마이크로서비스 경계를 만드는 것은 무엇인가?

• 본질적으로 마이크로서비스는 모델과 모든 연관된 문제 사이에서 네트워크 기반의 상호작용이 이루어지더라도 모듈식 분해의 또 다른 형태일 뿐이다.
• 정보 은닉
  • 모듈 경계 뒤에 많은 세부 정보를 숨기려는 욕구
  • 장점
    • 개발 시간 향상
    • 모듈별로 이해 가능
    • 유연성 → 독립적인 변경 및 다양한 결합
• 응집력
  • 적은 장소에서 변경할 수 있는 방식으로 기능을 그룹으로 묶는다.
• 결합
  • 느슨한 결합을 통해 한 서비스를 변경할 때 다른 서비스를 변경하지 않아도 되도록 만든다.
  • 강한 결합 예시
    • 한 서비스를 다른 서비스에 단단히 결합하는 통합 방식
• 결합과 응집력의 연관성
  • 콘스탄틴 법칙
    • 응집력이 강하고 결합도가 낮으면 구조가 안정된다.
      • 경계 자체에 대한 안정성
  • 응집력은 경계 내부에 있는 사물 사이의 관계 (마이크로서비스)
    • 한 팀 안에서 사람들이 같은 목표로 협력하는 정도
  • 결합은 경계 건너에 있는 사물간의 관계
    • 다른 팀끼리 얼마나 자주, 복잡하게 의존하는가
  • 결합과 응집력은 결국 코드를 그룹화할 위치와 그 이유에 대해 다양한 절충한을 명확히 하는 한 가지 방법

2.3 결합 유형

• 궁극적으로 시스템에서 일부 결합은 피할 수 없으며 결합의 양을 줄이길 원한다.

• 도메인 결합

  • 첫 번째 마이크로서비스가 다른 마이크로서비스가 제공하는 기능을 사용
  • 정보 은닉으로 필요한 것만 공유하고 최소한의 데이터만 전송
  • 시간적 결합
    • 하나의 마이크로서비스가 작업을 완료하기 위해 동시간에 어떤 작업을 수행하는 다른 마이크로서비스가 필요한 상황
    • 시간적 결합을 피하는 방법
      • 메시지 브로커와 같은 비동기 통신

• 통과 결합

  • 데이터가 필요하다는 이유로 다른 마이크로서비스에 데이터를 전달하는 상황

  • 결합을 구현하는데 가장 많은 문제를 유발하는 형태 중 하나

    

  • 하위에서 데이터를 변경하면 상위에서 더 큰 변경을 일으킬 수 있다는 문제점
    - 배송에서 데이터 변경 시 주문 처리기, 창고 변경 필요

    

  • 중간자를 우회하지 않고 직접 통신

  • 도메인 결합이 늘어나지만 트레이드 오프를 생각

  • 그러나 배송 서비스를 사용해 패키지를 발송하기 전에 창고 서비스에 재고를 예약해야 하고 배송이 완료된 후 재고를 업데이트 해야한다.
    - 복잡성 증가

    

  • 배송 마이크로서비스가 배송 목록을 원한다는 사실을 숨기기 위해 창고 서비스가 계약의 일부로 필요한 정보를 받은 다음 로컬에서 배송 목록을 만든다.

  • 초기에는 강한 결합이 있었지만 현재는 더 쉬운 배포 단계 진행 가능

• 공통 결합

  • 둘 이상의 마이크로서비스가 공통 데이터 집합을 사용하는 경우
    • 공유 데이터베이스, 공유 메모리, 공유 파일 시스템 사용
  • 데이터 구조 변경 시 여러 마이크로서비스에 영향

• 내용 결합

  • 상위 서비스가 하위 서비스의 내부까지 도달해 서비스 내부 상태 변경하는 상황

    • 다른 마이크로서비스의 데이터베이스에 액세스해 직접 변경하는 외부 서비스

  • 소유권 경계선이 명확하지 않아 개발자가 시스템을 변경하기 더 어렵다.

    

  • 주문 처리기, 창고 모두 주문 서비스의 내부 데이터를 액세스하는 예시

    • 주문 테이블의 내부 데이터 구조가 외부에 노출
    • 해결 방법
      • 창고 서비스가 주문 서비스에 요청을 보내게 한다.

2.4 딱 도메인 주도 설계만큼

• 보편 언어

  • 의사소통을 돕기 위해 코드와 도메인 설명에 사용할 공통 언어

• 애그리거트

  • 실제 도메인 개념을 표현하는 객체들의 집합

  • 하나의 애그리거트는 하나의 마이크로서비스에서 관리
    - 상태 변경 시 비정상적 상태 전환이 불가능하도록 거절 가능

    

  • 서로 다른 마이크로서비스의 두 애그리거트 간 관계가 구현되는 방식의 예시

    • URL 저장
    • URL 스킴 저장
      • 예시 > soundcloud:tracks:123

• 경계 콘텍스트

  • 복잡성을 숨기는 비즈니스 도메인 내부의 명시적 경계

  • 은닉 모델

    • 외부 세계에 대한 명시적인 인터페이스는 노출하되 자신들만 알아야 하는 세부 사항은 은닉

  • 공유 모델

    

    • 둘 이상의 경계 콘텍스트에서 나타나는 개념을 다른 이름으로 부른다.

  • 크고 대분화된 콘텍스트 관점에서 분리하고 내부 콘텍스트에 따라 세분화한다.

• 이벤트 스토밍

  • 도메인 모델 개발을 합동 훈련으로 만들면 결국 공유된 통합 세계관을 갖게 된다.
    • 사용자, 특정 분야 전문자, PO
      • 이해 관계자의 머릿속에 있는 개념을 꺼내 공개

2.5 마이크로서비스를 위한 도메인 주도 설계 사례

• 마이크로서비스 맥락에서 DDD의 유용성
  • 경계 콘텍스트가 정보 은닉에 명시적으로 사용
    • 내부의 복잡성을 숨기면서도 더 넓은 시스템에 명확한 경계를 제시
  • 공통적인 보편 언어를 정의하여 마이크로서비스 엔드포인트 정의

2.6 비즈니스 도메인 경계에 대한 대안

• 변동성
  • 분해 작업을 수행하는 유일한 대안은 아니다.
  • 상황이 자주 변경되거나 변경해야하는 기능을 추출하는 것에는 합당하다.
    • 목적이 가장 적절한 메커니즘을 결정
• 데이터

  • 개인정보 및 보안 문제로 인해 데이터를 분리해야하는 경우가 많다.

    

• 기술
  • 다른 기술을 사용해야 할 필요성도 경계를 찾아내는 한 요소가 될 수 있다.
• 조직
  • 조직 구성에 따라 시스템 아키텍처의 평가가 결정되므로 서비스 경계를 정의하는데 있어 의사 결정의 핵심 부분으로 고려해야 한다.
  • 조직 구조가 바뀌었을 때 어떻게 되는지도 고려해야 한다. 최악의 경우 서비스 분리를 검토해야할 지도 모른다.

2.7 혼합 모델과 예외

• 현재 처한 특정 상황을 살펴보고 선택지를 선택한다.