안녕하세요. SaaS 전환지원센터입니다.

트랜잭션이 지속적으로 쌓이는 SaaS 데이터베이스에서 과거 데이터를 정리하지 않고 방치하면, DB 전체의 성능 저하와 백업/복구 시간 증가로 이어져 운영 리스크가 커집니다. 

시스템 운영진은 운영 DB(Online DB)의 크기를 일정 수준 이하로 유지하기 위한 '정기 데이터 아카이빙 및 이관(Data Lifecycle Management)' 작업을 체계화해야 합니다.

가장 먼저 선행되어야 할 실무 작업은 '기준 일자 및 테넌트 상태 기반의 데이터 추출 배치(Batch) 구현'입니다. 

예를 들어 "작성된 지 2년이 지난 데이터" 또는 "해지/휴면 처리된 지 6개월이 지난 테넌트의 데이터"를 아카이빙 대상으로 정의합니다. 

이때 운영 중인 DB에 Lock을 걸지 않기 위해, 한번에 전체 데이터를 조회해 지우는 방식이 아니라 


Tenant ID와 Created At PK를 기준으로 'Chunk 단위(예: 1,000건씩)'로 끊어서 조회 및 백업 파일(S3, Object Storage 등)로 추출하는 배치를 트래픽이 적은 야간 시간에 돌려야 합니다.

둘째로, 추출된 과거 데이터의 '콜드 스토리지(Cold Storage) 아카이빙 및 조회 지원 방안' 마련입니다. 

메인 DB에서 삭제되더라도 고객사가 아주 가끔 "3년 전 결제 내역을 확인하고 싶다"고 요청할 수 있습니다. 

따라서 백업된 데이터를 비용이 저렴한 Object Storage(AWS S3 Glacier, GCP Coldline 등)에 저장하되, 

필요시 운영진이 Parquet/CSV 형태로 빠르게 쿼리해 조회해 줄 수 있도록 Athena나 BigQuery 같은 Serverless 쿼리 엔진과의 연결 고리를 미리 확보해 두어야 합니다.

마지막으로 이관이 완료된 데이터의 '운영 DB 안전한 삭제(Purge) 및 테이블 공간 반환'입니다. 이관이 확인된 데이터는 DELETE 쿼리로 지우되, 

이 역시 Chunk 단위로 나누어 지워야 DB 트랜잭션 로그(Undo/Redo Log)가 급증하여 서버가 멈추는 불상사를 막을 수 있습니다. 

또한, RDB 특성상 DELETE를 하더라도 실제 디스크 용량이 바로 반환되지 않으므로, 정기 점검 시간에 OPTIMIZE TABLE 또는 VACUUM 명령을 실행하여 실질적인 디스크 물리 공간을 회수하는 것까지 완료해야 아카이빙 작업이 완전히 마무리됩니다.

추가로 궁금하신 사항이나 더 자세한 안내가 필요하실 경우, 언제든 문의해 주시기 바랍니다. 

감사합니다.