Herokuの月額3,000ドルの請求を月額55ドルのサーバーで置き換える

 (disco.cloud)
13 ポイント 投稿者 GN⁺ 2025-10-22 | 1件のコメント | WhatsAppで共有
  • 非営利の求人プラットフォーム Idealist は、Herokuで発生していた 高額なステージング環境コスト の問題を解決するため、低価格の専用サーバーへ移行
  • Herokuでは環境ごとに課金される仕組みのため、各ステージング環境で 月500ドル 前後のコストが発生していた
  • その代わりに Hetzner CCX33サーバー（月額55ドル） 1台に複数の環境を構成し、Disco によってHerokuと同じ git push と自動化 の体験を維持
  • 1台のサーバーで6つのステージング環境が安定稼働しており、CPU使用率は2%、メモリ使用量は32GB中14GB程度と余裕がある
  • これにより、ステージング環境は 「コスト負担要因」から「自由に作成できるリソース」 へと変わり、開発チームの実験とデプロイ文化が大きく改善された

実用的なHerokuコスト削減戦略の実体験

問題: 月額500ドルのステージング環境

  • Idealist.orgは、毎月数百万人が訪れる大規模な非営利求人プラットフォームであり、本番環境とほぼ同一の ステージング環境 が不可欠
  • Herokuでは、Web・Worker dynoやPostgresなど必要なアドオンを組み合わせた1つのステージング環境のコストが約 月額500ドル だった
  • dev と main の2つを維持するだけでも、固定費は1,000ドルを超える
  • Herokuの価格設定は 環境単位の課金モデル であり、dynoを減らしても節約幅は小さく、アプリケーションが増えるほどコストが急増する

実験: 単一サーバーへの移行

  • 理想的なコスト削減のため、単一のHetzner CCX33サーバー（月額55ドル） を借りて実験を開始
  • Discoソリューション を活用し、従来のHerokuの git push デプロイ方式 をそのままサーバーに適用
  • すべてのステージング環境で同じサーバー上の 共有Postgresインスタンス を利用し、マネージドデータベースのコスト負担を大幅に削減
  • テストの観点では、開発者ごとの 分離されたデータベース を簡単に初期化できるため適している

Discoを使う理由: Docker Composeとの違い

  • 単にサーバーで docker-compose up するだけでは、開発者体験として十分ではない
  • Disco は次のような利点を提供する
    • Herokuと同じ git push デプロイプロセス
    • すべてのデプロイに対する 自動ゼロダウンタイムデプロイ対応
    • ブランチごとのURLに対する 自動SSL証明書の発行 と更新
    • ログと環境管理 のための直感的なWeb UI
  • 独自のデプロイ管理自動化を構築・維持する必要なく、開発の利便性をそのまま享受できる

ステージング環境の拡大とサーバー資源効率

  • Discoの活用により、ステージング環境の拡張 が非常に容易になった
  • 1台のサーバーで次のような環境を同時に運用している
    • メインブランチ
    • feature-freezeブランチ
    • 一時的なPR用のthrowaway環境
    • 大規模機能開発向けの長期環境
  • 合計 6つの独立したステージング環境 を問題なく起動中
  • Herokuなら月額3,000ドルが必要だが、Hetznerでは CPU 2%、メモリ14GB（32GB中） しか消費しない低コスト構成

トレードオフと現実的な考慮事項

  • 完全な代替ではなく、いくつかの 運用負担 が追加される
  • 新しい環境ごとのDNSやCDN設定などの インフラ作業 は自動化されていない
  • サーバー監視、セキュリティアップデート、障害時対応など 運用責任 が発生する
  • Hetznerは米国リージョンが限定的なため、米国ユーザー向け本番サービス には不向きな場合がある
  • サーバー障害時に再インストールを受け入れるという 可用性のトレードオフ がある
  • アプリケーションをDockerネットワーキングに合わせる作業に、エンジニア1日分ほどの作業が必要だった

得られた洞察と変化

  • 6か月以上運用し、このインフラは 常設の構成 として定着した
  • 最大の変化はコスト削減だけではなく、ステージング環境そのものが 豊富で自由なリソース として認識されるようになった点
  • 開発者は承認やコストの心配なく、必要なときにいつでもpull requestごとの環境を自由に作成できるようになった
  • チーム内では、コスト負担だけでなく 使うことをためらうこと自体が本当の損失だった という教訓を得た
    • "金銭的負担が開発速度と実験を制約してきた"

関連記事

1件のコメント

 
GN⁺ 2025-10-22
Hacker Newsのコメント

  • htop のスクリーンショットを見るとスワップがない点が目についたので、サービスが異常にメモリを食ったときにサーバー全体のダウンを防ぐため、earlyoom を有効にすることを勧めたいです。Linux カーネルの OOM killer はたいてい動くのが遅すぎます。zram を有効にして RAM を圧縮し、プロっぽくオーバープロビジョニングする方法もあります。長時間稼働するソフトウェアはメモリリークを起こしがちですが、圧縮するとかなり効率的です。Hetzner のベアメタルサーバーに Ansible で適用する方法を gist にまとめてあります。VM でも同じように動きます

    • まったく同意しません。スワップに達した時点で、ほとんどのアプリは深刻な問題を抱えることになります。これはあまりにもよく知られた事実で、AWS EC2 インスタンスでもスワップはデフォルトで無効です。もちろん AWS はもっと RAM を売りたいのでしょうが、いずれにせよ今の期待値にスワップは合っていません。90年代ならクリック後に 2〜3 秒待つこともありましたが、今は反応がなければ死んだと思ってすぐ再起動する時代です

    • 別の代案は、メモリを増やし、アプリごとに oom_score を調整して、重要でないアプリには高い kill 重みを、重要なアプリには負の重みを与えることです。たとえば OpenSSH は oom_score_adj がすでに -1000 に設定されています。staging/production サーバーでオーバーコミットを事実上無効化するのも非常に有用です。RAM 容量に応じて min_free と reserve の値を公式で算出して設定します。5 万台の物理サーバーを 10 年以上スワップなしで運用してきましたが、実運用で効果がありました。OOM が起きたのは、コードのデプロイ過程でメモリ要件を見誤ったときだけでした。Java のベストプラクティスに従わない場合の話もありますが長くなるので省きます。cgroup でアプリケーションごとのメモリ制限をかける方法もありますが、説明は割愛します。ディスクへの書き込みが不要な完全インメモリサーバーなら、そもそも OOM が発生しないようにして自動でセルフヒーリングさせるのもおすすめです。DRAC/iLO でクラッシュメッセージを取得するための猶予を与え、panic 再起動設定（kernel.panic、vm.panic_on_oom など）を入れるのも有用です。ちなみに NFS ディスクレスシステムでは、障害対応時に意図的にファーム全体の再起動トリガーとして使うこともできます

    • 参考になる情報をありがとう。systemd のシステム制限設定で RAM の閾値を使って制御しているのですが、プロセスの異常動作でインスタンス全体が応答不能になるのを防ぐには、earlyoom のほうがより良い選択なのか気になります

    • 念のため、ごく少量、たとえば 1GB くらいのスワップを置いておくのは良いアイデアだと思います

    • 2010 年以降、スワップは使っていません

  • 昨日 Nate Berkopec が rails の性能について似たようなテーマの文章を書いていて、Heroku は性能基準で 25〜50 倍高いと言っていました。本当に拍子抜けするほど価格競争する気がなく、もし Sidekiq のようにスタック全体を妥当な価格でライセンスしてくれるだけなら、ハードウェアが別でもずっと良いと思います。2025 年に 1GB RAM の dyno が $50 というのは、ほとんど盗みに近いです。特に標準的な rails アプリは昔よりリソース変動が大きいわけでもなく、むしろ効率的になっているのに、価格は逆に上がり、品質は落ちています。大勢の開発者が月に何百ドルも払って heroku でアプリを動かしながら、実際の開発用 MacBook より遅いマシンを使っているのは笑ってしまうほどです。結局のところ、最近の世の中の流れと大差なく、良い製品を妥当な価格で大衆に提供するより、最もお金を払う上位顧客だけに集中して値上げする傾向なのでしょう

    • 値上げだけの問題ではありません。Heroku やクラウドベンダーは、心理的な価格アンカー効果の恩恵を受けているのだと思います。ユーザーはサービスを始めたときの価格を基準点として持ち、その後の期待値は線形にしか変わらない傾向があります。実際の計算ハードウェア性能は指数関数的に向上するのに、ユーザーの体感は線形です。Heroku の価格は少なくとも 7 年以上変わっていませんが、ハードウェアはものすごく進歩しました。だから詐欺のように感じる理由は、実際には 2025 年の参照点と 2010 年代半ばの価格を比べているからです。大手クラウドベンダーは、新しいハードウェア性能をアンロックしたり SKU を更新したりといった障壁を設けます。Heroku にはこうした競合がいなかったので価格を固定できたわけで、この手の投稿は、新しいエンジニアがハードウェア性能を実感するたびに現れるお決まりのパターンです

    • 1GB RAM の dyno が $50 で盗みに近いと言っていましたが、AWS も大して変わりません。$50/月なら m7a.medium で、1vCPU と 4GB RAM です。RAM は多いですが、AWS がどうしてあれほど金を集められるのかはよく分かります

    • 安い価格でソフトウェアスタック全体を妥当にライセンスするモデルが Sidekiq のようにあってほしいという意見に共感して、私たちは canine.sh をオープンソース化しました。PaaS 事業者が、すでにマージンの乗ったクラウドの上にさらに過剰なマージンを載せる理由はないと思ったからです

    • 地元の整備工場でのオイル交換や、レストランのステーキの値段を見て、自分でやれば安いと言うのと似たようなものです

  • クラウドは、1 台のサーバーでどれだけ多くのことができるかを忘れさせます。staging 環境だけでも高価なクラウドに載せるのは理解しがたいですが、今どきのクラウドはさまざまな要素が複雑に絡んでいるので、その必要性は分かります

    • 複数の開発者にクラウドの基礎を教え、数人のクラウド専門家を置くのは、かなり長い期間コスト効率が良いです。staging/prod 環境を似せておけば、ミスにも早く気づけます。やがて人件費よりクラウド料金のほうが高くなり、その時点でクラウド脱出が本当に得になります。結局、自前サーバーへ移行すると、チームとハードウェアの価格を上回る時点がすぐ来ると思います

    • クラウドのせいで、開発者が Linux サーバーそのものを怖がるようになった気がします。マージンの大半は開発者の不安への対価だと思います。でもセルフホスティングは実際には簡単で楽しいです。Heroku や Vercel のようなところには魅力を感じたことがなく、最初から自分でサーバーを立ててみる以上に良い経験はないと信じています。すべての開発者が一度はやってみることを勧めます

    • 実運用に近い形で prod 環境を完全に複製するのは大いに役立ちます。デプロイ過程も似るので時間を節約でき、実際の prod により近いテストができます

    • これをもとにインフラ学習サイトを作ったら面白そうです。クラウドから X リソースを与えられ、決められた負荷に対応するよう設定し、その性能スコアを人同士で競えるような形です

    • 2006 年ごろは aws の最小構成でもまともな開発用デスクトップ級で、元を取るには 2 年以上借りる必要があるくらいでした。今の AWS マシンは携帯電話や安物ノート PC レベルで、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 のサーバー 1 台で 300 個のサービスを動かしています。その結果、はるかに多くのコードをデプロイできるようになりました。最大の気づきは、99.99% ではなく 99% のアップタイムでよいなら、世界はずっと広がるということでした。多くの開発者向けツールは 99.99% に固執していますが、99% で十分ならかなり効率的に運用できます。Disco にも興味が湧いたので、ぜひ試してみるつもりです

    • ありがとうございます。Disco のサービスについて気になることがあれば、いつでも Discord で歓迎です。似た事例が 2 つあって、プエルトリコのブートキャンプ/開発学校では、学生たちの最終プロジェクトを単一の VPS にすべてデプロイさせましたし、Recurse Center では Raspberry Pi 1 台で 75 個の Web プロジェクトをホストしています（リンク）

    • それに、本当に 99.99% が必要なら、hyperscaler（巨大クラウドベンダー）は避けるべきだと思います。最近の AWS の数時間にわたる障害がその例です

    • 300 個とは、それぞれのサービスがどんな役割なのか気になります

  • 現状を見るとセルフホスティングは本当に魅力的な解決策だと思いますが、記事そのものについて触れておきたい点があります。今回の記事は AI にかなり編集された感じがあり、実際「Bridging the Gap: Why Not Just Docker Compose?」のパートは Disco の製品ランディングページにある「Powerful simplicity」をそのまま 1:1 でコピペしています。このブログ記事は、彼らのメインページで見せている唯一のケーススタディでもあります

    • まったくその通りです。三つほど根拠を挙げたいところですが（冗談です）、私たちのライブラリはオープンソースですし、Idealist がコストを節約できたことを誇りに思っています。誇ることが宣伝に当たるなら、私は喜んで誇ります

    • マーケティング記事が問題だと言いますが、なぜ問題だと思うのか気になります。Hacker News のガイドラインで禁止されているのでしょうか。それとも、あらゆるマーケティングにラベル付けが必要だと思っているのでしょうか。世の中にマーケティングでない文章はほとんどありません

    • 価格競争についてマーケティングブログ記事を書く一方で、自社サイトでは価格を公開せずミーティング予約だけ受け付けているので、価格面では最大のレッドフラグだと思います

    • 私もすぐに収益モデルが気になって調べましたが、近いうちに公開されそうだという印象しか持てませんでした

    • これが初めてのマーケティング混じりの記事というわけでもありませんし、事例中心の記事によるマーケティングの何が問題なのか気になります。比較的おとなしい事例で、マーケティング色があっても興味深く有用に読めました

  • Heroku の価格は本当に狂っています。10 年ほど前にいたスタートアップで、単に HTML テーブルで QR コードを生成してメールに表示するサービスを動かすのに毎月 $10,000 以上使っているのを見て衝撃を受けました。1 件あたり $0.15 でした。開発リードはコードのプロファイリングすらしたことがなく、1 件あたり $0.01 までは下げましたが、それでも absurd です

    • 大したことでもないのに、QR コード 1 枚を生成するのにそこまで金がかかる理由が分かりません。エッジクラウドホスティングを使えば無料でもできます

  • なぜ staging サーバーを 6 台も（各 $500）使う必要があるのかよく分かりません。もし大きなチームだからだとしても、$3,000 のサーバー代は年収 $10 万超の人件費に比べれば微々たるものでは？ idealist.org を見ましたが、ただの求人掲示板に見えて、そこまで大げさに感じます

    • staging サーバー 6 台は、main、dev、それに複数のブランチを非開発者の QA が直接確認できるようにするためです。各 staging デプロイごとに Performance-M dyno、複数の Standard dyno、RabbitMQ、データベースなどが必要で、すぐにコストが膨らみます。Idealist のサービスは日次 10 万人規模なので、信頼性と速度の裏には多くの技術があります

    • 読んだ感じでは、各開発者向けに複数サービスを同時に立ち上げる dev 環境として staging サーバーを作っていたので、複数必要だったようです

    • 実際のコスト見積もりでは、人件費（工数）計算をみんな見落としがちです

  • Heroku を置き換えつつ Django サイトとデータベースだけダンプしておきたいのですが、自分でシステム管理をせずに使える最善の選択肢は何でしょうか

    • Render.com がほぼ一番近く、とても満足して使っています。ワークフローも Heroku と同じで、より安く、夜間の再起動や Python の最新バージョン対応も満足です

    • Docker Swarm を学ぶのもおすすめです。デプロイはコンテナを 1 回 push して 1 コマンドでできます。デプロイとサービス diff の両方に使える無料 CLI ツール rove.dev も自作しました。あるいは VM ベースの PaaS もおすすめできます。Semaphore、Dokku、Dokploy などを見てください

    • 自分に合う VPS を選んで、価格/性能/場所/サポートが合えば、Coolify や Dokploy のような好きなデプロイツールを載せて使えばよいです。最近 Coolify と Mythic Beasts で Django/Postgres を Google App Engine から簡単に移行しました。スキルがかなり錆びついていた状態でも、本当に手軽にマイグレーションできました

    • hetzner にサーバーを 1 台立てて、nginx と systemctl サービスを設定する程度で十分だと思います

    • PythonAnywhere（リンク）も良いです

  • 素晴らしいプロジェクトですね。ドキュメントを見ると GitHub 連携が Disco の必須要件のように見えるのですが、その理解で合っていますか？ また、別途ビルド工程なしで、自分のレジストリにある既存の Docker イメージだけをそのままデプロイできるのかも気になります（Kamal の --skip-push --version latest のように）

    • はい、現時点では GitHub 連携が必要です。ただし Disco は、すでに存在する Docker イメージを直接取得してデプロイすることもできます（私たちは RabbitMQ をこの方法でセルフホストしています）。例として、Meilisearch イメージのデプロイ方法は こちら と このチュートリアル を参照してください。普段はビルドしてレジストリに push する方式でしょうか。あなたのデプロイ手順についてもっと詳しく聞いてみたいです