[추석 서버 정상화 ④] 서버를 도쿄에서 서울로 옮겼습니다

.

낙엽1124·2026년 10월 20일

페미위키:운영팀/개발팀/기술 블로그/feed

© Matt Kieffer, CC BY-SA 2.0

안녕하세요, 페미위키 개발팀 낙엽1124입니다. 지난 글 "Claude Code로 크롤러 막기"에서는 크롤러를 가려내 속도 제한을 둔 이야기를 전해드렸습니다. 이번 글에서는 9월 26일에 페미위키 서버를 AWS의 도쿄 리전에서 서울 리전으로 옮기고, 다음 날 데이터베이스 프로그램까지 바꾼 이야기를 하려고 합니다.

배경

이야기를 시작하기에 앞서, 서버를 옮긴다는 것이 무슨 뜻인지 설명드리겠습니다.

우리가 평소에 느끼지는 못하지만 웹사이트는 어딘가에 놓인 기계 장치, 컴퓨터가 있어야 존재할 수 있습니다. 이 컴퓨터를 서버라고 부릅니다. 페미위키는 아마존의 AWS라는 서비스에서 서버를 빌리고 있는데, AWS의 서버는 세계 몇 도시의 데이터 센터에 존재합니다. 이렇게 데이터 센터가 모인 지역을 AWS는 '리전'이라고 부르고, 본사인 미국에도, 지사인 서울에도 리전이 있습니다. 그리고 페미위키의 서버는 그동안 어디에 있었냐면, 일본 도쿄 리전에 있었습니다.

네, 도쿄입니다. © Morio, CC BY-SA 3.0

어쩌다 도쿄에 있었을까요? 당연히 처음에는 서울에 있었습니다. 그러다 2018년 8월에 AWS가 T3라는 새 서버 종류를 출시했는데, 이전 세대(T2)보다 값은 10%쯤 싸면서 성능은 더 좋았습니다. 예산이 한정된 페미위키에는 반가운 소식이었지만, T3는 도쿄에는 나왔어도 서울에는 언제 나올지 기약이 없었습니다. 앞서 말씀드린 것처럼 서버는 각 지역 데이터 센터에 존재하기 때문에 새 제품은 유력한 국가에 먼저 서비스됩니다. 그래서 2018년 9월에 T3를 쓰려고 도쿄로 옮겼던 것 같습니다. T3는 11월에 서울에도 출시가 되었지만 페미위키는 그 뒤로 8년 가까이 그대로 도쿄에 있었습니다(여기에는 도쿄 리전에는 계속 신제품도 먼저 들어올 테니 그것들을 써보자는 셈속도 있었습니다).

하지만 서버가 멀리 있으면 그만큼 느려집니다. 방문자가 문서를 열면 요청이 인터넷을 따라 서버까지 갔다가 응답이 되돌아오는데, 광케이블 속을 빛으로 오가더라도 바다를 건너 1,000km 넘게 갔다 와야 합니다(네, 통신은 물리적인 거리를 이동해야 합니다). 페미위키의 접속자들은 대부분 한국에서 접속할 텐데 서버만 바다 건너에 있었던 셈입니다. 한국에서 실측했을 때 응답까지 도쿄 서버는 0.135초, 서울 서버는 0.03초가 걸려 이게 체감 가능한 수준인지는 모르겠습니다만, 어쨌든 이제는 서울에도 T3가 있고 같은 서버라면 요금도 서울이 도쿄보다 4%쯤 저렴하게 되었습니다. 그래서 그동안 미뤄 왔던 이사를 이번 연휴에 하게 되었습니다.

편집을 멈추지 않고 옮기기

옮기는 것은 웹 서버와 데이터베이스였고, 거의 동시에 둘을 옮겨야 했습니다. 미디어위키는 캐시에 없는 문서 하나를 위해서는 데이터베이스에 60번 가까이 요청을 하는데, 데이터베이스와 웹 서버가 다른 곳에 있다면 그 사이를 오가느라 문서 하나에 2초쯤이 더 걸릴 것이기 때문입니다.

다행히 웹 서버는 옮길 요령도 많고 몇 번 옮기기도 했었습니다. 어려운 것은 데이터베이스였습니다. 쓰는 데이터베이스를 도쿄에서 서울로 바꾸는 바로 그 순간에 시도된 편집은 저장에 실패할 수 있습니다. 처음에는 편집을 잠깐 막고 5분 점검을 공지할 생각이었습니다. 그간에도 그런식으로 몇번 옮겼던 적이 있었습니다. 하지만 이번에는 그 대신 데이터베이스 앞에 요청을 잠시 붙잡아 두는 중계 서버(ProxySQL)를 두어 편집을 막지 않고 옮겨 보기로 했습니다. 방법은 이렇습니다.

1. 서울에 서버와 데이터베이스를 새로 만들고, 도쿄 데이터베이스에 저장되는 내용이 서울 데이터베이스에도 준 실시간으로 똑같이 저장되게 합니다(복제).
2. 중계 서버에 새로 들어오는 쓰기 요청은 중계 서버가 실패시키지 않고 잠시 붙잡아 둡니다.
3. 도쿄의 내용이 서울에 빠짐없이 저장된 것을 확인하면 붙잡아 둔 쓰기를 서울로 보냅니다.
4. 웹 서버 도메인이 서울 서버를 가리키게 바꿉니다.

쓰기를 붙잡아 둔 시간은 실제로는 0.92초였고 이는 웹 서버에게는 충분했습니다. 실패한 쓰기도 없었고 그동안 읽기는 당연히 멈추지 않아 성공했다고 볼 수 있었습니다.

다만 도메인을 바꾼 뒤에도 도쿄 웹 서버를 당장 정리하지는 못하는데, 예전 주소를 기억해 둔 인터넷 회선이나 기기가 한동안 그리로 접속하기 때문입니다. 그래서 도쿄 웹 서버는 바로 끄지 않고 서울 데이터베이스에 이어 두었습니다. 이렇게 접속한 분들은 문서가 조금 늦게 열렸지만, 편집은 그대로 저장되었습니다.

MySQL에서 MariaDB로

다음 날인 9월 27일에는 데이터베이스 프로그램을 MySQL에서 MariaDB 10.11로 바꿨습니다. 이유는 그동안 쓰던 MySQL 8.0은 올해 4월에 지원이 끝났지만, 미디어위키가 MySQL의 다음 버전을 어디까지 지원하는지 확실하지 않아 그대로 쓰고 있었기 때문입니다. MariaDB는 위키미디어 재단이 위키백과에 쓰는 프로그램이라 어느 버전이 지원되는지도 확실하고 미디어위키와 함께 쓰면서 생기는 문제는 위키백과에서 먼저 드러나고 고쳐진다고 믿을 수 있습니다. 교체는 전날과 같은 방식으로 하였기에 이번에도 읽기는 멈추지 않았습니다(GTID 방식 차이에 대한 디테일이 있지만 생략합니다).

돌아보며

진행 중 계획대로 되지 않은 일이 크게 두 가지 있었습니다.

첫 번째, MariaDB로 바꿀 때 서울 서버는 새 데이터베이스로 돌렸지만 아직 남아 있던 도쿄 서버는 예전 데이터베이스에 그대로 이어 두었습니다. 도메인을 서울로 변경했으니 도쿄 서버에 무신경했던 것인데 실제로 세어 보니 전체 요청의 9%쯤이 아직 도쿄로 들어오고 있었고, 이 경우에는 문서를 읽을 수는 있었지만 편집은 저장되지 않았습니다. 다행히 편집이 드문 시간이어서 도쿄 서버의 연결을 고칠 때까지 실제로 저장되지 않은 편집은 없었던 것으로 추정합니다. 이후 도쿄 서버를 완전히 끌 때는 도쿄로 들어오는 요청 수를 확인하여 한 시간에 60건 아래로 떨어진 것을 보고 껐습니다(남아있던 요청들은 IP를 직접 쳐서 들어오는 크롤러였습니다).

둘 번째, 이전을 준비하다가 편집이 17분 막힌 일이 있었습니다. 복제를 설정하려면 데이터베이스의 관리자 비밀번호가 필요한데 패스워드 관리자에 적어 둔 값이 맞지 않았습니다. 아마 어딘가 적어놨을 것 같은데 어디를 뒤져도 나오지 않았고, 데이터 자체는 살아있기에 결국 새 데이터베이스 서버를 만들어 전날 백업으로 채운 뒤 갈아 끼워야 했습니다. 그런데 예상보다 백업 이후에 바뀐 내용을 마저 옮기는 시간이 오래 걸려서 9월 26일 13시 30분부터 17분 18초 동안 편집이 막혔습니다. 지금은 데이터베이스 서버를 만들 때 관리자 비밀번호를 자동으로 AWS에 보관하게 했습니다.

맺음말

도쿄의 서버는 9월 27일에 정리했고, 지금 도쿄에는 예전 백업을 보관하는 저장소 정도만 남아 있습니다. 다음 글에서는 이렇게 옮긴 뒤 페미위키가 얼마나 빨라졌는지 소개드릴 예정입니다.

출처

최근 포스트

• [추석 서버 정상화 ⑤] 페미위키는 얼마나 빨라졌나 2026년 10월 27일
• 7년 쓴 테라폼 클라우드를 떠나 OpenTofu로: 상태 암호화부터 GitHub environment 승인까지 2026년 10월 23일
• [추석 서버 정상화 ③] Claude Code로 크롤러 막기 2026년 10월 13일

블로그 목록으로