クラウドサーバーにて極力ダウンタイムを抑えるために

HPやシステムの保守を長年やっていると多くの方が少なくとも1回はサーバメンテナンスや障害対応に追われたことがあるかと思います。
AWS等のクラウドサービスの冗長化方法などのクラウドデザインパターンなどは多数の本が出版され様々な手法が掲載されています。
実際に事前メンテナンスの告知や障害が発生した場合はどのように対応していくのかを思考してみたいと思います。

DNSレコード 反映待ち対策

私自身サーバを扱いだして12〜3年くらいになるのですが、初期の段階でVPSに出会いました。
VPS自体リリースされたときは画期的なものだったのでお手軽にlinuxのlsコマンドが打てるというのは感動を覚えたものです。しかし、今もそうですが障害というのはそうそうあるものではないですがやはり定期的にやってくるメンテナンスは曲者でした。
簡単なapache等の再起動であれば、クライアントに簡単な再起動があります程度の告知で良いのですが、まれにディスク交換でお昼に2〜3時間程度停止しますなどの告知がやってきます。
VPSでもクラウドでも差異はなく、メンテナンス告知があると本番環境と同様のサーバを立て（今でこそクローンやコピーがありますが昔はなかった）更新等を一旦止め同期後移行後のIPアドレスにドメインを紐付けます。

そこで問題になるのが、DNSレコード切り替え作業です。
DNSレコードを更新した際にはすぐには反映せず反映待ちの状態となります。
一般的にTTLより短い切り替え時間にはできないし、提供DNSによってはTTLの設定自体不可にしている会社もあります。手元で切り替えタイミングを管理できないというのはけっこうな痛手です。

クラウドにはIPアドレスの動的な付替えが可能なサービスがあります。
この機能があるクラウドサービスと、無いクラウドサービスがありますが、AWSでは存在します。
EIP（静的IPアドレス）を利用することでIPアドレスの付け替えが可能となります。既存のEC2インスタンスに紐付いたEIPをデタッチし新しいEC2インスタンスにアタッチするだけとなります。
動的にIPアドレスを変更することでDNSレコードの反映に依存しない形でドメインを変更せずサーバの移動が可能となります。

ただ、次の課題として、別のVPCなどセグメントを越えた冗長系がある場合はどうすべきか？
やはりこの場合だとDNSレコードの書き換えが発生してしまうのでは？といったところですが、
こちらもAWSだとVPCのネットワークルーティングの設定ができるため、特にDNSレコードを変更せずにフェイルオーバーが可能となります。

サーバの差し替え

クラウドサービスの場合何らかの影響によりサーバ自体に不具合が発生し停止してしまった場合、障害が発生したサーバから仮想ディスクを切り離し別のサーバに付け替えるということも可能です。
上記のIPアドレスの動的付け替えと組み合わせることで非常に短期間での復旧作業が可能となります。

このあたりの機能は、機能を知っているか知っていないかだけで、移行作業に数時間かかるか数分で終わるかの差があるかと思います。
実際に障害によりダウンタイムが発生していまう構成を排除すべきではある（ELBの導入など）のですが、コスト面を考慮して単一構成を希望される場合もあります。
とは言うもののダウンタイムの長さはクライアントの満足度に直結することが多いため様々な復旧手法・手順を把握しておく必要があります。
冗長化が取られているサーバ構成はよく目にするのですが、防災訓練のような形で復旧作業のガイドライン等を作成しておくと有事の際に早急な対応が可能になるかもしれません。

参考

クラウドデザインパターン設計ガイド 改訂版
玉川憲 (著), 片山暁雄 (著), 鈴木宏康 (著), 野上 忍 (著), 瀬戸島 敏宏 (著), 坂西 隆之 (著), 日経SYSTEMS (編集)