마이크로서비스 패턴(2)

핵심내용

• 소프트웨어 아키텍처의 정의와 중요성
• 분해 패턴을 적용하여 비즈니스 능력 및 하위 도메인별로 애플리케이션을 서비스로 분해
• DDD의 경계 컨텍스트 개념을 활용하여 복잡하게 얽힌 데이터를 분해하기 더 쉽게 풀기

예시

• FTGO 마이크로서비스 전환 결정
• 애플리케이션을 기능에 따라 여러 서비스로 어떻게 정의할지에 대해 논의

내용

마이크로서비스 아키텍처란 무엇인가?

• 마이크로서비스 아키텍처의 핵심 사상은 기능 분해
• 소프트웨어 아키텍처
  • 구성 요소 및 그들 간의 디펜던시로 엮인 고수준의 구조물
  • 다차원적이므로 기술하는 방법도 다양
  • '~성(-ilities)'으로 끝나는 지표가 아키텍처에 의해 결정되기에 중요함
  • 마이크로서비스 아키텍처는 관리성, 테스트성, 배포성이 높은 애플리케이션을 구축하는 아키텍처 스타일

소프트웨어 아키텍처의 정의와 중요성

• 소프트웨어 아키텍처의 정의
  • 컴퓨팅 시스템의 소프트웨어 아키텍처는 소프트웨어 엘리먼트와 그들 간의 관계, 그리고 이 둘의 속성으로 구성된 시스템을 추론하는데 필요한 구조의 결합
  • 애플리케이션 아키텍처는 여러 파트(엘리먼트)로의 분해와 파트 간의 관계(연관성)
  • 분해가 중요한 이유
    • 업무와 지식을 분리하여 전문 지식을 보유한 사람들(또는 여러 팀)이 함께 생산적으로 작업 가능
    • 소프트웨어 엘리먼트가 어떻게 상호 작용하는지 알 수 있음
• 소프트웨어 아키텍처의 4+1 뷰 모델
  • 애플리케이션 아키텍처를 명쾌하게 표현하는 수단으로 4뷰는 중요한 아키텍처 측면을, 시나리오는 뷰의 여러 엘리먼트가 협동하는 과정을 명시
  • 소프트웨어 아키텍처를 바라보는 상이한 4뷰를 정의
  • 각 뷰는 아키텍처의 특정한 측면을 기술하고 특정 소프트웨어 엘리먼트와 그들 사이의 관계로 구성
  • 논리 뷰: 개발자가 작성한 소프트웨어 엘리먼트(클래스와 패키지 관계)(
  • 구현 뷰: 빌드 시스템의 결과물(JAR 파일이나 WAR 파일 등)
  • 프로세스 뷰: 런타임 컴포넌트(각 엘리먼트는 개별 프로세스, IPC는 프로세스 간 관계)
  • 배포 뷰: 프로세스가 머신에 매핑되는 방법
  • 시나리오: 뷰를 구동시키는 시나리오로 특정 뷰 내에서 얼마나 다양한 아키텍처 요소가 협동하여 요청을 처리하는지 기술
• 아키텍처의 중요성
  • 애픞리케이션 요건
    • 애플리케이션이 해야할 일을 정의한 기능 요건
    • '~성'으로 끝나는 서비스 품질 요건

아키텍처 스타일

• 계층화 아키텍처 스타일
  • 전형적인 아키텍처 스타일인 소프트웨어 엘리먼트를 계층별로 구성하는 계층화 아키텍처
  • 4뷰 적용 가능
    • 논리 뷰 적용 사례 : 3계층 아키텍처(표현, 비즈니스, 영속 계층)
  • 단점
    • 표현 계층이 하나뿐이다
    • 영속화 계층이 하나뿐이다
    • 비즈니스 로직 계층을 영속화 계층에 의존하는 형태로 정의
• 육각형 아키텍처 스타일
  • 논리 뷰를 비즈니스 로직 중심으로 구성하는 계층화 아키텍처 스타일의 대안
  • 비즈니스 로직이 어댑터에 의존하지 않음
    • 표현 계층 대신 비즈니스 로직을 호출하여 외부 요청을 처리하는 인바운드 어댑터 사용
    • 영속화 계층 대신 비즈니스 로직에 의해 호출되고 외부 애플리케이션을 호출하는 아웃바운드 어댑터 사용

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

• 모놀리식 아키텍처
  • 애플리케이션을 싱행/배포 가능한 단일 컴포넌트로 구성
  • 구현 뷰를 단일 컴포넌트로 구성한 아키텍처 스타일로 다른 뷰는 일체 등장하지 않음
  • 육각형 아키텍처 방식으로 구성한 논리 뷰를 가질 수 있음
• 마이크로서비스 아키텍처
  • 애플리케이션을 느슨하게 결함된, 독립적으로 배포 가능한 여러 서비스로 구성
  • 모놀리식 아키텍처와는 구현 뷰를 다수의 컴포넌트로 구성하는 차이점
  • 컴포넌트는 서비스로 각 서비스는 자체 논리 뷰와 아키텍처를 갖고 있음(전형적인 유각형 아키텍처)
• 서비스란?
  • 어떤 기능이 구현되어 단독 배포가 가능한 소프트웨어 컴포넌트
  • 클라이언트가 자신이 서비스하는 기능에 접근할 수 있도록 커멘드, 쿼리, 이벤트로 구성된 API 제공
  • 서비스 API는 내부 구현 상세를 캡슐화하여 모듈성 보장
• 느슨한 결함
  • 마이크로서비스 아키텍처 주요 특성 중 하나
  • 유지보수성, 테스트성을 높이고 애플리케이션 개발 시간을 단축하는 효과
• 공유 라이브러리의 역할
  • 서비스 코드 중복을 줄이는 것은 좋지만 의도치 않은 서비스 간 결함도를 유발하지 않도록 조심해야함
  • 바뀔 일이 거의 없는 기능은 라이브러리에 담아 쓰는 것이 좋음
  • 변경 가능성이 조금이라도 있는 기능이라면 별도의 서비스로 구현하는 것이 좋음
• 서비스 규모는 별로 중요하지 않다
  • 크기보다는 작은 팀이 가장 짧은 시간에 다른 팀과 협동하는 부분을 최소로 하여 개발 가능한 서비스를 설계해야 함

마이크로서비스 아키텍처 정의

시스템 작업 식별

• 고수준 도메인 모델 생성
• 시스템 작업 정의

서비스 정의: 비즈니스 능력 패턴별 분해

• 비즈니스 능력에 따라 서비스를 정의
• 비즈니스 능력은 곧 조직이 하는 일
• 비즈니스 능력 식별
• 비즈니스 능력을 여러 서비스로

서비스 정의: 하위 도메인 패턴별 분해

• DDD 하위 도메인별로 서비스를 정의

분해 지침

• 단일 책임 원칙
• 공동 폐쇄 원칙

서비스 분해의 장애물

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

서비스 API 정의

• 서비스 작업을 서비스로 배정
• 서비스 간 협동 지원에 필요한 API 확정

참고

• 마이크로서비스 패턴 자바(저 : 크리스 리처드슨)