BLOG
복제, 장애 조치 (failover), 복원력, 재해 복구 및 백업 – 기존 또는 비 클라우드 기반 아키텍처에서 이들 중 일부 또는 전부를 달성하는 것은 어려울 수 있습니다. 또한 때로는 상당한 재작업 노력이 필요합니다. 관련된 구현 및 인프라 비용이 높기 때문에 일부 기업은 가장 중요한 애플리케이션만 안전하게 보호할 수 있도록 애플리케이션을 계층화 해야합니다.
PostgreSQL용 Amazon Aurora로 이동하면 이러한 우려를 완화할 수 있습니다. AWS는 Oracle, MySQL, PostgreSQL 및 Aurora를 포함하되 이에 국한되지 않는 다양한 관계형 데이터베이스 엔진을 제공합니다. PostgreSQL의 경우 AWS는 Amazon EC2 인스턴스의 PostgreSQL, PostgreSQL용 Amazon RDS 및 PostgreSQL과 호환되는 Amazon Aurora를 비롯한 여러 가지 기능을 지원합니다. 올바른 PostgreSQL 버전을 선택하기 위한 많은 척도 중에서 다음과 같은 것들이 중요합니다.
- 고 가용성 (HA)
- 성능
- 관리의 용이함
Amazon Aurora PostgreSQL이 이러한 기준을 충족하는 방법에 대해 알아 보겠습니다.
고가용성 : HA는 Aurora PostgreSQL의 아키텍처에 내장되어 있으며 세 개의 가용성 영역에 걸쳐 6 개의 데이터 복사본이 유지 관리됩니다. 이는 각 가용 영역마다 2 개의 카피본이 존재하며 전체 가용 영역이 다운 된 경우에도 사소한 중단으로 가용성을 높입니다. 또한 데이터베이스는 Amazon S3에 지속적으로 백업되므로 백업을 위해 S3의 높은 내구성 (99.99999999)을 활용할 수 있습니다. Aurora PostgreSQL은 또한 특정 시점 복구를 지원합니다.
성능 : Amazon Aurora PostgreSQL은 Amazon EC2의 PostgreSQL에 비해 최대 3 배 우수한 성능을 제공합니다. 벤치 마크 테스트에 대한 자세한 내용은 Amazon Aurora PostgreSQL- 호환 에디션 벤치마킹 가이드를 다운로드 하세요. 또한 성능 인사이트를 통해 데이터베이스 분석 및 문제 해결을 보다 쉽게 수행 할 수 있습니다.
관리 효율성 : Amazon Aurora PostgreSQL은 프로비저닝, 패치, 백업, 복구, 오류 감지 및 복구와 같은 일상적인 데이터베이스 작업을 처리하여 관리를 단순화합니다. Aurora 스토리지는 자동으로 확장되며 일관된 성능을 제공하기 위해 fleet에서 I / O를 확장 및 재조정합니다.
이 글에서는 Amazon Aurora 클러스터 및 엔드포인트의 개요와 구성 변경 사항을 최소화하면서 읽기에 대한 장애 조치 및 로드 벨런싱을 수행하는 방법에 대해 설명합니다. Aurora 클러스터에서 페일오버가 작동하는 방식을 보여주는 예를 살펴보고 페일오버를 투명하게 만드는 방법을 설명합니다. 이 글은 주로 Amazon Aurora PostgreSQL에 대해 설명하지만 대부분의 개념을 Amazon Aurora MySQL에도 적용 할 수 있습니다.
Aurora 클러스터 소개
Amazon EC2 또는 PostgreSQL용 Amazon RDS의 PostgreSQL과 달리 Aurora PostgreSQL DB 인스턴스를 만들면 실제로 데이터베이스 클러스터가 생성됩니다. Aurora PostgreSQL에서 DB 클러스터는 하나의 읽기 / 쓰기 인스턴스와 최대 15 개의 읽기 인스턴스와 여러 가용 영역에 걸쳐있는 데이터 저장소 (클러스터 볼륨)의 모음입니다. 각 가용 영역은 두 개의 DB 클러스터 데이터 복사본을 유지 관리합니다.
Amazon Aurora Replicas는 원본 인스턴스와 동일한 기본 저장소를 공유하므로 비용이 절감되고 복제본 노드에 데이터를 복사할 필요가 없습니다. PostgreSQL 읽기 복제본을 위한 Amazon RDS는 실제 사본입니다. 원본 데이터베이스 인스턴스가 변경될 때마다 비동기 복제 방법을 사용하여 읽기 복제본을 업데이트합니다. 또한 PostgreSQL용 RDS의 경우 데이터베이스 소스 인스턴스당 읽기 복제본이 5 개로 제한되지만 Aurora 클러스터는 최대 15 개의 읽기 복제본과 함께 하나의 기본 (마스터 또는 읽기 / 쓰기) 인스턴스를 지원합니다.
다음 다이어그램은 Aurora PostgreSQL 아키텍처에서 마스터 및 3 개의 읽기 복제본을 보여줍니다.
Aurora 아키텍쳐에 대한 자세한 정보는 AWS 데이터베이스 블로그 글의 Aurora 스토리지 엔진 소개하기를 참조하십시오.
엔드포인트
Aurora PostgreSQL 인스턴스에 대한 연결은 엔드포인트를 사용하여 이루어집니다. 엔드포인트는 콜론으로 구분된 호스트 주소와 포트가 포함된 URL입니다. Aurora PostgreSQL 인스턴스를 만들면 AWS는 클러스터 레벨과 인스턴스 레벨에서 엔드포인트를 만듭니다. 클러스터 레벨에서는 읽기 / 쓰기 조작 (클러스터 엔드 포인트라고 함)과 읽기 전용 조작 (판독기 엔드 포인트라고 함)을 위한 두 개의 엔드 포인트가 생성됩니다. 다중 읽기 복제본에 대한 읽기전용 연결의 로드 벨런싱은 판독기 엔드포인트를 통해 이루어지지만 클러스터 엔드포인트를 통해 장애 조치가 가능합니다. 또한 클러스터에 읽기 복제본이 없으면 판독기 엔드포인트가 기본 인스턴스에 대한 연결을 제공합니다.
인스턴스 레벨에서 인스턴스당 하나의 엔드 포인트가 생성됩니다. 인스턴스 엔드 포인트에서는 기존 연결처럼 인스턴스에 직접 연결합니다. 클러스터 엔드 포인트가 없는 것들만으로 인스턴스 엔드포인트를 사용하는 것은 적절한 이유 없이는 권장되지 않습니다. 인스턴스 엔드포인트와 함께 클러스터 엔드포인트를 사용하여 읽기 쿼리의 수동 로드 밸런싱을 할 수도 있습니다.
다음 다이어그램은 엔드 포인트가 작동하는 방법을 보여줍니다.
참조: DB 클러스터의 이름을 바꾸면 클러스터 엔드 포인트 및 판독기 엔드 포인트가 변경됩니다.
Amazon RDS 콘솔에서 탐색 창에서 클러스터를 선택하여 클러스터 및 판독기 엔드포인트를 찾을 수 있습니다.
페일 오버는 어떻게 작동하는가?
DB 클러스터의 기본 인스턴스가 실패하면 Aurora는 다음 순서대로 자동으로 장애 조치합니다.
- Aurora 읽기 복제본을 사용할 수있는 경우, 기존의 읽기 복제본을 새 기본 인스턴스로 승격시키십시오.
- 읽기 복제본을 사용할 수 없는 경우, 새 기본 인스턴스를 만듭니다.
Aurora 읽기 복제본이 여러 개인 경우 승격 기준은 읽기 복제본에 대해 정의된 우선 순위를 기반으로 합니다. 우선 순위 번호는 0에서 15까지 다양하며 언제든지 수정할 수 있습니다. Amazon Aurora PostgreSQL은 Aurora Replica를 새로운 기본 인스턴스에 최우선 순위로 장려합니다. 우선 순위가 동일한 읽기 복제본의 경우 Aurora PostgreSQL은 크기가 가장 크거나 임의의 방식으로 복제본을 승격합니다.
클러스터 엔드포인트를 사용하여 연결하고 연결 재시도 로직을 구현하면 응용 프로그램이 최소한의 서비스 중단이 발생합니다. 장애 조치 중 AWS는 새로 생성 / 승격 된 DB 인스턴스를 가리키도록 클러스터 엔드포인트를 수정합니다. 잘 설계된 응용 프로그램은 자동으로 다시 연결됩니다. 장애 조치 중 가동 중지 시간은 정상적인 읽기 복제본의 존재 여부에 따라 다릅니다. 읽기 복제본이 구성되어 있지 않거나 기존 읽기 복제본이 정상적이지 않으면 새 인스턴스를 생성하기 위해 가동 중지 시간이 증가 할 수 있습니다.
Aurora 클러스터 장애 조치 예시
Amazon Aurora 클러스터의 장애 조치 예제를 살펴 보겠습니다. 다음 표에는 마스터와 두 개의 읽기 복제본이 있는 클러스터의 세부 정보가 나와 있습니다.
| Cluster name | pgcluster |
| Master instance | myinstance-us-east-2a |
| Read Replica | myinstance-us-east-2b (Priority 0) |
| Read Replica | myinstance-us-east-2c (Priority 1) |
| Cluster endpoint | pgcluster.cluster-xxxxxxxxxx.us-east-2.rds.amazonaws.com |
| Reader endpoint | pgcluster.cluster-ro-xxxxxxxxxx.us-east-2.rds.amazonaws.com |
이 표는 pgcluster 라는 이름의 Aurora PostgreSQL 클러스터를 나타냅니다. 클러스터의 엔드포인트 pgcluster.cluster-xxxxxxxxxx.us-east-2.rds.amazonaws.com 가 인스턴스 myinstance-us-east-2a를 나타내고 있는 점을 주목하세요.
다음 코드는 클러스터 엔드포인트를 사용하여 포트 5432의 데이터베이스 pgdb에 연결하는 것을 보여줍니다. 이 그림의 일부로 이 예에서는 failover라는 테이블을 만들고 테이블에 한 행을 삽입합니다.
psql -h pgcluster.cluster-xxxxxxxxxx.us-east-2.rds.amazonaws.com -d pgdb -p 5432 -U pgadmin
–Listing the name of master instance
pgdb=> select server_id from aurora_replica_status() where session_id=’MASTER_SESSION_ID’;
server_id
———————–
myinstance-us-east-2a
(1 row)
pgdb=> CREATE TABLE FAILOVER(FAILOVERNAME VARCHAR(20), FAILOVERTYPE INTEGER);
CREATE TABLE
pgdb=>
pgdb=> INSERT INTO FAILOVER VALUES (‘TEST-1’,1 );
INSERT 0 1
pgdb=>
pgdb=> SELECT * FROM FAILOVER;
failovername | failovertype
—————–+————–
TEST-1 | 1
(1 row)
다음 코드는 실패한 트랜잭션과 함께 판독기 엔드포인트를 사용하는 읽기 복제본 인스턴스에 대한 연결을 보여줍니다. failover 테이블은 동기화를 확인하기 위해 판독기 엔드포인트를 통해 읽기 복제본에서 액세스됩니다.
psql -h pgcluster.cluster-ro-xxxxxxxxxx.us-east-2.rds.amazonaws.com -d pgdb -p 5432 -U pgadmin
–Listing the name of master instance
pgdb=> select server_id from aurora_replica_status() where session_id=’MASTER_SESSION_ID’;
server_id
———————–
myinstance-us-east-2a
(1 row)
pgdb=> SELECT * FROM FAILOVER;
failovername | failovertype
—————–+————–
TEST-1 | 1
(1 row)
pgdb=> INSERT INTO FAILOVER VALUES (‘TEST-2’, 1 );
ERROR: cannot execute INSERT in a read-only transaction
예상했던대로 읽기만 가능한 복제본들은 작성 가능한 트랜잭션을 지원하지 않기에 에러가 발생합니다.
수동 failover
다음 스크린 샷은 Amazon RDS 콘솔의 현재 기본 myinstance-us-east-2a를 보여줍니다.
수동 failover 를 하기 위해서 콘솔에서 기본 인스턴스 이름을 선택하고 인스턴스 작업 메뉴에서 장애 조치를 선택하십시오.
그 다음 failover 창에서 확인하십시오.
수동 장애 조치가 완료되면 myinstance-us-east-2b 인스턴스가 새 기본 인스턴스로 승격되고 myinstance-us-east-2a 인스턴스 역할이 읽기 복제본으로 변경됩니다. 또한 클러스터 엔드포인트는 이제 myinstance-us-east-2b를 가리키고 myinstance-us-east-2a는 판독기 엔드포인트를 통해 사용할 수 있습니다.
다음 스크린 샷은 읽기 복제본이 RDS 콘솔의 새로운 기본 버전이 되는 것을 보여줍니다.
인스턴스 재연결하기
이제 동일한 클러스터 엔드포인트를 사용하여 재연결할 수 있습니다.
psql -h pgcluster.cluster-xxxxxxxxxx.us-east-2.rds.amazonaws.com -d pgdb -p 5432 -U pgadmin
–Listing the name of master instance after failover
pgdb=> select server_id from aurora_replica_status() where session_id=’MASTER_SESSION_ID’;
server_id
———————–
myinstance-us-east-2b
(1 row)
pgdb=> INSERT INTO FAILOVER VALUES (‘TEST-2’, 1 );
INSERT 0 1
pgdb=> SELECT * FROM FAILOVER;
failovername | failovertype
——————–+————–
TEST-1 | 1
TEST-2 | 1
(2 rows)
앞의 코드에서 볼 수 있듯이 연결은 엔드포인트를 변경 없이도 성공적입니다. 응용 프로그램 연결 재시도 논리를 추가하여 장애 조치를 투명하게 만들 수 있습니다.
클러스터 엔드포인트와 함께 적극적인 TCP 킵얼라이브(keepalive) 설정과 JDBC 연결 설정 또는 PGConn 클래스를 애플리케이션 레벨에서 구성하여 장애 조치를 훨씬 빠르게 처리 할 수 있습니다. 자세한 내용은 Amazon Aurora PostgreSQL의 모범 사례를 참조하십시오.
결론
자동 복구를 처리하는 것은 전반적인 조직의 가동 시간 서비스 수준 협약(SLA)을 달성하는 데 매우 중요합니다. Aurora PostgreSQL은 혁신적인 장애 조치 아키텍처를 통해 가용성 및 안정성 향상뿐 아니라 읽기 확장성을 통해 향상된 성능을 제공합니다.
응용 프로그램이 장애 조치에 응답하는 방법은 여러 가지가 있지만 클러스터 및 판독기 엔드포인트를 사용하면 구성 변경을 최소화하면서 장애 조치 및 로드 밸런싱을 수행할 수 있습니다. 또한 다음 TCP 킵얼라이브(keepalive) 및 JDBC 모범 사례와 함께 클러스터 엔드 포인트를 사용하여 빠른 장애 조치 및 고 가용성을 달성할 수 있습니다. 인스턴스 엔드 포인트를 기본 엔드 포인트로 사용하는 것은 권장하지 않습니다. 그러나 읽기에 대한 수동 로드 밸런싱을 지원하는 점에 사용할 수는 있습니다. 또한 응용 프로그램에 자동 재시도 기능을 추가하여 장애 극복을 투명하게 만들 수도 있습니다.
원문 URL: https://aws.amazon.com/ko/blogs/database/failover-with-amazon-aurora-postgresql/
** 메가존 TechBlog는 AWS BLOG 영문 게재글중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.