
インフラストラクチャ定義のパターン
147
9
章
イ ン フ ラ スト ラ ク チ ャ 定 義 の パ タ ー ン
本書第Ⅱ部の大半は、個別のサーバーのプロビジョニングと構成/ 設定に注目してきた。この章で
は、インフラストラクチャ要素のもっと大きなグループのプロビジョニングと構成 / 設定の方法を見て
みたい。インフラの規模、複雑度、ユーザー数が拡大していくと、Infrastructure as Code のメリット
を実現することが難しくなっていくのである。
●
特定の変更が影響を及ぼす範囲が広がっていくと、すばやく安全な変更をひんぱんに行うことが
難しくなる。
●
チームメンバーが日常的なメンテナンスや障害対策のために費やす時間が長くなると、サービス
に価値のある改良を加えるための時間が足りなくなる。
●
ユーザーにそれぞれのリソースのプロビジョニングと管理を任せると、ほかのユーザーやサービ
スに重大な影響を及ぼす危険が生まれる。
このような問題が起きると、一般にインフラに対する中央集権的な統制を強化する方向に向かうこと
が多い。しかし、それでは会議、ドキュメント、変更プロセスにかける時間が増えていき、会社のため
に価値を生むような活動に使える時間がさらに短くなる。
中央集権的な統制に代わるべきものは、変更が影響を与える範囲を最小限に抑えるようなインフラ
設計である。インフラの定義、プロビジョニング、管理のアプローチを効果的なものにできれば、イン
フラの規模が拡大しても、自信を持ってひんぱんに変更を加えられ ...