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

14.2

 ゼロダウンタイム変更

279

なことのように感じるかもしれない。しかし、実際には、よほど単純な場合を除けば、交換作業を複雑

にしている。多くの場合、複雑になっても、絶えず変化している環境で中断なしにサービスを実行し

続けられればメリットの方が大きいが、パターンの実装方法をしっかりと理解することが大切になる。

ゼロダウンタイム変更パターンは、使っているシステムコンポーネントの切り替えのために、精密な

コントロールが必要になる。それを実現するためのメカニズムは、コンポーネントの種類によって変わ

る。ウェブベースアプリケーション、サービス（つまり、HTTP、HTTPSプロトコルを使うもの）は、

このパターンが特によく使われる分野である。この場合、標準のHTTP/Sロードバランサーを使え

ば、ゼロダウンタイムデプロイを実現できることが多い。

新しくプロビジョニングされた要素は、完全にテストして本番対応になるまでロードバランサーから

排除しておくようにすれば、簡単に切り替えを実現できる。図14-5は、これを示したものである。新

しい要素はロードバランサープールに含まれないか、含まれているものの、ロードバランサーの健全性

チェックではねられて実際には使われないように構成 /設定されている。

ロード

バランサー

図14-5　ロードバランサーはプールから新しいサーバーを外すことができる

しかし、新サーバーが追加され、古いサーバーが削除されたときスムースな移行は難しそうに見える。

図 14-6 のように、新しいサーバー用と ...