Amazon Aurora MySQL을 활용한 클라우드 답게 데이터베이스 운영하기

본 블로그 시리즈의 이전 글에서는 Microsoft SQL Server와 오픈소스 데이터 베이스의 차이점에 대한 정리를 살펴보았습니다. Stored Procedure 기반의 어플리케이션을 옮겨올 때, 어떠한 기능들을 활용하여 옮겨와야 하는지, 대량의 데이터 변경에 대한 작업의 처리 방법과 같은 노하우 들이 주요 내용이었습니다. 이제 오픈소스 데이터베이스의 차이점에 대해 익숙해졌다면, Amazon Aurora의 클라우드 친화적인 기능들을 활용해, 더 안정적이고, 관리 작업의 편의성을 높일 수 있는 기능들을 소개시켜 드리고자 합니다.

앞서 블로그에서 설명드린 바와 같이, Amazon Aurora는 MySQL 과 PostgreSQL과 호환되는 완전 관리형 관계형 데이터베이스 서비스입니다. 고급 상용 데이터베이스의 속도와 안정성을 추구하면서도 단순성과 비용 효율성을 추구할 수 있는 오픈소스의 장점에, 고급 스토리지 시스템으로 구현되는 데이터 처리양의 이점은, 고객들의 데이터 아키텍쳐 운영의 편의성을 높이는데 많은 이점을 제공해 드리고 있습니다. 이번 블로그에서는 그 중, 운영 편의성에 관련된 기능들을 소개시켜 드리고자 합니다.

Amazon Aurora 빠른 복제 기능 (Clone)

직접 운영하는 데이터베이스에서, 분석 쿼리를 위한 스테이징 데이터베이스를 만들거나, 작업 이전에 테스트를 수행하기 위한 복제 데이터베이스를 만드는데 수 시간을 소비해서 데이터를 복제 대상인 데이터베이스에 복구하여야 했습니다. Amazon Aurora의 분산 스토리지 구조를 활용하면, 이러한 문제를 빠르게 해결할 수 있습니다.

Amazon Aurora는 클러스터가 스토리지 클러스터에 존재하는 데이터 페이지를 참조하고 있는 구조입니다. 따라서 복제 대상이 되는 클러스터가 원본의 데이터 페이지를 참조한다면, 데이터의 실제 복제 없이도 빠르게 데이터 복제본을 만들 수 있습니다. 이를 통해, 예상치 못했던 분석 요구사항에 대한 복제 클러스터 생성이나, 변경 작업 이전의 영향도 파악, 데이터베이스의 손쉬운 이관과 같은 작업 등 에서, 수 시간이 걸리던 작업을 수 분 만에 마칠 수 있게 됩니다.

이러한 작업은 Amazon Aurora의 콘솔 메뉴에 있는 Create Clone 버튼을 선택하여, 아주 쉽게 시작할 수 있습니다. 동일한 작업을 CLI, SDK로도 수행할 수 있어, 주기적인 복제작업을 자동화 할 수도 있습니다.

Amazon Aurora 의 빠른 백업

Amazon Aurora 클러스터는 하나의 데이터 볼륨이 아닌 스토리지 클러스터에 데이터를 담습니다. 이전에 하나의 디스크 볼륨을 백업하는 프로세스보다, 스토리지 클러스터의 여러 스토리지 블록에 대해 병렬적으로 백업을 수행 함으로서, 원본 클러스터에 미치는 영향을 최소화 하면서도, 더 빠르게 백업을 완료할 수 있습니다. 또한, Amazon Aurora 의 백업은 Amazon Backups와 연계하여 관리할 수 있으며, 이 기능은 여러 계정의 Amazon Aurora 클러스터를 한 계정에서 관리할 수 있어, 여러 서비스를 운영하는 데이터베이스 엔지니어들에게 편의성을 제공합니다.

Amazon Aurora Blue/Green Deployment

Amazon Aurora의 Clone을 통한 빠른 복제기능을 위에서 살펴보았습니다. 이 기능을 활용하여, 블루/그린(Blue/Green) 배포 형태의 데이터베이스 관리 작업 기능을 활용할 수 있습니다.

기존의 스키마 변경 및 패치 작업을 상상해 보겠습니다. 기존의 클러스터에 대해 변경작업을 실험하거나, 사전 작업 절차를 검증하기 위해서는 데이터베이스 복제본을 생성하여, 이를 실험하는 과정이 필요 했습니다. Amazon Aurora는 빠른 복제 (Clone) 기능으로 이를 지원하지만, 검증을 마친 클러스터를 프로덕션으로 변경하기 위해서는, 어플리케이션 레벨의 변경이나, 내부 DNS레코드의 변경을 수반하는 복잡한 작업이 필요합니다.

Amazon Aurora의 블루/그린 배포는 이러한 과정을 완전 관리형으로 사용할 수 있도록 기능을 제공합니다. 몇 단계 과정을 거치면 프로덕션 환경을 미러링 하는 스테이징 환경이 배포 됩니다. 블루/그린 배포는 논리적 복제를 활용하여 두 환경의 데이터를 지속적으로 복제합니다. 블루와 그린 환경에서의 쓰기가 차단되면, 두 환경은 완전히 같은 데이터를 가지는 상태가 됩니다. 이 상태에서 두 환경을 전환한다면, 어플리케이션의 변경 없이, 새로운 그린 환경으로 트래픽이 전환되고 새로운 환경에 데이터가 쓰여지게 됩니다.

Amazon Aurora 역추적(Backtrack) 및 시점 복구 (PITR)

종종 데이터베이스의 데이터의 변경을 매끄럽게 복구하거나, 테스트를 위해 반복적으로 데이터를 특정 시점의 상태로 되돌려야 하는 경우가 있습니다. Amazon Aurora 의 역추적과 시점 복구는 데이터베이스 클러스터의 상태를 특정 시점으로 복구하여, 데이터 변경의 실패나 테스트 데이터 셋의 지속적인 보존에 활용할 수 있는 기능입니다.

Amazon Aurora의 시점 복구 기능은, 1일 1회 저장되는 데이터베이스 스냅샷과 5분 주기로 저장되는 데이터베이스의 변경 로그를 활용하여, 새로운 Amazon Aurora 클러스터에 데이터를 복구하는 기능입니다. 아래의 스크린 샷과 같이, 주기적인 백업을 1일 이상 생성하면, 복구할 수 있는 최신의 시간이 표시되고, 제일 최근 혹은 지정한 시간의 데이터를 가지는 클러스터를 복구하게 됩니다.

Amazon Aurora의 역추적은 Amazon Aurora 스토리지 클러스터의 변경 레코드를 병렬적으로 저장하고, 이를 지정한 시점으로 돌리는 복구 방식입니다. Amazon Aurora의 시점 복구와는 다르게, 원본 클러스터 자체가 이전 시점의 데이터를 가지도록 변경됩니다.

아래의 그림에서 SEGMENT로 표시된 데이터 블록들은 각각의 스냅샷과 log record를 저장하게 됩니다. 이 상황에서 특정 시점으로 역추적을 요청하게 되면, 이전 시점의 데이터블록 스냅샷으로 데이터 원본의 상태를 되돌리고 로그들을 병렬적으로 다시 수행하여, 원하는 시점의 데이터 상태로 클러스터 데이터 상태를 복원합니다.

두 가지 기능에는 아래 표와 같은 차이점이 있습니다. 주요 사항을 요약해 보자면, 1/ 최대로 되돌릴 수 있는 시간 지점의 차이가 있고, 2/ 데이터 원본을 직접 되돌리는지 (역추적), 새로운 Amazon Aurora 클러스터에 복원을 하는지 (시점 복구), 3/ 복구에 걸리는 시간의 차이가 있습니다.

Zero-ETL

여러 월드 및 게임에 담긴 데이터를 통합하는 일은 이전부터 데이터 엔지니어들의 주요한 고민이었습니다. 현대 데이터 아키텍쳐들은 이러한 고민들을 여러 오픈소스 솔루션들을 활용하여 지원해 왔습니다. 데이터의 수집 영역에서 Amazon Managed Service for Kafka (MSK)를 활용하거나, 데이터를 Amazon S3에 저장하고, Amazon Glue 서비스를 통해 스키마를 파악하며 가공하고, Amazon Redshift와 여러 BI 도구들을 활용하여 시각화 하는 것이 대표적인 사례입니다.

그렇지만, 이러한 대표적인 사례를 구축 하는 것도, 데이터 엔지니어들의 운영에 대한 노력, 시간, 그리고 비용을 동반합니다. Amazon Aurora는 Zero-ETL이라는 기능으로 2022년 re:Invent에서 몇 번의 클릭 만으로 Amazon Aurora 클러스터의 데이터를 Amazon Redshift로 Seamless하게 동기화 하는 기능을 발표하였습니다. 이 기능을 활용하여, 엔드유저 대상의 반응성이 중요한 트랜잭션은 Amazon Aurora에서 수행하고, 여기서 모인 데이터들을 비지니스 인사이트에 활용할 때는 Amazon Redshift로 손쉽게 옮겨, 원본 클러스터에 영향을 주지 않으면서도, 근 실시간의 시의성을 갖추어 분석할 수 있게 합니다.

Amazon Aurora Limitless Database

대규모 MMORPG 게임을 구성할 때, 여러 월드로 데이터베이스를 분리하여 구성하는 것이 대다수의 모범사례였습니다. 그렇지만, 여러 대의 데이터베이스에 동일한 변경 작업을 수행하는 것은 운영의 부담으로 작용해 왔습니다. 또한, 이렇게 분리된 데이터베이스로 인해, 더 많은 유저가 하나의 서버에서 플레이를 즐기지 못하는 단점도 발생합니다. Amazon Aurora의 Limitless Database는 자동화된 수평 확장을 지원하여 초당 수백만 건의 쓰기 트랜잭션을 처리하고 단일 Aurora 데이터베이스에서 페타바이트 규모의 데이터를 관리할 수 있도록 지원하는 새로운 기능입니다.

Amazon Aurora Limitless Database는 테이블의 데이터를 샤드키 기준으로 자동으로 분산하여, 읽기 용량을 자동으로 확장할 때도, 중단 없이 데이터의 분포가 내부에서 자동으로 변경되는 이점을 가집니다. 또한, 데이터가 분산된 테이블과 참조를 위한 테이블을 명시적으로 지정하여, 자주 사용하는 데이터는 불필요한 분산으로 인한 오버헤드를 줄이도록 설정할 수 있습니다.

결론

이 블로그에서는 Amazon Aurora의 운영에 도움이 되는 6가지 기능을 살펴보았습니다. 오픈소스의 도입으로 단순성과 비용 효율성을 추구하면서도, 고급 관리 기능을 놓치지 않기 위해 꼭 활용해야 할 기능들입니다. 주요 내용을 운영 시나리오와 합쳐 살펴보면 아래와 같습니다.

• 빠른 복제 (Clone) : 예상치 못한 데이터의 분석, 스테이징 환경 구성, 또는 변경 작업에 대한 사전 검증 용도로 활용
• 빠른 백업 (Fast Backup) : 원본에 영향을 주지 않고서도, 주기적인 백업을 관리. 백업의 중앙 집중화 관리로, 규제 요구사항도 충족
• 블루/그린 배포 (Blue/Green Deployment) : 데이터베이스의 변경 작업의 다운타임을 최소화, 미리 그린 환경에 변경 및 패치 작업들을 수행하여, 사전 안정성 검증
• 역추적 및 시점 복구 (Backtrack & Point-in-time Recovery) : 반복적인 성능테스트, 여러 팀에게 테스트 데이터 셋 배포, 또는 변경 작업의 실수를 복구
• Zero-ETL : OLTP 데이터 액세스 패턴과 OLAP 데이터 액세스 패턴을 근 실시간 파이프라인으로 분리하여, 성능 안정적이면서도, 시의성 있는 데이터 분석 환경 제공
• Limitless Database (2024년 10월 기준 미리보기) : 여러 데이터베이스를 하나의 클러스터로 통합하고, 온라인 샤딩 기능을 활용. 손쉬운 수평 확장 기능을 RDBMS에서도 사용

Amazon Aurora의 여러 기능들을 활용한다면, 이전 인스턴스 기반의 데이터베이스의 확장 한계점으로 인해 겪었던 문제점을 손쉽게 해결할 수 있는 방안을 찾을 수 있을 것입니다.

이 글은 SQL Server to Amazon Aurora MySQL in Game Development 시리즈 블로그의 일부로 작성되어 있습니다. 시리즈의 모든 글들은 아래 링크들을 따라가시면 읽어보실 수 있습니다.

• 저장 프로시저 중심 아키텍처에서 벗어나 클라우드 데이터베이스 적응하기
• Aurora MySQL 성능 검증 직접 해보기 (업로드 예정)
• Game 개발시 Aurora MySQL을 사용하는 과정에서 SQL Server와 달라 주의할 점들에 대한 가이드 (업로드 예정)
• Amazon Aurora MySQL을 활용한 클라우드 답게 데이터베이스 운영하기
• Amazon Aurora MySQL의 여러 관리 도구를 SQL Server Management Studio 와 비교하기
• Amazon Aurora MySQL 오해와 진실