아무래도 ㅈ됐습니다.
찰나의 순간에 내린 저의 결론은
저는 ㅈ됐습니다.
데이터가 모두 사라지다
소프트콘 뷰어십은 작년 2023년 9월부터 현재까지 4억개가 넘는 인터넷 방송 데이터를 가지고 있습니다. 쌓아놓았던 모든 데이터를 단 한번의 실수로 날렸다면, 여러분은 어떠셨을것 같나요?
지금부터 11월 15일, 08시 42분 경 있었던 저의 실수에 관한 이야기를 들려드리려 합니다. 가까이서 보면 비극이지만 멀리서 보면 도움이 될지도 모르는 저의 개발 이야기입니다.
발생
소프트콘 뷰어십엔 인터넷 방송 데이터와 더불어 카테고리와 게임 데이터를 보관하는 테이블이 존재합니다. 이를 이용해 각 카테고리별 상세 데이터를 따로 만들어주고 있었죠.
하지만 데이터가 점점 많아지고, 일별 데이터를 뽑기 위해 매 6분마다 수집하여 하루 240개의 데이터를 1년이라는 장기간으로 보여주는 것은 시간이 너무 많이 걸리고 계산에 너무 많은 코스트가 발생하는 작업이였습니다.
그래서 저는 이를 하루마다 요약하여 summary 테이블을 만들고 해당 일별 요약 테이블을 이용하기 위해 개발을 진행하던 중이였습니다.
소프트콘 뷰어십은 현재 ORM으로 Prisma를 이용하고 있습니다. SQL-LIKE는 아니지만 그럼에도 대체적으로 이용하는 SQL ORM으로는 굉장히 좋습니다.
물론 세세한 개발을 위해선 SQL을 직접 짜야하는 경우도 많지만요.
여튼 DB와 ORM을 동기화해주는 중요한 스키마 파일인 schema.prisma 파일을 수정중에 있는 상황이였습니다. 새롭게 만들어야 하는 summary 테이블의 스키마를 수정하여 필요한 컬럼들을 만들어 가고 있는 중이였죠.
그렇게 스키마를 수정하고, prisma db push를 통해 DB에 반영하던 도중 다음의 오류가 cli에 나오기 시작합니다.
( 예시로 만든 가정입니다. 실제 값은 달랐습니다 )
흠.. 🧐
All data will be lost 라고는 하는데 제가 작업하고 있는 table만 리셋 되는것이라고 생각했습니다. 분명 앞에 reset the database 라고 써져있는데도 불구하고 말이죠.
몇초간 고민 끝에 저는 y를 눌러 리셋을 진행해버렸습니다.
그리고, 해당 테이블이 리셋된것을 확인한 저는 혹여나 하는 마음에 다른 테이블을 확인하기 시작했습니다.
텅..
비었습니다.
지금까지 모았던 모든 데이터가 한순간의 실수로 전부 날라가버렸습니다.
2023년 09월 부터 2024년 11월까지 있었던 데이터들이 전부 날라가버렸고 순간 머리속이 멍해지고 심박수가 급격히 상승하기 시작했습니다.
당시 차고 있던 갤럭시핏에서 측정한 심박수, 그 순간에 130bpm 까지 치솟았습니다.
지금 시간은 오전 8시 42분.
제가 가진 모든 지식을 이용해 데이터를 복구해야 합니다.
"살려야 한다"
지금 살리지 못하면, 저희 사이트의 데이터 뿐만 아니라 구독하고 있는 분들에게 사과드리고, 환불하고, 각종 인터넷방송 커뮤니티에서 비난과 손가락질이 으으.. 머리가!
이럴 시간이 없습니다.
현재 사용하고 있는 DB는 aws의 Aurora DB로 안정성 측면에서 좋은 평을 듣고 있는 DB 입니다. 이중 PostgresQL를 이용하고 있죠.
제가 먼저 생각한 방법은 snapshot 복구 방법이였습니다.
Aurora DB는 기본 설정으로 만들게 되면 특정 시간마다 snapshot을 만들어 줍니다. 스냅샷은 현재까지 DB에 있었던 트랜잭션을 기록하는 읽기 전용 데이터로 snapshot을 이용하면 해당 시점으로 데이터를 복구할 수 있었습니다.
제가 날렸던 시간이 08:42 이였고, 가장 최근 스냅샷은 02:53 이니 6시간 정도의 데이터를 날리지만 그래도 복구에는 문제 없었습니다.
다행히도 최근 15.4 에서 16.4 업데이트를 위해 미리 스냅샷을 이용해 DB 복구 작업을 진행한적이 있었고 해당 스냅샷을 이용해 새롭게 DB 클러스터를 생성하기 시작했습니다.
그런데, 곰곰히 생각해보니 6시간 정도의 데이터는 꽤 큰 간격입니다. 이것보다 더 줄일수 있는 방법이 있을텐데.. 한번 빠르게 찾아봅시다.
PIT 복구
PITR : Point In Time Recovery로 특정 시점 복구를 의미
Aurora DB의 장점중 하나는 지정된 시간으로 DB 클러스트를 복원할수 있습니다.
간단히 말해 특정 모든 시점의 DB 트랜잭션이 Aurora DB에 보관되어 있고, 이를 이용해 해당 시점의 DB 상태로 복원이 가능하다는 이야기이죠.
아마 내부적으로 아카이브 모드의 WAL (Write-Ahead Log) 데이터를 이용해 복구하는것으로 보이지만 이와 관련된 자세한 설명이 AWS 내에서는 따로 없어 어떤 방법을 이용하는지는 모르겠습니다.
여튼 이 복원을 이용하면 더 가까운 시점으로 복원이 가능할것으로 보입니다.
RDS > 자동 백업에서 확인해보니 정말 놀랍게도 데이터가 날라간 08:42 직전인 08:41로 돌릴수 있는 데이터가 저장되어 있었습니다. 무려 분단위로 돌아갈수 있었고, 해당 기능을 이용해 08:40 으로 시간을 맞춰 복원을 진행했습니다.
AWS의 복원은 기본적으로 새 클러스터 생성으로 이뤄집니다. 저 역시 해당 시점으로 새롭게 DB 클러스터를 생성하였고 기존과 동일한 설정으로 클러스터가 만들어지기 시작했습니다.
그렇게 20분 정도의 시간이 지나고, 클러스터 생성이 완료되었습니다.
그리고, DB의 첫번째 데이터인 23.08.29 시점의 데이터와 더불어 24.11.15 08:36 시점의 데이터 역시 되살아 난것을 확인할 수 있었죠.
이후 서버의 DB 주소를 새롭게 설정하고, 긴급 안내를 띄우고 복구 절차를 마무리했습니다. 그리고 매우 귀중한 교훈들도 많이 얻어갈 수 있었죠.
아마존 주식을 조금 더 사두자
모든 일은 개발 서버에서 먼저 해보자
에필로그
사실 사라진 데이터는 50분 분량의 데이터보다 더 짧습니다. 기존 DB가 전부 초기화되었을뿐, 수집되고 있는 데이터는 여전히 기존 DB에 저장되고 있었으니까요.
사실 해당 데이터를 새로운 DB에 옮길까 역시 고민했었지만, 데이터가 꼬여 또 다른 문제를 불러 일으킬수 있다는 판단으로 별다른 작업 없이 누락된 데이터로 가져가기로 했습니다.
이번일로 몇가지 알게 된 것들이 있습니다.
소프트콘 뷰어십은 수집 DB 와 계정용 DB가 분리되어 있습니다. 수집 DB가 날라가더라도 기존 유저 데이터는 전혀 문제가 없는데요, 수집 DB는 Aurora DB를 이용하고 계정용 DB는 supabase를 이용하고 있습니다.
AWS는 기본적으로 가격이 좀 비쌉니다. 현재 소프트콘 뷰어십은 t4g.large 인스턴스를 이용하고 이는 매달 $240 정도의 비용이 지출되고 있는 상황입니다. 이에 비해 supabase는 거의 $30 수준에서 끝나고 있죠. 물론 supabase는 t4g.micro 인스턴스를 사용하기에 그런것도 있을 것입니다.
하지만, supabase에서 동일한 PITR 기능을 이용하려면 매달 $100의 추가 지출이 발생합니다. 스냅샷은 동일하게 매일 동일 시점에 만들어주고 있으나, 특정 시점으로 복원하는 기능은 비용이 꽤 비쌉니다.
( AWS는 Aurora DB 에서 추가 비용 없이 7일 기본 지원, 다른 DB는 지원하지 않음 )
하지만 이러한 가격과 별개로 여러분이 긴급한 상황에 맞닥뜨리게 된다면 큰 도움이 될 것이라고 생각이 됩니다. 서비스가 중요하다면 해당 기능을 꼭 한번 확인해보시길 바라겠습니다.
감사합니다!
진짜 심장 떨어질 뻔...;;