Dynoサイズ

フォーメーション内の各プロセス（web、workerなど）はdyno上で動作します。dynoとは、アプリケーションの分離されたコンテナ化インスタンスです。dynoには複数のサイズがあり、それぞれメモリ、CPU、価格が異なります。プロセスタイプごとに適切なサイズを選ぶことは、コスト管理とパフォーマンスチューニングの両面で重要です（スケーリングとパフォーマンスを参照）。

Common Runtimeのサイズ

これらのサイズは共有のCommon Runtime上で動作するため、他のアプリのdynoとホストを共有することになります。コンテナによって分離されてはいますが、特に記載がない限りハードウェアを専有するわけではありません。

サイズ	メモリ	CPUシェア	専有	コンピュート	Dynoユニット
eco	512 MB	1x	いいえ	1x	1
basic	512 MB	1x	いいえ	2x	0.28
standard-1x	512 MB	1x	いいえ	4x	1
standard-2x	1 GB	2x	いいえ	8x	2
performance-m	2.5 GB	100%	はい	12x	8
performance-l	14 GB	100%	はい	50x	16
performance-l-ram	30 GB	100%	はい	24x	16
performance-xl	62 GB	100%	はい	50x	30
performance-2xl	126 GB	100%	はい	100x	60

Dynoユニットは、各サイズの相対的なコストを表します。dynoは稼働している1時間ごとにユニット数分を消費し、常時稼働させた場合は1か月あたり730時間分になります。ゼロにスケールされたプロセスタイプは消費しません。

dynoサイズの設定

プロセスタイプのサイズは、ps:scale を使ってスケールと同時に設定します。

$ bld ps:scale web=2:standard-2x worker=1:standard-1x -a my-app

TYPE=QUANTITY:SIZE という構文で、複数のプロセスタイプの数とサイズを1つのコマンドで設定できます。サイズを省略した場合は、現在のサイズがそのまま維持されます。

dyno数を変えずにサイズだけを変更するには、現在の数と新しいサイズを合わせて指定します。

$ bld ps:scale web=2:performance-m -a my-app

現在のサイズの確認

実行中のプロセスをサイズとともに一覧表示します。

$ bld ps -a my-app -j | jq '.[] | {type, state, size}'

または、アプリの詳細情報を見れば、フォーメーション全体（ゼロにスケールされたプロセスタイプを含む）を確認できます。

$ bld apps:info -a my-app -j | jq '.formation'

サイズの選び方

• 新しいアプリはまず standard-1x から始めるとよいでしょう。手頃な価格で、CPUシェアも十分です。
• レビューアプリや、トラフィックの少ないステージング環境、パフォーマンスよりコストを重視する簡単な検証などには eco または basic を使用します。
• メモリ制限の超過によりdynoが再起動される場合や、dyno数は十分にもかかわらず負荷時のレスポンスタイムが長い場合は、standard-2x または performance-* サイズへの変更を検討してください（垂直スケーリングを参照）。
• メモリを多く消費するもののCPUバウンドではないワークロードには、performance-l ではなく performance-l-ram を選びましょう。RAM容量が大きい分、コンピュートは控えめです。