서버/네트워크
CDN (Content Delivery Network)
1. 정의
CDN (Content Delivery Network)
= 콘텐츠 전송 네트워크
전 세계 여러 지역에 캐시 서버를 두고, 사용자에게 가장 가까운 서버에서 정적 파일(이미지, JS, CSS 등)을 빠르게 제공하는 시스템
2. 주요 목적
웹사이트를 빠르게 로딩시키고, 서버 부담을 줄이기 위해 사용한다.
3. 전달 대상 (정적 리소스)
- 이미지 (JPG, PNG, WebP 등)
- 동영상
- HTML / CSS / JavaScript 파일
- 폰트, PDF 등 기타 정적 파일
4. 동작 방식
[사용자] ─▶ 가까운 CDN 서버 ─▶ 캐시된 파일 제공
│
└▶ 원본 서버 (최초 요청 시)- 사용자가 요청 → 가장 가까운 CDN 서버에서 응답
- 해당 서버에 캐시가 없으면 → 원본 서버에서 가져옴
5. CDN의 장점
항목 | 설명 |
|---|---|
⚡ 웹 컨텐츠 로딩 속도 향상 | 사용자와 가까운 위치에서 응답 |
🌐 트래픽 분산 | CDN이 정적 리소스를 대신 제공 |
🧊 서버 부하 감소 | 웹 서버가 직접 모든 파일 제공 안 해도 됨 |
🛡️ 보안 강화 | DDoS 방어, HTTPS 지원, WAF 등 |
🧱 가용성 향상 | 한 지점이 망가져도 다른 서버가 응답 가능, 전 세계 사용자에게 균일한 서비스 제공 |
6. 대표적인 CDN 서비스
서비스명 | 제공 회사 |
|---|---|
Cloudflare | Cloudflare |
CloudFront | AWS |
Google Cloud CDN | |
Azure CDN | Microsoft |
Fastly, Akamai 등 | 기타 글로벌 CDN 업체들 |
7. 예시 사용 시나리오
- 블로그/웹사이트에 이미지, JS, CSS 빠르게 로딩
- 글로벌 사용자 대상 웹서비스
- 정적 파일을 S3에 저장 후 CloudFront로 제공
- 웹 앱의 초기 로딩 속도 최적화
EC2 vs S3 비교 & 아키텍처
1. EC2 vs S3 차이
항목 | EC2 (Elastic Compute Cloud) | S3 (Simple Storage Service) |
|---|---|---|
주 목적 | 가상 서버 (컴퓨팅 파워 제공) | 객체 스토리지 (파일 저장용) |
역할 | 웹서버, 앱서버, DB서버 실행 | 이미지, 백업, 정적 파일 저장 |
데이터 저장 방식 | 내부 디스크 (EBS) | 객체 단위 저장 (key-value 구조) |
접근 방식 | SSH 접속, 서버 실행 | HTTP/HTTPS 업로드/다운로드 |
운영체제 | Linux/Windows 등 설치 가능 | 운영체제 없음 |
요금 기준 | 사용 시간, 인스턴스 스펙 | 저장 용량, 요청 수, 전송량 |
예시 | 웹 앱, API 서버 구동 | 이미지, 백업, 정적 웹 호스팅 등 |
2. 차이점
- EC2 = 서버
- 내가 쓰는 컴퓨터와 유사
- 프로그램 설치 및 실행 가능
- 디스크(EBS)는 보조 저장소
- S3 = 클라우드 드라이브
- 구글 드라이브처럼 파일 저장에 최적
- 서버 없어도 이미지 업로드/공유 가능
- 대용량 정적 콘텐츠 배포에 적합
3. 둘 다 저장소 기능 포함하지만
항목 | 설명 |
|---|---|
EC2 | 주로 코드 실행 및 처리 에 사용, 저장은 부가 기능 |
S3 | 저장 자체가 주 기능, 실행 기능 없음 |
4. 비유
항목 | 비유 |
|---|---|
EC2 | 내가 직접 사용하는 컴퓨터 (앱 설치 후 실행) |
S3 | 구글 드라이브 (파일 저장 및 다운로드 전용) |
5. EC2 + S3 사용 예시
시나리오: 이미지 업로드 웹 애플리케이션
[사용자 브라우저]
↓ 요청
[EC2 웹서버]
↓ 업로드 처리 (Java, Node, Python 등)
[S3 버킷]
↑ 이미지 저장구성 요소
구성 요소 | 역할 |
|---|---|
EC2 인스턴스 | 웹서버/API 서버 실행 (예: Spring, Express 등) |
S3 버킷 | 업로드된 파일 저장소 |
IAM 역할 | EC2가 S3에 접근할 수 있는 권한 부여 |
보안 그룹 | EC2에 외부에서 접속 허용 (80/443포트) |
(선택) CloudFront | 전 세계로 빠르게 이미지 전송 (CDN 기능) |
- 블로그에서 이미지 업로드 기능
- EC2에서 백업 스크립트로 정기적으로 S3에 로그 저장
- 웹 앱의 프론트엔드 정적 파일을 S3에 배포하고 CloudFront로 캐싱
- EC2 ↔ S3 연결 시 IAM Role 사용이 권장된다. (보안)
- 또한 보안 관련하여 S3 버킷은 퍼블릭 액세스 차단이 기본이라고 한다.
- 업로드 URL을 클라이언트에 줄 경우 Presigned URL 사용
6. 정리
- EC2는 실행, 처리 중심
- S3는 저장, 보관 중심
- 둘을 함께 사용하면 서버는 가볍고, 저장은 안전하게 가능
Presigned URL이란?
1. Presigned URL이란?
S3에 저장된 파일을 제한된 시간 동안만 접근할 수 있게 해주는 임시 링크
- AWS 인증이 없는 사용자도 접근 가능하다.
- URL에 서명(signature) 과 만료 시간이 포함되는 것이 특징이다.
- 다운로드 또는 업로드 둘 다 가능하다.
2. 왜 필요한가?
S3는 기본적으로 비공개(private) 이기 때문에, 이미지나 파일을 외부 사용자에게 보여주려면 S3를 공개로 설정해야 하거나 Presigned URL을 발급해야 한다. 이 때 Presigned URL 이 더 안전하고 일시적인 방법으로 선호된다.
3. 사용 예시
시나리오 | 설명 |
|---|---|
사용자 프로필 이미지 업로드 | 프론트엔드에서 서버를 거치지 않고 S3에 직접 업로드 |
다운로드 링크 제공 | 로그인한 사용자에게만 일시적 다운로드 허용 |
전자책/PDF 같은 유료 콘텐츠 | 구매한 사람에게만 유효기간 있는 다운로드 링크 제공 |
- Presigned URL은 기본적으로 몇 분~몇 시간 단위로 설정
- 예: 1시간짜리 링크는 1시간 지나면 접근 불가
4. 예시 코드
https://my-bucket.s3.amazonaws.com/sample.pdf?
X-Amz-Algorithm=AWS4-HMAC-SHA256&
X-Amz-Credential=...&
X-Amz-Date=...&
X-Amz-Expires=3600&
X-Amz-Signature=...위는 Presigned URL이 생성된 형태이다. URL 자체에 인증 정보와 만료 시간이 포함되어 있어, 다른 사람도 이 링크만 알면 다운로드 가능하지만, 시간이 지나면 무효가 된다.