制限

この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。

最終更新日 2024年05月08日(水)

この記事は、Heroku プラットフォームのさまざまなコンポーネントで課される制限をまとめたものです。

制限は、さまざまな理由から存在します。Heroku プラットフォームのアーキテクチャ (Heroku ではアプリのログ履歴が最新の 1500 行しか保存されないなど) によって存在する制限もあれば、良質なプラットフォームシチズンシップ (1 時間あたり 4500 より多くのプラットフォーム API リクエストを行うことができないなど) を確保するために存在する制限もあります。

以下に記載されている制限の多くは他の Dev Center の記事にリンクされており、リンク先でその制限に関する詳細が提供されます。

アプリ

アプリ名

アプリ名は 30 文字以内にする必要があります。

アプリの最大数

  • 1 つのアカウントに 100 個までのアプリを保有できます。
  • Heroku Team は 100 個までのアプリを保有できます。
  • Enterprise Team は 200 個までのアプリを保有できます。

アプリあたりの最大カスタムドメイン数

1 つのアプリには、最大 1,000 件のカスタムドメインを割り当てることができます。

ソース

ログ

ログ履歴

Heroku では、ログ履歴は最新の 1500 行のみが保存されます。1500 行より多くを保存する場合は、ロギングアドオンを使用するか、独自の syslog ドレインを作成します。

ソース

ドレイン

どのアプリでも、最大で 5 つのドレインを使用できます。

行の長さ

10000 バイトを超える dyno によって生成される行は、末尾に新規行を追加せず、10000 バイトのチャンクに分割されます。チャンクはそれぞれ、個別のログ行として提示されます。

ソース

ビルド、CI、リリースフェーズ

ビルド、CI 実行、リリースフェーズによって生成されるログ出力は、300 MB に制限されています。その制限に到達するすべての出力は、先頭から 150 MB のチャンクで切り捨てられます。

ルーター

HTTP タイムアウト

HTTP リクエストでは、最初の 30 秒間の時間枠で Web プロセスが応答データ (完了済みの応答、またはプロセスがアクティブであることを示す一定量の応答データ) を返す必要があります。最初の 30 秒間の時間枠で応答データを返さないプロセスでは、ログに H12 エラーが表示されます。

初回応答の後、サーバーから送信されるバイトごとに繰り返しの 55 秒間の時間枠が再開されます。同様の 55 秒間の時間枠が、クライアントから送信されるバイトごとに再開されます。

この 55 秒間の時間枠で dyno からのデータが何も受信されない場合は、接続が切断され、H15 エラーがログに記録されます。

同様に、この 55 秒間の時間枠でクライアントからのデータが何も受信されない場合は、接続が切断され、H 28 エラーがログに記録されます。

ソース

HTTP 応答バッファ

ルーターは、1 つの接続あたりの dyno からの応答に対して、1MB のバッファを維持します。

ソース

HTTP リクエストバッファ

受信リクエストを処理するとき、ルーターは 8 KB の受信バッファを設定し、HTTP リクエスト行およびリクエストヘッダーの読み込みを開始します。それぞれの長さは最大で 8 KB ですが、まとめると合計で 8 KB より大きくなります。リクエスト行またはヘッダー行が 8KB より長いリクエストはディスパッチされずにルーターによって破棄されます。

ソース

dyno

dyno メモリ

dyno のサイズに応じて、最大 RAM の量は異なります。

  • eco​、basic​、standard-1x​ では 512 MB
  • standard-2x​ と private-s​ では 1 GB
  • performance-m​、private-m​、shield-m​ では 2.5 GB
  • performance-l​、private-l​、shield-l​ では 14 GB
  • performance-l-ram​、private-l-ram​、shield-l-ram​ では 30 GB
  • performance-xl​、private-xl​、shield-xl​ では 62 GB
  • performance-2xl​、private-2xl​、shield-2xl​ では 126 GB

ソース

dyno メモリと再起動

アプリケーションで使用できる RAM の上限は、使用する dyno タイプ​によって異なります。Dyno Manager によって dyno が再起動され、メモリ使用率が以下の場合は R15 エラー​がログ記録されます。

  • eco​、basic​、または standard-1x​ dyno が割り当ての 2 倍にあたる 1 GB に到達した場合。
  • standard-2x​ dyno が割り当ての 2 倍にあたる 2 GB に到達した場合。
  • performance-m​ dyno が割り当ての 2 倍にあたる 5 GB に到達した場合。
  • performance-l​ dyno が割り当ての 2 倍にあたる 28 GB に到達した場合。
  • performance-l-ram​ dyno が割り当ての 1.2 倍にあたる 36 GB に到達した場合。
  • performance-xl​ dyno が割り当ての 1.2 倍にあたる 74 GB に到達した場合。
  • performance-2xl​ dyno が割り当ての 1.2 倍にあたる 151 GB に到達した場合。
  • private-s​ または shield-s​ dyno が割り当ての 1 GB に到達した場合。
  • private-m​ または shield-m​ dyno が割り当ての 2.5 GB に到達した場合。
  • private-l​ または shield-l​ dyno が割り当ての 14 GB に到達した場合。
  • private-l-ram​ または shield-l-ram​ dyno が割り当ての 30 GB に到達した場合。
  • private-xl​ または shield-xl​ dyno が割り当ての 62 GB に到達した場合。
  • private-2xl​ または shield-2xl​ dyno が割り当ての 126 GB に到達した場合。

ソース

接続された One-off dyno のタイムアウト

One-off dyno への接続は、(入力と出力の両方で) アイドル状態が 1 時間続くと終了します。接続が終了すると、dyno には SIGHUP が送信されます。このアイドルタイムアウトにより、対話型コンソールセッションを開いて使用しないままにすることによる、意図しない請求の発生が阻止されます。

ソース

分離された One-off dyno のタイムアウト

分離された One-off dyno は 24 時間ごとに再起動されます。つまり、One-off dyno の実行時間は最長で 24 時間となります。

ソース

One-off dyno の停止

アプリごとに以下の制限があります。

  • 1 つの Eco One-off dyno (Eco には Eco dyno プラン)​のサブスクリプションが必要)
  • 最大 50 の並列 One-off Basic dyno
  • 最大 50 の並列 One-off Standard-1X dyno
  • 最大 50 の並列 One-off Standard-2X dyno
  • 最大 5 つの並列 One-off Performance-M dyno
  • 最大 5 つの並列 One-off Performance-L dyno
  • 最大 5 つの並列 One-off Performance-L-RAM dyno
  • 最大 5 つの並列 One-off Performance-XL dyno
  • 最大 5 つの並列 One-off Performance-2XL dyno
  • 最大 5 つの並列 One-off Private-S dyno
  • 最大 5 つの並列 One-off Private-M dyno
  • 最大 5 つの並列 One-off Private-L dyno
  • 最大 5 つの並列 One-off Private-L-RAM dyno
  • 最大 5 つの並列 One-off Private-XL dyno
  • 最大 5 つの並列 One-off Private-2XL dyno
  • 最大 5 つの並列 One-off Shield-S dyno
  • 最大 5 つの並列 One-off Shield-M dyno
  • 最大 5 つの並列 One-off Shield-L dyno
  • 最大 5 つの並列 One-off Shield-L-RAM dyno
  • 最大 5 つの並列 One-off Shield-XL dyno
  • 最大 5 つの並列 One-off Shield-2XL dyno

アプリケーションのこの制限を上げるには、リクエストを送信​します。

ソース

環境設定

環境設定のデータ (すべてのキーと値の集まり) は、各アプリにつき 32 KB 以内に制限されています。

ソース

ブートタイムアウト

dyno の Web プロセスでは、割り当てられた $PORT へのバインドに 60 秒以上かかってはなりません。

アプリケーションのブートにさらに多くの時間が必要な場合、ブートタイムアウトツール​を使用して上限を増やすことができます。ただし、一般的に起動時間が遅いとアプリケーションのデプロイが困難になり、dyno のエラーからのリカバリにも時間がかかるため、これは一時的な解決策​としてください。

ソース

終了タイムアウト

dyno が強制終了または再起動された場合、dyno 内のプロセスが SIGTERM を受信してから終了するまで 30 秒間もうけられています。この 30 秒が経過すると、プロセスに SIGKILL が送信され、プロセスは強制終了されます。

ソース

dyno の再起動の制限

これらの制限は、「dyno の自動再起動​」および「dyno のクラッシュ再起動ポリシー​」に記載されています。

dyno のスケール

eco​ および basic​ dyno タイプでは、プロセスタイプごとに​最大 1 つの実行中の dyno がサポートされます。さらに、eco​ dyno タイプを使用するアプリケーションは、最大で 2 つの並列実行されている dyno に制限されます。

デフォルトで、すべてのアプリケーションは 100 dyno に制限されています。さらに、performance​、private​、shield​ dyno では、プロセスタイプを、10 を超える dyno が使用されるようにスケーリングすることはできません。

アプリケーションのこの制限を上げるには、リクエストを送信​します。

ソース

プロセス/スレッド

同時に 1 つの dyno 内に存在できるプロセス/スレッドの最大数は、dyno タイプ​に応じて異なります。

  • eco​ dyno、basic​ dyno、および standard-1x​ dyno の場合、最大数は 256 以下です。
  • standard-2x​ dyno および private-s​ dyno の場合、最大数は 512 以下です。
  • performance-m​、private-m​、shield-m​ dyno の場合、最大数は 16384 です。
  • performance-l​、private-l​、shield-l​ dyno の場合、最大数は 32768 です。
  • performance-l-ram​、private-l-ram​、shield-l-ram​ dyno の場合、最大数は 24576 です。
  • performance-xl​、private-xl​、shield-xl​ dyno の場合、最大数は 32768 です。
  • performance-2xl​、private-2xl​、shield-2xl​ dyno の場合、最大数は 65536 です。

これらの上限には、実行中、休止中、またはその他の状態のすべてのプロセスとスレッドが含まれます。スレッドとプロセスはこの上限に対してカウントされることに注意してください。たとえば、255 のスレッドと 1 つのプロセスが含まれる standard-1x​ dyno は、制限が 256 以下であるため、上限に到達しています。

ソース

ビルド

並列ビルド

検証済みアカウント​のみが、1 つのアカウントで複数のアプリのビルドを同時に実行できます。

確立された支払履歴のない検証済みユーザーは、一度に 10 個まで並列ビルドを作成できます。確立された支払履歴のある検証済みユーザーは、一度に 300 個まで並列ビルドを作成できます。

ほぼ同じアプリに対して Heroku Pipeline​ を正しく使用していることを確認します。同じアプリの複数のバージョンを構築してデプロイする代わりに、パイプラインを使用して Slug を一度構築し、その Slug をパイプライン内の複数のアプリにプロモートします​。

Git リポジトリ

ユーザーは、1 時間あたり、アプリごと、ユーザーごとに、Heroku Git リポジトリ​に対して 75 件のリクエストの繰り返しに制限​されます。

リポジトリからの HEAD​ のチェックアウトの圧縮されていないサイズは、復元されたサブモジュールのサイズと合わせて 1 GB 以下にする必要があります。

ソース

slug のサイズ

slug のサイズは、正常に行われたコンパイルの最後に表示されます。slug のサイズ (圧縮後) は最大 500 MB であり、大半のアプリはこの上限を十分下回るようにします。slug のサイズが 300 MB に達すると、slug のサイズが大きくなるとブート時間が長くなる可能性がある旨が警告されます。

ソース

slug のコンパイル

slug のコンパイルは 15 分に制限されています。

ソース

Heroku Postgres

Dataclips の行制限

Dataclips が返す行は最大で 100,000 行です。

ソース

Dataclips のデータ制限

Dataclips が返すデータは最大で 100 MBです。

ソース

Dataclips のクエリ制限のタイムアウト

Dataclips では、クエリは 10 分経過するとキャンセルされます。

ソース

Basic、Standard、Premium、Enterprise 層の制限

Postgres プランの各層に関連する制限については、「Choosing the Right Heroku Postgres Plan​」 (適切な Heroku Postgres プランの選択) の記事で説明されています。

資格情報の制限

Heroku Postgres では 120 個までの資格情報がサポートされています。

ソース

セキュリティと運用上の理由から、使用する資格情報はできるだけ少なくすることを強くお勧めします。資格情報を使用している場所を必ず追跡してください。

API

Heroku API の制限

Heroku API の呼び出しは、1 時間あたり最大 4500 回に制限されています。

ソース

ネットワーク

ネットワーク帯域幅

ネットワーク帯域幅はアプリあたり 1 か月で 2 TB にソフト制限されています。

Enterprise Team

メンバーシップの制限

Enterprise Team のメンバーシップは、以下のとおり制限されています。

  • エンタープライズ以外のアカウント: 25 メンバー
  • エンタープライズアカウント: 500 メンバー

その他

SSH キーの最大数

すべてのアカウントで、最大 50 の SSH キーをアカウントに関連付けられます。それ以上必要な場合は、Build API​ の使用を検討してください。