
9.2
インフラストラクチャの構造化
163
機能や定義の共有が意味を持つのは、原則として、要件が本当に共通しており、変更がひんぱん
に発生せず、変更のリスクが低いときである。また、チームが共有機能を簡単かつ明確にカスタマイ
ズ、オーバーライドする方法があるときにも意味がある。
たとえば、オペレーティングシステムのベースディストリビューションはかなり簡単に共有できるこ
とが多い。そこで、ベースOSが含まれたサーバーテンプレートを中央で作り、チームに配布する。
チームは、ベーステンプレートに変更を加える階層を重ねた新しいテンプレートを作るか(「7.6.1 パ
ターン:階層化テンプレート」参照)、新しいサーバーインスタンスをプロビジョニングするときにベー
スイメージに変更を加えるサーバー構成定義(Chef、Puppetなど)を書いてベースをカスタマイズす
る。
チームがまったく異なるベースイメージを必要とするまれなケース(たとえば、別のOSディストリ
ビューションを必要とするサードパーティソフトウェアを実行する場合)では、チームが独自イメージ
を作成、管理して、必要ならほかのチームとそれを共有するというオプションも持てるようにする。
9.2.8
プラクティス:変更の範囲に合わせてインフラストラクチャを設計
せよ
インフラストラクチャをスタックに分割する方法を決めるときには考えなければならないトレードオ
フがあることは明らかだ。チーム構造やインフラがサポートするサービス次第で、ある会社で意味のあ
る分割方法が別の