아주 만약에 s3 버킷 내용물이 삭제된다면?

어쩌다 발생했을까?

행복한 금요일 퇴근 전 칼퇴를 꿈꾸던 저에게 비보가 날아들었습니다. 누군가의 실수로 s3에 있는 이미지들과 html 들이 삭제되었다는...

문제는 양이 꽤 되었고, 무엇이 삭제되었는지 정확히 알지 못했다는 것이죠. 잘못된 명령어로 전체 버킷에 대해 삭제를 진행하여 발생한 결과였습니다. cloudfront 를 통해 정적 파일들을 서빙하고 있기에 삭제된 파일을 복구하지 않는다면 timeout된 파일들이 원본에서 찾는 순간 서빙하지 못하는 상황이었습니다.

사용한 명령어

aws s3 sync ./app-docs s3://static-files/docs --delete --no-progress --exclude '.*'

s3 sync 명령은 버킷과 디렉토리의 콘텐츠 또는 두 버킷의 콘텐츠를 동기화합니다. 원본과 대상 간에 누락되거나 오래된 파일 또는 객체를 복사하지만 --delete 옵션을 통해 원본에 없는 파일이나 객체를 대상에서 제거할 수 있습니다.  실제로 사용한 명령도 크게 다르지 않습니다. 해당 명령들에 대해서는 후에 자세히 추가해보겠습니다.

 

해당 명령어를 통해 버킷에 작업한 내용을 올리려고 하였으나 업로드한 파일의 위치가 잘못 되었다는 이유로 삭제 명령을 날렸다고 합니다. 이때 사용한 명령이 버킷 전체에 대해 삭제를 진행하였고 중간에 멈춰 다행히 전부 삭제되지는 않았으나 삭제된 양이 적지는 않았습니다.

대체 왜...왜 때문에..

조치

1차적으로 삭제된 파일들을 찾아내어 서비스에 영향이 갈 법한 파일들을 선별하려 하였습니다. 선별하고 이들 파일들에 대해 어떤 조치를 해야할지 찾아보던 도중 '삭제마커'를 삭제하면 이전 버전, 즉 기존의 최신 버전으로 되살아난다는 것이었습니다. 따라서 중요도가 높아보이는 파일들 먼저 삭제마커에 대해 삭제를 해보았습니다. 결과는 성공! 하지만 이를 손수 한땀한땀 손으로 복구를 진행하기에는 무리가 있기 때문에 스크립트로 처리할 방법을 찾아 처리하였습니다.

교훈

결과적으로 운영상에 큰 문제는 없었지만 굉장히 아찔한 순간이었습니다. 이번 일을 통해 얻은 교훈을 적어보려 합니다.

1. 삭제는 신중히 하자.

사실 다른 위치에 파일을 업로드 했다면 정확한 위치에 다시 올리면 확인하고 사용하면 됩니다. 하지만 바로 삭제를 진행한 것은 좀 아쉬운 부분으로 다가왔습니다. 서비스에 영향을 줄 수 있다는 생각으로 앞으로는 저부터 조심히 진행하려합니다. 가급적 aws 콘솔에서...

2. 사고 공유는 빠르게 하자. 늦어지는게 더 큰일이다.

사실 이 사고에 대한 전파가 빠른 편이 아니었다고 생각합니다. 스스로 해결하기 위함일 수도 있고, 문제의 심각성을 파악하지 못했을 수 있습니다. 따라서 자신이 의도하지 않은 동작에 대해 해결해야 할 무언가가 있다면 주변의 동료들에게 과감히 공유하고 도움을 청하는게 차라리 나을 것 같다는 생각이 들었습니다. 

3. s3 버저닝을 켜두자.

해결에 도움이 되었던 부분인데 만약 버저닝을 켜두지 않았다면 어떻게 되었을지 생각하기도 싫어집니다. 다행히 이 옵션을 사용중이었고 그로 인한 덕을 보았으니 다음부터는 빠지지 않고 확인할 옵션이 될 듯 합니다. 요금이야 추가적으로 부과되겠지만 최신버전이 아닌 객체들을 지워준다면 어느 정도 해소될 문제로 생각합니다.

 

참고

https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/cli-services-s3-commands.htmlhttps://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/ManagingDelMarkers.html

https://isntyet.tistory.com/129