글을 적게된 이유
사내에서 시스템 리팩토링을 통해서 mongodb에 저장해야할 데이터를 80% 이상 개선한 경험이 있는데 이때 mongodb의 디스크 크기가 줄지 않는 트러블 슈팅을 공유하려고 합니다
배경
기존 레거시 시스템은 AI를 학습시켰던 데이터에 대한 미리보기를 위해서 원본 csv는 s3에 미리보기를 위해 csv의 row들을 mongodb에 저장하고 있었는데 s3의 select object content 기능을 통해서 s3에 저장된 원본 csv를 읽도록 리팩토링하면서 mongodb의 파싱된 데이터는 더 이상 사용되지 않아서 해당 데이터를 삭제하게 되었는데 mongodb에 할당된 디스크 크기가 줄지 않는 현상이 발생했습니다
한 번 원인 파악해보자
아래 명령어로 현재 어떤 데이터 상태가 어떤지 파악했습니다
db.adminCommand( { listDatabases: 1 } )
db.collection.stats()결과는 실제 저장된 데이터의 크기는 약 10GB인데
할당된 디스크 공간은 약 52GB로 시스템을 개선하기 전 데이터 크기로 할당되어 있었습니다
첫번째 최적화
mongodb PM분의 포스팅을 확인해보니 mongodb는 문서를 삭제할 때 데이터 파일에 빈 레코드 목록을 유지한다고 합니다
그래서 삭제된 이후 할당된 디스크의 크기를 최적화하기 위해서는 compact 명령어를 사용해서 최적화를 진행한다고 합니다
최적화를 완료하고 디스크 용량과 사용량을 고려해서 클러스터를 내린 뒤에
보다 더 최적화할 게 없는지 리서치하게 되었습니다
드디어 나왔다 oplog
리서치를 하다가 oplog라는 키워드를 발견했고 공식 docs를 찾아보게 됐습니다
mongodb 클러스터의 복제본 관리 원리에 대해서 간단하게 설명하겠습니다
mongodb 클러스터에서 primary, secondary node 중 primary node에서 모든 쓰기 작업을 수신하고 데이터 변경 사항을 oplog에 기록하면 secondary node에서 oplog를 복제한 뒤 적용하는 방식으로 복제본을 관리합니다
https://www.mongodb.com/ko-kr/docs/manual/replication/
두번째 최적화
저는 클러스터, 디스크 최대 용량도 downgrade 하였는데
downgrade하기 전의 기본 oplog의 크기로 설정되어 있었습니다
(기본 oplog 크기 : 디스크 여유 공간의 5%)
그래서 복제본 세트 멤버의 oplog 크기 변경 문서를 참고해서 해결했습니다
아래와 같이 oplog의 크기를 조정하고
db.adminCommand({replSetResizeOplog: 1, size: Double(16000)})oplog의 크기를 조정했지만 mongodb는 문서를 삭제할 때 데이터 파일에 빈 레코드 목록을 유지함으로 아래 명령어로 할당된 디스크를 최적화 합니다
db.runCommand({ "compact" : "oplog.rs" } )https://www.mongodb.com/ko-kr/docs/manual/core/replica-set-oplog/
