Dyno formation のスケーリング
この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。
最終更新日 2025年04月14日(月)
Table of Contents
この記事では、フォーメーション内の dyno サイズまたは dyno の数を変更して、アプリを手動でスケーリングする手順について説明します。一部の dyno 層ではオートスケールも利用できます。
アプリで実行するのに適切な dyno のサイズと数を見つける方法については、「dyno の選択に関するガイダンス」と「アプリケーションの負荷テスト」を参照してください。
dyno の数を変更する
プロセスタイプを水平方向にスケーリングすると、そのプロセスタイプが処理する作業の並列性が強化されます。たとえば、web dynos をさらに追加すると、より多くの並列 HTTP リクエストを処理できます。worker dynos をさらに追加すると、より多くのジョブを並行して処理できます。
dyno タイプごとに実行できる dyno の最大数については、「dyno のスケーリングとプロセスの制限」を参照してください。
Heroku Dashboard を使用する場合
1 つのプロセスタイプで複数の Eco dyno または Basic dyno を実行することはできません。dyno を追加する前に、まずより大きな dyno にアップグレードしてください。
- Heroku Dashboard からアプリを選択します。
Resources(リソース) タブに移動します。- プロセスタイプの横にある編集アイコンをクリックします (例:
web)。 - スライダーを移動するか、必要な dyno の数を手動で入力します。
Confirm(確認) をクリックします。
Heroku CLI を使用する場合
dyno の数を変更するには、heroku ps:scale を使用します。たとえば、heroku ps:scale web=3 とします。
複数のプロセスの dyno の数を同時に変更することもできます。たとえば、heroku ps:scale web=1 worker=5 とします。
プロセスの dyno サイズと dyno の数を同時に変更するには、heroku ps:scale を使用します。たとえば、heroku ps:scale web=3:performance-l とします。
Heroku API を使用する場合
Dyno formation の dyno サイズまたは dyno の数を変更するには、Heroku Platform API のフォーメーションエンドポイントを参照してください。
オートスケール
Heroku は、Performance 層、Private 層、Shield 層の dyno に対してオートスケールを提供しています。この機能がユーザーのニーズを満たさない場合は、Elements Marketplace にあるサードパーティ製のアドオンを検討してください。
dyno サイズを変更する
dyno サイズを変更して垂直方向に拡張し、各 dyno で利用可能なリソースを変更します。適切なサイズを選択するためのガイダンスについては、「dyno の選択に関するガイダンス」を参照してください。
Heroku Dashboard を使用する場合
Common Runtime Apps
- Heroku Dashboard からアプリを選択します。
Resources(リソース) タブに移動します。- dyno の一覧の上にある
Change Dyno Type(dyno タイプの変更) をクリックします。 - 目的の dyno 層をクリックします。
Save(保存) をクリックします。- リストされたプロセスの横にあるアイコンをクリックすると、dyno サイズのドロップダウンメニューが開きます。
- サイズを選択します。Eco 層と Basic 層にあるサイズは 1 つのみです。
Private Space アプリ
- Heroku Dashboard からアプリを選択します。
Resources(リソース) タブに移動します。- リストされたプロセスの横にあるアイコンをクリックすると、dyno サイズのドロップダウンメニューが開きます。
- サイズを選択します。
Heroku CLI を使用する場合
プロセスの dyno サイズを変更するには、heroku ps:type を使用します。たとえば、heroku ps:type worker=standard-2x とします。
プロセスの dyno サイズと dyno の数を同時に変更するには、heroku ps:scale を使用します。たとえば、heroku ps:scale web=3:performance-l とします。
Heroku API を使用する場合
Dyno formation の dyno サイズまたは dyno の数を変更するには、Heroku Platform API のフォーメーションエンドポイントを参照してください。アプリで使用できる dyno タイプのリストを検索するには、dyno サイズエンドポイントに問い合わせてください。
考慮事項
リリース
Fir 世代のアプリケーションが新しいリリースに応じて再起動すると、一時的に dyno の数が設定されたスケールを超過することがあります。この動作はアプリケーションの可用性の低下を防ぐために行われます。新しい dyno が作成され、準備完了が確認されてから、古いリリースを実行している dyno が終了します。
最新リリースによって正常に起動できない dyno は、以前のリリースで稼働している dyno と並行して引き続き存在します。この場合、最新の dyno が正常に稼働するまで、dyno の数が設定されたスケールを超えます。
スケーリングの制限
dyno サイズごとに実行できる dyno の最大数については、「dyno のスケーリングとプロセスの制限」を参照してください。
dynos 層の混在
eco 層または basic 層のアプリでは、さまざまな dyno タイプを混在させることはできません。これらの層のアプリでは、すべてのプロセスで同じタイプの dyno のみを使用する必要があります。
その他の dyno プランについては、特定のランタイム層にスコープされた任意の dyno を混在させることができます。ただし、異なるランタイム間で dyno を混在させることはできません。
次のような例があります。
- Common Runtime のアプリは
performance-mweb プロセスとstandard-1x ワーカーを使用できます。 - Private Space のアプリは
private-lweb プロセスとprivate-mworker プロセスを使用できます。 - Shield Space のアプリは
shield-lweb プロセスとshield-mworker プロセスを使用できます。 - Fir Space のアプリは
dyno-1c-1gbweb プロセスとdyno-2c-4gbworker プロセスを使用できます。
dyno を追加しない場合
シングルトンプロセス
clock/scheduler などのシングルトンプロセスタイプは、1 つの dyno を超えてスケールしないでください。これらのプロセスタイプには追加の並列性によるメリットがなく、レコードやイベントが重複して作成されることがあります。
バッキングサービスのボトルネック
場合によっては、ボトルネックによってアプリのパフォーマンスが制限されることがあります。このボトルネックは、バッキングサービス (特にデータベース) から発生する可能性があります。このような場合、dyno を追加すると問題がさらに悪化する可能性があります。まずボトルネックの問題を解決してください。たとえば、データベースの場合は、次のような対策を検討できます。
- データベースクエリを最適化する
- より大きなデータベースにアップグレードする
- キャッシングを実装してデータベースの負荷を減らす
- 共有設定に切り替えるか、スケーリングでフォロワーを使用して読み込む
実行時間の長いジョブ
データベースクエリに 30 秒かかるレポートや、20,000 人の購読者にニュースレターを送信するジョブなど、大規模でモノリシックな HTTP リクエストには、dyno を追加しても効果がありません。まず作業を分割し、ジョブを並行して実行できるようにしてから dyno の追加を検討してください。詳細は、「Worker dyno、バックグラウンドジョブ、キューイング」を参照してください。
スレッドとリクエスト
1 つの dyno は 1 秒あたり数千のリクエストに対応できますが、パフォーマンスは使用する言語とフレームワークによって大きく異なります。 シングルスレッドで非並列の Web フレームワーク (Rails 3 のデフォルト設定など) は、一度に 1 つのリクエストしか処理できません。各リクエストの処理に平均で 100 ミリ秒かかるアプリの場合、dyno あたり 1 秒に約 10 個のリクエストを処理することになり、最適ではありません。
また、並列リクエストの処理効率が悪いため、シングルスレッドのバックエンドは本番環境のアプリには推奨されません。本番環境のサービスを開発および実行する場合は、常に並列バックエンドを選択してください。 Java、Unicorn、EventMachine、Node.js などのマルチスレッドまたはイベント駆動型の環境では、多数の並列リクエストを処理できます。リクエストのスループットを特定する唯一の実際的な方法は、アプリの負荷テストです。