scaling

プロセスモデル（Procfileを経由する）を使用するアプリケーションは、コマンドライン、またはAPIから即座にスケールアップ・スケールダウンすることが可能です。それぞれのアプリケーションは、dyno manifold上で実行されている1組のプロセス群を所有しています。dyno manifoldは、プロセスを編成する機能として知られています。

スケーリング

dynoは時間に比例した決済が行われます。 そのため、色々な設定を試してみたい場合、試してみることは可能ですが、実際の使用時間により請求されることとなります。 覚えておいて下さい。正しい数のdynoとworkerをアプリケーションに割り当てるのは、あなた自身の責任です。

一般的に、webアプリケーションは、少なくともwebとworkerのプロセスタイプを使うことでしょう。それぞれのプロセスを実行するdynoの数を調整することで、どちらか一方の同時実行レベルを調整することが可能となります。ps:scaleコマンドを使用します。:

:::term
$ heroku ps:scale web=2
Scaling web processes... done, now running 2

もしくは、一度に両方設定することも可能です。:

:::term
$ heroku ps:scale web=2 worker=1
Scaling web processes... done, now running 2
Scaling worker processes... done, now running 1

dynoの量をスケールするには、実際の数を入力することでも可能ですし、現在のdynoの量からインクリメントすることも可能です。

:::term
$ heroku ps:scale web+2
Scaling web processes... done, now running 4

もし、特定のプロセスタイプを完全に停止したい場合は、シンプルに 0までスケールして下さい。:

:::term
$ heroku ps:scale worker=0
Scaling worker processes... done, now running 0

プロセスの編成

プロセスの編成という言葉は、ある期間におけるアプリケーションのプロセスのレイアウトを指しています。シンプルなアプリケーションのデフォルト編成は、単一のwebプロセスのみとなるでしょう。一方、より多くを要求するアプリケーションは、web、worker、clock等のプロセスタイプから構成されるでしょう。上記の例の場合、編成は初回時に2つのwebプロセスへと変更され、その後、2つのwebプロセスと1つのworkerへと変更されています。

scaleコマンドは、コマンドライン内で指定したプロセスタイプにのみ影響します。例えば、アプリケーションが既に2つのwebプロセスで構成されている状態で、`heroku ps:scale worker=2`を実行した場合、トータルで4つのプロセス（2つのwebプロセス、2つのworkerプロセス）を有する結果となります。

内省

プロセスの編成に対するいかなる変更は、ログ管理されます。:

:::term
$ heroku logs | grep Scale
2011-05-30T22:19:43+00:00 heroku[api]: Scale to web=2, worker=1 by [email protected]

ログには、プロセスの編成全体が含まれて出力されることに注意して下さい。scaleコマンドで指定したプロセスだけが出力されるわけではありません。

現在のプロセスの編成を確認するには、psコマンドにて常時参照可能となります。:

:::term
$ heroku ps
=== web: `bundle exec thin start -p $PORT -e production`
web.1: up for 8h
web.2: up for 3m

=== worker: `bundle exec stalk worker.rb`

並列処理の理解

clock/schedulerのプロセス、または、TwitterのストリーミングAPIを実行するプロセスと言った単体のプロセスタイプは、決して単一プロセス以上のスケールをすべきではありません。なぜなら並列処理を追加したところで、それによる恩恵を受けませんし、お互いが同じ処理を実行しようとし、重複したレコードやイベントを作成してしまうことになるからです。

一定のプロセスタイプをスケールアップすることは、このプロセスタイプがハンドルするworkがより多くの並列処理を行えるようにします。例えば、より多くのweb dynoを追加した場合、より多くの並列HTTPリクエストをハンドル出来るようになり、結果として、トラフィック量が上がります。また、より多くのworker dynoを追加した場合、より多くのジョブを並列処理することが可能となり、結果として、処理するジョブの量が増えます。

web、worker、その他のプロセスタイプを実行するために、より多くのdynoを追加することが救いとならない環境があります。よくあるのが、バッキングサービスにボトルネックがある場合です。一般的に、データベースがボトルネックとなります。仮にデータベースがボトルネックである場合、より多くのdynoを追加することで、明らかに事態が悪化することでしょう。代わりに、データベースクエリの最適化、より大きなデータベースへのアップグレード、データベースへの負荷を減らすためにキャッシュを使用する、共有または読み取り専用スレーブのデータベース設定へ切替を行う等を試してみて下さい。

並列処理を増やしたところで救いとならない別の環境として、長時間のリクエストまたはジョブの場合が考えられます。例えば、30秒を要するデータベースクエリで作成されるレポートと言った低速なHTTPリクエスト、またはニューズレターを2万人の購読者へメールするようなジョブ等です。並列処理は水平スケールを提供します。このことは、細分化可能なwork（大規模、一体構造なworkではなく）に最適であることを意味しています。

低速なレポートへの解決策として、レポートの計算を backgroundへ移動させることです。そして、直近の出力のmemcacheの結果をキャッシュすることです。長時間のジョブには、workを細分化することが答えです。2万ジョブ（それぞれのニューズレターが1通ずつ送信される）をキューに配置することで、扇形に展開される単一ジョブをクリエートして下さい。単一ワーカーは、これらのジョブを順に実行することが可能です。または、これらのジョブをより高速に実行するために、複数ワーカーへスケールアップすることも可能です。より多くのワーカーを追加すればするほど、より高速に全体のバッチ処理が完了することでしょう。