[AWS]데이터베이스 (2)

1편

https://jjongsk.tistory.com/entry/AWS%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-1

[AWS]데이터베이스 (1)

 

 

읽기 전용 복제본

데이터베이스 인스턴스가 성능을 만족시키지 못할 때, 수직적 확장과 수평적 확장 옵션을 통해 성능을 개선할 수 있다.

수직적 확장

데이터베이스 운영 중 메모리, 컴퓨터 성능, 네트워크 속도, 디스크 처리용량 등의 문제가 발생하면, 데이터베이스는 그대로 두고 인스턴스와 관련된 리소스만 추가하여 문제를 해결할 수 있다. 인스턴스의 클래스를 업그레이드하는 이 방식을 수직적 확장 또는 스케일 업(Scale Up)이라고 한다.

수평적 확장

수평적 확장 또는 스케일 아웃(Scale Out)은 읽기 전용 복제본(Read Replica)이라고 부르는 데이터베이스 인스턴스를 추가하는 방법으로 구현할 수 있다. 읽기 전용 복제본은 데이터베이스에 쿼리 작업만 가능한 또 다른 형태의 데이터베이스 인스턴스로, 마스터 데이터베이스 인스턴스의 쿼리 작업 부담을 줄여준다.

RDS는 최대 5개의 읽기 전용 복제본을 지원하며, Aurora의 경우 최대 15개까지 생성할 수 있다. 마스터 데이터는 비동기적으로 읽기 전용 복제본에 복제되므로 데이터의 차이가 발생할 수 있다. 데이터 유실이 중요한 문제라면 읽기 전용 복제본은 적합하지 않을 수 있다.

 

고가용성 구현(멀티AZ)

데이터베이스 인스턴스에 장애가 발생하더라도 서비스가 지속적으로 동작하도록 하기 위해서는 다수의 가용 영역(AZ)에 다수의 데이터베이스 인스턴스를 배포하는 것이 좋다. RDS에서는 이를 멀티 AZ(Multi-AZ) 배포라고 부른다. 멀티 AZ 배포는 하나의 AZ에 기본(primary) 데이터베이스 인스턴스를 두어 읽기 및 쓰기 작업을 담당하고, 다른 AZ에는 대기(standby) 인스턴스를 배치하는 방식으로 작동한다. Primary 인스턴스가 중단되면, 2분 내에 standby 인스턴스로 데이터베이스를 복구한다.

멀티 AZ 배포를 위해서는 모든 인스턴스가 동일한 리전에 있어야 한다. RDS는 동기적으로 primary 인스턴스에서 standby 인스턴스로 데이터를 복제하며, 이 과정에서 성능 저하가 발생할 수 있으므로 EBS 최적화 인스턴스 및 프로비전 IOPS SSD 스토리지를 사용하는 것이 권장된다.

이러한 방식으로, 데이터베이스 인스턴스의 가용성을 높이고 성능을 최적화할 수 있다.

 

Amazon Aurora에서 멀티 AZ 환경 구성

싱글 마스터

싱글 마스터 클러스터는 primary 인스턴스와 레플리카가 3개의 AZ(가용 영역)에서 동기적으로 복제되는 클러스터 볼륨을 공유한다.

• primary 인스턴스 장애 시: Aurora 레플리카가 없는 경우 자동으로 새로운 primary 인스턴스를 생성하며, 레플리카가 있는 경우에는 레플리카를 primary로 승격시킨다. 이 과정은 2분 안에 완료된다.

멀티 마스터

모든 인스턴스가 데이터베이스에 기록할 수 있으며, 하나의 인스턴스가 실패하더라도 별도의 장애 조치(failover) 작업 없이 다른 모든 인스턴스가 공유 클러스터에 데이터를 작성한다.

백업과 복원

RDS를 사용하면 데이터베이스 인스턴스의 EBS 볼륨 스냅샷을 기록할 수 있다.

• 스냅샷: 인스턴스에 있는 모든 데이터베이스와 S3에 저장된 데이터를 기록하며, 동일 리전 내 다수의 AZ에 중복 저장된다.
• I/O 중단: 멀티 AZ 기반 데이터베이스를 사용하지 않는 한 스냅샷 생성 시 몇 초간 모든 I/O 작업이 중단될 수 있다.

백업 및 복원 관련 주요 지표:

• RTO (Recovery Time Objective): 데이터 복원 및 처리 재개가 가능한 최대 허용 시간
• RPO (Recovery Point Objective): 최대 데이터 손실 허용 기간

자동 스냅샷

RDS는 자동으로 매일 30분간의 백업 윈도우 기간 동안 인스턴스 스냅샷을 생성할 수 있다.

• 성능 저하: 스냅샷 생성 시 성능이 저하되므로 피크 타임을 피하는 것이 좋다.
• 시점별 복구: 자동 백업 활성화 시 5분마다 데이터베이스 변경 로그를 기록하여 최대 5분의 데이터 손실만 발생할 수 있도록 한다.
• 보관 기간: 자동 스냅샷은 1일~35일 설정 가능하며, 기본적으로 7일 보관된다. 자동 스냅샷 기능을 끄면 보관 기간은 0일로 설정된다.

수동으로 데이터베이스 인스턴스 스냅샷을 기록할 수도 있으며, 이는 사용자가 삭제할 때까지 유지된다.

유지보수 항목

RDS는 관리형 서비스이므로 AWS가 데이터베이스 관리 작업을 처리한다. AWS는 주기적으로 인스턴스에 대한 유지보수를 수행하며, 데이터베이스 엔진 업그레이드 작업도 유지보수 기간 동안 이루어진다. 사용자는 업그레이드 여부를 선택할 수 있다.

Amazon RDS Proxy

Amazon RDS Proxy는 애플리케이션과 데이터베이스 인스턴스를 연결하는 프록시 서비스로, 애플리케이션과 데이터베이스 간의 보안 문제를 해결해준다.

• 동적 연결 관리: RDS Proxy는 데이터베이스 인스턴스와 최소한의 연결을 유지하며, 애플리케이션 측의 연결을 동적으로 확장하고 축소할 수 있다. 이는 연결 대기 시간 단축과 장시간 실행되는 쿼리에 대한 타임아웃 에러 문제를 해결해준다.
• 장애 대응: 프록시를 사용하지 않는 경우, 데이터베이스 장애 발생 시 실패한 연결을 제거하고 백업 데이터베이스 인스턴스에 새로운 연결을 요청하는 과정에서 가용성 저하 문제가 발생할 수 있다. Amazon RDS Proxy는 이 작업을 백엔드에서 자동으로 처리하여 장애 대응 기간에도 프록시 엔드포인트를 통해 연결을 유지할 수 있다.
• 보안 접속: 애플리케이션은 신뢰할 수 있는 인증 정보를 포함한 암호화된 연결 정보를 제공해야 하며, 이 정보는 LDAP, Active Directory 등 별도의 디렉토리 또는 데이터베이스 서버에 저장된다. Amazon RDS Proxy는 IAM 롤 기반 인증 체계를 사용하여 애플리케이션에서 별도의 암호화를 신경쓰지 않아도 된다. RDS Proxy는 AWS Secrets Manager에 저장된 연결 정보를 사용한다.

이러한 기능을 통해 Amazon RDS Proxy는 데이터베이스 연결의 안정성과 보안을 높이고, 애플리케이션의 성능을 최적화할 수 있다.

 

Amazon Redshift

Amazon Redshift는 복잡한 쿼리 작업을 위해 여러 개의 데이터베이스를 하나의 큰 데이터 웨어하우스로 통합한 솔루션이다. PostgreSQL 기반이지만 RDS와는 별개의 서비스이다. 데이터는 칼럼 단위로 저장하는 columnar storage 방식을 사용하여 저장 속도가 빠르고 효율적이며, 개별 칼럼에서 쿼리 작업을 수행한다. 또한, compress encodings 기법을 사용하여 스토리지에서 소요되는 칼럼의 수를 줄여주며, 사용자가 수동으로 칼럼 단위로 압축도 가능하다.

컴퓨트 노드

Redshift 클러스터는 하나 이상의 컴퓨트 노드를 가지며, 두 가지 유형이 있다.

• Dense 컴퓨트 노드: 마그네틱 또는 SSD에 데이터를 저장한다.
• 리더 노드: 컴퓨트 노드 간 커뮤니케이션을 조정한다.

 

데이터 분산 유형

데이터베이스의 행(row)은 다수의 노드에 분산 저장된다.

• EVEN: 기본 분산 방식으로, 리더 노드가 모든 노드에 데이터를 균일하게 분산한다.
• KEY: 단일 칼럼 내 값에 따라 데이터가 분산되며, 동일한 값의 칼럼은 동일한 노드에 저장된다.
• ALL: 각각의 테이블이 모든 노드에 분산 저장된다.

Redshift Spectrum

Redshift Spectrum은 S3에 저장된 파일에서 데이터를 쿼리할 수 있는 서비스이다. S3 버킷은 클러스터와 동일한 리전에 있어야 한다.

 

AWS DMS (데이터베이스 마이그레이션 서비스)

AWS DMS는 기존 데이터베이스와 스키마를 자동으로 복사하여 다른 데이터베이스에 저장할 수 있다. 서로 다른 데이터베이스 엔진 간, 관계형 및 비관계형 데이터베이스 간의 마이그레이션도 지원한다. 지원하는 엔진은 다음과 같다.

• Aurora
• DocumentDB
• DynamoDB
• IBM DB2
• MariaDB
• Microsoft Azure SQL
• MongoDB
• MySQL
• Oracle
• PostgreSQL
• Redshift
• S3
• SAP

이러한 기능을 통해 Amazon Redshift는 대규모 데이터 분석과 쿼리 작업을 효율적으로 수행할 수 있는 강력한 데이터 웨어하우스 솔루션을 제공한다.

 

NoSQL

NoSQL 데이터베이스는 초당 수만 회 이상의 트랜잭션을 일관되게 처리할 수 있도록 설계되었으며, 비구조화 데이터를 저장하는 데 최적화되어 있다. 시간에 따라 데이터베이스의 구조가 바뀔 수도 있으며, 테이블을 컬렉션이라고 부른다. 사용자는 컬렉션에 아이템을 저장하며, 이는 행(row) 또는 튜플(tuple)과 유사하다. 각 아이템은 하나 이상의 속성으로 구성되며, 이는 열(column)과 비슷하다. 속성은 유일한 이름인 키(key), 데이터 타입, 값(value)으로 구성된다.

데이터 정렬

비관계형 데이터베이스는 스키마가 없으며, 테이블 내 아이템들의 속성 또한 다를 수 있다. 각 아이템은 유니크한 기본 키 속성을 지니며, 이를 통해 아이템을 정렬할 수 있다. 따라서 기본 키 외에는 컬렉션 생성 시 속성 정의가 필요 없으며, 속성의 순서도 없고 별도의 관계성도 없다.

이로 인해 쿼리 작업을 위한 데이터 분할 및 병합 기능이 없으며, 데이터의 의도하지 않은 복제 문제가 발생할 수 있다.

데이터 조회

NoSQL 데이터베이스는 기본 키를 기준으로 하는 쿼리 작업에 최적화되어 있으며, 다른 속성에 대한 쿼리는 속도가 느려질 수 있다. 이로 인해 복잡한 쿼리나 임의의 쿼리 작업에는 적합하지 않다.

이러한 특성으로 NoSQL 데이터베이스는 구조가 유연하고 스키마가 자주 변경되는 환경에서 효과적으로 사용할 수 있다. 그러나 복잡한 관계형 데이터를 처리하는 데는 한계가 있을 수 있다.

 

비관계형 데이터베이스의 종류

비관계형 데이터베이스는 주로 키-값(Key/Value) 스토어 타입과 도큐먼트 지향(Document-oriented) 스토어 타입으로 나뉜다. 그러나 기본적으로는 모두 키-값 스토어 데이터베이스이다.

DynamoDB

DynamoDB는 비관계형 데이터베이스 서비스로, 다수의 파티션에 분산된 데이터 구조를 이용해 초당 수천 회의 읽기, 쓰기 작업을 처리한다. 파티션은 테이블을 위한 스토리지 할당 영역이며, 다수의 가용 영역(AZ)에 존재하는 SSD 장치를 사용한다.

파티션과 해시 키

테이블 생성 시 기본 키와 데이터 타입을 명시해야 하며, 두 가지 타입의 기본 키가 있다.

• 파티션 키 (해시 키): 하나의 값을 지닌 기본 키이다.
• 복합 기본 키: 파티션 키와 소트 키 또는 레인지 키라는 두 개의 키를 조합한 키이다. 파티션 키는 유일할 필요가 없지만, 파티션 키와 소트 키의 조합은 유일해야 한다.

DynamoDB는 기본 키를 사용해 파티션에 저장된 아이템을 분산하여 관리한다. 동일한 파티션에 저장된 아이템에 대해 많은 읽기, 쓰기 작업이 발생하면 이를 핫 파티션이라고 부르며, 성능 저하의 원인이 된다. 따라서 파티션 키는 세분화하여 관리하는 것이 좋다.

속성과 아이템

• 속성: 하나의 키-값 쌍을 의미하며, 하나 이상의 속성이 모인 것을 아이템이라고 부른다.
• 아이템: 최소 하나의 기본 키와 이에 상응하는 값을 지녀야 하며, 속성에는 다음 세 가지 데이터 타입 중 하나를 지정할 수 있다.
  • Scalar: 하나의 값만 지닐 수 있으며, string, number, binary, Boolean, null 타입이 있다.
    • string: UTF-8 인코딩 기반의 유니코드 데이터를 400KB까지 저장할 수 있고, 0보다 큰 수여야 한다.
    • number: 양수 및 음수를 최대 38자리까지 저장할 수 있다.
    • binary: Base-64 인코딩 포맷의 바이너리 데이터를 400KB까지 저장할 수 있다.
    • Boolean: true, false 값을 저장한다.
    • null: 미확인 값에 대해 null 타입을 부여한다. 속성 값은 비어있을 수 없고 null을 지정해야 한다.
  • Set: 무순위 스칼라 값 목록을 저장한다. 값은 Set 내에서 유일해야 하며, 최소 하나 이상의 값을 지녀야 한다.
  • Document: 스칼라, Set 데이터 타입이 아닌 또 다른 유형의 데이터를 정의하기 위한 32단계의 계층으로 문서 요소 간 중첩 관계를 정의할 수 있다.
    • List Document: 다양한 타입의 순서가 있는 데이터 모음을 저장할 수 있다.

처리 용량 옵션 선택

컬렉션 생성 시 DynamoDB는 온디맨드 모드와 프로비전 모드 중 선택할 수 있다.

• 온디맨드 모드: 자동으로 워크로드에 맞춰 확장된다.
• 프로비전 모드: 초당 읽기, 쓰기 횟수를 직접 지정할 수 있다.

DynamoDB는 테이블 생성 시 읽기 용량 유닛(RCU)과 쓰기 용량 유닛(WCU)의 수를 기준으로 파티션을 제공한다.

• 읽기 모드: 사용자는 아이템을 읽을 때 strongly consistent read (항상 최신의 데이터를 유지)와 eventually consistent read (최근의 쓰기 작업 내역이 반영되지 않을 수도 있음) 중 선택할 수 있다.

이러한 기능을 통해 DynamoDB는 유연한 데이터 구조와 높은 처리량을 제공하며, 다양한 애플리케이션 요구 사항을 충족할 수 있다.

 

Auto Scaling

처리 용량을 예측하기 어려운 경우, DynamoDB의 Auto Scaling 기능을 사용할 수 있다. Auto Scaling을 설정할 때는 활성화 비율과 함께 RCU(읽기 용량 유닛) 및 WCU(쓰기 용량 유닛)의 최대 및 최소 값을 지정해야 한다.

예약 처리 용량

100 유닛 이상의 WCU 및 RCU가 필요한 경우, 예약 처리 용량을 구매할 수 있다. 이는 비용 효율성을 높이고 예측 가능한 성능을 제공한다.

데이터 읽기

DynamoDB는 스캔과 쿼리 두 가지 읽기 방식을 제공한다.

• 스캔: 테이블 내 모든 아이템을 반환하는 방식으로, read-intensive 방식이므로 많은 읽기 유닛을 소진할 수 있다.
• 쿼리: 파티션 키 값에 따라 아이템을 반환하는 방식으로, 파티션 키와 정확하게 일치하는 아이템만 반환된다. 테이블에 소트 키가 있는 경우 이를 이용해 더 세부적인 쿼리를 할 수 있다.

보조 인덱스

특정 아이템을 쿼리할 때 정확한 파티션 키 값을 알고 있다면, 보조 인덱스를 사용하여 테이블의 기본 키 없이도 속성으로 데이터를 조회할 수 있다. 보조 인덱스가 속성 정보를 가져오는 테이블을 베이스 테이블이라고 한다.

• 전역 보조 인덱스 (GSI): 컬렉션 생성 후에 생성할 수 있으며, 파티션 키와 소트 키가 베이스 테이블과 다를 수 있다. 기본 키를 선택할 수 있지만, 인덱스의 기본 키는 다른 아이템과 구분될 수 있도록 해야 한다. 복합 기본 키를 사용할 때 파티션 키의 값이 같은 아이템은 동일한 파티션에 저장되기 때문이다.
• 지역 보조 인덱스 (LSI): 베이스 테이블과 함께 생성해야 하며, 생성 후에는 삭제할 수 없다. 파티션 키는 베이스 테이블과 동일해야 하지만 소트 키는 다를 수 있다.

전역 테이블

전역 테이블을 사용하면 다수의 리전에서 테이블을 복제하여 가용성을 높일 수 있다. 전역 테이블을 사용하려면 Auto Scaling을 활성화해야 한다. 전역 테이블은 읽기 전용 테이블의 모음이며, 각 리전당 하나의 읽기 전용 테이블만 가질 수 있다. 전역 테이블은 리전 간 강한 일관성 읽기를 지원하지 않는다.

백업

DynamoDB는 언제든 백업을 할 수 있으며, 이는 RCU를 소모하지 않고 성능에도 영향을 주지 않는다. 백업 횟수에는 제한이 없으며, 다른 리전에 있는 테이블로부터 백업을 복구할 수 있다. 테이블 복구 시 온디맨드 모드나 프로비전 모드를 선택할 수 있으며, 인덱스 및 암호화 옵션도 설정할 수 있다.

 

정리

관계형 데이터베이스와 비관계형 데이터베이스의 선택은 애플리케이션의 요구사항에 따라 달라진다.

• 관계형 데이터베이스: 데이터베이스에 특화된 SDK를 사용하는 경우 특정 데이터베이스 엔진과 상호작용해야 할 필요가 있다. AWS RDS는 가장 널리 사용되는 여섯 가지 엔진을 다양한 버전으로 제공한다.
• 비관계형 데이터베이스: 최근에 개발된 비관계형 기반 애플리케이션은 코드 변경 없이 온프레미스에서 DynamoDB로 간단히 변경하기 어렵다. 비관계형 데이터베이스를 사용해 서비스를 개발할 때는 처음부터 신중하게 고려해야 한다.

이러한 내용을 고려하여 애플리케이션의 요구사항에 가장 적합한 데이터베이스를 선택하는 것이 중요하다.