본문으로 바로가기

2. 분해전략

category 기술서적/마이크로 서비스 패턴 2025. 5. 8. 15:04
728x90
반응형
SMALL

2. 분해전략

아키텍처의 중요성

'~성' 으로 끝나는 서비스 품질 요건을 아키텍처는 충족시킬 수 있게 설계해야한다.

서비스 품질 요건은 확장성, 신뢰성과 같은 런타임 품질 외에도 관리성, 테스트성, 배포성처럼 개발 시점의 품질도 해당된다.

애플리케이션 아키텍처를 어떻게 선택하냐에 다라 이런 품질 요건을 얼마나 충족할 수 있을지 결정된다.



아키텍처 스타일 개요

계층형 아키텍처 스타일

  • 전형적인 아키텍처 스타일
  • 계층마다 명확히 정의된 역할을 분담하며 계층간 디펜던시는 아키텍터로 제한한다. 따라서 어떤 계층은 바로 하위에 있는 계층에 의존하거나, 하위에 위치한 어느 한 계층에 의존한다.
  • 표현/비즈니스/영속화 계층으로 구성된 아키텍처이다.

img


육각형 아키텍처 스타일

  • 기존 계층형 스타일의 비즈니스 로직에 있던 표현/데이터 접근 로직이 어댑터와 분리되었기 때문에 비즈니스 로직이 표현/데이터 접근 로직 어디에도 의존하지 않는다.
  • 때문에 비즈니스 로직만 따로 테스트 하기 쉽다.
  • 인바운드/아웃바운드 어댑터와 포트로 구성되어 있다.
  • 비즈니스 로직은 하나 이상의 포트를 지니며, 인바운드 어댑터는 외부 시스템의 요청을 처리하고 인바운드 포트를 호출한다. 아웃바운드 어댑터는 아웃바운드 포트를 통해 외부 시스템을 호출한다.

img


마이크로 서비스 아키텍처 스타일

  • 모놀리식과 달리 애플리케이션을 느슨하게 결합된, 독립적으로 배포 가능한 여러 서비스로 구성된다.
  • 여기서 각 컴포넌트는 곧 서비스이며, 서비스끼리 API를 통해서만 동작한다.
  • 서비스 별로 DB를 갖고있으며 공유하지 않는다. 때문에 락 블로킹 이슈는 없으나, 일관성을 유지가 복잡해지는 단점이 있다.
  • 유지보수성, 테스트성, 배포성 등 개발 단계의 품질 속성이 개선되며, 애플리케이션의 확장성도 향상된다.



마이크로 서비스 아키텍처

서비스 분해의 장애물

  • 네트워크 지연
  • 동기 통신으로 인한 가용성 저하
  • 여러 서비스에 걸쳐 데이터 일관성 유지
  • 데이터의 일관된 뷰 확보
  • 분해를 저해하는 만능 클래스

네트워크 지연

  • 분산 시스템의 고질적인 문제이다. 서비스를 여러 개로 나누면 서비스 간 왕복 횟수가 급증한다.
  • 값비싼 IPC 언어 수준의 메서드나 함수 호출로 대체하는 식으로 지연 시간을 줄여야 한다.

동기 IPC로 인한 가용성 저하

  • 서비스간 통신은 REST API를 동기 호출하는 것이 가장 쉬운 구현방법이지만, 타 서비스중 하나라도 다운될 경우 REST 같은 프로토콜은 가용성이 떨어진다.
  • 비동기 메시징으로 강한 결합도를 줄이고 가용성을 높이는 방법이 더 좋다.

여러 서비스에 걸쳐 데이터 일관성 유지

  • 여러 서비스에 있는 데이터를 업데이트 하는 시스템 작업이 있는경우 두 업데이트는 원자적으로 일어나야 한다.
  • 과거에는 커밋 방식의 2단계(2PC) 분산 트랜잭션을 많이 사용했지만, 요즘은 사가(saga)라는 방식으로 트랜잭션을 관리한다.
  • 사가는 메시징을 이용한 일련의 로컬 트랜잭션이다. 한가지 단점은 최종 일관성을 보장한다는 것이다.
  • 데이터를 원자적으로 업데이트해야 한다면 그 데이터를 하나의 서비스 내부에 두어야 하는데 이는 분해의 걸림돌이 된다.

일관된 데이터 뷰 확보

  • 모놀리식 애플리케이션에서는 ACID 트랜잭션 속성 덕분에 일관된 데이터 뷰가 반환되지만 MSA는 각 서비스별로 DB가 일관적이라고 해도 전역 범위에서 일관 데이터 뷰를 확보하기 힘들다. 이 역시 분해의 걸림돌이다.
  • 그러나 API Composition, CQRS+Event Sourcing 과 같은 해결방법이 있다.

만능 클래스는 분해의 걸림돌

  • 보통 이름도 Utils, Manager, CommonService, Handler 등으로 추상적이고 광범위하다.

  • "만능 클래스"는 MSA나 객체지향 설계에서 분해(모듈화, 분리)의 큰 걸림돌이 됩니다.

  • 재사용의 착각, "재사용을 위해 공통 클래스로 만들자"는 의도였지만, 실제로는 다양한 맥락을 억지로 수용하면서 설계가 망가짐

  • 도메인마다 고유한 로직을 분리하고, 절대 공유 클래스로 흘러들어가지 않게 관리하고, 정말로 의미 있고 재사용 가능한 경우에만 유틸 클래스로 분리하여 사용해야 한다.


MSA에서 각 서비스 인스턴스는 프로세스 형태이므로 반드시 IPC를 통해서 상호작용 해야한다.

다음 장은 REST, 메시징 등 다양한 IPC 옵션과 트레이드오프를 설명한다.

728x90
반응형
LIST

'기술서적 > 마이크로 서비스 패턴' 카테고리의 다른 글

4. 트랜잭션 관리: 사가  (0) 2025.05.13
3. 프로세스 간 통신  (0) 2025.05.09