이 글은 한빛미디어 Microservices Up & Running 책을 보고 작성한 글임을 알려드립니다.

1. 마이크로서비스란 무엇인가?

마이크로서비스에 대한 공식적인 정의는 없습니다. 하지만 마틴 파울러와 제임스 루이스는 다음과 같이 설명했습니다.

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

이 글의 핵심은 마이크로서비스의 9가지 특성입니다. 이것은 마이크로서비스의 주요한 아키텍쳐 원칙입니다.

• 서비스를 통한 컴포넌트화
• 비즈니스 기능 중심의 조직 구성
• 거버넌스 분산
• 인프라 자동화
• 프로젝트가 아닌 제품 중심
• 스마트 엔드포인트
• 덤 파이프
• 장애 대응 설계
• 진화하는 설계

반면 Microservice Architecture(O’Reilly, 2016)에서는 다음과 같이 마이크로서비스를 정의합니다.

마이크로서비스는 제한된 범위의 독립적으로 배포 가능한 구성 요소이며 메시지 기반 통신으로 상호 운용성을 지원한다. 마이크로서비스 아키텍쳐는 높은 수준으로 자동화된 엔지니어링 스타일이며 기능별 마이크로서비스로 구성된 진화할 수 있는 소프트웨어 시스템이다.
이전에 말한 정의와 비교했을 때, 대체로 비슷해 보이지만, 제한된 범위, 상호 운용성, 메시지 기반 통신에서 약간의 차이가 존재합니다.

기술의 세계에서 이름은 복잡한 개념을 간단하게 전달하는 역할을 하기 때문에 중요합니다. 마이크로서비스라는 이름은 다음과 같은 세 가지 일반적인 설계 특성이 있는 소프트웨어 아키텍처 스타일을 의미합니다. 이러한 특성만을 가지고도 마이크로서비스 시스템을 충분히 식별할 수 있습니다.

• 애플리케이션 아키텍처는 주로 네트워크에서 호출할 수 있는 ‘서비스’로 구성된다.
• 서비스의 크기(또는 경계)는 중요한 설계 요소다. 설계 요소는 런타임, 설계 시간, 사람을 포함한다.
• 목표를 달성하기 위해 소프트웨어 시스템, 조직, 일하는 방식을 전체적으로 최적화한다.

평소 마이크로서비스에 대한 저의 정의는 그저 서비스의 분리, 다중 컨테이너, 쿠버네티스, 프로세스 간 통신 정도로 요약할 수 있었습니다. 위와 같은 다양한 정의를 보고 마이크로서비스의 영역은 방대하단 점을 깨달았고, 시스템 뿐이 아닌, 조직 전반적인 협업과정과 의사결정과정도 포함된다는 것을 깨달았습니다. (갈길은 멀다..) 또한 정의 자체 부터 공식적인 부분이 없기 때문에 마이크로서비스에 관한 다양한 지식이 있어야 효율적인 아키텍처를 구성할 수 있다고 생각했습니다.

2. 마이크로서비스의 이점(조정 비용 절감 측면)

마이크로서비스의 다양한 이점이 있습니다. 하지만 그 중에서 조정 비용의 절감이 가장 큰 장점입니다. 또한 책에서는 마이크로서비스 아키텍처가 안정성과 속도를 동시에 높일 수 있는 접근 방식이라 주장합니다.

2-1. 마이크로서비스가 조정 비용 문제

복잡한 프로젝트를 수행하는 여러 팀은 일반적으로 독립적인 로드맵에 따라 독립적인 속도로 시스템에서 각자 맡은 부분을 구현합니다. 하지만, 이러한 부분에 있어서 각 파트 별로 의존성 문제를 위해 주기적으로 통합되어야 합니다. 즉 조정 비용이 생깁니다. 조정을 무시하고 계획대로 의존성이 준비될 것이라 행복회로(happy path)를 돌린다면, 개발의 속도는 향상 되겠지만 시스템의 안정성은 보장할 수 없습니다.

2-2. 마이크로서비스가 조정 비용 절감

마이크로서비스를 성공적으로 구축하는 근본적인 힘은 조정을 최소화하는 것입니다. ‘나의 결정이 조정 비용을 감소시키는가?’ 처럼 스스로에게 질문을 던져 조정 비용의 관점을 생각하고 결정해야 마이크로서비스를 성공적으로 구축할 수 있습니다.

조정의 최소화를 강조하면서 자율적인 팀이 독립된 소규모 작업을 수행하는 설계가 바로 마이크로서비스 아키텍처의 본질이다.

이 파트에서 궁금했던 부분은, 구체적으로 마이크로서비스가 어떻게 조정 비용을 절감하는가? 였습니다. 그 질문에 대해서는 마이크로서비스가 조정을 최소화해야 성공한다라는 추상적인 답이 있었습니다. 이 조정 비용을 해결하는 부분에 대한 저의 개인적인 생각은 각 마이크로서비스의 약한 결합으로 인한 조정의 최소화에 있지 않을까 추측합니다.

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

마이크로서비스의 장애물은 방대한 범위입니다. 이를 통해 우리는 일반적으로 다음과 같은 설계 문제를 겪습니다.

• 긴 피드백 루프
  : 결정에 대한 영향을 판단하기 어렵다. 즉, 의사 결정의 영향(피드백)이 돌아오는 시간이 오랜 시간이 지난 후에야 나타날 수 있다.

• 복잡한 시스템 구조
  : 시스템의 각 파트가 어떤 식으로든 다른 부분에 영향을 미친다.

• 분석 마비
  : 잘못된 종류의 시스템을 만드는 것에 대한 두려움(결정의 영향력에 대한 측정이 어렵기 때문에 발생)으로 인해 끝없는 추측, 토론, 평가를 한다. 비즈니스 성과 달성을 어렵하게 하는 분석마비 현상이 찾아온다.

4. 아키텍처 결정 기록(Architecture Decistion Record)

소프트웨어 구축에서 의사 결정은 매우 중요합니다. 소프트웨어 엔지니어와 아키텍처는 그들이 내리는 결정과 해결하는 문제에 대해 많은 보상을 받습니다. 소프트웨어의 품질과 그들이 추진하는 비즈니스의 결과는 이러한 결정의 품질에 달려있습니다. 하지만 결정이 항상 쉬운 것이 아니고 정확하지 않습니다. 예를 들어, 한 때 정확하다고 생각한 결정도 시간이 지나면 기술, 사람, 상황에 의해 구식으로 변합니다. 따라서 어떤 경우든 중요한 결정을 기록하여 시간이 지남에 따라 재평가하고 개선할 수 있는 방법이 필요합니다. 이러한 부분을 위해서 아키텍처 결정 기록(ADR)이라는 결정 기록 도구를 사용할 수 있습니다.

ADR 중요 포함 요소

• 콘텍스트: 목표, 해결 문제, 제약 등과 같은 상황에 대한 요약을 포함해야 한다.
• 대안: 결정을 내렸을 적에 선택지를 작성한다. 결정이 내려진 시점의 상황과 ‘선택 공간’을 파악하는데 용이하다.
• 선택: 선택한 사항에 대해 문서화한다.
• 영향: 결정에는 그에 따른 결과가 있으며 중요한 내용은 결정 기록에 문서화되어야 한다.

결정 기록은 텍스트 파일이나 프로젝트 관리 도구를 사용할 수 있습니다. 즉, 형식과 도구보다는 내용이 더 중요합니다. 이 책에서는 경량 아키텍처 결정 기록(LADR) 이라는 형식을 사용합니다.

4-1. 경량 아키텍처 결정 기록(Lightweight Architecture Decistion Record)

경량 아키텍처 결정 기록은 다음과 같이 작성합니다.

# 제목: 내용 ## 상태 : 결정이 위치한 생명 주기 단계를 작성한다. ## 콘텍스트 : 결정을 내리기 위한 문제, 제약, 배경을 설명한다. ## 결정 : 위 ADR 중요 포함 요소 중 선택과 대안을 작성하면 좋다. ## 결과 : 위 ADR 중요 포함 요소 중 영향과 같은 결과를 작성하면 좋다.