dyno および Dyno Manager

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

最終更新日 2024年04月25日(木)

Heroku アプリケーションはすべて、dyno​ と呼ばれる軽量の Linux コンテナの集まりにおいて実行されます。この記事では、Heroku プラットフォームの dyno の規則について説明します。

dyno の価格設定の詳細については、「Heroku 価格設定の概要​」を参照してください。

dyno の設定

すべての dyno は以下の 3 つの設定のうちいずれかに属しています。

  • Web​: Web dyno は、Procfile​ で定義される、「Web」プロセスタイプの dyno です。ルーター​から HTTP トラフィックを受信するのは Web dyno だけです。

  • Worker​: Worker dyno は、Procfile ファイルで宣言された「Web」以外のあらゆるプロセスタイプの dyno です。Worker dyno は通常、バックグラウンドジョブ、キューイングシステム、タイムドジョブに使用されます。アプリケーションで複数の種類の Worker dyno を使うことができます。たとえば、1 つを緊急のジョブに、もう 1 つを長期実行ジョブに使用します。詳細については、「Worker dyno、バックグラウンドジョブおよびキューイング​」を参照してください。

  • One-off​: One-off dyno は、単独で、または入力/出力をローカルのターミナルに接続して実行できる一時的な dyno です。これらには最新のリリースがロードされます。データベース移行やコンソールセッションなどの管理タスクの処理に使用できます。Heroku Scheduler​と同様、不定期のバックグラウンド処理の実行にも使用できます。詳細については、「One-off dyno​」を参照してください。

Web dyno または Worker dyno が開始されると、アプリの Dyno formation​ (各プロセスタイプの実行中の dyno の数) が変わり、dyno ライフサイクルに依存します。Dyno formation は、変更しない限りそのまま保持されます。一方、One-off dyno は短期間のコマンドを実行してから終了するのみで、Dyno formation には影響しないことが想定されています。

Dyno Manager

Dyno Manager により、dyno は自動で実行を継続します。つまり、アプリは通常自動操作でメンテナンスも不要です。Common Runtime​ には、地域あたり 1 つの Dyno Manager があり、地域で実行されているすべてのテナントについて dyno の管理を担当します。Private Spaces Runtime には、スペースごとに専用の Dyno Manager があります。この Dyno Manager は、そのスペース内で実行されている dyno のみ管理します。

dyno タイプ

Heroku では多数の異なる dyno タイプを提供しており、それぞれに一連の独自のプロパティとパフォーマンス特性が備わっています。Eco dyno、Basic dyno、Standard dyno、Performance dyno​ は、Common Runtime ですべての Heroku ユーザーにご利用いただけます。Private dyno は Private Space でのみ実行され、Heroku Enterprise​ で利用できます。

スケーラビリティ

水平方向への拡張 (スケールアウト) の場合は、dyno を追加します。たとえば、dyno を追加すると、より多くの並列 HTTP リクエストを処理できるため、より大量のトラフィックを処理できます。詳細については、「Dyno formation のスケーリング​」を参照してください。

垂直方向への拡張 (スケールアップ) の場合は、より大きな dyno を使用します。アプリケーションで使用できる RAM の上限は、使用する dyno タイプによって異なります。Common Runtime の詳細については「dyno タイプ​」を、Private Space の詳細については「Heroku Enterprise​」を参照してください。

水平方向および垂直方向の拡張はいずれも Professional dyno の機能であり、eco​ dyno または basic​ dyno では利用できません。

冗長性

複数の dyno が実行中のアプリケーションは、障害に対して冗長性が高くなります。dyno が欠落している場合、アプリケーションはリクエストの処理を続行し、欠落している dyno は置き換えられます。通常、欠落している dyno はただちに再起動されますが、重大な障害の場合は時間がかかることがあります。複数の dyno が異なる物理インフラストラクチャ (個別の AWS アベイラビリティ―ゾーンなど) で実行される可能性も高く、さらに冗長性が増します。

分離とセキュリティ

セキュリティ上の理由から、すべての dyno はそれぞれ強力に分離されています。Heroku では追加のカスタムハードニングによる OS のコンテナ化を使用して、すべてのお客様についてアクセスが適切に制限されるようにしています。

Eco dyno、Basic dyno、および Standard dyno は、完全に分離されている場合でも、基礎となるコンピューティングインスタンスを共有していることがあります。Heroku では、複数の手法を採用して、基礎となるリソースが適正に使用されるようにしています。ただし、これらの dyno タイプでは、基礎となるインスタンスへの負荷合計に応じてパフォーマンスにばらつきが出る可能性があります。

Performance dyno および Private dyno は、基礎となるコンピューティングインスタンスを他の dyno と共有しません。そのため、これらの dyno タイプは強力なだけではなく、パフォーマンスのばらつきが少なく、安定しています。専用のコンピューティングリソースを備えているのに加え、Private dyno はこれらがデプロイされている Private Space によって決定される独自の仮想ネットワークにさらに分離されています。

一時的なファイルシステム

各 dyno には、最も最近デプロイされたコードの新しいコピーが含まれる、独自の一時的なファイルシステムがあります。dyno の生存期間中、実行中のプロセスでこのファイルシステムを一時的なスクラッチパッドとして使用できますが、書き込まれたファイルは他の dyno のプロセスでは表示されず、書き込まれたすべてのファイルは dyno が停止または再起動した時点で破棄されます。この破棄は、アプリケーションのデプロイによって dyno が置き換えられるたび、および通常の dyno 管理の一環としておよそ一日一回発生します。

システムクロックおよび時間の同期

dyno は、カーネルのパススルーから間接的に Network Time Protocol (NTP) を時間の同期に使用します。dyno の基礎となるホストは、Heroku プラットフォームの Stratum 2 NTP サーバーによって提供されるタイムサービスを使用するように設定されています。これらのサーバーは、NIST​ によって提供される Stratum 1 タイムサーバーのプールに順番に同期されます。Herokuでは、同じタイムサーバーがフリート全体で使用され、場所に関係なく時間が均一で同期されるようになっています。

ネットワーキング

各 dyno には独自のネットワークインターフェースがあります。周辺のネットワーク設定はランタイム​のタイプによって異なります。

Common Runtime のネットワーキング

Common Runtime では、ファイアウォールを設定することによって、すべての dyno が相互に強力に分離されます。dyno に到達できる唯一のトラフィックは、$PORT​ 環境変数で指定されるポート番号をリッスンする Web プロセスにルーターから転送される Web リクエストです。Worker dyno および One-off dyno はインバウンドリクエストを受信することができません。

dyno 内の個々のプロセスは任意のアドレスやポートにバインドされ、バインドされたプロセス間で標準 TCP などを使用して通信することができます。各 dyno の外部ネットワークインターフェース (eth0) は、範囲が 172.16.0.0/12 の /30 プライベートサブネット (172.16.83.252/30 、172.30.239.96/30 など) の一部となります。1 つの dyno 内のプロセスは、IP またはサブネットを他の dyno と共有することも、他の dyno の TCP セッションの状態を監視することもありません。

Common Runtime のすべての dyno タイプは、インターネット上の他の場所で実行されているサービスにアウトバウンドリクエストを行うことができます。ユーザーは、これらのリクエストの発信元となる IP アドレスを制御できません。

Private Spaces Runtime ネットワーキング

Private Space 内の dyno はすべて、そのスペースの一部として設定されている仮想プライベートネットワークを通じて接続されています。スペースにインストールされているすべてのデータサービスも、このネットワークに接続されています。Common Runtime と同様、Web プロセスは $PORT​ 環境変数で指定されているポート番号をリッスンすることによって Web リクエストを受信できます。さらに、dyno 内のすべてのプロセスは任意のポート番号をリッスンし、プライベートネットワーク上の他の dyno から接続を受信することができます。これは、Web プロセス、Worker プロセス、One-off プロセスでサポートされます。

信頼済み IP 範囲​は、Private Space 内のアプリケーションと通信できるクライアント IP を制御するために使用できます。

Private Space 内の dyno は、すべての接続が一連の固定のアウトバウンド IP アドレス​から発信されるようにする NAT ゲートウェイ経由で、他のインターネットサービスへのアウトバウンド接続を行います。

dyno 管理用 CLI コマンド

アプリの dyno 設定を表示および変更するには、Heroku CLI を使用します。

タスク 例 関連情報
アプリに対する dyno の一覧表示 heroku ps​ スケーリング
Worker dyno を起動します(アプリに対して定義されている Worker プロセスタイプは Procfile で確認してください)。 heroku ps:scale worker=2​ スケーリング
特定の dyno タイプの停止 * heroku ps:stop worker​ スケーリング
特定の dyno の停止 * heroku ps:stop worker.2​ スケーリング
すべての dyno の再起動 heroku ps:restart​ Dyno Manager
特定の dyno タイプの再起動 heroku ps:restart web​ Dyno Manager
特定の dyno の再起動 heroku ps:restart web.1​ Dyno Manager
水平方向への拡張 (dyno の追加) heroku ps:scale web=2​ スケーリング
現在の dyno の数を増やすことによる水平方向への拡張 heroku ps:scale web+5​ スケーリング
異なる dyno タイプの水平方向の同時拡張 heroku ps:scale web=1 worker=5​ スケーリング
垂直方向への拡張 (より大きな dyno の使用) heroku ps:resize worker=standard-2x​ dyno タイプ
水平方向と垂直方向への同時拡張。この例では、Web dyno の数を3 つに拡張し、performance-l にサイズ変更します heroku ps:scale web=3:performance-l​ dyno タイプ
heroku ps コマンドのヘルプの取得 heroku ps --help​
コンソールで bash を実行する One-off dyno の起動 heroku run bash​ One-off dyno
アプリケーションの Procfile にある「Worker」プロセスタイプを実行する One-off dyno の起動 heroku run worker​ One-off dyno
ログの表示 heroku logs​ または heroku logs --tail​ ログ記録

*​ 拡張されたプロセスの一部である dyno で ps:stop​ を実行すると、dyno が自動的に再起動されます。Private Space では、dyno を実行している専用インスタンスが ps:stop​ によって終了し、置き換えられます。dyno を永続的に停止するには、プロセスをスケールダウンします。

アプリの一部の dyno の設定を、Heroku Dashboard​ で変更することもできます。

dyno のスリープ

スリープできるのは eco​ dyno のみです。詳細は、「Eco Dyno Hours​」(Eco dyno 時間) を参照してください。

起動

.profile ファイル

起動中、コンテナによって、dyno コマンドの実行前に、$HOME/.profile​ のあらゆるコードを実行する bash​ シェルが開始されます。このファイルに bash​ コードを入力して、アプリ内のあらゆる dyno タイプのランタイムの初期環境を制御します。

.profile​ スクリプトは、アプリの環境設定の後に​調達されます。環境設定が優先されるようにするには、以下で LANG​ で行われているのと同様のテクニックを使用します。

# add vendor binaries to the path
export PATH=$PATH:$HOME/vendor/bin


# set a default LANG if it does not exist in the environment
export LANG=${LANG:-en_US.UTF-8}

ほぼすべての目的について、環境設定​は .profile よりも便利で柔軟性があります。環境設定を編集するために新しいコードを入力する必要はありませんが、.profile​ はソースツリーの一部であり、すべてのコード変更と同様に編集およびデプロイする必要があります。

ローカル環境変数

Dyno Manager により、アプリケーション内でアクセスできる多数のデフォルト環境変数が設定されます。

  • dyno が Web dyno である場合は、$PORT​ 変数が設定されます。dyno が受信リクエストを受け取るには、このポート番号にバインドする必要があります。

$DYNO​ 変数値がアプリ内で一意である保証はありません。たとえば、デプロイ中または再起動中に、2 つの実行中の dyno に同じ dyno ID が使用されることがあります。ただし、最終的には整合が取れます。

  • $DYNO​ 変数は、web.1​、worker.2​、run.9157​ などの dyno ID に設定されます。

プロセス

.profile​ スクリプトが実行された後、dyno によって、dyno のプロセスタイプ​に関連付けられているコマンドが実行されます。たとえば、dyno が Web dyno の場合は、Web プロセスタイプに関連付けられている Procfile のコマンドが実行されます。

実行されるコマンドにより、追加のプロセスが発生する可能性があります。

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 以下であるため、上限に到達しています。

Web dyno

Web dyno は、起動から 60 秒以内に、割り当てられた $PORT​ にバインドする必要があります。バインドしない場合、Web dyno は Dyno Manager によって強制終了され、R10 (ブートタイムアウト)​ エラーがログに記録されます。プロセスは、$PORT​ にバインドする前とバインドした後、他のポートにバインドできます。

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

再起動

dyno の自動再起動

Dyno Manager により、以下の場合にアプリの dyno がすべて再起動されます。

また、Heroku で実行されているアプリケーションのヘルスを維持するために、dyno は最低一日一回は再起動されます。ローカルファイルシステムへの変更はすべて削除されます​。再起動は 24 時間ごとに行われます (同一アプリケーションのすべての dyno が同時に再起動するのを避けるため、追加で最大 216 分のランダムな間隔でも行われます)。手動での再起動 (heroku ps:restart​) およびリリース (デプロイまたは環境設定の変更) は、この 24 時間の周期でリセットされます。再起動は One-off dyno を含むすべての dyno で行われるため、dyno は最大で 24 時間 + 216 分間実行されます。複数の xyno がある場合、0 から 216 分の間でランダムに、異なるタイミングで再起動する必要があります。24 時間経過する前にアプリケーションに変更を行うと、再起動は行われません。dyno が再起動されると、以下のようなログエントリが表示されます。

2015-08-18T06:20:13+00:00 heroku[web.1]: Cycling

さらに、システムおよびアプリの全体的なヘルスに必要になったタイミングでも、dyno は再起動されます。たとえば、Dyno Manager が基礎となるハードウェアの障害を検出し、dyno を物理的に新しい場所に移動する必要が生じることがあります。このような処理は定期的に透過的かつ自動で行われ、アプリケーションログ​に記録されます。

dyno は、dyno の起動に使用されたコマンドが終了した場合にも再起動されます。dyno の起動に使用されるコマンドが終了するケースには、以下のようなものがあります。

  • 起動コードの欠陥 - アプリに不可欠の依存関係がない場合、または起動時のその他の問題がある場合は、コマンドがただちに終了し、スタックトレースが出力されます。
  • 起動時に使用されたリソースでの一時的なエラー - 起動時にアプリが何らかのリソースにアクセスし、そのリソースがオフラインの場合、コマンドが終了することがあります。たとえば、データベースとして Amazon RDS を使用し、Heroku アプリにセキュリティグループの ingress を作成しない場合、エラーが生成されるか、起動の試行がタイムアウトになります。
  • バイナリライブラリのセグメンテーション違反 - アプリでバイナリライブラリ (例: XML parser) が使用され、そのライブラリがクラッシュした場合、アプリケーション全体もクラッシュする可能性があります。例外処理はこれを捕捉できないため、プロセスが停止します。
  • インタープリターまたはコンパイラーのバグ - まれなケースとして、インタープリター (Ruby、Python) またはコンパイル (Java、Scala) のバグによってプロセスが停止することがあります。

dyno のクラッシュ再起動ポリシー

dyno の「クラッシュ」とは、dyno で実行中のプロセスから発生し、dyno が停止する原因となるすべてのイベントを指します。これには、0​ の終了コード (またはその他のあらゆる終了コード) で終了するプロセスが含まれます。

Common Runtime により、クラッシュする dyno についての増分バックオフポリシーが実装されます。

  • dyno が初めてクラッシュした場合、ただちに再起動されます。
  • dyno が再びクラッシュすると、再起動が試行される前に、クールオフの時間がもうけられます。
  • 最初のクールオフ時間は最大 20 分、次は最大 40 分、その後は最大 60 分、最大 180 分となり、最終的に最大 320 分となります。
  • 320 分のクールオフ時間に到達すると、再起動は 320 分おきに試行されます。
  • クールオフ時間は、dyno が正常に起動するか、アプリに新しいリリースをプッシュするか、(heroku restart​ と入力して) アプリを再起動するか、または dyno を 0 にスケールダウンしてから再びスケールアップするとリセットされます。

Private Spaces Runtime にはバックオフポリシーがありません。dyno がクラッシュした場合、クールオフ時間はなく、繰り返し再起動されます。

シャットダウン

SIGTERM によるグレースフルシャットダウン

Dyno Manager によって dyno が再起動されると、Dyno Manager は SIGTERM​ シグナルを送信してプロセスが緩やかにシャットダウンするようにリクエストします。このシグナルは、プロセスタイプだけではなく、dyno のすべてのプロセスに送信されます。

現在、シャットダウン中の dyno のプロセスが複数の SIGTERM を受信する可能性があることに注意してください。

アプリケーションプロセスがクリーンにシャットダウンするには 30 秒かかります (もっとすばやくシャットダウンするのが理想です)。シャットダウン中は、新しいリクエストやジョブは受け入れられず、現在のリクエストの終了が試行されたり、他の Worker プロセスが処理するようにジョブがキューに戻されたりします。この時間が経過した後もプロセスが残っている場合、Dyno Manager は SIGKILL​ で強制的にそれらのプロセスを終了します。

制御された再起動または定期的な再起動の実行中、シャットダウンシグナルが古い dyno のプロセスに送信されるとすぐに、新しい dyno がスピンアップされます。

これがどのように機能するかを、サンプル Worker プロセスを使用して、練習で確認できます。ここでは、説明用の言語として Ruby を使用します。メカニズムはその他の言語と同じです。ループが終わらず、定期的にメッセージが出力されるプロセスを想像してみてください。

STDOUT.sync = true
puts "Starting up"

trap('TERM') do
  puts "Graceful shutdown"
  exit
end

loop do
  puts "Pretending to do work"
  sleep 3
end

これ (適切な Gemfile​ および Procfile​ とともに)​) と heroku ps:scale worker=1​ をデプロイすると、dyno worker.1​ で実行中のループでプロセスを確認できます。

$ heroku logs
2011-05-31T23:31:16+00:00 heroku[worker.1]: Starting process with command: `bundle exec ruby worker.rb`
2011-05-31T23:31:17+00:00 heroku[worker.1]: State changed from starting to up
2011-05-31T23:31:17+00:00 app[worker.1]: Starting up
2011-05-31T23:31:17+00:00 app[worker.1]: Pretending to do work
2011-05-31T23:31:20+00:00 app[worker.1]: Pretending to do work
2011-05-31T23:31:23+00:00 app[worker.1]: Pretending to do work

dyno を再起動すると、dyno が SIGTERM​ を受けとります。

$ heroku restart worker.1
Restarting worker.1 process... done

$ heroku logs
2011-05-31T23:31:26+00:00 app[worker.1]: Pretending to do work
2011-05-31T23:31:28+00:00 heroku[worker.1]: State changed from up to starting
2011-05-31T23:31:29+00:00 heroku[worker.1]: Stopping all processes with SIGTERM
2011-05-31T23:31:29+00:00 app[worker.1]: Graceful shutdown
2011-05-31T23:31:29+00:00 heroku[worker.1]: Process exited

(コードから分かるとおり) app[worker.1]​ が「グレースフルシャットダウン」をログ記録します。すべての Dyno Manager メッセージは heroku[worker.1]​ としてログ記録します。

以下のように、TERM​ シグナルを無視するように worker.rb​ を変更した場合:

STDOUT.sync = true
puts "Starting up"

trap('TERM') do
  puts "Ignoring TERM signal - not a good idea"
end

loop do
  puts "Pretending to do work"
  sleep 3
end

動作が変更されているのが分かります。

$ heroku restart worker.1
Restarting worker.1 process... done

$ heroku logs
2011-05-31T23:40:57+00:00 heroku[worker.1]: Stopping all processes with SIGTERM
2011-05-31T23:40:57+00:00 app[worker.1]: Ignoring TERM signal - not a good idea
2011-05-31T23:40:58+00:00 app[worker.1]: Pretending to do work
2011-05-31T23:41:01+00:00 app[worker.1]: Pretending to do work
...
2011-05-31T23:41:25+00:00 app[worker.1]: Pretending to do work
2011-05-31T23:41:27+00:00 heroku[worker.1]: Error R12 (Exit timeout) -> Process failed to exit within 30 seconds of SIGTERM
2011-05-31T23:41:27+00:00 heroku[worker.1]: Stopping all processes with SIGKILL
2011-05-31T23:41:28+00:00 heroku[worker.1]: Process exited

プロセスによって SIGTERM​ が無視され、状況を把握しないまま処理が続行されます。30 秒後、Dyno Manager はプロセスが緩やかにシャットダウンするまで待機するのをあきらめ、SIGKILL​ で強制終了します。Error R12​ がログに記録されますが、これはプロセスが適切に操作していないことを示しています。

dyno ライフサイクルレイテンシー

Common Runtime 内の dyno は、制御応答性が最適化されています。One-off dyno プロセスの起動または Web プロセスや Worker プロセスのスケールアップにかかる時間は数秒です。

Private Space の dyno は、堅牢性とパフォーマンスが最適化されています。One-off dyno の起動または既存の Web formation や Worker formation への 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 に到達した場合。

使用する dyno タイプが小さすぎると、メモリスワップが繰り返され、アプリケーションのパフォーマンス低下につながります。メモリ使用率などのアプリケーション関連の指標​データは、Heroku Dashboard のMetrics​ (指標) タブにあります。ログのランタイム関連の指標でメモリを測定​することもできます。メモリ使用率の問題は、アプリのメモリリークが原因となる場合もあります。メモリリークが疑われる場合は、メモリプロファイリングツールが役に立ちます。

スワップは Provate Space の一部の dyno (例: Private-M) には使用できません。メモリ割り当てを大幅に超過した dyno は、R15 エラー​を発行しますが (ただしプラットフォームは場合により R15 エラーを削除することもあります)、スワップ領域を使用しません。代わりに、プラットフォームは、大量のメモリを消費しているプロセスを強制終了しますが、dyno 自体を強制終了しない場合があります。

少量のスワップ領域を使用し、メモリスワップが頻繁でない場合は、通常は問題になりません。アプリケーションがメモリ上限に達していない場合でも、オペレーティングシステムがメモリと利用可能なディスクキャッシュを管理しているため、少量のメモリがディスクにスワップされることは珍しくありません。

外部サービスへの接続

dyno 上で実行されているアプリケーションは、外部サービスに接続できます。Heroku では、アプリを複数の地域​で実行できるため、レイテンシーを最適にするには、アプリと同じ地域​でサービスを実行してください。

dyno およびリクエスト

1 つの dyno は 1 秒あたり数千のリクエストに対応できますが、パフォーマンスは使用する言語とフレームワークによって大きく異なります。

シングルスレッドの、非並列 Web フレームワーク (デフォルト設定の Rails 3 など) では、一度に 1 つのリクエストを処理できます。各リクエストの処理に平均で 100ms かかるアプリの場合、dyno あたり 1 秒に約 10 個のリクエストを処理することになり、最適ではありません。

シングルスレッドのバックエンドは、並列リクエストの処理が十分でないため、本番環境のアプリには推奨されません。本番環境のサービスを開発および実行する場合は、常に並列バックエンドを選択してください。

Java、Unicorn、EventMachine、Node.js などのマルチスレッドまたはイベント駆動型の環境では、多数の並列リクエストを処理できます。リクエストのスループットを特定する唯一の実際的な方法は、アプリの負荷テストです。