Railway에서 DigitalOcean으로 DB 마이그레이션을 한 썰
개인 프로젝트를 1년 반 넘게 Railway에서 운영해 왔습니다. Railway의 가장 큰 장점 중 하나는 월 $5의 비용 할인이었으며, 경량화된 배포 환경으로 적합했습니다.
육아휴직을 통해 개인 시간을 많이 확보하게 되면서, 개인 프로젝트를 정비하고 다양한 서비스를 경험하며 스킬을 향상시키고자 하는 생각에 DigitalOcean에 Kubernetes 클러스터를 생성하게 되었습니다. 관리형 데이터베이스도 함께 설정하다 보니 Railway와 DigitalOcean 두 군데에서 중복으로 비용이 발생해 부담이 되었습니다.
Railway는 배포 환경 구축이 쉬우며, 유저들이 올린 템플릿을 활용해 다양한 서비스를 쉽게 띄울 수 있는 장점이 있습니다. 그러나 사용하면서 느낀 단점은 메모리와 네트워크 비용이 예상보다 비싸다는 점이었습니다.
저는 200MB 정도의 메모리를 사용하는 Ruby on Rails 프로젝트 두 개와 MySQL 하나를 Railway에서 운영하고 있었으며, 이로 인해 1GB의 메모리를 사용하게 되었습니다. 메모리 비용은 다음과 같이 청구되었습니다:
-
Memory: $0.000231 / GB / 분
결과적으로 한 달에 $10 이상을 메모리 비용으로 소비하게 되었습니다.
또한, 네트워크 비용도 예상보다 많이 들었습니다. 개인 서비스로 운영 중이었는데, 한국어 서비스임에도 불구하고 유럽에서 무의미한 트래픽이 증가하여 비용이 추가로 발생했습니다. 네트워크 비용은 다음과 같습니다:
-
Egress: $0.10 / GB
비록 $10 이내의 비용 증가였지만, 개인 프로젝트로서는 부담이 될 수밖에 없었습니다.
결국, 회사였다면 긴장하며 신중하게 진행했던 데이터베이스 마이그레이션 작업을 이번에는 즉흥적으로 결정하게 되었습니다. Railway의 환경은 수정이 용이하여, 환경 변수 변경을 통해 마이그레이션을 간단하게 마무리할 수 있었습니다.
그러나, 미국에 위치한 Railway webapp에서 싱가포르에 위치한 데이터베이스로 접근할 때 레이턴시가 체감상 많이 늘어나는 문제가 발생했습니다. 이를 계기로 Kubernetes 클러스터로의 서비스 이전을 서두르게 되었습니다.
이번 경험을 통해 다양한 배포 환경에서의 운영 경험을 쌓을 수 있었고, 비용 효율성을 고려한 선택이 중요함을 다시 한 번 깨달았습니다.