피드로 돌아가기
Dev.toDevOps
원문 읽기
BullMQ와 AES-256-GCM 기반의 안정적 Self-hosted CI/CD 구축
I built a self-hosted CI/CD platform with persistent queue, encrypted secrets, and rollback UI — here's what I learned
AI 요약
Context
Bash 스크립트의 Audit Trail 부재와 Jenkins의 과도한 유지보수 비용 사이의 간극을 해결하고자 함. 초기 In-memory Queue 사용으로 인해 프로세스 재시작 시 배포 작업이 유실되는 데이터 정합성 문제 발생.
Technical Solution
- BullMQ 및 Redis 도입을 통한 Persistent Queue 구현으로 프로세스 재시작 후에도 작업 연속성 보장
- Exponential Backoff(1s → 5s → 25s) 전략을 적용한 3회 재시도 정책으로 일시적 네트워크 오류 대응
- AES-256-GCM 및 Unique IV를 활용한 환경 변수 암호화로 DB Dump 유출 시의 Secret 노출 리스크 최소화
- NotificationProvider, Channel, Subscription의 3계층 분리 구조를 통한 다대다(M:N) 알림 Fan-out 아키텍처 설계
- QueueReadyMiddleware 도입으로 Redis 연결 불가 시 API 요청에 503 응답을 반환하여 요청 유실 방지
- Promise.allSettled 기반의 알림 전송 로직을 통해 개별 채널 실패가 전체 프로세스에 영향을 주지 않는 격리 구조 구현
실천 포인트
- 비동기 작업 처리 시 In-memory 방식 대신 Redis 기반의 Persistent Queue 검토 - Secret 관리 설계 시 DB Dump 유출 시나리오를 가정하여 AES-256-GCM 등 암호화 표준 적용 - 알림 시스템 설계 시 공급자(Provider)와 대상(Channel)을 분리하여 확장성 확보 - 외부 의존성(Redis 등) 상태에 따라 API 응답을 제어하는 Middleware 배치로 시스템 가용성 명시