글로벌 복원력을 위한 Amazon Aurora HA 및 DR 설계 패턴 (DAT442)

세션 노트

Aurora의 성능 접근 방식

성능을 위해 복제본 추가

• 읽기 트래픽을 복제본으로 분산하여 기본 라이터에 미치는 영향을 줄입니다.
• 특정 워크로드(예: 분석)에 전용 복제본을 할당하여 노이즈 네이버를 분리할 수 있습니다.
• 세분화된 성능 관리를 위해 최대 15개의 복제본을 추가할 수 있습니다.
• 스토리지 확장:
• Aurora에서는 스토리지 용량과 성능이 자동으로 확장되므로 수동 프로비저닝이 필요하지 않습니다.
• 인스턴스 확장:
• 장애 조치 및 성능 관리를 위해 인스턴스를 다양한 크기(예: 16XL, 8XL, 4XL)로 추가할 수 있습니다.
• DB 인스턴스는 탄력적이며 0에서 256 Aurora 용량 단위로 확장됩니다.
• 장애 조치 계층은 크기와 용량을 기준으로 인스턴스 장애 조치 순서를 관리하도록 정의됩니다.
• 탄력적 인스턴스는 장기적인 비용 영향 없이 워크로드 급증을 관리하는 데 도움이 됩니다.

과제: Aurora의 연결 관리

• 여러 인스턴스에 대한 연결을 관리합니다. 특히 트랜잭션 작성자를 식별합니다.
• 기법:
• DB 인스턴스당 연결을 풀링하고 제한하여 재연결을 방지합니다.
• 드라이버 프레임워크:
• Spring 및 JDBC와 같은 표준 사례는 클러스터된 데이터베이스를 효과적으로 처리하지 못할 수 있습니다.

Aurora 엔드포인트

작성자 엔드포인트

• 항상 현재 작성자 노드를 가리키므로 일관된 트랜잭션 라우팅이 가능합니다.
• 리더 엔드포인트:
• 대략적인 로드 밸런싱을 위해 DNS 라운드 로빈을 사용하는 읽기 작업을 위한 인스턴스 풀을 가리킵니다.
• 사용자 정의 엔드포인트:
• 특정 사용 사례(예: 분석)에 대한 사용자 지정 엔드포인트를 생성하는 옵션입니다.

AWS 고급 래퍼 드라이버

래피드 드라이버

• 클러스터 상태에 대한 자세한 지식을 갖춘 향상된 드라이버로 더 빠른 장애 조치를 촉진합니다.
• RDS 프록시:
• 연결을 관리하고 장애 조치 시간을 줄이기 위한 추가 도구입니다.
• 플러그인:
• 향상된 장애 조치, 분할 재작성, 블루-그린 배포.

다중 지역 복원력

• 과제: 지역에 장애가 발생하거나 네트워크가 차단된 경우 비즈니스 연속성을 보장합니다.
• 해결책: 다른 지역에 복사본을 유지하고, 최소한의 비용으로 최신 상태로 유지하며, 다양한 목적으로 활용합니다.
• Aurora Global Database를 사용한 다중 지역 복원력:
• Aurora Global Database는 AMS 및 APG에 대해 최대 10 보조 지역을 허용합니다.
• 내부 복제 서버는 지역 간 비동기식 물리적 복제를 처리합니다.
• 헤드 노드는 관련되지 않으므로 논리적 복제와 관련된 성능이 저하됩니다.
• 구성 및 이점:
• 지역 A: 복제본과 스토리지가 있는 기본 지역입니다.
• 지역 B: 처음에 스토리지가 있는 보조 지역은 로컬 읽기를 위한 읽기 전용 인스턴스를 추가할 수 있습니다.
• 비대칭 구성이 가능합니다. 보조 지역의 인스턴스는 기본과 일치할 필요가 없습니다.
• RPO 지연은 지역 쌍 거리에 따라 일반적으로 약 1초입니다.
• 글로벌 엔드포인트 및 장애 조치:
• 글로벌 엔드포인트는 기본 지역 식별을 관리합니다.
• 지역 A에서 오류가 발생하는 경우 지역 B로의 장애 조치가 관리되며 비동기식 복제로 인해 데이터가 손실될 수 있습니다.
• 빠른 리디렉션을 위해 Route 53 데이터 플레인을 사용하여 글로벌 엔드포인트를 다시 지정합니다.
• 바꿔 넣기:
• 두 영역 모두 정상일 때 전환이 수행됩니다.
• 지역 A는 기본이 중지되고 지역 B는 기본이 됩니다.
• 중단 없이 지역 간 빠른 전환을 허용합니다.
• 전환 프로세스:
• 로그 기록 스트림에 특수 로그 기록(마커 로그 기록)을 삽입합니다.
• 상대방은 마커를 인식하여 지정된 로그 시간에 1차가 됩니다.
• 지역 A는 동시에 기본 역할을 중단하여 깔끔한 핸드오프를 보장합니다.
• RPO는 0이고 RTO는 매우 낮습니다(약 30초).

유지 관리 및 업그레이드

• 버전 업그레이드(예: PostgreSQL 16에서 PostgreSQL 17로) 및 OS 패치가 필요합니다.
• 자체 관리형 시스템에는 가동 중지 시간, 롤백을 위한 스냅샷, 호환성 테스트 및 성능 테스트가 필요합니다.
• Aurora는 완전히 관리되고 자동화된 부 버전 및 패치 업그레이드 환경을 제공합니다.
• 이제 롤링 운영 체제 업그레이드를 사용할 수 있어 가용성이 향상됩니다.
• 유지 관리 작업은 지정된 창 내에서 정의되거나 Aurora에 의해 자동으로 관리될 수 있습니다.
• AWS 상태 대시보드는 유지 관리 알림을 제공합니다.
• 유지 관리를 위한 옵트인 자동화를 적극 권장합니다.
• AWS 조직의 업그레이드 출시 정책:
• 개발, QA 및 프로덕션 환경의 여러 DB 클러스터에서 업그레이드를 관리하는 새로운 기능입니다.
• DB 클러스터의 수명주기 관리 자동화를 단순화합니다.
• AWS 조직의 여러 리소스에 걸쳐 태그를 기반으로 업그레이드 정책을 설정할 수 있습니다.
• 예:
• Prod 태그가 지정된 리소스는 마지막으로 업그레이드됩니다. 개발 리소스가 먼저 업그레이드됩니다.
• 기본 동작: 인식된 태그가 없는 리소스가 두 번째로 업그레이드됩니다.
• 업그레이드 롤아웃에는 정책을 리소스에 할당하고, 업그레이드 순서를 결정하고, 유지 관리 기간 내에서 순차적으로 진행하는 작업이 포함됩니다.
• 유지 관리 기간 동안 문제가 감지되면 업그레이드를 중단할 수 있는 유연성을 제공합니다.
• 전체 업그레이드:
• 오픈 소스와 호환되지 않는 주요 업그레이드의 경우 전체 업그레이드가 수행됩니다.
• 데이터베이스 클러스터의 복제본 생성, 복제본 업그레이드 및 애플리케이션 테스트가 포함됩니다.
• 검증되면 클론이 삭제되고 업그레이드가 프로덕션 클러스터에 적용됩니다.
• 블루-그린 배포:
• 주요 업그레이드, 스키마 변경 또는 정적 매개변수 변경에 대한 보다 유연한 접근 방식입니다.
• 논리적 복제를 사용하여 이전 환경( Blue )을 동기화된 상태로 유지하면서 새 환경( Green )을 생성하는 작업이 포함됩니다.
• 업그레이드를 프로덕션으로 승격하기 전에 친환경 환경에서 테스트할 수 있습니다.
• 전환은 일관성을 유지하기 위해 리소스 이름을 변경하며 단 1분 만에 완료됩니다.
• 이제 여러 지역의 글로벌 데이터베이스에 블루-그린 배포를 사용할 수 있습니다.
• Aurora APG 및 AMS 기능 요약:
• 가용성을 높이고 장애 조치를 활성화하기 위해 복제본을 추가합니다.
• 보다 원활한 장애 조치 프로세스를 위해 AWS Advanced Rapid Driver를 사용합니다.
• 최대 10 보조 지역에 걸친 내구성과 가용성을 위한 글로벌 데이터베이스입니다.
• 대기 시간이 짧은 로컬 지역 읽기 및 글로벌 엔드포인트를 통한 엔드포인트 관리 단순화.
• 관리되고 자동화된 클러스터 전체 업그레이드, 빠른 복제, 유지 관리를 위한 블루-그린 배포.

Aurora DSQL 소개

• Amazon Aurora DSQL는 항상 사용 가능한 애플리케이션을 위한 가장 빠른 서버리스 분산형 SQL 데이터베이스입니다. Aurora DSQL는 가장 빠른 다중 리전 읽기 및 쓰기를 제공합니다. 이를 통해 고객은 인프라 관리 및 가동 중지 시간 없이 유지 관리를 통해 모든 워크로드 수요를 충족하도록 쉽게 확장할 수 있습니다.
• 최고의 관계형 데이터베이스, 분산 데이터베이스 아키텍처 및 서버리스 서비스를 결합합니다.
• 복잡한 쿼리를 실행하고, 확장하고, 종량제 가격을 제공하도록 설계되었습니다.
• DSQL 아키텍처 개요:
• EC2.에서 실행되는 자체 관리형 PostgreSQL과 비교
• DSQL는 PostgreSQL 백엔드 프로세스와 유사하게 연결당 쿼리 프로세서를 사용합니다.
• 읽기 쿼리는 DSQL 스토리지 엔진으로 직접 전송됩니다.
• 쓰기는 커밋될 때까지 쿼리 프로세서의 메모리에 버퍼링됩니다.
• 커밋 시 트랜잭션은 동시성 제어를 위해 Adjudicator로 전송된 다음 내구성을 위해 Journal로 전송되어 최소한 2 AZs에 복제됩니다.
• 저널은 기존 PostgreSQL와 유사하게 스토리지를 업데이트하는 데 사용됩니다.
• DSQL는 활성-활성 서비스로, 언제든지 모든 연결에서 데이터를 읽거나 쓸 수 있습니다.
• 쿼리 프로세서(QPs)는 다양한 호스트 또는 가용성 영역에서 실행될 수 있습니다.
• DSQL에서 사용 가능 여부:
• 데이터베이스 노드에 오류가 발생하면 쿼리 프로세서(QPs)가 오류를 감지하고 트래픽을 정상 복제본으로 이동합니다.
• 복제본은 동일하거나 다른 가용성 영역에 있을 수 있습니다.
• 진행 중인 작업에서는 재시도로 인해 대기 시간이 약간 증가할 수 있습니다.
• DSQL는 지속적으로 데이터를 백업하고 실패한 노드를 자동으로 교체합니다.
• 교체 노드는 저널에 연결하여 최신 데이터를 따라잡습니다.
• 최적의 성능을 위해 트래픽이 로컬 복제본으로 다시 이동됩니다.
• 동시성 제어 및 내구성:
• Adjudicator는 동시성 제어 및 충돌 해결을 처리합니다.
• 단일 Adjudicator를 사용하면 네트워크 조정 없이 빠른 충돌 해결이 가능합니다.
• 대기 판정자는 장애 조치를 위해 다른 가용성 영역에 보관됩니다.
• 실패할 경우 대기 심사관은 리더십 프로토콜을 실행하여 새로운 리더를 선출합니다.
• 쿼리 프로세서는 새로운 리더 심사자에 대해 진행 중인 커밋을 다시 시도합니다.
• 프로세스는 원활하게 진행되며 애플리케이션에서 어떤 조치도 취할 필요가 없습니다.

DSQL의 고가용성

• DSQL은 단일 실패 지점이 없도록 설계되었습니다.
• 액티브-액티브 아키텍처는 기본적으로 고가용성을 제공합니다.
• DSQL는 증가하는 부하를 처리하기 위해 자동으로 확장되도록 설계되었습니다.
• 동시성 제어 프로토콜:
• DSQL는 트랜잭션이 거의 충돌하지 않는다고 가정하고 낙관적 동시성 제어를 사용합니다.
• 충돌로 인해 직렬화 실패 오류가 발생하고 클라이언트가 트랜잭션을 다시 시도해야 합니다.
• 애플리케이션은 재시도 및 낙관적 동시성 제어 문제를 처리해야 합니다.
• 도우미 기능을 구축하거나 가장 낮은 애플리케이션 계층에 처리 기능을 통합하는 것이 좋습니다.
• 불필요한 충돌 방지:
• 재시도를 줄이기 위해 불필요한 충돌을 최소화하는 애플리케이션을 설계합니다.
• 서로 다른 행을 업데이트하는 트랜잭션은 충돌 없이 동시에 커밋될 수 있습니다.
• 내부 샤딩 및 스케일링:
• DSQL는 심사관과 저널의 증가된 부하를 처리하기 위해 내부적으로 자동으로 샤딩됩니다.
• 쿼리 프로세서는 커밋을 적절한 샤드에 직접 전달합니다.
• 최적화된 2단계 커밋은 여러 샤드에 걸쳐 원자성 트랜잭션을 보장합니다.
• DSQL는 새 노드를 온라인으로 전환하고 복제본 전체에 로드 밸런싱을 수행하여 자동으로 확장됩니다.
• DSQL의 복제본은 항상 강력한 일관성을 유지하므로 원활한 확장이 가능합니다.
• DSQL의 일관성:
• DSQL는 시간 기반 동기화 프로토콜을 통해 강력한 일관성을 보장합니다.
• 마이크로초 단위의 정확한 타임스탬프를 위해 EC2 시간 동기화 서비스를 사용하고 측정 오류를 수정하려면 Clockbound 라이브러리를 사용합니다.
• 항상 이전에 커밋된 타임스탬프 이후의 선형화 가능한 타임스탬프를 보장합니다.
• 스토리지는 일관성을 보장하기 위해 행을 반환하기 전에 저널의 업데이트를 기다립니다.

2단계 커밋(2PC) 프로토콜 개요

• 2PC는 트랜잭션의 모든 참가자가 함께 커밋하거나 중단하도록 보장하는 분산 시스템 프로토콜입니다.
• 두 단계로 구성됩니다: 준비 및 Commit/Abort.
• 단계 1: 준비 단계:
• 코디네이터는 모든 참여 노드에 "준비" 요청을 보냅니다.
• 각 참가자는 트랜잭션 작업을 수행하고, 필요한 잠금을 획득하고, 트랜잭션 로그에 "준비된" 레코드를 기록합니다.
• 참가자는 코디네이터에게 "예" 또는 "아니요" 투표를 보냅니다.

단계 2: Commit/Abort 단계

모든 참가자가 "예"로 투표한 경우

• 코디네이터는 로그에 "커밋" 레코드를 기록하고 모든 참가자에게 "커밋" 메시지를 보냅니다.
• 참가자는 트랜잭션을 커밋하고 잠금을 해제한 다음 코디네이터에게 승인을 보냅니다.
• 참가자가 "아니오"로 투표한 경우:
• 코디네이터는 로그에 "중단" 레코드를 기록하고 모든 참가자에게 "중단" 메시지를 보냅니다.
• 참가자는 트랜잭션을 롤백하고 모든 잠금을 해제합니다.
• 주요 고려 사항: 원자성:
• 2PC는 트랜잭션이 원자성(모든 노드에서 완료되거나 모든 노드에서 완전한 실패)임을 보장합니다.
• 일관성:
• 여러 노드에서 데이터 일관성을 보장하지만 차단 및 결정 대기로 ​​인해 가용성에 영향을 미칠 수 있습니다.
• 실패 처리:
• 오류로부터 복구하는 메커니즘을 포함합니다. 코디네이터 오류로 인해 수동 개입이 필요한 "의심" 상태가 발생할 수 있습니다.

DSQL의 연결 관리

• DSQL에 대한 연결은 세션 라우팅 계층에 의해 관리됩니다.
• 변동을 일으키는 네트워크 이벤트 중에도 빠른 연결 가용성을 보장합니다.
• 즉시 사용할 수 있는 쿼리 프로세서(QPs)의 웜 풀을 유지 관리합니다.
• 연결이 요청되면 DSQL는 풀에서 사용 가능한 QP를 할당합니다.
• 연결 실패 처리:
• 연결이 실패하는 경우 애플리케이션은 실패를 감지하고 다시 시도해야 합니다.
• 낙관적 동시성 제어 섹션의 재시도 처리기가 이 목적에 유용합니다.
• 애플리케이션은 가용성을 유지하기 위해 연결 오류에 대한 재시도 논리를 구현해야 합니다.
• 스토리지 및 심사자 오류와 달리 애플리케이션은 실패한 연결을 수동으로 다시 연결해야 합니다.
• DSQL는 적절한 연결 관리를 장려하기 위해 연결에 대해 1시간의 최대 수명을 적용합니다.
• 연결 관리 모범 사례:
• 상태 확인 및 최대 연결 수명이 포함된 클라이언트 측 연결 풀링 라이브러리(예: Java C3PO)를 사용하세요.
• DSQL에는 본질적으로 연결 풀링이 포함되어 있어 서버 측 풀링(예: PG Bouncer, RDS Proxy)이 필요하지 않습니다.
• 대기 시간을 줄이기 위해 동일한 가용 영역의 QPs에 연결하는 것이 좋습니다.
• DSQL는 현재 영역을 사용할 수 없는 경우 자동으로 정상 영역으로 장애 조치됩니다.

DSQL의 다중 지역 클러스터

• DSQL는 두 지역에 클러스터를 생성하고 세 번째 지역을 감시 지역으로 지정하여 다중 지역 클러스터를 지원합니다.
• 감시 지역은 지역 실패에 대한 쿼럼 기반 프로토콜을 용이하게 하기 위해 저널 사본을 보유합니다.
• 애플리케이션은 읽기 및 쓰기를 처리할 수 있는 두 지역 모두에서 지역 간에 활성 상태를 유지할 수 있습니다.
• 쿼럼 기반 프로토콜
• 작업이 유효한 것으로 간주되기 전에 작업에 동의하도록 최소한의 참여 노드(쿼럼)를 요구함으로써 데이터 일관성, 내결함성 및 신뢰성을 보장하기 위해 분산 시스템에서 사용되는 방법입니다.
• S3 쿼럼 기반 프로토콜:
• 분산 시스템에서 "정족수"는 "회의를 구성하는 데 필요한 최소 구성원 수"를 의미합니다.
• Quorum 메커니즘은 Amazon S3.와 같은 분산 스토리지 시스템에서 데이터 중복성과 일관성을 보장하기 위한 투표 알고리즘입니다.
• 핵심 개념 및 용어:
• 읽기 쿼럼(Vr): 최소 읽기 투표 수
• 쓰기 쿼럼(Vw): 최소 쓰기 투표 수
• 총 투표수(V)
• 작동 원리:
• 분산 시스템에 V 데이터 복제본이 있다고 가정합니다.
• 데이터 일관성을 보장하려면 읽기 및 쓰기 작업에서 노드 확인의 "쿼럼"을 얻어야 합니다.
• 핵심 규칙:
• Vr + Vw > V: 읽기-쓰기 충돌을 방지하여 동일한 데이터를 동시에 읽고 쓰지 않도록 합니다.
• Vw > V / 2: 두 개의 쓰기 작업이 동시에 데이터를 수정하는 것을 방지하여 직렬화된 데이터 수정을 보장합니다.
• Vr 및 Vw를 조정하면 시스템이 읽기 성능과 쓰기 성능 간의 균형을 맞출 수 있습니다.
• Amazon S3 소개:
• Amazon S3는 2020에서 모든 GET, PUT 및 LIST 작업에 강력한 일관성이 있다고 발표했습니다.
• 작성된 데이터를 최신 버전으로 즉시 읽을 수 있어 빅데이터 워크로드가 단순화됩니다.
• S3는 최소 3개 이상의 가용 영역에 걸쳐 데이터 복제본을 저장하는 아키텍처를 통해 높은 내구성과 가용성을 보장합니다.

지역 오류 처리

• 지역 실패(예: 지역 B 실패)가 발생하는 경우 감시 지역은 실패를 명확하게 하고 실패한 지역을 쿼럼에서 제외하도록 투표합니다.
• DSQL는 실패한 지역을 제외하도록 저널을 자동으로 재구성하여 클러스터가 정상 지역(지역 A)에서 계속 사용 가능하도록 보장합니다.
• 데이터 손실은 없으며 트랜잭션은 하나 이상의 다른 AWS 지역에 계속 복제됩니다.
• 실패한 지역(지역 B)이 다시 온라인 상태가 되면 DSQL는 이를 감지하여 최신 상태로 업데이트하고 다중 지역 구성을 복원합니다.
• 권장 패턴: 활성 중복성을 위해 두 지역의 클러스터와 함께 애플리케이션을 배포합니다.
• 활성 이중화의 이점:
• 여러 지역의 클러스터와 함께 애플리케이션을 배포하면 지연 시간이 단축되고 애플리케이션 기능이 지속적으로 검증됩니다.
• 글로벌 엔드포인트(예: Route 53 DNS 레코드)를 사용하여 가장 가까운 정상 지역으로 트래픽을 보냅니다.
• 글로벌 엔드포인트로 지역 오류 처리:
• 지역 장애가 발생해도 데이터는 손실되지 않으며 DNS는 자동으로 트래픽을 정상 지역으로 보냅니다.
• 지속적인 검증을 통해 정상 지역이 작동하는지 확인합니다.
• DSQL의 유지 관리:
• DSQL은 고객의 유지 관리가 필요 없는 완전 관리형 서비스입니다.
• 쿼리 프로세스는 정기적으로 업데이트된 버전으로 교체되어 최신 OS, 보안 패치, 성능 개선 및 기능을 보장합니다.
• 고객은 유지 관리 작업을 수행할 필요가 없습니다.
• 시사점:
• Aurora는 PostgreSQL, MySQL 및 DSQL의 세 가지 엔진을 제공합니다.
• 모든 엔진은 기본적으로 3 AZ 내구성을 제공합니다.
• 확장 옵션은 다양합니다. APG 및 AMS는 쓰기를 위해 확장하고 읽기를 위해 확장합니다. DSQL는 핸즈프리 자동 스케일링을 제공합니다.
• 다중 지역 고려 사항: APG 및 AMS를 사용하면 데이터 손실 없이 장애 조치를 테스트할 수 있습니다. DSQL는 여러 지역에서 활성-활성을 지원합니다.
• 모든 엔진은 자동화된 보안 업데이트와 마이너 버전 업그레이드를 통해 손쉬운 유지 관리를 제공합니다.