Observability

개념/배경 마이크로서비스와 비동기 작업이 섞인 환경에서 요청의 전 흐름을 좇기 위한 상관 식별자 필요 일반적으로 trace id를 tid로 표기해 서비스 경계를 넘나들며 전파함 HTTP 같은 동기 호출과 메시지 큐 같은 비동기 처리의 전파 매체가 다르므로 매체별 규칙을 명확히 두는 것이 핵심 산업 표준은 W3C Trace Context와 OpenTelemetry가 사실상 기본값 프로세스 내부 전파에는 비동기 컨텍스트 저장소 사용 권장 핵심 개념과 정의 TID(trace id)와 span id 구분, tid는 전체 요청 상관을 위한 루트 식별자 역할 W3C Trace Context의 traceparent와 tracestate 헤더로 표준 전파 OpenTelemetry는 위 표준을 구현하고 언어별 SDK 제공 프로세스 내 컨텍스트 전파는 AsyncLocalStorage 등 런타임 컨텍스트로 처리 표준 패턴 HTTP 및 gRPC 같은 동기 네트워크 통신은 헤더 사용이 기본 원칙 메시지 큐나 비동기 작업은 메시지 Body 또는 시스템이 제공하는 메시지 속성 사용 지원되는 경우 메시지 헤더를 우선 사용, 없으면 Payload에 포함 요약 ...

개요 분산 추적 컨텍스트를 어디에 어떻게 실어 나를지에 대한 표준 패턴 정리. 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 헤더 사용 비동기 메시징은 채널이 헤더를 지원하면 헤더 사용, 아니면 데이터에 포함하는 전략 일반화 예시 ...

개요 좋은 시스템 설계는 복잡해 보이지 않고 긴 시간 동안 별문제 없이 돌아가는 상태를 말함 핵심은 상태를 최소화하고, 검증된 단순한 컴포넌트를 필요할 때만 조합하는 방향 과설계나 과도한 신기술 도입은 문제를 감추거나 유지보수 비용을 키우는 경향 최소 기능의 단순 구조에서 시작 후 관측 기반으로 점진 개선 권장 시스템 설계의 정의와 접근 소프트웨어 설계가 코드 조립이라면 시스템 설계는 서비스를 조합하는 일이라는 관점 주요 구성 요소 팔레트 앱 서버 데이터베이스 캐시 큐와 잡 러너 이벤트 버스 프록시와 게이트웨이 좋은 설계의 징후 ...

개요 HTTP Status Code만으로는 서비스 로직의 원인을 전달하기 부족함 400대와 500대는 네트워크 관점의 대분류 신호에 가깝고 실제로 필요한 것은 비즈니스 맥락의 구체적 사유임 결론은 단순함 HTTP Status는 대분류 신호로 두고 실제 의미와 추가 컨텍스트는 Response Body에 싣는 구조가 현실적 해법임 핵심 원칙 HTTP Status는 큰 범주 신호등 역할 2xx 성공 4xx 클라이언트 오류 5xx 서버 오류 비즈니스 의미는 Response Body의 커스텀 에러 구조로 표현 클라이언트가 코드 기반으로 분기하고 UI를 결정할 수 있어야 함 운영 관측을 위해 traceId 제공 업계에서 검증된 기본 구조 아래 형태가 가장 보편적으로 쓰이는 패턴임 ...

개요 운영 중인 서비스에서 전체 트래픽을 한 번에 신규 기능이나 신규 인프라로 전환하지 않고, 일정 비율만 점진적으로 이동하는 전략이 필요함 주요 활용 맥락 A/B 테스트로 실험군과 통제군 분리 카나리 배포로 신규 버전을 소수 사용자에게만 적용 신규 데이터베이스, 캐시, 인덱스 전환 검증 신규 알고리즘, 추천 엔진, 정책 점진 적용 서버 비용 최적화를 위한 점진적 트래픽 이동 아래는 대부분의 시나리오에 적용 가능한 일반화된 트래픽 분배 기법 정리 요구 조건 Deterministic — 같은 사용자나 리소스는 항상 같은 그룹에 속해야 함 요청마다 그룹이 바뀌면 실험 신뢰성이 떨어지고 디버깅이 어려움 안정적 해시 기반 결정 방식 필요 ...

개요 쿠버네티스는 명령을 조율하는 Control Plane과 실제 워크로드가 실행되는 Data Plane으로 구성됨 각 컴포넌트의 역할과 흐름을 이해하면 트러블슈팅, 성능 최적화, 보안 구성에 필요한 기준이 생김 클라우드 매니지드 쿠버네티스의 경우 Control Plane은 보통 제공자가 관리하지만 동작 원리 이해는 필수 Control Plane API Server 클러스터 유일 진입점 모든 컴포넌트와 사용자는 API Server를 통해 통신 인증과 권한 확인 수행 etcd 클러스터 상태와 스펙을 보관하는 분산 키밸류 저장소 API Server만 직접 접근 가능 상태 복구의 근간이 되는 데이터 원장 Scheduler ...

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