로컬에서 써 본 것만으로 자동화 서버의 하루 예산이 소진됐다
한눈에 답변
하루 API 호출량을 기록하는 장부 파일이 저장소에 커밋되는 구조였는데, 로컬 컴퓨터에서 개발하며 쓴 호출과 자동화 서버가 실제로 써야 할 호출이 같은 장부에 합산되고 있었다. 그 결과 로컬 개발만으로 자동화 서버의 첫 실행이 '하루 상한 도달'로 막힐 뻔한 상태가 됐다. 실행 환경을 기록에 남기고 같은 환경끼리만 합산하도록 고쳤다.
무엇을 발견했나
콘텐츠 자동화 파이프라인은 검색·모델 호출에 하루 상한을 두고 있고, 그 사용량을 저장소 안의 장부 파일에 기록한다. 그런데 이 장부는 로컬 컴퓨터에서 개발하며 실행한 호출과, 실제 자동화 서버가 매일 실행하며 쓰는 호출을 구분하지 않고 같은 파일에 함께 쌓고 있었다.
왜 문제였나
로컬에서 기능을 개발하고 테스트하는 과정에서 이미 상당한 호출을 쓴 상태였다. 이 기록이 그대로 커밋돼 저장소에 남아 있었기 때문에, 자동화 서버가 그날 처음 실행되는 순간 장부를 확인하면 이미 하루 상한에 가까운 상태로 보이게 된다. 실제로 첫 자동 실행이 상한 도달로 막힐 수 있는 상황이었다.
어떻게 고쳤나
실행 기록에 그 실행이 로컬 환경에서 일어난 것인지 자동화 서버(CI) 환경에서 일어난 것인지를 함께 남기도록 바꿨다. 그리고 하루 사용량을 계산할 때는 같은 환경의 기록만 더하도록 해서, 로컬 개발 중의 호출이 자동화 서버의 예산에 섞여 들지 않게 했다.
같은 문제를 겪으며 함께 고친 것
자동화 서버에서 특정 도구가 실패하면 데이터베이스 오류 전문이 그대로 출력되고 있었는데, 이걸 읽어서는 무엇을 해야 할지 알 수 없었다. 실제 원인은 인증 토큰이 설정돼 있지 않다는 훨씬 단순한 사실이었다. 오류 메시지를 그 원인이 드러나는 문장으로 바꾸고, 토큰이 없을 때는 해당 기능만 건너뛰도록 했다.
이 사건에서 얻은 교훈
여러 환경(로컬 개발, 자동화 서버)이 같은 상태 파일을 공유하면, 한쪽 환경의 활동이 다른 쪽 환경의 판단에 섞여 들어갈 수 있다. 예산이나 한도처럼 환경별로 독립적이어야 하는 값은, 기록 시점에 어느 환경인지를 함께 남겨야 나중에 정확히 분리해 계산할 수 있다.