6. AWS 의 데이터 베이스 서비스

시스템 구성 요소로서 데이터 베이스는 없어서는 안되는 존재이다. 1998년 이후 데이터 베이스에도 복수의 아키텍처나 데이터 모델이 등장하고 있으며, 시스템의 구성에 응하는 최적의 데이터 베이스를 선택하는 것도 아키텍처의 중요한 포인트가 되었다. AWS 에는 데이터베이스 관련하여 8가지의 서비스를 제공하고 있다. 솔루션 아키첵처로서 각각 서비스의 특징을 이해하고 최적의 서비스를 선택하는 능력을 기를 필요가 있다.

데이터 베이스의 분류

• Amazon RDS
• Amazon Redshift
• Amazon DynamoDB
• Amazon Elasticache
• Amazon Neptune
• Amazon QLDB
• Amazon DocumentDB
• Amazon Keyspaces
• Amazon Timestrem

아키텍처의 분류 방법에는 수많은 방법이 있지만, 이 섹션에는 크게 RDB와 NoSQL이라고 불리는 2가지 큰 아키텍처로 분류하여 설명해 볼까 한다. 각 데이터 베이스의 아키텍처의 상세한 포인트나 차이점에 대해서는 따로 공부해 두는 것을 권한다.

RDS ( Relation Database )

해석하자면 관계형 데이터 베이스 라고 한다. 데이터를 표 (테이블) 형식으로 표시하며, 각 표의 관계를 정의, 연결하는 것으로 데이터를 관리하는 데이터 베이스이다. RDB의 각종 조작에는 SQL ( Structed Query Language : 구조화 된 호출 언어 ) 를 사용한다. 인간이 이해가기 쉽도록 만들어진 인간 친화적 데이터 관리 방법이다. 데이터 베이스의 주요한 아키텍처로서 많은 시스템에서 사용되고 있다. AWS의 데이터베이스 서비스중에는 RDS와 Redshift가 RDB 서비스이다.

RDB의 주요 소프트웨어에는 Oracle, MySQL, Microsoft SQL Server, PostresSQL등을 언급할 수 있다.

NoSQL ( Not Only SQL )

RDB의 데이터 조작에서 사용하는 SQL을 사용하지 않는 데이터베이스 아키텍처로 구성되며, NoSQL이라고 하는 언어가 등장했다. NoSQL의 중에도 수많은 데이터 모델이 존재한다. RDB와 비교할때 NoSQL의 특징으로는 [모순적인 스키마리스 데이터 모델], [수평 스케일리비티], [분류 아키텍처], [고속의 처리] 를 들 수 있다. RDB를 넘어서는 퍼포먼스와 데이터 모델의 문제를 처리하는 을 목적으로 만들어진 새로운 아키텍처이다. AWS의 데이터 베이스 서비스 중에는 DynamoDB, Elasticache, Neptune, DocumentDB, Keyspaces이 NoSQL 서비스이다. 

NoSQL의 주요 소프트 웨어로는 아래를 언급할 수 있다.

• Redis, Memcached (Key-Value 스토어)
• Cassandra, HBase ( 컬럼 지향 데이터베이스 )
• MongoDB, CouchDB(도큐먼트 지향 데이터베이스)
• Node4j, Titan (그래프 지향 데이터베이스)

RDS와 NoSQL의 장단점을 잘 이해할 것,

지금 까지의 시스템은 데이터베이스라고 말한다면 시스템 언어의 안에서 RDB 하나만 존재하며, 저장할 필요가 있는 데이터는 모두 그 안에 저장하는 구성은 이젠 많이 낡은 구성이 되었다. 새롭게 등장한 NoSQL은 RDS를 상회할 정도는 아니지만, 시스템에서 어느 한쪽만 사용하는것이 아니라. 애플리케이션의 상황과, 프로젝트의 유스크에시으 대응하여 복수의 데이터베이스를 도입하여 사용하는것을 생각해 두는 것이 좋다.

RDS

AWS 가 제공하는 매니지드 RDS 서비스이다. MySQL, MariaDB, PostgresSQL, Oracle, MicrosoftSQL Server 등의 온프레미스에서도 사용해 왔던 데이터베이스 엔진들 중 자유롭게 선택할 수 있다. 여기 더하여 2014년에는 Amazon Aurora라고 하는 AWS가 독자적으로 개발한 클라우드환경을 최대한 활용할 수 있는 새로운 아키텍처의 RDS도 제공하고 있다. 백업이나 하드웨어 메인테넌스등의 운용작업, 장애시의 복구 작업은 모두 AWS가 제공하는 매지니드 서비스를 사용하는 것으로 복잡해지기 쉬운 데이터베이스의 운용을 심플하게 낮은 코스트로 실현해 준다. 운용의 효율화는 RDS를 사용하는 최대의 메리트중 하나라고 할 수 있다.

RDS에는 복수의 데이터베이스 엔진을 이용가능하지만, 각각의 엔진에서 제공하는 기능중 RDS에는 사용할 수 없는 기능도 더러 있기 마련이다. RDS를 이용하는 경우에는 어떤 기능이 제한되어 있는지 도큐먼트를 확인해두는 것이 중요하다. 애플리케이션의 사양으로 인해 RDS에서는 사용할 수 없는 기능이 필요할 경우에는 EC2의 인스턴스에 데이터베이스 소프트웨어를 인스톨하여 사용하는 등의 방법으로 회피도 가능하다. 

DB인스턴스는 EC2와 같이 복수의 인스턴스 타입으로 준비된 스펙을 선택할 수 있으나, 데이터베이스 엔진에 따라 선택할 수 있는 타입이 제한되어 있기 때문에 주의가 필요하다.

RDS에서 사용할 수 있는 스토리지 타입

RDS의 데이터 저장용 스토리지에는 EBS를 사용한다. EBS 중에서도 RDS에서 이용 가능한 스토리지 타입은 범용 SSD, 프로비저닝 IOPS SSD, 마그네틱 3종류이다. 마그네틱의 경우 과거에 작업한 DB 인스턴스의 하위호환을 위하여 이용을 제한하고 있으니, 새롭게 DB인스턴스를 작성할 경우 기본적으로 SSD 타입을 선택하도록 하자. 프로비전 IOPS는 높은 IOPS가 요구될 경우나, 데이터 내용을 비교하여 I/O가 많은 경우에 이용을 검토하는 것이 좋다.

스토리지의 내용은 64TB(MSSQL의 경우 16TB) 까지 확장 가능하다. 확장은 온라인 상태로 실시 할 수 있으며, 확장중에는 약간의 퍼포먼스 저하가 발생할 수 있기 때문에, 이용빈도가 적은 시간대에 실행하는 것이 좋다.

RDS의 특징

RDS를 사용하는 것의 메리트는 운용의 효율화, 생략화를 들 수 있다. 이것들을 실현하기 위해선 RDS에는 편리한 매니지드 서비스를 다양하게 제공하고 있다.

멀티 AZ 구성

하나의 리전 내에 2가지 AZ에 DB 인스턴스를 각각 배치하여 장애가 발생하거나, 멘테넌스시에 다운 타임을 짧게하는 것으로 고가용성을 실핸하는 서비스이다. DB인스턴스 작성시에 멀티 AZ 구성을 선택하는 것 만으로 이후에 모든 AWS가 자동으로 DB의 다중화에 필요한 환경을 작성해준다. 프로덕션 환경에서 RDS를 이용할 때에는 멀티 AZ 구성을 권장한다.

멀티 AZ 구성

멀티 AZ 구성은 매우 유용한 매니지드 서비스이지만, 이용시에 주의할 점이 2가지 있다.

• 데이터 작성 속도가 느려진다 : 2가지의 AZ 간에 데이터를 동기하기 위하여 싱글 AZ 구성보다 작성이나, 커밋에 걸리는 시간이 길어진다. 프로덕션 환경에서 멀티 AZ 구성을 이용할  경우에는 성능 테스트를 실시할 때 멀티 AZ 구성을 한 채로 테스트를 실시하도록 하자. AWS의 코스트를 절약하기 위해 개발 환경은 싱글 AZ로 구성하고, 그 환경을 이용해 그대로 테스트 한뒤, 프로덕션 환경은 멀티 AZ로 만들어, 테스트시에 발견하지 못한 성능저하가 생길 수 있다는 점을 명심하도록 하자.
• 페일오버는 60 ~ 120초가 걸린다 : 페일오버가 발생할 경우 RDS에 접속용 FQDN의 DNS레코드가 스탠바이측의 IP 주소에 작성된다. 평소이는 확인된 DNS 레코드의 정보가 작성되어 있으며, 새로운 접속처의 IP 정보가 취득 가능하도록 될 때 까지 DB에 접속할 수 없다. 애플리케이션 측에서 DB 접속처 IP의 캐쉬를 가지고 있을 경우 RDS 페일오버후 애플리케이션으로부터 RDS에 접속가능 까지 약 120초 정도의 시간이 소모될 수도 있다.

리드 레플리카

보통 RDS와는 다른 참조용 DB 인스턴스를 작성하는 것이 가능한 서비스이다. 2020년의 시점에는 모든 데이터베이스 엔진에서 리드 레플리카를 이용할 수 있도록 되어 있다. 반면 Oracle과 SQL Server에 대해서는 이용방법이나, 이용가능한 라이센스의 종류에 제한이 있으니 이를 주의해야 한다.

리드 레플리카

리드 레플리카를 작성하는 것으로 마스터 DB의 부하를 줄이거나, 쓰기 작업이 많은 애플리케이션에 대한 DB 리소스의 스케일 아웃을 유연하게 대응할 수 있게 되었다. 예를 들면, 마스터 DB의 메인테넌스시에도 참조계열 서비스만은 정지하고 싶지 않을 경우, 애플리케이션의 DB 접속처를 리드 레플리카로 변경한뒤 마스터 DB의 메인테넌스를 실시하면 된다.

마스터와 리드 레플리카의 데이터 동기는 비동기 레플리케이션 방식이라는 점을 알아 둘 필요가 있다. 그렇기에 리드 레플리카를 참조하는 타이밍에 따라 마스터 측에 갱신된 정보가 레플리카에는 반영되어 있지 않을 가능성도 있다. 하지만 리드 레플리카를 작성해도 멀티 AZ 구성의 스탠바이 측의 데이터 동기와 같은 마스터 DB의 퍼포먼스에 영향을 주는 경우는 거의 없다고 할 수 있다.

백업/리스토어

• 자동백업 : 백업 윈도우 보관 기간을 설정하는 것으로 하루에 한번 자동으로 백업 (DB 스냅샷)을 취득하는 서비스이다. 백업의 보관기간은 최대 35일이며, 백업으로 부터 DB를 복구하는 경우에는 취득한 스냅샷을 선택하여, 신규 RDS를 작성한다. 이동중의 RDS에 백업 데이터로 되돌리는 것은 불가능하다. 삭제한 DB인스턴스를 다시 아용할 가능성이 있는 경우에는 삭제시에 마지막으로 스냅샷을 취득하는 옵션을 사용하도록 하자.
• 수동 스냅샷 : 임의의 타이밍에 RDS 백업을 취득 가능한 서비스이다. 필요에 따라 백업을 취득 할 수 있지만, 수동 스냅샷은 하나의 리전에 100개 까지 취득할 수 있는 제한이 있다. RDS 단위가 아닌 리전 단위의 제한이 있다는 걸 주의할 필요가 있다.  또한 싱글 AZ 구성에서 스냅샷을 취득할 경우, 단기간의 I/O 가 멈추는 시간이 발생할 수 있다는 것또한 주의점이라 할 수 있다. 이 시스템 사양은 자동 백업 또한 동일하다. 멀티 AZ 구성의 경우에는 스탠바이측의 DB 인스턴스로 부터 스냅샷을 취득하기 때문에 마스터 DB 인스턴스에 영향을 주지 않는다. 이 점으로부터도 프로덕션 환경에서 RDS를 사용할 때 멀티 AZ 구성을 추천한다.
• 데이터 리스토어 : RDS에 데이터를 리스토어 할 경우에는 자동 백업 또는 수동으로 취득한 스냅샷으로 부터 신규 RDS를 작성한다. 스냅샷 리스트로 부터 되돌리고 싶은 시점의 스냅샷을 선택하는 것 만으로 매우 간단하게 데이터를 리스토어 할 수 있다.
• Point-In-Time Recovery : 최근 5분간으로 부터 최대 35일전 까지의 임의의 타이밍의 상태의 RDS를 신규 작성하는 것이 가능한 서비스이다. 되돌릴 수 있는 최대 일수는 자동 백업의 취급 기간과 동일하다. 그렇기 때문에 포인트 인 타임 리커버리를 사용하고 싶을 경우에는 자동 백업을 유효화 할 필요가 있다.

세큐리티

데이터 베이스에는 개인 정보 등의 중요한 정보나 기밀 정보 등을 저장하는 경우도 있기 때문에, 세큐리티에는 특히 주의를 필요로 한다. 여기서는 RDS가 구성하는 2가지 세큐리티 서비스에 대해 설명해 볼까 한다.

• 네트워크 세큐리티 : RDS는 VPC에 대응하고 있기 때문에 인터넷에 접속할 수 없는 AWS의 VPC 네트워크 내에서 이용할 수 있는 서비스이다. DB 인스턴스를 작성할 때에 인터넷으로 부터 접속을 허가하는 옵션도 있지만, 기본적으로 OFF로 설정되어 있다. 또한 EC2와 같은 세큐리티 그룹에 의한 통신 조건의 제한이 가능하다. EC2나 다른 AWS 서비스로부터 RDS까지의 통신은 각 데이터베이스 엔진이 제공하는 SSL을 사용하는 암호화에 의해 이루어 진다.
• 데이터의 암호화 : RDS의 암호화 옵션을 유효화 하는 것으로, 데이터가 저장되는 스토리지 ( 리드 레플리카용 포함 )이나 스냅샷 뿐만 아니라 로그 등도 RDS에 관련 하는 모든 데이터가 암호화 되는 상태로 저장된다. 이 옵션은 도중에 유효화 하는 것은 불가능하다. 미리 데이터에 대하여 암호화를 해두고 싶을 경우에는 스냅샷을 취득하여 스냅샷의 암호화를 복사한다. 그리고 작성된 암호화 스냅샷으로 부터 DB 인스턴스를 새롭게 작성하는 것으로 기존 데이터의 암호화를 이룰 수 있다.

Amazon Aurora

AWS가 독자적으로 개발한 클라우드의 특징을 최대한 살릴 수 있는 아키텍처를 채용한 새로운 데이터 베이스 엔진이다. 2014년에 첫 서비스를 개시할 때엔 MySQL과 호환성을 가진 간단한 에디션으로 시작했지만. 2017년 10월에 이르러 PostgresSQL과의 호환성을 가진 새로운 에디션을 제공하기 시작했다. 여기선 다른 RDS와 Aurora의 차이점에 대해 알아볼까 한다.

Aurora의 구성요소

DB인스턴스를 작성하면 동시에 DB 클러스터가 작성된다. DB 클러스터는 하나 이상의 DB 인스턴스와 각 DB 인스턴스로부터 참조하는 데이터 스토리지 ( 클러스터 볼륨 ) 으로 구성된다. Aurora의 데이터 스토리지는 SSD를 베이스로 한 클러스터 볼륨이다. 클러스터 볼륨은 단일 리전내에 3개의 AZ에 각각 2가지 (총 6개)의 데이터 복사로 구성되며, 각 스토리지 간의 데이터는 자동적으로 동기된다. 또한 클러스터 볼륨 작성시에는 내용을 지정할 필요가 없고, Aurora 내에 저장된 데이터 량에 의해 최대 64TB 까지 자동적으로 확장된다.

Aurora 구성 요소

Aurora 레플리카

Aurora는 다른 RDS와는 다른 멀티 AZ 구성 옵션은 없다. 하지만 Aurora 클러스터 내에 참조 전용 레플리카 인스턴스를 작성하는 것이 가능하다. 다른 RDS의 리드 레플리카와는 다른 Aurora 의 프라이머리 인스턴스 장애가 발생할 경우에는 레플리카 인스턴스가 프라이머리 인스턴스로 교체되는 것으로 페일오버를 실현한다.

엔드 포인트

평소 RDS를 작성하면 접속용 엔드 포인트 (FQDN)이 하나 작성되어 해당 FQDN을 사용하여 데이터 베이스에 접속한다. Aurora에는 다음 3가지 종류의 엔드포인트가 작성된다.

• 클러스터 엔드 포인트 : Aurora 클러스터 중 프라이머리 인스턴스에 접속하기 위한 엔드포인트이다. 클러스터 엔드 포인트 경유로 접속할 경우, 데이터 베이스의 모든 조작 ( 참조, 작성, 갱신, 삭제, 정의 변경 )을 조작할 수 있다.
• 읽기 전용 엔드 포인트 : Aurora 클러스터 중 레플리카 인스턴스에 접속하기 위한 엔드 포인트이다. 읽기 전용 엔드 포인트에 경유하여 접속할 경우에는 데이터베이스에 대해 참조만 이용할 수 있다. Aurora 클러스터 내에 복수의 레플리카 인스턴스가 있을 경우에는 읽기 전용 엔드 포인트에 접속하는 것으로 자동으로 부하의 분산이 이루어 진다.
• 인스턴스 엔드포인트 : Aurora 클러스터를 구성하는 각 DB 인스턴스에 접속하기 위한 엔드포인트이다. 접속한 DB 인스턴스가 프라이머리 인스턴스일 경우에는 모든 조작이 가능하다. 레플리카 인스턴스일 경우에는 참조만 가능하다. 특정 DB 인스턴스에 접속하고 싶을 경우 요건에 의해 사용된다.

커스텀 엔드포인트
Aurora 에는 또 하나 커스텀 엔드포인트 라고 불리는 엔드 포인트가 있다. 이것은 Aurora 클러스터를 구성하는 인스턴스 내에서 임의의 인스턴스를 그루핑하여 액세스 하는 경우에 사용한다. 예를 들어 읽기 전용 엔드포인트면 레플리카 인스턴스 전체에 액세스가 분산된다. 커스텀 엔드 포인트를 사용하면 레플리카 인스턴스를 웹 서비스용과 배치 처리용으로 나누는 것으로 배치 실행할 경우 부하가 높은 참조 처리가 웹 서비스의 참조 처리에 영향을 주지 않도록 구성을 이룰 수 있다.

엔드 포인트

Redshift

AWS가 제공하고 있는 데이터 웨어 하우스를 위한 데이터 베이스 서비스이다. 대량의 데이터로 부터 의사 결정에 도움이 되는 정보를 발견하기 위해 필요한 환경을 합리적인 가격으로 준비해 두었다. 지금까지 일반적으로 제공되었던 데이터 웨어 하우스의 도입 코스트와 비교하여 10분의 1 ~ 100분의 1 정도로 부터 시작하는 것이 가능하기에, 데이터 웨어 하우스를 활용한 빅데이터 분석의 도입을 검토할 경우 가장 인기 있는 서비스가 될 것이다.

Redshift는 PostgresSQL과 호환성이 있기 때문에, pgsql 커맨드로 접속하는 것도 가능하며, 다양한 BI 툴이 Redshift의 기능을 서포트 하고 있다.

Redshift의 구성

복수의 노드에 의해 병렬 실행이 가장 특징이라 할 수 있다. 하나의 Redshift를 구성하는 복수의 노드의 모음을 Redshift 클러스터 라고 부른다. 클러스터는 하나의 리더 노드와 복수의 컴퓨트 노드로 구성된다. 복수의 컴퓨트 노드를 거치지 않고 처리가 완결 되도록 분산 구성을 얼마나 잘 만들어 내는가가 Redshift를 유용하게 사용하는지의 포인트가 된다.

• 리드 노드 : SQL 클러스터나 BI 툴 로부터의 실행 쿼리를 받아들여 쿼리의 분석이나, 실행 플랜을 구성한다. 컴퓨트 노드의 수에 대하여 최적의 분산 처리를 실행할 수 있도록 하는 말하자면, 사령탑과 같은 역할이다. 또한 각 컴퓨트 노드로부터의 처리 결과를 받아들여 반환하는 처리도 담당하고 있다. 리더 노드는 각 클러스터에 한대만 존재할 수 있다.
• 컴퓨트 노드 : 리드 노드로 부터 받은 실행 쿼리를 처리하는 노드이다. 각 컴퓨트 노드는 스토리지와 세트 구성이다. 컴퓨트 노드를 추가하는 것으로 CPU나 메모리, 스토리지와 같은 리소스를 늘리는 것도 가능하며, Redshift 클러스터로서의 퍼포먼스도 향상 시킬 수 있다.
• 노드 슬라이스 : Redshift가 분산 병렬 처리를 하는 최소 단위이다. 컴퓨트 노드 중 더욱더 리소스를 분산하여 슬라이스 라고 하는 단위로 구성한다. 노드 내의 슬라이스 수는 컴퓨트 노드의 인스턴스 타입에 따라 차이가 있다.

Redshift 의 구성

Redshift의 특징

열 기반 (columnar) 데이터 베이스

데이터 웨어하우스 에는 대량의 데이터에 대한 집계 처리를 실행하는 것이 메인이다. 데이터 웨어 하우스의 보틀넥 부분은 데이터 I/O 부분이다. 그렇기 때문에 필요한 데이터를 효율적으로 액세스 가능한 조합은 퍼포먼스의 시선으로 보면 매우 중요하다. 열 기반형 데이터베이스는 집계 처리에 사용되는 데이터를 한대 모아 ( 열 단위로 ) 관리하고, 스토리지 로 부터 데이터의 취득을 효율화 한다. 결과로선 대용량의 데이터에 대하여 집계처리를 실행하는 경우에는 우수한 퍼포먼스를 발휘한다.

많은 압축 인코딩 방식

데이터 I/O 의 보틀넥이 발생하지 않도록 하기 위한 방법으로 취득한 데이터의 양을 줄이는 접근 방법이 있다. Redshift는 9종류의 압축 인코딩을 대응하고 있다. 또한 열 마다 압축 인코딩 방식을 지정할 수 있기 때문에, 데이터의 성격에 맞게 방법을 선택하는 것도 효율적인 데이터 압축을 실현할 수 있다. 각 테이블의 열내에 존재하는 데이터는 닮은듯한 데이터도 많기 때문에 열 기반의 데이터베이스와 조합하는 것으로 디스크 I/O를 더욱더 경감시킬 수 있음을 기대할 수 있다.

존 맵

Redshift에는 블록 단위로 데이터를 저장한다. 1 블록의 용량은 1MB이다. 존 맵이란 해당 블록 내에 저장되어 있는 데이터의 최소치와 최대치를 메모리에 저장하는 방법이다. 이 방법을 활용하는 것으로 데이터 검색 조건에 상응하는 값의 유무를 효율적으로 판단할 수 있으며, 데이터가 존재하지 않을 경우에는 해당 블록을 빠르게 넘겨 검색 처리를 효율적으로 이뤄낼 수 있다.

유연한 확장성

Redshift의 유연한 확장성을 실현하고 있는 방법은 MPP(Massively Parallel Processing)과 쉐어드낫싱 2가지이다. 이것들 두가지 방법을 이용하여 Redshift 클러스터를 구성하는 것으로 대량의 데이터를 효율적으로 집계 처리할 수 있다.

• MPP : 1회 집계처리를 복수의 노드에 분산하여 실행하는 방법이다. 이 방법이 있기에 노드를 증가 (스케일아웃) 하는 것만으로 분산 병렬 처리의 퍼포먼스를 향상시킬 수 있다.
• 쉐어드 낫싱 : 각 노드가 디스크를 공유하지 않고, 노드와 디스크 세트로 확장하는 방법이다. 복수의 노드가 동일한 디스크를 공유하는 것에서 발생하는 I/O 성능의 약점을 우회하기 위해 채용되어 있다.

워크로드의 관리 기능

Redshift 에는 매우 다양한 데이터 분석 요구를 효율적으로 처리하기 위한 관리 기능 (Workload Management WLM) 이 준비되어 있다. Redshift의 파라메터 그룹인 wlm_json_configuration 파라메터로 쿼리의 실행에 대한 정의가 가능하다.

쿼리 큐의 정의
실행하는 쿼리의 종류에 의해 전용 큐를 작성한다. 각 큐에서 정의 가능한 프로퍼티 열은 아래 표와 같다. 예를 들어 장시간 실행을 요하는 단발의 쿼리와 실행 시간은 짧지만 정기적으로 실행하는 쿼리가 있을 경우, 전자의 처리가 후자의 실행에 영향을 주지 않도록 큐를 나누어 사용하는 것으로 대응하고 있다.

 

프로퍼티	정의 내용
short_query_queue	기기 학습을 위해 자동적으로 실행 시간을 짧은 쿼리를 검출하여, 우선적으로 실행할지 말지를 지정한다.
max_execution_time	short_query_queue 를 True 로 설정할 경우, 실행 시간이 짧다고 판단하는 기준을 지정한다.
query_concurrency	큐 내의 동시 실행 가능한 쿼리 수를 정의한다. 해당 수 이상의 쿼리가 발생한 경우에는 큐 내부에서 대기하여, 순차적 실행이 가능하다.
user_group	쿼리를 실행하는 유저에의해 큐를 나누는 경우 지정한다. 복수 유저를 지정하는 경우에 콤마로 나눌 수 있다.
user_group_wild_card	user_group에 와일드 카드 문자를 이용 가능한지 어떤지를 지정한다.
query_group	실행하는 쿼리에 대하여 큐를 나누는 경우에 지정한다.
query_group_wild_card	query_group에 와일드 카드 문자를 이용가능한지에 대해 설정한다.
query_execution_time	쿼리가 실행되기 시작하면 취소되기까지의 시간을 지정한다. 타임아웃이 발생한 경우, 실행 조건에 일치하는 별도의 큐가 있을 경우 해당 큐에서 다시 쿼리가 실행된다. 조건에 일치하는 큐가 없을 경우에는 실행이 캔슬된다.
memory_percent_to_user	큐에 할당되는 메모리의 배합을 설정한다.
rules	쿼리 실생시의 CPU 이용율이나 데이터의 취득 조건등, 주로 고부하, 대용량 데이터 처리에 관한 쿼리에 한하여 특정 조건에 해당하는 경우 쿼리의 취급에 대하여 정의한다. 예를 들면 테이블 조합의 결과 해당 데이터가 몇억건을 넘을 경우에는 처리를 정지 한다 등이 있다.

 

Redshift Spectrum

S3에 놓여진 데이터를 외부 테이블로서 정의하는 것과 같이 Redshift 내에 데이터를 직접 넣지 않고, 쿼리의 실행이 가능하도록 하는 확장 서비스이다. 과거 Redshift를 사용할 때에는 아래와 같은 과제가 있었지만, 그것들을 해결하기 위한 솔루션으로서 등장하였다.

• S3로 부터 Redshift로의 데이터 로드 (COPY) 에 시간이 걸린다.
• 데이터의 정가에 따라 Redshift 클러스터의 스토리지 용량을 확장할 필요가 있지만, CPU나 메모리도 같이 추가되어 불필요한 코스트가 발생한다.

Redshift Spectrum

Redshift내의 데이터와 S3 상의 데이터를 조합한 SQL의 실행도 가능하기 때문에 액세스 빈도가 적은 데이터를 S3에 배치하여 디스크 용량을 절약하도록 하자. 복수의 Redshift 클러스터로 부터 S3 상의 데이터를 공유하는 것도 가능하게 되었다.

DynamoDB 의 특징

고 가용성 설계

단일 장애점 (Single Point Of Failure, SPOF) 를 가질 수 없는 구성으로 되어 있기 때문에, 서비스 면에서의 장애대응이나 멘테넌스 시의 운용을 생각할 필요가 거의 없다. 또한 DynamoDB 내의 데이터는 자동적으로 3가지 AZ에 저장되는 구성을 가지고 있기 때문에 매우 가용성이 높은 서비스라고 말할 수 있다.

스루풋 범위 

DynamoDB를 이용할 경우 테이블이나 인덱스를 작성할 때에 읽기와 쓰기에 필요한 스루풋을 지정한다. 이 스루풋의 범위는 언제든지 다운 타임 없이 변경이 가능하다. 스루풋 범위는 읽기와 쓰기 각각 개별의 범위 유닛을 단위로 지정한다.

• Read Capacity Unit (RCU) : 읽기용 스루풋 범위를 지정하는 지표이다. 1RCU는 최대 4Kb의 항목에 대하여 1초당 1회의 강력한 조합성이 있는 읽기 기능, 또는 1초당 2회의 결과적 조합성이 있는 읽기 성능을 담보하는 것을 나타낸다.
• Write Capacity Unit (WCU) : 쓰기를 위한 스루풋 범위를 지정하는 지표이다. 1WCU는 최대 1Kb의 항목에 대하여 1초당 1회의 쓰기 성능을 담보하다.

스루풋 범위의 변경을 증가 시키는데 있어선 제한이 없다. 하지만 수초간에 대해선 1일 9회 까지라는 제한이 있기에 주의해야 한다.

스루풋 범위의 동적 스케일링
부하의 상황에 응하여 스루풋 범위를 자동적으로 증감하는 것이 가능하다. 1일중 스루풋에 변화가 있을 경우 지정하는 것으로, 평시 높은 스루풋의 범위를 확보해둘 필요가 없기 때문에, 코스트면에서 메리트가 있다. EC2의 Auto Scaling과 같이 급격한 스루풋의 상한에 즉시 대응하는 것이 아니기 때문에 사전에 스파이크가 발생하는 것을 인지하고 있었다면 수동으로 범위를 확장하여 대응할 필요가 있다.

데이터 파티셔닝

DynamoDB는 데이터를 파티션이라고 하는 단위로 분류한다. 하나의 파티션에 대하여 확보 가능한 용량이나. 스루풋 범위가 정해져 있기 때문에, 데이터의 증가나 지정된 스루풋의 사이즈에 따라 최적화 되어 있는 상태를 가진 파티션을 확장한다. 이 제한은 DynamoDB 내부에 자동적으로 이루어 지기 때문에 이용자가 인식할 필요는 없다.

프라이머리와 인덱스

Key-Value 형 데이터 베이스 이기 때문에, 저장되어 있는 데이터 항목은 키 가 되는 속성과 그 외의 정보에 의해 구성되어 있다. 프라이머리키는 데이터 항목을 유니크하게 특정하기 위한 속성으로 [파티션 키] 하나로 이루어 진 것과 [파티션 키 + 정렬 키]의 조합으로 이루어져 있는 (복합 키 테이블) 의 2종류가 있다. 파티션 키 만으로는 유니크하게 특정할 수 없을 경우에는 정렬키와 조합하여 프라이머리 키를 구성한다.

또한 프라이머리 키 는 인덱스로서도 이용되며, 데이터 검색의 고속화를 담당하기도 하낟. 하지만 프라이머리키 만으로는 고속의 검색 요건을 만족 시킬 수 없을 경우도 있다. 이런 경우에는 세컨더리 인덱스를 작성하는 것으로 고속의 검색을 가능하게 만들 수 있다. 세컨더리 인덱스는 [로컬 세컨더리 인덱스인 LSI]와 [글로벌 세컨더리 인덱스 GSI] 의 2가지 종류로 이뤄진다.

• 로컬 세컨더리 인덱스 [LSI] : 프라이머리 키는 테이블에 지정한 파티션 키와 같은 별도의 속성을 정렬키로서 작성하는 인덱스를 지칭한다. 본래의 테이블과 같은 파티션 내의 검색이 이뤄지는 것으로 부터 [로컬] 이라고 하는 이름이 붙여진다. LSI는 복합 키 테이블만 작성할 수 있다.
• 글로벌 세컨더리 인덱스 [GSI] : 프라이머리 키와 다른 속성을 사용하여 작성하는 인덱스와 그것을 칭한다. GSI는 테이블과 별도의 범위 유닛과 스루풋을 지정한다.

세컨더리 인덱스는 편리하지만, Key-Value형의 데이터 베이스의 사용법의 본질은 아니다. 작성한 만큼은 데이터 용량을 확보할 필요가 있거나, 별도의 범위 유닛이 필요하거나 하는 등 코스트의 추가도 필요하다. 복수의 세컨더리 인덱스를 작성할 필요가 있을 경우에는 RDS로의 변경 등 구성을 새롭게 생각해 보는 것을 포함하여 검토해 볼 필요가 있다.

LSI 와 GSI

기간이 지난 데이터의 자동 멘테넌스 (Time To Live TTL)

DynamoDB 내의 각 항목에는 유효기간의 설정이 가능하며, 유효기간이 지난 데이터는 자동적으로 삭제된다. 데이터는 순차적으로 삭제되는 것이 아닌, 유효 기간이 끝난 뒤 최대 48시간 이내에 삭제된다. 자동 메엔테넌스에 따른 데이터 삭제 조작은 스루풋 범위 유닛을 소비하지 않기 때문에, 해당 기능을 유효활용 하는 것으로 과거 데이터의 메인테넌스를 효율적으로 실시할 수 있다.

DynamoDB Stream

DynamoDB에 대하여 행해진 최근 24시간 내의 추가, 변경, 삭제의 변경이력을 저장하는 기능이다. DynamoDB를 사용한 애플리케이션의 이용 이력을 파악하는 것도 물론 가능하며, 데이터가 변경된 타이밍을 확인하는 것도 가능하기 때문에, 변경 내용에 대한 처리를 리얼 타임으로 실행하는 등의 방법도 구성할 수 있다.

강한 일관성을 가진 참조 (Consistent Read)

DynamoDB는 결과 조합성 데이터 모델을 채용한 데이터베이스이다. 하지만 해당 옵션을 유효화 하는 것으로 참조의 리퀘스트가 있을 시점 보다 이전에 작성된 데이터가 모두 반영된 상태의 데이터를 원래의 참조 결과를 반환하게 할 수 있다. 해당 옵션을 이용한 RCU는 2배 소비되는 점에 주의할 필요가 있다. 세컨더리 인덱스의 경우 Key-Value 형 데이터 베이스의 본래 사양이 아니기 때문에, 해당 옵션을 사용할지, 아니면 RDB의 구셩을 변경하는 것이 좋을지 검토할 필요가 있다.

DynamoDB Accelerator (DAX)

DynamoDB의 전 단계의 캐시 클러스터를 구성하는 확장 서비스이다. DynamoDB 에는 원래 밀리 초 단위로의 읽기 레스폰스를 실현할 수 있지만, DAX를 이용하는 것으로 매초 수백만의 읽기 처리에도 마이크로 초 단위로의 반응을 실현할 수 있다. 성능이 점점 상승하는 것은 물론, DynamoDB에 대하여 직접 읽기 조작을 실행하는 회수를 감소 시키기 위하여 RCU의 확보는 물론 코스트 삭감에도 많은 영향을 준다.

DAX

Elasticache

Amazon Elasticache는 AWS가 제공하는 인 메모리형 데이터 베이스 서비스이다. 높은 빈도로 참조하는 데이터나 검색에 시간이 걸리는 데이터 셋을 메모리 상에 대기시켜 두는 것으로 시스템의 퍼포먼스 향상을 부여한다.

Elasticache는 Memcached와 Redis의 2종류의 엔진을 서포트 하고 있다. 용도에 따라 고속의 엔진을 선택하도록 하자.

• Memcached : KVS (key-value store) 형 인메모리 데이터 베이스의 사실상 표준이로 넓게 사용되고 있는 엔진이다. 매우 심플한 데이터 구조로 데이터 처리 퍼포먼스 향상에 특화된 캐시 시스템이다. 데이터의 영속성 기능은 없기 때문에, 메인테넌스나 장애에 의해 재기동이 이뤄질 경우 모든 데이터가 삭제된다. 아래의 용도의 경우에는 Memcached를 선택 하도록 하자.
  • 심플한 캐시 시스템을 이용하고 싶다.
  • 만일 데이터가 사라져도 시스템의 동작에 커다란 영향을 주지 않는다. ( 데이터가 없어도 기동은 한다 )
  • 필요한 캐시 리소스의 증감이 빈번하며, 스케일 아웃, 스케일인을 할 필요가 있다.
• Redis : KVS 형 인 메모리 데이터 베이스인 것은 Memcached와 동일 하지만, Memcached 보다 많은 데이터 형을 지원하며, 캐시 용도 뿐만 아니라 메세지 브로커를 구성하는 요소로서도 이용되고 있다. 또한 노드 간의 레플리케이션 기능이나, 데이터 영속성 기능이라 할 만한 가용성 면도 고려된 기능이 실시되어 있다. 아래의 용도의 경우 Redis를 선택하도록 하자.
  • 문자열, 리스트, 세트, 스토어드 세트, 해쉬, 비트맵 등 다양한 데이터형을 사용하고 싶다.
  • 키 스토어에 영속성을 가지게 하고 싶다.
  • 장애 발생시에 자동적인 페일오버를 하거나, 백업/리스토어 등의 가용성이 필요하다.

Memcached 판 Elasticache의 특징

클러스터 구성

Memcached 클러스터는 최대 20개의 Elasticache 인스턴스로 구성되어 있다. 클러스터 내의 저장된 데이터는 각 인스턴스에 분산되며, 클러스터를 복수 인스턴스로 구성할 떄에는 가용성을 고려하여, 복수의 AZ에 Elasticache 인스턴스를 작성하도록 하자.

클러스터를 작성하려면, 2종류의 액세스용 엔드 포인트가 작성된다.

• 노드 엔드 포인트 : 클러스터 내의 각 노드에 개별 액세스 하기 위한 엔드포인트, 특정의 노드 에서만 반드시 액세스 하고 싶은 경우 사용된다.
• 설정 엔드 포인트 : 클러스터 전체에 나눠져 있는 엔드포인트, 클러스터 내의 노드의 구성을 관리하며 클러스터의 구성 정보를 자동적으로 갱신한다. 애플리케이션으로 부터 Elasticache 서비스에 접속할 때에는 이 엔드 포인트를 이용한다.

스케일링

Memcached 클러스터 에는 스케일 아웃, 스케일 인, 스케일 업, 스케일 다운 4가지 스케일링으로 부터 필요에 따라 리소스를 조정할 수 있다.

• 스케일 아웃과 스케일 인 시의 주의점 : Memcached 클러스터의 데이터는 클러스터 내의 각 노드에서 분산되어 저장되는 것은 앞서 설명한 대로이다. 그렇기에 노드 수를 증감 시킬 경우 올바른 노드에 데이터를 재 매핑할 때 까지 캐시미스가 일시적으로 중가할 수 있다.
• 스케일 업과 스케일 다운 시의 주의점 : Memcached 클러스터를 스케일 업, 스케일 다운 할 때에는 신규 클러스터를 작성할 필요가 있다. Memcached는 데이터 영속성이 없기 때문에, 클러스터를 재 작성할 경우 그때까지 저장하고 있던 모든 데이터는 삭제된다.

Redis 판 Elasticache

클러스터 구성

Redis 판에는 클러스터 모드의 유/무효에 응하여 다양화의 구성이 변한다. 어떠한 경우에도 멀티 AZ 구성을 작성하는 것이 가능하기 때문에, 마스터 인스턴스가 장애상태가 될 경우에는 스탠바이 인스턴스가 마스터 인스턴스로 승격된다. 이런 확장 구승이 가능하단 것이 Memcached판 Elasticache와의 커다란 차이점이다.

• 클러스터 모드 무효 : 클러스터 모드가 무효인 경우 캐시 데이터는 모든 하나의 Elasticache 인스턴스에 저장된다. 또한 같은 데이터를 가진 리드 레플리카를 최대 5개 까지 작성할 수 있다. 하나의 마스터 인스턴스와 리드 레플리카의 세트를 샤드 라고 한다.
• 클러스터 모드 유효 : 클러스터 모드가 유효일 경우 최대 500개의 샤드에 데이터를 분산하여 저장하는 구성이 가능하다. 리드 레플리카는 하나의 시드에 대하여 최대 5개까지 작성할 수 있다. 데이터를 분산하는 것으로 Read/Write의 부하 분산 구성을 작성하는 것이 가능하다.

Redis 판 Elasticache의 액세스용 엔드 포인트는 3가지 종류가 존재한다.

• 노드 엔드 포인트 : 클러스터 내 각 노드에 개별 액세스 하기 위한 엔드포인트, 특정의 노드에만 반드시 액세스 하고 싶을 경우에 사용한다. 클러스터 모드가 유/무 효의 경우 모두 사용할 수 있다.
• 프라이머리 엔드 포인트 : 쓰기 처리용, Elasticache 인스턴스에 액세스 하기 위한 엔드포인트, 클러스터 모드가 무효의 경우 사용한다.
• 특정 엔드 포인트 : 클러스터 모드가 유효의 경우에 이 설정 엔드 포인트를 사용하여 Elasticache 클러스터에 대하여 모든 조작을 행할 수 있다.

구분	클러스터 무효	클러스터 유효
샤드	1	최대 500
리드 레플리카 수	최대 5대	최대 5대 ( 샤드 )
데이터의 분산화(샤딩)	X	O
리드 레플리카 추가 / 삭제	O	O
샤드 추가 / 삭제	X	△(Redis 3.2.10 이후 O)
엔지니어 업그레이드	O	O
레플리카 프라이머리 승격	O	X
멀티 AZ	O (옵션)	O
백업 / 복원	O	O

스케일링

Redis판 Elasticache 의 클러스터 모드는 처음 구축 후 [리드 레플리카] 의 추가, 삭제 [샤드] 의 추가, 삭제 [엔진 버전]의 변경이 불가능한 제약이 있다. 최근에는 이 부분의 제약은 없어졌다. 하지만 스케일링 중에는 처리의 대부분이 오프라인 상태가 되므로 스케일링은 여전히 계획을 새워 진행할 필요가 있다.

CPU 사용량

Redis는 싱글 스레드 이기 때문에 1 코어에서 동작한다. 예를 들어 4코어 인스턴스 타입을 사용하고 있다고 하더라도 1코어만 사용하기 때문에 CPU 사용률은 25%가 최대치이다. 이 점을 주의해야 한다. Redis6 에서 멀티 스레드에 대응하고 있기 때문에 Redis 판 Elasticache에서도 개선될 가능성이 있다.

데이터의 암호화

Redis 3.2.6 또는 4.0.10이후에는 Redis 클라이언트와 Elasticache 간의 통신과 Elasticache 내의 저장된 데이터의 암호화를 서포트 하고 있다. 데이터 암호화는 Redis판 Elasticache만 대응하며, Memcached 판에는 데이터 암호화 기능이 없다.

기타 데이터 베이스

실제로 이용 빈도가 많은 것은 RDS, Redshift, DynamoDB, Elasticache이지만, 이것 외의 데이터베이스에 대해서도 이름과 기능정도는 알아 둘 필요가 있다.

Amazon Neptune

풀 매니지드 그래프 데이터 베이스 서비스이다. 그래프 데이터 베이스는 노드, 엣지, 프로퍼티 3가지 요소에 의해 구성되어 있으며, 노드 간의 [관계성]을 나타낸다. 데이터 구조는 네트워크 형이며 facebook 이나 Twitter의 소셜 서비스와 같은 연결 관계를 구현하고 있다. 그 이외에도 경로 검색이나. 구입 이력으로 부터의 레코멘드 등에 이용한다.

Amazon DocumentDB

풀 매니지드의 MongoDB 호환의 도큐먼트 데이터 베이스 서비스이다.  호환 데이터 베이스 이기 때문에, 내부적 구조는 AWS가 독자적으로 재구축 되었다고 추측되지만, 인터페이스면에서 MongoDB와 호환성이 있으며, 서버 상에서 독자적으로 구축한 MongoDB를 DocumentDB에 이행하는 것이 가능하다.

Amazon Keyspaces

풀매니지드 Apache Cassandra 호환의 데이터베이스 서비스이다. 서비스로서의 특징은 DocumentDB와 같으며, AWS가 매니지한 호환 데이터베이스를 제공하고 있다 할 수 있다. 데이터베이스의 특징으로는 Cassandra는 열 지향 데이터 와 행 지향 데이터의 양쪽 모두의 특징을 가지고 있기 때문에, 검색성도 높은 임의의 데이터를 포괄적으로 취득시켜 주는 것도 특징이라 할 수 있다.

Amazon Timestream

풀 매니지드의 시열형 데이터 베이스 서비스이다. 시열형 데이터 베이스는 시계열 데이터를 다루는 것이 특징인 데이터베이스 이다. 시계열 데이터란, 서버의 메모리나, CPU등의 이용 상태의 변화나, 또는 기온의 변화등 시간적인 변화에 따른 정보를 가진 데이터를 일컫는다. 이것들의 데이터를 관계형 데이터베이스에 비해 천배의 속도에 거기다 낮은 코스트로 처리, 분석 가능한 설계가 되어 있다. IoT나 서버 모니터링 용도로 최적화 되어 있다.

Amazon QLDB( Quantaum Ledger Database )

풀 매니지드의 대장용 데이터 베이스라고 일컫는다. 대장 데이터 베이스란 변경 이력 등을 모두 남기며 거기에 해당 이력을 검증 가능한 상태로 관리하는 것이다. 기업의 경제활동이나, 재무 활동을 이력으로서 기록할 필요가 있을 경우 이용할 수 있는 서비스이다. 같은 용도로서 Hyperledger Fabric 이나 Ethereum 등의 블록체인 프레임워크가 활용되고 있지만, 해당 인프라를 관리하는 것은 매우 번거롭다. QLDB를 활용하는 것으로 같은 기능을 얻을 수 있다.