AWS SAA 자격증 준비 (5) - 스토리지 및 데이터베이스 (S3, RDS, DynamoDB)

이번 글은 AWS에서 지원하고 있는 스토리지 및 데이터베이스 서비스에 대해 정리해볼 것이다.

 

AWS의 스토리지 유형

우선 AWS에서 지원하는 스토리지 유형으로는 아래와 같이 세 가지가 있다.

1) 블록 스토리지 : 데이터가 관련 없는 블록의 어레이로 구성. 하드디스크, EBS 등

2) 파일 스토리지 : 공유 파일 서버를 만들고 싶을 때 파일들을 관리하기 위한 파일 서버를 서비스로 제공. EFS

3) 객체 스토리지 : 데이터, 데이터 속성, 메타데이터를 객체로 묶어 저장. S3

블록 스토리지는 자주 변경되는 데이터에 적합한 스토리지이다. EC2 사용시 많이 사용된다. 예를 들어 앞선 글에서 나왔던 인스턴스 스토어, Amazon EBS(Elastic Block Store)가 해당된다.

 

파일 스토리지는 공유 파일 서버를 만들 때 사용되는 Aamazon EFS와 같은 서비스가 해당된다. 여러 대의 EC2에 EFS를 마운트해서 사용하게 된다.

 

마지막으로 객체 스토리지의 경우 객체 단위로 저장하기 때문에 객체 단위로만 수정이 된다. 따라서 1KB만 바꾸더라도 전체 객체가 변경되게 된다. 이에 따라 객체 스토리지는 자주 변경되지 않는 데이터에 사용하는 것이 적합하다. 동시에 많이 접근하는 경우에 객체 스토리지를 사용하면 액세스에 필요한 지연시간을 최소화할 수 있다. AWS에서는 WORM이라고 하여 Write Once Read Many한 경우에 객체 스토리지를 권장한다. 따라서 동영상, 음악, 그림 같은 데이터를 저장하기에 적합할 것이다.

 

객체 스토리지는 객체에 대해 - 데이터, 메타데이터, 키 - 3가지를 저장한다. 그리고 객체가 생성되면 URL이 함께 생성된다. 이 URL은 접근과 복제가 용이하다. 객체 스토리지의 대표적인 예는 Amazon S3이다.

 

추가로 AWS에서 지원하는 데이터 베이스에 대해서는 아래와 같이 두 분류로 대표적인 서비스를 나열할 수 있다.

i. 관계형 데이터베이스 : RDS, Redshift, Aurora

ii. 비관계형 데이터베이스 : Dynamo DB, ElastiCache

 

 

AWS S3

S3는 Simple Storage Service의 약자이다. S3는 앞서 언급되었듯 미디어 호스팅용 객체 스토리지이다.

S3는 따로 설정하지 않더라도 3개 이상의 AZ에 분산되어 있다. 이에 따라 확장성과 내구성이 좋음

 

S3는 버킷으로 구성되어 있다. 버킷은 여러 폴더를 담는 공간이며 버킷 단위로 정책을 부여(리소스 기반 정책 부여 방식)할 수 있다. 혹은 엑세스 제어 목록이나 암호화로도 가능하다. 기본적으로 버킷을 생성하게 되면 퍼블릭 엑세스 차단이 되어있는데 이를 수정하며 버킷을 퍼블릭하게 공개할 수 있다.

버킷명은 globally unique하기 때문에 버킷명으로 접근과 정책을 설정할 수 있다.

 

버킷은 버전 관리 기능도 지원한다. 원복이 가능하기 때문에 객체를 삭제하게 되면 ‘삭제 마커'가 생기면서 사용자에게는 데이터가 없는 것처럼 보이게 만든다. 이 때 원복하기 위해서는 삭제마커를 없애면 다시 데이터가 조회된다. 혹은 객체를 대체하게되면 버전별로 파일이 생기게 된다. 이 때 버전별로 동일 혹은 변경된 개체들이 모두 저장되기 때문에 비용은 버전에 따라 저장용량을 잡아먹는 것만큼 부과되니 주의해야한다.

 

S3는 객체 복제 기능을 제공하여 객체를 비동기식으로 자동으로 복사할 수 있다. 이는 리전간 복제도 가능하다.

뿐만 아니라 이벤트 알림 설정을 통해 데이터가 적재되었을 때 다른 리소스를 트리거할 수 있다. 대표적으로 Lambda를 연결하여 이벤트에 따라 이후 행동을 정할 수 있다.

 

S3는 멀티파트 업로드를 지원한다. 객체 하나가 최대 5TB까지저장이 가능한데 대용량의 경우 업로드할때 멀티파트로 쪼개어 업로드하게 된다. 업로드하는 과정에서 오류가 발생하면 잘못된 파트만 재업로드하기 때문에 처리량이 향상된다.

 

S3는 저장공간, 저장기간 외에 얼마나 엑세스를 많이 하는지에 따라서도 요금 지불하게 된다. 참고로 S3로 수신하는 것에 대해서는 요금을 지불할 필요가 없다. 송신의 경우 동일한 리전 내 EC2 혹은 CloudFront로 전송하는 것은 요금을 지불할 필요가 없다.

S3의 스토리지 클래스

총 4가지의 스토리지 클래스가 있다 :

- S3 Standard : 자주 액세스하는 활성 데이터

- S3 Standard - Infrequent Access : access를 자주 하지 않는 데이터

- S3 One Zone - Infrequent Access : 재생성 가능하고 액세스 빈도가 적은 데이터

- S3 Glacier, S3 Glacier Deep Archive : Glacier Instant Retrieval, Flexible Retrieval (몇분~몇시간), Deep Archive(12시간내)로 나뉨.

위에서 아래 순으로 자주 액세스하지 않는 경우에 사용하는 클래스로 볼 수 있다. 특히 S3 Glacier는 다른 클래스와 다르게 데이터를 아카이빙하기 때문에 실시간 엑세스가 아닌 수시간 내 엑세스가 이루어지는 대신 여러 가용영역에 걸쳐 저장하게 된다.

 

추가로 S3 Intelligent-Tiering 기능을 통해 엑세스 패턴에 따라 객체를 계층 간에 자동으로 이동하게끔 설정할 수 있다.

 

 

AWS RDS

RDS는 관계형 데이터베이스로서 데이터를 하나의 테이블만을 만드는 것이 아니라 여러 테이블로 쪼갠 뒤 이들간의 관계를 지정하는 데이터베이스이다. AWS 클라우드 환경에서 관계형 데이터베이스 운영 및 크기 조정이 필요할 경우 이 서비스를 사용하게 된다. RDS가 지원하는 데이터베이스 엔진은 MariaDB, MySQL, Oracle, PostgreSQL가 있다.

RDS는 하드웨어, OS및 데이터베이스 관리할 필요가 없다. 비관리형 서비스이긴 하지만 인프라에 대해서는 AWS가 알아서 생성해주기 때문에 DB를 설치하는 과정을 사용자가 할 필요는 없다.

 

이 외에도 RDS는 여러 가지 기능을 제공하여 장점을 보유하고 있다.

첫째로 시간이 많이 드는 관리 작업을 자동화할 수 있다. 이 때 엔진, 컴퓨팅, 용량, 패치, 백업, 고가용성이 고려되어 각 영역별 설정만 하게 되면 사용자의 개입 없이 생성부터 완료까지 알아서 진행하게 된다.

 

둘째로는 데이터를 안전하게 저장 및 전송하는 기능을 한다. 네트워크 보안으로 일반적인 방법인 private subnet에 Amazon RDS 생성할 수도 있고 혹은 RDS 접근 가능한 사람들을 IAM으로 설정하여 접근을 제어할 수 있다.

 

그리고 데이터 백업 기능을 제공한다. 스냅샷을 적재하는 주기를 자동(기본, 7일 ~ 최대 35일까지 설정 가능)으로 설정하거나 수동으로 스냅샷을 남겨 백업을 할 수 있게끔 한다.

 

더 나아가 RDS는 데이터베이스 이중화라고 하여 multi-AZ, 즉 하나 이상의 가용영역에 대기 RDS를 생성해둘 수 있다. 운영중이던 DB가 다운되면 자동으로 대기 RDS에 접근하게 되고, 네트워크 설정 등도 기존의 RDS와 동일하게 되어 있어 DB가 다운되더라도 체감하는 정도가 적다.

 

AWS Aurora

추가로 RDS에서 데이터베이스 엔진으로 Aurora를 선택할 수 있는데 이 Aurora 서비스는 AWS에서 직접 개발한 DB엔진으로 최근 각광받고 있다. MySQL및 PostgreSQL 호환 관계형 데이터베이스이며 특히나 이 엔진은 클라우드 native한 엔진으로 소개하고 있다. 클라우드 native하다는 것에 대해 좀 더 부연설명을 붙이면, 인스턴스와 스토리지를 분리하여 관리한다. 즉 Aurora의 기본 인스턴스 외에 다른 가용영역에 복제본을 두고 각 가용영역에는 복제본에 대한 DB복제본을 보유하게 된다. 이 때 데이터가 인입되면 여러 가용영역에 걸쳐있는 DB복제본을 분산 저장하여 내구성과 확장성을 지닌다.

AWS DynamoDB

RDS가 관계형 데이터베이스였다면 DynamoDB는 완전관리형 키-값(NoSQL) 데이터베이스이다. 완전관리형이라는 의미는 사용자가 정해야할 것이 극소수라는 의미로 실제 AWS콘솔에서 DynamoDB를 생성해보면 partition Key, sort Key, DynamoDB 테이블명만 지정해주면 DB가 생성된다. 뿐만 아니라 Dynamo DB는 서버리스 솔루션이기에 더욱 사용자가 정의해야할 부분이 많지 않다.

키-값 데이터라는 것은 스키마가 따로 정해져있지 않다는 의미이기도 하다. 파티션 키가 데이터 분산을 결정하며

정렬 키가 다양한 쿼리 기능을 지원하게 된다. 파티션과 정렬키는 각각 한개만 지정할 수 있다. 흔히 회원정보 테이블이라고 하면 파티션 키는 ID, 정렬 키는 가입일자로 정하게 된다.

 

Dynamo DB는 ‘용량’을 지정해주어야 하는데 용량이라고 쓰지만 실상은 성능 (쓰기/읽기 성능)을 설정해야한다.

- 읽기 : RCU (Read Capacity Unit)

- 쓰기 : WCU (Write Capacity Unit)

위와 같이 RCU, WCU 단위를 설정하여 성능을 지정하게 된다.

 

뿐만 아니라 스케일링 방법으로 세 가지를 지원하는데,

- 프로비저닝 : 최대 사용량을 걸어두어 그 한계를 넘으면 작동X

- 오토스케일링 : 상한, 하한 지정

- 온디맨드 : 제한없이 사용한만큼 사용

세 가지 중에서 선택할 수 있다.

 

AWS Redshift

Redshift는 분석용 DB이다. OLAP을 지원하여 데이터의 대규모 병렬처리가 가능하다. 가장 큰 특징은 Column 기반 스토리지라는 것이다. Column 기반 스토리지는 우리가 보통 관계형 데이터베이스를 생각할 때 떠오르는 row 기반 스토리지가 아니다. Row기반 스토리지는 트랜잭션 처리 방식이어서 매우 빠른 데이터 쓰기가 가능하지만 column 기반 스토리지는 고도의 분석적 쿼리 모델에 적합하여 데이터 집계에 유리하다.

 

AWS 캐싱 서비스

캐싱을 사용하는 아키텍처는 더 빠른 스토리지를 사용하여 읽기 성능을 개선할 수 있다.

AWS에서 가장 대표적인 캐싱 서비스는 ElastiCache로 본래 가장 유명한 캐시 엔진인 Memcached, Redis 두 가지 엔진을 지원한다.

캐싱전략은 아래와 같이 두 가지가 있는데

- 라이트스루(Write-Through) : DB에 write 요청이 올때마다 cache도 write함

- 지연로딩 : 애플리케이션에서 read요청이 오는 데이터만 cache에 저장

각각 장단점이 있다.

 

지연 로딩의 경우 애플리케이션에서 cache서버에 우선적으로 요청하고 캐싱된 데이터가 없다면 DB로 요청하게 된다. 이 때 DB로 요청된 데이터를 cache에 write하게 된다. 장점으로는 필요한 data만, 즉 요청이 있는 데이터만 저장할 수 있다. 단점으로는 cache에 있는 데이터가 DB에는 업데이트가 되어도 캐시에 먼저 요청하여 접근하기 때문에 수정이 되지 않는다. 이 때문에 cache miss penalty가 발생하여 cache를 사용하는 본질이 흐려질 수 있다.

 

캐시에서 항목 제거하기 위해 TTL (Time to Live)이라는 용어가 등장한다. cache에 유효기간을 지정하여 일정 유효기간이 초과하게 되면 캐싱된 데이터를 삭제하게 되는 것이다.

 

추가로 Dynamo DB Accelerator라고 하여 Dynamo DB를 위한 캐시 서비스가 있다. 이는 milli second 단위가 아니라 micro second 단위의 데이터 접근이 필요한 경우 사용하면 유용한 서비스이다. 예를 들어 게임과 같이 실시간으로 지속적인 데이터 접근이 필요할때는 Dynamo DB Accelerator를 사용하면 유용할 것이다.

 

AWS 데이터 마이그레이션 지원 방식

오프라인 전송방식은 아래와 같이 세 가지가 있다.

1. snowcone

2. snowball edge

3. snowmobile

위 세가지 모두 기운영중인 데이터 센터에 연결하는 물리적인 장비를 제공하여 데이터 마이그레이션을 지원한다.

 

온라인 전송방식으로는 Data Sync 서비스가 있다. Data Sync 에이전트를 기운영중인 데이터 센터에 설치하여 WAN을 통해 AWS로 데이터를 전송하게 된다.

 

이 외에 Storage Gateway 서비스가 있는데, 온프레미스에서 사용하는 파일 프로토콜이 다양할 경우 사용하여 다양한 프로토콜로 데이터를 전송할 수 있게끔 해준다.

 

뿐만 아니라 이종 데이터베이스 마이그레이션 지원하기 때문에 현재 운영중인 온프레미스 데이터베이스가 다른 데이터 엔진을 기반으로 두고 있다고 하더라도 AWS의 데이터베이스로의 이관이 가능하다. 여기에 더 나아가 AWS Schema Conversion Tool도 제공된다.

 

 

---

첨부된 이미지는 모두 AWS 공식 Docs 자료입니다.