MongoDB 변경 스트림을 사용한 Cron 스케줄 핫스와핑

백그라운드 작업이 코드나 환경 변수에 내장된 cron 표현식으로 실행된다면, 작업 실행 시간을 변경하는 것은 재배포를 의미합니다. 보고서 시간을 오전 9시에서 오전 8시로 옮기면, 숫자 하나를 바꾸기 위해 빌드를 내보내고, 파이프라인을 실행하며, 프로세스를 재시작해야 합니다. 이는 느리고, 변경에 비해 위험이 크며, 시스템을 건강하게 유지하는 사소한 조정을 방해합니다. 해결책은 스케줄을 데이터베이스에 저장하고 스케줄러가 실시간으로 편집에 반응하도록 하는 것입니다. MongoDB 변경 스트림은 이 반응을 즉각적으로 만듭니다. 이 게시물에서는 설계, 안정성을 높이는 재연결 처리, 그리고 필요 이상의 장치가 되는 경우를 다룹니다.

코드 내 스케줄의 문제점

하드코딩된 스케줄은 완전히 다른 속도와 완전히 다른 이유로 변경되는 두 가지를 결합합니다. 작업의 로직은 작업이 변경될 때 변경되며, 이는 빌드에 속하는 엔지니어링 결정입니다. 작업의 타이밍은 보고서가 회의 전에 도착해야 하거나 무거운 작업을 피크 시간대 밖으로 옮겨야 하는 등 운영상의 필요가 변경될 때 바뀌며, 이는 코드와는 아무런 관련이 없는 운영상의 결정입니다. 이 둘을 묶는 것은 모든 타이밍 조정이 코드 배포라는 무거운 부담을 수반한다는 것을 의미합니다.

비용은 단지 배포 시간만이 아닙니다. 그것은 위축 효과입니다. 스케줄 변경이 프로덕션 배포가 되면 사람들은 그 일을 그만둡니다. 아무도 작업을 한 시간 옮기기 위해 빌드를 배포하고 싶어하지 않기 때문에 스케줄은 실제 필요와 어긋나게 됩니다. 스케줄은 릴리스해야 하는 코드가 아니라 편집할 수 있는 데이터여야 합니다.

데이터로서의 스케줄

첫 번째 단계는 스케줄을 컬렉션에 넣는 것입니다. 각 작업당 하나의 문서를 사용하고 cron 표현식을 필드로 포함합니다.

// One document per scheduled job. The cron expression is data, not code.
type Schedule struct {
	ID        string    `bson:"_id"`        // e.g. "daily_report"
	CronExpr  string    `bson:"cron_expr"`  // e.g. "0 9 * * *"
	UpdatedAt time.Time `bson:"updated_at"`
}

이제 스케줄 변경은 배포 없이 단일 데이터베이스 업데이트로 이루어집니다.

db.schedules.updateOne(
  { _id: "daily_report" },
  { $set: { cron_expr: "0 8 * * *", updated_at: new Date() } }
)

하지만 데이터만으로는 충분하지 않습니다. 무언가가 변경 사항을 감지하고 실행 중인 스케줄러를 재구성해야 합니다. 이를 위한 두 가지 방법이 있으며, 그 둘의 차이점이 이 게시물의 핵심입니다.

폴링 대 반응

간단한 접근 방식은 폴링하는 것입니다. 매분 스케줄러는 컬렉션을 다시 읽고 변경된 사항이 있으면 타이머를 다시 빌드합니다. 이 방식은 작동하며 많은 시스템에서 전적으로 적합합니다. 약점은 지연 시간과 낭비입니다. 변경 사항이 적용되려면 전체 폴링 간격만큼의 시간이 걸릴 수 있으며, 대부분의 폴링에서는 변경된 사항이 없어 순수한 오버헤드만 발생합니다. 지연 시간을 줄이기 위해 간격을 줄이면 낭비가 늘어납니다. 이것은 좋은 설정은 없고 덜 나쁜 설정만 있는 다이얼과 같습니다.

변경 스트림은 이 다이얼을 제거합니다. 타이머에서 "변경된 사항이 있습니까?"라고 묻는 대신, 스케줄러는 라이브 피드를 구독하고 무언가 변경되는 즉시 알림을 받습니다. 스케줄 편집은 거의 실시간으로 전파되며, 아무것도 변경되지 않으면 스케줄러는 아무것도 하지 않고 비용도 발생하지 않습니다. 동시에 더 낮은 지연 시간과 더 적은 작업을 얻게 되는데, 이는 이 메커니즘에 필요한 추가적인 주의를 기울일 가치가 있을 만큼 이례적인 일입니다.

변경 스트림이란

변경 스트림은 컬렉션에서 발생하는 쓰기 작업에 대한 실시간 순차 피드입니다. 내부적으로는 데이터베이스가 복제본 세트 멤버를 동기화 상태로 유지하는 데 사용하는 것과 동일한 복제 로그를 읽으므로, 폴링 없이 inserts, updates, deletes가 커밋되는 즉시 순서대로 볼 수 있습니다. 데몬은 스트림을 한 번 열고 블로킹 상태가 되며, 스케줄 문서가 변경될 때마다 이벤트를 수신합니다.

// Watch the schedules collection. Block until an edit arrives, then apply it.
stream, err := coll.Watch(ctx, mongo.Pipeline{})
if err != nil {
	return fmt.Errorf("open change stream: %w", err)
}
defer stream.Close(ctx)

for stream.Next(ctx) {
	var event struct {
		FullDocument Schedule `bson:"fullDocument"`
	}
	if err := stream.Decode(&event); err != nil {
		logger.Warn("decode change event", logger.Err(err))
		continue
	}
	scheduler.Reload(event.FullDocument) // rebuild this job's timer
}

운영자가 한 줄짜리 업데이트를 실행하면, 데몬은 즉시 이벤트를 수신하고 영향을 받은 타이머만 다시 빌드합니다. 재배포, 재시작, 폴링 간격 대기가 필요 없습니다. 이제 스케줄은 진정한 실시간 데이터가 됩니다.

변경 스트림은 복제 로그를 읽기 때문에 복제본 세트가 필요하며, 독립 실행형 서버는 이 로그를 유지하지 않습니다. 모든 프로덕션 MongoDB 배포는 이미 복제본 세트이므로 이것이 새로운 요구사항이 되는 경우는 드물지만, 이 기능을 사용할 수 없는 로컬 단일 노드 설정에서 사용하기 전에 알아두는 것이 좋습니다.

신뢰성을 보장하는 부분: 재개 토큰

단순한 변경 스트림에는 공백이 있습니다. 네트워크 장애, 장애 조치, 잠시 재시작 등으로 연결이 끊겼을 때 단순히 스트림을 다시 열면, 현재 시점부터 재개되어 연결이 끊겨 있던 동안 발생한 모든 변경 사항을 조용히 놓치게 됩니다. 30초간의 재연결 동안 수정된 스케줄은 손실될 것이고, 데이터베이스는 다른 내용을 담고 있는데도 데몬은 계속해서 이전 타이밍으로 실행될 것입니다. 이러한 불일치는 바로 이 전체 설계가 막으려고 했던 버그입니다.

변경 스트림은 재개 토큰으로 이 문제를 해결합니다. 모든 이벤트는 피드에서의 위치를 표시하는 토큰을 가지고 있습니다. 처리한 최신 토큰을 영속화하고, 연결이 끊긴 후에는 현재 시점 대신 해당 토큰부터 스트림을 다시 엽니다. 데이터베이스는 놓친 모든 변경 사항을 순서대로 다시 재생하고, 정확히 중단했던 지점부터 따라잡게 됩니다.

// Resume from the last processed position so a reconnect misses nothing.
opts := options.ChangeStream()
if resumeToken != nil {
	opts.SetResumeAfter(resumeToken)
}
stream, err := coll.Watch(ctx, mongo.Pipeline{}, opts)
// ... after handling each event, persist stream.ResumeToken() durably

각 이벤트를 처리한 후 데몬이 재시작되어도 유지될 만큼 영속적으로 토큰을 저장하는 것이 원칙입니다. 재연결 시에는 이를 로드하여 거기서부터 재개합니다. 이것이 준비되면 스트림은 빠를 뿐만 아니라, 장기 실행되는 모든 컨슈머에서 불가피한 연결 끊김에도 공백이 없어집니다. 토큰은 편리한 기능을 신뢰할 수 있는 기능으로 바꿔주는 요소입니다.

한 가지 주의할 점은, 재개 토큰은 유한한 크기를 가진 복제 로그에 변경 사항이 아직 존재할 동안에만 유효하다는 것입니다. 데몬이 오랫동안 다운되어 가장 오래된 미처리 변경 사항이 이미 로그에서 밀려났다면, 토큰은 무효화되고 스트림은 그 지점부터 재개할 수 없습니다. 이러한 경우는 무효한 재개 오류를 감지하고 컬렉션의 전체 리로드로 폴백하여 처리하며, 이는 스케줄러를 현재의 진실된 상태로 다시 동기화합니다. 이는 어차피 최초 시작 시에도 원할, 처음부터 다시 조정하는 경로와 동일합니다.

중단 없이 변경 사항 적용하기

이벤트를 수신하는 것은 작업의 절반에 불과합니다. 실행 중인 스케줄러를 변경하는 것이므로 적용 시에는 신중해야 합니다. 한 스케줄의 편집이 다른 스케줄을 방해하거나 교체 중 이중 실행의 위험을 초래하지 않도록, 모든 타이머를 해체하고 다시 생성하는 대신 변경된 작업에 대한 타이머만 특정하여 다시 빌드하십시오. 해당 job id의 이전 타이머를 취소하고, 업데이트된 cron 표현식으로 새 타이머를 설치하며, 다른 모든 작업은 그대로 두십시오. resume-from-token이 재연결 경계(reconnect boundary)에서 유발할 수 있는 것처럼 동일한 이벤트를 두 번 적용하더라도, 스케줄러가 한 번 적용했을 때와 동일한 상태가 되도록 재구성을 멱등성(idempotent) 있게 유지하십시오. 바로 그 멱등성이 재개된 스트림의 최소 한 번(at-least-once) 특성을 안전하게 만듭니다.

단순하게 유지해야 할 때

변경 스트림은 스케줄 변경이 너무 잦아서 재배포가 정말 부담스러울 때나 변경 사항이 적용되는 지연 시간이 실제로 중요할 때 적합한 도구입니다. 스케줄이 거의 변경되지 않는다면 운영상의 이점은 작으며, 단순한 재시작을 통한 리로드나 느린 폴링 방식이 구축할 것도 적고 고장 날 것도 적습니다. 누군가 일 년에 한두 번 스케줄을 편집하는 시스템에 라이브 이벤트 소비자, 재개 토큰 영속성, 그리고 유효하지 않은 토큰 폴백을 추가하지 마십시오.

더 깊은 원칙은 cron을 넘어 일반화됩니다. 코드상의 이유가 아닌 운영상의 이유로 변경되는 모든 설정은 실행 중인 시스템이 감시하는 데이터 저장소에 있어야 하며, 그래야 변경 작업이 릴리스가 아닌 편집이 됩니다. 스케줄은, 이전에는 배포였던 타이밍 변경이 한 줄짜리 업데이트가 된다는 점에서 이점이 매우 구체적이어서 명확한 예시이지만, 동일한 패턴이 피처 플래그, 라우팅 규칙, 그리고 사용량 제한에도 적합합니다. 설정을 데이터로 저장하고, 변경 스트림으로 감시하며, 재개 토큰으로 재연결을 처리하십시오. 이 세 가지 조합이 라이브 설정을 단순히 편리한 것을 넘어 신뢰할 수 있게 만드는 요소입니다.