목록 보기
Jenkins 배치 220개를 Temporal로 옮기며 고민한 것들
데브옵스

Jenkins 배치 220개를 Temporal로 옮기며 고민한 것들

인프런
인프런
2026년 10월 20일

두줄요약

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에서만 관리

다음 읽기

#Temporal 주제를 다룬 다른 회사 글

“스케줄이 또 안 돌았어요” — 우리가 Temporal을 선택한 이유

Jenkins 기반 스케줄 운영의 한계를 해결하기 위해 Temporal을 도입했습니다. 자동 재시도와 실행 이력 가시성으로 출고지시와 주문수집을 더 안정적으로 자동화했습니다.

무신사
무신사
백엔드

댓글 0개

댓글을 작성하려면 로그인이 필요합니다.

댓글을 불러오는 중...