db 서버 비교는 쿼리와 복구 시간부터 계산하는 방법

얼마 전 월 방문자 3만 명인 사이트가 데이터베이스를 분리해야 하느냐고 물었다. 서버가 느려진 건 맞았지만, 원인은 서버 크기가 아니었다. 검색 화면에서 인덱스가 빠진 쿼리 하나가 매번 테이블 전체를 읽고 있었다. 이런 경우 요금제를 올려도 잠깐 여유가 생길 뿐이다. db 서버 비교는 방문자 수보다 실제 쿼리와 장애 때 필요한 복구 시간을 먼저 보는 편이 정확하다.

방문자 수를 초당 쿼리로 바꾸기

하루 페이지 조회가 3만 회이고 페이지마다 데이터베이스 쿼리가 평균 3번 실행된다면 하루 9만 건이다. 평균으로는 초당 약 1건이지만, 접속이 몰리는 시간에는 다르다. 순간 부하가 평균의 20배라면 초당 약 21건을 처리해야 한다. 여기에 관리자 작업, 예약 작업, 검색 요청이 겹치는지도 확인한다. 방문자 3만 명이라는 숫자만으로는 이 차이를 알 수 없다.

측정할 값은 초당 쿼리 수, 느린 쿼리의 실행 시간, 동시에 실행 중인 쿼리 수, 메모리 사용량, 디스크 읽기·쓰기 대기 시간이다. 접속 수와 실행 중인 쿼리 수는 구분해야 한다. 애플리케이션이 접속을 50개 열어 둬도 실제로 쿼리를 실행하는 접속은 몇 개뿐일 수 있다. 반대로 동시 실행이 적어도 한 쿼리가 몇 초씩 잠금을 잡으면 사용자는 사이트가 멈췄다고 느낀다.

위 예시의 초당 21건이 모두 30밀리초 안에 끝난다면 단순 계산상 평균 동시 실행량은 1건 미만이다. 실제 용량은 쿼리 시간의 상위 구간, 트랜잭션 잠금, 갑작스러운 유입을 반영해 잡는다. 최소 며칠치 지표와 가장 바쁜 시간대의 느린 쿼리 기록을 보고 판단하는 이유다.

공유형부터 관리형까지 비용 비교하기

작은 블로그나 회사 소개 사이트라면 웹호스팅에 포함된 데이터베이스로 충분한 경우가 많다. 비용이 낮고 운영할 항목도 적다. 다만 동시 접속, 저장 용량, 백업 보관 기간에 제한이 있을 수 있으니 숫자로 확인해야 한다. 쿼리 기록이나 서버 설정을 직접 다룰 수 없다면 성능 문제를 추적하기 어려울 수도 있다.

단일 VPS에 웹서버와 데이터베이스를 함께 두면 설정과 로그를 직접 볼 수 있다. 유입이 크지 않고 운영자가 백업을 관리할 수 있다면 합리적인 선택이다. 대신 웹 요청이 메모리를 많이 쓰는 날에는 데이터베이스 캐시가 밀리고, 한 서버의 장애가 사이트 전체 장애로 이어진다. 데이터베이스를 별도 VPS로 옮기면 자원을 나눌 수 있지만 서버 요금과 내부 통신, 방화벽, 백업 작업이 추가된다.

관리형 데이터베이스는 자동 백업, 장애 감시, 일부 복구 기능을 제공한다. 운영 시간을 아끼거나 복구 시간을 짧게 잡아야 할 때 비용을 지불할 이유가 생긴다. 그렇다고 모든 서비스에 이중화가 포함되는 것은 아니다. 월 요금을 비교할 때는 기본 서버 비용뿐 아니라 저장 공간, 백업 저장량, 데이터 전송량, 대기 서버 비용까지 같은 조건으로 계산해야 한다.

CPU보다 먼저 메모리와 디스크를 확인하기

초기 규모의 전용 데이터베이스라면 2 vCPU와 메모리 4GB부터 측정해 보는 경우가 많다. 이 수치는 보장 사양이 아니라 출발점이다. 데이터베이스 캐시, 운영체제, 연결별 메모리, 백업 작업이 함께 공간을 쓰기 때문이다. 웹서버까지 같은 장비에 올린다면 4GB가 빠듯할 수 있다. 메모리가 부족해 디스크 스왑이 발생하면 CPU 사용률이 낮아도 응답이 느려진다.

데이터 파일이 20GB라고 해서 메모리도 20GB여야 하는 것은 아니다. 자주 읽는 인덱스와 데이터가 얼마나 되는지가 더 중요하다. 반대로 데이터가 2GB뿐이어도 쓰기가 자주 발생하고 느린 디스크를 쓰면 대기 시간이 길어진다. 평균 CPU 사용률 하나로 증설을 결정하지 말고, 바쁜 시간의 메모리 여유와 디스크 지연, 느린 쿼리를 함께 본다. 인덱스 개선이 서버 증설보다 효과가 큰 경우도 흔하다.

이전과 백업은 복구 목표에 맞추기

서버를 고를 때는 장애 뒤 어느 시점까지 데이터를 되돌릴 수 있어야 하는지 먼저 정한다. 하루 한 번 백업하면 최악의 경우 하루치 변경분을 잃는다. 15분 이내의 손실만 허용한다면 더 잦은 백업이나 변경 로그를 이용한 시점 복구가 필요하다. 복구 목표가 짧아질수록 저장 공간과 운영 부담도 늘어난다.

백업 파일을 원본 서버에만 두면 디스크 고장이나 계정 침해 때 함께 잃을 수 있다. 별도 저장 위치에 보관하고, 실제 복원에 걸리는 시간을 주기적으로 재야 한다. 백업 성공 알림만으로는 파일이 열리는지, 애플리케이션이 복원된 데이터로 동작하는지 알 수 없다. 이전 작업도 같은 원칙이다. 새 서버에 복원해 접속과 주요 화면을 확인하고, 쓰기를 멈추거나 변경분을 동기화한 뒤 전환한다. 되돌릴 기준과 이전 서버의 보관 기간도 작업 전에 정해 둔다.

내가 서버를 고를 때 가장 먼저 묻는 건 월 방문자 수보다 장애가 났을 때 몇 시간 안에 돌아와야 하는가다. 쿼리가 가볍고 하루치 데이터 손실을 감당할 수 있다면 저렴한 구성으로도 충분하다. 복구 시간이 매출이나 업무에 직접 영향을 준다면 그때 백업과 이중화에 비용을 쓰는 편이 납득된다.