인스턴스 스케일 아웃 시 Quartz 배치 중복 실행 방지: 완벽 가이드

작성자:

안녕하세요! 시스템 개발과 운영에 매진하고 계신 모든 개발자분들, 그리고 안정적인 서비스 제공을 위해 밤낮으로 애쓰시는 분들께 반가운 소식을 전해드립니다. 오늘은 많은 분들이 한 번쯤은 겪어보셨을, 혹은 앞으로 겪게 될 수도 있는 아주 중요한 문제, 바로 동일한 인스턴스로 스케일 아웃한 경우 인스턴스 안에 포함된 Quartz 배치가 두 인스턴스에서 동시에 실행되는 것을 방지하는 방법에 대해 깊이 있게 다뤄보려 합니다.

인스턴스 스케일 아웃 시 Quartz 배치 중복 실행 방지: 완벽 가이드 1

클라우드 환경이 대세가 되고, MSA(Microservice Architecture)가 보편화되면서 서비스는 더욱 유연하고 확장 가능하게 진화하고 있습니다. 하지만 그만큼 새로운 고민거리들도 생겨나고 있죠. 그중 하나가 바로 ‘분산 환경에서의 배치 처리’입니다. 특히 Quartz 스케줄러를 사용하시는 분들이라면, 서비스가 여러 인스턴스로 스케일 아웃될 때 배치 작업이 중복으로 실행되어 데이터 정합성 문제가 발생하거나 불필요한 리소스 낭비가 초래되는 상황에 직면할 수 있습니다.

저도 예전에 운영하던 서비스에서 비슷한 문제를 겪었습니다. 사용자 트래픽 증가에 대비해 애플리케이션 서버를 늘렸는데, 특정 배치 작업이 두 번씩 실행되어 재고 수량이 엉뚱하게 반영되거나 알림 메시지가 두 번씩 발송되는 웃지 못할(?) 상황이 벌어졌었죠. 그때의 아찔했던 경험을 생각하면 지금도 식은땀이 흐릅니다. 😭

하지만 걱정하지 마세요! 오늘 이 글을 통해 여러분의 고민을 시원하게 해결해 드릴 Quartz 배치 중복 실행 방지를 위한 모든 노하우를 공개할 예정입니다. 이 글은 단순히 이론적인 설명에 그치지 않고, 실제 적용 가능한 방법론과 구체적인 사례, 그리고 제가 직접 경험하며 얻은 꿀팁까지 아낌없이 공유할 것입니다. 이 글을 끝까지 읽으시면 더 이상 Quartz 배치 중복 실행으로 밤잠 설치는 일은 없을 것이라고 확신합니다!

 

목차

1. 서론: 왜 Quartz 배치 중복 실행 방지가 중요할까요?

 

오늘날 대부분의 웹 서비스는 트래픽 변동에 유연하게 대처하기 위해 수평 확장을 고려하여 설계됩니다. 이를 ‘스케일 아웃(Scale-out)’이라고 하죠. 예를 들어, 갑자기 접속자가 폭증하면 서버 인스턴스를 추가로 늘려 부하를 분산시키고, 트래픽이 줄어들면 다시 줄여 리소스 낭비를 막는 방식입니다. 이 과정에서 애플리케이션 내부에 포함된 배치 작업, 특히 Quartz 스케줄러와 같은 라이브러리를 통해 예약된 작업들은 예상치 못한 문제를 일으킬 수 있습니다.

바로, 동일한 배치 작업이 여러 인스턴스에서 동시에 실행되는 ‘중복 실행’ 문제입니다. 예를 들어, 매일 새벽 1시에 오늘의 정산 데이터를 처리하는 배치 작업이 있다고 가정해 봅시다. 이 배치가 한 번만 실행되어야 정확한 정산 결과를 얻을 수 있는데, 스케일 아웃된 두 개의 인스턴스에서 동시에 실행된다면 어떻게 될까요?

  • 데이터 정합성 문제: 데이터베이스에 중복된 데이터가 쌓이거나, 집계 값이 두 배로 계산되어 잘못된 통계가 나올 수 있습니다. 예를 들어, 재고를 차감하는 배치인데 두 번 차감되어 재고가 마이너스가 되는 불상사가 생길 수도 있죠.
  • 리소스 낭비: 불필요한 연산이 두 번, 세 번 발생하면서 서버 CPU, 메모리, 네트워크, 데이터베이스 등 시스템 리소스를 낭비하게 됩니다. 이는 결국 운영 비용 증가로 이어집니다.
  • 비즈니스 로직 오류: 사용자에게 중복 알림이 가거나, 같은 이벤트에 대해 두 번 처리되어 사용자 경험을 해치고 비즈니스 신뢰도에 악영향을 줄 수 있습니다. 제가 겪었던 알림 중복 발송 문제가 바로 이런 경우였습니다.

이러한 문제들은 서비스의 신뢰도를 떨어뜨리고, 심각할 경우 금전적인 손실이나 법적 문제로까지 이어질 수 있습니다. 따라서 동일한 인스턴스로 스케일 아웃한 경우 인스턴스 안에 포함된 Quartz 배치가 두 인스턴스에서 동시에 실행되는 것을 방지하는 방법을 아는 것은 안정적인 서비스 운영을 위한 필수적인 지식이라고 할 수 있습니다.

 

2. 본론 1: Quartz 스케줄러와 분산 환경의 이해

 

본격적인 해결책을 논하기 전에, Quartz 스케줄러가 무엇인지, 그리고 분산 환경에서 어떤 특성을 가지는지 다시 한번 짚고 넘어가는 시간을 갖겠습니다.

 

Quartz 스케줄러 기본 개념 복습

 

Quartz 스케줄러는 Java 기반의 오픈소스 스케줄링 라이브러리입니다. 특정 시간에 특정 작업을 실행하도록 예약하고 관리하는 데 사용됩니다. Cron 표현식을 이용한 주기적인 작업, 특정 시간 한 번만 실행되는 작업 등 다양한 형태의 스케줄링을 지원하며, Job, Trigger, Scheduler 등의 핵심 구성 요소를 가집니다.

  • Job: 실제로 실행될 비즈니스 로직을 담고 있는 인터페이스입니다. Job 인터페이스를 구현하여 execute() 메서드 안에 원하는 작업을 정의합니다.
  • Trigger: Job이 언제 실행될지 정의하는 역할을 합니다. CronTrigger, SimpleTrigger 등이 있으며, 실행 주기, 시작 시간, 종료 시간 등을 설정할 수 있습니다.
  • Scheduler: Job과 Trigger를 등록하고 관리하며, 지정된 시간에 Job을 실행하는 핵심 엔진입니다.

 

분산 환경에서 Quartz가 마주하는 문제점

 

일반적인 단일 서버 환경에서는 Quartz 스케줄러가 단 하나만 존재하므로 배치 중복 실행 문제는 발생하지 않습니다. 하지만 서비스가 성장하고 트래픽이 증가함에 따라 여러 대의 서버에 애플리케이션을 배포하여 부하를 분산시키는 스케일 아웃 전략을 사용하게 됩니다.

이때, 각각의 서버 인스턴스에 배포된 애플리케이션은 독립적인 Quartz 스케줄러 인스턴스를 가지게 됩니다. 만약 아무런 조치 없이 모든 인스턴스에 동일한 배치 작업을 등록해 둔다면, 설정된 실행 시간에 모든 인스턴스의 Quartz 스케줄러가 동시에 해당 작업을 실행하려고 시도할 것입니다. 이것이 바로 우리가 해결해야 할 Quartz 배치 중복 실행의 원인입니다.

 

인스턴스 스케일 아웃 시 Quartz 배치 중복 실행 방지: 완벽 가이드 2

3. 본론 2: Quartz 배치 중복 실행 방지를 위한 핵심 전략

 

이제 오늘의 핵심인 Quartz 배치 중복 실행을 방지하는 방법에 대해 자세히 알아보겠습니다. 여러 가지 전략이 있지만, 각각의 장단점과 구현 방식을 면밀히 살펴보고 여러분의 프로젝트 상황에 가장 적합한 방법을 선택하는 것이 중요합니다.

 

전략 1: 데이터베이스를 활용한 클러스터링 (가장 안정적이고 권장되는 방법)

 

Quartz 클러스터링은 분산 환경에서 Quartz 배치 중복 실행을 방지하는 가장 대표적이고 안정적인 방법입니다. 여러 인스턴스에 배포된 Quartz 스케줄러들이 하나의 공유된 데이터베이스를 바라보면서 서로의 상태를 동기화하고, 특정 Job이 한 번만 실행되도록 조율합니다.

 

어떻게 동작할까요?

 

Quartz는 데이터베이스에 여러 개의 테이블을 생성하여 Job, Trigger 정보뿐만 아니라 클러스터링에 필요한 잠금(Lock) 정보, 실행 중인 인스턴스 정보 등을 저장합니다.

  1. 공유 데이터베이스: 모든 Quartz 스케줄러 인스턴스가 동일한 데이터베이스를 사용하도록 설정합니다.
  2. 테이블 잠금(Table Locking): Quartz는 Job 실행 시 QRTZ_LOCKS 테이블을 사용하여 분산 락을 획득합니다. 예를 들어, ACQUIRE_NEXT_TRIGGER 락을 획득한 인스턴스만이 다음 실행될 트리거를 가져갈 수 있습니다.
  3. Heartbeat 메커니즘: 각 인스턴스는 주기적으로 데이터베이스에 자신의 ‘살아있음(Heartbeat)’을 알립니다. 이를 통해 다른 인스턴스들은 현재 활성화된 스케줄러 인스턴스들을 파악할 수 있습니다.
  4. Failover: 만약 특정 인스턴스가 비정상적으로 종료되면, 다른 활성 인스턴스들이 데이터베이스를 통해 이를 감지하고 해당 인스턴스에 할당되었던 Job이나 Trigger를 넘겨받아 이어서 실행합니다. 이는 고가용성(High Availability) 측면에서도 큰 장점입니다.

 

필수 설정: quartz.properties 상세 분석

 

Quartz 클러스터링을 활성화하려면 quartz.properties 파일에 몇 가지 중요한 설정을 추가해야 합니다.

Properties

# Quartz 스케줄러 이름 설정
org.quartz.scheduler.instanceName = MyClusteredScheduler

# 인스턴스 ID 설정 (AUTO로 두면 고유하게 생성)
org.quartz.scheduler.instanceId = AUTO

# 데이터베이스에 작업 정보를 저장하도록 설정
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX

# JDBC 드라이버 설정 (사용하는 DB에 맞게)
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.StdJDBCDelegate

# 데이터베이스 연결 정보 (DataSource 설정)
org.quartz.jobStore.dataSource = myDS

# 클러스터링 활성화
org.quartz.jobStore.isClustered = true

# 클러스터링에서 Heartbeat 간격 설정 (밀리초 단위, 기본 7500ms)
org.quartz.jobStore.clusterCheckinInterval = 5000

# SQL 문에서 테이블 접두사 설정 (기본은 QRTZ_)
org.quartz.jobStore.tablePrefix = QRTZ_

# DB 연결 풀 설정 (예: C3P0, HikariCP 등)
org.quartz.jobStore.useProperties = false

# DataSource 설정 (Spring Boot 사용 시 application.yml 등에서 설정)
org.quartz.dataSource.myDS.driver = com.mysql.cj.jdbc.Driver
org.quartz.dataSource.myDS.URL = jdbc:mysql://localhost:3306/quartz_db?useSSL=false&serverTimezone=UTC
org.quartz.dataSource.myDS.user = root
org.quartz.dataSource.myDS.password = password
org.quartz.dataSource.myDS.maxConnections = 5

핵심 설정:

  • org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX: Job 정보를 데이터베이스에 저장하도록 설정합니다. JobStoreTX는 트랜잭션 관리 기능을 제공합니다.
  • org.quartz.jobStore.isClustered = true: 이것이 바로 클러스터링을 활성화하는 핵심 설정입니다. 이 값을 true로 설정하면 Quartz는 데이터베이스를 통해 다른 인스턴스들과 통신하며 중복 실행을 방지합니다.
  • org.quartz.jobStore.clusterCheckinInterval: 각 인스턴스가 데이터베이스에 자신의 상태를 보고하는 주기(Heartbeat)를 설정합니다. 너무 짧으면 DB 부하가 커지고, 너무 길면 Failover 감지가 늦어질 수 있습니다.

 

데이터베이스 테이블 구조 이해 (QRTZ_LOCKS, QRTZ_JOB_DETAILS 등)

 

Quartz 클러스터링을 이해하려면 Quartz가 사용하는 주요 테이블들을 알아두는 것이 좋습니다.

  • QRTZ_JOB_DETAILS: Job의 상세 정보(이름, 그룹, 클래스 등)를 저장합니다.
  • QRTZ_TRIGGERS: Trigger의 상세 정보(이름, 그룹, 타입, Job 키 등)를 저장합니다.
  • QRTZ_CRON_TRIGGERS / QRTZ_SIMPLE_TRIGGERS: 각 Trigger 타입별 상세 설정(Cron 표현식, 반복 횟수 등)을 저장합니다.
  • QRTZ_FIRED_TRIGGERS: 현재 실행 중인 Trigger의 정보를 저장합니다. Job 실행이 시작될 때 여기에 기록되고, 완료되면 삭제됩니다.
  • QRTZ_SCHEDULER_STATE: 클러스터 내의 각 스케줄러 인스턴스의 상태(마지막 Heartbeat 시간 등)를 저장합니다. 이를 통해 다른 인스턴스의 생사 여부를 파악합니다.
  • QRTZ_LOCKS: 가장 중요한 테이블 중 하나입니다. Job 실행 시 해당 테이블에 특정 리소스에 대한 락을 획득하여 중복 실행을 방지합니다. 예를 들어, ACQUIRE_NEXT_TRIGGER 락은 다음 실행될 트리거를 가져갈 권한을 의미하며, 이를 획득한 인스턴스만이 트리거를 실행할 수 있습니다.

 

장점: 높은 안정성, 쉬운 구현

 

  • 높은 안정성: 데이터베이스의 트랜잭션과 락 메커니즘을 활용하므로 분산 환경에서 매우 안정적으로 중복 실행을 방지합니다.
  • 쉬운 구현: quartz.properties 파일에 몇 줄만 추가하면 되므로 구현 난이도가 낮습니다.
  • Failover 지원: 특정 인스턴스가 갑자기 종료되더라도 다른 인스턴스가 해당 인스턴스의 작업을 이어받아 처리하므로 서비스 연속성이 보장됩니다.

 

단점: 데이터베이스 부하, 네트워크 지연 가능성

 

  • 데이터베이스 부하: 모든 인스턴스가 주기적으로 데이터베이스에 접근하여 상태를 동기화하고 락을 관리하므로, 배치 작업이 많거나 클러스터 규모가 커질수록 데이터베이스에 상당한 부하를 줄 수 있습니다.
  • 네트워크 지연: 데이터베이스 접근 시 발생하는 네트워크 지연이 전체 배치 실행 시간에 영향을 줄 수 있습니다.
  • 단일 장애점 (DB): 데이터베이스 자체가 다운되면 전체 Quartz 클러스터가 동작 불능 상태가 됩니다. (물론 DB는 보통 이중화되어 운영되므로 실제 발생 가능성은 낮습니다.)

 

전략 2: 분산 락(Distributed Lock) 활용

 

데이터베이스 부하가 걱정되거나, 더 경량화된 솔루션을 찾고 있다면 Redis, ZooKeeper, Apache Kafka 등의 분산 락 시스템을 활용하는 방법도 고려해 볼 수 있습니다.

 

어떻게 동작할까요?

 

이 방식은 Quartz 자체의 클러스터링 기능 대신, 외부 분산 락 시스템의 도움을 받아 Job의 실행 권한을 제어합니다.

  1. 락 획득 시도: Job이 실행되기 전에, 모든 인스턴스는 Redis나 Zookeeper 등에 특정 Job에 대한 락을 획득하려고 시도합니다.
  2. 단일 실행 보장: 락을 성공적으로 획득한 인스턴스만이 Job을 실행합니다. 다른 인스턴스들은 락 획득에 실패하므로 해당 Job을 실행하지 않고 대기하거나 종료합니다.
  3. 락 해제: Job 실행이 완료되면, 락을 해제하여 다른 인스턴스가 다음 주기에 Job을 실행할 수 있도록 합니다.

 

Redis를 이용한 분산 락 구현 예시 (Spring Data Redis)

 

Spring Boot 환경에서 Redis를 이용한 분산 락을 구현하는 예시입니다. Quartz Job 내부에서 락을 획득/해제하는 로직을 추가해야 합니다.

Java

@Component
public class MyQuartzJob implements Job {

    private final RedissonClient redissonClient; // Redisson 라이브러리 사용 예시

    public MyQuartzJob(RedissonClient redissonClient) {
        this.redissonClient = redissonClient;
    }

    @Override
    public void execute(JobExecutionContext context) throws JobExecutionException {
        String lockKey = "my_batch_job_lock";
        RLock lock = redissonClient.getLock(lockKey);

        try {
            // 락 획득 시도 (3초 대기, 10초 후 자동 해제)
            boolean locked = lock.tryLock(3, 10, TimeUnit.SECONDS);

            if (locked) {
                System.out.println("Job '" + context.getJobDetail().getKey().getName() + "' executed on instance: " +
                                   InetAddress.getLocalHost().getHostName());
                // 실제 배치 로직 수행
                // ...
                System.out.println("Job execution completed.");
            } else {
                System.out.println("Job '" + context.getJobDetail().getKey().getName() + "' skipped on instance: " +
                                   InetAddress.getLocalHost().getHostName() + " (lock not acquired)");
            }
        } catch (InterruptedException | UnknownHostException e) {
            Thread.currentThread().interrupt();
            throw new JobExecutionException("Error acquiring lock", e);
        } finally {
            if (lock.isLocked() && lock.isHeldByCurrentThread()) {
                lock.unlock(); // 락 해제
            }
        }
    }
}

 

장점: 빠른 응답 속도, 데이터베이스 부하 감소

 

  • 빠른 응답 속도: Redis나 Zookeeper는 인메모리 기반이거나 분산 코디네이션 서비스이므로 데이터베이스보다 훨씬 빠르게 락을 획득하고 해제할 수 있습니다.
  • 데이터베이스 부하 감소: Quartz 클러스터링과 달리 데이터베이스에 락 관리를 위한 부하를 주지 않습니다.

 

단점: 락 관리 복잡성, 락 해제 실패 시 문제 발생 가능성

 

  • 락 관리 복잡성: 락 획득/해제 로직을 직접 구현해야 하며, 데드락(Deadlock) 방지, 락 해제 실패 시 처리 등 고려할 사항이 많습니다.
  • 락 해제 실패: 네트워크 문제나 애플리케이션 충돌 등으로 락이 제대로 해제되지 않으면 다음 주기에도 Job이 실행되지 않는 문제가 발생할 수 있습니다. 이를 위해 락에 TTL(Time-To-Live)을 설정하거나, 락 소유권을 확인하는 로직이 필요합니다.
  • 별도 인프라 필요: Redis, Zookeeper 등의 분산 시스템을 별도로 구축하고 관리해야 합니다.

 

전략 3: 외부 스케줄러(External Scheduler) 활용

 

애플리케이션 내부에 Quartz를 내장하는 방식이 아닌, Jenkins, Apache Airflow, Rundeck과 같은 전문적인 외부 스케줄러를 사용하는 방법입니다.

 

어떻게 동작할까요?

 

외부 스케줄러는 배치 Job의 실행을 중앙에서 관리합니다. 애플리케이션 서버는 단지 외부 스케줄러의 호출을 받아 Job을 실행하는 ‘Worker’ 역할만 수행합니다.

  1. Job 등록: 배치 Job을 외부 스케줄러에 등록하고 실행 주기를 설정합니다.
  2. Job 호출: 외부 스케줄러가 설정된 시간에 특정 애플리케이션 인스턴스로 Job 실행 요청을 보냅니다 (예: REST API 호출, SSH 실행 등).
  3. Job 실행: 요청을 받은 애플리케이션 인스턴스는 Job을 실행하고 결과를 외부 스케줄러에 보고합니다.

 

장점: 중앙 집중식 관리, 다양한 기능

 

  • 중앙 집중식 관리: 모든 배치 작업을 한 곳에서 관리하고 모니터링할 수 있어 편리합니다.
  • 다양한 기능: 복잡한 Job 의존성 관리, 재시도 로직, 알림, 대시보드 등 강력한 기능을 제공합니다.
  • 중복 실행 방지 보장: 외부 스케줄러 자체가 중복 실행을 방지하는 메커니즘을 내장하고 있으므로, 별도의 고민이 필요 없습니다.

 

단점: 추가적인 인프라 구축 및 관리 필요

 

  • 추가적인 인프라: 외부 스케줄러를 위한 서버 및 인프라를 구축하고 관리해야 합니다. 이는 초기 설정 비용과 운영 복잡성을 증가시킵니다.
  • 학습 곡선: 새로운 스케줄러 시스템에 대한 학습이 필요할 수 있습니다.

이 방식은 대규모 분산 배치 시스템이나 복잡한 워크플로우를 가진 환경에 더 적합하며, 단순한 Quartz 배치 중복 방지에는 다소 과할 수 있습니다.

 

전략 4: 특정 인스턴스에서만 실행되도록 설정

 

가장 간단한 방법이지만, 실제 프로덕션 환경에서는 추천하지 않는 방법입니다. 특정 애플리케이션 인스턴스에서만 Quartz 스케줄러를 활성화하거나, Job을 등록하도록 설정하는 방식입니다.

 

어떻게 동작할까요?

 

  • 환경 변수 활용: 특정 인스턴스에만 QUARTZ_ENABLED=true와 같은 환경 변수를 설정하고, 애플리케이션 시작 시 해당 변수를 확인하여 Quartz 스케줄러를 초기화합니다.
  • 설정 파일 활용: 특정 프로파일(예: batch-server)에서만 Quartz 관련 설정을 활성화하고, 해당 프로파일로 애플리케이션을 실행합니다.

 

장점: 간단한 구현

 

  • 매우 간단하게 구현할 수 있습니다.

 

단점: 단일 장애점(SPOF) 발생 가능성, 스케일 아웃의 의미 퇴색

 

  • 단일 장애점: Quartz 배치를 실행하는 유일한 인스턴스가 다운되면, 해당 배치 작업은 더 이상 실행되지 않습니다. 이는 서비스의 핵심 기능을 마비시킬 수 있는 치명적인 문제입니다.
  • 스케일 아웃의 의미 퇴색: 부하 분산을 위해 스케일 아웃을 했음에도 불구하고 배치 작업은 여전히 한 인스턴스에 종속되므로, 확장성의 이점을 제대로 누릴 수 없습니다.

따라서 이 방법은 소규모 시스템이나 테스트 환경에서 임시적으로 사용하는 경우를 제외하고는, 안정성과 고가용성이 중요한 프로덕션 환경에서는 절대 추천하지 않습니다.

 

4. 본론 3: 실제 구현 시 고려사항 및 꿀팁

 

앞서 소개한 전략들을 실제로 구현할 때 주의해야 할 점들과 제가 직접 경험하며 얻은 꿀팁들을 공유합니다.

 

데이터베이스 클러스터링 설정 시 주의할 점

 

  • JDBC 드라이버 및 DataSource 설정: 사용하는 데이터베이스(MySQL, Oracle, PostgreSQL 등)에 맞는 JDBC 드라이버를 pom.xml 또는 build.gradle에 정확히 명시하고, application.properties 또는 application.yml에 DataSource 설정을 올바르게 구성해야 합니다. 특히 Spring Boot 환경에서는 DataSource 빈을 Quartz에 연결하는 설정이 필요합니다.
  • 데이터베이스 테이블 생성: Quartz 클러스터링을 사용하려면 Quartz가 사용할 테이블들을 미리 데이터베이스에 생성해야 합니다. Quartz 배포 패키지 내부에 각 데이터베이스에 맞는 tables_xxx.sql 스크립트가 포함되어 있으니, 해당 스크립트를 실행하여 테이블을 생성하세요.
  • clusterCheckinInterval 설정: 너무 짧게 설정하면 DB에 과도한 부하를 줄 수 있고, 너무 길게 설정하면 Failover 감지 시간이 길어져 서비스 연속성에 영향을 줄 수 있습니다. 일반적으로 5초에서 30초 사이의 값을 사용하는 경우가 많습니다. 시스템의 부하 특성과 요구 사항에 맞춰 적절한 값을 찾아야 합니다.
  • 트랜잭션 관리: Quartz 클러스터링은 내부적으로 트랜잭션을 사용합니다. 스프링 환경에서 @Transactional 어노테이션을 사용하여 Job 내의 비즈니스 로직을 트랜잭션으로 묶는 경우, Quartz 내부 트랜잭션과 충돌하지 않도록 주의해야 합니다. 보통 Quartz는 자체 트랜잭션을 관리하므로, Job 내부에서는 별도의 트랜잭션 관리가 필요하지 않거나 PROPAGATION_REQUIRES_NEW 등으로 분리하는 것을 고려할 수 있습니다.

 

분산 락 구현 시 타임아웃 및 재시도 전략

 

Redis나 Zookeeper 같은 분산 락을 사용하는 경우, 락 획득 실패 시 처리 전략이 매우 중요합니다.

  • 락 획득 타임아웃: 락을 무한정 기다리지 않도록 tryLock(waitTime, leaseTime, unit)과 같이 타임아웃을 설정해야 합니다. waitTime은 락을 기다리는 최대 시간, leaseTime은 락을 획득했을 때 해당 락이 자동으로 해제될 시간(TTL)입니다.
  • 자동 해제 (TTL): leaseTime을 설정하여 Job이 비정상적으로 종료되어도 락이 영구적으로 걸려있지 않도록 해야 합니다. 이는 데드락을 방지하는 중요한 메커니즘입니다.
  • 재시도 전략: 락 획득에 실패했을 때 즉시 포기할 것인지, 아니면 일정 시간 대기 후 재시도할 것인지 결정해야 합니다. 시스템의 중요도에 따라 재시도 횟수와 간격을 조절합니다. 예를 들어, Exponential Backoff 전략을 사용하여 재시도 간격을 점진적으로 늘려나갈 수 있습니다.
  • 락 소유권 확인: 락을 해제하기 전에 현재 스레드가 락의 소유자인지 반드시 확인해야 합니다. lock.isHeldByCurrentThread()와 같은 메서드를 사용합니다.

 

로깅(Logging)의 중요성: 중복 실행 감지 및 문제 진단

 

어떤 방식을 사용하든, 배치 작업의 실행 로그를 상세하게 남기는 것은 매우 중요합니다.

  • 실행 시작/종료 로그: 각 Job이 언제 시작해서 언제 종료되었는지 명확하게 기록합니다.
  • 인스턴스 정보: 어떤 인스턴스에서 Job이 실행되었는지(호스트명, IP 주소 등) 로그에 포함합니다.
  • 락 획득/해제 로그: 분산 락을 사용하는 경우, 락 획득 시도, 성공/실패 여부, 락 해제 등의 과정을 상세히 기록합니다.
  • 오류 로그: 배치 작업 실행 중 발생하는 모든 예외와 오류를 상세하게 기록하여 문제 발생 시 신속하게 원인을 파악할 수 있도록 합니다.

충분한 로깅은 문제 발생 시 신속한 진단을 가능하게 하고, 중복 실행이 의도치 않게 발생했을 때 그 원인을 추적하는 데 결정적인 역할을 합니다.

 

모니터링(Monitoring) 시스템 구축

 

로깅과 더불어, 배치 작업의 실행 상태를 실시간으로 모니터링할 수 있는 시스템을 구축하는 것이 좋습니다.

  • Job 실행 통계: 각 Job의 실행 횟수, 성공/실패 여부, 평균 실행 시간 등을 그래프로 시각화하여 비정상적인 패턴을 즉시 감지할 수 있도록 합니다.
  • 중복 실행 경고: 동일한 Job이 짧은 시간 내에 여러 번 실행되는 경우 경고 알림을 받을 수 있도록 설정합니다.
  • 시스템 리소스 모니터링: CPU, 메모리, 디스크 I/O 등 서버 리소스 사용량을 모니터링하여 배치 작업으로 인한 시스템 부하를 파악합니다.
  • 데이터베이스 연결 수 모니터링: Quartz 클러스터링 사용 시 데이터베이스 커넥션 풀 사용량을 모니터링하여 과부하를 미리 감지합니다.

Grafana, Prometheus, ELK Stack(Elasticsearch, Logstash, Kibana) 등의 도구를 활용하여 강력한 모니터링 시스템을 구축할 수 있습니다.

 

Graceful Shutdown 구현: 실행 중인 배치 작업의 안전한 종료

 

서버를 재시작하거나 배포할 때, 현재 실행 중인 배치 작업이 강제로 종료되지 않고 안전하게 마무리될 수 있도록 Graceful Shutdown을 구현해야 합니다.

  • Quartz 스케줄러 종료 설정: Quartz는 scheduler.shutdown(waitForJobsToComplete) 메서드를 제공합니다. waitForJobsToComplete를 true로 설정하면 현재 실행 중인 Job이 완료될 때까지 스케줄러가 종료되지 않고 기다립니다.
  • JVM 종료 후크: Spring Boot 애플리케이션에서는 기본적으로 Graceful Shutdown을 지원하지만, shutdown 훅이나 @PreDestroy 어노테이션 등을 활용하여 애플리케이션 종료 시 Quartz 스케줄러를 안전하게 종료하도록 명시적인 로직을 추가하는 것이 좋습니다.

Java

// Spring Framework 예시
@Bean(destroyMethod = "shutdown") // shutdown 메서드를 호출하도록 설정
public SchedulerFactoryBean scheduler(DataSource dataSource, JobFactory jobFactory) throws IOException {
    SchedulerFactoryBean factory = new SchedulerFactoryBean();
    factory.setDataSource(dataSource);
    factory.setJobFactory(jobFactory);
    factory.setQuartzProperties(quartzProperties()); // quartz.properties 로드
    factory.setApplicationContextSchedulerContextKey("applicationContext");
    factory.setWaitForJobsToCompleteOnShutdown(true); // 이 부분이 중요!
    return factory;
}

setWaitForJobsToCompleteOnShutdown(true)는 서버 재시작 시점에 이미 시작된 배치 작업이 완료될 때까지 기다려 주어 데이터 유실이나 정합성 문제를 방지합니다.

 

테스트 환경에서의 검증: 실제 서비스 반영 전 충분한 테스트

 

아무리 좋은 솔루션이라도 실제 운영 환경에 적용하기 전에 반드시 충분한 테스트를 거쳐야 합니다.

  • 다중 인스턴스 환경 구성: 최소 2개 이상의 인스턴스를 띄워 실제 스케일 아웃 환경을 시뮬레이션합니다.
  • 중복 실행 테스트: 의도적으로 Job의 실행 시간을 겹치게 설정하거나, 인스턴스를 갑자기 종료시키는 등의 상황을 연출하여 중복 실행 방지 메커니즘이 제대로 동작하는지 확인합니다.
  • 부하 테스트: 동시 사용자 증가 상황을 시뮬레이션하여 배치 작업이 정상적으로 처리되는지, 데이터베이스나 다른 시스템에 과도한 부하를 주지는 않는지 확인합니다.
  • Failover 테스트: 특정 인스턴스를 갑자기 종료시켰을 때, 다른 인스턴스들이 해당 인스턴스의 작업을 정상적으로 이어받아 처리하는지 확인합니다.

철저한 테스트만이 안정적인 서비스 운영을 보장합니다.

 

5. FAQ (자주 묻는 질문)

 

이제 여러분이 궁금해하실 만한 질문들을 모아 답변해 드리겠습니다!

 

Q1: Quartz 클러스터링은 어떤 데이터베이스에서든 잘 작동하나요?

 

A1: 네, 대부분의 관계형 데이터베이스에서 잘 작동합니다. MySQL, PostgreSQL, Oracle, MS SQL Server 등 주요 데이터베이스를 지원합니다. Quartz 배포 패키지에 포함된 tables_xxx.sql 스크립트를 사용하여 해당 데이터베이스에 맞는 테이블을 생성하고, quartz.properties에서 올바른 JDBC 드라이버와 DataSource 설정을 해주면 됩니다.

 

Q2: 분산 락 방식이 데이터베이스 클러스터링보다 항상 좋은가요?

 

A2: 아닙니다. ‘좋다’의 기준은 상황에 따라 다릅니다.

  • 데이터베이스 클러스터링은 설정이 비교적 간단하고 Quartz 자체에서 제공하는 안정적인 방법입니다. 대부분의 경우에 권장됩니다.
  • 분산 락 방식 (Redis, Zookeeper 등)은 데이터베이스에 대한 부하를 줄이고, 락 획득/해제 속도가 빠르다는 장점이 있습니다. 하지만 락 관리 로직을 직접 구현해야 하고, 별도의 분산 시스템을 구축/관리해야 한다는 단점이 있습니다. 배치 작업의 특성(실행 빈도, 중요도), 시스템 아키텍처, 팀의 기술 스택 등을 고려하여 가장 적합한 방법을 선택해야 합니다. 일반적으로는 Quartz 클러스터링으로 시작하여, DB 부하 등 성능 문제가 발생할 경우 분산 락 방식으로 전환하는 것을 고려할 수 있습니다.

 

Q3: 스케일 아웃된 인스턴스 중 하나가 죽으면 배치는 어떻게 되나요?

 

A3: Quartz 클러스터링을 사용하고 있다면, 걱정하지 않으셔도 됩니다. Quartz는 Heartbeat 메커니즘을 통해 다른 인스턴스의 상태를 지속적으로 모니터링합니다. 만약 특정 인스턴스가 Heartbeat를 보내지 않아 죽었다고 판단되면, 해당 인스턴스에 할당되었던 미완료 Job이나 Trigger를 다른 활성 인스턴스가 이어받아(Failover) 실행합니다. 이는 Quartz 클러스터링의 가장 큰 장점 중 하나입니다. 분산 락 방식을 사용하고 있다면, 락에 설정된 TTL(Time-To-Live)이 중요합니다. 인스턴스가 죽더라도 TTL 시간이 지나면 락이 자동으로 해제되어 다른 인스턴스가 락을 획득하고 Job을 실행할 수 있습니다. 하지만 TTL이 너무 길게 설정되어 있다면, 다음 Job 실행 주기까지 락이 해제되지 않아 Job이 지연될 수 있습니다.

 

Q4: Quartz 클러스터링 시 성능 저하가 발생할 수도 있나요?

 

A4: 네, 가능성이 있습니다. 주로 다음과 같은 경우에 성능 저하가 발생할 수 있습니다.

  • 과도한 clusterCheckinInterval 설정: clusterCheckinInterval 값이 너무 짧으면 모든 인스턴스가 짧은 주기로 데이터베이스에 Heartbeat를 보내게 되어 DB에 불필요한 부하를 줄 수 있습니다.
  • 잦은 Job 실행: 매우 짧은 주기로 많은 Job이 실행되면, QRTZ_LOCKS 테이블에 대한 락 경합이 심해져 DB 부하가 증가하고 Job 실행이 지연될 수 있습니다.
  • 데이터베이스 성능 부족: 데이터베이스 서버 자체의 성능이 충분하지 않거나, 네트워크 지연이 심한 경우 클러스터링 성능에 영향을 줄 수 있습니다. 이러한 문제들은 적절한 clusterCheckinInterval 설정, Job의 실행 주기 조정, 데이터베이스 성능 최적화, 그리고 경우에 따라서는 분산 락 방식으로의 전환 등을 통해 해결할 수 있습니다.

 

6. 결론: 안정적인 배치 운영을 위한 마지막 당부

 

오늘 우리는 동일한 인스턴스로 스케일 아웃한 경우 인스턴스 안에 포함된 Quartz 배치가 두 인스턴스에서 동시에 실행되는 것을 방지하는 방법에 대해 심도 있게 알아보았습니다. Quartz 클러스터링, 분산 락 활용, 외부 스케줄러 사용 등 다양한 전략들을 살펴보았으며, 각 방법의 장단점과 구현 시 고려사항까지 자세히 다루었습니다.

이 중 가장 보편적이고 안정적인 방법은 데이터베이스를 활용한 Quartz 클러스터링입니다. 대부분의 경우 이 방법으로 충분히 안정적인 배치 운영 환경을 구축할 수 있습니다. 만약 데이터베이스 부하가 문제가 되거나 더 높은 수준의 유연성이 필요하다면 Redis 등의 분산 락을 고려해 볼 수 있으며, 대규모 분산 배치 시스템을 구축해야 한다면 Jenkins, Airflow와 같은 외부 스케줄러가 좋은 대안이 될 수 있습니다. 하지만 어떤 방법을 선택하든, 아래 세 가지는 잊지 마세요.

  1. 충분한 로깅: 문제가 발생했을 때 신속하게 원인을 파악할 수 있도록 상세한 로그를 남기세요.
  2. 지속적인 모니터링: 배치 작업의 실행 상태와 시스템 리소스를 꾸준히 모니터링하여 비정상적인 상황을 조기에 감지하세요.
  3. 철저한 테스트: 실제 운영 환경에 적용하기 전에 충분한 테스트 환경에서 중복 실행 방지 메커니즘과 Failover 기능을 검증하세요.

안정적인 배치 운영은 서비스의 신뢰도를 높이고, 개발팀의 불필요한 야근을 줄여줍니다. 😉 오늘 알려드린 내용들이 여러분의 서비스가 한 단계 더 성장하는 데 도움이 되기를 진심으로 바랍니다. 궁금한 점이 있다면 언제든지 댓글로 질문해주세요! 함께 성장하는 개발 문화, 우리 모두 만들어가요!