피드로 돌아가기
Dev.toDevOps
원문 읽기
OCI Manifest 기반 단일 진입점으로 월 12,000회 배포 달성
The Perfect Fruit Salad: 12,000 deployments per month with a single entry point
AI 요약
Context
CI와 CD의 경계가 모호한 Monolithic Pipeline 구조로 인해 환경 이슈 발생 시 전체 빌드와 테스트를 재수행해야 하는 비효율 발생. 배포 로직이 CI에 종속되어 시장 출시 속도가 저하되고 파편화된 도구 사용으로 인한 개발자 경험 저하가 심화된 상황.
Technical Solution
- CI(Artifact Factory)와 CD(Logistics)의 엄격한 Separation of Concerns을 통한 파이프라인 분리 설계
- Kargo를 단일 진입점으로 채택하여 Backend, Lambda, Frontend 등 다양한 워크로드에 동일한 배포 인터페이스 제공
- Non-Kubernetes 아티팩트 처리를 위해 ORAS CLI를 이용한 OCI Manifest 기반 메타데이터 마커 도입
- ECR에 저장된 OCI Annotations를 Kargo가 폴링하여 S3나 Helm Registry의 실제 자산으로 연결하는 간접 참조 구조 설계
- Datadog-ci CLI와 연동된 Automated Verification Service를 구축하여 배포 전후의 Health Check 및 자동 롤백 체계 마련
- PR Label 기반의 Backend Preview 환경 구축 및 Helm Chart Diff 자동화를 통한 코드 리뷰 효율성 증대
실천 포인트
1. CI 파이프라인에서 배포 로직을 분리하여 빌드 결과물(Artifact) 생성과 배포 제어를 독립적으로 운영하는가?
2. 서로 다른 기술 스택(K8s, Serverless, Static Web)을 관통하는 공통의 배포 추상화 레이어가 존재하는가?
3. 배포 성공 판단 기준을 단순히 '프로세스 종료'가 아닌 실제 서비스의 Health Check 및 메트릭 기반으로 정의했는가?
4. 개발자가 배포 상태를 확인하기 위해 여러 로그 시스템을 전전하지 않고 하나의 인터페이스에서 가시성을 확보했는가?