[AWS Hero 스페셜] RDS to Aurora PostgreSQL Migration - 변규현(당근마켓) :: AWS Community Day Online 2020

RDS to Aurora PostgreSQL
Migration
변규현 / 개발자, 당근마켓

2020.10.17 | AWS Community Day Online | Aurora Postgres | 변규현
발표자 소개
• 당근마켓 채팅플랫폼 개발자
• AWS Serverless Hero
• Go언어를 주로 사용함
• 개발을 잘하고 싶어함

RDS를 쓰고 계시나요?

그럼 RDS를 왜 쓰시나요?

RDS의 특징
• 데이터 베이스 설치에 대한 부담이 없음
• 데이터 베이스 업그레이드, Backup 및 확장에 대해서 부담이 없음
(Maintenance, Scalability, Replication)
• Multi AZ를 통한 고가용성
• IOPS에 따른 스토리지 선택 가능
(Magnetic, SSD, Provisioned IOPS Storage)
• Security Group을 통한 접근 제어
• IAM을 통한 사용자 제어 가능
• MySQL, MariaDB, PostgreSQL, Oracle, MSSQL Server 지원

RDS PostgreSQL에서 겪었던 어려움

RDS PostgreSQL에서 겪었던 어려움
• Replica를 직접 설정하고 관리
(Replica 생성 > Rout53 가중치 기반 레코드 설정)
-> 인스턴스 추가할 때 마다 Route53 에서 설정 필요
• Replica instance가 5대로 제한
• 저장공간을 직접 늘려주어야 함
(Storage autoscaling 기능을 사용할 수 있음)

처음에는 운영상 어려움은 없었어요
서비스가 크지 않다면
RDS PostgreSQL로 충분해요

그런데, 우리는 빠르게 성장하고 있었어요
DB 부하는 매주 높아지고 있었고,
이를 더욱 잘 대응하기 위한 준비가 필요했어요.

Migration 이전 RDS PostgreSQL의 CPU
2019.07.10 ~ 2019.07.15

Aurora PostgreSQL은 해답이 될 수 있을까

Amazon Aurora의 특징
• MySQL 데이터 베이스보다 최대 5배 많은 처리량 지원
• 표준 PostgreSQL 보다 3배 많은 처리량 지원
• 1/10 비용으로 상용 데이터베이스의 보안, 가용성 및 안정성 제공
• RDS의 기본 기능 모두 사용 가능
• 분산 스토리지 시스템으로, 인스턴스당 최대 128TB까지 자동 확장
• Replica 15개 사용 가능
• 3개의 AZ에 걸친 복제
• 손쉬운 Custom Endpoint 설정
• 빠른 마스터 복원
• IOPS 사용량에 따른 과금

가장 와닿은 내용들
- 처리량
- 스토리지
- Replica 15개
- 빠른 마스터 복원

Migration을 준비하기로 결정했어요.

근데, Migration은 어떻게 준비하나요?

Migration할 인스턴스에 대해서
Aurora PostgreSQL을 Read Replica로 생성

준비는 이게 전부에요.

그리고 Migration은 신중해야하니
연습을 했어요

Migration 연습
• 연습환경 만들기
• 백업 AMI로 RDS 복구
• 네트워크 설정 확인
(Security Group, Subnet Group, VPC)
• Aurora PostgreSQL로 복제본 생성
• Migration Simulation
• 트래픽 완전 차단(Webserver, Security Group)
• 웹서버 DB Endpoint 수정
• Aurora PostgreSQL을 Master로 승격

각 스테이지 별 적용 및 테스트 완료!
Production Migration Simulation 5회

연습한 대로 Migration을 시작했어요
Aurora PostgreSQL을 Master로 승격시키고
모니터링을 했어요.

문제는 없었을까요?

DB가 3번 재시작했어요

RDS Performance Insight와 PGHero 를 통해
특정 쿼리가 해결되지 않고
계속 남아있는 것을 발견했어요.

SELECT pg_terminate_backend(PID);
이걸로도 죽지 않는 쿼리가 있었어요.

전체 트래픽을 차단하고
워커도 전부 중지시켰다고 생각했는데,
Migration 시점에 워커 하나가 동작하고 있었어요

Hanging Query가 있었고,
그 쿼리들은 워커에서 사용한 테이블들과 연관이 있었어요.
더 살펴보니, 이 테이블들의 인덱스를
사용하는 쿼리들만 문제가 있었어요

관련된 테이블들의 Index에 대해서
REINDEX를 진행하고,
다시 모니터링을 시작했어요.

이후의 Aurora PostgreSQL CPU

REINDEX 명령어를 통해
깨졌던 인덱스가 복구되고,
문제가 되었던 Index 범위의 쿼리들도
정상적으로 처리되기 시작했어요! 😊

복구를 성공적으로 완료했어요 🎉

Aurora로 전환하고
어떤 점이 개선되었을까요?

1년 운영 후기

1년 간 느낀점
• 대규모 이벤트 진행 또는 급작스런 트래픽 증가에 대해
Read replica를 사용한 유연한 대응이 용이함
• Custom Endpoint를 활용한 서비스별 커넥션 관리 가능
• 용량 확장 및 IOPS에 대한 고민 사라짐
• 빠른 Master DB 복구
(AZ 장애 발생 시 알람과 동시에 복구됨)
• Performance Insight를 통한 Slow Query 대응
• 빠르고 유연한 확장이 가능하기 때문에 DB인스턴스 CPU 및 Memory를 피크 시간
기준 50% 이상 사용
• 테이블 삭제시 1초도 안돼서 명령이 종료됨

현재 운영중인 Aurora PostgreSQL CPU
• Writer 1대
• Reader for webserver
7대
• 데이터 분석용 1대

운영을 하는 부담이 많이 줄었네요!

Aurora를 도입해보는 건 어떨까요?

마지막으로...

에서
함께할 분을 찾고 있어요 😊
dngn.kr/join-us-dev

감사합니다!
Email: novemberde1@gmail.com
Blog: novemberde.github.io
Github: github.com/novemberde

[AWS Hero 스페셜] RDS to Aurora PostgreSQL Migration - 변규현(당근마켓) :: AWS Community Day Online 2020

Recommended

Recommended

More Related Content

More from AWSKRUG - AWS한국사용자모임

More from AWSKRUG - AWS한국사용자모임 (20)

[AWS Hero 스페셜] RDS to Aurora PostgreSQL Migration - 변규현(당근마켓) :: AWS Community Day Online 2020