멀티파트와 청크 업로드

두 가지입니다. 재시도 단위를 줄이고 병렬로 올려 대역폭을 채웁니다.

단일 요청에는 크기 상한이 있어서 큰 파일은 쪼개는 것이 필수입니다. 상한 아래여도 쪼개는 이유는 실패 비용입니다.

모바일에서 연결이 끊기는 것은 예외가 아니라 정상 상황이므로, 재시도 단위가 작다는 것이 그대로 완주율이 됩니다.

흔한 실수: 멀티파트를 속도 향상 기법으로만 설명하는 것. 병렬 업로드로 빨라지는 것도 맞지만, 실무에서 더 중요한 이득은 실패했을 때 다시 보낼 양입니다. 대역폭이 좁으면 병렬로도 빨라지지 않지만 재시도 이득은 그대로 남습니다.

파일 크기에서 계산합니다. 고정값으로 둘 수 없습니다.

상충이 있습니다. 작게 하면 재시도가 싸지지만 요청 수와 왕복 오버헤드가 늘고, 크게 하면 요청 수가 줄지만 실패 시 다시 보낼 양이 커집니다.

여기에 파트 개수 상한이 겹칩니다. 50GB 를 5MB 로 나누면 10,000개가 되는데 상한이 그보다 낮으면 파트를 키워야 합니다.

파트 크기 = max(최소 파트 크기, 파일 크기 / 파트 개수 상한)

그래서 작은 파일은 최소 크기로, 큰 파일은 개수 상한에 맞춰 커집니다.

흔한 실수: 파트 크기를 상수로 박는 것. 그러면 어느 파일 크기에서 개수 상한을 넘어 업로드가 실패하는데, 테스트 파일이 작으면 그 경계를 만나지 못해 운영에서 터집니다.

올린 파트들이 미완성 업로드로 스토리지에 남고 저장 요금을 냅니다.

합치기를 완료하지 않았으므로 최종 객체는 만들어지지 않습니다. 그런데 파트는 이미 저장돼 있습니다. 문제는 이 조각이 객체 목록에 보이지 않는다는 것입니다.

사용자가 앱을 닫거나 네트워크가 끊기는 것은 흔한 일이라 조각이 계속 쌓입니다. 그래서 일정 기간 지난 미완성 업로드를 자동으로 지우는 규칙을 처음부터 걸어 둡니다.

흔한 실수: 업로드가 실패했으니 아무것도 안 남았다고 답하는 것. 실패 시점에 이미 올라간 파트는 남아 있고, 지우는 쪽은 우리가 설정해야 합니다.

클라이언트 쪽 한계를 봅니다. 무한히 늘리면 오히려 느려집니다.

브라우저는 호스트당 동시 연결 수에 제한이 있어서, 그 이상 늘려도 큐에서 기다립니다. 모바일은 여기에 배터리와 발열 제약이 더해집니다.

실패한 파트만 다시 큐에 넣는 구조로 만들면, 동시 개수를 적게 유지해도 전체 완주율이 떨어지지 않습니다.

흔한 실수: 파트를 전부 동시에 던지는 것. 파트가 500개면 요청 500개를 한 번에 만드는 셈이고, 대부분이 대기하면서 메모리만 점유합니다.