#개발 #기술블로그 #동아리 #ACC #AWS #S3 #EBS #EFS #Storage #인프라 #infra #백엔드 #EBS #EFS #S3 ![](https://img1.daumcdn.net/thumb/R800x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdna%2FIeOQf%2FbtrQf45xEdp%2FAAAAAAAAAAAAAAAAAAAAANnMY6AQSfU0V4tu_QDLNuA-c5VJLpV29kKRBLrAMqOK%2Fimg.png%3Fcredential%3DyqXZFxpELC7KVnFOS48ylbz2pIh7yKj8%26expires%3D1777561199%26allow_ip%3D%26allow_referer%3D%26signature%3DQlYgW8HoaxN5aBr7qfjhIwqg%252F%252FE%253D) 이번주 ACC EWHA 세션에서는 Storage에 대해서 다루고, 그 중에서도 S3와 CloudFront 위주의 학습을 진행했다. 아티클을 작성하면서 EBS와 EFS에 대해서도 간단히 다루었는데, S3는 많이 다뤄보아서 그냥 오~알지 하고 넘어갔지만;; 나머지는 제대로 보는 건 처음이었다. 백엔드 개발자로서 '어떤 상황에 어떤 스토리지를 택해야 하는지'는 감이 잘 잡히지 않아서 이번 스터디 주제로는 **스토리지 선택 전략**에 대해 다루게 되었다. 우선 스토리지 3개를 하이레벨에서 비교하고 $\to$ EBS, EFS에 대해 조금 더 공부해보고 (S3에 대한 내용은 [[클라우드 스토리지부터 CDN까지 — S3와 CloudFront 구조 한 번에 정리하기]]를 참고하자) $\to$ 어떤 상황에서 어떤 걸 골라야 하는지 정리해보려고 한다!! --- # 1. 스토리지 3종 비교 ## Block / File / Object 비교 | 구분 | Block Storage (EBS) | File Storage (EFS) | Object Storage (S3) | | --------- | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | **정의** | 데이터를 동일 크기 블록으로 나눠 저장, 각 블록에 고유 식별자(ID) 부여 | 공유 파일 시스템으로 여러 시스템에 접근 제공, 계층적 디렉토리 구조 | 비정형 데이터를 객체 단위로 저장, 가용성보다 저장 용량에 우선순위 | | **특징** | 메타데이터를 최소화해서 오버헤드가 가장 적음 → 빠른 전송 | 파일에 붙은 메타데이터를 직접 읽고 수정 가능, ACL 기반 권한 제어 | 대용량 비정형 데이터 저장에 최적, 단 Block보다 지연 시간(latency)이 김 | | **접근 방식** | 단일 EC2 인스턴스가 DAS(Direct-Attached Storage)처럼 직접 마운트<br><br>즉, 1:1 연결 | NFSv4 프로토콜로 수천 개의 클라이언트가 동시 접근 가능<br><br>즉, 여러 서버 동시 접근 | HTTP 기반 REST API<br><br>즉, API 기반 접근 | | **출처** | [AWS Compare — Block vs File vs Object](https://aws.amazon.com/compare/the-difference-between-block-file-object-storage/) | [AWS EFS FAQ](https://aws.amazon.com/efs/faq/) | [AWS Compare — Block vs File vs Object](https://aws.amazon.com/compare/the-difference-between-block-file-object-storage/) | ## S3 / EBS / EFS 비교 | 스토리지 | 설명 | 핵심 특성 | | --------------- | ----------------------------------------- | ------------------------------- | | **Object (S3)** | 업계 최고 수준의 확장성, 가용성, 성능을 제공하는 객체 스토리지 | 99.999999999% (11 9's) 내구성으로 설계 | | **Block (EBS)** | EC2 인스턴스가 접근 가능한 영구 스토리지가 필요한 워크로드 대상 | DAS / SAN과 유사한 일관된 저 지연 블록 스토리지 | | **File (EFS)** | 대용량 콘텐츠 리포지토리, 개발 환경, 미디어 스토어, 사용자 홈 디렉토리 | 공유 파일 시스템 | [AWS Well-Architected — Storage](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf-storage.html) 참고 --- # 2. Amazon EBS (Elastic Block Storage) ![](https://img.youtube.com/vi/b6vaNi1SD7Y/maxresdefault.jpg) [[Amazon EBS]] 에 간단한 내용을 정리해두었다. ## EBS 기본 특성 - `정의` EC2 인스턴스에 연결하는 **영구(durable) 블록 레벨 스토리지 디바이스** - `특징` - EC2 인스턴스 수명과 **독립적으로** 유지됨 - 하나의 인스턴스에 **여러 볼륨 연결 가능** - 볼륨과 인스턴스는 **동일 가용 영역(AZ)** 에 있어야 함 *([[VPC와 Route53로 이해하는 AWS 네트워크 구조]] 참고)* - `Elastic Volumes` 무중단으로 **크기·[[IOPS]]·타입** 동적 변경 가능 - 데이터는 **동일 AZ 내 여러 서버에 복제**되어 내구성 확보 - *출처*: [AWS EBS — Volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volumes.html) / [AWS EBS Features](https://aws.amazon.com/ebs/features/) ## EBS 볼륨 타입 EBS 볼륨은 크게 **SSD 계열 / HDD 계열**로 나뉜다. - **SSD**: "자주 랜덤하게 읽고 쓰는" 워크로드 → 지배 지표는 **IOPS** (초당 I/O 횟수) - **HDD**: "한 번에 쭉 읽고 쓰는" 워크로드 → 지배 지표는 **throughput** (초당 MB) > 왜 이렇게 나뉘냐면, DB처럼 작은 데이터를 빠르게 여러 번 읽는 작업과, 로그처럼 큰 데이터를 순차로 읽는 작업은 요구하는 하드웨어 특성이 완전히 다르기 때문. ### SSD 계열 - 자주 랜덤하게 읽고 쓰는 워크로드 #### `gp3` — 범용 SSD (대부분의 경우 이거 사용!) 웹 서버, 중소규모 DB, 개발 환경 등 **"특별히 튀는 요구사항 없는 일반적인 워크로드"** 용. AWS가 공식적으로 권장하는 기본 볼륨. - `핵심 아이디어` **용량과 성능을 분리**해서 프로비저닝 가능 - gp2 시절엔 "용량 = 성능"이었음 (100 GiB → 300 IOPS 고정) - gp3는 크기 상관없이 기본 3,000 IOPS + 125 MiB/s 상시 제공 - 더 필요하면? 용량 안 늘리고 IOPS만 추가 구매 가능 (최대 16,000 IOPS) - `비유` 인터넷 요금제에서 "데이터 용량"과 "속도"를 따로 고르는 느낌 - `성능 한계` 볼륨당 최대 80,000 IOPS / 2,000 MB/s - `지연 시간` single-digit millisecond (1~9 ms) - `내구성` 99.8% ~ 99.9% (연간 장애율 0.2% 이하) - *출처*: [AWS EBS — General Purpose SSD](https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html) #### `io2 Block Express` — Provisioned IOPS SSD (돈 써서라도 성능 보장 받아야 할 때 사용) **Mission Critical (장애 나면 큰일나는;) DB용.** gp3로는 부족하거나, 성능이 "99.9% 시간 동안 일정하게 보장"되어야 할 때. - `핵심 아이디어` **Provisioned** = 사용자가 원하는 IOPS를 **직접 예약**하고, AWS가 그 수치를 보장 - gp3: "3,000은 기본이고 필요하면 더 살 수 있음" (유연함) - io2 Block Express: "나 100,000 IOPS 필요함 → 그만큼 확보하고 요금 지불" (예약제) - `성능 한계` 볼륨당 최대 **256,000 IOPS / 4,000 MiB/s** (gp3의 3배 이상) - `지연 시간` **500 마이크로초 미만** (gp3의 ms 단위보다 10배 빠름) - `내구성` **99.999%** → gp3 대비 **100배 높음** - 금융/의료처럼 데이터 유실이 치명적인 워크로드가 타겟 - `권장 용도` SAP HANA, MSSQL, Oracle DB, IBM DB2 — **엔터프라이즈급 RDBMS** - *출처*: [AWS EBS Volume Types](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) ### HDD 계열 — 순차 읽기 워크로드 SSD보다 훨씬 싸다. 대신 **랜덤 접근은 느리고, 순차 접근은 빠른** HDD 특성을 그대로 활용. - `st1` — **Throughput Optimized HDD** - "크고 순차적인 데이터를 쭉 밀어넣고 쭉 읽는" 워크로드 - `권장 용도` Kafka 로그, MapReduce, 데이터 웨어하우스, ETL 파이프라인 - 최대 **500 MB/s per volume** - *왜 HDD인데 빠르냐?* → 순차 I/O만 생각하면 HDD도 스루풋이 충분히 나옴. 대신 랜덤 접근은 포기. - `sc1` — **Cold HDD** - **자주 안 보는 데이터**의 최저 비용 저장소 - 백업, 아카이브성 로그 등 - *출처*: [AWS EBS Volume Types](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) ## EBS 볼륨 선택 기준 | 상황 | 선택 | | --------------------------------------------------- | --------------------- | | 웹 서버 / 일반 앱 서버의 루트 볼륨, 중소형 DB | **gp3** | | 금융·결제·ERP 같은 미션 크리티컬 DB, 성능 보장 필수 | **io2 Block Express** | | Kafka / 로그 수집 / 빅데이터 ETL (순차 I/O, 대용량) | **st1** | | 거의 안 읽지만 일단 보관은 해야 하는 데이터 | **sc1** | → 잘 모르겠으면 **gp3부터 시작**. 성능 부족 느껴지면 io2 Block Express로 **무중단 전환** 가능 (Elastic Volumes 기능). --- # 3. Amazon EFS (Elastic File System) ![](https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2022/12/17/Amazon_EFS_video_thumbnail.jpeg) [Amazon EFS의 처리량 및 성능 모드에 대한 이해와 올바른 선택](https://aws.amazon.com/ko/blogs/tech/how-to-select-the-right-throughput-and-performance-mode-of-amazon-efs/) 참고 ## EFS 기본 특성 - `정의` EC2, 컨테이너, Lambda, 온프레미스 서버가 공유하는 **서버리스 파일 스토리지** - `특징` - [[NFSv4]] 프로토콜, **Strong Consistency + 파일 잠금(file locking)** 지원 - **GB → PB 자동 확장**, 용량 프로비저닝(예약) 불필요 - 수천 개의 컴퓨트 인스턴스가 동시에 접근 가능 - *출처*: [AWS EFS FAQ](https://aws.amazon.com/efs/faq/) ## Performance Mode (성능 모드) > **생성 후 변경 불가** - `General Purpose` **(모든 파일 시스템에 권장)** - 대부분의 워크로드에 적합 - 파일 작업 당 **낮은 지연 시간** - `모니터링` `PercentIOLimit` CloudWatch 지표로 IOPS 한도 모니터링 - `Max I/O` *(이전 세대)* - 고도로 병렬화된 워크로드 중 **높은 지연을 감내할 수 있는 경우** - 초당 작업 수(operations/sec)에 내재적 한도 없음 - **One Zone, Elastic Throughput에서는 지원 X** - 공식 문서: "Max I/O의 **per-operation 지연이 더 높으므로**, 모든 파일 시스템에 **General Purpose를 권장**" - *출처*: [AWS EFS — Performance Specifications](https://docs.aws.amazon.com/ko_kr/efs/latest/ug/performance.html) ## Throughput Mode (처리량 모드) > 운영 중 변경 가능 (단, Provisioned 전환/증가 시 **24시간 대기** 필요) - `Elastic 탄력적` **(기본값, 대부분의 워크로드 권장)** - **탄력적 모드는 워크로드를 처리하기 위해 자동으로 성능을 확장하고 축소하기 때문에, 성능 사용 패턴을 명확하게 정의할 수 없는 워크로드를 위한 좋은 선택.** - **워크로드에 맞춰 자동 스케일**, 별도 프로비저닝 불필요 - `과금` 실제 read/write한 데이터 양에 대해서만 지불 - `사용 케이스` 피크 처리량이 불확실 or 매우 **스파이키**한 워크로드 (평균 사용률이 피크의 5% 이하) - `최대 IOPS` 자주 접근하는 데이터 기준 **read 250,000 / write 50,000** - `Provisioned 프로비전드` - **사용자가 필요한 처리량 성능을 직접 설정하는 모드로, 워크로드의 데이터 사용 용량과는 무관하게 지속적인 처리량 성능이 필요할 경우에 사용할 수 있음.** - **일정한 스루풋**이 필요한 애플리케이션용 - **Read throughput은 write의 3배**로 제공 (EFS는 read 요청을 1/3로 미터링) - `Bursting 버스팅` *(이전 기본값)* - 비용은 파일 시스템의 사용 용량에만 과금이 되며, 별도의 성능 비용은 과금되지 않음. - 따라서, 파일 시스템의 사용 용량이 증가할 수록 높은 성능이 필요한 워크로드의 경우에, 가장 비용과 성능에 대한 균형을 맞출 수 있는 처리량 모드입니다. - **스토리지 크기에 비례**해 스루풋 제공 - **버스트**: 모든 파일 시스템이 100 MB/s까지 가능, 1TB 이상이면 TB당 100 MB/s까지 가능 ## 주요 Storage Classes - `EFS Standard` **SSD 기반**, 자주 액세스하는 파일에 적합하며, 여러 AZ에 데이터를 저장하여 높은 가용성과 내구성을 제공 - `EFS IA (Infrequent Access)` 자주 접근 X → 접근 빈도가 낮은 데이터를 저렴한 비용으로 저장합니다. 저장 비용은 낮지만 데이터 접근 시 비용이 발생 - `EFS Archive` 분기/연 단위 접근 → 매우 오래되거나 접근하지 않는 데이터를 위한 가장 저렴한 계층으로, IA 등에서 마이그레이션하여 사용. - *출처*: [AWS EFS — Performance Specifications](https://docs.aws.amazon.com/efs/latest/ug/performance.html) --- ## 4. 백엔드 관점에서, 어떤 스토리지를 언제 써야 할까? ### `EFS를 선택해야 할 때` — 여러 서버가 같은 파일을 공유해야 함 [실사용 예시](https://velog.io/@kjw4840/aws-EFS-구축) - **공유 파일 접근이 필요한 애플리케이션** - *예: Spring Boot 앱을 ECS/EKS로 오토스케일링 중인데, 사용자가 업로드한 프로필 이미지를 여러 인스턴스가 공통으로 읽어야 할 때* - **수천 개 클라이언트에 높은 집약 처리량 제공** - *예: 머신러닝 학습 시 수백 개 GPU 인스턴스가 같은 데이터셋을 병렬로 읽는 경우* - **레거시 애플리케이션을 코드 수정 없이 클라우드로 이전** - **주의** 분산 아키텍처라서 가용성·내구성·확장성은 ↑지만, 각 I/O마다 **네트워크 오버헤드**가 있음 - → **작은 파일을 엄청 자주** 읽는 워크로드엔 불리 - → **큰 파일 하나를 쭉** 읽는 워크로드엔 오버헤드가 분산돼서 유리 ### `EBS를 선택해야 할 때` — 단일 서버가 빠르게 읽고 써야 함 (이미 EC2가 사용하고 있다...) - **단일 호스트 전용 블록 스토리지** - *예: EC2 한 대에 MySQL/PostgreSQL 직접 설치하고 운영 (RDS 안 쓰는 경우)* - 이런 경우는 거의 없긴 할 것임... - *예: Redis를 EC2에 직접 올려서 AOF 파일 저장* - *참고: RDS도 내부적으로 EBS를 씀 → 즉, DB 성능 = EBS 성능* - **가장 낮은 지연이 필요한 워크로드** - *예: JPA `saveAll()`로 수만 건 배치 insert → 매 트랜잭션마다 디스크 fsync 발생 → IOPS가 병목* - *예: 트랜잭션당 1ms가 중요한 결제 서버* - **EC2의 로컬 디스크처럼 대용량 저장이 필요한 경우** - *예: EC2 루트 볼륨 — OS, JDK, Spring Boot jar, 로그 파일이 다 여기 저장됨* - *예: Elasticsearch/OpenSearch를 EC2에 직접 올려서 인덱스 데이터 수백 GB 저장* - *예: Docker 이미지 캐시, 빌드 산출물, 임시 파일(`/tmp`) 등 로컬 파일시스템이 필요한 모든 것* - *예: 대용량 로그를 로컬에 쌓아두고 주기적으로 S3로 아카이브하는 구조* - **왜 EFS를 쓰지 않을까?** - DB 데이터 파일은 **랜덤 I/O + 파일 잠금 성능**이 생명인데, EFS의 네트워크 오버헤드(수 ms)가 DB 트랜잭션 지연을 만듦 - 공식 문서에서도 EBS(특히 io2)를 DB용으로 권장 ### `S3를 선택해야 할 때` — 파일 시스템이 아예 필요 없음 - **객체 스토리지로 충분한 경우** - *예: 사용자 프로필 이미지 → `PUT /images/user123.jpg` - *예: 일 단위 백업 파일, 엑셀 리포트, PDF 영수증* - *예: 데이터 분석용 로그 (S3 → Athena로 쿼리)* - **Spring에서의 전형적 패턴** - 컨트롤러에서 `MultipartFile` 받아서 → `s3Client.putObject()` → DB엔 S3 URL만 저장 - **Presigned URL** 활용 시: 서버 안 거치고 클라이언트가 **S3에 직접 업로드** → 서버 부하 ↓, 네트워크 비용 ↓ - **"확장, 내구성, 저비용"** - 11 9's 내구성, 사실상 무한 확장, GB당 월 $0.023 (Standard 기준) - EBS($0.08/GB) / EFS($0.30/GB)와 비교하면 압도적으로 저렴 - **쓰면 안 되는 경우!** - 파일을 **수정**해야 할 때 (S3는 객체 단위 덮어쓰기만 가능, 부분 수정 불가) - **낮은 지연**이 필요할 때 (S3는 첫 바이트까지 수십 ms 걸림) - *그래서 DB 데이터 파일, 세션 저장소 같은 건 절대 S3에 두지 않음* --- ### 한 줄로 기억하기 | 질문 | 선택 | | -------------------------------------- | ------- | | 여러 EC2가 같은 파일을 **공유**해야 함 | **EFS** | | EC2 한 대가 **빠르게** 읽고 써야 함 (특히 DB) | **EBS** | | 파일 업로드/다운로드만 되면 됨, **API 기반**으로 쓸 수 있음 | **S3** | → 실무에서 가장 흔한 Spring 백엔드 구성: - **RDS (내부적으로 EBS)** → 트랜잭션 DB - **S3** → 사용자 업로드 파일, 정적 리소스, 백업 - **EFS** → 필요할 때만 (공유 업로드 디렉토리, 공유 설정 파일 등) --- 사실 어떤 유즈케이스들이 있을까 하고 공부를 시작한 건데, 공부하다 보니 결국 내부적으로 이미 쓰고 있는 EC2나 RDS와 연관이 많다는 걸 알게 되었다.... 그나마 좀 나중에 새로 써볼 수 있겠다 싶은 건 EFS일 것 같다 (오토스케일링 sticky session 회피해 stateless로 유지하려고 할 때라든가?...) 그럼 끝... ![](https://media.tenor.com/47uNbDssyFUAAAAM/nerd-cat-actually.gif)