Github Actions: 스팟 인스턴스 클레임으로 중단된 CI 작업 자동 재시도

(dev.to)

AWS 스팟 인스턴스 회수로 인해 발생하는 GitHub Actions의 가짜 실패를 로그 기반으로 자동 감지하고 재시도하여, 비용 절감과 CI 안정성을 동시에 확보하는 기술적 방법론을 제시합니다.

이 글의 핵심 포인트

1AWS 스팟 인스턴스 중단 시 발생하는 특정 로그 패턴(shutdown signal 등)을 감지하여 자동 재시도하는 Python 스크립트 구현
2GitHub Actions의 `workflow_run` 트리거를 사용하여 실패한 작업의 로그를 분석하고 재실행 여부를 결정
3무한 재시도 방지를 위해 최신 실행 건 존재 여부, 재시도 횟수 제한(최대 3회), 동시성 그룹 충돌 등을 고려한 로직 적용
4AWS ASG의 `capacityRebalance` 기능이 정상 작동하려면 `maxCapacity`가 `desiredCapacity`보다 커야 함을 명시
5재시도 작업 자체는 중단 위험이 없는 GitHub 호스팅 러너(`ubuntu-latest`)에서 실행되도록 설계

이 글에 대한 공공지능 분석

왜 중요한가?

클라우드 비용 최적화를 위해 스팟 인스턴스를 사용하는 것은 필수적이지만, 인스턴스 중단은 CI/CD 파이프라인의 신뢰도를 떨어뜨리는 치명적인 요소입니다. 이 글은 인프라 비용을 낮추면서도 개발 프로세스의 안정성을 유지할 수 있는 구체적인 자동화 해법을 제시합니다.

어떤 배경과 맥락이 있나?

많은 스타트업이 비용 절감을 위해 AWS 스팟 인스턴스를 Self-hosted Runner로 활용합니다. 그러나 AWS가 자원을 회수할 때 발생하는 프로세스 종료 신호는 GitHub Actions에서 일반적인 테스트 실패와 동일하게 표시되어, 개발자가 불필요한 디버깅에 시간을 허비하게 만듭니다.

업계에 어떤 영향을 주나?

단순히 '비싼 온디맨드 인스턴스를 쓰자'는 식의 접근이 아니라, 소프트웨어적인 자동화(Python 스크립트 및 워크플로우 로직)를 통해 인프라의 불안정성을 극복할 수 있음을 보여줍니다. 이는 DevOps 엔지니어링의 수준을 한 단계 높이는 사례입니다.

한국 시장에 어떤 시사점이 있나?

클라우드 비용 관리가 생존 직결 문제인 한국 스타트업들에게, 스팟 인스턴스 활용도를 극대화하면서도 배포 파이프라인의 무결성을 지킬 수 있는 실무적인 아키텍처 가이드를 제공합니다.

이 글에 대한 큐레이터 의견

이 사례는 '비용 효율성'과 '개발자 경험(DX)'이라는 상충하는 가치를 엔지니어링으로 해결한 탁월한 접근입니다. 단순히 인프라를 교체하는 대신, 로그 분석을 통해 실패의 원인을 분류하고 자동 재시도 로직을 구축함으로써 인프라 비용은 유지하면서도 개발자의 불필요한 개입을 최소화했습니다.

하지만 주의할 점도 있습니다. 이러한 자동 재시도 로직이 너무 완벽하게 작동하면, 인프라의 근본적인 불안정성(Spot 인스턴스 가용성 저하 등)이 은폐될 위험이 있습니다. 만약 재시도 횟수가 급증한다면 이는 자동화로 해결할 문제가 아니라, 인스턴스 타입을 변경하거나 ASG 설정을 재검토해야 한다는 강력한 신호로 받아들여야 합니다.

스타트업 창업자라면 이러한 '비용 최적화 자동화'를 장려하되, 자동화된 복구 로직이 인프라의 결함을 가리는 '기술적 부채'로 변질되지 않도록 모니터링 지표(예: 재시도 발생 빈도)를 반드시 함께 관리하도록 팀에 권고해야 합니다.

원문 보기 →