-
Notifications
You must be signed in to change notification settings - Fork 9
dynos
Herokuの構造における基本単位であるdynoとは、ユーザーが指定した単一コマンドを実行する軽量のコンテナのことです。 dynoは、バーチャル化されたUnixのコンテナと考えることも出来ます。---そのコンテナにおける初期環境があれば、 意味をなす全てのコマンドを実行することが出来ます（我々はCedar stackで、それを提供しています）。 またslug（実装したコードとランタイム言語のベースとなる）においても同様です。
コマンドは、webプロセス、ワーカープロセス（定時のジョブと待ち行列システムのような）、そしてアプリのProcfile内で 宣言されたいかなるプロセスタイプを含むdynoの範囲内で実行されます。 一度限りのアドミニプロセスも、同様にdynoの範囲内で実行されます。
-
柔軟性とスケール: アプリに割り当てられたdynoは、いついかなる時でも、増やすこと、減らすことが可能です。 より詳しく知りたい場合は、dynoのスケーリングを読んで下さい。
-
賢いルーティング: routing meshは、webプロセス(web dynos)を実行する全てのdynoの場所を追跡し、 それに応じて、HTTPのトラフィックをルーティングします。
-
プロセスの管理: 常駐プロセスは、レスポンスをモニターされます。おかしな動きをしているプロセスのdynoは取り払われ、 新たなdynoがローンチされます。
-
ディストリビューションと冗長性: dynoは、dyno manifoldとして知られている柔軟な実行環境にディストリビュートされます。 2つのweb dynoを設定したアプリでは、2つのwebプロセスをホストすると期待するかもしれませんが、それぞれのプロセスは、 物理的に異なるロケーションで実行されています。基礎的なインフラが、あなたのサイトを正常動作させることに失敗した場合でも、 たった2つのdynoを設定しておくことで、どちらかのdynoが同等の処理を行うため、冗長化を行えます。
-
分離: 各dynoは、セキュリティ、リソースの保証、全体的な堅牢性といった多くの恩恵を受けたバーチャル化された コンテナ内で、完全に分離されています。
オペレートするために各dynoへ512MBのメモリーが割り当てられています。多くのアプリケーションがこのサイズで快適にフィットする でしょう。ですので、開発者としてメモリーのことを心配する必要は全くありません。
いくつかのケースでは、dynoの常駐プロセスが、512MBに達する、もしくは超過するかもしれません。原因として典型的なのが、 アプリケーション内のメモリリークです。 このようなケースの場合、メモリのプロファイリングとして、Rubyであれば、Oink、 Pythonであれば、Heapyのようなツールを 原因の追求・フィックスするために使いたいと思うことでしょう。
512MBのメモリ使用を越えたプロセスを有するdynoは、ログ内で、R14のエラーとして認識されます。 このエラーは、プロセスを終わらせるようなことはしませんが、512MB以上使われるメモリが、実質的にdynoのパフォーマンスを 劣化させるスワップへと移送され、悪化したアプリケーションの状態であることを警告します。
もし、メモリの使用サイズが割当量の3倍(512MB x 3 = 1.5GB)に達するまで増大し続けたら、 dyno manifoldは、R15のエラーを返し、dynoを再起動させるでしょう。
dyno manifoldとは、分散型で、フォールトトレラントで、かつ水平にスケール可能な実行環境を あたなのアプリケーションのdynoへ提供するもののことです。 dyno manifoldは、プロセスモデルを経由し、完全に無干渉かつメンテナンスフリーな流儀で ほぼ無限に広がるプログラムの数と多様性を管理します。
新たなコードをディプロイしたり、設定変数を変更したり、もしくはアドオンを変更したり
することで、新たなリリース版をクリエートした時はいつでも、dyno manifoldが、アプリの全dynoを再起動させます。
1つのターミナル内でコードをプッシュ中、または設定変数を変更中に、別のターミナル内で、watch heroku psコマンドを実行することで、
この再起動が起こるのをリアルタイムに確認することが出来ます。
dynoは少なくとも一日一回、または、dyno manifoldが基礎となるハードウェアに障害を見つけ、 dynoを物理的に新たなロケーションへ移す必要が発生した時はいつでも、循環が行われます。 これらの動作は両方とも、定期的に、目に見えない形で自動的に行われ、アプリケーションログへ追記されます。
もしあなたのアプリが、たった1つのweb dynoを実行しているのであれば、 ワーカーのdynoの数に関わらず、アイドルすることになるでしょう。アイドリングを防ぐには、2つ以上の**web** dynoが必要となります。
web dyno (webプロセスタイプを実行するdynoのこと)の数をスケールする
アプリが、たった1つのweb dynoを実行している場合、アクティブでない時間が1時間を越えるとweb dynoをアイドルさせます。
この状態が発生した場合、以下のようなログを見ることになるでしょう。:
2011-05-30T19:11:09+00:00 heroku[web.1]: Idling
2011-05-30T19:11:17+00:00 heroku[web.1]: Stopping process with SIGTERM
ブラウザからアプリへアクセスしたり、それ以外の方法でHTTPリクエストを送信することで、routing meshは、
dyno manifoldへシグナルを送り、webプロセスタイプを実行するよう、dynoをアイドル状態から解放（"目を覚まさせる"）します。:
2011-05-30T22:17:43+00:00 heroku[web.1]: Unidling
2011-05-30T22:17:43+00:00 heroku[web.1]: State changed from created to starting
このことが初回のリクエスト時に数秒の遅延を発生させます。連続するリクエストは通常通りのパフォーマンスを保証するでしょう。
2つ以上のweb dynoが実行されているアプリであれば、アイドルすることは決してありません。 ワーカーのdynoがアイドルすることは決してありません。
もし、スタートアップ時、通常オペレーション時のいずれにおいて、dynoの常駐プロセスがクラッシュした場合、
dyno manifoldは即時、dynoをリスタートしようと試みます。もし、再度クラッシュした場合、リスタートするまで
10分間、クールダウンの期間に入ります。（heroku restartコマンドで、いつでも手動のリスタートが可能です。）
複数のdynoが実行されるアプリケーションは、障害に対して冗長性を高めます。もし仮に、アプリケーションが、 いくつかのdynoを喪失しても、喪失したdynoを置き換えながら、リクエストを処理し続けます。 通常は、喪失したdynoの置き換えは即時行われますが、致命的な障害の場合、多少時間を要します。
dynoは、互いに完全に分離した状態で実行されます。たとえ物理的に同一のインフラに存在したとしてもです。
このことは、プロセスの構成におけるdynoと
heroku runコマンドで実行される一度限りのアドミニプロセスにおけるdynoの両方が含まれることを意味します。
また、このことは、全ての利用可能なリソースを食いつぶし、あなたのアプリケーションへ処理不能を返すような
その他アプリケーションのプロセスから完全に保護されることも意味します。
システムレベルのプロセスからさえも保護されます。
dyno manifoldは、厳重なdynoの分離を強制するために、様々なテクノロジーを駆使しています。最も顕著なものとして、
バーチャル環境のリソースとプロセステーブルの分離のために使うLXC、
独立したファイルシステムのネームスペース、ファイルシステム分離のためのpivot_rootシステムコールがあります。
これらのテクノロジーは、セキュリティを確保し、Herokuのマルチテナントな環境におけるCPUとメモリと言ったリソースの確保を保証します。
それぞれのdynoは、最も最近ディプロイされたコードのフレッシュコピーだけの、短命なファイルシステム管理となります。 dynoの生存期間中、実行プロセスはファイルシステムを一時的なメモ帳として使います。 但し、書き込まれたファイルは、他のdynoにおけるプロセスには見えることがありません。 書き込まれたファイルは、dynoが停止、または再起動するとすぐに破棄されます。
複数のdynoを実行する場合、アプリはdyno manifoldにおけるいくつかのノードを経由してディストリビュートされます。 それぞれのdynoへのアクセスとルーティングは、常にrouting meshによりコントロールされ、 Herokuのpublic IPsを通過します。
結果として、dynoは静的なIPアドレスを持つことはありません。IPを使ってdynoへ直接アクセスすることは出来ませんが、 dynoから直に出力のリクエストを創出することは可能です。しかしながら、静的になっているdynoのIPに頼らないで下さい。 我々は積極的にグリッドをモニターしており、最も好ましい信頼性とパフォーマンスを確保するために、しばしばdynoの配置換えをしています。