728x90
티베로의 프로시저를 사용해서 프로그램해도 될 것같다. 그러나 jenkins 배치를 사용하는 이유가 궁금하다
결국 “티베로 프로시저로도 충분히 처리할 수 있는 로직인데, 왜 굳이 외부에서 Jenkins가 cron처럼 배치를 돌리고 있느냐?”가 핵심입니다.
현업에서 티베로(Tibero) 프로시저만으로는 못 버티고 Jenkins(또는 다른 스케줄러)를 함께 쓰는 이유를 9가지 실무 관점으로 정리했습니다.
현업에서 티베로(Tibero) 프로시저만으로는 못 버티고 Jenkins(또는 다른 스케줄러)를 함께 쓰는 이유를 9가지 실무 관점으로 정리했습니다.
1. “DB는 귀한 자원” → 오래-돌리면 회사가 덜덜 떤다
-
프로시저 내부에서 1억 건을 CURSOR 돌리면
– Tibero가 먹는 CPU·메모리 → DB 서버 격통
– 동시 OLTP 세션은 대기(PX 대기, enq: TM lock) → 온라인 장애 -
외부 스케줄러(Jenkins)가 Java·Python·Spark로 I/O를 끌어내 처리하면 DB는 짧은 SQL만 받고 금방 놓아줌 → OLTP 보호
2. “트랜잭션 시간 제한” & UNDO 폭증
-
대용량 UPDATE/INSERT는 UNDO·REDO 폭증 →
– Archive 로그 장비 꽉 참
– 세션 Kill 시 롤백 2시간 -
외부 배치는 Pagination(범위) 조회 → 1만 건씩 커밋하는 식으로 쪼갤 수 있음.
프로시저 안에서도 가능은 하지만, 실수로 커밋 누락하면 “장시간 대기 + 전체 롤백” 위험.
3. “외부 시스템과 handshake”는 DB만으로 못한다
-
A시스템이 받은 파일을
-
SFTP로 내려받고
-
압축 풀고
-
검증하고
-
DB 적재
하는 흐름은 프로시저 안에서 불가능(또는 JVM-in-DB 권한 오픈이 더 위험).
-
-
Jenkins + Shell/Python 에선 1~3을 끝내고 마지막 4번만 짧은 프로시저 호출 → DB 점유 시간 10초 미만.
4. “병렬·분산” 처리
-
프로시저는 단일 DB 인스턴스 안에서만 돌아감.
-
Jenkins는
– 슬레이브 노드 여러 대에서 잡을 나눠 실행
– Spark on K8s처럼 클러스터 1,000 코어로 아웃-오브-DB 병렬 처리
→ 3시간 작업을 10분로 압축 가능.
5. “의존성·재시도·SLA” 메타 관리
-
프로시저를 DBMS_SCHEDULER로 깔 수 있지만,
– “전날 마감 프로시저 완료 후 02:00에 금일 프로시저 시작”
– “실패 시 3번 재시도, Slack 알림, 대기 걸지 말고 다음꺼 skip”
같은 조건을 걸기 위해선 Airflow/Jenkins DAG이 훨씬 직관적.
6. 버전 관리 & CI/CD
-
프로시저는 DB 안에 소스가 있어 Git 버전 ↔ 패키지 Body 동기화가 깨지기 쉬움.
-
Jenkins pipeline은 GitOps:
– PR → 리뷰 → Merge 되면 Argo CD가 자동 배포 → 누가 바꿨는지 히스토리 명확.
7. 장애 격리 & 롤백
-
프로시저 하나가 데드락/장애 → DB 전체가 느려질 수 있음.
-
외부 배치는 컨테이너 단위 격리 → 죽어도 DB엔 영향 X, 즉시 새 Pod 띄워 재시도.
8. 스케일-아웃이 안 된다
-
DB 서버 scale-up만 가능(비용 기하급수).
-
Jenkins + K8s는 Spot 500 Core를 30분만에 띄웠다가 끄는 식으로 비용 1/3.
9. “우리도 알지만, 레거시가 그렇게 돌아가고 있다”
-
10년 전에는
– 담당자가 PL/SQL만 알았고
– 온라인 트래픽이 지금의 1/100
– 파일 용량도 수십 MB
수준이라 “프로시저+DBMS_SCHEDULER”로 충분했음. -
데이터·파일이 폭증하고 연계 시스템이 늘어나자 점점 외부 로직이 늘어났고,
그걸 cron보다 Jenkins로 관리하게 된 것임
결론
-
“프로시저로도 될 것” → 작업량이 작고 외부 I/O가 없고 DB 부하가 허용될 때만 맞는 말.
-
“Jenkins를 쓰는 이유” → DB를 보호하면서 외부 I/O·병렬·분산·버전관리·의존성 관리까지 해야 하기 때문.
-
앞으로의 방향
– 단순 SQL 집계는 프로시저 안에 두더라도 호출 주체는 Airflow/Jenkins
– 대용량·복잡 로직은 Spark/Kafka 로 아웃-오브-DB → DB는 “짧고 가벼운 쿼리만”
– 결국 Jenkins도 단순 스케줄러 → 메타 오케스트레이션 역할로 축소,
실제 연산은 K8s/Spark/Flink가 담당하는 하이브리드 구조가 최종 목표입니다.
728x90