BLOG
Amazon Aurora 는 클라우드용으로 구축된 MySQL 및 PostgreSQL 호환 관계형 데이터베이스로, 기존의 엔터프라이즈 데이터베이스의 성능 및 가용성과 오픈 소스 데이터베이스의 단순성 및 비용 효율성이 결합된 서비스입니다. Aurora 글로벌 데이터베이스를 사용하면 여러 리전에 걸쳐 관계형 데이터베이스를 확장할 수 있으며, 특히 리전 간 재해 복구를 원하거나 보조 리전에서 지연 속도를 최소화하려는 경우에 적합합니다. 이러한 글로벌 데이터베이스는 여러 지역에 걸쳐 독자를 확장할 수 있는 좋은 수단이기도 합니다.
이번 포스팅에서는 글로벌 데이터베이스 엔드포인트 관리를 자동화하는 솔루션에 대해 알아보겠습니다.
글로벌 데이터베이스의 개요
글로벌 데이터베이스 클러스터는 여러 지역의 클러스터로 구성되는데요, us-east-1및 us-west-2의 클러스터와 같이 지원되는 리전에 최대 6개의 리전 클러스터를 가질 수 있습니다. 글로벌 데이터베이스 토폴로지에서는 하나의 리전만이 기본이고 다른 모든 리전은 보조입니다. 기본 리전에는 유일한 writer instance endpoint와 active writer endpoint가 포함되어 있습니다. writer instance는 항상 active writer node를 가리킵니다. 모든 보조 리전에도 작성자 엔드포인트가 있지만 비활성 상태입니다. 각 지역 클러스터에는 리더 엔드포인트도 있습니다. 리더 엔드포인트는 읽기 트래픽을 지역 클러스터의 읽기 전용 복제본(있는 경우)으로 분산하며, 전역 데이터베이스 장애 조치(failover) 후에도 영향을 받지 않습니다.
글로벌 데이터베이스에는 관리형 방식으로 현재 기본 지역에서 보조 지역으로 전환할 수 있는 관리형 계획 장애 조치 기능이 있습니다. AWS Management 콘솔 , AWS 명령줄 인터페이스 (AWS CLI) 또는 API 를 통해 관리형 장애 조치 프로세스를 호출할 수 있습니다. 장애 조치 프로세스 중에 지정된 보조 클러스터는 기본 클러스터로 승격되고 이전 기본 클러스터는 보조 클러스터로 강등되며 복제 방향은 반대입니다. 이 프로세스가 수행되는 동안 클러스터의 writer endpoint가 변경되고, 새 기본의 writer endpoint가 active writer endpoint가 됩니다. 이 경우 데이터베이스 사용자와 응용 프로그램은 새 엔드포인트를 사용하도록 연결 문자열의 업데이트를 재구성해야 합니다.
계획된 장애 조치 후에 애플리케이션을 재구성하는 것은 시간이 많이 걸리는 작업입니다. 오늘 포스팅에서는 연결 문자열을 업데이트하기 위해 앱을 다시 구성할 필요가 없도록 리전 간에 자동으로 전환하는 글로벌 데이터베이스에 대한 엔드포인트 관리를 자동화하는 솔루션에 대해 알려드리겠습니다. 포스팅에서 다뤄진 솔루션은 GitHub에서 샘플 코드로 사용하실 수 있습니다.
아키텍처의 개요
이 솔루션은 Amazon Route 53 프라이빗 호스팅 영역 과 CNAME 레코드를 생성합니다. 아래 다이어그램과 같이 사용자와 애플리케이션은 Route 53 CNAME 엔드포인트에 연결하여 데이터베이스 작성기에 연결합니다. 자동화는 계획된 관리형 장애 조치(failover)가 발생한 경우 글로벌 데이터베이스에 있는 현재 기본 클러스터의 작성기 엔드포인트로 CNAME을 업데이트합니다. SSL을 사용하지 않는 애플리케이션은 계획된 관리형 장애 조치에서 자동화된 엔드포인트 업데이트를 얻을 수 있습니다. 이 SSL 지원 제한 사항에 대해서는 포스팅 뒷부분에서 설명을 하도록 하겠습니다.
솔루션은 이벤트 알림에 의존하는데요, 현재 보조 클러스터의 승격을 수행하여 수행되는 계획되지 않은 수동 장애 조치에 대한 이벤트 알림은 없습니다. 따라서 계획되지 않은 수동 장애 조치 또는 끝점 연결에 SSL을 사용하는 경우 엔드포인트 업데이트를 수동으로 계속 처리하려면 주의를 기울여야 합니다. 배포된 후 솔루션은 관리되는 계획된 장애 조치로 인해 엔드포인트 변경이 발생한 경우 CNAME을 올바른 작성자로 업데이트된 상태로 유지합니다.
솔루션에 관련된 구성 요소
아키텍처에서 사용되는 서비스에 대한 간략한 개요를 살펴보겠습니다.
- Amazon Route 53 – Route 53은 가용성과 확장성이 뛰어난 클라우드 DNS(Domain Name System) 웹 서비스입니다. www.example.com숫자 IP 주소 와 같은 이름을 변환하여 최종 사용자를 애플리케이션으로 라우팅하는 매우 안정적이고 비용 효율적인 방법을 개발자와 기업에 제공하도록 설계되었습니다. 솔루션은 private hosted zone과 클라이언트 요청을 활성 작성기 엔드포인트로 라우팅하는 CNAME 레코드를 생성합니다. 모든 전역 데이터베이스 클러스터에 대해 하나의 CNAME 레코드가 생성되고 해당 클러스터의 현재 작성기 끝점을 가리키도록 업데이트된 상태로 유지됩니다. CNAME(Canonical Name) 레코드는 DNS(이 경우 Route 53)에서 한 도메인 이름에서 다른 도메인 이름으로 별칭을 만드는 데 사용됩니다. 이 경우 CNAME 레코드는 솔루션의 초기 배포 중에 매개변수로 전달되고 연결을 현재 작성기 끝점으로 리디렉션합니다.
- Amazon DynamoDB – Amazon DynamoDB 는 모든 규모에서 한 자리 수 밀리초 성능을 제공하는 키-값 및 문서 데이터베이스입니다. 인터넷 규모 애플리케이션을 위한 보안, 백업 및 복원, 인메모리 캐싱이 내장된 완전 관리형 다중 지역, 다중 활성, 내구성 데이터베이스입니다. 이 솔루션은 기록 보관을 위한 DynamoDB 테이블을 생성합니다.
- Amazon EventBridge – Amazon EventBridge 는 애플리케이션, 통합 SaaS(Software as a Service) 애플리케이션 및 AWS 서비스에서 생성된 이벤트를 사용하여 대규모 이벤트 기반 애플리케이션을 더 쉽게 구축할 수 있게 해주는 서버리스 이벤트 버스입니다. EventBridge는 이벤트 소스에서 실시간 데이터 스트림을 제공합니다. 이 솔루션은 전역 데이터베이스 관리 계획된 장애 조치가 한 지역에서 성공적으로 완료될 때마다 이벤트 패턴을 일치시키는 데 사용되는 EventBridge 규칙을 생성합니다. 장애 조치가 완료되면 완료 이벤트가 감지되고 이 규칙이 트리거됩니다.
- AWS Lambda – AWS Lambda는 서버 프로비저닝 또는 관리, 워크로드 인식 클러스터 확장 로직 생성, 이벤트 통합 유지 또는 런타임 관리 없이 코드를 실행할 수 있는 서버리스 컴퓨팅 서비스입니다. 이 솔루션은 전역 데이터베이스 장애 조치 시 트리거되는 Lambda 함수를 생성하고 CNAME 레코드를 올바른 값으로 업데이트합니다.
솔루션 개요
전역 데이터베이스 장애 조치가 발생할 때 이벤트 순서에 따라 이 솔루션이 어떻게 작동하는지 살펴보겠습니다. 다음 다이어그램은 이벤트 체인을 보여줍니다.
이 솔루션은 서버리스 스택을 사용하여 CNAME 레코드의 변경을 조정합니다. 다음은 관리형 계획 장애 조치 기능을 사용하여 글로벌 데이터베이스가 장애 조치될 때 펼쳐지는 이벤트 순서입니다.
- Aurora는 모든 유형의 글로벌 데이터베이스 활동을 포함하여 특정 작업이 수행되거나 특정 이벤트가 발생할 때 이벤트를 생성합니다. 우리가 관심을 갖고 있는 활동은 전역 데이터베이스 장애 조치를 완료하는 것입니다. AWS CLI, API 또는 콘솔을 통해 관리형 계획 장애 조치가 시작되면 글로벌 데이터베이스 장애 조치 프로세스가 시작됩니다. 새 클러스터가 기본 클러스터로 승격되고 작성기 엔드포인트가 변경된 후 장애 조치 프로세스가 완료되면 EventBridge 규칙을 트리거하는 이벤트가 발행됩니다. 이 규칙은 이 리전 및 계정의 모든 글로벌 데이터베이스 클러스터에 대해 트리거됩니다. 특정 전역 데이터베이스 클러스터를 관리 대상에서 제외해야 하는 경우 솔루션 배포 가이드를 사용하여 수행할 수 있습니다. 이 규칙은 다음 이벤트 패턴과 일치하여 트리거됩니다.
{
“detail-type”: [“RDS DB Cluster Event”],
“source”: [“aws.rds”],
“detail”: {
“EventCategories”: [“global-failover”],
“EventID”: [“RDS-EVENT-0185”]
}
}
2. 규칙에는 Lambda 함수로 정의된 대상이 있습니다. 전역 데이터베이스 장애 조치 완료 이벤트에 의해 규칙이 호출되면 Lambda 함수가 트리거됩니다. 이 함수에는 이 솔루션의 핵심 논리가 포함되어 있습니다.
3. 이 함수는 DynamoDB 테이블을 조회하여 이 솔루션에서 글로벌 데이터베이스를 관리하고 이 솔루션에 대해 생성된 프라이빗 호스팅 영역 ID를 확인합니다(초기 배포 중에 호스팅 영역 이름 전달).
4. 레코드가 DynamoDB 테이블에서 발견되면 글로벌 데이터베이스 클러스터가 이 솔루션에서 관리되고 있음을 의미합니다. Lambda 함수는 현재 작성자 엔드포인트를 조회하고 CNAME을 업데이트합니다.
이 시점에서 자동화가 완료되고 클라이언트가 새 기록기 엔드포인트에 성공적으로 연결할 수 있습니다.
전제 조건
이 솔루션을 배포하려면 다음의 사전 요구 사항이 있어야 합니다.
- 관리자 권한으로 이미 구성된 AWS CLI
- 파이썬 3의 최신 버전
- 파이썬에 대한 AWS SDK (boto3)
- 2개 이상의 리전이 있는 1개 이상의 Aurora 글로벌 데이터베이스가 있는 AWS 계정
- 망할 놈의 명령 행 도구 설치
이 솔루션은 MIT 라이선스에 따라 GitHub 에서 샘플 코드로 제공됩니다.
솔루션 배포
계정에 이 솔루션을 배포하려면 다음 단계를 완료해야 합니다.
1.저장소를 로컬 개발 머신에 복제합니다:
git clone https://github.com/aws-samples/amazon-aurora-global-database-endpoint-automation.git
2. GitHub 리포지토리를 복제한 루트 디렉터리의 명령줄에서 다음 명령을 실행합니다. 글로벌 데이터베이스 클러스터가 배포된 모든 리전을 통과했는지 확인합니다.
usage:
python3 buildstack.py [–template-body <‘managed-gdb-cft.yml’>] <–stack-name ‘stackname’> [–consent-anonymous-data-collect <‘yes/no’>] <–region-list ‘regionlist’>
example:
python3 buildstack.py –template-body ‘managed-gdb-cft.yml’ –stack-name ‘gdb-managed-ep’ –consent-anonymous-data-collect ‘yes’ –region-list ‘us-east-1, us-west-1’
이 스크립트는 선택한 모든 리전에 AWS CloudFormation 템플릿을 배포하고 AWS CloudFormation 이 개별 스택 프로비저닝을 마칠 때까지 기다립니다. 다음의 매개변수에 유의해야 합니다.
- – – region-list – 이 명령은 매개변수로 전달한 모든 리전에 스택을 빌드합니다 –region-list. 앞의 명령을 실행할 때 글로벌 데이터베이스 클러스터가 배포된 모든 리전을 전달해야 합니다. 여기서 클러스터 수는 관련이 없으며 지역만 전달하면 됩니다. 지역 목록은 값을 쉼표로 구분된 지역 이름으로 허용합니다. (예: us-east-1 ,us-west-2)
- – – 동의 익명 데이터 수집 – 이 스크립트는 고객이 이 솔루션을 배포한 횟수를 이해하기 위해 익명, 비PII 및 계정 식별이 불가능한 데이터를 수집합니다. 데이터 수집은 완전히 선택 사항이며 no를 값으로 전달하면 선택 해제됩니다. 이 매개변수의 기본값은 yes입니다. 스택 이름, 지역, 타임스탬프 및 스택 ID의 UUID 부분(고유성)만 수집합니다. 우리는 솔루션이 얼마나 사용되고 있는지 이해하기 위해서만 데이터를 수집하며, 그렇다면 계속해서 리소스와 노력을 투입하여 솔루션을 개선하고 기능을 추가하도록 동기를 부여합니다.
명령의 모든 매개변수에 대한 자세한 설명은 GitHub 리포지토리 의 readme 섹션을 참조하십시오.
3. AWS CloudFormation이 모든 리전에서 리소스 구축을 완료한 후 다음 명령을 실행하여 글로벌 데이터베이스의 모든 리전을 전달합니다.
usage:
python3 create_managed_endpoint.py –cluster-cname-pair ‘{“<global database clustername>”:”<desired writer endpoint >”} [,”<global database clustername>”:”<desired writer endpoint>”},…]’ –hosted-zone-name=<hosted zone name> –region-list <‘regionlist’>
example:
python3 create_managed_endpoint.py –cluster-cname-pair ‘{“gdb-cluster1″:”writer1.myhostedzone.com” ,”gdb-cluster2″:”writer2.myhostedzone.com”}’ –hosted-zone-name=myhostedzone.com –region-list ‘us-east-1,us-west-1’
실수를 한 경우 다시 실행할 수 있습니다. 스크립트는 idempotent한 성질을 가지고 있으므로, 새 전역 클러스터를 추가할 준비가 되면 새 전역 데이터베이스 클러스터 및 CNAME 쌍으로 간단히 다시 실행할 수 있습니다.
다음 매개변수에 유의하십시오.
- – – cluster-cname-pair – 관리하려는 전역 클러스터 이름과 생성하려는 작성기 엔드포인트가 콜론으로 구분된 키-값 형식으로 전달됩니다. 예를 들어, 관리 중인 전역 데이터베이스 클러스터의 이름이 지정 gdb-clu-1되고 엔드포인트를 지정하려는 testdomain.com경우 값을 전달합니다 {“gdb-clu-1”:“writer1.testdomain.com”}. 쉼표로 구분한 클러스터를 원하는 만큼 전달할 수 있습니다.
- – – hosts-zone-name – 생성할 호스팅 영역의 이름입니다. 엔드포인트의 도메인 부분과 호스팅 영역 이름이 일치하는지 확인해야 합니다.
명령의 모든 매개변수에 대한 자세한 내용은 GitHub 리포지토리의 추가 정보 섹션을 참조하세요. 클러스터 또는 리전 수에 관계없이 솔루션 전체가 2-3분 내에 배포됩니다. 이 솔루션을 배포하면 두 가지 유형의 리소스가 표시됩니다.
- 계정당 생성된 글로벌 리소스:
- 프라이빗 호스팅 영역(Route 53) – 전달한 값을 기반으로 프라이빗 호스팅 영역이 생성됩니다.
- CNAME 레코드 – 클러스터별로 전달한 파라미터를 기반으로 호스팅 영역 내부에 CNAME 레코드가 생성됩니다.
- 리전별로 생성된 로컬 리소스:
- IAM 역할 – 실행 중에 Lambda 함수가 이 역할을 맡을 수 있도록 AWS Identity and Access Management 역할이 생성됩니다. 역할은 매우 세분화되어 있으며, 최소한만 부여되었습니다. Lambda 기능을 실행하는 데 필요한 기능을 수행하는 데 필요한 권한만 선택적으로 부여합니다.
- Lambda 함수 – 이 함수는 전역 데이터베이스 장애 조치 완료 이벤트에서 호출되고 CNAME을 업데이트합니다. 솔루션 자동화의 핵심 로직이 포함되어 있습니다.
- DynamoDB 테이블 – 이라는 DynamoDB 테이블 gdbcnamepair이 생성됩니다. 이 테이블은 이 솔루션에서 관리하는 클러스터를 추적합니다.
- EventBridge 규칙 – 이 규칙은 글로벌 데이터베이스가 리전에서 장애 조치를 완료할 때 트리거됩니다. 이 규칙에는 대상으로 Lambda 함수가 있습니다.
현재의 제한 사항
이 솔루션에는 다음과 같은 제한 사항이 있습니다.
- 부분 SSL 지원 – 솔루션이 Route 53 CNAME을 사용하기 때문에 SSL 인증서 는 Aurora 인스턴스 엔드포인트 일반 이름을 검증할 수 없습니다. 예를 들어 PostgreSQL 클라이언트 verify-full 또는 MySQL 클라이언트 ssl-verify-server-cert 가 서버 ID의 유효성을 검사하지 못합니다. 그러나 서버 이름 확인 옵션 없이 SSL 암호화를 계속 사용할 수 있습니다.
- 관리형 계획 장애 조치만 지원 – 글로벌 데이터베이스 클러스터에서 보조 지역 클러스터를 제거한 다음 보조 지역 클러스터를 기본으로 승격하여 계획되지 않은 수동 장애 조치를 수행하는 경우 이 솔루션은 해당 조건을 감지할 수 없습니다. 관리형 계획 장애 조치를 사용해야 합니다.
- 교차 리전 VPC 경로를 설정해야 함 – 솔루션은 리전 및 VPC 전반에 걸쳐 DNS 확인만 설정합니다. 애플리케이션에 필요한 경우 리전 전체에 걸쳐 VPC 간에 네트워크 경로를 설정할 책임이 있습니다(예: VPC 피어링 , 전송 게이트웨이 또는 전송 VPC 사용 ). 여러 리전에서 작성기 엔드포인트에 연결하는 애플리케이션이 없는 경우 VPC 간에 네트워크 경로를 설정할 필요가 없습니다.
요약
이번 포스팅에서는 특히 관리형 장애 조치 후 이 사용자 지정 솔루션 을 사용하여 Aurora 글로벌 데이터베이스에 대한 엔드포인트 관리를 자동화하는 방법에 대해 살펴보았습니다. 솔루션은 처음 배포되고 나면 완전히 손을 떼고 몇 분 안에 설정되며 완전히 서버리스 및 이벤트 기반입니다.
관리되는 계획된 장애 조치 이벤트 중에 데이터베이스 엔드포인트를 관리하거나 애플리케이션 연결 문자열을 재구성해야 하는 걱정 없이 사용자 환경에서 글로벌 데이터베이스의 리전 간 이점을 누릴 수 있습니다.
이 솔루션을 테스트해보고 의견 섹션에 피드백을 남겨주세요!
원문URL: https://aws.amazon.com/ko/blogs/database/automate-amazon-aurora-global-database-endpoint-management/
메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글이나 관련 기사 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.