AWS에서 Hetzner로 마이그레이션

3 weeks ago 12

  • AWS와 DigitalOcean에서 Hetzner로 마이그레이션함으로써 클라우드 비용을 76% 절감하고 리소스 용량은 3배로 증가함
  • 과거에는 AWS의 안정성과 DigitalOcean의 간편함을 바탕으로 두 클라우드 서비스를 병행 사용함
  • 무료 크레딧 소진 후 운영 비용 급증으로 인해 Hetzner 같은 대안을 모색하게 됨
  • Hetzner와 Talos Linux 및 CloudNativePG를 비롯한 도구를 활용해 인프라를 재구성하고 자동화 중심 스택을 구현함
  • 네트워크 구조의 차이와 컨테이너 배포 자동화 문제 등 시행착오를 겪었으나, 궁극적으로 고성능·저비용 인프라로 전환함

배경

  • DigitalSociety에서 개발하는 모든 소프트웨어는 클라우드 기반에서 구동됨
  • 마이그레이션 전에는 주요 인프라를 AWS(주요 서비스와 인증·메일 등 관리)DigitalOcean(경량 서비스와 모니터링, Kubernetes) 양쪽에서 운영함
  • AWS는 15년 넘게 활용해 온 익숙함과 높은 API 안정성으로 선택함
  • DigitalOcean은 간단한 Kubernetes 환경과 무료 컨트롤 플레인, 그리고 비용 효율성 덕분에 선택함
  • 초기에는 DigitalOcean만 사용했으나, 데이터 집약형 SaaS인 tap처럼 많은 리소스와 추가 크레딧이 필요해 AWS의 스타트업 크레딧($1,000)을 활용함

크레딧 종료와 비용 부담

  • AWS의 Fargate(서버리스 컨테이너 러닝) 덕분에 초기에 저렴하게 구축이 가능했으나, tap 서비스의 데이터 집약적 특성상 성능 유지를 위해 최소 2x CPU, 4 GiB RAM이 필요함
  • Fargate 기준 해당 스펙의 컨테이너는 월 $70 이상 비용이 들며, 두 개의 워커 인스턴스 및 기타 인프라를 합산하면 월 $449.50까지 증가함
  • 제공된 무료 크레딧은 6개월이 채 안 되어 소진되고, 자가 자본 스타트업 입장에서는 심각한 고정비 부담으로 작용함

대안 탐색 과정

  • 높은 운영비 절감과 기술 독립성 확보를 위해 UK/EU 기반 클라우드 제공업체를 모색함
  • Hetzner의 가격 경쟁력에 매료되어 자가 관리형 VPS 환경과 운영 복잡성에도 불구하고 AWS와 DigitalOcean 모두에서 마이그레이션을 결정함
  • 이미 Kubernetes 기반으로 서비스 대부분을 운영 중이었기에, Talos Linux의 간편한 클러스터 구축 기능 덕분에 Hetzner 환경에서도 자체 Kubernetes 클러스터를 구축함
  • 기존 AWS나 DigitalOcean의 Managed DB 서비스는 없으나, CloudNativePG로 PostgreSQL 클러스터를 Kubernetes 환경에서 안전하게 통합 관리(모니터링, 백업, 장애 대응 등)함

새로운 인프라 스택

  • Hetzner: ARM 서버, 블록 스토리지, 부하분산기, 네트워크, 방화벽, S3 호환 객체 스토리지 활용
  • Talos Linux: 선언형 설정을 통한 Kubernetes 노드 관리로 운영 자동화 실현
  • CloudNativePG: Kubernetes 매니페스트에 DB 클러스터 선언 및 자동백업, 장애대응 등 통합 지원
  • Ingress NGINX Controller: 클러스터 내 HTTP 라우팅 통합 관리
  • ExternalDNS: 인그레스 리소스에 DNS 자동 연동
  • cert-manager: HTTPS용 TLS 인증서 자동 발급
  • 모든 인프라는 Terraform과 Helm으로 코드화, GitHub Actions를 통한 자동 배포로 DevOps 실현

비용 및 리소스 변화

  • AWS와 DigitalOcean 사용 시 월 최대 $559.36, 작업 가능 리소스는 12 vCPU / 24 GiB RAM 수준
  • Hetzner로 전환 후, 실제 지원 리소스는 44 vCPU / 88 GiB RAM(기존 대비 +367%)로 증가함에도 월 총 비용이 훨씬 저렴함

마이그레이션 과정의 도전과 시행착오

  • Hetzner의 네트워크 존은 AWS의 가용영역(Availability Zone) 과 완전히 동일하지 않음
    • AWS는 한 리전에 여러 가용영역, 프라이빗 네트워킹이 리전 단위로 광범위하게 연결됨
    • Hetzner는 한 network zone(eu-central) 아래 여러 지역(location)이 있으며, 이들 간 네트워크 지연(latency)이 큼
    • 실제로는 여러 지역에 분산할 경우 성능 저하 등 문제 발생함을 모니터링을 통해 경험함
    • 대안으로 단일 지역(뉘른베르크) 내 Placement Group을 활용해 물리적 서버 분산을 통한 장애 복원력 확보
  • 컨테이너 기반 서비스라도 이식이 간단하지는 않음
    • AWS ECS에서 Kubernetes로 환경을 옮길 때, 전체 설정의 자동화 스크립트(특히 config 파일 배포 등) 수정 작업이 예상외로 오래 걸림
    • 결국 Kustomize로 민감한 설정 연동 및 config 파일 관리 체계를 개선해 추적성과 검토 편의성을 높임

결론

  • Hetzner는 월등히 경쟁력 있는 클라우드 비용을 제공하며, 인프라 수준 제어가 가능하면 저렴하고 성능 좋은 대안을 구현할 수 있음
  • 이 방식으로 데이터 집약형 SaaS인 tap을 합리적인 비용과 안정적인 성능 하에 계속 개발 및 운영할 수 있는 기반을 마련함

Read Entire Article