Day 4 - S3 성능 최적화: 멀티파트 업로드, 전송 가속화, 접두사 설계

S3가 "무한 확장"이라고 광고하지만, 실제로는 어떻게 사용하느냐에 따라 성능이 수십 배 차이가 난다. 잘못된 접두사 설계로 핫 파티션을 만들거나, 단일 PUT으로 대용량 파일을 올리다 네트워크 오류로 처음부터 다시 시작하거나, 전 세계 사용자가 단일 리전 S3를 인터넷을 통해 접근하는 경우 — 이 모든 상황에서 S3는 병목이 된다. 이 day에서는 S3 성능의 수학적 한도를 이해하고, 그 한도를 최대한 활용하는 설계 패턴을 파고든다.

S3의 처리량 한도 — 접두사 단위의 독립적 한도

S3의 처리량은 접두사(Prefix) 단위로 독립적으로 적용된다. 구체적으로:

• 접두사당 초당 3,500 PUT/COPY/POST/DELETE
• 접두사당 초당 5,500 GET/HEAD

"접두사"란 객체 키에서 파일명을 제외한 앞부분이다. photos/2026/01/image.jpg에서 접두사는 photos/2026/01/다.

왜 접두사 단위인가? S3 내부적으로 데이터는 파티션에 분산 저장되며, 같은 접두사를 가진 객체들은 같은 파티션에 배치되는 경향이 있다. 접두사를 다양하게 만들면 S3가 내부적으로 여러 파티션에 분산 저장할 수 있고, 각 파티션의 한도가 독립적으로 적용된다.

[단일 접두사 패턴 - 성능 낮음]
s3://bucket/uploads/file1.jpg    → 3,500 PUT/s 한도 공유
s3://bucket/uploads/file2.jpg
s3://bucket/uploads/file3.jpg

[다중 접두사 패턴 - 성능 높음]
s3://bucket/a/uploads/file.jpg  → 3,500 PUT/s 독립
s3://bucket/b/uploads/file.jpg  → 3,500 PUT/s 독립
s3://bucket/c/uploads/file.jpg  → 3,500 PUT/s 독립
→ 합산 10,500 PUT/s 가능

S3 내부의 파티션 분할 메커니즘은 2012년 Amazon이 특허 출원한 분산 해시 기반 키-밸류 스토리지에 기반한다. 과거(2018년 이전)에는 알파벳 순서가 같은 키들이 같은 파티션에 몰리는 문제가 있어서 키 앞에 랜덤 해시 prefix를 붙이는 것이 권장됐다(abc123/uploads/file.jpg). 2018년부터 S3가 자동 파티션 분할(Automatic Partitioning)을 도입하면서 이런 해킹이 더 이상 필요없어졌다. 하지만 이미 많은 시험 자료에 "랜덤 prefix 추가"가 정답으로 나와 있어 혼동이 생긴다 — 현재는 다양한 prefix를 사용하는 것이 권장이지 랜덤 문자를 앞에 붙이는 게 아니다.

Burst Capacity — 일시적 트래픽 급증 처리

S3는 접두사당 처리량 한도를 초과하는 요청에 즉시 throttling하지 않는다. 일정 시간 미사용된 용량을 누적했다가 갑작스러운 트래픽 급증에 사용하는 Burst Capacity 메커니즘이 있다.

Burst Capacity의 동작 원리: 미사용 용량은 최대 300초(5분) 치까지 누적된다. 트래픽이 급증하면 이 누적된 용량을 먼저 소진한 후 throttling이 시작된다. 별도 설정이 필요없고 자동으로 동작한다.

실무적 함의: 1시간에 한 번 대량 파일을 올리는 배치 작업이 있다면, Burst Capacity 덕분에 한도를 일시적으로 초과할 수 있다. 하지만 지속적으로 한도를 초과한다면 접두사를 분산시키거나 S3에 직접 올리지 않고 SQS를 거쳐 순차 처리하는 패턴이 필요하다.

멀티파트 업로드 — 대용량 파일 업로드의 표준

단일 PUT 요청으로 업로드할 수 있는 최대 크기는 5GB다. 5TB 객체를 올리려면 반드시 Multipart Upload를 사용해야 한다.

Multipart Upload의 3단계:

1. CreateMultipartUpload
   → UploadId 발급 (이 ID로 이후 작업 식별)

2. UploadPart (병렬로 N번)
   → 각 파트에 1~10,000 번호 부여
   → 파트 크기: 최소 5MB (마지막 파트 예외), 최대 5GB
   → 각 파트 완료 시 ETag 반환

3. CompleteMultipartUpload
   → 파트 번호 + ETag 목록 제출
   → S3가 파트들을 합쳐 단일 객체 완성
   → 성공 시 최종 ETag 반환

Multipart의 핵심 이점은 세 가지다. 첫째, 병렬 업로드 — 10개 파트를 동시에 올리면 이론적으로 10배 속도 향상이 가능하다. 둘째, 부분 재전송 — 네트워크 오류로 5번 파트가 실패해도 1~4번과 6~N번은 다시 올릴 필요 없다. 셋째, 스트리밍 업로드 — 파일 크기를 미리 알 수 없을 때도 파트 단위로 업로드를 시작할 수 있다(마지막 파트는 어떤 크기든 가능).

⚠️ 함정: 완료되지 않은 멀티파트 업로드는 S3에 "중간 파트"로 영구히 저장되며 저장 비용이 계속 발생한다. 어플리케이션이 크래시하거나 업로드를 취소해도 이미 업로드된 파트들은 자동으로 정리되지 않는다. 수명 주기 정책에 AbortIncompleteMultipartUpload를 반드시 추가해야 한다. "7일 후 미완료 멀티파트 자동 삭제" 같은 규칙이 없으면 비용이 조용히 쌓인다.

import boto3
from boto3.s3.transfer import TransferConfig
 
s3 = boto3.client('s3')
 
config = TransferConfig(
    multipart_threshold=1024 * 25,  # 25MB 이상이면 멀티파트
    max_concurrency=10,              # 최대 10개 병렬 스레드
    multipart_chunksize=1024 * 25,  # 파트 크기 25MB
    use_threads=True
)
 
# boto3 transfer manager가 자동으로 멀티파트 처리
s3.upload_file(
    'large_file.zip',
    'my-bucket',
    'uploads/large_file.zip',
    Config=config
)

boto3의 TransferManager는 임계값 이상의 파일을 자동으로 멀티파트로 처리한다. 직접 CreateMultipartUpload API를 호출할 필요 없다.

바이트 범위 가져오기(Byte-Range Fetches) — 병렬 다운로드

HTTP Range 헤더를 사용하면 객체의 특정 바이트 범위만 요청할 수 있다. 이를 활용한 3가지 패턴:

병렬 다운로드: 10GB 파일을 1GB씩 10개 범위로 나누어 동시 다운로드 → 이론적 10배 속도 파일 헤더 조회: 첫 수백 바이트만 다운로드해서 파일 타입/메타데이터 확인 중단된 다운로드 재개: 끊긴 지점부터 이어받기

# Range 헤더로 파일의 첫 1KB만 다운로드
response = s3.get_object(
    Bucket='my-bucket',
    Key='large-video.mp4',
    Range='bytes=0-1023'
)
file_header = response['Body'].read()
 
# 병렬 다운로드: 10MB~20MB 구간
response = s3.get_object(
    Bucket='my-bucket',
    Key='large-file.bin',
    Range='bytes=10485760-20971519'
)

HTTP Range Request는 RFC 7233에 정의된 표준이다. S3는 이 표준을 완전히 지원하며, 동시에 여러 Range 요청을 보내는 것도 허용된다. 이 기법은 P2P 다운로드 클라이언트(BitTorrent, 다운로드 매니저)에서 수십 년간 사용된 기술을 HTTP로 구현한 것이다. S3의 병렬 Range 다운로드는 이론적으로 단일 접두사 한도인 5,500 GET/s 이내에서 자유롭게 사용할 수 있다.

S3 Transfer Acceleration — 엣지 경유 업로드 가속

Transfer Acceleration은 CloudFront 엣지 네트워크를 활용해 업로드 속도를 높인다. 클라이언트는 가장 가까운 CloudFront 엣지 로케이션에 업로드하고, 엣지에서 AWS 내부 백본 네트워크를 통해 목적지 S3 버킷으로 전달된다.

일반 업로드 경로:
[서울 클라이언트] → 퍼블릭 인터넷 → [us-east-1 S3]
(지연 시간 높음, 패킷 손실 가능성)

Transfer Acceleration 경로:
[서울 클라이언트] → AWS 서울 엣지(최적화된 경로) → AWS 백본 → [us-east-1 S3]
(내부 네트워크 = 낮은 지연, 높은 안정성)

활성화 방법: 버킷 단위로 설정, 추가 비용 발생(GB당 $0.04). URL은 bucket.s3-accelerate.amazonaws.com으로 변경된다.

언제 사용하는가: ① 전 세계 사용자가 단일 리전 버킷에 업로드할 때, ② 장거리 업로드에서 네트워크 불안정성이 문제일 때. 같은 리전 내 업로드에는 효과 없다.

Transfer Acceleration vs CloudFront vs Multi-Region Access Point 비교

MRAP(Multi-Region Access Point)는 2021년 출시된 기능으로, 여러 리전의 버킷을 묶어 글로벌 엔드포인트 하나로 접근하게 한다. 요청은 자동으로 가장 가까운 리전의 버킷으로 라우팅된다. CRR(Cross-Region Replication)과 함께 사용하면 글로벌 Active-Active 패턴을 구현할 수 있다.

S3 Select — SQL로 필요한 데이터만 가져오기

10GB CSV 파일에서 특정 조건의 행 100개만 필요한 상황을 가정한다. 일반적인 방법은 10GB를 전부 다운로드한 후 클라이언트에서 필터링하는 것이다. S3 Select는 S3 서비스 측에서 SQL을 실행하여 필터링된 결과만 반환한다.

-- S3 Select SQL 예시: CSV에서 나이 30 이상인 사용자만
SELECT s.name, s.email 
FROM s3object s 
WHERE CAST(s.age AS INTEGER) > 30

지원 형식: CSV, JSON, Parquet (GZIP/BZIP2 압축도 지원). 비용: 스캔한 GB + 반환한 GB 기준 과금.

제한사항: 단순 SELECT/WHERE만 지원하고 JOIN, GROUP BY, 서브쿼리 등은 불가. 복잡한 쿼리가 필요하면 Amazon Athena를 사용해야 한다.

S3 Select로 필요한 행만 추출하면, 100GB 파일을 전부 내려받아 Spark 클러스터에서 처리하는 방식보다 전송량과 EC2 처리 비용이 크게 줄어든다. S3 API 요청 비용은 늘 수 있지만 전체 비용은 낮아질 수 있다.

CloudFront + S3 Origin Access Control — 비공개 S3 보안 배포

정적 웹사이트나 다운로드 파일을 CloudFront를 통해 배포할 때, S3 버킷을 퍼블릭으로 열면 CloudFront를 우회한 직접 접근이 가능해진다. OAC(Origin Access Control)는 CloudFront만 S3에 접근할 수 있게 제한하는 메커니즘이다.

OAC 설정 후 버킷 정책에서 CloudFront 서비스 주체를 허용하고 나머지는 거부하면, 퍼블릭 인터넷에서 S3 URL로 직접 접근하면 403이 반환된다.

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Service": "cloudfront.amazonaws.com"
    },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/ABCDEF"
      }
    }
  }]
}

⚠️ 함정: 시험 자료가 2022년 이전에 작성됐다면 "CloudFront + S3 비공개 배포"의 답으로 OAI가 나온다. 2022년 이후에는 OAC가 권장이며 SSE-KMS 암호화 객체도 CloudFront로 서빙할 수 있다. 시험 문제에서 "CloudFront가 SSE-KMS 암호화된 S3 객체를 서빙해야 한다"는 조건이 있으면 OAC가 유일한 답이다.

S3 Athena와의 결합 — 데이터 레이크 패턴

S3 Select가 단일 객체에 대한 간단한 필터링이라면, Amazon Athena는 수천 개의 S3 파일을 분산 쿼리 엔진(Presto/Trino 기반)으로 처리하는 서비스다.

"수억 개의 S3 객체에서 SQL로 복잡한 분석" → Athena. "하나의 10GB 파일에서 일부 행만 추출" → S3 Select.

S3 + Athena + Glue Data Catalog 조합이 AWS 데이터 레이크의 표준 아키텍처다. Parquet나 ORC 형식으로 저장하면 Athena 스캔 비용을 대폭 줄일 수 있다(컬럼 기반 형식이라 필요한 컬럼만 읽음).

S3의 성능 최적화는 단순히 "빠르게"가 아니라 처리량·지연 시간·비용의 균형을 맞추는 설계 문제다. 멀티파트, Transfer Acceleration, Byte-Range, S3 Select, CloudFront OAC — 각 도구가 어떤 상황에서 최적인지를 이해하면 시험의 시나리오 문제를 자연스럽게 풀 수 있다.