Drive I/O 병목과 오디오 Shard 캐싱

manifest 캐싱과 같은 원리로 오디오도 한 번 잘라서 로컬에 저장해두는 방향으로 바꿨다.

시도와 실패: 병렬 처리

세션당 wav를 여러 번 열던 것부터 sf.SoundFile로 파일을 한 번만 열고 seek()으로 구간 이동하도록 고쳤고, 여기에 ThreadPoolExecutor로 병렬화도 시도했다.

max_workers=8에서 77.5개/분, max_workers=20으로 올리면 오히려 60개/분으로 떨어졌다. 병목이 클라이언트 쪽 동시성이 아니라 Drive API/FUSE 자체의 처리 한계라는 뜻이었다. 결국 병렬화보다 순차 처리로 되돌리는 쪽을 택했다.

용량 초과: 계정 이전과 원복

캐시를 Drive에 영구 저장하기로 하고 float32 .npy로 32,840개를 저장하던 중, 개인 학교 계정 용량(10GB)이 부족해졌다. 4,062개 시점에 8.4GB — 전체 완주하면 약 67GB가 필요한 계산이었다.

개인 Gmail 계정으로 옮기려 했지만, 팀 공유 폴더의 "바로가기"는 원본 폴더 접근 권한이 없는 계정에서는 열리지 않았다. 결국 Google Drive 데스크톱 앱으로 학교 계정에 실제 파일을 로컬 미러링해둔 뒤, 그 로컬 파일을 개인 계정으로 재업로드하는 방식으로 우회했다. 이후 폴더 구조가 바뀌면서 manifest에 저장된 wav_path 컬럼이 옛 경로를 가리키는 문제도 함께 발생해, 문자열 치환으로 정리했다.

결국 계정을 다시 원래 10GB 계정으로 되돌리기로 하면서, 저장 구조 자체를 압축하는 방향으로 정리했다.

최종 구조: 청크 로컬 복사 + Shard 압축

멘토링 답변에서 받은 세 가지 조언을 그대로 반영했다.

• -원본과 캐시는 Drive에 유지
• -전처리는 일정 단위(청크)만 로컬로 복사해서 처리
• -캐시는 개별 파일이 아니라 묶어서 압축 저장

Drive 파일 개수는 32,840개에서 청크 수(약 60여 개) 수준으로 줄었고, float32 → int16 변환과 15초 길이 상한까지 더해 예상 저장량을 10GB 안쪽으로 맞췄다. 학습 시점에는 shard를 로컬로 한 번에 복사해두고, ShardMajorSampler로 같은 shard 내 인덱스를 몰아서 접근하도록 해 캐시 스래싱을 줄였다.

다음 계획

전처리에 시간을 많이 쓰는 동안 팀 회의에서 다른 팀원들 진행 상황을 들었는데, 랜덤포레스트 + MFCC로 진행 중인 팀원은 전처리가 오래 걸리지 않았다고 했다. CNN + raw waveform 캐싱 대신 MFCC 같은 저차원 특징을 먼저 추출해 저장하는 방식이 Drive I/O 총량 자체를 줄여줬을 가능성이 있어 보인다. 다음은 이 부분을 비교해보고, 필요하면 특징 추출 단계를 더 가볍게 바꾸는 것부터 검토할 계획이다.