erosion resistance

これまで、SaaS（Software-as-a-service）のアプリケーションは稼働し続けるために、アクティブな開発環境にあろうとなかろうと、常時メンテナスが必要となるトラディショナルなサーバーベース環境へディプロイされて来ました。一方で、Herokuのプラットフォームは、耐摩耗性（常時メンテナンス不要）です。

摩耗はアプリにとって問題

アプリケーションを構築し、どこかのサーバー上へ稼働用のセットアップを実施後、数ヶ月経過してから確認してみると、アプリケーションがダウンしていることに気付いたことがあるという方ならどなたでも、この摩耗の問題には慣れたものでしょう。エントロピー（無秩序）の力により、以下のような稼働中のアプリケーションが摩耗の影響を受けることとなります。:

• OSのアップグレード、kernelのパッチ、セキュリティに関する脆弱性を修正したインフラ用ソフトウェア（例：Apache, MySQL, ssh, OpenSSL）のアップデート
• ログファイルにより一杯になったサーバーのディスク
• 誰かがログインし、再起動する必要のある、クラッシュまたはスタックした1つ以上のプロセス
• 基礎となるハードウェアの故障で、1つ以上のサーバーがダウンする原因となり、アプリケーションもそれに引っ張られるような場合

このような影響度とエントロピー（無秩序）の力のようなものは、"bit rot"、または、"software erosion"として知られています。

Herokuは耐摩耗性

トラディショナルなサーバーベース環境とは対照的に、Herokuのプラットフォームは、耐摩耗性となるよう構築されています。

dyno manifoldが手動での介入無しに、アプリケーションのprocess formationを稼働し続けます。dyno manifoldはクラッシュしたプロセスを自動的に再起動させ、さらに基礎となるハードウェアの故障が発生した場合はいつでも、dynoを新たなロケーションへ自動的かつ即座に移動させます。

Herokuのオペレーションチームはセキュリティパッチを適用することで、基礎となるオペレーティングシステムのカーネル及び、その他コンポーネントを最新の状態に保っています。このことは、再起動が発生することを除き、稼働中のdynoに大きなインパクトを与えることなく処理されることを意味します。dynoの再起動は舞台裏で自動的に、かつひっそりと行われます。

HerokuのPostgreSQLサービス上で稼働しているデータベースは、十分に管理され、かつ監視されています。ハードウェアの故障はHerokuのPostgreSQLチームにより、完璧にハンドリングされており、アプリケーション所有者の介入を必要としません。