Ch1. Monolithic vs Micro service

Overview

Definition

딱 맞는 정의라고 보기는 어렵지만 일반적으로 통용되는 내용으로 작성하여 보면
Monolithic은 단일 어플리케이션에서 다양한 서비스를 제공하는 구조이고,
Micro Service는 service 또는 도메인 중심으로 어플리케이션을 나눈 구조라고 볼 수 있습니다.

Micro service architecture의 대두

기존의 소규모 프로젝트에서는 Monolithic 구조로 진행을 하여도, 큰 문제는 없습니다.
하지만 점차 프로젝트 규모가 커지고, 이에 따른 요구사항이 커져감에 따라서 Monolithic 구조는 개발자에게 많은 피로감을 선사합니다.
크게 다음과 같은 문제점들이 있습니다.

1. 개발이 더디다 : IDE를 통한 빌드 시간, 코드를 고치고 실행에 걸리는 시간이 증가합니다.
2. 커밋 및 배포까지의 험난한 여정: 커밋 및 배포에 반영되는데에 있어서, 여러가지 내부 서비스들이 맞물리게 되면서 자연히 버그도 증가하고, 또한 배포 시기도 늦어지게 됩니다.
3. 확장의 어려움 : 실질적으로 하나의 코드에서 여러개의 서비스가 존재하지만 각각의 서비스들의 리소스 요건이 서로 맞지 않습니다. ( I/O intensive, CPU intensive jobs.... ), 이에 따라 낭비되는 리소스가 존재하거나 또는 리소스 조율에 신경을 써야합니다.
4. 확실하게 전달하기 어렵다. : 규모가 큰 프로젝트는 철저하게 테스트 하기도 어렵고, 결함 격리가 되지 않기 때문에 하나의 버그가 전체 프로젝트의 장애로 이루어질 수 있습니다.
5. 확장성의 어려움: 기존에 활용했던 기술스택을 변경하기 위해서는 전체 코드를 수정해야 합니다. 이는 규모가 커질수록 거의 불가능에 가까우며, 필요한 기술 스택을 적용하는데에 어려움을 만듭니다.

확장 큐브

아래는 The art of scalability에서 가져온 scale cube에 관련된 내용입니다.

주 내용은 어플리케이션을 확장하는 방법에 있어서 크게 3가지 축으로 설명을 합니다.

1. 다중 인스턴스 ( X축 ) : 인스턴스를 여러개 두고, 앞단에 Load balancer를 통한 확장 구조입니다.
2. 파티셔닝 ( Z축 ) : 데이터를 파티셔닝 하거나 또는 사용자 id 별로 요청을 분산하는 형태입니다.
3. 어플리케이션을 서비스로 분해 ( Y축 ) : 하나의 어플리케이션에서 존재하는 여러개의 서비스를 분해하는 형태입니다. 각각의 서비스들은 또한 X축, Z축으로 확장 가능합니다.

Micro service의 단점

위의 글을 본다면 Micro service가 만능인 것 같지만, 모든 상황에 부합하는 것이 아닙니다. Micro service의 단점은 아래와 같습니다.

1. 딱 맞는 서비스를 찾기 어려움 : 아키텍쳐를 Micro service로 가져간다는 것은 정답이 있는 것이 아니기 때문에, 이를 만들어나가는 과정은 쉽지 않습니다.
2. 복잡성: 서비스간 통신에 대한 정의, 지연 시간, 부분 실패한 서비스에 대한 처리 등등 고려할 것이 많습니다. 또한 서비스별 DB가 따로 구성이 되어 있기 때문에 여러개의 서비스에서 맞물리는 다중 트랜잭션을 구현하는 것은 쉽지 않을 수 있습니다 (이는 추후의 사가 패턴을 통해 해결합니다)
3. 운영 복잡도: 여러 인스턴스가 떠있으므로 프로덕션에서 관리해야되는 인스턴스 자체도 늘어납니다. 이를 위해서 플랫폼을 ( 스핀네이커, 클라우드 파운드리, 도커 스웜, 쿠버네티스 등등) 고도화 시켜 자동화시켜야 합니다.
4. 공통 기능: 여러 서비스에서 사용하는 공통 기능을 관리하게 될 경우 배포 계획 및 호환성 유지에 특별히 유의해야 합니다.

패턴 및 패턴 언어

패턴이란

특정한 상황에서 발생한 문제에 대한 재사용 가능한 해법

패턴 언어란

특정 영역 내부에서 문제를 해결하는 연관된 패턴의 집합 (Lattern Language: Towns, Buildings, Construction 도서 참조)

패턴 구조

• 강제 조항(forces): 문제 해결을 위해 반드시 처리해야 할 이슈
• 결과 맥락(resulting context): 패턴 적용 결과 장,단점 및 새로 발생한 이슈
• 연관 패턴(related patterns): 한 패턴과 다른 패턴의 고나계를 기술하는 영역
  • 선행자: 이 패턴을 필요하게 만든 선행 패턴
  • 후행자: 이 패턴으로 야기된 이슈를 해결하는 패턴
  • 대안: 대체 솔루션을 제공하는 패턴
  • 일반화: 문제를 해결하는 일반적인 솔루션에 해당하는 패턴
  • 세분화: 특정 패턴을 더 세부적으로 나타낸 형태

Microservice architecture pattern language overview

• 패턴 언어는 각각의 계층으로 도식화 할 수 있다. (한가지 관점만이 존재하는 것이 아님)
  • 아키텍쳐 패턴
  • 어플리케이션 인프라 패턴
  • 인프라 패턴
  • 통신 패턴
  • 서비스 배포 패턴
  • 데이터 쿼리 패턴
  • 관측성 패턴
    • 헬스 체크
    • 로그 수집
    • 분산 추적
    • 예외 추적
    • 어플리케이션 지표
    • 감사 로깅
  • 서비스 테스트 패턴
    • consumer driven contract test: 클라이언트가 의도한 대로 서비스가 동작하는지 확인
    • consumer-side contract test: 클라이언트와 서비스가 상호 통신 가능한지 확인
    • service component test: 서비스를 따로따로 테스트 진행
  • 횡단 관심사 처리 패턴
    • credential
    • Microservice Chassis pattern
  • 보안 패턴
    • identity
    • role
    • ex) JWT

출처

• 확장 큐브
• 마이크로 서비스 패턴