耐崩壊性
最終更新日 2024年10月16日(水)
Table of Contents
従来型のサーバーベースの環境にデプロイされた Software-as-a-service アプリは、アプリが開発中かどうかに関係なく、実行し続けるために継続的なメンテナンスが必要です。 Heroku プラットフォームには、耐崩壊性があります。
崩壊はアプリにとって問題です
アプリケーションを構築している人は誰でも、いずれかの場所にあるサーバーで稼働するようにアプリケーションを設定し、数か月後に、この問題には停止がつきものであることに気が付きます。 稼働中のすべてのアプリケーションに影響するエントロピーの力には、次のようなものがあります。
- セキュリティ上の脆弱性を修正するためのオペレーティングシステムのアップグレード、カーネルのパッチ、インフラストラクチャソフトウェア (Apache、MySQL、ssh、OpenSSL など) のアップデート。
- サーバーのディスクがログファイルで満杯になる。
- 1 つ以上のアプリのプロセスがクラッシュまたはスタックし、誰かがログインして再起動する必要がある。
- 基盤ハードウェアの障害によって、1 台以上のサーバー全体が停止し、それに伴いアプリケーションも停止する。
上記の例をはじめ、同様の力による影響は「ビット崩壊」や「ソフトウェア崩壊」としても知られています。
Heroku には耐崩壊性があります
従来型のサーバーベースの環境とは異なり、Heroku プラットフォームは耐崩壊性を実現するように構築されています。
Dyno Manager により、アプリの Dyno formation は人手を介さずに稼働し続けます。 クラッシュした dyno は自動的に再起動され、基盤ハードウェアで障害が発生したときにはいつでも、すぐに dyno が自動的に新しい場所に移動されます。
Heroku の運用チームにより、基盤オペレーティングシステムのカーネルやその他のコンポーネントには最新のセキュリティパッチが適用され、常に最新の状態が維持されます。 この作業は、再起動以外は稼働中の dyno に影響を及ぼさずに行われます。再起動は、自動かつ無音で、背後で行われます。
Heroku の PostgreSQL サービスが稼働しているデータベースは、完全にマネージドで、監視されています。 ハードウェア障害には Heroku PostgreSQL チームが完全に対応するため、アプリの所有者が介入する必要はありません。
耐性があるということは、排除ではありません
Heroku の耐崩壊性は、アプリが永久に実行されるという意味ではありません。技術革新の力により、アプリを安全かつ安定した方法で実行し続ける必要がある場合は、最終的にお客様による手動での作業が必要となります。手動での作業が必要になる主な変更要因は、次の 2 つです。
ソフトウェアスタックのライフサイクル
アプリが稼働するソフトウェアスタックには、独自のライフサイクルがあります。基盤オペレーティングシステムや言語バイナリは、通常、限られた期間のみ、それぞれの運営組織によってサポートされます。
たとえば、言語のバージョンが運営組織によって非推奨になると、通常、それ以降のセキュリティパッチは受けられなくなります。 アプリケーションを新しいバージョンのコンポーネントに移行して、安全性と安定性を維持する必要があります。
Heroku では、サポートされているスタックと言語のビルドパックのソフトウェアライフサイクルを追跡しており、変更を行う必要がある場合は、事前にお知らせします。可能な限り最適な移行オプションをご利用いただけるようにします。
Heroku のサービス変更
Heroku の独自サービスは、定期的に進化しています。Heroku は、時々、時間の経過と共に古いサービスを置き換える新しいサービスを導入します。場合によっては、アプリケーションを古いサービスから新しいサービスに移動するために、お客様による作業が必要になることがあります。そのような変更を行う場合は、時間的な余裕を持って事前にお客様にお知らせし、できるだけシームレスに移行を行えるように最善を尽くします。