AWS EVENT: i3 인스턴스 은퇴(Retirement)에 따른 Instance Store Volume(휘발성 디스크) 대응

AWS i3 괴담..

Overview

최근 운영 중이던 AWS i3 인스턴스가 은퇴(retirement) 대상이 되면서 예상치 못한 이슈를 겪었습니다.
기존 서비스가 i3 인스턴스의 휘발성(Instance Store) 디스크를 데이터 저장소로 사용하고 있었던 것입니다!

추측하기론 인프라 구축 당시 i3의 빠른 Instance Store SSD 성능을 극대화하기 위해 선택된 설계로 보입니다.
 
AWS에서는 인스턴스 종료/재시작 시 휘발성 디스크의 데이터가 보존되지 않는다고 명확히 안내하고 있지만, 실제로 이벤트가 오기 전까지는 그 리스크를 체감하기 어려웠습니다. 이번 경험을 통해 배운 점을 공유하고자 합니다.

인스턴스가 종료될 때 데이터 보존
Docs: 인스턴스가 종료되면 인스턴스 스토어 볼륨이 자동으로 삭제되고 데이터가 손실됩니다

 
 
의식의 흐름
“아, 인스턴스가 재부팅되는구나…”
“Instance Store Volume은 데이터가 사라진다고?”
“그걸 쓰고 있나?”
“망했다.”

---

문제 상황 진단

• 인스턴스 유형: i3 (Instance Store 기반)
• 데이터 저장 위치: i3의 휘발성 디스크(Instance Store Volume)
• AWS에서 i3 은퇴(retirement) 공지 메일 수신
• 은퇴 이벤트로 재부팅 시 휘발성 디스크에 있던 데이터는 모두 소실될 위험

저희 환경은 EC2 인스턴스 내에 서버와 데이터베이스를 함께 올려둔 모놀리식 구조였습니다.
EBS 기반 스토리지 + RDS + S3로 분리된 AWS 아키텍처가 아니었고 이관을 고려한 설계가 되어있지 않았기 때문에 단시간 내 새로운 EC2로 환경을 그대로 이관하는 것이 쉽지 않았습니다

---

고려한 시나리오

1안: 별도 EC2로 완전 이관

• 방법: 새로운 EC2 인스턴스를 생성하고 모든 데이터를 옮긴 뒤 서비스를 마이그레이션
• 장점: 깨끗한 환경에서 안전하게 이주 가능
• 단점: 데이터량이 많아 시간이 오래 걸리고, 마이그레이션 중 서비스 중단 위험이 큼
• 제약:
  
  • EC2에 서버와 데이터베이스까지 포함된 모놀리식 구조라서 단순 이전이 불가
  • 전체 환경을 다시 세팅해야 하므로 시간과 리스크 모두 부담

2안: i3 유지 + 데이터만 보존

• 방법: 기존 i3 인스턴스를 유지한 채, 휘발성 디스크에 있는 데이터를 EBS로 이전
• 장점: 서비스 중단 최소화 가능
• 단점: 첫 백업은 오래 걸림, EBS 비용 추가 발생
• 선택 이유:
  • 권장 아키텍처는 아니었지만, 단기간 내 안정적 데이터 보존에 가장 적합
  • 비용을 고려할 만큼 여유롭지 않음

---

최종 선택 시나리오와 트레이드 오프

최종적으로 2번 시나리오를 선택했습니다.

선택의 핵심은 곧바로 문제를 해결할 수 있는 안정성과 그에 따라 따라오는 비용 증가 사이의 트레이드오프였습니다.

결국 현재 상황에서는 안정성 > 비용 최적화라는 우선순위를 반영해 2안을 선택하게 되었습니다.
즉, 인스턴스는 그대로 두고 새로운 EBS 볼륨을 생성한 뒤 Instance Store에 있던 데이터를 EBS로 이전하는 방식입니다.

 * 다만 이번 기회를 놓치면 인프라를 개선할 시기를 놓칠 것 같았습니다. 이번 문제로 인프라 개선의 필요성에 대해 합의되었고 여유가 되는 시점에 RDS로 분리 작업을 진행하기로 논의되었습니다.

---

1. EBS 볼륨 생성 후 인스턴스에 연결 (인스턴스 운영 중에도 가능함)
2. Instance Store → EBS로 데이터 복사
3. 재부팅 (이벤트 발생 시간 전에 수동 재부팅을 해도 은퇴 이벤트가 완료됨)
4. 시스템이 Instance Store Volume 대신 EBS를 바라보도록 mount 포인트 변경
5. 서비스 정상화 확인

---

중단 시간 최소화 전략

데이터 이동 과정에서 필연적으로 시스템 중단이 발생할 수밖에 없었습니다.

• 수년간 쌓여온 데이터를 옮기는 데 시간이 오래 걸리고
• 라이브 상태에서 전체 복사를 하면 무결성이 깨질 위험이 있기 때문입니다.

데이터 이동 과정에서 중단은 불가피했지만, rsync를 활용해 중단 시간을 최소화하는 전략을 세웠습니다.
 

rsync 활용

rsync(1) - Linux man page
Docs: It is famous for its delta-transfer algorithm...

 

rsync -avh --progress /mnt/instance-store/ /mnt/ebs-volume/

 
rsync는 변경된 파일만 복사(Delta-transfer) 할 수 있기 때문에 중단 시간을 최소화하는 전략에 적합했습니다.
 
 
운영 중 rsync를 활용해 미리 1차 데이터 복사를 진행하여 중단 시 복사할 데이터의 양을 줄일 수 있도록 했습니다.

(다행히 사전에 실험해본 결과 운영 중 복사 작업이 서비스에 거의 영향을 주지 않는다는 것을 확인했습니다.)

• 1차 복사 (운영 중): 약 10시간 소요
• 2차 복사 (서비스 중단 후, Delta): 약 15분 소요

결과적으로 rsync를 통해 데이터 무결성을 유지하면서도 서비스 중단 시간을 최소화할 수 있었습니다.

 

재부팅과 최종 전환

재부팅과 데이터 이관이 끝나니, 그 다음 작업은 의외로 간단했습니다.

(사실 재부팅 버튼을 누를 때 너무 무서웠습니다...)

기존에 Instance Store Volume을 마운트하던 폴더에 새로 붙인 EBS Volume을 그대로 마운트해주고 서비스를 다시 활성화하니 다행히 아무 문제 없이 정상적으로 동작했습니다

---

마무리

다행히 문제를 해결했지만 AWS 인프라를 더 깊이 이해할 필요성을 다시 한번 깨닫는 계기가 되었습니다.
특히 초기 인프라 설계의 중요성을 다시 생각하게 되었고 AWS에 대해 깊게 공부할 계획입니다.

은퇴 이벤트를 처음 경험해보지만 공부해보니 하드웨어 결함과 같은 이유로 인스턴스가 “재부팅”되는 경우는 생각보다 흔하게 발생했습니다. 언제든 이벤트가 발생할 수 있다는 전제를 두고 인프라를 설계해야 한다는 것을 배웠습니다.

 

비슷한 경험이나 더 나은 방법이 있다면 댓글이나 메일로 공유해 주시면 감사하겠습니다!