이 글을 읽고 계시다면 아마 Amazon Aurora에 대해 들어보셨을 것입니다. 아시다시피, Amazon Aurora는 AWS에서 RDS 서비스 제품군의 일부로 제공하는 PaaS 서비스입니다. 두 가지 유형(MySQL 및 Postgres)으로 제공되는 완전 관리형 관계형 데이터베이스 관리 시스템(RDBMS)을 제공하는 동시에 두 가지와의 유선 호환성을 유지합니다. 그러나 이것이 고가용성 전략 및 옵션에 어떤 영향을 미칩니까?
Amazon Aurora가 Amazon RDS의 MySQL 또는 PostgreSQL과 어떻게 다른지 궁금할 수 있습니다. 이것들도 완전히 관리되는 RDBMS 서비스입니다. 맞습니까? 예, 하지만 기본적으로는 다수의 EC2 인스턴스에서 실행되고 AWS에서 관리하는 표준 오픈 소스 구현입니다. Aurora와의 주요 차이점은 AWS가 데이터베이스 엔진에서 스토리지 엔진을 분리했다는 것입니다. AWS는 관심사 분리 원칙을 오픈 소스 데이터베이스에 적용했습니다.
관심의 분리
일반적으로 RDBMS는 일반적으로 사용 가능한 하드웨어에서 실행되어야 합니다. 즉, DML 및 DDL 처리, ACID 호환 트랜잭션, 복제, 고가용성(HA), 내결함성. 그러나 구현이 일반적으로 사용 가능한 하드웨어에서 실행될 필요가 없고 데이터베이스용으로 특별히 설계된 환경에서만 실행되어야 한다면 다양한 책임을 계층으로 분리하여 데이터베이스 엔진과 스토리지 엔진에 집중하고 전문화할 수 있습니다. 결과적으로 고가용성 및 성능이 크게 향상될 수 있습니다. MySQL보다 최대 5배, 표준 PostgreSQL보다 최대 3배 더 뛰어난 성능을 제공합니다.
좋습니다. 더 빠르지만 특수 데이터베이스 및 스토리지 엔진이 HA에 어떻게 도움이 될까요? 이것이 HA를 달성하는 데 도움이 되는 몇 가지 방법이 있습니다. 이에 대해 알아보기 전에 Aurora 스토리지 엔진이 어떻게 작동하는지 간단히 살펴보고 이러한 분리에서 HA가 파생되는 방식을 이해하겠습니다.
데이터가 Aurora 스토리지 엔진에 기록될 때 엔진은 데이터가 일관되고 정확하며 지속적으로 기록되는지 확인합니다. 데이터는 총 6개의 다른 위치에 대해 3개의 가용 영역 각각의 2개 위치에 기록됩니다. 스토리지 엔진은 이 모든 것이 올바르게 발생하는지 확인하는 복잡성을 처리합니다. 약간의 과장이 있을 수 있지만 본질적으로 데이터베이스 엔진은 이제 데이터, 트랜잭션 로그, 복구 가능성 등에 대해 더 이상 걱정할 필요가 없도록 "실행 후 잊어버릴 수" 있습니다.
데이터베이스 엔진에서 스토리지 문제를 제거하여 여러 HA 전략을 사용할 수 있게 되었습니다.
읽기 복제본
읽기 전용 복제본의 개념은 Aurora보다 오래 전에 구현되었지만 오픈 소스 솔루션이 아닌 구현에는 로그 전달 또는 쿼리 재생이 포함됩니다. Aurora를 사용하면 ReadReplicas는 마스터와 정확히 동일한 스토리지에 대한 읽기 전용 액세스 권한을 갖습니다. 즉, 데이터가 기록된 시간부터 읽기 전용 복제본에 표시될 때까지 복제 대기 시간이 매우 적습니다(이 시나리오에서는 복제 지연이 잘못된 명칭이 됨). 여러 개의 읽기 전용 복제본이 필요한 경우 모든 읽기 전용 복제본은 동일한 데이터를 확인하여 표준 MySQL 및 PostgreSQL 구현에서 발견되는 마스터에 가해지는 오버헤드와 복잡성을 제거합니다. 이러한 기능을 함께 사용하면 마스터가 실패할 경우 읽기 전용 복제본이 즉시 인계할 수 있습니다. 또한 AWS는 프로비저닝된 용량을 충족하기 위해 실패한 인스턴스를 새 인스턴스로 교체하고 새 마스터를 가리키도록 DNS를 업데이트합니다.
이는 읽기 대 쓰기 비율이 높은 애플리케이션에 적합한 솔루션입니다. 그러나 기본 인스턴스는 전체 쓰기 로드를 처리할 수 있을 만큼 충분히 커야 합니다. 또한 쓰기 HA의 경우 마스터와 동일한 크기의 읽기 전용 복제본을 하나 이상 프로비저닝하려고 합니다. 그런 다음 이 읽기 전용 복제본을 기본 인스턴스로 승격할 우선 순위 인스턴스로 설정합니다. 장애가 발생한 경우 읽기 및 쓰기 용량 모두에 대해 고가용성을 유지합니다.
자동 확장
자동 확장은 사용 가능한 서버 집합에서 수평으로 확장(인스턴스 추가) 또는 축소(인스턴스 제거)하는 기능입니다. EC2 인스턴스용 Autoscaling에 대해 들어본 적이 있을 수 있지만 Aurora 읽기 전용 복제본에도 탄력성을 가질 수 있다는 사실을 알고 계셨습니까? 일반적으로 기본 로드를 처리하고 수요 변화에 따라 인스턴스를 추가하거나 제거하는 자동 확장 정책을 갖도록 읽기 전용 복제본의 최소 수를 구성합니다. 탄력성을 활용하는 능력은 스토리지 엔진이 데이터베이스 엔진과 분리되어 있다는 사실에서 파생된 또 다른 요소입니다.
이것이 유용한 예시 시나리오는 B2B 전자상거래 사이트입니다. 평일 업무 시간에는 교통 체증이 심하지만 야간 및 주말에는 거의 발생하지 않습니다. 이미지와 콘텐츠 설명은 읽기-쓰기 비율이 높으며 읽기 전용 복제본과 자동 크기 조정의 이점이 있습니다. ReadReplicas를 자동 확장하면 사용량이 많은 시간에 수요를 충족하는 동시에 업무 외 시간의 비용을 최소화할 수 있습니다.
지역 간 복제
가용성을 한 단계 끌어올려야 하는 경우 다른 지역에 복제하십시오. 데이터베이스 엔진이 데이터를 다른 지역에 복제하도록 함으로써 로컬에서 읽거나 주 지역에 장애가 발생한 경우 사용할 수 있습니다. 보조 지역의 인스턴스는 읽기 전용 복제본으로 처리되지만(다중 마스터가 아님) 자체 읽기 전용 복제본을 가지거나 기본 지역에서 장애가 발생한 경우 마스터가 될 수도 있습니다.
교차 리전 복제가 필요한 데는 여러 가지 이유가 있습니다. 때때로 데이터는 단일 지리적 지역에 저장하기에는 너무 중요합니다. 이는 비즈니스 연속성, 규제 또는 재정적 이유 때문일 수 있습니다. 또 다른 이유는 사용자와 데이터베이스 백엔드 간의 대기 시간 감소입니다. 전자 상거래를 다시 한 번 예로 들면 이미지 및 설명의 변경 사항을 단일 지역의 마스터에 적용할 수 있지만 로컬에서 읽기 위해 전역으로 배포할 수 있습니다.
외부 복제
Aurora 클러스터 외부의 데이터가 필요한 상황은 어떻습니까?기업 정책 또는 규제 환경에서 이를 요구하거나 데이터를 처리하거나 Aurora 외부에서 보고서를 실행해야 하는 상황이 있습니다. 이러한 모든 경우는 다음을 사용하여 처리할 수 있습니다. 외부 복제.
Aurora가 데이터를 Amazon EC2 MySQL 인스턴스, MySQL을 실행하는 Amazon EC2 인스턴스 또는 기업 데이터 센터에서 실행되는 MySQL 인스턴스에 복제하도록 하는 것은 쉽습니다. 이 단방향 복제를 사용하면 데이터가 항상 Aurora 클러스터와 동기화되고 Aurora 외부에서 사용할 수 있습니다.
서버리스
마지막으로 중요한 것은 서버리스입니다. 가용성 및 확장성을 위한 가장 중요한 개발 중 하나는 방정식에 서버리스를 추가한 것입니다. 분명히 서버리스가 서버가 없다는 것을 의미하지는 않습니다. 즉, 서버의 프로비저닝, 구성, 확장 또는 유지 관리에 대해 걱정할 필요가 없습니다.
Aurora Serverless를 구성하려면 애플리케이션에 사용 가능한 용량을 지정하면 AWS가 클라이언트가 필요할 때 온디맨드 방식으로 용량을 사용할 수 있는지 확인하는 세부 정보를 처리합니다. 서버리스의 경우 데이터베이스 엔진과 스토리지 엔진이라는 두 개의 기존 레이어에 추가 레이어인 프록시 레이어가 추가되었습니다.
AWS는 수신 요청을 수신하는 프록시 서버 집합을 유지 관리합니다. 또한 DB 용량의 웜 풀이 요청을 처리하기 위해 기다리고 있습니다. 첫 번째 쿼리가 들어오면 프록시 집합이 이를 수신하고 웜 풀에서 인스턴스를 요청하고 사용을 위해 할당된 후 해당 인스턴스로 요청을 전달합니다. 더욱이 사용에 할당된 인스턴스의 수는 탄력적이며 Aurora Serverless 구성에서 지정한 제한과 수요에 따라 확장 및 축소됩니다. 이전 전략과 마찬가지로 데이터베이스 엔진을 동적으로 할당하는 기능은 데이터베이스와 저장소를 분리하여 가능합니다. 구성에 따라 데이터베이스 인스턴스는 사용자에게 할당된 상태로 유지되며 즉시 사용할 수 있습니다. 제한 시간이 만료되면 인스턴스가 웜 풀로 반환됩니다. 사용 중인 리소스에 대해서만 요금이 부과됩니다. 인스턴스가 사용을 위해 할당되면 해당 인스턴스와 사용된 스토리지에 대한 요금이 부과됩니다. 할당되지 않은 경우 사용된 스토리지에 대해서만 요금이 부과됩니다.
개발 및 테스트 환경과 같이 사용량이 많은 워크로드 또는 사용 패턴을 예측할 수 있는 충분한 기록이 없는 새로운 애플리케이션의 경우 서버리스가 적합합니다. 사용하지 않는 리소스에 대해 더 이상 비용을 지불하지 않아도 됩니다. 주말에 출발하기 전에 개발 팀이 불을 켰는지 확인하는 것에 대해 걱정할 필요가 없습니다. ' 시간대는 귀하의 sleepzone과 일치합니다.
마무리
Amazon Aurora는 가용성, 내구성 및 확장성을 염두에 두고 구축되었습니다. 표준 오픈 소스 구현처럼 사용하면 견고하고 안정적이며 성능이 뛰어난 데이터베이스를 갖게 됩니다. Aurora의 기능과 이를 활용하는 패턴을 조금 더 자세히 살펴보면 로컬 읽기 오프로딩에서 전 세계적으로 분산된 가용성에 이르기까지 요구 사항을 충족하는 솔루션을 구현할 수 있습니다.
피드백 탭을 사용하여 의견을 남기거나 질문하십시오.