목차
1. Intro.
2. Aurora란?
3. 기존 DB와 Aurora의 가장 중요한 차이
4. 왜 Aurora를 사용해야 하는지?
5. Decoupled Computing and Storage
- Aurora 전체 구조
- Storage 구조
6. Recovery
7. Backup
1. Intro.
Aurora는 기존 DB가 가지는 painpoint를 해결하기 위해 나온 서비스이다. 가장 큰 painpoint는 Computing과 Storage가 같이 있다는 것이다. 그래서 Aurora를 이해하는 핵심은 Storage 구조에 있다. 해당 구조가 기존 DB와 가장 큰 차이점이고 해당 구조로 인해 cloud에서 기존 DB보다 약 5배 이상 높은 성능을 보일 수 있기 때문이다.
이글에서는 Aurora 구조, 특히 Storage 구조를 중심으로 성능 효율성과 Recovery와 Backup 중심으로 안정성을 알아보겠다.
2. Aurora란?
- 일반적인 설명은 mysql을 클라우드 환경에 적합하도록 AWS에서 제공하는 RDBMS 서비스라고 할 수 있다.
- 구체적인 설명으로는 Log Stream 기반의 공유 분산 스토리지 기반의 기존 RDBMS를 뛰어넘는 확장성 및 안정성을 확보할 수 있는 cloud native RDBMS이다.
3. 기존 DB와 Aurora의 가장 중요한 차이
- Storage에 있다.
- Aurora는 Storage가 분리되어 있음
- 기존 DB는 같이 있다.
4. 왜 Aurora를 사용해야 하는지?
- 대략 7배 정도의 I/O 횟수가 줄어든다.
- 30배 이상의 throughput(시간당 처리량)이 증가한다.
- Storage 분리로 인해 높은 확장성(Flexibility)
- Recovery와 Backup 시스템으로 인해 높은 안정성(Reliability)
5. Decoupled Computing and Storage
- 연산을 위한 computing과 데이터 저장을 위한 storage는 근본적으로 라이프사이클이 다를 수밖에 없다. 그래서 Computing과 Storage를 분리하였다.
- Storage 영역에서는 128TB까지 안정적으로 자동 확장이 가능
- 공유분산 스토리지로 6개의 복제본을 만들어 쓰기작업이 왔을 때 해당 작업을 병렬처리한다.
- 여러 스토리지 노드가 논리적인 하나의 스토리지 볼륨이 되어 각 computing node에 공유되는 구성으로 storage내에서 발생하는 I/O 작업이 분산되어 병렬처리됨을 의미
- storage내에서는 각각의 데이터가 서로 다른 물리적 위치에 있는 storage node에 6개의 복제본을 구성함으로써 데이터의 가용성을 극대화한다. 이러한 복제본의 논리적 집합을 protection group이라 부른다.
- protection group은 10GB 사이즈로 구성되며 self-healing, crash recovery, backup, auto-scaling의 기본 단위가 되는 중요하고 논리적인 객체
- 6-way 복제방식 - 물리적으로 분리된 6개의 복제본을 통한 데이터 가용성 확보는 computing 영역의 부하 없이 스토리지 내에서 수행된다.
- quorum 방식(최소한의 개수)의 읽기 및 쓰기 방식을 사용한다.
읽기의 경우 3개 쓰기의 경우 4개가 있어야 사용이 가능하다.
1) 3개 이상 잃어버리기 전에 쓰기 능력 유지 - 2개까지 잃어버려도 된다는말.
2) 4개 이상 잃어버리기 전에는 읽기 능력 유지 - 3개까지 잃어버려도 된다는말.
Decoupled Storage 방식의 문제점은?
- Computing과 Storage 간의 네트워크 구성으로 인해 I/O 성능이 취약해짐
해결책 - Log Stream
- log를 활용한다.
- 데이터 변경에 대한 기록
- 이러한 변경에 대한 기록으로 데이터를 생성해 낼 수 있다.
- 각 트랜잭션에서 발생한 변경 기록을 통해 해당 데이터 블록을 최신의 데이터 상태로 생성/유지 할 수 있다.
Storage 구조
*일반적인 RDBMS 경우
- 일반적인 RDBMS의 I/O는 computing node의 메모리를 이용해 해당 데이터 및 로그를 처리하고 메모리 상의 변경된 데이터와 스토리지에 있는 데이터간 sync를 하기 위한 checkpoint를 발생시킨다. 이러한 체크포인트는 컴퓨팅과 스토리지 간의 데이터의 일관성을 확보하지만 주기적으로 대량의 I/O를 발생시키고 이에따른 성능상 불이익을 발생시킨다.
*Aurora Storage 경우
- 각 스토리지 노드에서 레코드는 먼저 인-메모리(in-memory) 큐에 들어갑니다. 이 큐의 로그 레코드는 중복 제거됩니다. 예를 들어, 마스트 노드가 스토리지 노드에 성공적으로 쓰고 난 후, 마스터 노드와 스토리지 노드 사이의 연결이 중단 된 경우 마스터 노드는 로그 레코드를 재전송 하지만 중복된 로그 레코드는 폐기됩니다. 보관할 레코드는 핫 로그(hot log)에서 디스크에 저장됩니다.
- 레코드가 지속 된 후, 로그 레코드는 업데이트 큐라는 인-메모리 구조에 기록됩니다. 업데이트 큐에서 로그 레코드는 먼저 병합 된 다음 데이터 페이지로 만들어 집니다. 하나 이상의 로그 시퀀스 번호(LSN)가 누락 된 것으로 판단되면 스토리지 노드는 볼륨의 다른 노드에서 누락 된 LSN을 검색하는 프로토콜을 사용합니다. 데이터 페이지가 갱신 된 후 로그 레코드가 백업되고 가비지 컬렉션으로 표시됩니다. 그리고 데이터 페이지는 비동기식으로 Amazon S3에 백업됩니다.
- 핫 로그에 기록되어 쓰기가 지속되면 스토리지 노드는 데이터 수신을 확인합니다. 6개 스토리지 노드 중 4개 이상이 수신 확인을 하면 쓰기 작업은 성공한 것으로 간주되고 답신은 클라이언트 애플리케이션에 반환됩니다.
- Amazon Aurora가 다른 엔진보다 빠르게 쓸 수 있는 이유 중 하나는 스토리지 노드에만 로그 레코드를 보내고 이러한 쓰기 작업이 병렬로 수행된다는 것입니다. 실제로 MySQL과 비교할 때, Amazon Aurora는 데이터가 6개의 다른 노드에 쓰여지고 있지만 유사한 워크로드 대해 IOPS가 약 1/8 정도 필요합니다.
- 이 모든 작업의 단계는 비동기적으로 진행됩니다. 쓰기는 지연을 줄이고 처리량을 향상시키기 위해 그룹 커밋(Group Commit)을 사용하여 병렬로 수행됩니다.
쓰기 대기 시간이 짧고 입출력 풋프린트(footprint)가 줄어든 Amazon Aurora는 쓰기 집약적인 애플리케이션에 이상적입니다.
K = 1,000
M = 100만
6. Recovery
- Tx1 이후에 checkpoint가 수행되고 Tx4 중간에 장애가 발생한다면, 기존의 RDBMS 구조에서는 아직 Storage와 sync되지 않은 Tx2, Tx3 Tx4에 대해 redo와 undo작업을 수행하며 시스템 복구를 수행한다.
- 이에 반해 aurora는 이미 Tx1에서 Tx4 까지의 변경 log와 Tx의 완료 여부를 통해 해당 데이터 블록의 최신 버전을 Storage에 병렬로 생성해 내기에 별도의 시스테 복구없이 시스템을 빠르게 운영상태로 복구할 수 있다.
redo: 복구(다시 하다)
undo: 원상태로 돌리다. - 작업 롤백, 읽기 일관성, 복구
둘 다 공통적으로 복구 한다는 의미
checkpoint: 검사점 - log, 메모리에 있는 버퍼 캐시에서 변경된 후 실제 disk에는 반영되는 지점을 의미
7. Backup
- storage layer에서 snapshot과 log를 주기적으로 5분 단위의 간격을 가지고 S3에 백업하는 것으로 수행된다.
- 이 것은 aurora의 PG(protection Group) 단위로 이루어지며 각 PG의 snapshot 및 log 백업은 병렬로 이루어진다.
- aurora 백업의 핵심은 병렬과 PG 단위라는 것으로 빠른 수행을 보장할 뿐만 아니라 변경되지 않은 블록에 대한 작업이 없기에 효율적으로 수행된다.
- 이러한 구조는 computing node의 부하를 없애고 storage 백업의 I/O를 효율적으로 사용함으로써 백업을 빠르고 손쉽게 사용가능
references
https://aws.amazon.com/ko/blogs/database/
https://www.youtube.com/watch?v=7_VXMqYixS4&t=1053s
https://aws.amazon.com/ko/blogs/korea/databaseintroducing-the-aurora-storage-engine/
https://aws.amazon.com/ko/getting-started/hands-on/aurora-autoscaling-with-readreplicas/
https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.Endpoints.html
https://aws.amazon.com/ko/blogs/aws/additional-failover-control-for-amazon-aurora/
https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-parallel-query.html
https://aws.amazon.com/ko/getting-started/hands-on/migrate-rdsmysql-to-auroramysql/
https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.html
https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html
'AWS' 카테고리의 다른 글
| Amazon Aurora with Custom url(domain) 연결 안되는 이슈 (0) | 2022.11.22 |
|---|---|
| Amazon Aurora + spring boot + java + maven (0) | 2022.11.22 |
| The clusterInstanceHostPattern configuration property is required (0) | 2022.11.21 |
| VPC 주요 개념들 (0) | 2022.10.20 |
| AWS Backup 사용방법 (1) | 2022.09.08 |