Amazon Aurora MySQL 성능/특성 정리: Reader 확장, Failover, Lag, connection storm 대응

Amazon Aurora MySQL 성능/특성 정리: Reader 확장, Failover, Lag, connection storm 대응

이 글은 Amazon Aurora MySQL를 성능/운영 관점에서 길게 정리한 개인 노트입니다. 목표는 "지금 느린 이유"를 증거로 좁히고, 재발을 줄이는 체크리스트를 갖추는 것입니다.

전제: 성능은 DB만으로 결정되지 않습니다. 쿼리 패턴, 데이터 분포, 인덱스/스키마, 애플리케이션 트랜잭션 경계, 인프라(IO/네트워크)가 함께 결정합니다. 그래서 이 글은 '성능 모델(어디서 시간이 쓰이나) -> 설계/쿼리 -> 설정 -> 운영' 순서로 정리합니다.

Aurora MySQL은 '스토리지 분리 + 멀티 AZ 복제'로 운영 편의성이 강하지만, 애플리케이션은 failover/엔드포인트/리더 지연을 전제로 설계해야 합니다.

이 DB를 언제 선택하나

정답은 항상 케이스 바이 케이스지만, 선택을 빠르게 만들기 위해 기준을 먼저 둡니다. 아래에 해당이 많을수록 이 DB를 고려할 만합니다.

- MySQL 호환을 유지하면서도 고가용성(HA)과 운영 자동화를 강화하고 싶을 때
- 스토리지 장애/복구를 최대한 관리형으로 넘기고 SLA에 집중하고 싶을 때
- 리더(읽기 전용) 확장으로 읽기 트래픽을 분산하고 싶을 때

성능 모델: 어디서 시간이 쓰이나

Aurora는 컴퓨트(인스턴스)와 스토리지(클러스터 볼륨)가 분리된 형태로 생각하면 이해가 빠릅니다. 쓰기는 Writer로 들어가고, 읽기는 Reader로 분산할 수 있습니다.

성능 이슈는 1) 연결/재시도(특히 failover), 2) reader lag(읽기 일관성), 3) 쿼리/인덱스(결국 MySQL과 동일), 4) 관측(Performance Insights/CloudWatch)로 나뉩니다.

Aurora를 쓴다고 인덱스/쿼리 튜닝이 사라지지 않습니다. 다만 운영 관점에서 장애 전환과 엔드포인트 전략이 필수 과제가 됩니다.

핵심 용어 빠른 사전

성능/장애 분석에서 자주 쓰는 단어는 팀마다 다르게 이해되기 쉽습니다. 용어를 짧게 정의하고, 어떤 지표/증상과 연결되는지 같이 적어둡니다.

용어	설명	실무에서 연결되는 것
Writer	쓰기 가능한 인스턴스	장애 전환 시 Writer가 바뀌며 커넥션 재수립 필요
Reader	읽기 전용 인스턴스	읽기 확장/분산, 다만 lag/일관성 고려
Cluster Endpoint	클러스터 단위 엔드포인트	인스턴스 교체/failover를 애플리케이션에서 흡수
Reader Endpoint	Reader 라우팅 엔드포인트	읽기 전용 트래픽을 분산
Failover	Writer 장애 시 승격	재시도/풀 정책이 없으면 장애가 길어짐
Reader Lag	Writer 대비 적용 지연	read-after-write가 필요한 기능은 위험

옵션/핵심 요소(3~6)

자주 부딪히는 핵심 요소를 표로 먼저 고정해 두면, 장애/튜닝 때 팀 커뮤니케이션이 빨라집니다.

항목	의미	언제 쓰는지(실무 상황)
Cluster Endpoint	Writer/Reader를 추상화하는 엔드포인트	인스턴스 교체/failover를 애플리케이션에서 흡수할 때
Reader Endpoint	Reader 인스턴스로 라우팅	읽기 트래픽을 분산할 때
Failover	Writer 장애 시 새 Writer로 승격	재시도/풀 정책을 설계해야 할 때
Reader Lag	Writer 대비 Reader 적용 지연	쓰기 직후 읽기 정합성이 필요한 기능
Performance Insights	쿼리/대기 이벤트 기반 분석	병목이 CPU인지 락/IO인지 분리할 때
Parameter Group	MySQL 파라미터 설정	InnoDB 설정/로그/캐시를 조정할 때

실무 튜닝 포인트(설정/옵션별)

설정에는 정답이 없습니다. 워크로드(읽기/쓰기/동시성/데이터 크기) 기준으로 관측하고 조정합니다. 아래는 실무에서 가장 자주 만지는 레버를 '항목별'로 정리한 것입니다.

max_connections
의미: 동시 연결 상한
언제 만지나: 연결 폭증을 막고 풀링 기반으로 안정화할 때
주의/트레이드오프: 상한을 늘리면 실패를 늦출 뿐이고 풀링 설계가 같이 필요

innodb_buffer_pool_size
의미: 버퍼 풀 크기
언제 만지나: 읽기 IO가 많고 메모리 여유가 있을 때
주의/트레이드오프: 인스턴스 클래스/메모리 압박(다른 캐시) 고려

innodb_flush_log_at_trx_commit
의미: commit 내구성/지연 정책
언제 만지나: 내구성과 지연을 균형 잡을 때
주의/트레이드오프: 요구사항 문서화 + 장애 테스트로 검증 필요

wait_timeout
의미: 유휴 커넥션 종료
언제 만지나: 유휴 연결이 늘어나는 환경
주의/트레이드오프: 풀링과 충돌하면 재연결 폭증 가능

net_read_timeout
의미: 읽기 타임아웃
언제 만지나: failover/네트워크 흔들림에서 빨리 실패
주의/트레이드오프: 너무 짧으면 정상 쿼리도 실패 가능

net_write_timeout
의미: 쓰기 타임아웃
언제 만지나: 큰 결과/네트워크 불안정에서 빠른 실패
주의/트레이드오프: 환경에 따라 조정 필요

slow_query_log
의미: 느린 쿼리 로그
언제 만지나: PI와 함께 개선 루프를 만들 때
주의/트레이드오프: 로그 비용/보관 정책 고려

binlog_format
의미: 바이너리 로그 포맷
언제 만지나: 복제/CDC 요구에 맞출 때
주의/트레이드오프: row 기반은 로그가 커질 수 있음

쿼리/스키마 설계에서 성능이 갈리는 지점

Aurora MySQL에서 스키마/쿼리 튜닝은 기본적으로 MySQL(InnoDB)와 동일한 원칙을 따릅니다. 차이는 읽기 스케일을 Reader로 나누는 순간 기능별 일관성 요구가 달라진다는 점입니다.

결제 직후 조회 같은 기능은 Writer 또는 강한 일관성 경로를 쓰고, 검색/피드/대시보드 같은 기능은 Reader로 보내는 식의 라우팅이 흔합니다. 즉, 튜닝은 쿼리뿐 아니라 트래픽 라우팅 설계까지 포함됩니다.

-- writer/reader 상태를 확인할 때(진단용)
SHOW VARIABLES LIKE 'read_only';

-- 쿼리 튜닝은 MySQL 방식으로 EXPLAIN부터
EXPLAIN SELECT * FROM orders WHERE user_id = 42 ORDER BY created_at DESC LIMIT 50;

진단 명령/쿼리 모음(바로 실행용)

장애 때는 문서 찾을 시간이 없습니다. 아래는 현장에서 자주 쓰는 '첫 5분' 진단 명령/쿼리만 모은 것입니다. 환경/권한에 따라 일부는 제한될 수 있습니다.

-- 1) Writer/Reader 여부(진단용)
SHOW VARIABLES LIKE 'read_only';

-- 2) 커넥션 수/상태(기본 MySQL 방식)
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Threads_running';

-- 3) 상위 쿼리/대기 이벤트는 Performance Insights로 확인(콘솔/지표)
-- CloudWatch/PI에서 failover 이벤트 시점과 오류율/재시도 폭주를 함께 본다

자주 하는 실수(운영/튜닝)

실수 체크리스트:
- 인스턴스 엔드포인트에 고정 연결(핀ning)해서 failover를 못 따라간다
- 재시도(backoff) 없이 무한 재시도로 장애를 증폭시킨다
- read-after-write가 필요한 기능까지 Reader로 보내 일관성 이슈를 만든다
- 커넥션 풀에서 failover 감지 시 커넥션 폐기(evict) 규칙이 없다
- PI/CloudWatch 없이 슬로우 쿼리만 보고 원인을 단정한다
- Writer 부하가 높은데도 Reader만 늘려 해결하려 한다(쓰기 병목은 별개)

운영/모니터링 체크리스트

운영 체크는 1) failover 발생 시 오류율/재시도 폭주 여부, 2) reader lag, 3) PI 상위 대기 이벤트, 4) 커넥션 수(풀 상태), 5) 스토리지/IO 지표를 우선으로 둡니다.

failover는 DB가 살아났는데 애플리케이션이 못 따라간 상태를 만들기 쉽습니다. 커넥션 풀, 엔드포인트 캐시, 재시도(backoff) 전략을 같이 검증해야 합니다.

공통 체크리스트:
- 느린 쿼리 top N을 지속 수집(시간/호출수/총시간)
- 지연(p95/p99)과 오류율을 애플리케이션 지표와 함께 본다
- 캐시/메모리/디스크 IO 중 무엇이 병목인지 먼저 분리한다
- 복제/HA를 쓰면 일관성 요구가 높은 기능을 분리한다
- 튜닝/변경 후에는 동일 조건으로 재측정해 회귀를 막는다

트러블슈팅 루틴(순서 고정)

장애 때는 선택지가 너무 많아서 흔히 길을 잃습니다. 아래 순서를 팀 표준으로 정해두면, 원인 추적이 빨라지고 '감으로 설정만 만지는' 일을 줄일 수 있습니다.

1) 오류율/타임아웃 증가를 먼저 확인한다(애플리케이션 관점)
2) Performance Insights로 병목 타입(CPU/락/IO)을 분리한다
3) Reader를 쓰는 기능이면 reader lag과 라우팅을 점검한다
4) 엔드포인트 캐시/DNS TTL/풀 재사용 때문에 failover가 지연되지 않는지 본다
5) 쿼리 문제면 EXPLAIN/인덱스/통계를 MySQL 방식으로 튜닝한다
6) 조치 후 강제 failover 리허설로 검증한다

문제 상황(정확히 1개)

상황 -> 장애 전환 이후 서비스는 살아났는데, 특정 서버에서만 DB 타임아웃이 수분간 계속된다.
원인 -> 커넥션 풀이 기존 Writer 커넥션을 쥐고 있고, 엔드포인트 캐시로 새 Writer로 재연결이 지연됐다.
해결 -> failover 감지 시 커넥션을 폐기(evict)하도록 풀 설정/로직을 조정하고, 엔드포인트 기준으로 재연결되게 한다.
예방 팁 -> 정기적인 failover 리허설과 TTL/풀 정책/재시도 규칙 문서화를 팀 공통 규칙으로 유지한다.

참고/출처

정확한 동작/버전별 차이는 공식 문서를 기준으로 확인합니다. 실무에서는 버전 차이가 곧 성능/장애 차이입니다.

• Amazon Aurora User Guide
• Aurora MySQL
• Performance Insights