Microservices

개요 CQRS(Command and Query Responsibility Segregation)는 쓰기 명령과 읽기 쿼리의 책임을 분리하는 아키텍처 패턴 CQS를 제안한 Bertrand Meyer의 아이디어가 뿌리이고, 실무적 CQRS 패턴을 알린 인물로 Greg Young이 널리 알려짐 핵심은 CUD(Command: Create, Update, Delete)와 R(Query: Read)을 하나의 모델로 처리하지 않고 분리해 복잡도와 결합도를 낮추는 것 왜 분리하는가 전통적인 CRUD 중심 구조에서는 단일 도메인 모델이 쓰기와 읽기 모두를 떠안음 변화 무쌍한 도메인 규칙과 고도화된 UX 요구로 인해 모델이 비대해지고, 유지보수 비용과 리스크가 누적됨 실제 비즈니스 룰과 제약은 쓰기 경로에서 주로 발생하고, 읽기는 상대적으로 단순 조회나 집계 중심인 경우가 많음 두 책임을 하나의 모델로 끌어안으면 불필요한 속성과 검증 로직이 뒤섞여 모델이 설계 의도에서 이탈함 CQRS는 책임을 분리해 각 경로를 그 목적에 맞게 최적화할 수 있게 함 ...

개요 분산 추적 컨텍스트를 어디에 어떻게 실어 나를지에 대한 표준 패턴 정리. HTTP 같은 동기식 통신과 메시지 큐 같은 비동기식 통신은 전달 수단이 다름. 업계 표준은 W3C Trace Context와 이를 구현한 OpenTelemetry를 따르는 흐름임 핵심 개념 trace-id, span-id, sampling 플래그 등 추적 컨텍스트 전달 필요 동기식 요청/응답 채널은 헤더 기반 메타데이터 전달이 자연스러움 비동기 메시징은 메시지 자체가 전달 단위이므로 페이로드 또는 메시지 속성 이용 채널이 헤더 개념을 지원하면 헤더 우선, 없으면 페이로드에 포함 통신별 패턴 HTTP/REST 통신: 요청/응답 헤더에 trace 컨텍스트 실어 전달 gRPC: 메타데이터(헤더 개념)로 전달 Kafka: 메시지 헤더 지원. 가능하면 헤더 사용 권장 RabbitMQ: 메시지 프로퍼티의 headers 사용 가능 AWS SQS: Message Attributes 사용 가능. 미지원 시 Body에 포함 BullMQ/Redis 기반 잡 큐: 헤더 개념 없음. Job data에 포함 WebSocket: 초기 핸드셰이크 단계에서 허용된 메타데이터 채널 또는 쿼리로 전달, 이후 각 메시지 페이로드에 포함. 환경 제약으로 커스텀 헤더 불가한 경우 존재 산업 표준 OpenTelemetry는 W3C Trace Context를 구현하는 업계 표준 스택 HTTP는 W3C traceparent, tracestate 헤더 사용 비동기 메시징은 채널이 헤더를 지원하면 헤더 사용, 아니면 데이터에 포함하는 전략 일반화 예시 ...

개념과 배경 마이크로서비스로 분산이 심화되면 로깅, 모니터링, 보안, 네트워킹 같은 공통 기능을 어디에 둘지 결정이 어려워짐 애플리케이션 코드에 공통 기능을 계속 끼워 넣으면 침투와 중복 증가, 배포와 버전 관리 복잡도 상승 사이드카 패턴은 공통 기능을 별도 컨테이너로 분리해 메인 서비스는 비즈니스 로직에 집중하게 하는 접근법 컨테이너 오케스트레이션 환경에서 일관된 운영 모델을 제공한다는 점이 실무적 장점 핵심 개념 사이드카 패턴의 구성 요소 메인 컨테이너: 비즈니스 로직 담당, 웹 서비스나 API 서버 등 사이드카 컨테이너: 횡단 관심사 처리, 로그 수집, 모니터링 에이전트, 프록시, 보안 검사 등 같은 파드 내 배치로 네트워크 네임스페이스와 볼륨 공유 가능, 표준 출력/공유 볼륨 등을 통해 데이터 연계 업데이트와 배포를 컨테이너 단위로 분리해 독립적 버전 관리 가능 동작 원리 하나의 파드에 메인 컨테이너와 사이드카 컨테이너를 함께 배치 ...