커넥션이 많다고 다 좋은 게 아니다 애플리케이션 서버를 오토스케일링으로 늘렸는데 갑자기 데이터베이스 응답이 느려지는 상황을 겪어본 적이 있다면, 원인이 CPU나 디스크가 아니라 "커넥션 수 자체"였던 경험도 있을 것입니다.
카테고리
Database
총 6편의 글
쿼리 튜닝, 인덱스, 파티셔닝, 마이그레이션처럼 데이터베이스 운영 안정성과 성능을 좌우하는 주제를 다룹니다.
- 적용 대상
- 서비스 데이터 모델과 운영 쿼리를 책임지는 개발자
- 주요 초점
- 쿼리 분석스키마 변경성능 검증
인덱스가 없으면 느리고, 잘못 만들면 더 느리다 MongoDB를 프로덕션에서 처음 운영해보는 팀은 대개 비슷한 경험을 합니다. 로컬에서는 순식간에 응답하던 쿼리가 실 데이터가 수백만 건을 넘어서면서 갑자기 수 초씩 걸리기 시작하고, "인덱스를 추가하면 되겠지"라는 생각에 db.collection.
SQLite가 프로덕션용으로 적합한 워크로드 SQLite를 프로덕션에서 쓴다는 말을 꺼내면 종종 이런 반응이 돌아옵니다. "그거 테스트용 아닌가요?" 하지만 이 인식은 현실과 상당히 멀어져 있습니다.
스키마 변경은 코드 배포보다 오래 남는다 애플리케이션 코드는 잘못 배포해도 이전 버전으로 되돌릴 수 있습니다. 하지만 데이터베이스 스키마 변경은 되돌리기 어렵습니다. 컬럼을 삭제했는데 이전 버전 서버가 아직 그 컬럼을 읽고 있다면 즉시 장애가 납니다. 타입을 바꿨는데 오래 떠 있는 워커가 예전 형식으로 쓰기를 계속하면 데이터가 섞입니다.
큰 테이블은 어느 순간 운영 방식이 달라진다 PostgreSQL에서 테이블이 수천만 행을 넘어가면 단순 인덱스 추가만으로 해결되지 않는 문제가 생깁니다. 최근 7일 데이터만 자주 보는데도 인덱스와 통계는 전체 테이블 크기의 영향을 받고, 오래된 데이터를 삭제하려면 VACUUM이 길게 돌고, 월말 집계 배치가 실행 계획을 흔듭니다.
새벽 2시에 울린 알럿: 명절 정산 배치가 멈췄던 그 밤 설 연휴 직전이었습니다. 평소 새벽 1시에 시작해 1시간 안에 끝나던 정산 배치가 그날따라 2시가 넘어도 돌아가고 있었습니다. PagerDuty 알럿이 울렸고, 슬랙에는 SRE 온콜 담당자의 메시지가 쏟아졌습니다. 필자의 경험으로는 급하게 접속해 APM 대시보드를 열었습니다.