요청과 메시지 처리가 진행 중인 서버에 종료 신호가 왔습니다. 새 유입, 기존 작업, DB 풀을 어떤 순서로 정리해야 하나요?

먼저 새 일을 받는 것을 멈추고, 진행 중인 일이 끝나거나 안전하게 중단된 뒤 그 일이 쓰는 자원을 정리하겠습니다. DB 풀이나 로그 저장소부터 닫으면 아직 실행 중인 요청이 실패할 수 있습니다. 종료도 의존성의 역순을 따라야 합니다.

드레이닝은 새 일을 더 받지 않으면서 이미 받은 일을 끝내는 과정입니다. 예를 들어 주문 저장 중인 워커가 있는데 DB 연결 풀을 먼저 닫으면 정상 종료를 시도하다 주문을 실패시킬 수 있습니다. 그 워커의 커밋과 결과 기록을 끝내거나 복구 가능한 상태로 만든 뒤 공유 자원을 닫아야 합니다.

웹 서버라면 준비 상태를 내려 유입을 줄이고 리스너의 새 수락을 중지하겠습니다. 이미 연결된 요청과 백그라운드 작업은 별도로 추적해야 합니다. 메시지 소비자는 새 메시지를 가져오는 것을 멈춘 뒤 처리 중인 작업의 커밋과 확인 응답을 정리합니다. 강제로 중단될 수 있으므로 중복 전달과 미완료 복구는 원래부터 안전해야 합니다.

종료 대기를 무한히 하지는 않겠습니다. 전체 종료 기한을 정하고, 기한을 넘긴 작업에는 취소를 전파한 뒤 정리 가능한 범위를 확인합니다. 되돌릴 수 없는 외부 효과가 진행 중이면 단순 실패로 덮지 말고 재시작 후 확인할 기록을 남겨야 합니다. 마지막에 공유 풀과 로그를 닫되 로그 전송 자체도 무한히 기다리지 않게 합니다. 테스트는 정상 신호뿐 아니라 진행 중 요청·긴 연결·소비 작업이 있는 상태에서 종료해 오류와 재처리 결과를 확인하겠습니다.

진입 경로별로 유입을 닫습니다

HTTP는 readiness를 먼저 내리고 새 연결 수락을 멈추며, keep-alive·HTTP/2·스트림의 남은 요청을 추적합니다. 메시지 소비자는 새 fetch를 중단하고 처리 중인 메시지의 DB 커밋 뒤 ACK를 보냅니다. 스케줄러와 백그라운드 작업은 새 자식을 만들지 않게 하고, 독립 실행으로 넘기는 경우 그 소유권과 최대 수명을 명시합니다. 단순히 프로세스의 스레드 수가 0이 되는 것을 기다리는 것만으로 외부 효과가 끝났다고 볼 수 없습니다.

유예 시간 이후를 설계합니다

앱의 내부 deadline은 오케스트레이터의 termination grace period보다 짧아야 합니다. 기한을 넘긴 요청은 취소하고, 이미 결제 요청을 보냈거나 ACK 전인 메시지는 결과 조회·멱등 재시도·대사 큐로 넘깁니다. DB 풀과 로그 sink는 모든 작업의 성공·취소·복구 대기 상태를 기록한 뒤 닫습니다. ACK 직전 프로세스 종료, readiness 전파 중 새 요청, 긴 스트림, 취소를 무시하는 하위 호출을 재현해 drain 시간 p99와 중복·유실 결과를 조정하겠습니다.

구체적인 경계 사례

종료 상태는 Running→Draining→Stopping→Stopped처럼 한 방향으로 관리하고 반복된 종료 신호도 같은 절차를 두 번 실행하지 않게 합니다. Draining으로 전환한 후 새 작업 등록을 막는 검사와 작업 카운터 증가 사이에 경쟁이 있으면 마지막 작업을 놓칩니다. 진입 차단과 카운터 등록이 하나의 동기화 규칙을 따르고, 카운터가 0이 되기 전에는 작업이 쓰는 자원을 해제하지 않겠습니다.

취소 요청을 보냈어도 하위 I/O가 계속 버퍼를 참조하면 그 메모리를 먼저 반환할 수 없습니다. 내부 정리 기한에 끝나지 않는 작업은 결과 불확정을 내구 기록에 남기고 프로세스 강제 종료·재시작 복구 경로로 넘깁니다. DB 커밋은 끝났지만 응답을 보내지 못한 요청도 정상 재시도에서 중복 효과 없이 결과를 조회할 수 있어야 합니다.