[AWS Aurora] Aurora I/O Planning

 

l  Version : Aurora

 

Amazon Aurora 상용 데이터베이스의 성능 가용성과 오픈 소스 데이터 베이스의 단순성 비용 효율성을 결합한다. Aurora 클러스터는 공유 분산 Aurora 스토리지 볼륨에 연결된 하나 이상의 인스턴스로 구성된다. 새로운 스토리지 엔진은 관계형 데이터베이스에서 일반적으로 사용되는 기존 블록 스토리지 장치를 자동 크기 조정, 자동 복구, 로그 기반 동적 스토리지 볼륨으로 대체한다. 새로운 스토리지 엔진은 클라우드용으로 설계되었으므로 데이터베이스가 전통적으로 스토리지 시스템과 상호작용하는 방식에서 가지 근본적인 변경이 이루어 졌다. 글은 기존 데이터베이스와 비교하여 Aurora에서 I/O 작동하는 방식, Aurora I/O 비용을 모니터링하는 방법 Aurora I/O 최적화하는 방법을 설명한다.

 

[데이터베이스 I/O 개요]

높은 수준에서 관계형 데이터베이스는 전통적으로 블록 스토리지와 상호작용한다. 블록 스토리지에서 데이터는 페이지라는 블록에 저장된다. 페이지 크기는 데이터베이스 엔진마다 다르며 동일한 데이터베이스 엔진 내에서도 엔진의 구성 매개변수에 따라 다르다. Aurora Amazon Aurora MySQL 대해 16KB 페이지 크기와 Amazon Aurora PostgreSQL 대해 8KB 페이지 크기를 지원한다. 페이지 크기는 데이터베이스 엔진이 수행하는 가장 작은 I/O 작업이다.

 

[읽기 작업]

MySQL 또는 PostgreSQL 같은 관계형 데이터베이스가 디스크에서 페이지를 읽을 해당 페이지는 버퍼풀이라는 세그먼트의 메모리에 저장된다. 해당 페이지는 버퍼풀로 읽혀지는 다른 페이지의 메모리 압력으로 인해 제거되거나 엔진이 다시 시작될 때까지 무기한 남아 있을 있다. 응용 프로그램이 SELECT 쿼리를 실행할 엔진은 버퍼풀에 이미 있는 페이지를 사용하여 쿼리를 수행하려고 시도한다. 쿼리를 완료하는데 필요한 페이지 버퍼 풀에 존재하지 않는 페이지는 쿼리가 완료되기 전에 먼저 디스크에서 버퍼풀로 읽어와야 한다.

 

Aurora 사용하면 읽기가 기본 MySQL 또는 PostgreSQL 동일한 방식으로 처리된다. , 버퍼풀을 채우는데 필요한 만큼 스토리지 볼륨에서 페이지별로 데이터를 읽고 버퍼풀 내부의 해당 페이지에 대해 SELECT 쿼리를 실행한다. 이와 같이 읽기I/O 작업은 스토리지 볼륨에서 페이지 또는 익스텐트를 읽을 누적된다. 쿼리를 실행하는데 필요한 모든 페이지가 이미 버퍼풀에 존재하는 쿼리인 경우 스토리지 볼륨에서 읽을 이유가 없기 때문에 해당 쿼리에 대한 I/O 0이다. 스토리지 볼륨에서 페이지를 검색 해야하는 쿼리의 경우 읽은 각페이지는 하나의 읽기 I/O 계산된다.

 

여러 요인에 따라 페이지가 얼마나 가득 있는지 따라서 동일한 수를 유지하는데 필요한 페이지수를 결정할 있다. 이러한 요인 중하나는 인덱스의 지정된 채우기 비율이다, 채우기 비율 100 인덱스가 생성될 페이지가 100% 용량에 최대한 가깝게 채워 져야함을 나타낸다. 결과 동일한 수의 행을 저장하는데 사용되는 페이지수가 줄어들어 읽기 I/O 효율성이 최대화 된다. 예를 들어 테이블의 크기가 100바이트이고 채우기 비율이 100 기본 키가 생성된 경우 대략 160개의행이 16KB 페이지에 기록된다. 그러나 채우기 비율이 50이고 페이지가 50% 용량으로 채워지면 결과는 각각 80행이 있는 페이지가 된다. , 채우기 비율이 50 동일한 집합을 읽으면 읽기 I/O 작업이 많이 발생한다. 채우기 비율은 기본 또는 인덱스를 생성하거나 다시 작성할 적용된다.

 

후속 DML 작업이 페이지를 채우는 정도는 다른 여러 요인에 따라 다르다. 예를 들어, 테이블의 기본 키를 순차적인 자동 증가 정수로 지정하면 행이 페이지에 깔끔하게 쌓이기 때문에 페이지가 용량까지 채워지고 페이지 수가 최소화된다. 반대로 GUID 또는 여러 열로 구성된 자연 키와 같이 기본 키가 무작위인 경우 행이 끝에 추가되지 않고 인덱스 중간에 삽입 있기 때문에 페이지가 분할되는 경향이 있다. 이런 식으로 인덱스가 단편화(조각화)되고 같은 수의 행을 저장하는 필요한 페이지 수가 크게 늘어난다. 조각난 페이지는 버퍼풀에서 많은 공간을 낭비하고 읽기 I/O 증기 시킨다.

 

[쓰기 작업]

관계형 데이터베이스가 INSERT, UPDATE, DELETE 같은 쓰기 작업을 수행 가지 일이 발생한다. 먼저 수정할 페이지를 버퍼풀에 넣고 해당 페이지에 대한 변경 기록을 트랜잭션 로그에 기록한다. 로그의 이름은 플랫폼마다 다르지만 MySQL에서는 redo로그, PostgreSQL에서는 WAL 로그라고 한다. 플랫폼에 따라 디스크에 기록되는 MySQL 바이너리 로그(binlog) 같은 다른 로그도 있지만 글에서는 redo 로그에 초점을 맞춘다.

 

redo 로그가 기록된 페이지는 버퍼풀에서 수정되고 체크포인트로 알려진 프로세스가 다른 모든 더티 페이지와 함께 해당 페이지를 디스크에 때까지 버퍼풀에 더티 페이지로 남아 있다. 체크포인트 프로세스는 쓰기 집약적이며 상당한 디스크  I/O 유발할 있다.

 

Aurora 사용하면 페이지를 버퍼풀에 배치하고, redo 로그에 쓰고, 버퍼풀에서 페이지를 수정하는 동일한 작업이 유지되며, redo 로그 레코드는 페이지에 대한 변경 사항을 나타낸다. 가장 차이점은 Aurora 체크포인트를 발행하지 않는다는 것이다. 대신 Aurora스토리지 볼륨에 기록되는 데이터는 전체 페이지에 비해 크기가 매우 작은 redo로그 뿐이다. , 일반적으로 더티 8KB 또는 16KB 페이지를 디스크에 기록하여 생성되는 모든 디스크 I/O 제거된다. 대신 페이지는 스토리지 노드에서 주기적으로 구체화되며 경우에 따라 요청시에도 구체화된다. 이러한 I/O 작업에는 요금이 부과되지 않는다. 이러한 변경의 순효과는 모든 쓰기가 3개의 가용 영역에 분산된 6개의 스토리지 노드로 전송된다는 사실에도 불구하고 쓰기 I/O 작업이 전반적으로 감소한다는 것이다. (1개의 쓰기로 계산됨)

 

실제 로그 레코드의 크기는 다양하지만 Aurora 클러스터에 대한 쓰기는 가능한 경우 4KB 단위로 전송된다. 기록기에 크기가 4KB 미만인 여러 로그 레코드가 동시에 있으면 단일 쓰기 작업으로 일괄 처리 된다. 예를 들어 50바이트 로그 레코드와 3000바이트 로그 레코드를 단일 쓰기 작업으로 결합할 있다. 4KB보다 로그 레코드는 4KB 단위로 분할된다.

 

Aurora 클러스터에 읽기 전용 인스턴스가 포함된 경우 스토리지 볼륨으로 전송된 동일한 쓰기가 해당 읽기 전용 인스턴스에도 전송된다. 이렇게 하면 판독기의 버퍼풀이 최신 상태로 유지된다. 리더가 로그 레코드를 수신하고 이미 읽기 전용 인스턴스의 버퍼 풀에 있는 페이지에 해당하면 로그 레코드에 설명된 변경 사항이 리더의 버퍼풀에 있는 페이지에 적용된 다음 로그 레코드 자체가 삭제 된다. 버퍼풀에 페이지가 없으면 로그 레코드는 단순히 폐기된다. 경우 모두 스토리지 볼륨에 대한 I/O활동이 발생하지 않는다.

 

[I/O 작업]

이제 Aurora에서 I/O 기본 사항을 다루었으므로 Aurora MySQL 사용하는 보다 구체적인 예를 살펴본다. 아래 스크립트를 실행할 column_name1 테이블의 기본키이며 현재 버퍼풀은 아무것도 채워져 있지 않은 상태를 가정한다.

UPDATE <tablename> SET <column_name2> = ‘XXX’ WHERE <column_name1> = YYY;

 

작업 순서는 아래와 같다.

1.        클러스터형 인덱스를 탐색하여 수정할 행이 포함된 페이지에 도달 (암시적 읽기 I/O)

2.        트랜잭션 시작 업데이트를 위한 undo 로그 공간 할당 (데이터베이스 엔진 I/O)

3.        수정 중인 행이 포함된 페이지 업데이트 (사용자 SQL 쿼리 I/O)

4.        트랜잭션 시스템에 undo 로그 기록 (데이터베이스 엔진 I/O)

5.        트랜잭션 커밋 (데이터베이스 엔진 I/O)

 

예에서는 암시적 I/O 작업이 여러 있지만 쓰기 작업의 일부 또는 전체를 단일 쓰기 I/O 일괄 처리할 있다. 또한 쓰기 작업임에도 불구하고 읽기 I/O 여전히 필요했다. 마지막으로 주의할 점은 데이터베이스 엔진의 일반적인 트랜잭션 프로세스의 일부인 I/O 작업이 있다는 것이다. 쿼리를 전혀 포함하지 않는 다른 I/O 작업들도 있다. 예를 들어 인덱스 생성이다. 시나리오 에서는 인덱스를 만드는데 필요한 데이터를 읽기 위한 암시적 읽기 I/O 스토리지 볼륨에 인덱스를 쓰기 위한 명시적 I/O 쓰기가 있다.

 

[I/O 모니터링]

Aurora 클러스터로 최적의 I/O 비용을 보장하려면 모니터링부터 시작하는 것이 가장 좋다. Amazon CloudWatch 지표에서 [Billed] Volume Read IPOS (Count) 사용하면 모든 Aurora 인스턴스에 소비하는 초당 읽기 I/O수를 모니터링 있다. [Billed] Volume Write IPOS (Count) 지표는 모든 Aurora 인스턴스에서 소비한 쓰기 IPOS수를 모니터링 있다. 모니터링이 설정되고 평균 읽기 쓰기 I/O 요청 수에 대한 기준이 결정되면 CloudWatch 경고 알림을 설정하여 I/O 사용량이 급증하는 경우 알림을 받을 있다.

 

[MySQL 관련 고려 사항]

Aurora 클러스터의 쓰기 노드와 읽기 노드 간의 복제에는 추가 I/O 필요하지 않다. 그러나 일부 사용 사례에서는 binlog 활성화 하여 Aurora외부의 대상으로 복제 해야 수도 있다. Aurora MySQL에서 binlog 활성화하면 트랜잭션에 대해 쓰기 I/O 요청이 하나 이상 증가하고 내부 binlog 구조를 유지하기 위해 추가 쓰기 I/O 필요할 있다. 사용자가 binlog 읽을 추가 읽기  I/O 발생한다.

 

느린 쿼리 로그를 활성화 하여 장기 실행 쿼리를 캡처하는 것은 최적화 해야 하는 쿼리를 찾는데 유용한 방법일 있다. 또는 성능 스키마 개체를 사용하여 많은 행을 처리하거나 성능 조정이 필요한 SQL 쿼리 목록을 가져올 있다.

 

[PostgreSQL 관련 고려 사항]

PostgreSQL에서 테이블의 행은 튜플로 유지된다. 행이 삭제될 해당 행을 나타내는 튜플은 물리적으로 제거되지 않는다. 단순히 삭제된것으로 표시된다. 또한 업데이트 작업으로 인해 이전 튜플을 삭제된 것으로 표시하고 동일한 행을 나타내기 위해 튜플을 삽입한다. 시간이 지남에 따라 삭제된 튜플의 수가 증가하여 데이터베이스 엔진이 이러한 삭제된 튜플을 통과할 불필요한 I/O 그에 따른 성능 저하가 발생할 있다. Vacuum(진공 청소기) 프로세스는 데드 튜플을 제거한다. PostgreSQL vacuum 프로세스에서 생성되는 여러 유형의 데이터베이스 엔진 읽기 쓰기 I/O 작업이 있다.

 

pgBadger 사용하여 로그를 분석하여 느리게 실행되는 쿼리를 표시할 있으며 pg_stat_statements 비싼 SQL문을 캡처하기 위한 강력한 저수준 도구가 있다. 또한 Aurora PostgreSQL 쿼리 계획 관리를 지원한다. 기능은 계획 안정성과 계획 적응성을 모두 제공한다.

 

주기적으로 테이블 인덱스 확장을 검토하고 적절하게 vacuum 프로세스를 실행하는 것이 가장 좋다. 선호되는 접근 방식은 auto vacuum 활성화하는 것이다. 이는 vacuum 프로세스를 자동화 하고 나은 성능과 낮은 I/O 소비를 제공하는데 도움이 된다.

 

기본적으로 모든 업데이트는 색인된 속성이 수정되지 않은 경우에도 새로 생성된 페이지에 연결하기 위해 새로운 색인 항목을 추가 해야한다. HOT(Heap Only Tuple) 경우 업데이트 튜플 체인을 유지하면서 가능한 경우 이전 튜플과 동일한 페이지에 튜플이 생성된다. 페이지가 생성되지 않았기 때문에 인덱스는 계속해서 동일한 페이지를 가리킬 있으며 수정할 필요가 없다.

 

다음 쿼리는 HOT 업데이트 수를 반환한다. 테이블에 대한 HOT 업데이트 수가 많으면 채우기 비율을 수정하여 향후 일반 또는 HOT 업데이트에 사용하지 않는 데이터 페이지의 추가 디스크 공간을 남길 있다.

select schemaname, relname, n_tup_upd, n_tup_hot_upd from pg_stat_all_tables order by n_tup_upd;

 

 

[Aurora 전용 기능]

Cloning - 복제 기능을 사용하면 Aurora 클러스터의 복사본을 빠르게 생성할 있다. 생성 데이터가 복사되지 않기 때문에 프로세스가 빠르고 I/O 집약적이지 않다. 대신 Aurora 클론은 클론이 생성될 당시 존재했던 페이지가 변경될 페이지를 생성하는 쓰기시점의 복사 메커니즘을 사용한다. 이러한 I/O 작업은 다른 Aurora 클러스터의 I/O 작업과 정확히 동일한 방식으로 작동하고 비용이 청구된다. 변경을 일으킨 클러스터는 I/O 작업이 청구되는 클러스터이다.

Global databases -  Amazon Aurora 글로벌 데이터베이스는 리전간 지연 시간이 짧은 글로벌 읽기 재해복구를 제공한다. Aurora 글로벌 데이터베이스를 사용하면 기본 클러스터에 단일 지역 클러스터와 동일한 방식으로 I/O 비용이 발생한다. 그러나 전역 복제본을 유지 관리하려면 모든 쓰기 I/O 보조 지역으로 전성되고 보조 클러스터에 기록되어야 한다. 하나의 기본 클러스터와 하나의 복제본 클러스터가 있는 시나리오에서 쓰기 I/O 기본 클러스터의 쓰기 I/O 3배이다. (기본 + 전송 + 보조). 읽기 I/O 경우 기본 보조 클러스터의 독립적인 읽기를 기반으로 요금이 청구 된다.

Parallel queries (Aurora MySQL) – Aurora MySQL 병렬 쿼리는 필터링 집계 작업의 대부분을 스토리지 엔진으로 푸시하여 특정 분석 쿼리에 대한 성능 향상을 제공한다. 그러나 병렬 쿼리로 처리된 페이지는 버퍼풀에 저장되지 않는다. 따라서 읽기 I/O 요청이 증가할 있다.

Cluster cache management (Aurora PostgreSQL) – Aurora PostgreSQL 클러스터 캐시 관리 기능은 클러스터에서 기본 장애 조치 노드로 지정된 리더 노드가 작성자와 유사한 버퍼풀을 유지하도록 한다. 이를 통해 장애조치(failover) 기록기의 성능이 향상된다. 리더(Reader) 버퍼풀에서 유사한 페이지 세트를 유지하려면 스토리지 볼륨에서 주기적으로 읽어야 한다. 활동으로 인해 해당 인스턴스에 대한 읽기 I/O활동이 증가한다.

 

[일반적인 모범 사례]

다음은 Aurora에서 I/O 계획할 모범 사례이다.

인덱스 검토

l  모든 인덱스가 쓰기 I/O 볼륨에 추가되므로 사용하지 않는 인덱스를 제거

l  테이블 스캔 또는 기타 높은 I/O 활동을 처리하기 위해 인덱스를 작성

l  기본키의 경우 값에 자동 증가 정수를 사용

l  테이블과 인덱스를 생성할 적절한 채우기 비율을 고려

l  가능하면 커버링 인덱스를 사용

l  특정 쿼리에 대해 분석된 페이지를 최소화 하려면 가능한 경우 파티션을 사용

 

실적이 저조한 쿼리 식별

l  Amazon RDS 성능 개선 도우미와 같은 도구를 사용하여 성능이 낮은 쿼리를 식별

l  I/O 대기가 높은 쿼리의 실행 계획을 검사

l  높은 I/O 대기 쿼리를 다시 작성하거나 이러한 쿼리를 지원하는 적절한 인덱스를 다시 생성

 

하드웨어 고려

l  99.98% 이상의 목표로 버퍼캐시 적중률을 모니터링한다. 측정 단위는 디스크에서 페이지를 읽는 것이 아니라 버퍼풀에서 페이지를 찾는 빈도를 반영한다.

l  버퍼 캐시 적중률이 낮으면 메모리가 많은 인스턴스 유형을 사용하는 것이 좋다.

l  많은 메모리를 제공하는 인스턴스 크기로 확장하면 보고 워크로드에 대한 전체 읽기 I/O 줄어들어 전체 I/O 비용이 감소할 있다.

 

내장된 Aurora 기능 사용

l  높은  I/O 초래할 있는 논리적 내보내기를 사용하는 대신 Aurora 특정시점 복구 기능을 활용한다.

l  전체 데이터베이스를 스캔해야 하는 논리적 내보내기 도구를 사용하는 것과 비교하여 클론을 생성하려면 I/O 필요하지 않다.

 

[목적에 맞게 구축된 데이터베이스]

올바른 작업에 올바른 도구를 사용하는 것이 중요하다. Aurora 처리량이 많은 대규모 병렬 OLTP 시스템으로 설계 되었다. Aurora 초당 수십만개의 쿼리로 수천개의 연결을 처리하는데 탁월하다. 이러한 쿼리는 일반적으로 단일 또는 작은행 집합에서 작동한다. Aurora에는 분석 쿼리와 관련하여 향상된 기능을 제공하는 Aurora MySQL 병렬 쿼리와 같은 특정 기능이 있지만 대규모 테이블 스캔 대규모 집계를 중심으로 설계된 워크로드는 상당한 수의 읽기 IOPS 생성한다. 시나리오에서는 Amazon Redshift, Amazon Athena, S3 Select 또는 Amazon EMR 같은 다른 도구가 이러한 워크로드에 적합할 있다. 마찬가지로 쓰기가 많고 읽기가 거의 없는 로그 중심의 워크로드의 경우 Amazon Kinesis Data Firehose 같은 도구를 Amazon Simple Storage Service(Amazon S3) 함께 사용하는 것이 가장 적합할 있다.

 

 

[참고자료]

l  https://dataintegration.info/planning-i-o-in-amazon-aurora

 

 

 

2022-03-20 / Sungwook Kang / http://sungwookkang.com

 

 

AWS RDS, MySQL, Aurora, RDS Aurora, Aurora MySQL, Aurora Storage, Aurora PostgreSQL, Aurora I/O Plan, 오로라 읽기 쓰기 계획, 오로라 스토리지 계획, 오로라 활용

[AWS Aurora] Aurora Storage Engine

 

l  Version : Aurora

 

Amazon Aurora 스토리지 엔진은 지역의 여러 AWS 가용 영역(AZ) 걸쳐 있는 분산 SAN 이다. AZ 물리적 데이터센터로 구성된 논리적 데이터센터 이다. AZ 해당 지역의 다른 AZ 빠른 통신을 허용하는 짧은 지연 시간 링크를 제외하고 다른 AZ 격리되어 있다. Amazon Aurora 중심에 있는 분산형 저지연 스토리지 엔진은 AZ 의존한다.

 

Amazon Aurora 현재 보호 그룹이라고 하는 10GB 논리 블록에 스토리지 볼륨을 구축한다. 보호 그룹의 데이터는 6개의 스토리지 노드에 복제된다. 그런 다음 이러한 스토리지 노드는 Amazon Aurora 클러스터가 있는 리전의 3 AZ 할당된다.

클러스터가 생성될 때에는 매우 적은 양의 스토리지를 사용한다. 데이터 볼륨이 증가하고 현재 할당된 스토리지를 초과하면 Aurora 수요를 충족하도록 볼륨을 원활하게 확장하고 필요에 따라 보호 그룹을 추가한다. Amazon Aurora 현재 64TB 도달할 때까지 이러한 방식으로 계속 확장된다.

 

Amazon Aurora에서 데이터를 쓰기가 발생하면 6개의 스토리지 노드에 병렬로 전송된다. 이러한 스토리지 노드는 3개의 가용 영역에 분산되어 있어 내구성과 가용성이 크게 향상된다. 스토리지 노드에서는 레코드는 먼저 메모리 대기열에 들어간다. 대기열의 로그 레코드는 중복 제거된다. 예를 들어, 마스터 노드가 스토리지 노드에 성공적으로 쓰기 작업을 했으나 마스터와 스토리지 노드 간의 연결이 끊긴 경우 마스터 노드는 로그 기록을 재전송하지만 중복된 로그 기록은 폐기한다. 유지해야하는 기록은 로그의 디스크에 저장된다.

 

레코드가 지속되면 로그 레코드는 업데이트 대기열이라는 메모리 구조에 기록된다. 업데이트 대기열에서 로그 레코드는 먼저 병합된 다음 데이터 페이지를 만드는데 사용된다. 하나 이상의 LSN(Log Sequence Number) 누락된 것으로 확인되면 스토리지 노드는 프로토콜을 사용하여 볼륨의 다른 노드에서 누락된 LSN 검색한다. 데이터페이지가 업데이트되면 로그 레코드가 백업되고 가비지 수집용으로 표시된다. 그런 다음 페이지는 Amazon S3 비동기식으로 백업 된다. 쓰기가 로그에 기록되어 지속 가능하게 되면 스토리지 노드는 데이터 수신을 확인한다. 6개의 스토리지 노드 4 이상이 수신을 확인하면 쓰기가 성공한 것으로 간주되고 클라이언트 애플리케이션에게 성공을 반환한다.

 

Amazon Aurora 다른 엔진보다 훨씬 빠르게 있는 이유 하나는 로그 레코드를 스토리지 노드에만 보내고 이러한 쓰기가 병렬로 수행되기 때문이다 실제로 Amazon Aurora 데이터가 6개의 다른 노드에 기록되고 있음에도 불구하고 평균적으로 MySQL 비교하여 유사한 워크로드에 대해 1/8 IOPS 필요한다. 프로세스의 모든 단계는 비동기 방식이다. 쓰기는 그룹 커밋을 사용하여 병렬로 수행되어 대기 시간을 줄이고 처리량을 향상 시킨다. 쓰기 지연 시간이 짧고 I/O 풋프린트가 감소한 Aurora 쓰기 집약적인 애플리케이션에 이상적이다.

 

아래 다이어그램은 3개의 AZ 저장된 데이터를 보여준다 복제된 데이터는 99.999999999% 내구성을 제공하도록 설계된 S3 지속적으로 백업 된다.

 

설계를 통해 Amazon Aurora 클라이언트 애플리케이션에 대한 가용성 영향 없이 전체 AZ 또는 2개의 스토리지 노드 손실을 견딜 있다.

 

 

복구 중에 Aurora 데이터 손실 없이 보호 그룹에 있는 AZ 다른 스토리지 노드의 손실을 유지하도록 설계 되었다. 이는 보호 그룹에 있는 4개의 스토리지 노드에 지속된 경우에만 Aurora에서 쓰기가 지속되기 때문이다. 쓰기를 수신한 3개의 스토리지 노드가 다운 되더라도 Aurora 여전히 4번째 스토리지 노드에서 쓰기를 복구 있다. 복구 읽기 쿼럼을 달성하기 위해 Aurora 3개의 스토리지 노드가 동일한 LSN 따라 잡는지 확인한다. 그러나 쓰기를 위해서 볼륨을 열기 위해 Aurora 향후 쓰기를 위한 쓰기 쿼럼을 달성할 있도록 4개의 스토리지 노드가 복구될 때까지 기다려야 한다.

 

읽기의 경우 Aurora 읽기를 수행할 갖아 가까운 스토리지 노드를 찾으려고 한다. 읽기 요청은 타임스탬프, LSN 연결된다. 스토리지 노드는 LSN 도달한 경우 (해당 LSN까지의 모든 업데이트를 수신한 경우) 읽기를 수행할 있다. 하나이상의 스토리지 노드가 다운되거나 다른 스토리지 노드와 통신할 없는 경우 해당 노드는 가십 프로토콜을 사용하여 온라인 상태가 자신을 재동기화 한다. 스토리지 노드가 손실되고 자리를 대신할 노드가 자동으로 생성되는 경우에도 가십 프로토콜을 통해 동기화 된다.

 

Amazon Aurora 사용하면 컴퓨팅과 스토리지가 분리된다. 이를 통해 Aurora 복제본은 복제본 자체의 데이터를 유지하지 않고도 스토리지 계층에 대한 컴퓨팅 인터페이스 역할을 있다. 이렇게 하면 데이터를 동기화할 필요 없이 인스턴스가 온라인 상태가 되는 즉시 Aurora 복제본이 트래픽 제공을 시작할 있다. 마찬가지로 Aurora 복제본의 손실은 기본 데이터에 영향을 미치지 않는다 Aurora 복제본이 마스터 노드가 되면 데이터 손실이 없다. 최대 15개의 Aurora 복제본을 지원하고 로드 밸런싱하기 때문에 Aurora 고가용성, 읽기 집약적 워크로드에 적합하다.

 

Aurora 성능에 영향없이 특정 시점에 대한 클러스터의 데이터 스냅샷을 생성할 있다. 또한 백업에서 복원할 10GB보호 그룹은 병렬로 복원한다. 또한 보호 그룹이 복원된 에는 로그를 다시 적용할 필요가 없다. , 보호 그룹이 복원되는 즉시 Amazon Aurora 최고 성능으로 작동할 있다.

Aurora AES-256 암호화를 사용하여 모든 저장 데이터를 암호화 있다. 사용자는 AWS Key Management Service (AWS KMS) 사용하여 키를 관리 수도 있다. 또한 TLS 연결을 통해 전송 중인 데이터를 보호할 있다.  

 

[참고자료]

l  https://aws.amazon.com/ko/blogs/database/introducing-the-aurora-storage-engine/

l  https://www.percona.com/blog/2016/05/26/aws-aurora-benchmarking-part-2/

l  https://blog.acolyer.org/2019/03/25/amazon-aurora-design-considerations-for-high-throughput-cloud-native-relational-databases/

l  https://www.slideshare.net/AmazonWebServices/amazon-aurora-storage-demystified-how-it-all-works-dat363-aws-reinvent-2018

 

 

 

2022-03-19 / Sungwook Kang / http://sungwookkang.com

 

 

AWS RDS, MySQL, AWS Aurora, RDS Aurora, MySQL Aurora, Aurora Storage, Storage Node

[AWS RDS MySQL] RDS MySQL Aurora MySQL 차이점

 

l  Version : 

 

AWS에서 관리형 관계형 데이터베이스를 보면 RDS MySQL Aurora MySQL 있다. 서비스의 차이점은 무엇일까? 결론부터 말하면 기존의 MySQL 소스를 기반으로 AWS 에서 커스터마이징 하여 만든 것이 Aurora이며   서비스는 스토리지 메커니즘이 다르다.

 

AWS RDS MySQL

RDS 플랫폼은 기존 데이터베이스 아키텍처를 중심으로 완전히 관리되는 추상화 계층을 제공한다. RDS 내에서 데이터베이스 플랫폼은 EC2에서 수동으로 수행하는 것처럼 구축된다. EC2인스턴스는 적절한 Amazon Machine Image (AMI)에서 프로비저닝 되고, EBS(Elastic Block Store)스토리지는 프로비저닝된 인스턴스에 연결된다. 그리고 적절한 서브넷 그룹과 보안그룹이 인스턴스에 연결되는 구조이다. RDS 몇번의 버튼 클릭만으로 데이터베이스 플랫폼을 안전하고 성능있는 방식으로 프로비저닝 있다. 프로비저닝되면 RDS 백업/복원 패치가 모두 자동으로 처리되어 플랫폼 유지관리가 자동으로 이루어진다. 아래는 RDS MySQL 특징 가지를 정리한 것이다.

l  트랜잭션 로그 데이터베이스 데이터 파일은 로컬 EBS 스토리지 볼륨 사용

l  데이터베이스의 모든 커밋된 트랜잭션 I/O WAL(Write-Ahead Log)이라고 하는 전후 이미지가 있는 로그 레코드를 생성한 지속가능한 스토리지로 저장

l  체크포인트 작업은 수정된 페이지를 디스크로 플러시하여 수행

l  EC2 인스턴스에 생성되기 때문에 I/O 대역폭 IOPS 인해 성능이 제한됨

l  튜닝에는 I/O 대역폭을 늘리거나 I/O 수를 줄여야

 

 

AWS Aurora MySQL

Aurora 플랫폼은 AWS만의 관계형 데이터베이스로써 기존의 소스를 커스터마이징하여 AWS 최적화 시킨 것이 특징이다. 기존 RDS 모든 관리 기능 뿐만 아니라 데이터베이스에 최적화된 스토리지 하위 시스템을 제공하여 RDS 플랫폼을 확장한다. RDS에서 사용하는 EBS 스토리지 대신 NVMe SSD 드라이브 위에 구축되어 훨씬 빠른 성능 이점을 제공한다. 아래는 Aurora 특징 가지를 정리한 것이다.

l  애플리케이션에 따라 자동으로 확장

l  6개의 데이터 복사본을 만들어 여러 위치에 배포하고 Amazon S3 지속적으로 백업

l  99.99% 이상의 가용성 제공

l  스토리지 장애로부터 투명하게 복구

l  일반 적으로 30 미만의 인스턴스 장애조치 허용

l  이전 시점으로 빠르게 복구할 있는 기능 제공

 

Aurora 빠른 로컬 성능 재해 복구를 위해 여러 지역에 데이터를 복제하고 컴퓨팅 스토리지 작업을 분리하여 I/O병목현상을 줄인다. 로컬 스토리지에 대한 체크포인트 작업으로 데이터베이스 인스턴스에 부담을 주신 대신 Aurora 지속적인 체크포인트를 위해 분산 스토리지 플릿을 사용한다. 분산 스토리지 플릿은 Aurora 처리량 측면에서 표준 MySQL 능가하는데 도움이 되며 가용성과 내구성도 향상된다.

 

아래 그림을 보면 MySQL 경우 로컬 EBS 데이터를 저장하고 저장된 EBS 미러링한 다음 Replication 통해 Replica instance 보내 복제 DB 로컬 EBS 다시 저장한다. Aurora 경우 4/6 쿼럼을 사용하여 스토리지에 저장하고 스토리지 레벨에서 복제가 발생한다.

 

 

 

 

Aurora 다른 특징은 교차 리전 복제(Cross Region Replication, CRR)이다. 리전당 3개의 가용 영역, 6개의 복제본이 제공된다. Write 작업은 Primary 인스턴스에서 수행되고 로그 레코드가 Replica 인스턴스로 전달된다.

 

 

 

[참고자료]

l  https://d1.awsstatic.com/events/reinvent/2019/REPEAT_Amazon_Aurora_storage_demystified_How_it_all_works_DAT309-R.pdf

l  https://aws.amazon.com/ko/blogs/database/amazon-aurora-as-an-alternative-to-oracle-rac/

 

2022-03-18 / Sungwook Kang / http://sungwookkang.com

 

AWS RDS, MySQL, AWS Aurora, RDS Aurora, MySQL Aurora

[AWS RDS MySQL] InnoDB cache warming

-          버퍼풀 정보를 저장하고 시작시 로드하여 워밍업 단계 생략하기

 

l  Version : AWS RDS MySQL 5.6 later

 

InnoDB cache warming(캐시워밍) DB 인스턴스가 종료될 버퍼 풀의 현재 상태를 저장한 다음 DB 인스턴스가 시작될 저장된 버퍼 정보를 다시 로드하여 MySQL DB 인스턴스에 대한 성능 향상을 제공할 있다. 뜻은 정상적인 데이터베이스 사용에서 버퍼풀의 워밍업 필요를 무시하고 대신 알려진 공통 쿼리에 대한 페이지로 버퍼풀을 미리 로드한다. 버퍼풀 정보를 저장하는 파일은 페이지 자체가 아니라 버퍼풀에 있는 페이지에 대한 메타데이터만 저장한다. 따라서 결과적으로 파일에 많은 저장공간이 필요하지 않다. 파일크기는 캐시 크기의 0.2% 정도이다. 예를들어 64GB캐시의 경우 캐시 워밍업 파일은 128MB이다. 캐시워밍에 대한 자세한 내용은 MySQL 공식 문서인 아래 링크에서 확인할 있다.

l  Saving and Restoring the Buffer Pool State : https://dev.mysql.com/doc/refman/8.0/en/innodb-preload-buffer-pool.html

 

AWS RDS에서는 MySQL 5.6 버전 이상에 대해서 InnoDB 캐시 워밍업을 지원한다. InnoDB 캐시 워밍업을 활성화 하려면 DB 인스턴스의 파라미터 그룹에서 innodb_buffer_pool_dump_at_shutdown,  innodb_buffer_pool_load_at_startup 파라미터를 1 설정해야 한다. 해당 파라미터 값을 변경하면 해당 파라미터 그룹을 사용하는 모든 MySQL DB 인스턴스에 영향이 있기 때문의 사용시 주의하도록 한다. 특정 MySQL 대해서만 InnoDB 캐시 워밍업을 활성화 하려면 해당 인스턴스에 대한 파라미터 그룹을 생성 하도록 한다.

 

InnoDB 캐시 워밍은 주로 표준 스토리지를 사용하는 DB 인스턴스에 대한 성능 이점을 제공한다. PIOPS 스토리지를 사용하는 경우 일반적으로 상당한 성능 이점이 나타나지 않는다. InnoDB 캐시 워밍을 활성화 하였더라도 장애 조치중과 같이 MySQL DB 인스턴스가 정상적으로 종료되지 않으면 버퍼풀 상태가 디스크에 저장되지 않는다. 경우 MySQL DB 인스턴스가 다시 시작될 사용 가능한 모든 버퍼 파일을 로드 한다. 이런 경우에도 데이터베이스에는 아무런 이상이 없지만 복원된 버퍼풀은 가장 최근의 상태를 반영하지 않을 수도 있다. 시작 InnoDB 캐시를 워밍업 하는데 사용할 있는 버퍼풀의 최신 상태를 사용하려면 주기적으로 버퍼풀을 덤프하는 것이 좋다.

버퍼풀의 현재 상태를 디스크에 저장하려면 아래 프로시저를 호출 한다.

CALL mysql.rds_innodb_buffer_pool_dump_now();

 

디스크에 저장된 버퍼풀의 상태를 로드하려면 아래 프로시저를 호출 한다.

CALL mysql.rds_innodb_buffer_pool_load_now();

 

진행중인 로드 작업을 취소하려면 아래 프로시저를 호출 한다.

CALL mysql.rds_innodb_buffer_pool_load_abort();

 

버퍼풀을 주기적으로 자동으로 덤프하는 이벤트를 생성하여 사용할 경우 수동으로 매번 호출할 필요가 없다. 아래 스크립트는 매시간 버퍼풀을 덤프하는 periodic_buffer_pool_dump라는 이벤트를 생성한다.

CREATE EVENT periodic_buffer_pool_dump
ON SCHEDULE EVERY 1 HOUR
DO CALL mysql.rds_innodb_buffer_pool_dump_now();

 

 

[참고자료]

l  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html#MySQL.Concepts.VersionMgmt

l  https://dev.mysql.com/doc/refman/8.0/en/innodb-preload-buffer-pool.html

l  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_innodb_buffer_pool_dump_now.html

l  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_innodb_buffer_pool_load_now.html

l  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql_rds_innodb_buffer_pool_load_abort.html

 

 

 

2022-03-17 / Sungwook Kang / http://sungwookkang.com

 

 

AWS RDS, MySQL, InnoDB Cache warming, 캐시워밍업, 버퍼풀, buffer pool

+ Recent posts