원문 : https://jonasboner.com/resources/Reactive_Microsystems.pdf
GTP 번역기돌려 요약만 간추린버전
마이크로서비스의 필수 특성
모든 것을 격리하라 (Isolate All the Things)
"위대한 고독 없이는 어떤 진지한 작업도 불가능하다."
— 파블로 피카소
격리는 마이크로서비스에서 가장 중요한 특성이며, 많은 고급 이점을 제공하는 기초가 됩니다.
격리는 설계와 아키텍처에 가장 큰 영향을 미치며, 이는 처음부터 고려해야 하는 요소입니다.
격리는 서비스 간의 독립성을 보장하며, 다음과 같은 이점을 제공합니다:
- 연속적 배포 가능성 (Continuous Delivery): 서비스별로 안전하게 배포하고, 변경 사항을 점진적으로 적용 및 되돌릴 수 있습니다.
- 독립적 확장성: 각 서비스를 개별적으로 확장할 수 있습니다.
- 모니터링 및 디버깅의 용이성: 서비스의 상태를 독립적으로 확인하고 문제를 해결할 수 있습니다.
자율적으로 작동하라 (Act Autonomously)
"자율 시스템의 네트워크에서 에이전트는 자신의 정책에 대한 주장만을 신경 쓰며, 외부 에이전트가 그 동의 없이 지시할 수 없습니다."
— 마크 버지스
격리는 자율성을 위한 전제조건입니다. 서비스가 격리되었을 때만 독립적으로 결정하고 작동하며, 다른 서비스와 협력할 수 있습니다.
자율성은 다음을 가능하게 합니다:
- 서비스 오케스트레이션 및 워크플로 관리
- 확장성 및 가용성 개선
- 독립적인 팀 운영 (새 기능 배포 및 서비스 업데이트 등)
단일 책임 원칙 (Single Responsibility)
"유닉스 철학: 하나의 작업을 잘 수행하는 프로그램을 작성하라."
— 더그 맥일로이
마이크로서비스는 단일 책임 원칙(SRP)을 따라야 합니다.
하나의 서비스는 한 가지 목적만을 가지고, 이를 잘 수행하도록 설계되어야 합니다.
이 원칙을 따르면 다음과 같은 장점이 있습니다:
- 서비스의 범위와 목적이 명확해집니다.
- 시스템 확장성, 이해도, 유지보수성 향상
상태를 독점적으로 소유하라 (Own Your State, Exclusively)
"개인으로 존재할 이유가 없으면 프라이버시는 무의미하다."
— 조너선 프랜즌
마이크로서비스는 상태와 동작을 캡슐화하는 상태 기반 컴포넌트입니다.
서비스 간 격리를 유지하려면 상태 또한 각 서비스가 독점적으로 관리해야 합니다.
이는 다음과 같은 결과를 가져옵니다:
- 서비스 간 강한 일관성을 포기하고 최종적 일관성(Eventual Consistency)에 의존해야 합니다.
- 단일 데이터베이스를 사용하는 대신 서비스별로 분리된 데이터 저장소를 사용해야 합니다.
유동적이되 주소 가능하게 유지하라 (Stay Mobile, but Addressable)
"이동하고, 숨 쉬며, 날고, 떠다니며, 주고받으며 여행하라. 여행은 삶이다."
— 한스 크리스티안 안데르센
클라우드 컴퓨팅 및 가상화 시대에는 서비스가 정적인 토폴로지에 고정되지 않고 동적으로 이동할 수 있어야 합니다.
이를 위해 서비스는 다음을 충족해야 합니다:
- 유동성: 런타임 중에 서비스의 위치를 변경할 수 있음
- 주소 가능성: 서비스의 위치와 무관하게 항상 접근 가능
이 내용은 "마이크로서비스의 필수 특성" 챕터의 요약 번역입니다. 추가적으로 더 깊이 있는 번역이나 설명이 필요하면 알려주세요!
나의 말:
이벤트 중심의 도메인 설계
ChatGPT의 말:
ChatGPT
다음은 이벤트 중심의 도메인 설계(Events-First Domain-Driven Design)에 대한 번역입니다:
이벤트 중심의 도메인 설계
이벤트 중심의 도메인 설계는 도메인의 구조(명사)에 집중하는 기존 접근법에서 벗어나, 도메인에서 발생하는 이벤트(동사)에 초점을 맞추는 설계 원칙입니다. 이 접근법은 시스템의 데이터 흐름 및 통신 관점에서 도메인의 본질을 이해하고, 확장 가능한 이벤트 기반 설계를 구현할 수 있도록 돕습니다.
이벤트에 초점 맞추기: 무엇이 발생하는가?
"라리, 이것이 무슨 일인지 봤어? 무슨 일이 일어났는지 알겠어?"
— 월터 소브첵, 빅 리버스키
객체지향 프로그래밍(OOP)과 도메인 주도 설계(DDD)는 도메인의 객체(명사)를 식별하는 데 중점을 두었습니다. 하지만 이러한 접근은 설계 초기 단계에서 구조에 초점을 맞추는 문제를 야기합니다.
대신 도메인의 이벤트, 즉 무엇이 발생하는가에 초점을 맞추는 것이 중요합니다. 이는 시스템에서 변화가 어떻게 전파되는지, 즉 통신 패턴, 워크플로, 데이터 책임 등을 이해하는 데 도움이 됩니다. 이벤트 중심의 설계는 다음과 같은 이점을 제공합니다:
- 시스템의 시간적 관점 파악: 이벤트는 시스템에서 시간의 흐름과 원인을 이해하는 데 필수적입니다.
- 도메인 이벤트 모델링: 이벤트는 도메인의 사실을 나타내며, 불변성을 가진 진실된 데이터로 정의됩니다.
이벤트는 사실(Facts)을 나타낸다
"사실을 증기로부터 농축해라."
— 닐 스티븐슨, 스노우 크래쉬
이벤트는 도메인에 대한 사실을 나타내며, 이를 통해 시스템의 상태를 정확히 반영할 수 있습니다. 이벤트는 다음과 같은 속성을 가집니다:
- 불변성 (Immutability): 이벤트는 발생한 사실을 나타내며, 과거를 수정할 수 없듯이 변경될 수 없습니다.
- 누적 가능성 (Cumulative Knowledge): 기존 이벤트에서 파생된 새 이벤트가 시스템의 지식을 확장합니다.
이벤트 스토밍(Event Storming)
"폭풍 속을 지나면, 들어가기 전의 자신과 같지 않을 것이다."
— 하루키 무라카미, 해변의 카프카
이벤트 스토밍은 도메인을 분석하고 이벤트의 흐름과 의존성을 이해하기 위한 협업 설계 프로세스입니다. 이 과정에서 도메인 전문가와 개발자가 함께 모여, 포스트잇을 활용하여 다음을 수행합니다:
- 이벤트 식별: 시스템에서 무엇이 발생하는지 탐색하고, 이벤트 간의 인과 관계를 분석합니다.
- 명령(Command)과 이벤트(Event) 관계 정의: 이벤트를 유발하는 명령을 찾고, 이 명령이 도메인의 어떤 부분에서 실행되는지 확인합니다.
- 데이터 흐름 모델링: 데이터가 어떻게 전달되고 처리되는지 시각화합니다.
일관성 경계(Consistency Boundaries)를 생각하라
"서비스 지향 아키텍처로 전환하는 데 가장 큰 도전 과제는, 개발자가 서비스 내부의 '현재' 상태와 외부에서 들어오는 데이터의 '과거' 상태를 이해해야 한다는 점이다."
— 팻 헬런드
도메인의 이벤트를 모델링한 후, 일관성 경계를 정의하여 데이터의 무결성과 의존성을 관리해야 합니다. 이를 위해 다음 단계를 따릅니다:
- 데이터를 중심으로 생각합니다. (동작보다 데이터의 의존성에 초점)
- 최소한의 강한 일관성을 보장하며, 필요한 만큼만 보장합니다.
- 단일 책임 원칙을 따르며 데이터 모델을 단순화합니다.
집계(Aggregates): 일관성의 단위
"일관성은 신뢰의 진정한 기반이다."
— 로이 T. 베넷
집계는 도메인 모델의 일관성을 유지하기 위한 논리적 경계를 정의합니다. 집계는 하나 이상의 엔티티로 구성되며, 모든 작업은 집계 루트를 통해 수행됩니다. 집계는 다음 원칙을 따릅니다:
- 독립성 유지: 다른 집계와 직접 참조를 금지하고, ID로만 참조합니다.
- 최소화된 데이터 범위: 가능한 한 작은 일관성 단위를 유지합니다.
상태는 내부에서만 변경하라
"할당문은 프로그래밍 언어의 병목이자, 역사를 계속 초기화하는 파괴적 작업이다."
— 존 배커스, 튜링상 수상 연설
상태 변경은 필수적일 수 있지만, 외부에서 관찰할 수 없는 서비스 내부에서만 수행되어야 합니다. 외부에 알릴 때는 변경 내용을 불변성 데이터인 이벤트로 변환하여 게시합니다.