Skip Navigation
Show nav
Heroku Dev Center
  • Get Started
  • ドキュメント
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
  • ドキュメント
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
View categories

Categories

  • Heroku のアーキテクチャ
    • Dyno (アプリコンテナ)
    • スタック (オペレーティングシステムイメージ)
    • ネットワーキングと DNS
    • プラットフォームポリシー
    • プラットフォームの原則
  • コマンドライン
  • デプロイ
    • Git を使用したデプロイ
    • Docker によるデプロイ
    • デプロイ統合
  • 継続的デリバリー
    • 継続的統合
  • 言語サポート
    • Node.js
    • Ruby
      • Bundler の使用
      • Rails のサポート
    • Python
      • Django の使用
      • Python でのバックグランドジョブ
    • Java
      • Maven の使用
      • Java でのデータベース操作
      • Spring Boot の使用
      • Java の高度なトピック
    • PHP
    • Go
      • Go の依存関係管理
    • Scala
    • Clojure
  • データベースとデータ管理
    • Heroku Postgres
      • Postgres の基礎
      • Postgres Getting Started
      • Postgres のパフォーマンス
      • Postgres のデータ転送と保持
      • Postgres の可用性
      • Postgres の特別なトピック
    • Heroku Redis
    • Apache Kafka on Heroku
    • その他のデータストア
  • モニタリングとメトリクス
    • ログ記録
  • アプリのパフォーマンス
  • アドオン
    • すべてのアドオン
  • 共同作業
  • セキュリティ
    • アプリのセキュリティ
    • ID と認証
    • コンプライアンス
  • Heroku Enterprise
    • Private Space
      • インフラストラクチャネットワーキング
    • Enterprise Accounts
    • Enterprise Team
    • Heroku Connect (Salesforce 同期)
      • Heroku Connect の管理
      • Heroku Connect のリファレンス
      • Heroku Connect のトラブルシューティング
    • シングルサインオン (SSO)
  • パターンとベストプラクティス
  • Heroku の拡張
    • Platform API
    • アプリの Webhook
    • Heroku Labs
    • アドオンのビルド
      • アドオン開発のタスク
      • アドオン API
      • アドオンのガイドラインと要件
    • CLI プラグインのビルド
    • 開発ビルドパック
    • Dev Center
  • アカウントと請求
  • トラブルシューティングとサポート
  • Integrating with Salesforce
  • Heroku のアーキテクチャ
  • プラットフォームポリシー
  • 制限

制限

日本語 — Switch to English

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

最終更新日 2022年11月28日(月)

Table of Contents

  • アプリ
  • ログ
  • ルーター
  • dyno
  • ビルド
  • Heroku Postgres
  • API
  • ネットワーク
  • Enterprise Team
  • その他

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

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

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

アプリ

アプリ名

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

アプリの最大数

1 つのアカウントに 100 個までのアプリを保有できます。

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

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​ では 1024 MB
  • performance-m​ では 2.5 GB
  • performance-l​ では 14 GB

ソース

dyno メモリと再起動

dyno のメモリサイズが割り当ての 2 倍 (Standard-1x dyno の場合は 512 MB x 2 = 1 GB) に達するまで増え続けると、Dyno Manager によって dyno が R15 エラーで再起動されます。

ソース

接続された 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
  • 最大 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

アプリケーションのこの制限を上げるには、セールスに問い合わせ​ます。

ソース

環境設定

環境設定のデータ (すべてのキーと値の集まり) は、各アプリにつき 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 に制限されています。さらに、プロセスタイプを、10 を超える performance​ dyno を使用するようにスケーリングすることはできません。

アプリケーションのこの制限を上げるには、セールスに問い合わせ​ます。

ソース

プロセス/スレッド

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

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

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

ソース

ビルド

並列ビルド

Heroku では、1 つのアカウントで同時に複数のアプリのビルドを実行することを、検証済みアカウント​にのみ許可しています。確立された支払履歴のない検証済みユーザーは、一度に 10 個まで並列ビルドを作成できます。確立された支払履歴を持つ検証済みユーザーは、一度に 300 個まで並列ビルドを作成できます。

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 プランの選択) の記事で説明されています。

API

Heroku API の制限

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

ソース

ネットワーク

ネットワーク帯域幅

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

Enterprise Team

メンバーシップの制限

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

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

その他

SSH キーの最大数

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

関連カテゴリー

  • プラットフォームポリシー
負荷テストのガイドライン スタック更新ポリシー

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Podcasts
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing

Subscribe to our monthly newsletter

Your email address:

  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Heroku Podcasts
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Facebook
  • Instagram
  • Github
  • LinkedIn
  • YouTube
Heroku is acompany
  • heroku.com
  • Terms of Service
  • Privacy
  • Cookies
  • Cookie Preferences
  • Your Privacy Choices
  • © 2023 Salesforce.com