AWS에서 Fly.io로 마이그레이션하기 개요 (Migrating from AWS to Fly.io Overview)
AWS에서 Fly.io로 옮길 때 마주하게 될 주요 아키텍처 차이를 설명하는 가이드예요. 컴퓨팅, 스토리지, 네트워킹, 스케일링, 배포, 시크릿, 데이터베이스, 모니터링까지 두 플랫폼이 어떻게 다르게 작동하는지 전반을 빠르게 훑어볼 수 있어요.
출처: 문서
본문
**Fly.io는 전 세계 리전에서 빠르게 시작되는 VM("Fly Machines")을 제공해 앱을 사용자와 가깝게 실행합니다.** 이 가이드는 AWS에서 앱을 옮기는 분들을 위한 것입니다. 마주하게 될 주요 아키텍처 차이와 배포 모델을 조정하는 방법을 안내합니다.
AWS에서 Fly.io로 마이그레이션한다는 것은 몇 가지 가정을 다시 생각하는 걸 의미해요. 두 플랫폼은 앱을 다르게 실행하고, 네트워크를 다르게 구성하며, 스케일링과 데이터 영속화에 다른 도구를 줘요. AWS 클라우드 본진을 떠날 때 무엇이 바뀌는지 훑어보는 여행이에요.
컴퓨팅
먼저 컴퓨팅. Fly.io는 앱을 가상 머신으로 실행하지만 AMI나 EC2를 사용하지 않아요. 대신 Docker 이미지를 주면 우리가 그것을 풀어서, 우리가 여러분을 위해 띄우는 VM의 루트 파일 시스템으로 만드는 거예요. 우리는 이것을 Fly Machines이라고 불러요. 빠르고, 작아요. 그리고 하이퍼바이저 콜드 스타트 시간이 없고 ECS나 EKS에서 볼 수 있는 공유 커널 게임도 없어서 부팅이 빠르죠.
하지만 단서가 있어요: 볼륨을 마운트하지 않으면 루트 파일 시스템은 임시(ephemeral)예요. 재시작하면 사라져요. 거기에 쓴 데이터는 다른 곳에 저장하지 않으면 사라져요. 앱이 현재 EBS 볼륨에 의존하거나 재시작 후에도 유지될 것으로 기대하는 임시 파일만 써도, 그것을 다시 생각해야 해요.
스토리지
Fly Volumes은 영구 스토리지에 대한 우리의 답이에요. 물리 호스트에 직접 마운트되는 NVMe 조각이에요. 네트워크 연결형이 아니에요. 즉 빠르고 단순하지만 특정 호스트에 묶여요. 머신이 죽으면 다른 머신을 부팅해 볼륨을 다시 연결할 수 있어요. 네트워크 간접 계층과 리전 추상화를 뺀 EBS라고 생각하면 돼요. ML 모델 같은 큰 정적 자산도 볼륨에 저장할 수 있어서 Docker 이미지를 가볍게 유지하고 배포를 빠르게 할 수 있어요.
객체 스토리지에는 Tigris를 제공해요. S3 호환이며 Fly.io 자체에서 실행돼요. AWS S3에서 마이그레이션한다면 편리한 shadow bucket 모드가 있어요: 파일이 아직 복사되지 않았다면 Tigris가 기존 S3 버킷에서 가져오는 방식으로 폴백할 수 있어요. 첫 요청은 S3에서 가져오고 이후 요청은 로컬을 사용해요. 쓰기도 동기화되므로 점진적 마이그레이션이 무난해요.
네트워킹
RDS 같은 AWS 호스팅 서비스와 통신하려면 약간의 요령이 필요해요. AWS VPC로 직접 WireGuard 브리지는 없어요. RDS에 안전하게 연결하려면 가장 간단한 방법은 정적 egress IP를 가진 Fly Machine으로 PgBouncer를 실행하는 거예요. RDS 보안 그룹에서 그 IP를 허용 목록에 추가하세요. 그러면 앱 머신이 Fly의 프라이빗 네트워크를 통해 PgBouncer에 연결하고, PgBouncer가 RDS로 전달해요.
네트워크에 대해 말하자면: Fly.io 앱은 조직별로 격리된 프라이빗 네트워크에 존재하며 WireGuard로 연결돼요. 머신들은 .internal 호스트 이름(직접)이나 .flycast(프록시를 통한 로드 밸런싱)로 서로 통신해요. 이 구성은 AWS의 프라이빗 서브넷과 보안 그룹에 꽤 가까워요. 보통 엣지(edge) 앱만 공개 인터넷에 노출해요.
리전별 로드 밸런서 대신 Anycast를 사용해요. DNS는 하나의 글로벌 IP를 가리켜요. Fly Proxy가 요청을 가장 가까운 엣지 서버로 라우팅하고, 엣지 서버는 부하와 지연 시간에 따라 정상 앱 인스턴스로 트래픽을 전달해요. 즉 us-east-1과 us-west-2 사이에서 수동으로 밸런싱할 필요가 없어요.
스케일링
스케일링도 다르게 작동해요. Machines는 요청 트래픽에 따라 온디맨드로 생성되지 않아요. 사전에 프로비저닝하고, 필요에 따라 우리가 시작/중지해요. 즉 최대 지출을 예측할 수 있어요. 오토스케일링을 원하나요? Prometheus로 메트릭을 모니터링하고 flyctl이나 API 클라이언트로 스케일하세요. 자동화는 여러분의 몫이에요.
배포와 시크릿
그래서 Infrastructure-as-code(IaC)로 이어져요. 대부분의 사용자는 Bash 스크립트와 flyctl로 조합하고, 규칙(convention)으로 상태를 관리해요. 마찰은 적지만 추상화도 낮아요. 그래도 CloudFormation보다는 머리가 덜 아파요. 더 많은 인프라 자동화 아이디어는 여기에서 확인할 수 있어요.
좋은 점으로, 헬스 체크를 사용하고 여러 머신을 실행한다면 배포를 제로 다운타임으로 할 수 있어요. 그 헬스 체크를 fly.toml에 정의하면 프록시가 비정상 노드를 피해 라우팅해요. 배포 전에 release_command로 DB 마이그레이션을 실행할 수도 있고, 이전 이미지 태그를 밀어넣어 롤백할 수도 있어요.
시크릿은요? Fly Secrets를 사용하세요. 런타임에 환경 변수로 마운트되고 저장 시 암호화된 상태로 유지돼요. AWS Secrets Manager나 Parameter Store와 비슷하지만 더 단순해요. 중앙 관리 키로 앱이 데이터를 암호화/복호화할 수 있게 하는 AWS KMS처럼 작동하는 새로운 Secrets API도 있어요.
데이터베이스
데이터베이스는요? Managed Postgres를 제공해요. RDS와 유사하게 프로덕션 PostgreSQL 데이터베이스 실행의 모든 측면을 처리하는 완전 관리형 데이터베이스 서비스예요. 자동 백업/복구, 자동 장애 조치가 있는 고가용성, 성능 모니터링과 메트릭, 리소스 스케일링, 24/7 지원, 자동 데이터 암호화를 처리해요.
다른 데이터베이스 옵션으로는 파트너 Upstash의 관리형 Redis, 자체 Redis 또는 Valkey 실행, LiteFS를 통한 분산 SQLite, Tigris와 함께하는 LanceDB 같은 벡터 DB가 있어요.
모니터링
모니터링을 위해 Prometheus 메트릭과 Grafana 대시보드를 사용할 수 있어요. 아직 네이티브 알림은 없지만, 많은 사람들이 Alertmanager와 함께 자체 Prometheus를 실행하거나 Grafana로 알림을 설정해요. AWS CloudWatch 알람에 비해 사용자 설정이 더 필요하지만, 그 대가로 Grafana와 Prometheus 커뮤니티의 풍부한 리소스를 얻을 수 있어요.
요약
AWS는 깊은 추상화를 가진 방대한 플랫폼이에요. Fly.io는 그 많은 것을 걷어내요. 인프라에 더 원시적으로 접근할 수 있고 사용자 지연 시간도 더 나아지지만, 어느 정도 편의성은 포기할 수도 있어요. 마이그레이션은 일반적으로 개념을 번역하는 문제라기보다 앱을 어떻게 빌드하고 배포하는지 다시 생각하는 문제예요.