[microservice] 아키텍처

개요

• 어플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법

Monolithic Architecture VS MicroService Architecture

• Monolithic Architecture
  • 하나의 서비스 또는 어플리케이션이 하나의 거대한 아키텍처를 지니는 설계 방식
  • 
• MicroService Architecture
  • 하나의 큰 어플리케이션을 여러 개의 작은 어플리케이션으로 나뉘는 설계 방식
  • 

장점

• 확장성
• 서비스 간의 의존성과 연관성이 최소화
• 배포
  • 서비스 별 개별 배포 가능
  • 배포 시 다른 서비스에 영향 없음
• 장애 전이성
  • 특정 서비스에 장애가 발생되어도 다른 서비스는 정상 동작
• 신규 서비스 추가 및 유지보수
  • 코드 분석 및 개발의 진입장벽 낮음
  • 해당 서비스에만 집중 가능
• 기술 스택 선택의 자유로움
  • 서비스간 프로토콜만 지킨다면 언어나 신기술 적용이 자유로움

단점

• 통신 비용 증가
  • 서비스 간의 통신이 필요
• 모니터링 포인트 증가
  • 서비스 개수 만큼의 모니터링 필요
• 트랜잭션
  • 서비스와 데이터베이스가 분산되면서 단일 DBMS의 트랜잭션 기능으로 해결 불가능한 경우 발생
• 테스트가 상대적으로 복잡

패턴

• SAGA pattern
  • 서비스들끼리 이벤트를 주고 받으면서 다음 트랙잭션 단계를 트리거
  • 실패 시 이전 서비스들에게 보상 이벤트를 발행하여 롤백 시도
  • Choreography based SAGA pattern
    • 서비스 별로 트랜잭션 관리 로직이 있어 실패한 서비스가 보상 이벤트를 발행
    • 서비스가 적은 시스템에 적합
    • 이벤트 추적이 어려움
    • 서로의 이벤트를 소비해야 하므로 순환 종속성 유의
  • Orchestration based SAGA pattern
    • 트랜잭션 처리를 위해 SAGA 인스턴스가 별도로 존재
    • 서비스들은 SAGA 인스턴스에 의하여 트랜잭션을 수행하
    • 실패 시 SAGA 인스턴스가 보상 이벤트를 발행
    • 서비스가 많은 시스템에 적합
    • 이벤트 추적이 쉬움
    • 관리 포인트 증가
• CQRS(Command and Query Responsibility Segregation) pattern
  • 커맨드와 쿼리를 구분
    • 커맨드
      • CRUD 중에 CUD
    • 쿼리
      • CRUD 중에 R
  • 대부분 데이터 변경과 데이터 조회로 구분이 되는데 하나의 도메인 모델로 처리하려고 하다보니 복잡도 증가를 해결하기 위해 등장
  • 적용 방안
    • 데이터베이스는 분리하지 않고 모델만 커맨드 모델과 쿼리 모델로 분리
      • 쉽게 적용 가능
      • 데이터베이스 관련 성능 향상은 불가
    • 데이터베이스 분리
      • 각각의 모델에 맞는 데이터베이스 선택
      • 데이터베이스 간의 동기화 문제 존재
    • 이벤트 소싱 적용
      • 모든 이벤트를 저장
      • 수정, 삭제가 없고 추가만 존재
• DDD(Domain Driven Design) pattern
  • 도메인 주도 설계