FSR vs Warm Pool

1. 배경: AMI 베이킹과 콜드 스타트의 불가피한 딜레마;

1.1. 초기 문제점 및 AMI 베이킹 결정;

우리가 직면했던 초기 문제는 안정성이었다. 이미지 생성 모델에 필요한 수십 GB 에 달하는 모델 파일이 있었고, 기존에는 컨테이너 실행 시마다 S3 에서 다운로드해야 했다.

• 치명적인 위험: 다운로드 과정 중 발생하는 네트워크 불안정은 곧바로 서비스 장애로 이어진다.
• 해결: 이 위험을 제거하고자 모델을 인스턴스 디스크에 포함하여 AMI(Amazon Machine Image) 를 생성했다. 이는 EBS 스냅샷을 기반으로 하는 베이킹(Baking) 전략이었다.

1.2. FSR 도입의 근거: 길어진 디스크 초기화 시간;

AMI 베이킹으로 안정성은 확보되었지만, 부작용이 발생했다. 수십 GB 의 데이터가 포함된 EBS 스냅샷을 기반으로 새 볼륨을 생성할 때, OS가 데이터를 로드하는 디스크 초기화(콜드 스타트) 시간이 비정상적으로 길어진 것이었다.

• 임시 해결책: 이 느린 초기화 지연을 우회하기 위해 FSR(Fast Snapshot Restore) 을 도입했다. FSR 은 새 볼륨 생성 즉시 최대 성능을 보장하여, 인스턴스 시작 직후의 성능 저하를 방지하는 역할을 수행했다.
• 숨겨진 비용: FSR 은 활성화된 시간당 비용이 발생하는 유료 기능으로, 지속적인 비용 부담이 발생했다... 꽤나 많이..

---

2. FSR 비활성화의 단서: 환경 재분석;

FSR 의 지속적인 필요성을 재검토하기 위해, 현재 운영 환경의 두 가지 핵심 요소를 분석했다.

2.1. 환경 특성: Spot 인스턴스 미사용의 중요성;

우리는 Spot Instance 대신 ECS EC2 타입 (On-Demand) 용량을 사용하고 있었다.

• FSR 역할의 변화: On-Demand 환경에서는 AWS 에 의한 강제 회수(Spot Interruption) 위험이 존재하지 않았다. 따라서 FSR 의 주된 역할인 재난 복구 보험 기능은 불필요하게 된 것이었다. FSR 의 역할은 오직 새 인스턴스의 콜드 스타트 가속화로 축소되었다.

2.2. Warm Pool 재활용 정책을 통한 FSR 우회;

가장 결정적인 단서는 Warm Pool 설정이었다.

• 운영 정책: Scale-in 시 인스턴스를 Terminate 대신 Stopped 상태로 웜풀에 복귀시키고, Scale-out 시 이 인스턴스를 재활용하는 정책이었다.
• 재활용 효과: 재활용되는 인스턴스는 이미 디스크 초기화 과정이 완료된 상태였다. Scale-out 시 새 볼륨을 생성하지 않으며, FSR 의 가속 기능은 사용되지 않았다.

---

3. 결론: FSR 을 일시적 가속 도구로 활용;

우리의 환경에서 FSR 이 필요한 경우는 오직 Warm Pool 이 비어 ASG 가 새로운 인스턴스를 생성하여 Warm Pool 을 리필할 때로 한정했다. 리필 과정은 빈번하지 않기 때문에, FSR 을 지속적으로 활성화하는 것은 비효율적인 비용 지출이라고 판단했다.

최종 비용 최적화 전략:

1. FSR 활성화 시점: 모델 업데이트 후 새 AMI 스냅샷을 생성할 때만 일시적으로 FSR을 활성화한다.
2. FSR 비활성화 시점: ASG 에 새 AMI 배포가 완료되고 인스턴스가 안정적으로 운영되기 시작하면, 해당 스냅샷에 대한 FSR 을 즉시 비활성화한다.

이 전략을 통해 우리는 안정성(AMI 베이킹)을 유지하면서, Warm Pool 재활용의 이점을 극대화하고, 불필요한 FSR 유지 비용을 줄일 수.. 사실 다음달에 확인이 가능하다. 🙈

---

return;