DigitalOcean에서 Hetzner로, **14,388달러 절감** 무중단 마이그레이션 성공!

본 마이그레이션은 6단계(Six Phases)로 구성되었으며, 서비스 중단을 최소화하기 위한 전략을 사용했다. 특히, MySQL 복제(Replication)를 통해 데이터 동기화를 유지하면서, DNS 설정을 변경하고, Nginx 설정을 리버스 프록시(Reverse Proxy)로 전환하여 트래픽을 새로운 서버로 점진적으로 이전했다. 이러한 접근 방식은 서비스 가용성을 보장하면서, 데이터 이전(Data Migration)의 위험을 줄이는 데 기여했다.

MySQL 데이터베이스(Database) 이전은 mydumper와 myloader를 활용하여 병렬 처리(Parallel Processing)를 극대화했다. mydumper를 사용하여 데이터를 덤프(Dump)하고, myloader를 통해 새로운 서버로 데이터를 로드(Load)하는 과정을 거쳤다. 특히, 32개의 스레드(Threads)를 사용하여 248GB의 데이터를 수 시간 내에 이전하는 데 성공했다. 이는 기존의 mysqldump 방식보다 훨씬 빠른 속도를 제공하며, 대용량 데이터 이전(Large Data Migration)에 효과적임을 입증했다.

마이그레이션 과정에서 MySQL 5.7에서 8.0으로의 업그레이드(Upgrade)를 진행하면서, 스키마(Schema) 불일치 문제가 발생했다. mysql.user 테이블의 컬럼(Column) 수가 예상과 다르게 나타났고, 이로 인해 sys 스키마(Schema)가 제대로 임포트(Import)되지 않아 인증 오류가 발생했다. 해결책으로 sys 데이터베이스(Database)를 삭제하고 업그레이드를 재실행하여 문제를 해결했다. 이는 데이터베이스 업그레이드(Database Upgrade) 시 발생할 수 있는 일반적인 문제이며, 꼼꼼한 사전 검증(Validation)의 중요성을 보여준다.

34개의 Nginx 설정 파일을 수동으로 수정하는 대신, Python 스크립트를 사용하여 자동화된 설정 변경(Automated Configuration Change)을 수행했다. 스크립트는 각 설정 파일의 server {} 블록을 분석하여 리버스 프록시(Reverse Proxy) 설정을 추가하고, 기존 설정을 백업했다. 이 방식을 통해 DNS 전파(DNS Propagation) 과정에서 발생할 수 있는 서비스 중단을 방지하고, 설정 관리(Configuration Management)의 효율성을 높였다.

마이그레이션 후, 애플리케이션 사용자에게 부여된 SUPER 권한으로 인해 read_only 설정이 무시되는 문제가 발생했다. 이는 보안 취약점(Security Vulnerability)으로 이어질 수 있으며, 데이터베이스(Database)의 무결성을 훼손할 수 있다. 해결책으로, 모든 애플리케이션 사용자의 SUPER 권한을 제거하고, read_only 설정을 다시 적용하여 문제를 해결했다. 이는 권한 관리(Privilege Management)의 중요성을 강조하며, 보안 설정을 꼼꼼하게 검토해야 함을 시사한다.