EKS Bottlerocket에서 이미지 캐싱으로 이미지 Pull 시간 줄이기

인프랩은 ML·데이터 파이프라인에서 GB 단위의 큰 컨테이너 이미지를 사용했고, 특히 Spot 인스턴스처럼 노드 재생성이 잦은 환경에서 이미지 pull과 압축 해제가 병목이 됐다. 컨테이너 준비에만 최대 15분이 걸리며 EC2 비용과 네트워크 비용도 불필요하게 커졌다.

해결책으로 EKS + Bottlerocket 환경에서 이미지가 저장된 데이터 볼륨(EBS) 을 스냅샷으로 캐시하는 방식을 적용했다. Bottlerocket은 OS 볼륨과 컨테이너 데이터 볼륨이 분리돼 있어, 이미지가 들어 있는 볼륨의 스냅샷을 다른 인스턴스에 복원하면 동일한 캐시 상태를 바로 재사용할 수 있다.

스냅샷 생성은 AWS 공식 예제 레포지토리인 bottlerocket-images-cache 스크립트로 처리했다. 흐름은 다음과 같다.

• CloudFormation으로 Bottlerocket EC2, Role, InstanceProfile, LaunchTemplate 등을 생성
• admin container를 활성화한 뒤 ctr로 필요한 이미지 pull
• 기존 이미지와 불필요한 서비스는 제거하고, 캐시가 들어간 /dev/xvdb 볼륨의 EBS snapshot 생성

이 과정에서 Bottlerocket 접근은 control container와 admin container를 통해 이뤄졌다. SSM 권한이 있으면 control container로 접속할 수 있고, 이미지 pull 같은 작업은 root 권한과 호스트 파일시스템 접근이 가능한 admin container에서 수행했다.

노드 프로비저닝 단계에서는 Karpenter EC2NodeClass의 blockDeviceMappings에 생성된 snapshotID를 연결해, 새 노드가 뜰 때부터 캐시된 이미지를 바로 쓰도록 구성했다. 그 결과 첫 컨테이너 시작 시간을 평균 10초 이내로 줄였다.

다만 스냅샷 기반 볼륨은 첫 접근 시 lazy loading 때문에 대용량 파일 읽기 지연이 생길 수 있었다. 이를 줄이기 위해 fio로 사전 로드, IOPS/Throughput 상향, fast snapshot restore 세 가지를 검토했고, 비용 대비 효과를 따져 IOPS/Throughput 상향을 선택했다. fast snapshot restore는 az당 월 $540 수준이라 현재 사용 방식에는 부담이 컸다.

정리하면, 짧은 작업 시간과 고사양 인스턴스 비용 구조에서는 초기에 EBS 성능을 높여 스냅샷 데이터를 빠르게 로드하는 편이 더 경제적이었다. 대용량 이미지를 자주 다시 올려야 하는 파이프라인이나, 노드 재생성이 빈번한 Spot 환경이라면 이미지 캐시용 스냅샷 전략이 유효한 최적화가 될 수 있다.