매일 새벽 데이터를 수집하는 파이프라인을 두고 가장 먼저 떠오르는 그림은 상시 켜진 서버에 스케줄러를 걸어 두는 것입니다. 그런데 하루에 한 번, 길어야 수십 분 도는 작업을 위해 서버를 종일 켜 두는 것은 낭비고 관리 부담입니다. 서버가 죽으면 누군가 살려야 하고 보안 패치도 챙겨야 합니다. 이 파이프라인은 관리할 서버 없이 배치 작업과 스케줄러만으로 도는 구조를 택했습니다.
필요할 때만 뜨는 배치 작업
핵심은 수집기를 상시 프로세스가 아니라 필요할 때만 뜨는 일회성 배치 작업으로 만드는 것입니다. 스케줄러가 정해진 시각에 배치 작업을 깨우면, 작업은 컨테이너로 잠깐 실행되어 데이터를 수집해 저장한 뒤 스스로 종료합니다. 도는 동안만 자원을 쓰고 끝나면 아무것도 남지 않으니, 관리할 서버가 없고 유휴 비용도 들지 않습니다.
한 가지 예외가 있었습니다. 2차 인증 코드를 받는 콜백 서비스는 언제 문자가 올지 모르므로 상시 대기해야 합니다. 그래서 수집기는 필요할 때만 뜨는 배치로, 콜백만 상시 서비스로 성격을 나눠 배치했습니다. 대부분의 무거운 작업은 배치로 돌리고 정말 상시성이 필요한 최소한만 서비스로 남기는 구분이 자원과 관리 부담을 함께 줄여 줍니다.
채널별 장애를 격리한다
여러 채널을 한 파이프라인에서 돌리려면 한 채널의 실패가 다른 채널을 물고 늘어지지 않게 해야 합니다. 그래서 채널마다 실행을 분리하고 수집 결과를 성공과 실패로 나눠 각각 담아 반환하게 했습니다. 한 채널이 로그인 실패나 서버 오류로 멈춰도 그 실패는 해당 채널에만 갇히고 나머지 채널은 계속 수집을 이어 갑니다.
이 격리 덕에 전체 배치의 결과도 이분법이 아니라 부분 성공으로 표현됩니다. 모두 성공하면 정상, 일부만 실패하면 부분 실패, 전체가 깨지면 실패로 상태를 구분해 남깁니다. 담당자는 이 상태만 봐도 오늘 어느 채널이 문제였는지 바로 알 수 있고 부분 실패한 채널만 다음 날 다시 챙기면 됩니다.
무한정 도는 것을 막는 타임아웃
무인으로 도는 배치에서 가장 무서운 것은 어딘가 걸려 영원히 도는 상황입니다. 외부 API가 응답하지 않거나 폴링이 끝나지 않으면 배치가 종료되지 못하고 자원을 붙든 채 매달립니다. 그래서 배치 전체에 실행 시간 상한을 걸어 정해진 시간이 지나면 남은 작업을 건너뛰고 정리하며 마무리하도록 했습니다. 각 단계의 폴링에도 개별 타임아웃이 있어 한 채널의 지연이 전체 시간을 잡아먹지 않게 이중으로 막았습니다.
일시적인 오류에는 지수 백오프로 재시도해 스스로 회복을 시도하되, 재시도 횟수에도 상한을 둡니다. 회복을 시도하는 것과 무한정 매달리는 것은 다릅니다. 몇 번 다시 해 보고도 안 되면 그 채널은 실패로 접고 다음으로 넘어가는 편이, 하나에 매달려 전체를 늦추는 것보다 낫습니다.
로그는 남기되 비밀은 가린다
무인 파이프라인에서 로그는 유일한 눈입니다. 무엇이 언제 성공했고 어디서 멈췄는지가 로그에 남아야 사람이 지켜보지 않아도 상황을 재구성할 수 있습니다. 그래서 각 채널의 수집 건수와 소요 시간, 실패 원인을 구조화된 형식으로 남겼습니다. 클라우드 로깅이 바로 인식할 수 있는 형식으로 찍으면, 나중에 심각도나 채널로 걸러 보기도 쉽습니다.
다만 로그에는 인증 키나 토큰 같은 민감한 값이 섞여 들어가기 쉽습니다. 그래서 로그를 내보내기 직전에 키·시크릿·토큰처럼 보이는 문자열을 자동으로 가리는 필터를 두었습니다. 로그는 충분히 남기되 비밀은 새지 않게 하는 균형입니다. 새 계정이나 채널을 추가할 때도 파이프라인을 다시 짜지 않고 스케줄과 설정을 더하는 수준으로 확장되므로, 운영 부담이 채널 수에 비례해 폭증하지 않습니다. 전체 시스템은 멀티채널 광고·정산 데이터 수집 파이프라인 사례에서 볼 수 있습니다.
자주 묻는 질문
왜 상시 서버 대신 배치 작업을 쓰나요?
하루에 한 번, 짧게 도는 작업을 위해 서버를 종일 켜 둘 이유가 없기 때문입니다. 배치 작업은 스케줄러가 깨울 때만 잠깐 실행되고 끝나면 사라지므로 유휴 비용이 없고 관리할 상시 서버도 없습니다. 다만 언제 요청이 올지 모르는 2차 인증 콜백처럼 상시성이 꼭 필요한 부분만 예외로 서비스로 둡니다.
한 채널이 실패하면 그날 수집이 전부 실패하나요?
아니요. 채널별로 실행을 격리했기 때문에 한 채널의 실패는 그 채널에만 갇힙니다. 나머지 채널은 계속 수집을 이어 가고 전체 결과는 부분 성공으로 남습니다. 담당자는 실패한 채널만 골라 다음 날 다시 챙기면 됩니다.
무인으로 도는데 문제가 생기면 어떻게 아나요?
로그가 눈 역할을 합니다. 채널별 수집 건수와 소요 시간, 실패 원인을 구조화된 형식으로 남기고 배치 전체 상태를 정상·부분 실패·실패로 구분해 기록합니다. 실행 타임아웃과 재시도 상한이 있어 무한정 매달리지 않고 문제가 생기면 명확한 실패로 로그에 드러나 사람이 이어서 대응할 수 있습니다.