마이크로서비스 아키텍처 구축 : 3장 모놀리스 분해

3.1 목표를 가져라

• 마이크로서비스는 목표가 아니다.
  • 합리적인 결정이어야 한다.
  • 최종 목표를 달성하는 더 쉬운 방법을 찾을 수 없는 경우에 선택
    • 로드밸런서 뒤에 기존 모놀리식 시스템의 복제본을 몇 개 추가하는 대안

3.2 점진적 마이그레이션

• 모놀리식을 한 번에 조금씩 떼어내는 것이 좋다.

3.3 모놀리스가 적인 경우는 드물다.

• 모놀리스가 없는 것에 집중하지 않고 아키텍처 변경이 가져올 혜택에 집중
• 모놀리스와 마이크로서비스가 공존하는 현실은 엉망이 아니다.
  • 요구와 지식의 변화에 따라 적응
• 조급한 분해의 위험성
  • 도메인에 대한 이해가 명확하지 않을 때는 마이크로서비스를 생성하는 데 위험이 따른다.

3.4 무엇을 먼저 나눌까?

• 마이크로서비스의 목적성을 파악
  • 애플리케이션 확장? → 현재 시스템의 부하 처리 능력 제한 기능
  • 출시 시간 단축? → 가장 자주 변경
  • CodeScene 같은 정적 분석 도구를 이용해 코드베이스의 불안정한 부분 찾기
  • 어떤 분해가 실행 가능한지 고려
    • 얼마나 결합되어있는지 확인
• 마이크로서비스로 추출하는 작업의 용이성, 추출의 이점 사이의 균형에 따라 결정
  • 난이도가 낮은 것부터 먼저 선택

3.5 계층별 분해

• 마이크로서비스에서 사용자 인터페이스로의 매핑은 1:1이 아닌 경우가 많다.
• 백엔드 기능의 분해와 UI 분해를 확인해보자
• 기존 위시리스트 코드와 데이터 추출 과정
• 코드 우선
  • 위시리스트 코드를 새 마이크로서비스로 옮기고 데이터는 모놀리식 데이터베이스에 남겨둔다.
    • 애플리케이션 코드는 추출됐지만 데이터 추출이 불가능하다고 판명되면 문제 발생
  • 단기적인 이익을 전달하기 쉽다.
  • 시작 전에 애플리케이션 코드, 데이터 모두 추출하는 방법 스케치
• 데이터 우선
  • 흔하지 않은 방식
    • 데이터를 깔금하게 분리 가능한지 여부가 불확실한 상황에서 유용
  • 데이터베이스에서 강제적인 데이터 무결성 손실이나 두 데이터 집합 간의 트랜잭션 작업 부족과 같은 문제는 사전에 처리

3.6 유용한 분해 패턴

• 교살자 무화과 패턴

  • 시간이 지남에 따라 기존 시스템을 새 시스템으로 감싸는 과정
    - 새 시스템이 이전 시스템의 기능을 점진적으로 더 많이 차지

    

  • 장점

    • 모놀리식 애플리케이션을 변경하지 않고 수행

• 병렬 실행

  • 모놀리식 기능 구현과 새로운 마이크로 서비스 구현을 나란히 실행해 같은 요청을 제공하고 결과 비교

• 기능 토글

  • 제품 기능을 켜거나 끄고 아니면 기능에 대한 2개의 다른 구현 사이를 오가게 하는 메커니즘

3.7 데이터 분해에 대한 우려

• 데이터베이스를 분리할 때 직면하는 문제

  • 성능
    • 조인 기능의 부재
      • 서비스 내에서 조인하면 성능이 느리다.
  • 데이터 무결성
    • 서로 다른 데이터베이스에 있으므로 데이터 모델의 무결성을 강제할 수 없다.
  • 트랜잭션
    • 여러 데이터베이스에 걸쳐 데이터를 분할하면 ACID 트랜잭션의 안정성을 잃게 된다.
      • 분산 트랜잭션으로 대응
  • 도구
    • 데이터베이스를 쉽게 변경할 수 있는 도구가 제한돼있다.
      • Flyway
        • 오픈소스 DB 마이그레이션 툴
  • 리포팅 데이터베이스

    • 외부 액세스용으로 설계된 전용 DB를 만들고 마이크로서비스가 내부 저장소의 데이터를 리포팅 데이터베이스로 푸시

      

  • 내부 상태 관리를 숨기면서 DB 데이터 제공
  • 핵심 사항
    • 정보 은닉을 위해 최소한의 데이터만 노출
    • 다른 마이크로서비스 엔드포인트와 동일하게 취급
      • 내부 정보를 변경하더라도 엔드포인트의 호환성 유지