[microservice-upLearning] Ⅰ. MSA로의 여정

Ⅰ. Microservice

Microservice 란 무엇인가

레퍼런스

Microservice는 단일 어플리케이션을 작은 규모의 서비스 조합으로 나워 개발하는 방식이다. 각 서비스는 자체 프로세스로 실행되며 가벼운 매커니즘으로 통신한다. 비지니스 기능을 중심으로 구축되며 완전 자동화된 배포 기계를 통해 독립적으로 배포 가능하다.

위 영상과 아티클의 핵심 : Microservice의 9가지 특성

  1. Componentization via Services
  2. Organized around Business Capabilities
  3. Products not Projects
  4. Smart endpoints and dumb pipes
  5. Decentralized Governance
  6. Decentralized Data Management
  7. Infrastructure Automation
  8. Design for failure
  9. Evolutionary Design

이 특성들이 하나로 모여서 전체적인 솔루션을 형성한다고 함

다른 의견도 있음

Microservice는 제한된 범위의 독립적으로 배포 가능한 구성요소이며 메시지 기반 통신으로 상호 운용성을 지원한다. MSA는 높은 수준으로 자동화된 엔지니어링 스타일로 기능별 Microservice로 구성된 진화할 수 있는 소프트웨어 시스템이다

두 정의의 차이

  • 제한된 범위, 상호 운용성, 메시지 기반 통신에서 약간의 차이
  • Microservice와 이를 가능케 하는 MSA를 구별

기술의 세계에서 이름은 중요하다 : 복잡한 개념을 간단하게 전달하게 하므로

마이크로서비스는 다음의 특성이 있는 소프트웨어 아키텍처 스타일을 의미

  1. 어플리케이션 아키텍처는 주로 네터워크에서 호출 가능한 ‘서비스’로 구성됨
  2. 서비스의 크기(또는 경계)는 중요 설계요소이다. 설계 요소는 런타임, 설계 시간, 사람을 포함한다
  3. 목표 달성을 위해 sw 시스템 조직, 일하는 방식을 전체적으로 최적화

마이크로서비스는 항상 조정 비용의 관점에서 생각해야 한다

  • ‘나의 결정이 팀의 조정 비용을 최소화 하는가’ - 스스로에게 늘 질문

마이크로서비스 어려운 부분

  • 긴 피드백 루프

    • 오늘 내린 결정의 문제가 오랜 시간 지난 후에 나타날 수 있음
    • 처음 시작시 특정 라이브러리를 사용하기로 결정한 것이 시간이 지남에 따라 해당 라이브러리
      최신화 유지가 힘들고 큰 문제가 될 수도 있음
    • 핵심은 문제가 발생하기 전까지 특정 결정의 영향 판단이 어려움
  • 복잡한 시스템 구조

    • 마이크로서비스는 기본적으로 복잡한 적응형 시스템
    • 이는 시스템의 각 파트가 어떤 식으로든 다른 부분에 영향
    • 복잡성 때문에 설계가 어렵고 득보다 실이 클 수 있음
  • 분석 마비

    • 위의 2가지로 인한 상태
    • 내려야 하는 결정은 매우 영향력이 크나 측정이 어려움
    • 비지니스 성과 달성하는 구축 선택 대신 선택에 대한 끝없는 고민만 반복

    ADR : architecture decision record
    좋은 ADR

    • 컨텍스트
      • 목표? 해결할 문제는? 제약은? → 해당 내용 요약을 제공해야한다
      • 결정의 근거와 기록의 업데이트가 필요한 이유를 이해가능
    • 대안
      • 결정을 내릴 수 있는 선택지가 없으면 좋은 결정이 아니다
      • 좋은 ADR은 선택지가 우엇인지 이해하는데 도움이 되어야 한다
      • 결정이 내려진 시점의 상황과 ‘선택 공간’을 이해가능
    • 선택
      • 결정의 핵심
      • 모든 ADR은 선택을 문서화한다
    • 영향
      • 결정에 따른 결과가 있으며 해당 결과의 중요 내용은 ADR에 문서화 되어야 한다

LADR : 마크다운 텍스트 형식

1
2
3
4
5
6
7
8
9
10
# OPM1: 결정을 추적하기 위해 ADR을 사용한다

## 상태
승인됨

## 콘텍스트

## 결정

## 결과
  • 컨텍스트에는 결정을 내리기 위한 문제, 제약, 배경을 설명
    1
    2
    3
    4
    ## 콘텍스트
    MSA는 복잡하기에 많은 결정이 필요하다
    결정에 대한 결과 재평가를 위해 중요한 결정을 트래킹할 방법도 필요하다
    우리는 새로운 sw 설치가 필요없는 가벼운 텍스트 기반 솔루션을 원한다
  • 콘텍스트를 작성한 후에는 실제 결정을 기록하는 단계
    1
    2
    3
    4
    5
    6
    7
    8
    ## 결정
    우리는 Michael Nygard의 LADR을 사용하기로 결정했다.
    텍스트 기반이며 가볍다
    각 LADR을 텍스트 파일에 보관하고 파일을 코드처럼 관리한다.

    또한 다음과 같은 사항의 도입을 고려했다
    - 프로젝트 관리 도구 사용 : 새로운 도구 설치 원하지 않으므로 선택 x
    - 비공식 또는 입소문 정보 보관 : 신뢰 불가로 선택 x
  • 결과 문서화
    1
    2
    3
    ## 결과
    - 주요 결정을 위한 결정 기록을 작성한다
    - 결정 기록 파일을 관리하기 위한 소스 코드 관리 솔루션이 필요

Related POST

공유하기