대비
(장애가 일어나기 전)
데이터 백업
1) Xtrabackup 및 mysqldump로 백업할 수 있다.
- 주로 Slave DB를 백업한다고 함
- mysqldump default 설정은 테이블 락을 거니 주의
- 크론탭으로 주기적으로 백업 가능 (새벽에 하는 걸 추천)
https://dung-beetle.tistory.com/162#google_vignette
xtrabackup vs mysqldump
| 구분 | xtrabackup | mysqldump |
|---|---|---|
| 백업 방식 | 물리적(Physical) 백업 | 논리적(Logical) 백업 |
| 백업 속도 | 빠름 (파일 단위 복사) | 느림 (SQL 구문으로 추출) |
| 복구 속도 | 빠름 (데이터 파일 복사) | 느림 (SQL 실행 필요) |
| 서버 부하 | 낮음 (비동기 I/O 기반) | 높음 (CPU, I/O 사용 많음) |
| 백업 형태 | 실제 데이터 파일 (.ibd, .frm 등) | SQL 스크립트 (INSERT, CREATE TABLE 등) |
| 설치 필요 여부 | 별도 설치 필요 | MySQL 기본 포함 |
2) aws rds 스냅샷 (주기적으로 자동 백업)
- 단일 AZ DB가 스냅샷을 생성하면 잠시 I/O가 중단 됨
- 중단되지 않으려면 다중 AZ 필요 (비용 발생)
- https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html
다중 AZ (하나의 Primary DB + 하나의 Standby DB)
- 장애 발생시 Standby가 자동으로 Primary로 승격
- 퇴근 시간동안 발생하는 매출이 다중 AZ 비용보다 크면 다중 AZ 필요
- 크지 않더라도 서비스 신뢰도가 중요하면 다중 AZ 필요
중요) Standby DB는 읽기 불가. 즉, 트래픽 분산 불가
트래픽이 날마다 점차 증가하는 추세면
영구적으로 스케일링
트래픽이 특정 시간에만 증가하면
잠깐동안 스케일링 후 원복
aws db는 스토리지 단위의 오토 스케일링을 지원한다.
컴퓨터 단위의 오토 스케일링 지원은 db 종류마다 다르다.
수동 스케일링은 db 종류와 상관없이 모두 가능
-
aws aurora db는 'auto' scale out 지원 o
aurora db 종류) MySQL, PostgreSQL, DSQL -
aws rds는 'auto' scale out 지원 x
Cloudwatch & Lambda를 기반으로 자동화 가능 (추천 x) -
aws documentDB (mongoDB)는 'auto' scale out 지원 x
Cloudwatch & Lambda를 기반으로 자동화 가능 (추천 o)
aurora 설명 캡쳐
rds 설명 캡쳐
스케일 업, 스케일 아웃 中 선택
| RDS 인스턴스 타입 | vCPU | RAM(GB) | 월 가격(₩) |
|---|---|---|---|
| db.t4g.micro | 2 | 1 | ₩13,000 |
| db.t4g.small | 2 | 2 | ₩26,000 |
| db.t4g.medium | 2 | 4 | ₩52,000 |
| db.t4g.large | 2 | 8 | ₩104,000 |
| db.t4g.xlarge | 4 | 16 | ₩208,000 |
| db.t4g.2xlarge | 8 | 32 | ₩416,000 |
| db.m5.24xlarge | 96 | 384 | ₩12,000,000 |
(2025-11-05 기준)
스케일 업과 스케일 아웃 가격은 같다
ex) t4g.mirco x 2 = t4g.small
쓰기용 db
쓰기용 db는 정합성 때문에 제공하는 최대 스펙까지 스케일 업하는게 운영하기 쉽다.
ps) 샤딩 및 다중 쓰기용 db 전략은 운영하기 어렵다
읽기용 db
읽기용 db는 스케일 아웃이 가능하지만 스케일 업하는 게 운영하기 쉽다.
ps) 근데 처리 속도는 스케일 아웃이 빠르다.
총 스펙은 동일해도, 스케일 업은 '컨텍스트 스위칭 오버헤드' 한계가 있기 때문
배치 어플리케이션이 많으면, 읽기용 db를 스케일 아웃하자
(어느 정도 스케일 업 한 상태에서)
대응
(장애가 일어난 후)
CPU 사용률이 100%일 때
- 새 요청을 처리할 여유가 없어짐
- 쿼리 처리 속도가 느려짐
- 트랜잭션 대기(락 대기) 발생
- 연결 타임아웃 에러 발생
- 보통 트래픽 다 지나가면 해결 됨
RAM 사용률이 100%일 때
- Out Of Memory 발생하여 멈춤
- 보통 재부팅해야 해결 됨
하드웨어 망가짐
- 장비 교체 후 데이터 옮기기
슬로우 쿼리
- 인덱스 적용
- 쿼리 리팩토링
번외
실수로 db 테이블 또는 row 삭제한 경우
- 기존에 백업한 파일로 복구
- 새벽부터 지금까지의 데이터는 binary log로 복구
