53분짜리 크론 하나에서 시작한 배포 종료 설계

📚 Overview

한동안 배포할 때 사람이 기다리는 시간이 있었다. (한.. 오전 09:00 ~ 10:00 사이쯤?)

이메일을 보내는 크론 하나가 한 회차에 53분 걸렸기 때문이다. 그게 도는 중에 배포하면 발송이 중간에서 끊길 것 같아, 끝나기를 기다렸다가 배포한 적이 있다.

서비스는 Kubernetes 위에서 돌고 ArgoCD 가 롤링 업데이트로 배포한다. 새 파드가 준비되면 구 파드는 정해진 유예 시간 안에 사라진다. 53분짜리 작업이 그 안에 끝날 수는 없으니, 기다리는 쪽을 사람이 맡고 있었던 셈이다.

처음엔 이걸 성능 문제로 봤다. 크론이 느리니 빠르게 만들면 되는 일이라고.

그런데 실행 시간을 분해해보니 대부분이 의도적으로 넣은 대기 였다. 메일 서버의 rate limit 에 걸려 발송이 거부되는 것을 막기 위해 한 건과 다음 건 사이에 간격을 두고 있었다. 성능을 위해 줄여도 되는 값이 아니라, 발송이 성립하기 위한 조건이었다.

이 크론은 v1 서비스에서 v2 로 마이그레이션한 코드였다. 마이그레이션의 안전 장치로 v1 의 동작을 먼저 테스트로 고정하고 그 테스트를 통과시키는 방식을 택했는데, 덕분에 기능이 어긋나는 일은 없었지만 v1 이 갖고 있던 구조적 불합리함까지 계약으로 함께 굳어졌다. 한 프로세스가 순차로 발송하며 그 사이를 대기로 메운다는 형태가 정확히 그런 항목이었다.

그래서 목표를 다시 잡았다. 크론을 빠르게 만드는 것이 아니라, 크론 한 회차를 짧게 유지하는 것 과 배포가 진행 중인 일을 스스로 기다리게 만드는 것 이다. 이 둘이 맞물려야 사람이 배포 앞에서 기다릴 필요가 없어진다.

그런데 후자는 아무 장치가 없었다. 종료 신호를 받으면 애플리케이션이 곧바로 프로세스를 끝내고 있어서, 진행 중인 요청이나 돌고 있는 크론을 기다리는 절차 자체가 없었다. 배포 안정성이 유예 시간과 운에 맡겨져 있던 것이다.

할 일은 두 개였다.

발송을 크론 밖으로 내보내 한 회차를 짧게 만든다.
graceful shutdown 을 넣어 남은 일을 애플리케이션이 기다리게 한다.

이번 포스팅은 이 두 가지를 순서대로 해결한 기록이다.

1. 기다릴 수 있는 크기로 만들기 — 발송을 크론 밖으로

먼저 53분을 분해했다. 한 회차 945초 가운데 540초(57%)가 의도적인 대기 였다. 발송에 성공할 때마다 5초를 쉬었고, 그 회차의 대상이 108건이었다.

이 대기는 줄일 수 없다. 메일 서버가 받아주는 속도에 맞춘 값이라, 줄이면 발송이 거부되기 시작한다. 그렇다면 바꿀 수 있는 건 하나뿐이었다. 한 프로세스가 108건의 대기를 전부 혼자 짊어지는 구조 다.

그래서 크론은 보낼 메시지를 outbox 테이블에 적재하기만 하고, 릴레이가 그 행을 Kafka 로 발행하고, 컨슈머가 실제 발송을 맡도록 나눴다. 5초 대기는 컨슈머 쪽으로 옮겨간다.

중복은 UPDATE 한 줄로 막는다

outbox 릴레이는 발행을 놓치지 않는 대신 중복을 떠안는다. 여기서는 발행하기 전에 시도 횟수부터 올리는 방식 으로 그 중복에 상한을 뒀다.

const affected = await this.outboxRepository.nativeUpdate(
  {
    outboxUuid,
    status: OutboxStatus.Pending,
    // 내가 읽은 뒤로 아무도 건드리지 않았고($eq), 시도 횟수가 상한 아래일 때($lt)만 갱신된다.
    attempts: { $eq: attempts, $lt: Outbox.MaxAttempts },
  },
  {
    attempts: raw('attempts + 1'),
    nextAttemptAt,
  },
);

// 한 건이 갱신됐을 때에만 이 실행이 발행할 권리를 가진다.
return affected === 1;

$eq 는 여러 파드가 같은 행을 동시에 집는 경쟁을, $lt 는 끝없이 실패하는 행을 막는다.

다만 모든 실패를 상한까지 재시도하지는 않는다. 수신 불가 주소처럼 다시 보내도 결과가 같은 오류는 재시도 없이 바로 종결하도록 했다.

횟수를 발행 뒤에 올리면 문제가 생긴다. 발행은 성공했는데 상태 기록이 실패한 행은 시도 횟수가 그대로인 채 pending 으로 남고, 다음 주기가 그 행을 계속 다시 집는다. 같은 메시지가 끝없이 발행되는 것이다. 먼저 올려 두는 것만으로 이 반복에 끝이 생긴다.

대기는 컨슈머로 옮겨간다

컨슈머는 메시지를 받아 메일을 보낸다. 문제의 출발점이었던 5초 대기가 여기로 온다.

@EventPattern(OutboxTopic.EmailDispatch)
async handleEmailDispatch(@Payload() message: EmailDispatchMessage): Promise<void> {
  // 대기는 사라진 것이 아니라 여기로 옮겨왔다. 다만 이 대기를 짊어지는 것은
  // 배포가 완주를 기다려야 하는 크론이 아니라, 죽어도 다시 집히는 컨슈머다.
  await this.emailRateLimiter.acquire();
  await this.emailSender.send(message);
}

같은 5초를 여전히 기다리지만 성질이 달라졌다. 이전에는 크론 한 회차가 108건의 대기를 혼자 짊어졌고, 배포는 그 회차가 끝나길 기다려야 했다. 지금은 여러 컨슈머가 나눠 가져가고, 하나가 도중에 죽어도 처리되지 않은 메시지는 다른 컨슈머가 다시 받는다.

이 변화가 종료 설계에 준 것은 두 가지다.

크론이 짧아졌다. 메시지를 적재하는 시간만 쓰니 실행 시간이 초 단위로 내려왔고, 비로소 “크론을 몇 초까지 기다릴 것인가” 를 물을 수 있게 되었다.
릴레이와 컨슈머는 기다려줄 필요가 없다. 도중에 죽어도 다른 쪽이 이어받으니, 전달이 끝까지 되는지가 프로세스 생존과 무관하다.

이 순서를 뒤집어 종료 대기를 먼저 넣었다면, 상한을 몇 초로 잡든 매 배포가 강제 종료로 끝났을 것이다. 53분을 기다려주는 상한은 존재할 수 없다.

2. 기다리는 절차를 애플리케이션이 소유하게 만들기

Nest 에는 종료 훅이 있고 app.enableShutdownHooks() 한 줄로 켤 수 있다. 처음엔 이걸로 끝날 일이라고 생각했다.

넣어봤지만 아무것도 달라지지 않았다. 원인은 이미 SIGTERM 리스너가 하나 등록되어 있었다는 것 이었다.

// 사내 텔레메트리 패키지가 심어 둔 리스너 — 트레이스를 비운 뒤 프로세스를 끝낸다
process.on('SIGTERM', () => {
  sdk.shutdown().finally(() => process.exit(0));
});

종료 훅을 추가하면 같은 신호를 두 리스너가 동시에 받는다. 그리고 트레이스를 비우는 쪽이 수 밀리초 안에 process.exit(0) 을 호출하므로, Nest 가 막 시작한 app.close() 는 끝까지 가지 못하고 잘린다.

즉 문제는 종료 절차가 없다 는 것이 아니라 종료 순서를 누가 소유하는가 였다.

그래서 이미 등록된 리스너를 걷어내 보관하고, 우리 절차가 끝난 마지막에 다시 불러주기로 했다.

const handlers: SignalHandler[] = [];

for (const signal of params.signals) {
  handlers.push(...(emitter.listeners(signal) as SignalHandler[]));
  emitter.removeAllListeners(signal);
}

return {
  count: handlers.length,
  invoke(signal: NodeJS.Signals): void {
    for (const handler of handlers) {
      // 한 건이 throw 하면 뒤 리스너와 정상 종료 경로가 통째로 사라지므로 건별로 격리한다.
      try {
        handler.call(emitter, signal);
      } catch (error) {
        params.logger.error('gracefulShutdown phase=flush failed', error);
      }
    }
  },
};

패키지가 SDK 인스턴스를 노출하지 않아 sdk.shutdown() 을 직접 부를 수는 없었다. 리스너 자체를 함수로 들고 있다가 되부르는 방식이 유일한 선택이었다.

호출 자리는 NestFactory.create 이전, 모듈 로드 직후다. 부팅 도중에 오는 신호까지 덮어야 하므로 앱 참조는 값이 아니라 지연 함수로 넘겼다.

얼마나 기다릴 것인가 — 네 개의 값이 한 묶음인 이유

순서를 소유하게 되자 대기 상한을 정할 차례였다. 처음엔 항목별로 따로 정하면 되는 값이라고 생각했는데, 실제로는 네 개가 서로를 제약하는 하나의 예산 이었다.

export const ShutdownTimeout = {
  // 정상 응답 중 가장 긴 외부 서버 호출 상한 20초 + 여유 5초. 이 아래로 내리면 성공 응답을 끊는다.
  HttpDrainMs: 25_000,
  ConnectionPollMs: 250,
  // 가장 긴 크론의 실행 시간은 이 값을 넘지만 하루 1회라 그 시간대 배포를 피한다. 그 외 크론은 이 값 안에 끝나야 한다.
  CronDrainMs: 90_000,
  // 크론 대기 90초(요청 대기 25초와 동시 진행) + app.close 와 텔레메트리 flush 예산 20초.
  // k8s 유예 130초에서 preStop 10초를 뺀 120초 안에 들어간다.
  HardDeadlineMs: 110_000,
} as const;

값의 근거는 실측에서 가져왔다. HTTP 25초는 정상 응답 중 가장 느린 경로가 외부 호출 20초 상한에 걸리는 API 였기 때문이고, 크론 90초는 APM 에서 크론별 실행 시간 최댓값을 뽑아 정했다.

이 과정에서 하나를 배웠다. 조회 창의 길이가 결론을 바꾼다. 24시간 창에서는 가장 긴 크론의 실행 시간이 80초 정도라 90초가 넉넉해 보였는데, 7일 창으로 늘리자 같은 크론이 121초까지 튀는 날이 있었다.

그 크론은 자정에 하루 한 번만 도는 종류였다. 상한을 올려 모든 배포를 느리게 만드는 대신, 그 시간대를 배포 금지 구간으로 정하고 저장소의 PR 규칙 문서에 넣었다. main 브랜치로 배포 PR 을 만들 때 확인하는 항목이 되도록 해서, 사람이 기억하지 않아도 배포 흐름이 걸러주게 했다.

마지막 줄의 110초는 우리가 고른 값이 아니라 주어진 시간에서 거꾸로 계산한 값 이다.

Kubernetes 는 파드에 종료 신호를 보낸 뒤 130초를 기다려주고, 그래도 끝나지 않으면 강제로 죽인다. 그중 처음 10초는 새 요청이 더 들어오지 않게 잠시 멈춰 있는 시간(preStop)이라, 애플리케이션이 실제로 쓸 수 있는 건 120초다. 그 안에서 확실히 끝내기 위해 110초가 되면 스스로 멈추도록 했다.

이 130초는 배포할 때뿐 아니라 트래픽이 줄어 파드 수를 줄일 때도 똑같이 쓰인다. 그래서 넉넉하게 늘리면 그만큼 모든 축소가 느려진다.

남는 여유가 10초뿐이니, HTTP 요청과 크론을 차례로 기다릴 수는 없었다. 둘을 동시에 기다려야 한다.

// 진행 중 크론이 없을 때 배포 시간이 늘지 않도록 요청과 크론을 동시에 기다린다.
const [drain, cron] = await Promise.all([
  this.drainHttp().catch(/* ... */),
  ShutdownState.waitForCronsIdle(ShutdownTimeout.CronDrainMs).catch(/* ... */),
]);

이 Promise.all 은 성능 최적화가 아니라 예산이 성립하기 위한 필요조건 이다. 직렬로 되돌리면 25 + 90 = 115초가 되어 데드라인 110초를 넘기고, 정상적으로 종료되는 경우에도 강제 종료로 바뀐다.

코드만 보면 “동시에 기다리니 조금 빠르겠네” 로 읽힌다. 그래서 주석에 최적화가 아니라는 사실을 남겼다. 누군가 가독성을 이유로 직렬로 펴는 순간 모든 배포가 강제 종료되는데, 그 신호는 로그 한 줄뿐이기 때문이다.

🤔 Understanding

이번 작업에서 가장 크게 남은 것은, 무중단 배포가 애플리케이션 설정이 아니라 앱과 인프라가 공유하는 하나의 예산 이라는 점이다.

애플리케이션이 110초를 쓰겠다고 정하는 것만으로는 의미가 없다. 파드 종료 유예가 기본값 30초로 남아 있으면 요청과 크론을 기다리는 절차가 30초에 잘린다. 그래서 배포 순서가 곧 안전 조건이 되었다. 차트의 유예 시간과 preStop 이 먼저 반영된 뒤에야 애플리케이션 변경이 나갈 수 있다.

같은 성격의 의존이 그보다 앞에 하나 더 있었다. 53분짜리 작업을 outbox 와 브로커 뒤로 옮기는 일이 종료 절차보다 먼저 와야 했다. 돌이켜보면 종료를 설계하는 일의 절반은 기다릴 수 있는 크기의 일로 만들어 두는 것 이었다.

대기가 사라진 것이 아니라는 점도 적어 둔다. rate limit 에 맞춘 5초는 컨슈머에 그대로 남아 있다. 달라진 것은 그 시간을 누가 짊어지는가 였고, 종료가 기다려야 하는 쪽에서 기다려주지 않아도 되는 쪽으로 옮긴 것이 이번 변경의 실체였다.

검증도 로컬이 아니라 롤아웃 로그로 했다. 실제 롤아웃에서 구 파드 전부가 신호 수신 → 요청·크론 대기 → 자원 정리 → 트레이스 비우기 를 수십 밀리초 안에 완주했고, 데드라인으로 끊긴 경우는 없었다.

다만 지금의 수치가 끝은 아니다. 25초·90초·110초는 모두 현재의 트래픽과 크론 실행 시간을 기준으로 정한 값이라, 서비스가 달라지면 함께 달라져야 한다. 꾸준히 관측하면서 조절해 나갈 생각이다.

배포를 기다리던 53분에서 시작해 결국 신호의 소유권과 시간 예산을 다시 설계하는 일이 되었다. 종료를 정리 작업 이 아니라 제한 시간이 걸린 절차 로 보게 된 것이 이번에 얻은 가장 큰 관점의 변화였다.

참고 자료