레디스가 싱글스레드라서 BullMQ에서 job data가 커지면 Redis가 터진다고 단순화해서 말하는 경우가 많음 하지만 실제로는 Redis가 큰 payload 처리 때문에 막히고, 그 지연이 메모리와 네트워크 문제로 이어지며 타임아웃이나 OOM 같은 연쇄 문제로 번지는 쪽이 더 큼 job data가 커질 때 Redis에서 바로 벌어지는 일 1) 이벤트루프가 큰 값 때문에 오래 점유 BullMQ는 job을 만들 때 job data를 보통 Redis에 문자열이나 JSON 형태로 저장함 job data가 커지면 쓰기와 조회 모두에서 처리해야 하는 바이트가 늘어남 SET이나 HSET 같은 쓰기, HGET 같은 조회가 한 명령당 처리해야 하는 바이트를 키움 ...
개념/배경 마이크로서비스와 비동기 작업이 섞인 환경에서 요청의 전 흐름을 좇기 위한 상관 식별자 필요 일반적으로 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에 포함 요약 ...