Amazon Web Services 한국 블로그

Amazon Aurora 내부 들여다보기(5) – Fast DDL

이 글은 AWS Database Blog의 Amazon Aurora Under the Hood: Fast DDL 의 한국어 번역으로 AWS코리아의 안효빈 솔루션즈 아키텍트가 번역해 주셨습니다.

Amazon Aurora는 MySQL과 호환되는 데이터베이스로 고성능 상용 데이터베이스의 속도와 가용성을 오픈 소스 데이터베이스의 단순성, 비용 효율성과 결합하였습니다. 이 게시물에서는 어떻게 Amazon Aurora가 MySQL에서 몇 시간이 걸리던 데이터 정의 언어(DDL)문을 즉각적으로 수행할 수 있는지 살펴보겠습니다. 이 기능은 현재 Lab mode에서 가능하며 Aurora 버전 1.12 이상을 지원합니다.

빠른 DDL이란 무엇이며, 이것이 중요합니까?
애플리케이션 변경에 따라 데이터베이스 스키마를 변경해야 합니다. 쿼리 워크로드 변경에 따라 인덱스를 추가 혹은 삭제(drop)해야 합니다. 데이터 형식(format) 변경에 따라 기존 열(column)의 데이터 형식을 변경해야 합니다. 그리고 변경은 자주 일어날 수 있습니다. Ruby on Rails 애플리케이션을 지원하는 일부 DBA는 매주 수십 개의 스키마를 변경한다고 합니다.

모든 MySQL DBA가 알고 있듯이 이러한 스키마 변경은 운영 시스템을 방해하게 되고 몇 시간에서 며칠이 걸릴 정도로 느립니다. 게다가 시스템 자원(resource)을 소모하고, 애플리케이션의 실제 처리량은 감소합니다. 장시간 실행되는 작업은 복구 시간을 지연 시킬 수 있습니다 . DDL 작업 일부는 쓰기 잠금이 필요하므로 애플리케이션의 일부를 사용할 수 없는 문제도 발생합니다. 임시 공간이 많이 필요하게 되어 작은 인스턴스의 경우는 디스크가 부족할 수 있습니다.

우리는 이러한 문제를 해결하기 위해 가장 일반적인 DDL 작업부터 시작합니다: 테이블 마지막에 null 허용(nullable) 열(column)을 추가하는 것입니다.

현재의 접근 방법이 어려운가?
MySQL이 테이블 마지막에 null 허용 열을 추가하는 방법을 살펴보겠습니다.
다음은 MySQL의 작업 순서입니다:

  1. 데이터베이스는 트랜잭션 준비 단계에서 기존 테이블에 대하여 exclusive lock을 설정합니다 .
  2. 원하는 스키마로 빈 테이블 을 생성합니다.
  3. 인덱스를 업데이트하면서 한 번에 한 행(row)씩 복사합니다. 이 시간 동안 발생하는 데이터 조작 언어(Concurrent DML)문은 임시 파일에 기록됩니다.
  4. 신규 테이블에 exclusive lock을 설정한 뒤 임시 파일에 저장한 DML작업을 적용합니다. 만약 적용 할 작업이 많은 경우 프로세스에 다소 시간이 걸립니다.
  5. 그런 다음 원본 테이블을 삭제하고 새 테이블을 원래 테이블명으로 변경합니다.

여기에는 lock과 데이터 복제와 인덱스 구성에 따른 오버헤드, I/O 및 활성 테이블의 임시 공간 등이 많이 소모됩니다.

나은 방법이 있을까?
이러한 문제에 대해 할 수 있는게 거의 없다고 생각할 수 있습니다. 결국에는 모든 행마다 데이터 형식을 변경해야 하기 때문입니다. 하지만 테이블에서 수행되는 다른 DML(그리고 연관된 I/O) 작업 과정과 함께 많은 다른 작업을 추가로 수행할 수 있습니다. 이 블로그에서 전체를 모두 다루기에는 너무 복잡하기 때문에 간단히 살펴 보겠습니다.

Aurora에서 사용자가 DDL 문을 수행할 때:

    • 데이터베이스가 INFORMATION_SCHEMA 시스템 테이블을 새 스키마로 업데이트합니다. 추가로 데이터베이스는 작업을 타임 스탬프 처리하고, 이전 스키마를 새 시스템 테이블(스키마 버전 테이블)에 기록한 뒤 이러한 변경 사항을 읽기 복제본에 전파합니다.

DDL 작업 중 다른 세션의 대기가 필요한 부분은 여기까지입니다.

그 뒤 후속 DML 작업의 영향을 받는 데이터 페이지에 보류 중인 스키마 작업이 있는지 확인합니다. 이는 페이지의 로그 시퀀스 넘버(LSN) 타임 스탬프와 스키마 변경의 LSN 타임 스탬프를 비교하여 쉽게 수행할 수 있습니다. 필요한 경우 DML 문을 적용하기 전에 페이지를 새로운 스키마로 업데이트합니다. 이 작업은 다른 모든 작업과 동일하게 redo-undo 레코드 페이지의 업그레이드 프로세스를 따릅니다. 그리고 모든 I/O는 사용자 활동에 추가됩니다.

업그레이드를 수행하면 페이지 분할이 발생할 수 있으므로 DML 작업에 대한 페이지만 업그레이드를 수행하도록 주의해야합니다. 데이터 변경을 허용하지 않는 Aurora 복제본에서도 업그레이드를 반영해야 하기 때문입니다. SELECT문 수행을 위해 MySQL로 다시 전달되는 버퍼 내 메모리 이미지를 갱신하여, 스토리지에 이전 및 신규 스키마 형식이 혼합되어 있더라도 항상 최신 스키마를 조회할 수 있습니다.

Aurora가 스토리지로부터 변경사항을 스토리지 내 읽기 쿼럼에 반영하는 방법에 관해 알고 있다면 이와 유사한 방법이란 것을 알 수 있습니다. 하지만, 이 방법은 실행 로그가 아닌 테이블을 사용하여 수행 할 변경 사항을 기록합니다.

다음은 성능 비교입니다 – Aurora는 스키마 버전 테이블만을 업데이트하므로 일정한 시간이 소요되는 것을 확인할 수 있습니다. 반대로 일반 MySQL은 테이블 크기에 따라 거의 선형적으로 DDL 작업 시간이 길어집니다.

우리가 개선해야 할 많은 DDL 작업이 있지만 대부분의 작업을 동일한 방식으로 해결할 수 있다고 확신합니다. 이것은 중요한 사안입니다 – 데이터베이스가 정상적인 가용성 범위 내에서 운영되고 있더라도, 장시간 수행되는 DDL 작업들로 인해 애플리케이션은 정상 수행될 수 없습니다. 병렬, 백그라운드 및 비동기 방식 실행이 차별점입니다.

질문이나 블로그에서 다뤄지길 바라는 주제가 있으면 aurora-pm@amazon.com로 연락을 주십시오.

– Anurag Gupta;

전체 목록

  1. Amazon Aurora 내부 들여다보기(1) – 쿼럼 및 상관 오류 해결 방법
  2. Amazon Aurora 내부 들여다보기(2) – 쿼럼 읽기 및 상태 변경
  3. Amazon Aurora 내부 들여다보기(3) – 쿼럼 집합을 이용한 비용 절감 방법
  4. Amazon Aurora 내부 들여다보기(4) – 쿼럼 구성원
  5. Amazon Aurora 내부 들여다보기(5) – Fast DDL