Swift 에서 기간이 만료된 파일 삭제 처리관련 문의사항

원글

질문

안녕하세요.
일전에도 질문드렸었던 Swift 에서 만료파일 삭제 처리와 관련하여 몇가지 문의사항이 있어 질문드려봅니다.
현재 겪고 있는 문제는 다량의 파일이 주기적으로 업데이트와 삭제를 반복하고 있는 패턴을 보이고 있는 서비스 환경에서, 만료된 파일의 tomestone (.ts) 및 suffix/hash 디렉토리가 완전히 삭제되지 않고 남아있어 실제로 존재하는 object 보다 더 많은 디스크 inode 가 쌓이고 있다는 점입니다. 이는 더 작고, 빈번한 요청의 경우 더 큰 부하를 일으키는 주요 원인이 되리라 생각됩니다. object 만료처리를 위해 업로드시 “X-Delete-After” 키워드를 사용하고있으며 tomestone 유지시간인 “reclaim_age” 는 매우 짧게 설정하여 테스트하고있습니다.
기대하는 object life cycle 는 아래와 같습니다.

  1. object 업로드 (x-delete-after)
  2. object-expirer 데몬에서 만료파일 삭제 timestamp.data -> timestamp.ts
  3. replicator 에서 reclaim_age 초과된 timestamp.ts 및 suffix 디렉토리 삭제
  4. sqlite3 테이블에서 deleted=1 로 설정된 row 삭제

문제가 되는 부분은, 3번에서 replicator 가 만료 파일에 대한 정리를 제대로 하고있지 않다는것이며, 삭제는 잘 되지면 그 잔여 기록들은 reclaim_age 를 초과하여도 정리가 되고 있지 않음을 확인하였습니다.
보다 명확한 이해를 위해 관련 소스코드를 확인해보았습니다. 그결과, replicator 에서는 주기적으로 ring 에서 파티션정보를 가져와 각 파티션의 hashes.pki 파일을 확인하고 suffix, hash 값을 가져와 replicator 등을 수행하는데, hashes.pki 파일을 확인하는 과정에서 “hash_cleanup_listdir” 로직을 통해 tomestone, suffix dir 등을 삭제처리하게 됩니다. 하지만 object-expirer 는 timestamp.ts 로 정리만 할뿐 hashes.pki 파일에 대한 suffix, hash 딕셔너리 값은 삭제하지 않으며, 이후에도 주기적으로 파티션을 검사하는 로직에서도 만료파일 정리 로직은 전혀 발생하지 않는다는 결론입니다.
(그외 put 이벤트에도 해당로직이 발생하는것이 확인되었으나, 기대하는 로직은 만료파일에 대한 명확한 삭제입니다)

해당 이슈에 대해서는 irc 채널에서 애기해본결과 아래와 같이 버그 리포트에 등록하였습니다.
https://bugs.launchpad.net/swift/+bug/1301728

해당문제를 해결하기 위해 직접 소스코드를 수정할까 하였지만 일단은 별도의 스크립트를 작성하여 partition 내부의 hashes.pki 파일을 삭제해 보았으며, 이경우 replicator 에서는 hash 를 찾지못해 해당 파티션에 대해 hashes.pki 파일을 재구성하고 그 과정에서 만료된 파일 및 디렉토리 또한 의도한대로 정리되는것을 확인하였습니다. 보다 더 테스트를 진행해보고 시스템에도 적용해볼 예정중에 있으나, 다른 선배님들은 혹시 이러한 문제에 대해 어떻게 대처하셧는지 궁금하며 아니면 이러한 이슈사항은 swift 에서 의도한 사항인데 제가 컨셉을 잘못 이해한것이 아닌지 궁금합니다.


추가로 한가지 더 질문드려봅니다.
3-replicator 설정에서, object upload 시 각각 다른 zone 에 분할하여 복사본이 존재하는것이 swift ring 분배 컨셉입니다. 하지만 최초 업로드 시점에는 zone 분리 여부와는 관계없이 중복 zone 에도 복사본을 생성하는것으로 확인되며, 이후 각기 다른 zone 으로 복사본이 이동하는것으로 확인됩니다.

왜 한번에 각 zone에 대해 독립적으로 복사본을 생성하지 않는지 궁금하며 그 이후 이동하는 역할은 어떤 데몬에서 하는지 궁금합니다.
(object-auditor 소스코드를 훑어보고있는 중입니다.)

감사합니다. 좋은 하루되십시요.

답변

댓글로 확인하세요….
너무 길어요…..