엔지니어링

최소한의 다운타임으로 아마존 RDS Aurora DB로 이전하기

Avatar
Harry Kim Chief Technology Officer
Share

Get Started!

Sign up for a full-featured 30 day free trial. No credit card required.

Free Trial

안녕하세요. 센드버드의 CTO인 김여신 입니다.

센드버드는 퍼시스턴트 스토리지로(Persistent Storage)로 RDBMS인 마리아 디비 10을 사용하고 있었습니다. 기존 MySQL의 Drop-in replacement이면서 InnoDB 스토리지 엔진의 성능향상 버전인 XtraDB 엔진을 사용하여, 기존 MySQL의 장점 및 향상된 성능을 모두 이용할 수 있다는 점에서 매력적이었습니다.

마리아 디비를 사용하면서 큰 성능상의 이슈는 없었습니다. 다만, 성능 외적인 부분에서 서비스를 운영하며 아래와 같은 여러 문제점에 직면하였고, 오로라 디비가 제공하는 기능등을 이용하면 이런 문제들을 해결할 수 있어 이전을 결정하게 되었습니다.

오로라 디비는 MySQL과 호환되며 오로라 엔진을 채용하여 퍼포먼스와 신뢰도를 향상시킴으로 기존 MySQL 클라이언트를 그대로 적용할 수 있다는 장점이 있습니다.

MariaDB를 이용하면서 만난 문제점들

1. 백업

주기적으로 백업을 하여 S3에 올리는 방식을 사용하고 있었습니다. 서비스가 커지고 사용자가 늘어나면서 데일리 백업 용량과 시간이 무시못할 정도로 증가하기 시작합니다.

2. 레플리카 생성

테스트를 위한 디비를 생성하거나 새로운 레플리카를 생성하기 위해 새로운 인스턴스를 생성하고 기존 마스터에서 데이터를 덤프 받아 레플리카에 리스토어하는데 며칠의 시간이 걸리기 시작합니다.

3. Failover

일반적인 마스터-레플리카(Master-Replica) 설정에서 Failover를 달성하기 위해서는 마스터의 장애를 발견하고 레플리카의 복제를 끊고 기존 서버들의 설정을 모두 레플리카 서버로 수정 후 재시작을 하는 등 사람의 지속적인 개입을 필요로 합니다.

4. 하드웨어 예측

AWS나 기타 다른 Cloud 하드웨어를 사용하는 이유중 하나인 온디맨드(On-Demand) 하드웨어 증설이 힘들어 집니다. 미래의 트래픽 증가를 감안하여 추후 다운타임(Downtime)을 최소하 하기 위해 필연적으로 스토리지 용량과 하드웨어를 필요 이상의 티어(Tier)를 선택할 수 밖에 없습니다.

오로라 디비로 이전 후 개선된 사항들 

1. 백업

백업 시간을 지정하면 해당 시간대에 스냅샷 형태로 저장이 되며  백업된 스냅샷으로 새로운 RDS 인스턴스를 생성할 수 있습니다.

2. 레플리카 생성

원 클릭으로 생성이 가능하며 보통 10분 이내에 10ms 이하의 Lag을 가지고 완벽히 동작하는 레플리카를 구성 할 수 있습니다.

3. Failover

기본적으로 오로라 디비는 클러스트로 구성이 되며 원 버튼 클릭만으로 1~2분 내에 레플리카를 마스터로 승격 시킬 수 있습니다. 여기서 중요한 점은 구 마스터 도메인의 아이피가 자동으로 새롭게 승격된 새로운 마스터로 변경되므로 서버 설정을 수정할 필요가 없습니다. DNS 캐시 타임이 문제가 될 수 있으므로 Java의 경우 DNS 캐시 타임을 JVM에서 조정을 해줘야 합니다. [http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html]

4. 하드웨어 예측

오로라 디비의 경우 스토리지 용량이 증가함에 따라 64TB까지 자동으로 증설이 되므로 스토리지 용량을 미리 부터 정해야 할 필요가 없습니다. 하드웨어의 경우에도 Failover 기능을 이용하여 1~2분의 다운타임만으로 다음 티어의 하드웨어로 업그레이드를 할 수 있으니 서비스의 방향에 따라 유동적으로 하드웨어를 조정할 수 있습니다.

최소한의 다운타임으로 오로라 디비로 이전하기

오로라 디비로 이전을 결정 후 최소한의 다운타임으로 디비를 이전 할 수 있는 방법을 찾아야 했습니다.

다행히 오로라 디비의 경우 일반적인 MySQL 5.6과 동일하며 스토리지 엔진이 오로라 엔진으로 변경된 형태이므로 기존 MySQL의 레플리카로 동작할 수 있습니다. 이 기능을 이용하여 현재 디비의 레플리카로 오로라 디비를 설정한 후 복제가 완료되는 시점에서 마스터로 승격시키는 순서로 작업을 진행 하였습니다.

이전 시나리오는 다음과 같습니다.

  • 오로라 인스턴스 생성
  • 오로라 인스턴스를 기존 디비의 레플리카로 지정
  • 복제가 완료된 후 서비스 셧다운
  • 오로라 인스턴스를 마스터로 승격
  • 서비스의 디비 설정을 오로라 디비로 변경 후 재시작

위의 시나리오를 따를 경우 서비스 셧다운 시점부터 설정 변경 재시작 까지의 시간만큼의 서비스 다운타임이 필요하게 되므로 비교적 짦은 시간에 오로라 디비로의 이전이 가능했습니다. [http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.NonRDSRepl.html]

오로라 DB 이전의 결과

오로라로 이전한 후 다음과 같은 기능등을 이용하여 기존 문제가 되던 부분을 쉽게 해결 할 수 있었습니다.

  • 백업을 이용하여 즉시 디비 인스턴스를 생성할 수 있으며 배포 전 테스트를 위한 임시 디비 생성을 위한 시간이 비약적으로 단축 되었습니다.
  • 원 클릭 Failover 기능으로 인해 고가용성을 확보할 수 있었습니다.
  • CloudWatch API를 이용하여 오로라 디비의 모든 메트릭을 상세히 사내 대시보드에 통합할 수 있습니다.
  • 하드웨어의 변경에 따른 부담이 감소하여 최적화된 코스트의 장비를 선택할 수 있었습니다.

다만 오로라 디비로 이전을 생각하시는 분들은 다음의 문제점들을 확인해 보셔야 할 것 같습니다.

  • 기본 설정의 Max Connection이 최대 메모리 사용량을 기준으로 잡혀서 생각보다 적게 잡혀 있습니다. 더 높은 숫자로 수동 변경이 필요합니다.
  • CPU 사용률이 높습니다. 기존 마리아 디비를 이용한 EC2 인스턴스에 비해 2~3배 정도 많은 CPU를 필요로 하는것 같습니다. 오로라 엔진만의 문제인지 RDS의 기본적인 성능의 문제인지 정확히 파악되지 않았습니다.
  • RDS 인스턴스외 스토리지 용량과 I/O횟수에 따른 추가 과금이 존재합니다. 스토리지 용량 과금은 무시할만한 수준이지만 I/O별 과금의 경우 초기 데이터를 오로라로 리스토어 하는 경우 생각보다 높은 가격이 나올 수 있습니다. [https://aws.amazon.com/rds/aurora/pricing/]

오로라 디비(Aurora DB)는?

아마존에서 제공 하는 MySQL 호환성을 가지고 더 높은 성능과 향상된 기능을 제공하는 AWS RDS(Relational Database Service) 서비스 중 하나입니다.

오로라 디비는 기존 RDS에 비해 자동 스토리지 용량 증설, 로우 레이턴시 복제기능, 향상된 Failover 등 향상된 성능을 제공하며 또한 아마존은 기존 MySQL대비 최대 5배의 성능 향상도 제공한다며 광고중입니다. [https://aws.amazon.com/rds/aurora/faqs/]

센드버드?

센드버드는 모바일 앱/ 웹사이트를 위한 실시간 메시징 솔루션입니다. 크로스 플랫폼의 개발환경을 지원하며, 현재 iOS, 안드로이드, 유니티3D 엔진 및 웹(JavaScript) SDK와 서버API를 제공하고 있습니다.

Categories: 엔지니어링

Tags: Engineering