-
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をアイドルさせます。
この状態が発生した場合、以下のようなlogsを見ることになるでしょう。:
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がアイドルすることは決してありません。
If a dyno's resident process crashes, either during start-up or during regular operation, the dyno manifold will immediately attempt to restart the dyno. If it crashes again, it will be subject to a ten-minute cooldown period until it restarts. (You can always manually restart it with the heroku restart command.)
Applications with multiple running dynos will be more redundant against failure. If some dynos are lost, the application can continue to process requests while the missing dynos are replaced. Typically, lost dynos are replaced immediately, but in the case of a catastrophic failure, it can take some time.
Dynos execute in complete isolation from one another, even when on the same physical infrastructure. This includes both dynos in the process formation and dynos run as one-off admin processes with heroku run. This provides complete protection from other application processes, or even system-level processes, consuming all available resources and rednering your application un-manageable.
The dyno manifold uses a variety of technologies to enforce strict dyno isolation, most notably LXC for subvirtualized resource and process table isolation, independent filesystem namespaces, and the pivot_root syscall for filesystem isolation. These technologies ensure security and guarantee resources such as CPU and memory in Heroku's multi-tenant environment.
Each dyno gets its own ephemeral filesystem, with a fresh copy of the most recently deployed code. During the dyno's lifetime its running processes can use the filesystem as a temporary scratchpad, but no files that are written are visible to processes in any other dyno and any files written will be discarded the moment the dyno is stopped or restarted.
When running multiple dynos, apps are distributed across several nodes in the dyno manifold. Access and routing to individual dynos is always controlled by the routing mesh, and goes through Heroku's public IPs.
As a result, dynos don't have static IP addresses. While you can never access a dyno directly by IP, it is possible to originate outgoing requests directly from a dyno. However, do not count on the dyno's IP being static. We actively monitor our grid, and frequently move dynos around to ensure optimal reliability and performance.