객체 스토리지와 CDN
💡 학습 가이드: 이 글은 파일 업로드부터 사용자 다운로드까지의 전체 연결고리를 안내합니다. 객체 스토리지가 "스마트 창고"처럼 대량의 파일을 관리하는 방법, CDN이 "택배 물류망"처럼 콘텐츠를 사용자家门口까지 전달하는 방법, 그리고 그 사이에 어떤 "함정"이 있는지 알아보겠습니다. 기본적인 HTTP 요청과 DNS 해석 원리를 먼저 이해하는 것을 권장합니다.
시작하기 전에 몇 가지 "기본 지식"을 보충하는 것을 권장합니다:
- HTTP 요청 흐름: 브라우저에 URL을 입력하면 무슨 일이 일어나는가를 먼저 읽고 전체 요청 연결고리를 이해하세요.
- DNS 해석 원리: 도메인 해석에 익숙하지 않다면 DNS 쿼리 흐름의 그림 설명 부분을 먼저 보세요.
0. 서론: 왜 파일 업로드/다운로드가 이렇게 "느린"가?
이 시나리오를 상상해 보세요: 이미지 커뮤니티에서 10MB 고화질 사진을 업로드했는데, 반 분이나 걸려서 완료되었습니다. 반면 베이징에 있는 친구는 다운로드하는 데 2초밖에 걸리지 않았습니다. 같은 파일인데 업로드와 다운로드 경험이 왜 이렇게 다를까요?
또 다른 상황을 생각해 보세요: 전자상거래 웹사이트에서 더블 11(광군제) 이벤트를 하고, 상품 상세 페이지에 갑자기 백만 트래픽이 몰려 서버가 "다운"되었습니다. 대역폭이 부족한 걸까요? 아니면 아키텍처 설계에 문제가 있는 걸까요?
이러한 질문의 답은 객체 스토리지와 CDN이라는 "황금 파트너십"에 숨겨져 있습니다.
1. 객체 스토리지: 당신의 "스마트 클라우드 창고"
1.1 객체 스토리지란 무엇인가?
전통적인 파일 시스템은 집의 옷장과 같습니다: 옷을 "상의/바지/치마"로 계층적으로 분류하고, 셔츠 하나를 찾으려면 옷장 열기 → 상의 구역 → 셔츠 칸 순서로 찾아야 합니다. 이런 "계층적 중첩" 모델은 파일 수가 폭발적으로 늘어나면 매우 불편해집니다.
객체 스토리지는 현대 물류 창고와 같습니다: 각 소포에는 유일한 "택배 번호"(객체 키)가 있으며, 번호만 말하면 로봇이 수많은 소포 중에서 정확하게 찾아냅니다.
핵심 차이 비교:
| 차원 | 전통적 파일 시스템 | 객체 스토리지 |
|---|---|---|
| 구성 방식 | 계층적 디렉토리 트리 | 평면적 키-값 쌍 |
| 접근 프로토콜 | POSIX(로컬 파일 작업) | HTTP/REST API |
| 확장성 | 단일 서버 용량 제한 | 거의 무한한 수평 확장 |
| 메타데이터 | 기본 속성(크기, 시간) | 풍부한 커스텀 메타데이터 |
| 대표적 시나리오 | 로컬 오피스 문서 | 이미지/비디오/백업/정적 리소스 |
1.2 객체 스토리지의 핵심 개념
버킷(Bucket): "창고 구역"
버킷은 객체 스토리지의 최상위 컨테이너로, 독립적인 네임스페이스입니다. 모든 객체는 어떤 버킷에 보관되어야 합니다.
명명 규칙(알리바바 클라우드 OSS 기준):
- 전역 고유: 클라우드 제공자의 모든 사용자 중에서 중복 불가
- 소문자, 숫자, 하이픈만 포함 가능
- 소문자나 숫자로 시작하고 끝나야 함
- 길이 3~63자
실전 주의사항: 한 팀이 비즈니스 라인별로 수십 개의 버킷을 만들었는데, 월말 청구서를 보고 깜짝 놀랐습니다 — 각 버킷마다 최소 스토리지 비용과 요청 비용이 부과되었습니다. 권장 사항: "환경+용도" 조합으로 버킷을 계획하세요. 예: prod-static-assets, dev-backup-archive.
객체(Object): "데이터 소포"
객체는 스토리지의 기본 단위로, 세 부분으로 구성됩니다:
키(Key): 객체의 유일한 식별자, "택배 번호"에 해당
- 예시:
images/avatar/2024/user123.jpg - 경로처럼 보이지만 본질은 문자열
- 예시:
데이터(Data): 객체의 내용 자체
- 임의의 바이너리 데이터
- 크기 제한은 클라우드 제공자에 따라 다름(보통 단일 객체 5TB 이내)
메타데이터(Metadata): 객체를 설명하는 추가 정보
- 시스템 메타데이터: Content-Type, ETag, Last-Modified 등
- 커스텀 메타데이터: 예:
x-oss-meta-owner,x-oss-meta-project
접근 제어: 누가 내 "창고"를 건드릴 수 있는가?
객체 스토리지는 다층 권한 제어를 제공합니다:
| 계층 | 제어 방식 | 대표적 시나리오 |
|---|---|---|
| 버킷 수준 | Bucket Policy(리소스 정책) | 모든 외부 접근 차단, 특정 IP만 허용 |
| 객체 수준 | ACL(접근 제어 목록) | 공개 이미지, 비공개 문서 |
| 임시 권한 | STS(보안 토큰 서비스) | 프론트엔드 직접 업로드, 모바일 업로드 |
보안 레드라인: AccessKey ID와 AccessKey Secret을 프론트엔드 코드에 절대 작성하지 마세요! 올바른 방법: 프론트엔드에서 백엔드에 임시 STS 자격 증명을 요청하고, 백엔드가 신원을 확인한 후 만료 시간이 있는 임시 자격 증명을 반환합니다.
2. CDN: "글로벌 택배 네트워크"
2.1 왜 CDN이 필요한가?
선전에 서버를 둔 쇼핑몰을 운영한다고 상상해 보세요. 지금 베이징 사용자가 이미지에 접근합니다:
CDN이 없는 경우: 요청이 베이징→허베이→허난→후베이→후난→광둥→선전을 거치며, 2,000km 이상을 횡단합니다. 왕복이면 4,000km 이상입니다. 네트워크 전송만으로도 수십 밀리초가 걸리며, 네트워크 정체 시 더 심합니다.
CDN이 있는 경우: 요청이 베이징의 CDN 노드(베이징 유니콤 데이터 센터에 있을 수 있음)로 바로 전달되어, 거리가 2,000km에서 20km로 줄고 지연이 50ms에서 5ms로 줄어듭니다.
이것이 CDN의 핵심 가치입니다: 콘텐츠를 사용자에게 더 가까이.
2.2 CDN의 핵심 아키텍처
엣지 노드: 사용자에게 가장 가까운 "택배소"
엣지 노드는 CDN 네트워크에서 사용자에게 가장 가까운 계층으로, 보통 다음과 같은 곳에 배포됩니다:
- 통신사 데이터 센터(유니콤/차이나텔레콤/차이나모바일)
- 대도시 인터넷 익스체인지 포인트
- 주요 교통 요충지
한국 주요 CDN 노드 분포:
- 수도권: 서울, 인천
- 지방: 부산, 대구, 광주, 대전
- 해외: 도쿄, 싱가포르, 실리콘밸리, 프랑크푸르트
Edge Node Distribution Demo
Shows global CDN edge-node distribution and scheduling strategy.
Edge node distribution demo placeholder - interaction to be implemented
원본 서버: 콘텐츠의 "본 창고"
원본 서버는 CDN이 콘텐츠를 가져오는 곳으로, 다음이 될 수 있습니다:
- 객체 스토리지(OSS/COS/S3)
- 자체 구축 서버(ECS/물리 서버)
- 로드 밸런서(SLB/CLB)
주요 설정:
- 오리진 HOST: CDN 노드가 원본 서버에 접근할 때 사용하는 도메인/IP
- 오리진 프로토콜: HTTP인지 HTTPS인지
- 오리진 포트: 80, 443 또는 커스텀 포트
중간 계층 노드: "지역 배송 센터"
엣지 노드와 원본 서버 사이에 CDN은 보통 한 계층 이상의 중간 노드를 둡니다:
- 집계 노드: 여러 엣지 노드의 오리진 요청을 집계하여 원본 서버 부하 감소
- 지역 센터: 하나의 대지역의 콘텐츠 배포와 스케줄링 담당
이러한 계층적 아키텍처의 장점:
- 원본 서버 부하 감소: 1,000개의 엣지 노드 요청이 원본 서버에는 10번의 요청만 발생
- 적중률 향상: 인기 콘텐츠가 중간 계층에서 차단되어 오리진 필요 없음
- 장애 격리: 특정 링크에 문제가 발생하면 다른 경로로 자동 전환
2.3 CDN 가속의 전체 프로세스
실제 사용자 요청을 추적해 보겠습니다:
Cache policy demo placeholder - interaction to be implemented
1단계: DNS 해석(스마트 스케줄링)
사용자 입력: cdn.example.com/image.jpg
↓
DNS 서버 반환: 베이징 유니콤 CDN 노드 IP(1.2.3.4)핵심은 스마트 DNS: 사용자의 통신사, 지리적 위치, 노드 부하에 따라 최적의 CDN 노드 IP를 반환합니다.
2단계: 엣지 노드 검색(캐시 적중 여부?)
요청이 베이징 유니콤 CDN 노드(1.2.3.4)에 도달
↓
노드가 로컬 캐시 확인:
├─ 적중? 콘텐츠를 직접 반환 ✓
└─ 미적중? 다음 단계로 이동3단계: 오리진 가져오기(계층별 상향)
엣지 노드 미적중
↓
부모 노드(예: 화북 지역 센터)에 요청
├─ 부모 노드 적중? 콘텐츠 반환
└─ 부모 노드 미적중? 계속 상향
↓
원본 서버에 요청
↓
원본 서버가 콘텐츠 반환4단계: 캐싱 및 반환(다음 접속은 더 빠르게)
콘텐츠가 링크를 따라 반환됨
↓
각 계층의 노드가 복사본을 캐싱
↓
최종적으로 사용자에게 도달이렇게 하면 다음에 같은 파일을 요청하는 사용자가 있으면 엣지 노드에서 직접 반환되어 "즉시 로딩"이 가능합니다.
3. 업로드부터 접근까지: 전체 연결고리 분석
3.1 파일 업로드의 세 가지 방법
방법 1: 클라이언트 → 서버 → 객체 스토리지(전통적 모델)
브라우저 → 백엔드 서버 → 객체 스토리지장점:
- 구현이 간단하여 프론트엔드/백엔드 모두 제어가 쉬움
- 백엔드에서 파일 검증, 포맷 변환 가능
- 민감한 작업에 로그 기록, 권한 검증 가능
단점:
- 대역폭 이중 소비: 사용자 업로드가 대역폭을 한 번 차지하고, 서버 전송이 또 한 번 차지
- 서버 부하 증가: 대용량 파일은 메모리와 CPU를 많이 사용
- 업로드 속도 저하: 중간에 한 단계가 더 있어 사용자가 체감하는 업로드 시간이 길어짐
적용 시나리오: 소용량 파일(<10MB), 백엔드 처리 필요(이미지 압축, 워터마크 등), 내부 관리 시스템.
방법 2: 클라이언트 직접 업로드(현대적 권장 방법)
브라우저 ──────→ 객체 스토리지
↑
백엔드는 임시 자격 증명만 발급장점:
- 업로드 속도 빠름: 중간 단계가 없어 사용자 체감 속도가 가장 빠름
- 서버 부하 감소: 자격 증명 발급만 처리, 파일 스트림 처리하지 않음
- 대역폭 절약: 한 번의 업로드 트래픽만 발생
- 보안성 높음: 임시 자격 증명에 만료 시간이 있어 유출되어도 피해가 제한적
적용 시나리오: 대용량 파일 업로드, 사용자 생성 콘텐츠(UGC), 높은 동시성 업로드가 필요한 비즈니스.
방법 3: 멀티파트 업로드 + 재개 가능 업로드(대용량 파일 필수)
10GB 비디오 파일
↓
1000개의 10MB 분할 조각으로 분할
↓
병렬 업로드(동시에 5개 조각 전송)
↓
네트워크 끊김! 600개 전송 완료
↓
네트워크 복구, 601번째부터 이어서 전송
↓
모든 조각 전송 완료, "병합" 요청 발송3.2 CDN 오리진 정책 상세
Cache policy demo placeholder - interaction to be implemented
"오리진"이란 무엇인가?
CDN 엣지 노드가 원본 서버의 콘텐츠를 캐싱하지만, 다음과 같은 경우:
- 사용자가 요청한 콘텐츠가 처음으로 접근
- 캐싱된 콘텐츠가 만료됨(TTL 만료)
- 캐시가 수동으로 갱신/예열됨
CDN 노드가 원본 서버에 최신 콘텐츠를 요청해야 하며, 이 과정을 "오리진(원본 가져오기)"이라고 합니다.
오리진의 세 가지 모드
| 모드 | 원리 | 적용 시나리오 | 장단점 |
|---|---|---|---|
| 직접 오리진 | CDN 노드 → 원본 서버 | 원본 서버에 공인 IP가 있고 트래픽이 많지 않음 | 간단하고 직접적이지만 원본 서버 부하가 높음 |
| 중간 오리진 | CDN 노드 → 중간 계층 → 원본 서버 | 대형 웹사이트, 다층 캐시 아키텍처 | 원본 서버 부하 분산, 아키텍처가 복잡함 |
| OSS/COS를 원본으로 | CDN 노드 → 객체 스토리지 | 정적 리소스, 이미지, 비디오 | 모범 사례, 비용 낮고 성능 좋음 |
3.3 캐시 정책 설정
Cache policy demo placeholder - interaction to be implemented
캐시 키(Cache Key): "같은 파일"의 기준
CDN이 두 요청이 같은 캐시 복사본을 반환해야 하는지 어떻게 판단할까요? 캐시 키가 그 역할을 합니다.
캐시 시간(TTL): 콘텐츠 "신선도"의 균형
TTL(Time To Live)은 콘텐츠가 CDN 노드에 캐싱되는 기간을 결정합니다. 너무 짧게 설정하면 오리진이 많아지고 비용이 증가하며, 너무 길게 설정하면 콘텐츠 업데이트 후 사용자가 이전 콘텐츠를 보게 됩니다.
파일 유형별 TTL 설정 권장 사항:
| 파일 유형 | 권장 TTL | 이유 |
|---|---|---|
| HTML 페이지 | 0-5분 | 콘텐츠가 자주 업데이트되어 실시간성 필요 |
| JS/CSS 파일 | 1년(파일명 해시와 결합) | 콘텐츠가 변하지 않으며 파일명이 변경되면 캐시 무효화 |
| 이미지/비디오 | 7-30일 | 업데이트 빈도가 낮아 장기 캐싱 가능 |
| 폰트 파일 | 1년 | 거의 변하지 않음 |
| API 응답 | 0-5분(비즈니스에 따라) | 데이터 실시간성 요구가 높음 |
캐시 갱신과 예열
수동 갱신(긴급 시나리오):
원본 서버의 콘텐츠를 업데이트했지만 CDN 캐시가 아직 만료되지 않아 사용자가 이전 콘텐츠를 보는 경우:
| 갱신 유형 | 효과 | 소요 시간 | 적용 시나리오 |
|---|---|---|---|
| URL 갱신 | 지정된 URL의 캐시 무효화 | 5-10분 | 단일 파일 업데이트 |
| 디렉토리 갱신 | 지정된 디렉토리의 모든 콘텐츠 무효화 | 10-30분 | 대량 업데이트 |
| 전체 사이트 갱신 | 전체 도메인의 캐시 무효화 | 30분 이상 | 긴급 롤백 |
4. 트래픽 스케줄링: 사용자가 "가장 가까운" 노드에 접속하도록 하기
Traffic scheduling demo placeholder - interaction to be implemented
4.1 스마트 DNS 스케줄링
전통적 DNS 해석:
사용자 질문: cdn.example.com의 IP는 무엇인가요?
DNS 답변: 1.2.3.4(고정)스마트 DNS 해석:
사용자(서울 KT) 질문: cdn.example.com의 IP는 무엇인가요?
스마트 DNS: 확인 중... 서울 KT의 CDN 노드는 1.2.3.4입니다
사용자(부산 SK브로드밴드) 질문: cdn.example.com의 IP는 무엇인가요?
스마트 DNS: 부산 SK브로드밴드의 CDN 노드는 5.6.7.8입니다5. HTTPS 최적화: 보안과 성능의 균형
HTTPS optimization demo placeholder - interaction to be implemented
5.1 CDN에서 HTTPS가 중요한 이유
HTTPS 없음:
사용자가 http://cdn.example.com/image.jpg에 접속
↓
브라우저 주소창에 "안전하지 않음" 표시
↓
특정 브라우저/앱이 접속을 직접 차단
↓
SEO 순위 하락HTTPS 있음:
사용자가 https://cdn.example.com/image.jpg에 접속
↓
브라우저에 녹색 자물쇠 아이콘 표시
↓
HTTP/2 멀티플렉싱 활성화
↓
성능 + 보안 동시 향상6. 접근 분석: CDN 보고서 이해하기
Access analytics demo placeholder - interaction to be implemented
6.1 핵심 지표 해독
적중률(Hit Ratio)
정의: CDN 엣지 노드에서 적중된 요청이 전체 요청에서 차지하는 비율
계산 공식:
적중률 = (적중 수 / 총 요청 수) × 100%
또는
적중률 = (1 - 오리진 트래픽 / 총 아웃바운드 트래픽) × 100%
업계 기준:
- 이미지/비디오/JS/CSS: > 95%
- HTML 페이지: 50-80%(업데이트 빈도에 따라)
- API 인터페이스: 보통 캐싱하지 않거나 매우 낮음7. 실전 사례: 이미지 가속 솔루션을 처음부터 구축하기
7.1 비즈니스 시나리오
이미지 커뮤니티의 기술 책임자로서 다음과 같은 도전에 직면했다고 가정해 보겠습니다:
- 사용자 업로드: 사용자가 매일 100만 장의 이미지 업로드(평균 2MB/장)
- 사용자 접근: 매일 5,000만 회의 이미지 조회 요청
- 접근 분포: 전국에 사용자가 분포, 해외에도 일부 접근
- 성능 요구: 이미지 로딩 시간 < 500ms
- 비용 예산: 월 5만 위안 이내로 통제
7.2 아키텍처 설계
(아키텍처 다이어그램은 원문의 것과 동일한 구조를 유지합니다)
7.3 핵심 설정 상세
객체 스토리지 설정
스토리지 버킷 계획:
Bucket: myapp-images-prod
├─ 디렉토리 구조:
│ ├─ uploads/ # 사용자가 업로드한 원본 이미지
│ ├─ thumbnails/ # 썸네일
│ │ ├─ small/ # 100x100
│ │ ├─ medium/ # 400x300
│ │ └─ large/ # 800x600
│ └─ processed/ # 처리된 이미지(워터마크 등)
│
├─ 접근 권한:
│ ├─ 원본 디렉토리: 비공개(서명 필요)
│ ├─ 썸네일 디렉토리: 공개 읽기
│ └─ CORS: *.myapp.com 접근 허용
│
└─ 수명 주기 정책:
├─ 업로드 7일 후: 저빈도 스토리지(비용 40% 절약)
├─ 업로드 90일 후: 아카이브 스토리지(비용 70% 절약)
└─ 업로드 3년 후: 자동 삭제8. 요약: 객체 스토리지 + CDN의 황금 법칙
8.1 아키텍처 설계 원칙
원칙 1: 동적/정적 분리
동적 콘텐츠(API, HTML) → 원본 서버 또는 엣지 함수 경유
정적 콘텐츠(이미지, JS, CSS, 비디오) → CDN + 객체 스토리지 경유원칙 2: 사용자 근접 서비스
사용자가 어디에 있든 콘텐츠를 해당 위치에 캐싱
→ 커버리지가 넓은 CDN 서비스 제공자 선택
→ 스마트 DNS 스케줄링 활성화
→ 중요 콘텐츠는 사전 예열원칙 3: 계층적 캐시
브라우저 로컬 캐시(가장 강력)
↓
CDN 엣지 노드 캐시(다음으로 강력)
↓
CDN 중간 계층/지역 노드(백업)
↓
객체 스토리지/원본 서버(최후 방어선)8.2 주의사항 체크리스트
스토리지 버킷 명명 및 권한
- [ ] 버킷 이름은 전역 고유, 이미 사용 중인 이름 피하기
- [ ] 비공개 파일은 공개 읽기로 설정하지 않기
- [ ] AccessKey를 프론트엔드 코드에 작성하지 말고 STS 임시 자격 증명 사용
- [ ] 서버 측 암호화(SSE)를 활성화하여 민감 데이터 보호
CDN 캐시 설정
- [ ] HTML 파일의 TTL이 너무 길지 않게(권장 < 5분)
- [ ] JS/CSS는 해시가 포함된 파일명을 사용하고 TTL을 1년으로 설정
- [ ] 캐시 키를 합리적으로 설정하고 사용자 정보 등 가변 값을 포함하지 않기
- [ ] 중요 업데이트 후 캐시 갱신 또는 예열 잊지 않기
HTTPS 보안
- [ ] 인증서가 만료되지 않도록 자동 갱신 설정
- [ ] 최소 TLS 버전은 1.2 권장
- [ ] 다운그레이드 공격 방지를 위해 HSTS 활성화
- [ ] 민감한 쿠키에 Secure와 HttpOnly 설정
비용 관리
- [ ] 대역폭 상한 알림을 활성화하여 비정상 트래픽 방지
- [ ] 저빈도/아카이브 스토리지는 최소 보관 기간과 조기 삭제 수수료에 주의
- [ ] 오리진 트래픽 비용도 비싸므로 CDN 적중률을 높이기 위해 노력
- [ ] 정기적으로 접근 로그를 분석하여 좀비 리소스 정리
9. 용어 대조표
| 영문 용어 | 한국어 | 설명 |
|---|---|---|
| Object Storage | 객체 스토리지 | 데이터를 객체로 관리하는 데이터 스토리지 아키텍처. 파일 시스템 계층 구조가 아닌 방식. 이미지, 비디오, 백업 등 비정형 데이터 저장에 적합. |
| Bucket | 스토리지 버킷 | 객체 스토리지의 최상위 컨테이너로 데이터를 구성하고 격리. 각 버킷은 독립적인 권한 제어와 설정을 가짐. |
| Object | 객체/파일 객체 | 객체 스토리지의 기본 단위로, 데이터 자체, 메타데이터(Metadata), 전역 고유 키(Key)를 포함. |
| CDN | 콘텐츠 전송 네트워크 | Content Delivery Network, 전 세계에 엣지 노드를 배포하여 웹사이트 콘텐츠를 사용자에게 가장 가까운 위치에 캐싱하여 접속 속도를 가속화. |
| Edge Node | 엣지 노드 | CDN 네트워크에서 각지에 배포된 캐시 서버로 사용자에게 직접 콘텐츠 접근 서비스를 제공. |
| Origin | 원본 서버 | CDN이 콘텐츠를 가져오는 서버로, 객체 스토리지, ECS 또는 자체 구축 서버일 수 있음. |
| Cache Hit | 캐시 적중 | 사용자가 요청한 콘텐츠가 CDN 엣지 노드에 이미 존재하여 오리진 없이 직접 반환. |
| Cache Miss | 캐시 미적중 | 엣지 노드에 요청한 콘텐츠가 없어 오리진에서 가져와야 함. |
| Hit Ratio | 적중률 | 캐시 적중 횟수가 전체 요청 횟수에서 차지하는 비율. 적중률이 높을수록 오리진이 적고 비용이 낮아짐. |
| TTL | 생존 시간/캐시 시간 | Time To Live, 콘텐츠가 CDN 노드에 캐싱되는 유효 기간. 만료 후 다시 오리진에서 가져와야 함. |
| Back to Source | 오리진(원본 가져오기) | CDN 엣지 노드가 원본 서버에 콘텐츠를 요청하는 과정. |
| Purge/Refresh | 캐시 갱신 | CDN 캐시를 강제로 무효화하고 다음 요청 시 오리진에서 최신 콘텐츠를 가져오도록 함. |
| Preheat | 예열 | 공식 발행 전에 콘텐츠를 미리 CDN 노드에 푸시하여 사용자가 첫 접속 시 캐시 적중이 되도록 함. |
| CORS | 교차 출처 리소스 공유 | Cross-Origin Resource Sharing, 브라우저의 보안 메커니즘으로 다른 도메인 간의 리소스 접근을 제어. |
| STS | 보안 토큰 서비스 | Security Token Service, 임시 접근 자격 증명을 발급하는 서비스로 프론트엔드 직접 업로드 등의 시나리오에 사용. |
| Multipart Upload | 멀티파트 업로드 | 대용량 파일을 여러 개의 작은 조각으로 분할하여 병렬로 업로드하며 재개 가능 업로드를 지원하여 업로드 효율과 안정성을 향상. |
요약: 객체 스토리지 + CDN의 황금 법칙
- 업로드는 직접 업로드: 대용량 파일은 멀티파트, 보안은 STS
- 캐시는 계층별로: 브라우저 → CDN → 원본 서버, 계층적 캐싱
- 사용자 근접 서비스: 스마트 DNS + 글로벌 노드 커버리지
- 보안은 소홀히 하지 않기: HTTPS + 핫링킹 방지 + 접근 제어
- 비용은 모니터링: 적중률, 대역폭, 스토리지 계층화, 지속적 최적화
이 아키텍처는 인터넷 대부분의 정적 리소스 접근을 지탱하며, 이를 이해하면 현대 웹 성능 최적화의 기초를 이해하는 것입니다.