Magic Pocket의 immutable blob store 저장 효율 개선하기

Magic Pocket은 Dropbox의 exabyte-scale blob storage로, immutable 구조 때문에 삭제와 업데이트가 곧바로 공간 회수로 이어지지 않는다. blob이 한 번 쓰이면 수정되지 않고, 필요 없는 데이터는 garbage collection으로 표시된 뒤 compaction을 통해 실제로 재배치돼야만 공간을 돌려받을 수 있다.

문제는 최근 새 placement 경로가 도입되면서 fragmentation이 급격히 늘었다는 점이다. 특히 Live Coder 경로에서 생성된 volume 일부는 live data가 5% 미만인 수준까지 비어 있었고, 이로 인해 raw capacity를 과도하게 점유하는 긴 tail이 생겼다. 기존의 steady-state compaction만으로는 이 분포를 따라잡지 못해 storage overhead가 다시 치솟았다.

기존 baseline인 L1은 host volume이 이미 꽉 차 있는 상태에서 donor volume의 live bytes를 채워 넣는 방식이었다. 이 방식은 안정적이지만, 한 번의 run이 보통 새로운 volume 하나를 만들고 끝나기 때문에, 매우 sparsely filled volume이 많이 생긴 상황에서는 회수 속도가 부족했다.

이를 해결하기 위해 Dropbox는 두 가지 전략을 추가했다.

• L2: 중간 정도로 비어 있는 volume들을 여러 개 묶어, 새 destination volume을 거의 꽉 채우도록 만드는 bounded packing 문제로 풀었다. dynamic programming을 사용하되, source volume 개수 제한과 byte granularity coarsening으로 계산량과 메모리를 제한했다.
• L3: 가장 sparsely filled 된 tail을 대상으로 Live Coder를 streaming pipeline처럼 활용해 live blobs를 계속 다시 encode했다. 덜 채워진 volume부터 빠르게 drain해 reclaim 속도를 높였지만, blob 재작성과 metadata update가 늘어나는 tradeoff가 있다.

운영 측면에서는 compaction이 user traffic과 경쟁하지 않도록 rate limit을 두고, cell 내부에서만 처리해 data center 간 이동은 피했다. 또한 host eligibility threshold를 고정값이 아니라 fleet signal에 따라 조정하는 dynamic control loop로 바꿔, overhead가 오르면 더 공격적으로 reclaim하고 안정되면 다시 완화하도록 만들었다.

결과적으로 L2는 production에서 L1보다 2~3배 빠르게 overhead를 낮췄고, L2가 활성화된 cell에서는 일주일 기준 30~50% 더 낮은 compaction overhead를 달성했다. L1이 steady state를 지키고, L2가 중간층을 정리하고, L3가 가장 sparse한 꼬리를 비우는 layered strategy로 바꾸면서, Dropbox는 immutable blob store의 공간 효율을 다시 안정권으로 되돌렸다.