AWS SAA 강의 정리 week4
EBS, EFS, FSx, 인스턴스 스토어
EBS (Elastic Block Store)
EBS는 외장 SSD/HDD처럼 EC2 또는 RDS에 연결해서 사용하는 블록 스토리지 서비스이다.
- EBS는 EC2, RDS를 제외한 다른 AWS 서비스에는 연결해서 사용할 수 없다.
- EBS는 단일 AZ에서만 작동한다.
- 고성능 스토리지로 사용할 수 있는 유형이 존재한다.
보충: EBS는 특정 AZ(가용 영역)에 종속되기 때문에, 다른 AZ의 EC2 인스턴스에는 연결할 수 없다. 다른 AZ로 이동하려면 스냅샷(Snapshot)을 찍어 복사한 뒤 새 볼륨을 만들어야 한다.
참고 문서: AWS EBS 공식 문서
EFS (Elastic File System)
EFS는 여러 대의 컴퓨터가 동시에 같은 파일 시스템을 공유해서 쓸 수 있는 NFS(Network File System) 스토리지이다. 파일을 백업하기 위해 사용하는 Google Cloud나 iCloud를 떠올리면 편하다. 여러 사용자가 동시에 같은 파일 시스템을 공유해서 쓰는 방식이다.
- EFS는 다중 AZ에서 작동할 수 있다.
- 고성능 스토리지는 아니다.
- NFS 프로토콜만 지원한다.
- S3의 Intelligent-Tiering 기능처럼 자주 접근하지 않는 파일을 EFS IA(Infrequent Access) 스토리지 클래스로 이동시켜주는 EFS Intelligent-Tiering 기능도 존재한다.
- EFS IA 스토리지 클래스로 이동한 파일이라도 즉시 접근이 가능하다.
보충: EFS는 여러 EC2 인스턴스가 동시에 마운트해서 같은 파일을 읽고 쓸 수 있다는 점에서 EBS와 다르다. EBS는 기본적으로 하나의 EC2에만 연결 가능하지만, EFS는 수천 대의 EC2가 동시에 접근할 수 있다.
참고 문서: AWS EFS 공식 문서
인스턴스 스토어 (Instance Store)
인스턴스 스토어는 EC2 컴퓨터에 내장되어 있는 임시용 디스크이다.
- EC2 컴퓨터에 내장된 디스크이다 보니, EC2 인스턴스를 중지하거나 종료하면 데이터가 전부 사라진다.
보충: 데이터가 사라지는 휘발성 특성 때문에 영구 보관이 필요한 데이터에는 절대 사용하면 안 된다. 주로 임시 캐시, 버퍼, 스크래치 데이터 처리처럼 속도가 중요하고 잃어도 괜찮은 데이터에 활용한다. EBS보다 I/O 속도가 훨씬 빠르다.
참고 문서: AWS 인스턴스 스토어 공식 문서
FSx (File System for Extended use)
FSx는 고성능(높은 처리량, 낮은 지연 시간) 파일 스토리지 서비스이다.
- FSx for Lustre
- 머신러닝, 빅데이터 분석 시 자주 활용
- S3와 연동해서 사용 가능
- Lustre 자체 프로토콜만 지원
- FSx for NetApp ONTAP
- 다양한 운영체제(윈도우, 맥, 리눅스)에 호환
- NFS, SMB 프로토콜 둘 다 지원
- NFS : 리눅스/유닉스 시스템에서 사용하는 파일 공유 프로토콜
- SMB : Windows에서 사용하는 파일 공유 프로토콜
- FSx for Windows File Server
- SMB 프로토콜만 지원
- FSx for OpenZFS
- NFS 프로토콜만 지원
보충: 시험에서는 사용 환경에 따라 FSx 유형을 고르는 문제가 자주 나온다. 리눅스 HPC·ML 환경 → Lustre, Windows 환경 → Windows File Server, 멀티 OS 혼합 환경 → NetApp ONTAP 으로 기억해두면 편하다.
참고 문서: AWS FSx 공식 문서
DataSync, Snowball Edge, Transfer Family, Storage Gateway
DataSync
DataSync는 대용량 데이터를 전송할 때 사용하는 서비스이다.
- 온프레미스의 스토리지와 AWS 시스템 간에 데이터를 전송하는 용도로 사용할 수 있다.
- AWS 스토리지 서비스들 간에 데이터를 전송하는 용도로 사용할 수 있다.
- AWS 스토리지 서비스와 다른 클라우드 스토리지 시스템 간에 데이터를 전송하는 용도로 사용할 수 있다.
보충: 온프레미스에서 DataSync를 사용할 때는 별도의 DataSync 에이전트(Agent)를 온프레미스 서버에 설치해야 한다. 에이전트가 AWS와 통신을 중계해주는 역할을 한다.
참고 문서: AWS DataSync 공식 문서
Snowball Edge
Snowball Edge는 물리적 장비 배송으로 대용량 데이터를 전송할 때 사용하는 서비스이다.
과정은 다음과 같다.
- AWS 사이트에서 Snowball Edge를 신청한다.
- AWS에서 Snowball Edge 장비를 택배로 보내준다.
- 택배로 받은 Snowball Edge 장비를 데이터를 옮기고자 하는 컴퓨터에 직접 연결해 데이터를 옮겨 담는다. 물리적으로 직접 연결해서 데이터를 옮기기 때문에 속도가 굉장히 빠르다.
- 데이터를 다 옮겨 담았다면 Snowball Edge 장비를 다시 AWS로 보낸다.
이 과정을 외울 필요는 없다.
보충: Snowball Edge는 네트워크 전송이 느리거나 불안정한 환경, 또는 데이터 양이 너무 많아서 네트워크로는 현실적으로 옮기기 힘들 때(일반적으로 수십 TB 이상) 사용하는 대안이다. 인터넷이 없는 오지나 군사 시설 같은 환경에서도 활용된다.
참고 문서: AWS Snowball Edge 공식 문서
Transfer Family
Transfer Family는 파일을 송수신할 때 필요한 FTP(SFTP, FTPS) 서버 역할을 하는 서비스이다.
- Transfer Family를 활용하면 S3와 연동해서 파일을 송수신할 수 있다.
보충: 기존에 FTP/SFTP 방식으로 파일을 주고받는 레거시 시스템을 그대로 유지하면서 백엔드 스토리지만 S3로 바꾸고 싶을 때 사용한다. 클라이언트 측 코드 변경 없이 AWS 스토리지로 마이그레이션할 수 있다는 게 핵심 장점이다.
참고 문서: AWS Transfer Family 공식 문서
Storage Gateway
Storage Gateway는 온프레미스 환경에서 S3 스토리지를 로컬 스토리지처럼 쓸 수 있게 연결해주는 서비스이다.
- Storage Gateway는 데이터를 옮기는 것이 목적이 아닌, 연결해서 쓰는 것이 목적인 서비스이다.
- Storage Gateway는 통로(Gateway) 역할을 할 뿐, 자체적인 스토리지 기능을 가지고 있지는 않다.
- 파일 게이트웨이
- 온프레미스 데이터를 공유 폴더 형태로 연동해 S3에 저장해주는 게이트웨이
- NFS, SMB 프로토콜을 사용해서 파일 자체를 S3에 업로드하는 방식
- 파일 자체를 업로드했기 때문에 실시간으로 사용 가능
- 볼륨 게이트웨이
- 온프레미스 데이터를 블록 스토리지(디스크) 형태로 연동해 S3에 저장해주는 게이트웨이
- 파일이 아닌 블록 스토리지(EBS) 스냅샷을 S3에 업로드하는 방식
- 파일의 형태로 업로드한 게 아니라서 실시간으로 사용 불가
- 테이프 게이트웨이
- 온프레미스의 테이프(tape)에 저장된 데이터를 S3에 저장해주는 게이트웨이
- 물리 tape는 데이터를 저장하는 오래된 방식의 값싸고 장기 보관용 저장 장치이다.
- AWS의 테이프(tape)에 저장하는 것처럼 S3에 백업하는 방식
- 백업 및 아카이빙 용도로 사용
보충: DataSync는 일회성 또는 정기적인 데이터 이전이 목적이고, Storage Gateway는 온프레미스와 AWS를 상시 연결해서 함께 쓰는 하이브리드 클라우드 환경을 위한 서비스이다. 두 서비스의 목적이 다르니 헷갈리지 않도록 주의하자.
참고 문서: AWS Storage Gateway 공식 문서
RDS, 스토리지 유형, 기능
RDS란?
RDS는 관계형 데이터베이스(RDBMS) 서비스이다. 대표적인 관계형 데이터베이스로 MySQL, PostgreSQL이 있다.
보충: RDS는 데이터베이스 설치, 패치, 백업 같은 운영 작업을 AWS가 대신 처리해주는 완전 관리형 서비스이다. EC2에 MySQL을 직접 설치하는 방식보다 관리 부담이 훨씬 적다.
참고 문서: AWS RDS 공식 문서
RDS 스토리지 유형
- 범용 SSD 스토리지(gp3, gp2)
- 범용적으로 사용하는 스토리지
- 일반적으로 이 스토리지를 사용한다.
- 프로비저닝된 IOPS SSD
- 높은 처리량과 짧은 지연 시간의 스토리지
- IOPS를 직접 설정할 수 있다.
- IOPS는 Input Output Operations Per Second의 약자로, 초당 처리할 수 있는 읽기/쓰기 작업량을 의미한다.
기능
- Multi AZ 배포 (다중 AZ 배포)
- 기존 DB를 복제해서 대기 DB(Standby DB)를 생성해두고, 장애 시 자동으로 대기 DB를 주 DB(Primary DB)로 전환하는 기능이다.
- 고가용성(높은 확률로 서비스 중단 없이 잘 작동하도록 설계된 상태) 확보를 위해 사용하는 기능이다.
- 동시에 같이 작동시키는 DB가 아닌 대기 DB를 추가하는 것이기 때문에 성능 향상이 일어나진 않는다.
- Multi AZ DB Cluster (다중 AZ 클러스터 배포)
- 기존 DB를 복제해서 읽기 전용 DB를 2대 이상 더 추가해서 구성한다.
- DB가 여러 대이기 때문에 하나의 DB에 장애가 발생해도 정상적으로 작동한다. 즉, 고가용성을 확보할 수 있다.
- 읽기 전용 DB를 2대 이상 추가해서 구성하기 때문에 읽기 성능을 개선할 수 있다.
- Read Replica (읽기 전용 복제본)
- 읽기 전용 DB를 추가함으로써 읽기 성능을 향상시키고 기존 DB의 부하를 줄이기 위한 기능이다.
- Cross Region Read Replica (리전 간 읽기 전용 복제본)
- 리전 간 읽기 전용 복제본은 재해 복구(DR, Disaster Recovery, 대규모 재해가 발생했을 때 서비스를 다시 살리는 전략)를 위한 기능이다.
- RDS Proxy (프록시)
- 애플리케이션과 DB 사이에서 DB 연결(Connection)이 과도하게 많이 일어나서 발생하는 문제를 막아주는 기능이다.
- RDS Proxy가 DB 연결을 재사용하고 관리함으로써 DB 연결과 관련된 문제를 예방한다.
- RDS Blue/Green Deployment (블루/그린 배포)
- 프로덕션 환경(블루)과 동기화된 별도의 스테이징 환경(그린)을 생성한다.
- 스테이징 환경에서 DB를 변경하고 테스트한 뒤, 다운타임을 1분 미만으로 최소화하면서 트래픽을 그린으로 전환할 수 있는 기능이다.
보충: Multi AZ 배포(Standby) vs Read Replica 헷갈리지 않기: Multi AZ 배포의 대기 DB는 읽기 트래픽을 처리하지 않고 장애 대비용으로만 존재한다. Read Replica는 실제 읽기 쿼리를 처리해 성능을 높이는 목적이다. RDS Proxy는 Lambda처럼 짧은 시간에 DB 연결이 폭발적으로 늘어나는 환경에서 특히 효과적이다.
Aurora, DynamoDB, ElastiCache
Aurora
Aurora는 고성능 관계형 데이터베이스(RDBMS) 서비스이다. Aurora의 대표적인 유형으로는 Aurora MySQL, Aurora PostgreSQL이 존재한다.
- Global Database (글로벌 데이터베이스)
- 여러 리전에 걸쳐 여러 개의 DB를 구축
- 재해 복구(DR, Disaster Recovery)
- 전 세계 읽기 성능 최적화
- Auto Scaling (오토스케일링)
- CPU 사용량 같은 지표를 모니터링하다가, 미리 설정한 임계치를 넘어가면 읽기 전용 복제본을 자동으로 생성한다.
보충: Aurora는 일반 RDS에 비해 스토리지가 자동 확장되고(최대 128TB), 내부적으로 6개의 스토리지 사본을 3개 AZ에 분산 저장해 내구성이 높다. 성능과 가용성이 중요한 프로덕션 환경에서는 RDS보다 Aurora를 선택하는 경우가 많다.
참고 문서: AWS Aurora 공식 문서
DynamoDB
DynamoDB는 NoSQL 데이터베이스 서비스이다. 그러다 보니 MySQL, PostgreSQL과 같은 RDBMS(관계형 데이터베이스)는 지원하지 않는다.
- DynamoDB Streams
- 데이터 변경 사항을 실시간으로 추적 및 전달하는 기능
- DynamoDB Accelerator (DAX)
- 기존 DynamoDB보다 성능을 끌어올리고 싶을 때 사용하는 기능
- DynamoDB에 호환되면서 바로 장착할 수 있는 캐시 기능
- 읽기 성능을 향상시킬 수 있다.
보충: DynamoDB는 서버리스(Serverless)로 동작해서 용량을 미리 프로비저닝할 필요 없이 트래픽에 따라 자동으로 확장된다. 수평 확장이 필요한 대규모 서비스나 스키마가 자주 바뀌는 애플리케이션에 적합하다. 단, 복잡한 JOIN 쿼리는 지원하지 않는다.
참고 문서: AWS DynamoDB 공식 문서
ElastiCache
ElastiCache는 자주 조회되는 데이터를 빨리 조회해주는 캐시 서비스이다.
- 읽기 성능을 향상시킬 수 있다.
- ElastiCache가 일부 트래픽에 대응해줌으로써 DB 부하를 줄여줄 수 있다.
- ElastiCache는 동일한 데이터를 반복적으로 조회할 때 사용된다.
- 조회 결과가 자주 변경되는 데이터일 경우에는 적합하지 않다.
보충: ElastiCache는 Redis와 Memcached 두 가지 엔진을 지원한다. Redis는 데이터 영속성(재시작해도 데이터 유지), 복제, 정렬된 집합 등 고급 기능을 제공하고, Memcached는 단순한 캐싱에 특화된 경량 엔진이다. 시험에서 세션 관리나 리더보드처럼 복잡한 데이터 구조가 필요하면 Redis를 고르면 된다.
참고 문서: AWS ElastiCache 공식 문서