Amazon Web ServicesとRackspaceはXenのハイパーバイザにパッチを当てるため、サーバを再起動すると通知した。
AWSの公式ブログによれば、9つのリージョンの10%のサーバがXenのハイパーバイザの未公表のセキュリティホールの影響を受けた。つまり、顧客が利用しているかなりの数の仮想マシンが影響を受ける。また、その後、Rackspaceはあるタイプの仮想マシンをメンテナンスの一環で再起動すると発表した。
AWSがクラウドで計画的に再起動を行うのはこれが2回目だ。2011年12月、パッチを適用するためEC2インスタンスの再起動を強制したことでAmazonは非難された。Amazon EC2のメンテナンスヘルプページは計画メンテナンスの一環として2種類の再起動が行われる、している。すなわち、インスタンスの再起動とシステムの再起動だ。インスタンスの再起動は仮想インスタンスの再起動であり、OSの再起動と同じだ。システムの再起動は下層の物理サーバの再起動を必要とする。
クラウド管理プラットフォームのRightScaleはこの再起動に対処するためのガイダンスを提供している。同社のブログによれば、短時間の再起動を許容できる顧客は今回の再起動では何もしなくていい。Amazonは仮想インスタンスを自動で再起動し、仮想マシンは再起動前と同様に動作するはずだからだ。
クラウドインフラを支える物理ホストのパッチ当てやメンテナンスのためにダウンタイムが生まれるのは、どのクラウドプロバイダでも同じだ。しかし、最近では、IaaSプロバイダは透過的なメンテナンスを行えるようになっている。Google Cloud Platfromは最初に透過的なメンテナンスをサポートしたプロバイダの一つだ。技術的にはLive Migrationと呼ばれているこの特徴は、顧客のVMを停止なしでメンテナンス対象のホストから新しい物理ホストへ移行することができる。これによってGoogleは顧客の仮想マシンを停止せず、計画的なダウンタイムも発生させずに、データセンターのメンテナンスを行うことができる。また、最近になって、VMwareもパブリッククラウドであるvCloud Airに同様の機能を導入した。vSphereプラットフォームを動かしている仮想マシンを移行させる技術であるvMotionの開発で獲得した知見をクラウドへと展開したのだ。MicrosoftもHyper-Vで同様の機能をサポートしている。
再起動後、RackspaceのCEOであるTaylor Rhodes氏は顧客に謝罪した。“このメンテナンスは私たちの20万の顧客の4分の1に影響を与えました。また、このメンテナンス作業中にいくつかミスを犯しました。例えば、想定よりも長くかかってしまった再起動もありました。また通知の内容もわかりにくかったです。私たちはこれらのミスを修正するよう、変革を行っています。また私たちはフィードバックを歓迎します。”
また、AWSはフォローアップのブログ記事もアップしている。弾性のアプリケーションのためのベストプラクティスを紹介する記事だ。AWSを含むクラウドプロバイダは顧客に再起動や再開を行っても問題ないような設計にすることを推奨している。手動の再起動だけではなく、アプリケーションをよりスケーラブルにするための設計だ。
AmazonのチーフエバンジェリストであるJeff Barr氏は次のように推奨している。
- インスタンスを複数のAvailability Zonesで実行する。
- AWS Management Consoleのアラートやメールでの通知に注意する。AWS Billing Consoleの"Alternate Contacts"を入力しておく。
- Trusted Advisorでのアーキテクチャの評価をレビューする。ベストプラクティスを実装するためにAWS Premium Supportを使って支援を受ける。
- Chaos Monkeyを使って人為的に障害を起こしてみる。
- Amazon Route 53とElastic Load Balancingの利用拡大を検討して、トラフィックが正常なインスタンスに流れるようにする。
- Auto Scalingを使って正常なインスタンスが一定数立ち上げっていることを保証する。