Amazon Aurora 스토리지 및 안정성 - Amazon Aurora

Amazon Aurora 스토리지 및 안정성

다음에서 Aurora 스토리지 하위 시스템에 대해 자세히 배울 수 있습니다. Aurora는 Aurora 클러스터의 성능, 확장성 및 안정성에 중요한 요소인 분산 및 공유 스토리지 아키텍처를 사용합니다.

Amazon Aurora 스토리지 개요

Aurora SSD(Solid State Drive)를 사용하는 단일 가상 볼륨인 클러스터 볼륨에 저장됩니다. 클러스터 볼륨은 동일한 AWS 리전에 속한 세 가용 영역의 데이터 사본으로 구성되어 있습니다. 이러한 가용 영역에서 데이터가 자동으로 복제되기 때문에 데이터 손실 가능성은 줄고 오히려 내구성이 크게 높아집니다. 이러한 복제를 통해 장애 조치 중에도 데이터베이스의 가용성이 높아집니다. 데이터 사본이 이미 나머지 가용 영역에 존재하여 DB 클러스터의 DB 인스턴스에 대한 데이터 요청을 계속 처리할 수 있기 때문입니다. 복제 양은 클러스터의 DB 인스턴스 수와는 관계가 없습니다.

Aurora는 비영구 임시 파일에 대해 별도의 로컬 스토리지를 사용합니다. 여기에는 쿼리 처리 중 대용량 데이터 세트를 정렬하고 인덱스를 작성하는 등의 목적으로 사용되는 파일이 포함됩니다. 자세한 내용은 Aurora MySQL에 대한 임시 스토리지 한도Aurora PostgreSQL에 대한 임시 스토리지 한도 단원을 참조하세요.

클러스터 볼륨에 포함된 항목

Aurora 클러스터 볼륨에는 모든 사용자 데이터, 스키마 객체, 내부 메타데이터(예: 시스템 테이블 및 이진 로그)가 포함되어 있습니다. 예를 들어 Aurora는 클러스터 볼륨의 Aurora 클러스터에 대한 모든 테이블, 인덱스, BLOB(Binary Large Object), 저장 프로시저 등을 저장합니다.

Aurora 공유 스토리지 아키텍처는 데이터를 클러스터의 DB 인스턴스와 독립적으로 만듭니다. 예를 들어 Aurora가 테이블 데이터의 새 복사본을 만들지 않으므로 DB 인스턴스를 빠르게 추가할 수 있습니다. 대신에 DB 인스턴스는 이미 모든 데이터를 포함하는 공유 볼륨에 연결됩니다. 클러스터에서 기본 데이터를 제거하지 않고 클러스터에서 DB 인스턴스를 제거할 수 있습니다. 전체 클러스터를 삭제하는 경우에만 Aurora가 데이터를 제거합니다.

Amazon Aurora DB 클러스터의 스토리지 구성

Amazon Aurora에는 다음과 같은 두 가지 DB 클러스터 스토리지 구성이 있습니다.

  • Aurora I/O-Optimized – I/O 집약적 애플리케이션을 위해 향상된 가격 대비 성능 및 예측 가능성을 제공합니다. 읽기 및 쓰기 I/O 작업에 대한 추가 비용 없이 DB 클러스터의 사용량 및 스토리지에 대한 비용만 지불하면 됩니다.

    Aurora I/O-Optimized는 I/O 지출이 총 Aurora 데이터베이스 지출의 25% 이상인 경우 가장 좋은 선택입니다.

    Aurora I/O-Optimized 클러스터 구성을 지원하는 DB 엔진 버전으로 DB 클러스터를 생성하거나 수정할 때 Aurora I/O-Optimized를 선택할 수 있습니다. 언제든지 Aurora Standard에서 Aurora I/O-Optimized로 전환할 수 있습니다.

  • Aurora Standard – I/O 사용량이 보통인 많은 애플리케이션을 위한 비용 효과적인 요금을 제공합니다. DB 클러스터의 사용량 및 스토리지 외에도 I/O 작업에 대해 요청 1백만 건당의 표준 요금이 부과됩니다.

    Aurora Standard는 I/O 지출이 총 Aurora 데이터베이스 지출의 25% 미만인 경우 가장 좋은 선택입니다.

    30일마다 한 번 Aurora Standard에서 Aurora I/O-Optimized로 전환할 수 있습니다. Aurora Standard에서 Aurora I/O-Optimized로, 또는 Aurora I/O-Optimized에서 Aurora Standard로 전환해도 다운타임이 발생하지 않습니다.

AWS 리전 및 버전 지원에 대해 자세히 알아보려면 Aurora 클러스터 스토리지 구성 섹션을 참조하세요.

Amazon Aurora 스토리지 구성 요금에 대해 자세히 알아보려면 Amazon Aurora 요금을 참조하세요.

DB 클러스터를 생성할 때 스토리지 구성을 선택하는 방법에 대한 자세한 내용은 DB 클러스터 생성 섹션을 참조하세요. DB 클러스터에 대한 스토리지 구성을 수정하는 방법에 대한 자세한 내용은 Amazon Aurora에 대한 설정 섹션을 참조하세요.

Aurora 스토리지 크기가 자동으로 조정되는 방법

데이터베이스의 데이터 용량이 늘어날수록 Aurora 클러스터 볼륨도 자동 확장됩니다. Aurora 클러스터 볼륨의 최대 크기는 DB 엔진 버전에 따라 128테비바이트(TiB) 또는 64TiB입니다. 특정 버전의 최대 크기에 대한 자세한 내용은 Amazon Aurora 크기 제한 섹션을 참조하세요. 이 자동 스토리지 조정은 고성능의 고도로 분산된 스토리지 하위 시스템을 통해 이루어집니다. 따라서 주요 목표가 안정성과 고가용성인 경우 중요한 엔터프라이즈 데이터에 Aurora를 선택하면 좋습니다.

볼륨 상태를 표시하려면 Aurora MySQL DB 클러스터를 위한 볼륨 상태 표시 또는 Aurora PostgreSQL DB 클러스터를 위한 볼륨 상태 표시 섹션을 참조하세요. 스토리지 비용과 다른 우선 순위의 균형을 맞추려면 스토리지 조정에서 CloudWatch를 통해 Amazon Aurora 지표 AuroraVolumeBytesLeftTotalVolumeBytesUsed를 모니터링하는 방법을 참조하세요.

Aurora 데이터가 제거되면 해당 데이터에 할당된 공간이 복원됩니다. 데이터 제거의 예로는 테이블 삭제 또는 자르기 등이 있습니다. 이렇게 스토리지 사용량이 자동으로 줄어들면 스토리지 요금을 최소화할 수 있습니다.

참고

여기서 설명하는 스토리지 제한 및 동적 크기 조정 동작은 클러스터 볼륨에 저장된 영구 테이블 및 기타 데이터에 적용됩니다.

Aurora PostgreSQL의 경우 임시 테이블의 데이터가 로컬 DB 인스턴스에 저장됩니다.

Aurora MySQL 버전 2의 경우 임시 테이블 데이터는 기본적으로 라이터 인스턴스의 경우 클러스터 볼륨에, 리더 인스턴스의 경우 로컬 스토리지에 저장됩니다. 자세한 내용은 온디스크 임시 테이블에 대한 스토리지 엔진 섹션을 참조하세요.

Aurora MySQL 버전 3의 경우 임시 테이블 데이터는 로컬 DB 인스턴스 또는 클러스터 볼륨에 저장됩니다. 자세한 내용은 Aurora MySQL 버전 3의 새로운 임시 테이블 동작 섹션을 참조하세요.

로컬 스토리지에 있는 임시 테이블의 최대 크기는 DB 인스턴스의 최대 로컬 스토리지 크기로 제한됩니다. 로컬 스토리지 크기는 사용하는 인스턴스 클래스에 따라 다릅니다. 자세한 정보는 Aurora MySQL에 대한 임시 스토리지 한도Aurora PostgreSQL에 대한 임시 스토리지 한도 섹션을 참조하십시오.

클러스터 볼륨의 최대 크기 및 데이터 제거 시 자동 크기 조정과 같은 일부 스토리지 기능은 클러스터의 Aurora 버전에 따라 다릅니다. 자세한 내용은 스토리지 조정 섹션을 참조하세요. 또한 스토리지 문제를 방지하는 방법과 클러스터에서 할당된 스토리지와 사용 가능한 공간을 모니터링하는 방법을 배울 수 있습니다.

Aurora 데이터 스토리지 요금이 청구되는 방법

Aurora 클러스터 볼륨은 최대 128 tebibytes (TiB)까지 확장될 수 있지만 요금은 Aurora 클러스터 볼륨에서 사용한 공간에 대해서만 청구됩니다. 이전 Aurora 버전에서는 데이터를 제거할 때 복원된 공간을 클러스터 볼륨이 다시 사용할 수 있지만 할당된 스토리지 공간은 줄어들지 않습니다. 이제 테이블이나 데이터베이스를 삭제하는 등의 방법으로 Aurora 데이터가 제거되면 비슷한 양만큼 할당된 전체 공간이 감소합니다. 따라서 더 이상 필요하지 않은 테이블, 인덱스, 데이터베이스 등을 삭제하면 스토리지 요금을 줄일 수 있습니다.

작은 정보

동적 크기 조정 기능이 없는 이전 버전의 경우 클러스터의 스토리지 사용량을 재설정하려면 논리적 덤프를 수행하고 새 클러스터로 복원하는 절차가 필요했습니다. 데이터 양이 많을 경우 이 작업은 오랜 시간이 걸릴 수 있습니다. 이러한 상황이 발생하면 클러스터를 동적 볼륨의 크기 조정을 지원하는 버전으로 업그레이드하는 것이 좋습니다.

동적 크기 조정을 지원하는 Aurora 버전과 클러스터의 스토리지 사용량을 모니터링하여 스토리지 요금을 최소화하는 방법에 대한 내용은 스토리지 조정 단원을 참조하세요. Aurora 백업 스토리지 요금에 대한 자세한 정보는 Amazon Aurora 백업 스토리지 사용량 파악 단원을 참조하세요. Aurora 데이터 스토리지에 대한 요금 정보는 Amazon RDS for Aurora 요금을 참조하세요.

Amazon Aurora 안정성

Aurora는 안정성, 내구성 및 내결함성을 고려하여 설계되었습니다. Aurora DB 클러스터는 Aurora 복제본을 추가하여 다른 가용 영역에 배포하는 등의 방법으로 가용성을 높이도록 설계할 수 있습니다. 그 밖에도 Aurora에는 안정적인 데이터베이스 솔루션을 위한 자동 기능이 몇 가지 포함되어 있습니다.

스토리지 자동 복구

Aurora는 3개의 가용 영역에 여러 개의 복사본을 보관하고 있기 때문에 디스크 결함으로 인한 데이터 손실 가능성이 최소화됩니다. 또한 Aurora는 클러스터 볼륨을 구성하는 디스크 볼륨에서 장애를 자동으로 감지합니다. 예를 들어 디스크 볼륨 세그먼트에 결함이 발생하면 Aurora가 즉시 해당 세그먼트를 복구합니다. Aurora가 디스크 세그먼트를 복구할 때는 동일한 클러스터 볼륨을 구성하는 나머지 디스크 볼륨의 데이터를 사용하기 때문에 복구 세그먼트의 데이터도 이용 가능합니다. 결과적으로 Aurora는 데이터 손실을 방지할 뿐만 아니라 특정 시점으로 복구 기능을 사용해 디스크 결함을 복구할 필요성도 줄어듭니다.

유지 가능한 페이지 캐시

Aurora에서는 각 DB 인스턴스의 페이지 캐시가 데이터베이스와 별도의 프로세스로 관리되며, 이를 통해 페이지 캐시가 데이터베이스와 상관없이 유지됩니다. (페이지 캐시는 Aurora MySQL에서는 InnoDB 버퍼 풀, Aurora PostgreSQL에서는 버퍼 캐시라고도 합니다.)

드문 경우이지만 데이터베이스 장애가 발생할 경우, 페이지 캐시는 메모리에 남아 데이터베이스가 재시작될 때 현재 데이터 페이지를 페이지 캐시에 '웜' 상태로 유지합니다. 이렇게 하면 페이지 캐시를 '워밍업'하기 위해 초기 쿼리가 읽기 I/O 작업을 실행할 필요가 없으므로 성능이 향상됩니다.

Aurora MySQL의 경우 재부팅 및 장애 조치 시 페이지 캐시 동작은 다음과 같습니다.

  • 버전 2.10 이전 - 라이터 DB 인스턴스가 재부팅되면 라이터 인스턴스의 페이지 캐시는 그대로 유지되지만, 리더 DB 인스턴스의 페이지 캐시는 손실됩니다.

  • 버전 2.10 이상 – 리더 인스턴스를 재부팅하지 않고 라이터 인스턴스를 재부팅할 수 있습니다.

    • 라이터 인스턴스가 재부팅될 때 리더 인스턴스가 재부팅되지 않으면 페이지 캐시가 손실되지 않습니다.

    • 라이터 인스턴스가 재부팅될 때 리더 인스턴스가 재부팅되면 페이지 캐시가 손실됩니다.

  • 리더 인스턴스가 재부팅되면 라이터 및 리더 인스턴스의 페이지 캐시가 모두 유지됩니다.

  • DB 클러스터가 장애 조치될 때 이 효과는 라이터 인스턴스가 재부팅될 때와 유사합니다. 새 라이터 인스턴스(이전 리더 인스턴스)에서는 페이지 캐시가 유지되지만, 리더 인스턴스(이전 라이터 인스턴스)에서는 페이지 캐시가 유지되지 않습니다.

Aurora PostgreSQL의 경우 클러스터 캐시 관리를 사용하여 장애 조치 후 라이터 인스턴스가 되는 지정된 리더 인스턴스의 페이지 캐시를 보관할 수 있습니다. 자세한 내용은 장애 조치 후 Aurora PostgreSQL용 클러스터 캐시 관리를 통한 신속한 복구 섹션을 참조하세요.

예기치 않은 재시작 시 복구

Aurora는 예기치 않은 재시작에서 거의 즉각적으로 복구하여 바이너리 로그 없이 애플리케이션 데이터를 계속 제공하도록 설계되었습니다. Aurora는 병렬 스레드에서 비동기적으로 복구를 수행하여 데이터베이스가 열리고 예기치 않은 재시작 후 즉시 사용할 수 있도록 합니다.

자세한 정보는 Aurora DB 클러스터의 내결함성데이터베이스 재시작 시간 단축을 위한 최적화 섹션을 참조하십시오.

다음은 Aurora MySQL에서의 바이너리 로깅 및 예기치 않은 재시작 복구 시 고려 사항입니다.

  • Aurora 바이너리 로깅을 활성화하면 DB 인스턴스로 하여금 강제로 바이너리 로그 복구를 수행하도록 하므로 예기치 않은 재시작 후 복구 시간에 직접적인 영향을 줍니다.

  • 사용되는 이진 로깅 유형은 로깅의 크기와 효율에 영향을 미칩니다. 데이터베이스 활동의 양이 동일하더라도 형식에 따라 이진 로그에서 더 많은 정보가 로깅됩니다. 다음과 같은 binlog_format 파라미터 설정으로 로그 데이터의 양이 달라집니다.

    • ROW – 최대 로그 데이터

    • STATEMENT – 최소 로그 데이터

    • MIXED – 일반적으로 데이터 무결성과 성능의 최상의 조합을 제공하는 적당량의 로그 데이터

    이진 로그 데이터의 양은 복구 시간에 영향을 미칩니다. 이진 로그에 로깅된 데이터가 더 많은 경우, DB 인스턴스는 복구 도중 더 많은 데이터를 처리해야 하므로 복구 시간이 길어집니다.

  • 이진 로깅으로 계산 오버헤드를 줄이고 복구 시간을 개선하기 위해 향상된 binlog를 사용할 수 있습니다. 향상된 binlog는 데이터베이스 복구 시간을 최대 99% 개선합니다. 자세한 내용은 향상된 binlog 설정 섹션을 참조하세요.

  • Aurora은 DB 클러스터 내에서 데이터를 복제하거나 특정 시점 복원(PITR)을 수행하기 위해 바이너리 로그를 필요로 하지 않습니다.

  • 외부 복제(또는 외부 이진 로그 스트림)에 이진 로그가 필요하지 않은 경우, binlog_format 파라미터를 OFF로 설정하여 이진 로깅을 비활성화하는 것이 좋습니다. 이렇게 하면 복구 시간이 단축됩니다.

Aurora 이진 로깅 및 복제에 대한 자세한 내용은 Amazon Aurora를 사용한 복제 단원을 참조하십시오. 다양한 MySQL 복제 유형의 영향에 대한 자세한 내용은 MySQL 설명서의 Advantages and Disadvantages of Statement-Based and Row-Based Replication을 참조하세요.