donghyeon.kang/llm-wiki

Fork 0

Files

T

DongHyeonka 58515ab0f3 feat: 공식 문서 근거자료, 브랜치 기능 문서 작성

2026-07-29 18:05:17 +09:00

6.0 KiB

Raw Permalink Blame History

title, source_type, url, archive_url, related_branches, related_projects, tags, created

title

source_type

url

archive_url

related_branches

related_projects

AWS — Amazon S3 multipart upload limits

Layer: raw/ — 외부 자료의 원문 발췌·출처 기록.

활용 branch (필수, 최소 1개+)

Branch	이 자료가 정당화하는 결정
`[[raw/branch-notes/feature-frontend-large-object-transfer-contract]]`	`TRANSFER_PART_SIZE_BYTES` 의 하한 검증이 필요한 이유(`D8`), part 수 상한이 최대 전송 크기를 결정한다는 사실

출처

원본 URL: https://docs.aws.amazon.com/AmazonS3/latest/userguide/qfacts.html
보조 URL:
아카이브 URL:
저자 / 조직: Amazon Web Services (Amazon S3 User Guide)
발행일: (문서 지속 갱신)
마지막 확인일: 2026-07-28

왜 저장했는지

branch 가 part size default 를 8 MiB, 병렬도를 3 으로 적어 두었는데 "측정값이 아니라 초기 default" 라고만 밝혀 두었다. 문제는 part size 가 취향의 문제가 아니라 vendor 가 강제하는 하한이 있는 값이라는 점이다. 하한 아래로 설정하면 전송이 마지막 part 를 제외한 전 구간에서 거부된다. vendor 를 아직 고르지 않았더라도(FE-Q-012) 대표적인 구현 하나의 실제 수치를 확보해야 "하한 검증을 계약에 넣어야 한다" 를 근거 있게 말할 수 있다.

⚠️ vendor 선택이 아니다. 이 문서는 Amazon S3 의 제약을 증명할 뿐이며, 이 프로젝트가 S3 를 쓴다는 결정은 존재하지 않는다(FE-Q-012 미해소). 다른 vendor 의 수치는 다를 수 있다.

핵심 인용

[§Amazon S3 multipart upload limits] "In general, when your object size reaches 100 MB, you should consider using multipart uploads instead of uploading the object in a single operation."

[§Amazon S3 multipart upload limits] "There is no minimum size limit on the last part of your multipart upload."

[§표 — Maximum object size] "48.8 TiB"

[§표 — Maximum number of parts per upload] "10,000"

[§표 — Part numbers] "1 to 10,000 (inclusive)"

[§표 — Part size] "5 MiB to 5 GiB. There is no minimum size limit on the last part of your multipart upload."

[§표 — Maximum number of parts returned for a list parts request] "1000"

추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
C1	S3 multipart 의 part size 는 5 MiB 이상 5 GiB 이하여야 한다	[§표 — Part size] "5 MiB to 5 GiB."	`official-reference`	Amazon S3	다른 object storage 의 하한이 같다는 것
C2	마지막 part 에는 최소 크기 제한이 없다	[§limits] "There is no minimum size limit on the last part of your multipart upload."	`official-reference`	Amazon S3	마지막 part 를 특별 취급하지 않아도 된다는 뜻 — 오히려 분할 로직이 이 예외를 알아야 한다
C3	upload 당 part 수는 최대 10,000 이며 part number 는 1~10,000 이다	[§표] "Maximum number of parts per upload / 10,000"	`official-reference`	Amazon S3	10,000 을 넘는 분할이 다른 vendor 에서도 불가능하다는 것
C4	단일 객체 최대 크기는 48.8 TiB 다	[§표 — Maximum object size] "48.8 TiB"	`official-reference`	Amazon S3	브라우저가 그 크기를 다룰 수 있다는 것
C5	list parts 요청 1회가 돌려주는 part 는 최대 1000 개다	[§표] "Maximum number of parts returned for a list parts request / 1000"	`official-reference`	S3 API 소비자	프론트가 list parts 를 직접 호출한다는 것 — presigned 방식에서는 backend 책임일 수 있다
C6	100 MB 부터 multipart 사용을 고려하도록 권고한다	[§limits] "when your object size reaches 100 MB, you should consider using multipart uploads"	`official-reference`	S3 사용자 일반	100 MB 미만에서 multipart 가 금지된다는 것 — 권고이지 제약이 아님

적용 경계

이 자료가 직접 증명하는 것:
- C1~C5: S3 의 part size 범위·part 수 상한·객체 크기 상한이라는 하드 제약의 존재와 실제 수치
이 자료가 증명하지 않는 것:
- 이 프로젝트가 S3 를 쓴다는 것 (FE-Q-012 미해소)
- part size 8 MiB 나 병렬도 3 이 최적이라는 것 — 이 문서는 성능이 아니라 허용 범위만 말한다
- 브라우저에서 10,000 part 를 병렬 관리하는 것이 현실적이라는 것
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- 실제 선택 vendor 의 part size 하한 (FE-Q-012) — 그 값이 TRANSFER_PART_SIZE_BYTES 검증의 기준이 된다
- part size × part 수 상한으로 계산되는 최대 전송 크기를 제품이 수용하는지

메모

인용 1 해석 후보 (미검증): C1+C3 을 곱하면 고정 part size 가 최대 전송 크기를 결정한다. 8 MiB × 10,000 ≈ 80 GB. 이 계산은 우리 도출이며 AWS 가 그렇게 적은 것이 아니다. 그 이상을 전송하려면 part size 를 키우거나 분할 전략을 바꿔야 한다.
인용 2 해석 후보 (미검증): C1 의 하한 때문에 TRANSFER_PART_SIZE_BYTES 는 자유값이 아니라 검증 대상 계약값이다. 8 MiB 는 S3 하한을 넘지만, 하한을 넘는다는 사실 자체를 부팅 시 검사하지 않으면 vendor 를 바꾸는 순간 조용히 깨진다.
추가로 봐야 할 동일 출처 페이지: mpuoverview (multipart upload 개요), presigned URL 만료 정책 문서

6.0 KiB Raw Permalink Blame History Unescape Escape