
Jenkins 배치 220개를 Temporal로 옮기며 고민한 것들
두줄요약
Jenkins의 장애 전파·알림 누락·자원 비효율 문제를 Temporal과 Kubernetes Job 기반 구조로 이관했습니다. 공용 라이브러리로 실패 알림, 중복 방지, 멈춤 감지, 로그 추적을 기본화했습니다.
문제 상황
- Jenkins 디스크 포화와 플러그인 의존성 충돌로 서비스별 배치 전체 중단 및 대기 큐 적체
- 잡별 알림 설정 누락, 유휴 시간의 낮은 자원 활용률, 집중 실행 시 자원 경합
- EC2 12대에서 220개 잡을 하루 약 15,900회 실행하는 운영 구조
해결 방법
- Temporal 서버를 EKS에 배치하고 Aurora PostgreSQL을 상태 저장소로 활용
- 서비스별 TypeScript 워커와 공용 라이브러리로 스케줄, 컨테이너 실행, API 호출, 실패 알림 통합
- Kubernetes Job을 배치별로 생성하고 Jenkins와 병행 운영하며 잡 단위 전환
성능/운영 포인트
- 실행 ID와 시도 번호 기반 Job 이름으로 워커 장애 시 중복 실행 방지
- Activity 타임아웃·heartbeat, Temporal 메트릭 알림, 1시간 이내 실행만 catchup으로 멈춤 및 밀린 실행 관리
- Datadog 로그에 실행 ID를 공통 태그로 연결하고 Karpenter 축출 방지 표시 적용
트레이드오프
- Jenkins EC2 종료 시 배치 시스템 비용 절반 이상 절감 기대와 배치별 자원 보장
- Temporal·Datadog 개념 학습, 서비스별 워커 운영, 더 복잡해진 구조 관리 부담
- 스케줄 활성 상태는 코드 동기화 충돌 방지를 위해 Temporal UI에서만 관리




