Data Science Lab

[AWS Aurora] Aurora Parallel Query 활성화 방법 및 특징

l  Version : AWS Aurora

Amazon Aurora MySQL 병렬 쿼리는 데이터 집약적인 쿼리 처리에 수반되는 I/O 및 컴퓨팅의 일부를 병렬화 하는 최적화 작업이다. 병렬화되는 작업은 스토리지로부터 행 검색, 열 값 추출, 어떤 행이 WHERE 절 및 JOIN절의 조건과 일치하는지 판단한다. 데이터 집약적인 작업은 Aurora 분산 스토리지 계층의 여러 노드에 위임(푸시다운)되고 병렬 쿼리가 없으면 각 쿼리가 스캔한 모든 데이터를 Aurora MySQL 클러스터(헤드노드)내의 단일 노드로 가져오고 거기에서 모든 쿼리 처리를 수행한다. 병렬 쿼리 기능을 설정하면 Aurora MySQL 엔진이 힌트 또는 테이블 속성과 같은 SQL의 변경 필요 없이 쿼리에 따라 자동으로 병렬화 여부를 판단한다.

데이터베이스를 생성할 때 [Engine Version]에서 [Hide filters]를 확장하여 parallel query 기능을 활성화할 수 있다.

기본적으로, 병렬 쿼리를 사용하지 않을 경우 Aurora 쿼리에 대한 처리는 원시 데이터를 Aurora 클러스터 내 단일 노드(헤드 노드)로 전송한다. 그런 다음 Aurora는 해당 단일 노드의 단일 스레드에서 해당 쿼리에 대해 추가되는 모든 처리를 수행한다. 병렬 쿼리를 사용할 경우, 이러한 I/O 집약적이고 CPU 집약적인 작업의 대부분이 스토리지 계층의 노드로 위임된다. 행은 이미 필터링되고 열 값은 이미 추출되어 전송된 상태로, 결과 집합의 간소화된 행만 다시 헤드 노드로 전송된다. 성능 혜택은 네트워크 트래픽의 감소, 헤드 노드에서 CPU 사용량의 감소, 및 스토리지 노드 전체에서 I/O 병렬화로부터 비롯된다. 병렬 I/O, 필터링 및 프로젝션의 양은 쿼리를 실행하는 Aurora 클러스터의 DB 인스턴스 수와 무관하다.

아래는 위에서 설명한 병렬 쿼리 사용의 장점을 목록으로 정리한 것이다.

l  여러 스토리 노드에 걸친 물리적 읽기 요청을 병렬화 하여 I/O 성능 개선

l  네트워크 트래픽 감소 : Aurora는 전체 데이터 페이지를 스토리지 노드로부터 헤드 노드로 전송한 다음 그 후에 불필요한 행과 열을 필터링 하지 않고 결과 집합에 필요한 열 값만 포함된 간소화된 튜플을 전송한다.

l  푸시 다운, 행 필터링 및 WHERE 절에 대한 열 프로젝션으로 인한 헤드 노드에 대한 CPU 사용량 감소.

l  버퍼 풀에서의 메모리 압력 감소 : 병렬 쿼리에 의해 처리된 페이지는 버퍼풀에 추가되지 않으므로 데이터 집약적인 스캔 중 버퍼 풀에서 자주 사용되는 데이터가 제거될 가능성이 감소.

l  기존 데이터에 대한 장기 실행 분석 쿼리 수행이 유용해진 덕분에 추출, 변환, 로드(ETL) 파이프라인에서 데이터 중복의 잠재적 감소.

Aurora MySQL에서 병렬 쿼리를 사용하기 위해서는 몇 가지 사전 조건 및 제한 사항이 있다. 해당 내용은 버전에 따라 지원되는 내용이 다르고, 향후 버전 업데이트에 따라 변경될 가능성이 크기 때문에 자세한 내용은 아래 링크의 내용을 직접 참고한다.

l  Amazon Parallel Query  : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-parallel-query.html

Aurora MySQL 3 버전 부터는 해시조인(Hash Join)이 기본적으로 설정되어 있다. optimizer_switch 구성 설정의 block_nested_loop 플래그를 사용하여 설정을 비활성화 할 수 있다. Aurora MySQL 3버전에서는 Aurora_disable_hash_join 옵션은 사용되지 않는다.

Aurora MySQL 1.23 또는 2.09 이상 버전에서는 병렬 쿼리 및 해시 조인 설정이 기본적으로 해제되어 있다. 이 부분을 활성화하기 위해서는 클러스터 구성 파라메터 aurora_disable_hash_join=OFF로 설정한다.

버전 1.23 이전의 Aurora MySQL 5.6 호환 클러스터의 경우 해시 조인은 병렬 쿼리 클러스터에서 항상 사용할 수 있다. 이 경우 해시 조인 기능에 대해 어떤 작업도 수행할 필요가 없다. 이러한 클러스터를 버전 1 또는 버전 2의 상위 릴리스로 업그레이드하는 경우 해시 조인도 설정해야 한다.

병렬 쿼리를 사용하려면 테이블 속성이 ROW_FORMAT=Compact 또는 ROW_FORMAT=Dynammic 설정을 사용해야하기 때문에 INNODB_FILE_FORMAT 구성 옵션에 대한 변경 사항이 있는지 확인해야한다. 옵션을 변경할 때에는 항상 변경 전후에 대한 성능 문제가 발생할 수 있으므로 반드시 워크로드 테스트를 진행할 수 있도록 한다.

앞에서도 언급하였지만 병렬 쿼리를 이용하기 위해 어떤 특별한 조치를 수행할 필요는 없다. 필수적 요구사항을 충족한 후에는 쿼리 옵티마이저가 각 특정 쿼리에 대하여 병렬 쿼리를 사용할지 여부를 자동으로 결정하기 때문이다. 쿼리가 실행될 때 병렬 쿼리로 실행되었는지 유무는 EXPLAIN 명령을 실행하여 실행계획을 통해 확인할 수 있다.

아래 예시는 해시 조인이 설정되어 있지만 병렬 쿼리가 해제되어 있어 병렬 쿼리가 아닌 해시 조인으로 실행계획이 표시되었다.

병렬 쿼리가 설정된 후에는 해시 조인 실행 시 parallel query 라고 표시된 것을 확인할 수 있다.

Aurora MySQL 클러스터가 병렬 쿼리를 실행할 때 버퍼풀을 사용하지 않기 때문에 VolumeReadIOPS 값이 증가할 수 있다. 따라서 쿼리는 빠르기 실행되지만 이렇게 최적화된 프로세싱은 읽기 작업 및 관련 비용을 증가시킬 수 있다. 병렬 쿼리 모니터링에 대한 카운터는 아래 링크에서 “병렬 쿼리 모니터링” 섹션을 참고할 수 있도록 한다. 카운터는 DB 인스턴스 수준에서 추적된다. 서로 다른 엔드포인트로 연결된 경우 각 DB 인스턴스가 자체의 고유한 병렬 쿼리 집합을 실행하기 때문에 사로 다른 지표가 표시될 수도 있다. 또한 리더 엔드포인트가 각 세션마다 서로 다른 DB 인스턴스에 연결된 경우에도 서로 다른 지표가 표시될 수도 있다.

l  Amazon Parallel Query  : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-parallel-query.html

병렬 쿼리는 InnoDB 테이블에만 적용된다. Aurora MySQL에서는 임시 테이블 사용시, 임시 저장소로 MyISAM을 사용하기 때문에 임시 테이블을 포함하는 내부 쿼리 단계에서는 병렬쿼리를 사용하지 않는다. 그리고 실행 계획으로는 Using temporary라고 표시된다.

(MySQL 8.0 부터는 임시 테이블이 디스크에 저장될 때 InnoDB 스토리지를 사용하도록 개선되어 있다.)

[참고자료]

l  Amazon Parallel Query  : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-parallel-query.html

l  https://aws.amazon.com/blogs/aws/new-parallel-query-for-amazon-aurora/

2022-07-25 / Sungwook Kang / http://sungwookkang.com

AWS, Aurora, Aurora Parallel Query, 오로라 병렬처리, 병렬 쿼리, Aurora Optimize, 오로라 최적화

[AWS Aurora] Aurora Global Database를 사용한 Cross-Region 장애조치

l  Version : AWS Aurora

Amazon Aurora Global Database는 여러 AWS 리전에 걸쳐 있고 대기 시간이 짧은 글로벌 읽기를 지원하기 때문에, 전세계 지역에서 실행되는 애플리케이션들은 가까운 리전의 Aurora Global Database에서 서비스를 제공받기 때문에 안정적이며 빠른 서비스를 제공할 수 있다. 또한 Aurora Global Database는 데이터를 마스터링하는 하나의 기본 AWS 리전 및 최대 5개의 읽기 전용 보조 AWS 리전으로 구성되기 때문에, AWS 리전에서 장애 발생시 신속하게 다른 리전으로 복구할 수 있다.  Aurora Global Database는 아래와 같은 장점을 가지고 있다.

l  로컬 대기 시간으로 글로벌 읽기 : 전 세계에 지사를 두고 있는 경우, Aurora Global Database를 사용하여 기본 AWS 리전에서 정보의 주요 소스를 최신 상태로 유지할 수 있다. 다른 리전의 사무실은 로컬 지연 시간을 사용하여 해당 리전의 정보에 액세스할 수 있다.

l  확장 가능한 보조 Aurora DB 클러스터 : AWS 리전에 읽기 전용 인스턴스(Aurora 복제본)를 추가하여 보조 클러스터를 확장할 수 있다. 세컨더리 클러스터는 읽기 전용이므로 단일 Aurora 클러스터에 대하여 일반적인 제한인 15개가 아닌 최대 16개의 읽기 전용 Aurora 복제본 인스턴스를 지원할 수 있다.

l  기본 DB클러스터에서 보조 Aurora DB 클러스터로의 빠른 복제 : Aurora Global Database에서 수행되는 복제는 기본 DB 클러스터의 성능에 거의 영향을 미치지 않는다. DB 인스턴스의 리소스는 애플리케이션 읽기/쓰기 워크로드 처리 전용이다.

l  리전 전체의 운영 중단으로부터 복구 : 보조 클러스터를 사용하면 기존 복제 솔루션보다 적은 데이터 손실(더 낮은 RPO)로 새로운 기본 AWS 리전에서 Aurora Global Database를 보다 신속하게(더 낮은 RTO) 가용 상태로 만들 수 있다.

Aurora Global Database는 한 리전의 기본(Primary) Aurora 클러스터와 다른 리전의 보조(Secondary) Aurora 클러스터로 생성된다. Aurora 글로벌 데이터베이스는 Aurora 전용 스토리지 계층의 전용 인프라를 사용하여 리전 간 복제를 처리한다. 스토리지 계층의 전용 복제 서버가 복제를 처리하므로 시스템 로드 중에도 데이터베이스 성능을 저하시키지 않으면서 향상된 복구 및 가용성 목표를 달성할 수 있다. Aurora Global Database는 물리적 스토리지 수준 복제를 사용하여 동일한 데이터 세트로 기본 데이터베이스의 복제본을 생성하므로 논리적 복제 프로세스에 대한 종속성이 제거된다. 아래 그림은 기본(Primary) 및 보조(Secondary) 리전에 걸쳐 있는 Aurora 클러스터가 있는 Aurora 글로벌 데이터베이스이다.

Aurora Global Database복제과정은 아래와 같다.

1.       Aurora 클러스터의 기본 인스턴스는 Primary 리전의 스토리지 노드, 복제본 인스턴스 및 복제 서버에 병렬로 로그 레코드를 보낸다.

2.       Primary 리전의 복제 서버는 로그 레코드를 Secondary 리전의 복제 에이전트로 스트리밍한다.

3.       복제 에이전트는 Secondary 리전의 스토리지 노드 및 복제본 인스턴스에 병렬로 로그 레코드를 보낸다.

4.       Secondary 리전의 복제 서버는 스토리지 노드에서 로그 레코드를 가져와 동기화 한다.

Aurora 스토리지 시스템은 단일 리전 내의 3개 가용 영역에 걸쳐 6개의 데이터 복사본을 자동으로 유지 관리하고 데이터 손실 없이 정상적인 가용 영역에서 데이터베이스 복구를 자동으로 시도하므로 내구성과 가용성이 크게 향상된다. 쓰기 쿼럼은 6개 복사본 중 4개의 승인이 필요하고 읽기 쿼럼은 보호 그룹의 6개 구성원 중 3개이다. 데이터는 최종 사용자에 대한 성능 영향 없이 실시간으로 Aurora를 사용하여 Amazon Simple Storage Service(Amazon S3)에 지속적으로 백업된다.

아래 그림은 기본 리전에서 여러 보조 리전으로 물리적 스토리지 수준 아웃바운드 복제가 있는 Aurora 글로벌 데이터베이스를 나타낸다.

Aurora 글로벌 데이터베이스를 사용하여 각 보조 리전에서 최대 5개의 보조 리전과 최대 16개의 읽기 전용 복제본을 구성할 수 있다. 각 보조 클러스터는 기본 클러스터 및 다른 보조 클러스터와 다른 리전에 있어야 한다.

Aurora 글로벌 데이터베이스를 사용하면 장애조치에 대한 두 가지 접근 방식 중에서 선택할 수 있다.

l  관리형 계획 장애조치 : 기본 DB 클러스터를 Aurora 글로벌 데이터베이스의 보조 리전 중 하나로 재배치 한다. 이 기능을 사용하면 RPO가 0(데이터 손실 없음)이고 다른 변경을 수행하기 전에 보조 DB 클러스터를 기본 클러스터와 동기화한다. 이 자동화된 프로세스의 RTO는 일반적으로 수동 장애조치의 RTO보다 적다.

l  계획되지 않은 수동 장애조치 : 계획되지 않은 중단에서 복구하기 위해 Aurora 글로벌 데이터베이스의 보조 데이터베이스 중 하나로 교차 리전 장애조치를 수동으로 수행할 수 있다. 이 수동 프로세스의 RTO는 계획되지 않은 중단에서 Aurora 글로벌 데이터베이스를 얼마나 빨리 수동으로 복구할 수 있는지에 따라 다르다. RPO는 일반적으로 초 단위로 측정되지만 오류 발생 시 네트워크 전체의 Aurora 스토리지 복제 지연에 따라 다르다.

 Aurora Global Database사용시 수동 장애조치가 어떻게 이루어지는지 살펴보자.

기본 리전에서 Writer 인스턴스에서 읽기 및 쓰기를 수행하고 읽기 전용 복제본에서만 읽기를 수행하는 Aurora 클러스터에 연결된 애플리케이션과 보조 리전에서 읽기 전용 복제본에서 읽기만 수행하는 Aurora 클러스터에 연결된 애플리케이션이 있다. Amazon Route 53 (CNAME 레코드)은 장애조치 및 재구성으로 인해 애플리케이션을 다시 연결하기 위해 수행해야 하는 수동 작업의 양을 최소화하기 위해 Aurora 리더 및 라이터 엔드포인트를 가리키도록 생성된다.

전체 지역의 인프라 또는 서비스를 기본 지역에서 사용할 수 없게 되거나, 잠재적은 성능 저하 또는 격리 문제가 발생할 경우, 보조 클러스터를 기본 클러스터로 승격하도록 수동으로 장애조치를 시작하거나 스크립트를 작성할 수 있다. 장애조치 시 RPO에 의해 수량화된 잠재적 데이터 손실을 이해할 수 있어야 한다.

장애조치가 완료되면 승격된 리전(이전 보조 리전)이 새로운 기본 Aurora 클러스터 역할을 하며 1분 이내에 전체 읽기 및 쓰기 워크로드를 처리할 수 있으므로 애플리케이션 가동 시간에 대한 영향이 최소화된다. 이전 기본 리전의 인프라 또는 서비스를 사용할 수 있게 되거나 리전을 추가하면 계획되지 않은 중단 중에 애플리케이션에서 읽기 워크로드만 가져오는 새로운 보조 Aurora 클러스터 역할을 할 수 있다.

[참고자료]

l  Amazon Aurora Global Database  : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html

l  Cross-Region disaster recovery using Amazon Aurora Global Database for Amazon Aurora PostgreSQL : https://aws.amazon.com/blogs/database/cross-region-disaster-recovery-using-amazon-aurora-global-database-for-amazon-aurora-postgresql/

2022-07-24 / Sungwook Kang / http://sungwookkang.com

AWS, Aurora, Aurora Global Database, Cross-Region Replication, 오로라 글로벌 데이터베이스, 글로벌 장애조치

[AWS Aurora] Aurora 스토리지 특징 요약

l  Version : AWS Aurora

Amazon Aurora 스토리지는 SSD(Solid State Drive)를 사용하는 단일 가상 볼륨인 클러스터 볼륨에 저장된다. 클러스터 볼륨은 동일한 AWS 리전에 속한 세 가용 영역의 데이터 사본으로 구성되어 있다.

l  Aurora Storage Engine : https://sungwookkang.com/1488

가용 영역에서 데이터는 자동으로 복제되기 때문에 디스크 결함으로 인한 데이터 손실 가능성을 최소화 한다. 또한 클러스터 볼륨을 구성하는 디스크 볼륨에서 장애를 자동으로 감지한다. 예를 들어 볼륨 세그먼트에 결함이 발생하면 Aurora가 즉시 해당 세그먼트를 복구한다. Aurora가 디스크 세그먼트를 복구할 때는 동일한 클러스터 볼륨을 구성하는 나머지 디스크 볼륨의 데이터를 사용하기 때문에 복구 세그먼트의 데이터도 이용 가능하다. 결과적으로 Aurora는 데이터 손실을 방지할 뿐만 아니라 특정 시점으로 복구 기능을 사용해 디스크 결함을 복구할 필요성도 줄어든다. 복제 양은 클러스터의 DB 인스턴스 수와 관계없다.

Aurora 클러스터 볼륨에는 모든 사용자 데이터, 스키마, 객체, 내부 메타데이터(시스템 테이블, 바이너리 로그 등)가 포함되어 있다. Aurora 공유 스토리지 아키텍처는 데이터를 클러스터의 DB 인스턴스와 독립적으로 만든다. 즉 DB 인스턴스를 추가할 때 새 복사본을 만들지 않으므로 빠르게 추가가 가능하다. 대신에 DB 인스턴스는 이미 모든 데이터를 포함하는 공유 볼륨에 연결된다. 클러스터에서 기본 데이터를 제거하지 않고 클러스터에서 DB 인스턴스를 제거할 수 있다. 전체 클러스터를 삭제하는 경우에만 Aurora가 데이터를 제거한다.

데이터베이스의 용량이 늘어날수록 Aurora 클러스터 볼륨도 자동 확장된다. Aurora 클러스터 볼륨의 최대 크기는 DB 엔진 버전에 따라 128TiB 또는 64TiB까지 확장될 수 있지만 요금은 사용한 공간에 대해서만 청구된다. Aurora 데이터가 제거되면 해당 데이터에 할당된 공간을 재사용 하게 된다. 데이터 제거의 예로는 테이블 삭제 또는 자르기 등이 있다. 이렇게 스토리지 사용량이 자동으로 줄어들면 스토리지 요금을 최소화 할 수 있다. 하지만 이미 할당된 공간이 축소된 것은 아니다.  Aurora MySQL 2.09.0 및 1.23.0, Aurora PostgreSQL 3.3.0 및 2.6.0 부터는 테이블이나 데이터베이스를 삭제하는 등의 방법으로 Aurora 데이터가 제거되면 비슷한 양만큼 할당된 전체 공간이 감소한다.

여기서 주의할 점은 임시테이블의 데이터는 로컬 DB 인스턴스에 저장되며 최대 크기는 사용하는 인스턴스 클래스에 따라 다르다.

Aurora는 전원이 꺼진 데이터베이스를 가동하거나 결함 발생 이후 다시 시작할 때 버퍼 풀 캐시를 워밍한다. 즉 Aurora가 인메모리 페이지 캐시에 저장된 기존 공통 쿼리 페이지를 이용해 버퍼풀을 미리 로드한다. 이 경우 웜업을 우회할 수 있기 때문에 성능이 향상되는 이점이 있다. Aurora 페이지 캐시는 데이터베이스가 아닌 별도 프로세스로 관리되기 때문에 데이터베이스와 상관없이 유지된다.  자세한 내용은 아래 링크를 참고 한다.

l  InnoDB Cache warming : https://sungwookkang.com/1486

[참고자료]

l  Amazon Aurora 스토리지 및 안정성 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.StorageReliability.html

l  InnoDB Cache warming : https://sungwookkang.com/1486

l  Aurora Storage Engine : https://sungwookkang.com/1488

2022-07-11 / Sungwook Kang / http://sungwookkang.com

AWS, Aurora, Aurora Storage, 오로라 스토리지

[AWS Aurora] Aurora DB 클러스터 엔드포인트 연결 종류 4가지

l  Version : AWS Aurora

Amazon Aurora DB Cluster는 하나 이상의 DB 인스턴스와 이 DB 인스턴스의 데이터를 관리하는 클러스터 볼륨으로 구성된다. Aurora 클러스터 볼륨은 다중 가용 영역을 아우르는 가상 데이터베이스 스토리지 볼륨으로 각 가용 영역에는 DB 클러스터 데이터의 사본이 있다.

l  기본 DB 인스턴스 : 읽기 및 쓰기 작업을 지원하고 클러스터 볼륨의 모든 데이터 수정을 실행한다. Aurora DB 클러스터마다 기본 DB 인스턴스가 하나씩 있다.

l  Aurora 복제본 : 기본 DB 인스턴스와 동일한 스토리지 볼륨에 연결되며 읽기 작업만 지원한다. 각 Aurora DB 클러스터는 기본 DB 인스턴스에 대해 최대 15개 까지의 Aurora 복제본을 구성할 수 있다. Aurora DB 기본 인스턴스를 사용할 수 없는 경우 자동으로 Aurora 복제본으로 자동 장애조치 한다.

 Amazon Aurora는 일반적으로 단일 인스턴스 대신에 DB 인스턴스 클러스터와 관련된다. 각 연결은 특정 DB 인스턴스에서 처리한다. Aurora 클러스터에 연결하면 지정한 호스트 이름과 포트가 엔드포인트(endpoint)라는 중간 핸들러를 가리킨다. Aurora는 엔드포인트 메커니즘을 사용하여 연결을 추상화 한다. 따라서 일부 DB 인스턴스를 사용할 수 없을 때 모든 호스트 이름을 하드코딩 하거나, 연결을 다시 라우팅하고 로드 밸런싱을 하기 위한 자체 로직을 작성할 필요가 없다.

Aurora 엔드포인트 유형에는 클러스터 엔드포인트, 리더 엔드포인트, 사용자 지정 엔드포인트, 인스턴스 엔드포인트로 네 가지 종류가 있다. 각 엔드포인트에 대한 특징을 살펴보자.

[클러스터 엔드포인트 (Cluster endpoint)]

Aurora DB 클러스터의 클러스터 엔드포인트(또는 Writer endpoint)는 해당 DB 클러스터의 현재 기본 DB 인스턴스에 연결된다. DDL 문 등의 쓰기 작업을 수행할 수 있는 유일한 엔드포인트 이다. 각 Aurora DB클러스터에는 클러스터 엔드포인트 하나와 기본 DB 인스턴스 하나가 있다. 삽입, 업데이트, 삭제 및 DDL 변경을 비롯하여 DB의 모든 쓰기 작업에 대해 클러스터 엔드포인트를 사용한다. 또한 읽기 작업에도 클러스터 엔드포인트를 사용할 수 있다. 클러스터 엔드포인트는 장애조치를 지원한다. 아래는 Aurora MySQL DB 클러스터의 엔드포인트를 나타낸 예제이다.

장애조치 메커니즘에서 새 DB 인스턴스가 클러스터의 읽기/쓰기 기본 인스턴스가 되도록 승격하면 클러스터 엔드포인트가 가리키는 물리적 IP 주소가 변경된다. 어떤 형식의 연결 풀링이나 기타 멀티플렉싱을 사용하는 경우, 캐싱된 DNS 정보의 TTL(Time To Live)을 플러시 하거나 줄이도록 준비한다. 이렇게 하면 사용할 수 없게 되었거나 장애 조치 후 이제 읽기 전용인 DB 인스턴스에 읽기/쓰기 연결 설정을 시도하지 않아도 된다.

[리더 엔드포인트 (Reader endpoint)]

Aurora DB 클러스터의 리더 엔드포인트는 DB 클러스터에 대한 읽기 전용 연결시 로드 밸런싱을 지원한다. 읽기 작업에 대한 요청을 복제본에서 처리하기 때문에 기본 인스턴스에 대한 오버헤드를 줄일 수 있다. 또한 클러스터의 Aurora 복제본 수에 비례하여 동시에 SELECT 쿼리를 처리할 수 있도록 용량을 확장할 수 있다. 각 Aurora DB 클러스터에는 리더 엔드포인트가 1개씩 있다. 클러스터에 하나 이상의 Aurora 복제본이 포함된 경우 리더 엔드포인트는 Aurora 복제본 사이의 각 연결 요청을 로드 밸런싱 한다. 이 경우 해당 세션의 SELECT 와 같은 읽기만 실행할 수 있다. 클러스터에 기본 인스턴스만 있고 Aurora 복제본이 없는 경우 리더 엔드포인트는 기본 인스턴스에 연결한다. 이 경우 엔드포인트를 통해 쓰기 작업을 수행할 수 있다. 아래는 Aurora MySQL DB 클러스터의 리더 엔드포인트를 나타낸 예제이다.

RDS Proxy를 통해서도 Aurora 클러스터용 추가 읽기 전용 엔드포인트를 생성할 수 있다. 이러한 엔드포인트는 Aurora 리더 엔드포인트와 동일한 종류의 로드밸랜싱을 수행한다.

l  Amazon RDS Proxy 엔드포인트 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/rds-proxy-endpoints.html#rds-proxy-endpoints-reader

[사용자 지정 엔드포인트 (Customer endpoint)]

Aurora 클러스터의 사용자 지정 엔드포인트는 선택한 DB 인스턴스 집합을 나타낸다. 엔드포인트에 연결하면 Aurora가 로드 밸런싱을 수행하고 그룹에서 연결을 처리할 인스턴스 중 하나를 선택한다. 이 엔드포인트가 참조하는 인스턴스를 정의하고, 이 엔드포인트가 어떤 목적으로 사용되는지 결정한다. 사용자 지정 엔드포인트는 클러스터를 생성할 때 자동으로 생성되지 않으며, 프로비저닝된 각 Aurora 클러스터에 대해 최대 5개의 사용자 지정 엔드포인트를 만들 수 있다. Aurora Serverless 클러스터에는 사용자 지정 엔드포인트를 사용할 수 없다.

사용자 지정 엔드포인트는 DB 인스턴스의 읽기 전용 기능 또는 읽기/쓰기 기능 이외의 다른 조건을 기반으로 로드 밸런싱된 데이터베이스 연결을 제공한다. 예를 들어 특정 AWS 인스턴스 클래스 또는 특정 DB 파라메터 그룹을 사용하는 인스턴스에 연결할 사용자 지정 엔드포인트를 정의할 수 있다. 또는 보고서 생성 등과 같은 일회성 쿼리 같은 것을 저용량의 내부 서버로 보내고, 고용량 인스턴스로는 프로덕션 트래픽을 보낼 수 있다.

사용자 지정 엔드포인트와 연결된 모든 DB인스턴스로 연결이 이동할 수 있기 때문에 해당 그룹내의 모든 DB 인스턴스가 일부 유사한 특성을 공유하는지 확인하는 것이 좋다. 그렇게 하면 성능, 메모리 용량 등이 해당 엔드포인트에 연결하는 모든 사람에게 일관되도록 보장할 수 있다. 이 기능은 모든 Aurora 복제본을 동일한 클러스터에 유지하는 것이 적절하지 않은 특수한 종류의 워크로드가 있는 고급 사용자를 위한 것으로 사용자 지정 엔드포인트를 통해 각 연결에 사용되는 DB 인스턴스를 예측할 수 있다. 사용자 지정 엔드포인트를 사용할 경우 일반적으로 해당 클러스터에 리더 엔드포인트를 사용하지 않는다. 아래는 Aurora MySQL DB 클러스터의 사용자 지정 엔드포인트를 나타낸 예제이다.

사용지 지정 엔드포인트의 이름은 최대 63글자 까지 가능하다. 사용자 지정 엔드포인트 이름에는 클러스터 이름이 포함되지 않기 때문에, 클러스터 이름을 바꿀 경우 엔드포인트 이름을 변경할 필요가 없다. 동일한 리전에 있는 둘 이상의 클러스터에 동일한 사용자 지정 엔드포인트 이름을 재사용할 수 없다. 각 사용자 지정 엔드포인트에 특정 리전 내의 사용자 ID가 소유한 클러스터 전체에서 고유한 이름을 부여한다. 장애 조치 또는 승격으로 인해 DB 인스턴스가 기본 인스턴스와 Aurora 복제본 간에 역할을 변경해도 Aurora는 정적 목록 또는 제외 목록에 지정된 DB 인스턴스를 변경하지 않는다. 예를 들어 READER 유형의 사용자 지정 엔드포인트에는 Aurora 복제본 이었다가 이후 기본 인스턴스로 승격된 DB 인스턴스가 포함될 수 있다. 사용자 지정 엔드포인트 유형 (READER, WRITER 또는 ANY)에 따라 해당 엔드포인트를 통해 수행할 수 있는 작업의 종류가 결정된다. Aurora 복제본을 사용할 수 없게 된 경우에도 사용자 지정 엔드포인트와는 연결된 상태로 유지된다. 예를 들어 이상이 있거나, 중지되었거나, 재부팅 되더라도 사용자 지정 엔드포인트의 일부로 유지된다. 그러나 클러스터가 다시 사용할 수 있게 될 때까지 기존 엔드포인트를 통해 연결할 수 없다.

[인스턴스 엔드포인트 (Instnace  endpoint)]

인스턴스 엔드포인트는 Aurora 클러스터에 있는 특정 DB 인스턴스에 연결된다. DB 클러스터의 DB 인스턴스에는 각각 고유한 인스턴스 엔드포인트가 있다. 그러므로 DB 클러스터의 현재 기본 DB 인스턴스에 대해 인스턴스 엔드포인트 하나가 있고, DB 클러스터의 각 Aurora 복제본마다 인스턴스 엔드포인트 하나가 있다.  클러스터 엔드포인트 또는 리더 엔드포인트의 사용이 부적합한 시나리오에서 인스턴스 엔드포인트가 DB 클러스터에 대한 연결을 직접 제어한다. 예를 들어 어플리케이션에서 워크로드 유형에 따라 더욱 세분화된 로드 밸런싱이 필요할 경우 각 애플리케이션 속성에 따라 각기 다른 Aurora 복제본에 연결한 후 읽기 워크로드를 분산 시킬 수 있다. 아래는 Aurora MySQL DB 클러스터의 DB 인스턴스 엔드포인트 예제이다.

고가용성이 중요한 클러스터의 경우 라이터 엔드포인트를 읽기/쓰기 또는 범용 연결에 사용하고 리더 엔드포인트를 읽기 전용 연결에 사용한다. 라이터 및 리더 엔드포인트는 인스턴스 엔드포인트보다 DB 인스턴스 장애조치를 더 잘 관리한다. 인스턴스 엔드포인트와 달리 라이터 및 리더 엔드포인트는 클러스터의 DB 인스턴스를 사용할 수 없게 되면 연결된 DB 인스턴스를 자동으로 변경한다. 인스턴스 엔드포인트 연결을 관리하는 자체 애플리케이션 로직을 설계하는 경우, DB 인스턴스의 결과 집합을 수동으로 또는 프로그래밍 방식으로 가져올 수 있다. 그런 다음 장애 조치 이후 인스턴스 클래스를 확인하고 해당 인스턴스 엔드포인트에 연결하면 된다.

[참고자료]

l  Amazon Aurora DB 클러스터 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.html

l  Amazon Aurora 연결관리 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.Endpoints.html

l  Amazon RDS Proxy 엔드포인트 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/rds-proxy-endpoints.html#rds-proxy-endpoints-reader

2022-07-10 / Sungwook Kang / http://sungwookkang.com

AWS, Aurora, Aurora Connection Management, Aurora 클러스터 연결, 오로라 클러스터 연결, 오로라 엔드포인트, Aurora endpoint