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

274

14

章 継続性とダイナミックインフラストラクチャ

のチームで共有することを一所懸命追求している会社がある。しかし、それでは継続性の実現を不必

要に難しくしてしまう。同じインスタンスを使っていれば、ひとつのチームが他のチームに迷惑をかけ

る余地が生まれてしまう。

ツールのインスタンスを自動的にプロビジョニングできるなら、各チームに専用のインスタンスを与

えるのは簡単なことだ。アップグレードやメンテナンスもこれでやりやすくなる。すべてのユーザー

チームがサービスダウンを受け入れられる時間帯を見つけ出さなくても済むようになる（もちろん、ゼ

ロダウンタイム交換など考える余地もない）。

14.2

　

ゼロダウンタイム変更

インフラストラクチャ要素をオフラインにしたり、完全に交換したりといったことが必要な変更は多

い。OSカーネルのアップグレード、ネットワークの再構成、アプリケーションの新しいバージョンの

デプロイなどがそうだ。しかし、これらの変更は、サービスを中断しなくても実行できることが多い。

ゼロダウンタイム変更には、サービスを 24 時間稼働でき、スタッフの時間外勤務を避けられるとい

う誰の目にも明らかなメリットがある。しかし、継続性の向上を阻む大きな障害を取り除くという強力

なメリットは見過ごされがちだ。

勤務時間外での変更はリスキーでボトルネックになりがちだ。変更が遅れるくらいならよい方で、悪

くすれば変更を嫌がるようになる。これがさらにエスカレートすると、小さな問題や「既知の問題」は

我慢するという「まあまあ」 ...