▲

Heroku 월 3,000달러 요금을 월 55달러 서버로 대체하기

 (disco.cloud)
10P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 비영리 구직 플랫폼 Idealist는 Heroku에서 발생하던 비싼 스테이징 환경 비용 문제를 해결하기 위해 저가형 전용 서버로 이전
  • Heroku에서는 환경별로 과금되는 구조로 인해, 각 스테이징 환경이 월 500달러 수준의 비용을 발생시켰음
  • 이를 대신해 Hetzner CCX33 서버(월 55달러) 한 대에 여러 환경을 구성하고, Disco를 통해 Heroku와 동일한 git push 및 자동화 경험을 유지함
  • 서버 한 대에서 6개의 스테이징 환경이 안정적으로 구동되며, CPU 사용률은 2%, 메모리 사용량은 32GB 중 14GB 수준으로 여유로움
  • 이로써 스테이징 환경이 ‘비용 부담 요소’에서 ‘자유롭게 생성 가능한 자원’ 으로 바뀌며, 개발팀의 실험과 배포 문화가 크게 개선됨

실용적인 Heroku 비용 절감 전략 경험기

문제: 월 500달러 스테이징 환경

  • Idealist.org는 월간 수백만 명이 방문하는 대규모 비영리 구직 플랫폼으로, 실제 운영 환경과 거의 동일한 스테이징 환경이 필수적임
  • Heroku에서 웹·워커 dyno와 Postgres 등 필요한 애드온을 조합한 한 스테이징 환경의 비용이 약 500달러/월 수준
  • dev, main 두 개만 유지해도 1,000달러가 넘는 고정비 발생
  • Heroku의 가격책정 방식은 환경 단위 과금 모델이며, dyno를 줄여도 비용 절감 폭이 작고, 애플리케이션이 많아질수록 비용이 급증함

실험: 단일 서버로 이전

  • 이상적인 비용절감을 위해 단일 Hetzner CCX33 서버(월 55달러) 를 임대하여 실험 시작함
  • Disco 솔루션을 활용해 기존 Heroku의 git push 배포 방식을 서버에 그대로 적용함
  • 모든 스테이징 환경에서 동일 서버의 공용 Postgres 인스턴스를 활용하여, 관리형 데이터베이스 비용 부담을 대폭 낮춤
  • 테스트 관점에서는 개발자별로 분리된 데이터베이스를 쉽게 초기화할 수 있어 적합함

Disco를 쓰는 이유: Docker Compose와의 차별점

  • 단순히 서버에서 docker-compose up만으로는 개발자 경험이 충분하지 않음
  • Disco는 다음과 같은 이점을 제공함
    • Heroku와 동일한 git push 배포 프로세스
    • 모든 배포를 대상으로 자동 무중단 배포 지원
    • 브랜치별 URL에 대한 자동 SSL 인증서 발급 및 갱신
    • 로그 및 환경 관리를 위한 직관적인 웹 UI
  • 자체 배포 관리 자동화를 구축/유지할 필요 없이, 개발 편의를 그대로 누릴 수 있음

스테이징 환경 폭발 및 서버 자원 효율

  • Disco 활용으로 스테이징 환경 확장이 매우 간편해짐
  • 한 대의 서버에서 다음과 같은 환경을 동시에 운영함
    • 메인 브랜치
    • feature-freeze 브랜치
    • 임시 PR용 throwaway 환경
    • 대규모 기능 개발용 장기 환경 등
  • 총 6개의 독립 스테이징 환경을 무리 없이 기동 중임
  • Heroku에서라면 월 3,000달러가 필요하지만, Hetzner에서는 CPU 2%, 메모리 14GB(32GB 중) 만 소모하는 저비용 구조

트레이드오프 및 현실적 고려사항

  • 완전한 대안은 아니며, 몇 가지 운영 부담이 추가됨
  • 신규 환경별 DNS, CDN 설정 등의 인프라 작업은 자동화되어 있지 않음
  • 서버 모니터링, 보안 업데이트, 장애시 대응 등 운영 책임이 발생함
  • Hetzner는 미국 리전이 제한적이므로, 미국 사용자 대상 프로덕션 서비스에는 부적합할 수 있음
  • 서버 장애시 재설치를 감수한다는 가용성 트레이드오프가 있음
  • Docker 네트워킹에 애플리케이션을 맞추는 작업에 하루 정도의 엔지니어 작업이 필요했음

얻은 인사이트 및 변화

  • 6개월 이상 운영하며 해당 인프라가 상시 구조로 자리잡음
  • 가장 큰 변화는 비용 절감만이 아니라, 스테이징 환경 자체가 풍부하고 자유로운 자원으로 인식이 바뀐 점
  • 개발자는 동의나 비용 걱정 없이, 필요할 때마다 자유롭게 pull request별 환경을 생성할 수 있게 됨
  • 팀 내에서는 비용 부담뿐 아니라, 사용 주저함 자체가 진정한 손해였다는 교훈을 얻음
    • "금전적 부담이 개발 속도와 실험을 제약해왔음"
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • htop 스크린샷을 보니 스왑이 없는 점이 눈에 띄어서, 서비스가 비정상적으로 메모리를 잡아먹을 때 전체 서버 다운을 막기 위해 earlyoom을 활성화하는 것을 추천함, 리눅스 커널 OOM killer는 보통 너무 늦게 동작함, zram을 활성화해 램을 압축해서 프로처럼 오버프로비저닝하는 방법도 있음, 장기 실행되는 소프트웨어는 메모리 누수를 자주 일으키는데 압축하면 꽤 효율적임, Hetzner 베어메탈 서버에 Ansible로 적용하는 방법을 gist에 정리해둠, VM에서도 동일하게 동작함

    • 절대 동의하지 않음, 스왑에 도달하면 대부분의 앱이 심각한 문제를 겪게 됨, 이건 너무나 잘 알려진 사실이고 AWS EC2 인스턴스도 스왑 기본 비활성화함, 물론 AWS가 더 많은 램을 팔고 싶어하긴 하지만, 오늘날 기대치에 스왑은 적합하지 않음, 90년대에는 클릭에 2~3초 기다리기도 했으나 지금은 무반응이면 죽은 줄 알고 바로 재부팅하는 시대임

    • 또 다른 대안은 메모리를 더 추가하고, 앱 별로 oom_score를 조정해서 비중요 앱에 높은 킬 가중치를, 중요한 앱에는 음수 가중치를 주는 것임, 예를 들어 OpenSSH는 oom_score_adj가 이미 -1000으로 설정됨, staging/production 서버에서 오버커밋을 사실상 비활성화하는 것도 매우 유용함, 램 용량에 따라 min_free와 reserve 값을 공식으로 산출해 설정함, 50,000대의 물리 서버를 10년 넘게 스왑 없이 운영하면서 실전에서 효과를 봄, OOM은 오로지 코드 배포 과정에서 메모리 요구량을 잘못 계산했을 때만 발생했음, Java의 모범 사례를 따르지 않을 때도 긴 얘기가 있음, cgroup으로 애플리케이션별 메모리 제한을 거는 방법도 있으나 설명을 생략함, 디스크에 기록이 필요 없는 완전 인메모리 서버라면 OOM이 아예 발생하지 않게 하고 자동으로 셀프힐링하게 하는 것도 추천함, DRAC/iLO로 크래시 메시지 캡처할 여유 시간을 주고 패닉 재부팅 설정(kernel.panic, vm.panic_on_oom 등)도 유용함, 참고로 NFS 디스크리스 시스템에서 장애극복시 의도적으로 전체 팜 재시작 트리거로도 쓸 수 있음

    • 좋은 정보 고마움, 시스템 제한설정(systemd)에서 램 임계치로 제어 중인데, earlyoom이 프로세스 이상 동작으로 인스턴스 전체가 응답 없는 상황을 막는 데 더 좋은 선택인지 궁금함

    • 만일을 대비해서 아주 소량, 예를 들어 1GB 정도 스왑을 두는 건 좋은 아이디어라고 생각함

    • 2010년 이후로 스왑을 사용하지 않았음

  • 어제 Nate Berkopec이 rails 성능 관련해서 비슷한 주제로 글 쓴 걸 봤는데, Heroku가 성능 기준 25~50배 비싸다는 얘기를 했음, 정말 허무할 정도로 가격 경쟁의 의지가 없으며 만약 Sidekiq처럼 스택 전체를 합리적 가격에 라이선스만 해준다면 하드웨어는 따로더라도 훨씬 나을 거라 생각함, 2025년에 1GB RAM 다이노가 $50이라니 거의 도둑질임, 특히 표준 rails 앱이 예전보다 큰 리소스 변동도 없고 더 효율적이기까지 한데 가격은 오히려 더 비싸지고 품질은 하락했음, 수많은 개발자가 한 달에 수백 달러씩 heroku로 앱을 운영하면서 실제 개발용 맥북보다도 느린 장비를 쓰고 있음이 우스울 정도임, 결국 요즘 세상의 흐름과 크게 다르지 않게, 좋은 제품을 합리적 가격에 대중에게 제공하기보다 가장 돈 많은 상위 고객에만 집중하며 가격만 올리는 추세임

    • 가격 인상만의 문제는 아님, Heroku와 클라우드 벤더들이 심리적 가격 기준 효과의 수혜를 본다고 생각함, 사용자가 서비스 시작할 때 가격에 기준점을 두고 그 뒤로 기대치는 선형적으로만 변화하는 경향이 있음, 실제 연산 하드웨어 성능은 기하급수적으로 좋아지는데 사용자는 선형적으로만 체감함, Heroku 가격은 최소 7년 이상 변하지 않았으나 하드웨어는 엄청나게 발전함, 그래서 사기라고 느끼는 이유가 실제론 2025년의 참조점과 중반 2010년대 가격을 비교하는 것임, 대형 클라우드 벤더들은 새로운 하드웨어 성능을 잠금 해제하거나 SKU 업데이트 등 장애물을 부여함, Heroku는 이런 경쟁자가 없어 가격을 고정했고 이런 글은 새로운 엔지니어가 하드웨어 성능을 체감할 때마다 등장하는 패턴임

    • $50에 1GB RAM 다이노가 도둑질이라 말했는데, AWS도 그리 다를 것 없음, $50/월이면 m7a.medium이 오는데 1vCPU와 4GB RAM임, 램은 더 많지만 AWS가 왜 돈을 끌어모으는지 알만함

    • 저렴한 가격에 소프트웨어 스택 전체를 합리적으로 라이선스하는 모델이 Sidekiq처럼 있었으면 좋겠다는 의견에 공감해서 우리는 canine.sh를 오픈소스로 만들었음, PaaS 제공업체들이 이미 마진이 붙은 클라우드 위에 또 과도한 마진을 붙일 이유가 없다고 생각했음

    • 지역 정비소의 오일 교환이나, 식당의 스테이크 가격도 직접 해 먹으면 저렴하다는 얘기와 비슷함

  • 클라우드는 한 대의 서버로 얼마나 많은 걸 할 수 있는지 잊게 만듦, staging 환경만 해도 비싼 클라우드에 올리는 게 이해가 안 되긴 하지만, 요즘 클라우드는 여러 요소가 복잡하게 얽혀 있어서 필요성을 이해함

    • 여러 개발자에게 클라우드 기초를 가르치고 몇 명의 클라우드 전문가를 두는 건 상당 기간 비용 효과적임, staging/prod환경을 유사하게 맞추면 실수도 빨리 발견할 수 있음, 나중엔 인건비보다 클라우드 요금 더 내게 되고 그때 클라우드 탈출이 진짜 이득이 됨, 결국 자체 서버로 전환하면 팀과 하드웨어의 가격을 넘어가는 시점이 곧 온다고 생각함

    • 클라우드 덕분에 개발자들이 리눅스 서버 자체를 두려워하게 된 감이 있음, 마진 대부분은 개발자 불안의 댓가라고 생각함, 그런데 셀프 호스팅은 실제로 쉽고 재미있음, Heroku, Vercel 같은 데 매력을 못 느꼈고, 처음부터 직접 서버 올려보는 것보다 좋은 경험은 없다고 믿음, 모든 개발자가 직접 해보는 걸 추천함

    • 실제 운영과 유사하게 prod 환경을 완전히 복제하는 게 도움이 큼, 배포 과정이 비슷해 시간도 아끼고 실제 prod와 더 비슷하게 테스트할 수 있음

    • 이걸 기반으로 인프라 학습 사이트를 만들면 재밌을 것 같음, 클라우드에서 X 리소스를 받고 정해진 부하에 대응하도록 설정해야 하며, 성능 점수를 사람들끼리 겨룰 수 있게 하는 식임

    • 2006년쯤에는 aws의 가장 작은 장비가 괜찮은 dev 데스크탑 사이즈여서 2년 이상 빌려야 본전을 뽑는 수준이었음, 요즘 AWS 장비는 모바일폰이나 싸구려 노트북 수준이고 3~6개월만 렌트해도 하드웨어를 사는 게 더 이득임, 75% 할인 받지 않는 한 클라우드보다 온프레미스가 인력, 비용 모두 절약임

  • 안녕하세요, Disco라는 오픈소스 PaaS를 친구 Antoine Leclair와 함께 개발하고 있음, 요즘 셀프호스팅, 클라우드 탈출에 대해 많은 논의가 오가는 중임, 궁금한 점 언제든 얘기 환영임

    • 너가 언급한 "서버 리소스 사용량이 매우 낮았다"에서 htop의 load average는 CPU 코어당임을 상기하면 더 인상적임, 예컨대 8코어라면 load average 0.1은 전체 CPU 용량의 1.25% 수준임, 블로그 재밌게 잘 읽었음, 이런 패턴을 통해 나도 좋은 경험을 얻음

    • 이미 Coolify 같은 도구와 비교해 Disco가 특별히 더 제공하는 점이 궁금함, Hetzner VPS에 대부분의 서비스를 호스팅 중이라 Disco만의 강점이 있으면 알고 싶음

  • Hack Club에서 비슷한 경험을 했음, 우리 비영리단체는 고등학생의 코딩, 전자공학 입문을 돕는데 집중하고 있음, 예전엔 Heroku를 썼지만 비용뿐 아니라 이 작은 유틸리티 앱이 월 $15를 낼 만큼 가치가 있나 고민하게 되었음, 올해 Coolify로 셀프호스팅하면서 Hetzner의 월 $300짜리 서버 한 대에 서비스 300개 돌리고 있음, 그 결과 훨씬 많은 코드를 배포할 수 있었음, 가장 큰 깨달음은 99.99%가 아니라 99% 업타임만 필요하다면 세상이 훨씬 넓어진다는 거였음, 대부분 개발자 도구는 99.99%에 집착하는데 99%면 충분하면 효율적으로 운영할 수 있음, Disco도 관심 생겨서 꼭 써볼 계획임

    • 고마움, Disco 서비스 관련 궁금한 부분 있으면 언제든 Discord로 질문 환영임, 비슷한 사례 두 가지가 있는데, 푸에르토리코의 부트캠프/개발학교에서는 학생들의 최종 프로젝트를 단일 VPS에 전부 배포하게 했고, Recurse Center에 라즈베리파이 한 대로 75개 웹 프로젝트를 호스팅 중임(링크)

    • 그리고 정말 99.99%가 필요하다면 hyperscaler(초대형 클라우드 벤더)를 피하는 게 맞다고 생각함, 최근 AWS의 몇 시간짜리 장애가 사례임

    • 300개라니 서비스가 각각 무슨 역할을 하는지 궁금함

  • 현 상황을 보면 셀프호스팅이 정말 매력적인 해법이라고 생각하지만, 글 자체에 대해 언급하고 싶은 점이 있음, 이번 글은 AI가 강하게 편집한 느낌이 있고, 실제로 "Bridging the Gap: Why Not Just Docker Compose?" 파트는 Disco 제품 랜딩페이지의 "Powerful simplicity"를 1:1로 복붙함, 이 블로그 포스트는 그들의 메인 페이지에서 보여주는 유일한 사례 연구이기도 함

    • 완전히 맞는 말임, 세 가지 근거를 대고 싶지만(농담임), 우리 라이브러리는 오픈소스고 Idealist가 비용을 아꼈다는 점이 자랑스러움, 자랑이 홍보에 해당한다면 난 충분히 자랑스러움

    • 마케팅 글이 문제라고 하는데 왜 문제라고 생각하는지 궁금함, HackerNews 가이드라인에서 금지 항목인지, 아니면 모든 마케팅을 표시해야 한다고 생각하는지, 세상에 마케팅 아닌 글은 거의 없음

    • 가격 경쟁에 대해 마케팅 블로그 포스트를 쓰면서도 정작 자사 홈페이지에 가격을 공개하지 않고 미팅 예약만 받아서, 가격 관련해 가장 큰 레드플래그라고 생각함

    • 나도 바로 수익 구조가 궁금해서 찾아봤지만 곧 공개될 것 같다는 생각만 들었음

    • 이번이 처음으로 마케팅이 곁들여진 글이 아니고, 사례 중심 글을 통한 마케팅이 뭐가 문제인지 궁금함, 비교적 온건한 사례이고 마케팅 성격이 있어도 흥미롭고 유용하게 읽었음

  • Heroku 가격은 정말 미침, 10년 전쯤 다녔던 스타트업에서 단순히 HTML 테이블로 QR코드를 만들어 이메일에 표시하는 서비스를 돌리는 데 매월 $10,000 이상을 쓰는 걸 보고 충격받음, 개당 $0.15꼴이었음, 개발 리드가 코드 프로파일링도 해본 적이 없어서 개당 $0.01까지 내렸지만 그래도 황당함

    • 별다른 게 아닌데 왜 QR코드 한 장 만드는 데 그 정도 돈이 드는지 이해할 수 없음, 엣지 클라우드 호스팅만 써도 무료로 가능함

  • 왜 staging 서버를 6대씩(각 $500)이나 써야 하는지 잘 이해가 안 됨, 만약 그게 대형 팀 때문이라면 $3,000 서버비는 연간 $10만 이상 인건비에 비하면 미미하지 않음?, idealist.org를 봤는데 그냥 직업 게시판인데 너무 과하다고 느낌

    • 6대 staging 서버는 main, dev, 그리고 여러 브랜치를 비개발자 QA가 직접 확인하도록 하기 위함임, 각 스테이징 배포마다 Performance-M 다이노, 여러 Standard 다이노, RabbitMQ, 데이터베이스 등으로 금방 비용이 커짐, Idealist 서비스는 일일 10만명에 달해 신뢰성과 속도 뒤에 많은 기술이 들어감

    • 읽어보니 각 개발자별로 여러 서비스를 동시에 띄우는 dev 환경 용도로 staging 서버를 만들었기에 여러 개가 필요했던 것 같음

    • 실제 비용 산정에서 인건비(맨데이) 계산을 다들 간과함

  • Heroku를 대체하면서 Django 사이트와 데이터베이스만 덤프해두고 싶은데 직접 시스템 관리 없이 쓸 수 있는 가장 좋은 옵션이 뭔지 궁금함

    • Render.com이 거의 가장 비슷하고 쓰기에 정말 만족함, 워크플로우도 Heroku와 동일하고 더 저렴하며, 야간 재시작이나 파이썬 최신 버전 지원 모두 만족스러움

    • Docker Swarm을 배우는 것도 추천함, 배포는 컨테이너 한 번 푸시하고 한 명령어로 가능함, 배포와 서비스 diff 겸용 무료 CLI 도구인 rove.dev도 직접 만들었음, 아니면 VM 기반 PaaS도 추천할 만함, 세마포어, Dokku, Dokploy 등 참고

    • 본인이 원하는 VPS 골라서 가격/성능/위치/지원만 맞추고 Coolify, Dokploy 등 원하는 배포 도구를 붙여 사용하면 됨, 최근에 Coolify와 Mythic Beasts로 Django/Postgres를 구글 앱 엔진에서 쉽게 이전함, 숙련도가 많이 녹 슬은 상태여도 정말 손쉽게 마이그레이션 가능했음

    • hetzner에 서버 하나만 띄워서 nginx랑 systemctl 서비스 정도만 설정하면 충분하다고 생각함

    • PythonAnywhere(링크)도 괜찮음

  • 멋진 프로젝트임, 문서를 보니 GitHub 연동이 Disco 필수 요건처럼 보이는데 맞는지 궁금함, 그리고 별도 빌드 과정 없이 내가 가진 레지스트리의 기존 Docker 이미지만 바로 배포할 수 있는지도 궁금함(Kamal의 --skip-push --version latest와 비슷하게)

    • 맞음, 현재로선 GitHub 연동이 필요함, 하지만 Disco가 이미 존재하는 Docker 이미지를 직접 받아와서 배포하는 것도 가능함(우리는 RabbitMQ를 이렇게 셀프호스트함), 예시로 Meilisearch 이미지 배포 방법은 이곳과 이 튜토리얼 참고, 보통 빌드를 하고 레지스트리에 푸시하는 방식인지 궁금하고, 더 자세한 네 배포 과정이 듣고 싶음
답변달기