45GB짜리 데이터베이스를 옮기는 도중에 복제 로그가 사라져서, 처음부터 다시 시작했습니다.
쇼핑몰 데이터베이스가 AWS RDS에 올라가 있었는데 비용과 성능 두 가지를 이유로 카페24 퀵서버로 옮기기로 했습니다. 문제는 이런 작업을 서비스 멈춰놓고 할 수가 없다는 겁니다. 45GB를 통째로 내려받아 옮기는 동안에도 주문은 계속 들어오고 그 사이에 쌓인 데이터는 그대로 사라집니다.
그래서 질문은 이거였습니다. 서비스를 세우지 않고 45GB를 옮기면서, 옮기는 동안 새로 쌓이는 데이터까지 어떻게 따라잡을 것인가.
복제(Replication) 방식으로 해결했고, 옮긴 뒤 성능은 약 20% 올랐습니다. 대신 세 군데에서 막혔습니다.
왜 굳이 옮겼나?
이유는 두 가지였습니다. 하나는 비용입니다. RDS는 편하지만 그만큼 값을 받습니다. 다른 하나는 성능인데, 옮겨갈 퀵서버 쪽이 CPU와 RAM 사양이 더 좋았습니다.
클라우드 관리형 DB를 쓰다가 일반 서버로 내려오는 게 역행처럼 보일 수 있습니다. 다만 트래픽이 예측 가능한 범위 안에서 움직이는 쇼핑몰이라면, 관리형에 붙는 프리미엄만큼 값어치를 못 하는 구간이 분명히 있습니다.
세 가지 방법 중 왜 복제를 골랐나?
DB를 옮기는 방법은 크게 셋입니다.
- 덤프 후 복원 — 가장 단순합니다. 대신 덤프 뜨는 시점부터 복원 끝나는 시점까지 서비스를 멈춰야 합니다. 45GB면 몇 시간짜리입니다
- 전용 마이그레이션 도구 — 편하지만 대상 조합에 따라 지원 범위가 갈립니다
- 복제(Replication) — 기존 DB를 Master, 새 DB를 Slave로 묶어 실시간으로 따라오게 합니다
복제를 골랐습니다. 데이터 유실이 가장 적기 때문입니다.
원리는 간단합니다. MariaDB는 데이터가 바뀔 때마다 그 변경 내역을 binlog(바이너리 로그)라는 파일에 순서대로 적어둡니다. Slave는 이 binlog를 받아서 자기한테 똑같이 재생합니다. 그래서 Master에 주문이 하나 들어오면 몇 초 안에 Slave에도 같은 주문이 생깁니다.
덕분에 전환은 이렇게 됩니다. 복제를 걸어두고 Slave가 Master를 다 따라잡을 때까지 기다린 다음, 앱 서버가 바라보는 주소만 바꿔주면 끝입니다. 서비스가 멈추는 시간은 주소 바꾸는 그 순간뿐입니다.
버전이 다르면 안 되나?
복제는 Master와 Slave의 버전 차이에 민감합니다. 먼저 확인한 게 이거였습니다.
RDS 쪽이 10.11.13, 퀵서버 쪽이 10.11.16이었습니다. 같은 10.11 계열의 패치 버전 차이라 그대로 진행했습니다.
순서는 지켜야 합니다. 복제는 낮은 버전에서 높은 버전으로 흐르는 건 괜찮지만 반대는 위험합니다. 새 버전이 쓴 로그를 옛 버전이 못 읽을 수 있기 때문입니다. 이번엔 Master가 낮고 Slave가 높아서 방향이 맞았습니다.
어디서 막혔나?
binlog 보존 기간을 안 걸어두면 처음부터 다시 한다
가장 크게 데인 부분입니다.
binlog는 무한정 쌓이지 않습니다. 그대로 두면 디스크가 꽉 차니까 일정 시간이 지나면 알아서 지워집니다. 그런데 45GB를 초기 복사하는 데만도 시간이 꽤 걸립니다. 복사가 끝나고 "이제 이어서 따라가라"고 할 때, 이어붙일 지점의 binlog가 이미 지워져 있었습니다.
끊긴 지점부터 이어갈 방법이 없으니 처음부터 다시 했습니다.
보존 기간을 미리 넉넉하게 잡아뒀으면 없었을 일입니다. 초기 복사에 걸리는 시간을 재보고 거기에 여유를 붙여서 설정해두는 게 순서였습니다.
테이블 하나가 통째로 비어 있었다
복제는 도는데 eventMileage 테이블만 데이터가 안 맞았습니다.
한참 들여다보다가 그 테이블만 비우고 다시 복제로 채워서 해결했습니다. 전체를 다시 하는 것보다 훨씬 빨랐습니다.
여기서 배운 건 "복제가 돌고 있다"와 "데이터가 맞다"는 다른 말이라는 겁니다. 복제 상태가 정상이라고 나와도 테이블별 건수는 따로 대조해봐야 합니다.
RDS는 일부 명령어를 막아둔다
복제가 잘 따라오는지 보려면 로그 위치를 확인해야 하는데, SHOW BINARY LOGS 같은 명령이 RDS에서는 막혀 있었습니다. 관리형 서비스라 최고 권한을 안 주기 때문입니다.
RDS가 따로 제공하는 조회 방법으로 우회했습니다. 크게 어렵진 않았지만 익숙한 명령이 안 먹힌다는 걸 작업 도중에 알게 되면 당황합니다. 관리형 DB에서 나올 때는 쓰려던 명령이 실제로 되는지 먼저 확인해보는 게 좋습니다.
결과
45GB를 옮겼고 Slave가 Master를 다 따라잡았습니다. 남은 건 앱 서버 접속 정보를 바꾸는 것뿐입니다.
벤치마크를 돌려보니 약 20% 빨라졌습니다. CPU와 RAM 사양이 올라간 만큼의 결과입니다. 비용도 함께 내려갑니다.
다음에 같은 작업을 한다면
체크리스트로 남겨둡니다.
- Master와 Slave의 버전과 방향을 먼저 확인한다 (낮은 쪽 → 높은 쪽)
- binlog 보존 기간을 먼저 늘려둔다. 초기 복사 예상 시간 + 여유
- 관리형 DB에서 나올 때는 쓰려는 명령이 막혀 있는지 미리 확인한다
- 복제 상태만 믿지 말고 테이블별 건수를 대조한다
- 전환 직전에 되돌아갈 경로를 정해둔다
DB 이전은 한 번 어긋나면 되돌리기가 번거로운 작업입니다. 그래서 손이 빠른 것보다 순서를 지키는 쪽이 결국 빠릅니다.
저희는 카페24 쇼핑몰 맞춤 개발을 하면서 이런 인프라 작업도 함께 맡고 있습니다. 실제로 진행했던 사례는 포트폴리오에 정리해두었습니다.