Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

10

1

章 課題と原則

オートメーションツー ル の

外で変更を加えている

オートメーションツー ル を

実行すると、何かが壊れな

いか心配だ

サーバーに統一性がない

怖い！

図 1-1　オートメーション恐怖症の悪循環

本書第Ⅲ部で説明するように、優れたモニタリングと効果的な自動テストの体制が確立すれば、構

成/ 設定が確実に適用され、問題があればすぐにキャッチできるという自信が生まれる。

1.3.6

　

システム疲労

理想的には、新しい何かをサポートするとか、壊れている部分を修正するといった理由以外で構

築した自動化インフラストラクチャに手を触れる必要はないはずだ。しかし、この世界にはエントロ

ピー増大の法則というものがあり、新しい要件がなくても、インフラは時間の経過とともに壊れてい

く。Herokuの人々はこれをシステム疲労（Erosion、https://devcenter.heroku.com/articles/erosion-

resistance）と呼んだ。システム疲労とは、時間の経過とともに実行中のシステムに問題が忍び込むこと

である。

Herokuの人々は、時間の経過とともにシステム疲労を起こす力の例を挙げている。

●

オペレーティングシステムのアップグレード、カーネルパッチ、インフラソフト（たとえば、

Apache、MySQL、SSH、OpenSSL）のセキュリティ脆弱性を修正するためのアップデート。

●

ログファイルの成長によるサーバーディスクの残容量の消滅。

●

アプリケーションプロセスのクラッシュ、無 ...