お問い合わせ
  • アプリ開発

Heroku本番運用3年の学び ― 強みと、運用でわかったこと

「スマホアプリを作ります」と言うとき、実際に作っているのはアプリだけではありません。データを置く場所、アプリと通信するAPI、決まった時間に動く処理、管理画面。この裏側がなければアプリは成立しません。
アプリとHerokuの関係
弊社では、その裏側をHerokuというプラットフォーム(PaaS:Platform as a Service)の上に構築することが多くあり、3年近くいくつものシステムで運用をしてきました。
この記事では、そのHerokuについて「何が良かったのか」「運用してみて何がわかったのか」を、実際に本運用をしてきた経験から書いていきます。

Herokuの強み ― 実際に効いた4つのポイント

3年運用してきて、Herokuを使っていて良かったと感じるのは次の4点です。

強み1:必要なものが1つのプラットフォームに揃う

Web・API・cron・DB・ストレージが別サービスに散ると、認証もネットワークも監視も請求もバラバラになります。Herokuはアプリを置けばHTTPSまで付いてきて、データベースも同じ画面から足せます。「どこに何があるか」を追いかける時間が、そもそも発生しません。

強み2:git push から本番リリースまでが速い

HerokuではGitHubと連携することで、「git push」するだけでシステムをリリースすることができます。最初のリリースまでの速度は、そのままプロジェクトの成否に関わると言っても過言ではありません。インフラ構築に2週間かけずに済むのは、それ自体が価値だと考えています。

強み3:運用に必要な周辺機能を、必要になってから足せる

定期実行が要る、ログをSlackに流したい、外向き通信のIPを固定したい。運用が始まってから出てくる要望に、アドオンを足すだけで応えられます。最初から全部を設計し切らなくてよいというのは、実務ではかなり大きい利点です。

強み4:構成が標準的なので、あとで別の環境に移しやすい

最初の環境を一生使うとは限りません。Herokuは公式buildpackとPostgresという一般的な構成なので、あとで別の環境へ載せ替えるときの障壁が低くなります。

Herokuで実際に何を利用してきたか

実際に使っている機能とアドオンは以下のようなものになります。(あくまで一例です)

アプリ実行 Dyno(Web / worker)、Procfileによる起動制御
ビルド 公式buildpack(Node.js / PHP)など
データベース Heroku Postgres
Salesforce連携 Heroku Connect
定期実行 Heroku Scheduler
デプロイ Heroku Pipelines、Review Apps
監視・通知 Papertrailでログを収集し、エラーをSlackへ自動通知
ネットワーク Fixie(外向き通信のIP固定)、IP制限
障害時の見せ方 エラーページ / メンテナンスページのカスタマイズ

このうち、実運用で特に効いているものを3つ紹介します。

Review Apps

プルリクエストを出すと、検証用の環境が自動で立ち上がります。「この画面、実際に触って確認したい」という依頼に、URLをお渡しするだけで応えられます。レビューの質が変わりました。

Papertrail から Slack への通知

ログを人間が見に行く運用は続きません。エラーレベルなどの条件で検索を保存しておき、引っかかったらSlackに飛ばしています。

運用してみた実感としては、通知を作ることよりも、ノイズを削る作業のほうが本体でした。調査済みで対応不要なエラーを除外条件に積み上げていくことで、「鳴ったら見る」状態を維持しています。

Heroku Connect

Salesforceに入っているデータを、コードを書かずにPostgresへ同期できる仕組みです。Salesforceを業務基盤にされているお客様のシステムでは、これがあるかないかで構成がまるごと変わります。

※ Heroku Connectがあるから、Herokuをシステム基盤として選択するということが多い印象です。

運用でわかったこと ― 直面した制約

実際に運用する中で、Heroku固有の制約には以下のようなものがありました。

リクエストは30秒でタイムアウトとなる

Herokuのルーターは30秒でタイムアウトします。設定で短くすることはできますが、長くすることはできません。CSVダウンロードや画像の一括ダウンロードで、実際に詰まりました。

対処は設計側で行います。非同期ジョブにする、ストリーミングで返す、事前に生成してストレージから配る。制約が先にあるぶん、最初から素直な設計に寄せられるという言い方もできます。

メモリ超過はアプリを落とす

画像データをサーバー側でメモリに展開している箇所があり、メモリ逼迫のアラートが鳴り続けたことがありました。原因を特定し、データを展開せずそのまま返す形に変更したところ、メモリ使用量のグラフが目に見えて落ち着きました。

Herokuはメモリ超過を明確なエラーコードで知らせてくれるので、原因調査の起点はつかみやすいと感じています。

エラーコードは「結果」しか教えてくれない

「アプリが落ちた」というルーター側のエラーは出ますが、なぜ落ちたのかはアプリ側のログを見に行かないとわからない場合がありました。

実際、リリースしたのにアクセスできず、調べてみたら起動コマンドの定義漏れだった、ということが2回ありました。ログを確認する癖がつくまでは、ここで時間を使うことになります。

まとめ ― 3年運用して

ここまで、Herokuの強みを4つ、運用で当たった制約を3つ挙げてきました。

必要なものが一箇所に揃っていて、リリースは速く、足りないものは後から足せて、いざとなれば別の環境にも移せる。
規模の小さい立ち上げに向いているのはもちろんですが、お客様の業務の中心で動くシステムでも、これらの強みを活かして開発のスピードを保ったまま構築できました。

制約はあるものの、30秒の壁もメモリ超過も、事前に把握して設計に織り込んでおけば、安定して動かし続けられます。率直に言って、3年運用してきて、困った場面よりも助かった場面のほうが多かったです。

運用の中で、ただHerokuの操作方法覚えるのではなく、「30秒リクエストがタイムアウトする前提でどう設計するか」などの「インフラも交えてシステム設計をどうするか」について、学ぶことができたと感じています。

補足:2026年2月の発表について

2026年2月6日、Herokuは公式ブログ「An Update on Heroku」で今後の開発方針を発表しています。Salesforceが投資をAI領域に集中させるため、Herokuは新機能の開発を行わず、セキュリティ・安定性・信頼性・サポートの維持に専念する体制(sustaining engineering model)へ移行する、という内容です。

発表で示されている主な内容は次のとおりです。

  • 新機能の開発は行われない
  • 新規のお客様向けには、Enterprise Account契約が提供されない
  • クレジットカードでのご利用は、新規・既存ともに料金・課金・サービスに変更なし
  • アプリ、パイプライン、Team、アドオンといったコア機能への影響はなし

本記事で紹介した強みや制約は、あくまで弊社がこれまでHerokuを運用してきた中で得た経験にもとづくものです。これから新規にHerokuの利用を検討される場合は、この発表の内容もあわせて考慮に入れていただき、最新の情報については、Herokuの公式アナウンスをご確認ください。

ドコドア エンジニア部

ドコドア エンジニア部

Flutterなどの技術を活用し、ユーザーにとって価値ある高品質なモバイルアプリ・Webアプリの開発に取り組んでいます。
このブログでは、アプリ開発の現場で培ったフロントエンド、バックエンド、インフラ構築の知識から生成AI活用のノウハウまで、実践的な情報をアプリ開発に悩む皆様へ向けて発信しています!
【主な技術スタック】 Flutter / Firebase / Svelte / AWS / GCP / OpenAI API

Contact Us

Web制作、Webマーケティング、SFA・MA導入支援に関するお悩みがある方は、お気軽にご相談ください。

お問い合わせ・ご相談

ホームページ制作、マーケティングにおける
ご相談はお気軽にご連絡ください。

資料請求

会社案内や制作実績についての資料を
ご希望の方はこちらから。

お電話でのお問い合わせ

お電話でのご相談も受け付けております。

※コールセンターに繋がりますが、営業時間内は即日
担当より折り返しご連絡をさせて頂きます。

9:00-18:00 土日祝休み

電話する 無料相談はこちら