데이터는 어디에 저장해야 할까?
원문: AWS Cloud Practitioner Essentials — Module 5: Storage and Databases
출처: AWS E-Learning / Compiled by Kenneth Leung (2020)
한 줄 요약: AWS는 블록·객체·파일 스토리지와 관계형·비관계형·데이터 웨어하우스까지 다양한 저장소를 제공하며, 핵심은 “데이터의 성격에 맞는 저장소를 고르는 것”이다.
데이터가 사라진다고? — Instance Store
EC2 인스턴스를 실행하면 CPU, 메모리와 함께 스토리지도 함께 제공된다. 이때 기본으로 붙어 있는 저장소가 인스턴스 스토어(Instance Store)다.
인스턴스 스토어는 EC2가 올라가 있는 물리 호스트에 직접 연결된 디스크다. 문제는 EC2를 중지하거나 종료하면 데이터가 모두 사라진다는 것이다. EC2는 가상 머신이기 때문에, 중지 후 다시 시작하면 다른 물리 호스트에서 기동될 수 있다. 이전 호스트의 디스크는 더 이상 존재하지 않는다.
따라서 인스턴스 스토어는 임시 파일, 스크래치 데이터, 언제든 재생성할 수 있는 데이터에만 사용해야 한다.
꺼도 남아 있는 디스크 — Amazon EBS
Amazon Elastic Block Store(Amazon EBS)는 EC2에 붙여 쓸 수 있는 블록 수준 스토리지 서비스다. 인스턴스 스토어와 달리, EC2를 중지하거나 종료해도 EBS 볼륨의 데이터는 그대로 유지된다. USB 외장하드를 서버에 꽂아 쓰는 것과 비슷하되, 서버를 껐다 켜도 외장하드 안의 데이터는 사라지지 않는 셈이다.
EBS 볼륨을 만들 때 크기와 유형을 정의하고, 생성 후 EC2 인스턴스에 연결(attach)한다. 주의할 점은 EBS 볼륨과 EC2 인스턴스가 같은 가용 영역(Availability Zone, AZ)에 있어야 한다는 것이다. 그리고 용량을 다 채워도 자동으로 늘어나지 않는다.
EBS 스냅샷 — 증분 백업
EBS 스냅샷(snapshot)은 증분 백업(incremental backup) 방식이다. 첫 스냅샷은 전체 데이터를 복사하지만, 이후 스냅샷은 직전 스냅샷 이후 변경된 블록만 저장한다. 전체 백업(full backup)은 매번 모든 데이터를 복사하므로, 증분 방식이 저장 공간과 시간 면에서 훨씬 효율적이다.
파일이 아니라 객체로 저장한다 — Amazon S3
Amazon Simple Storage Service(Amazon S3)는 객체 스토리지(object storage) 서비스다. 데이터를 파일 디렉토리가 아닌 버킷(bucket)이라는 컨테이너에 객체(object) 단위로 저장한다. 각 객체는 데이터, 메타데이터, 고유 키(key)로 구성된다.
S3의 핵심 특징은 다음과 같다.
- 무제한 저장 공간 (단, 개별 객체 최대 크기는 5TB)
- 객체별 접근 권한 설정 가능
- 버전 관리(versioning)로 변경 이력 추적 가능
- 정적 웹사이트 호스팅 가능
- 11 nines(99.999999999%)의 내구성 — 최소 3개 시설에 분산 저장
S3 스토리지 클래스 — 접근 빈도와 비용의 균형
스토리지 클래스를 선택할 때 고려할 두 가지: (1) 데이터에 얼마나 자주 접근하는가, (2) 얼마나 빠르게 사용할 수 있어야 하는가.
| 스토리지 클래스 | 특징 | 적합한 상황 |
|---|---|---|
| S3 Standard | 최소 3개 AZ 저장, 높은 가용성 | 자주 접근하는 데이터 (웹사이트, 콘텐츠 배포) |
| S3 Standard-IA | Standard와 동일한 가용성, 저장 비용↓ 검색 비용↑ | 드물게 접근하지만 빠른 접근이 필요한 데이터 (백업, 재해 복구) |
| S3 One Zone-IA | 단일 AZ 저장, 비용 최저 수준 | 쉽게 재생성할 수 있는 데이터 |
| S3 Intelligent-Tiering | 30일 미접근 시 자동으로 IA로 이동, 접근 시 Standard로 복귀 | 접근 패턴을 예측하기 어려운 데이터 |
| S3 Glacier | 수 분~수 시간 내 검색, 볼트 잠금 정책(WORM) 지원 | 감사 기록, 장기 보관 데이터 |
| S3 Glacier Deep Archive | 12시간 내 검색, 최저 비용 | 거의 접근하지 않는 아카이브 |
수명 주기 정책(Lifecycle Policy)을 설정하면 S3 Standard → S3-IA → Glacier로 데이터를 자동 이동시킬 수 있다. 코드 변경 없이 비용을 최적화하는 방법이다.
EBS vs S3 — 언제 뭘 써야 하나
핵심 차이는 업데이트 방식에 있다.
| 비교 항목 | Amazon EBS | Amazon S3 |
|---|---|---|
| 저장 방식 | 블록 단위 (파일을 쪼개서 저장) | 객체 단위 (파일 전체를 하나의 객체로 저장) |
| 수정 방식 | 변경된 블록만 업데이트 | 전체 파일을 다시 업로드 (델타 업데이트 없음) |
| EC2 필요 여부 | 필요 (EC2에 연결해서 사용) | 불필요 (서버리스, 웹에서 직접 접근) |
| 적합한 작업 | DB, 영상 편집 등 빈번한 읽기/쓰기 | 이미지, 문서, 백업 등 완성된 객체 저장 |
80GB짜리 영상 파일을 편집한다면 EBS가 적합하다. 변경된 부분만 업데이트하면 되기 때문이다. 반면 수백만 장의 사진을 저장하고 웹에서 조회해야 한다면 S3가 정답이다.
여러 서버가 동시에 접근해야 한다면 — Amazon EFS
Amazon Elastic File System(Amazon EFS)은 파일 스토리지 서비스다. 블록 스토리지나 객체 스토리지와 달리, 여러 클라이언트(서버, 애플리케이션)가 파일 경로를 통해 동시에 같은 데이터에 접근할 수 있다.
| 비교 항목 | Amazon EBS | Amazon EFS |
|---|---|---|
| 범위 | 단일 AZ | 리전 전체 (여러 AZ) |
| 동시 접근 | 단일 EC2 인스턴스 | 다수 EC2 인스턴스 동시 읽기/쓰기 |
| 용량 확장 | 수동 (프로비저닝한 크기 고정) | 자동 (페타바이트까지 자동 확장/축소) |
| 온프레미스 접근 | 불가 | AWS Direct Connect로 가능 |
관계형 데이터베이스 — Amazon RDS와 Aurora
관계형 데이터베이스(relational database)는 SQL(Structured Query Language)을 사용하여 데이터를 행과 열로 구조화해서 저장한다. 커피숍의 재고 관리 시스템처럼, 각 레코드가 상품명, 크기, 가격 등의 컬럼으로 연결되어 있는 형태다.
Amazon Relational Database Service(Amazon RDS)는 이 관계형 데이터베이스를 AWS에서 관리형(managed)으로 운영할 수 있게 해주는 서비스다. 하드웨어 프로비저닝, 패치, 백업, 장애 복구를 자동화하여 운영 부담을 줄인다.
지원 엔진
Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server — 총 6가지 엔진을 지원한다.
Amazon Aurora
Amazon Aurora는 AWS가 자체 개발한 엔터프라이즈급 관계형 데이터베이스다.
- MySQL보다 최대 5배, PostgreSQL보다 최대 3배 빠름
- 3개 AZ에 걸쳐 6개 복제본 유지, S3에 지속적 백업
- 상용 DB 대비 1/10 수준의 비용
- 최대 15개의 읽기 전용 복제본(read replica) 배포 가능
고가용성이 필요한 워크로드에 적합하다.
유연한 스키마가 필요하다면 — Amazon DynamoDB
관계형 데이터베이스는 복잡한 조인이 필요할 때 강력하지만, 단순한 조회(look-up) 위주의 작업에는 오버헤드가 크다. 직원 연락처처럼 단일 테이블로 충분한 데이터에 관계형 DB의 복잡한 기능을 붙이면, 쓰지 않는 기능이 성능과 비용의 부담이 된다.
Amazon DynamoDB는 비관계형(NoSQL), 키-값(key-value) 데이터베이스 서비스다. 핵심 특징은 다음과 같다.
- 서버리스: 서버 프로비저닝, 패치, 관리가 불필요
- 한 자릿수 밀리초 응답: 수백만 사용자 규모에서도 일관된 성능
- 자동 확장: 데이터 크기에 따라 용량을 자동 조정
- 다중 AZ 자동 복제: 고가용성 내장
RDS vs DynamoDB — 선택 가이드
| 상황 | 추천 서비스 |
|---|---|
| 복잡한 조인, 다중 테이블 분석 (공급망 관리, BI 등) | Amazon RDS |
| 단일 테이블 조회, 키-값 구조 (연락처, 게임 리더보드 등) | Amazon DynamoDB |
과거를 분석한다면 — Amazon Redshift
운영 중인 데이터베이스는 “지금” 일어나는 트랜잭션을 빠르게 처리하는 데 최적화되어 있다. 그런데 “지난달 전 매장의 매출 추이”처럼 과거 데이터를 다양한 소스에서 모아 분석하려면, 운영 DB로는 한계가 있다. 데이터의 양(volume), 속도(velocity), 다양성(variety) 모두 기존 관계형 DB를 압도하기 때문이다.
Amazon Redshift는 빅데이터 분석을 위한 데이터 웨어하우징(data warehousing) 서비스다. 여러 소스의 데이터를 모아 과거 분석(historical analytics)에 특화되어 있으며, 기존 DB 대비 최대 10배 빠른 성능을 제공한다. Redshift Spectrum을 사용하면 데이터 레이크의 비정형 데이터에 직접 SQL 쿼리를 실행할 수도 있다.
데이터베이스를 옮겨야 한다면 — AWS DMS
AWS Database Migration Service(AWS DMS)는 기존 데이터베이스를 AWS로 마이그레이션하는 서비스다.
| 마이그레이션 유형 | 설명 | 예시 |
|---|---|---|
| 동종(homogeneous) | 소스와 타겟이 같은 DB 엔진 | MySQL → Amazon RDS MySQL |
| 이종(heterogeneous) | 소스와 타겟이 다른 DB 엔진 | Oracle → Amazon Aurora (AWS Schema Conversion Tool 필요) |
마이그레이션 중에도 소스 데이터베이스가 정상 운영되므로 다운타임이 최소화된다. 마이그레이션 외에도 개발/테스트 환경 구축, 데이터베이스 통합, 지속적 복제(재해 복구용)에 활용할 수 있다.
그 밖의 데이터베이스 서비스들
| 서비스 | 유형 | 적합한 상황 |
|---|---|---|
| Amazon DocumentDB | 문서 DB (MongoDB 호환) | 콘텐츠 관리, 카탈로그, 사용자 프로필 |
| Amazon Neptune | 그래프 DB | 소셜 네트워크, 추천 엔진, 사기 탐지 |
| Amazon QLDB | 불변 원장 DB | 변경 이력 전체를 추적해야 하는 시스템 |
| Amazon Managed Blockchain | 블록체인 네트워크 | 탈중앙화 원장이 필요한 다자간 거래 |
| Amazon ElastiCache | 인메모리 캐시 (Redis, Memcached) | DB 위에 캐시 계층을 추가하여 읽기 속도 향상 |
| Amazon DynamoDB Accelerator (DAX) | DynamoDB 전용 인메모리 캐시 | 밀리초 → 마이크로초 응답 시간 단축 |
마무리
데이터를 저장하는 방법은 하나가 아니다. 임시 데이터에는 인스턴스 스토어, 영구 블록 데이터에는 EBS, 완성된 파일에는 S3, 공유 파일에는 EFS. 관계형 데이터에는 RDS, 유연한 키-값 조회에는 DynamoDB, 과거 분석에는 Redshift. 중요한 것은 “어떤 서비스가 최고인가”가 아니라 “내 데이터의 성격에 맞는 저장소는 무엇인가”라는 질문이다.