Heroku でアプリのデプロイやスケールが行われると、そのアプリに該当するスタックとスラッグが読み込まれた dyno が 1 つまたは複数作成されます。その後、Heroku の Dyno Manager が設定ファイルで指定されているコマンドを実行し、Heroku 上でアプリの実行を開始します。Heroku では、さまざまな dyno タイプと dyno の設定から適切なものを選択して「dyno フォーメーション」を作成することによりアプリのランタイムリソースを微調整できます。
Dyno の設定
最先端のアプリは相互にデータをやり取りするコンポーネントで構成されています。たとえば一般的な Web アプリには、Web トラフィックを処理する Web コンポーネント、キュー（Heroku では通常、アドオンとして提供）のほか、キューから要素を取り出して処理する 1 つ以上のワーカーなどがあります。Heroku では特定の「プロセスタイプ」の dyno を使用して dyno フォーメーションを構成することにより、このようなアーキテクチャを簡単に作成できます。
プロセスタイプ
Heroku アプリでは、「Procfile」と呼ばれる設定ファイルを 1 つだけ使用してアプリの実行に必要なプロセスタイプを指定します。各プロセスタイプは、dyno を起動するときに Dyno Manager が実行するコマンドに相当します。主なプロセスタイプには次の 3 種類があります。
- Web dyno：ルーターから HTTP トラフィックを受信し、通常は Web サーバーを実行します。
- Worker dyno：バックグラウンドジョブ、キューイングシステム、時間指定のあるジョブなど、その他すべてのタスクを実行します。
- One-off dyno：dyno フォーメーションには含まれない一時的な dyno です。この種類の dyno は一時的なコマンド（ローカル端末のコマンドのこともあります）を実行するものであり、一般的には管理タスクの処理（REPL シェルを実行してデータベースの移行や一時的なバックグラウンド作業を行う場合など）に使用します。
各プロセスタイプは、そのプロセスを実行する dyno の数を増やすスケールアウトと、dyno ごとのサイズやパフォーマンスを増やすスケールアップのどちらにも対応しています。新しいバージョンのアプリをデプロイすると現在実行されている dyno が新しい dyno に置き換えられますが、既存の dyno フォーメーションは維持されます。
アプリで実行できる dyno の数に制限はなく、その設定もほぼ自由です。各 dyno の違いは最初に実行するコマンドだけで、使用するスタックとスラッグはどの dyno も同じです。たとえば、最初に実行するコマンドがそれぞれ異なる worker dyno を複数用意すれば、アプリで dyno ごとに異なるタスクを実行できます。各プロセスタイプは必要に応じて個別にスケールすることができます。
Conifer 社では worker dyno と Heroku の強力なバックグラウンド処理機能を活用し、メディアファイルを効率的に分割してお客様に最適なコンテンツを提供しています。
LaunchPad Lab 様事例→
Dyno タイプ
Heroku にはさまざまなタイプの dyno があり、その特徴、機能、価格設定はタイプごとに異なります。アプリに最適なパフォーマンスを実現するうえで必要とされるリソースに最も適した dyno タイプをご利用ください。
「共通ランタイム」と呼ばれるマルチテナント型の dyno ランタイムでは、次の dyno タイプを利用できます。
- Eco dyno：アイディアの実験や断続的に利用されるアプリに最適です。各月の dyno 時間が含まれます。web dyno または worker dyno を 1 つ実行できます。これらの dyno は 30 分間何も操作がないと、（残りの無料 dyno 時間を節約するために）スリープ状態に移行します。
- Basic dyno：小規模なプロジェクトにぴったりです。このタイプの dyno はスリープ状態に移行しません。各アプリには最大 10 個のプロセスタイプを設定でき、プロセスタイプごとに Basic dyno が 1 つずつ実行されます。スケールアウトが必要になるプロ用途のプロジェクトを運用する場合は、Standard dyno 以上のレベルの dyno を使用することをお勧めします。
- Standard dyno（1x または 2x）：スケールアウトが容易で、可視性、パフォーマンス、可用性が高く、プロ仕様のアプリを運用する場合に最適な dyno です。
以下の dyno タイプはシングルテナント型の dyno です。
- Performance dyno（M-2XL）：共通ランタイムで運用する大規模かつ高トラフィックのアプリ向けに、ここぞという場面で優れたパフォーマンスを発揮します。
- Private dyno（S-2XL）：Heroku Enterprise 内の Heroku Private Spaces ランタイムでのみ利用できます。Private Spacesで dyno がどのように機能するかについては、リンク先のページをご覧ください。
Heroku では Linux のコンテナ化機能により、タイプを問わずあらゆる dyno の隔離状態と安全性が確保されます。
Heroku アドオンと dyno
Heroku には、アプリの開発と運用をあらゆる側面からサポートするアドオンサービスが多数用意された強力なエコシステムが存在します。ジョブにスケジュールを設定して実行する Heroku Scheduler や、dyno 時間の節約に役立つ Process Scheduler など、広範にわたる Heroku アドオンが dyno の運用を強力にサポートします。dyno の間ではファイルの状態が共有されないため、アプリの中で dyno が相互に通信するには多くの場合、何らかのストレージメカニズムが必要になります。このため、多くの Heroku アプリでは Heroku Redis、Heroku Postgres、Apache Kafka on Heroku などのアドオンがキューの補助的メカニズムとして採用されています。
-
当社の事業はスケーラビリティに関する要件が非常に厳しいですが、Heroku PX の dyno で対応することができました。シード資金と 2 名のエンジニアだけのスタートアップですが、ある日の午後に突然、訪問者が 0 人から 50 万人に急増したような場合でも、パフォーマンスを良好な状態に保ったままトラフィックを処理できます。Heroku に処理を任せられるので、夜もよく眠れます。
Quikly 様事例→