#038. 인프라: 사이드 프로젝트 호스팅 서비스 이사 기록

파트라슈 일어나.. 이사가야지

온프레미스 환경

- 사용한 이유: 
프로젝트를 시작하면서 서버 비용을 걱정하니 아는 분이 서버를 사용해도 좋다고 하셔서 사용하게 되었다. 심지어 MySQL과 Redis까지 제공해주셔서 현재 프로젝트의 큰 틀을 걱정하지 않고 설정할 수 있었다. 글을 쓰다보니 한 번 더 고마운 마음이다. argoCD 배포 시스템이 되어있어서 도커로 말아서 배포했다. 이 때 actuator를 사용해 무중단 배포 설정을 했다. (글 링크) 
- 이사 이유: 
아무래도 서버를 빌려서 하는 것이다보니 언젠가 여유가 생기면 이사를 가야지 하다가 어느날 마음을 먹고 이사를 하게 되었다. 조금 서두르면서 하다보니 엉성한 곳이 있었지만, 처음으로 MySQL 덤프를 뜨고 스키마들을 싹 옮기는 경험을 했었다. 

CloudRun + LB (GCP)

- 사용한 이유:
CloudRun의 무료 크레딧과 컨테이너 이미지로 배포하는 환경때문에 선택하게 되었다. (CloudRun Pricing) 이사할 당시 가지고 있던 유저 정보가 30명이 안되었고 하루에도 요청이 10건 이하였기 때문에 절대 이 무료 크레딧을 넘을 일은 없다고 생각했었다. 다만 DB는 무거워지기 쉬우니 DB와 Redis는 팀원이 가진 NAS 에 올려두기로 했다. 이미지로 만들어 올리는 cli 프로세스도 잘 되어있어서 서버로는 만족하면서 사용했었다.

- 이사 이유:
이사 할 때는 생각지 못했던 게 많았는데, 우선 온프레미스에서는 내부적으로 DNS 설정이 되어있었다는 점이 제일 컷다. CloudRun은 배포된 서비스에 기본 주소를 제공하는데 이 주소가 dynamic 하다. 프런트에서 사용할 DNS를 설정하기 위해 고정 IP가 필요했고 커스텀 도메인 기능을 사용하기로 했다.(GCP 커스텀 도메인) 도메인 설정은 cloudflare로 하고 CloudRun에 붙이려고 하니 LB를 설정하게 되었다. 
IP를 고정하니 해킹 시도도 있었다. 고정 IP에 뜬금 없이 /.env 와 같은 패스로 요청했는데 한시간에 거의 1.2k 건의 요청이 오며 순간적으로 instance가 20대까지 늘어난 적이 있다. LB에서 존재하지 않는 path로 요청을 하면 스토리지에 미리 만들어둔 NotFound 정보를 내려주도록 설정해서 서버 공격을 막았다. 요금 폭탄 맞을까봐 깜짝 놀랐다.
그래도 GCP에는 northeast-3 서울리전이 있었기 때문에 API 속도가 빠른 것까지는 아니어도 불편하지 않은 정도로 동작했다.

구글의 혜자 크레딧이 끝나고 운영, 개발서버에 LB까지 올라가 있던 우리의 서버는 하루에 2000원씩 내야하는 상황이 되었다. 그렇게 조금 더 싼 가격 정책을 가지고 있는 플랫폼을 찾게 되었다.

railway.app

- 선택 이유:
이번 이사를 하면서는 railway.app와 fly.io을 비교하면서 어느 Paas 가 더 좋을 지 고민을 했기 때문에 아래에 정리해보려고 한다.
크게 속도, 가격, 사용성 세 가지 측면에서 고민했다.

	railway.app	fly.io
속도 - 한국에서 서비스 중	- 현재 미국 리전만 지원 (최소 약 300ms)	- 도쿄 리전 지원 (최소 약 40ms) (fly.io 리전 문서)
가격 - 최소 1GB RAM - 운영 및 개발 각각 서버, DB, Redis (총 6대 사용) - 월 $20 이하의 운영비가 목표	- $5/월 + 사용량 반영 $5에 아래와 같은 리소스 포함 - Max up to 8 GB of RAM - Max up to 8 vCPU cores - Max 100 GB of Disk (Soft cap) - Max 5 members per project	- $5.7/월 (사용량에 따라 측정) - 1 shared-cpu - 1GB RAM
사용성 - 모니터링, 로깅 지원 - 컨테이너 배포 지원 - MySQL, Redis 와 지원 - 환경 및 네트워크 설정 커스텀	- 간단한 대시보드 지원	- Grafana 지원

둘 다 여러 측면에서 비슷하게 좋은 부분을 가지고 있었다. 아직까지 미국 리전과 일본 리전은 유저가 느끼기에 큰 차이가 없을거라고 생각했다. 다만 가격 측면에서 railway.app의 hobby plan의 리소스가 마음에 들었다. 지금은 DB, Redis, 서버 모두 크지 않아서 원래 목표였던 $20달러를 넘지 않으면서도 개발 환경까지 올릴 수도 있겠다고 판단해 railway.app을 선택하게 되었다.

 

 

아래는 railway의 설정 및 기능들을 몇가지 정리해두려고 한다.

배포 프로세스

* github을 직접 바라보게 할 수 있다. 특정 브랜치에 push 하면 자동으로 배포되는 설정이 기본 값이다. build(Nixpacks 지원)와 deploy를 자동으로 해준다. 기본 무중단 배포를 지원한다. 이전 버전은 Removed로 아카이브된다.
* 환경 (production, alpha) 에 따라 바라보는 브랜치를 다르게 할 수 있다. alpha는 develop 브랜치를, 운영은 main 브랜치를 보도록 설정했다.
* 각 환경에 맞게 환경 변수도 분리할 수 있어서 config 값을 관리할 수 있다.

 
모니터링

아래와 같이 CPU, Memory, Network 등 간단한 대시보드를 제공한다. 그라파나 템플릿이 있어서 필요한 경우 연결해볼 수 있을 것 같다.

 
리전

현재(2023년 6월) 리전 지원이 되지 않고 있어 미국 서버만 사용할 수 있다. 8월에는 리전을 지원한다는 안내가 있다. MySQL, Redis까지 하나의 네트워크에 올려두었는데 한국에서 사용하기에 일반적인 앱서비스 수준의 속도를 내고 있다. (약 500 ~ 600ms)

비용 문제로 LB를 내리려고 서버 먼저 레일웨이(미국섭)에 올리고 DB(MySQL, Redis)는 한국 NAS(가정집 네트워크) 서버에 몇 일 올려 둔 적이 있는데 사용자에게 강력한 항의를 받은 적이 있다. 

커스텀 도메인 (독스)

~~ railway.app 으로 끝나는 기본 주소도 제공하지만 [+ Cusom Domain]을 통해 DNS 서비스와 연결할 수도 있다. 참고로 cloudflare와 railway.app 모두 강제적으로 HTTPS Protocol로만 접속하게 하는 HSTS 룰이 적용되기 때문에 cloudflare 의 SSL/TLS encryption mode와 proxy 기능을 맞춰서 사용해야한다. 지금 서비스에서는 submain을 사용하지 않고 모두 CNAME 만 사용하며, 가능한 돈을 안내고 싶기 때문에 cloudflare는 flex mode로 하고, proxy는 끄도록 설정해두었다.

위의 설명을 지키지 않으면 아래와 같이 301 무한 리다이렉트를 경험할 수 있다.
자세한 내용은 이 문서를 참고할 수 있다.

리밋 기능 (rate, resource limit 등)

7월 오픈 예정

프라이빗 네트워크

6월 오픈 예정

테라폼

6월 오픈 예정

scale to zero:

GCP 사용할 때 개발 환경은 instance 0 로 설정해뒀다. 이 기능이 나오면 여기에도 적용 예정.

개발 예정 중인 서비스에 대해 더 자세히 알고 싶다면 railway 의 블로그 글을 참고