Amazonは9月末，メジャーアップデートメンテナンスを実施した。同社クラウドサーバ群のおよそ10%に影響する，Xenハイパーバイザのセキュリティ上の脆弱性に対するパッチの実施が目的だ。今回のアップデートではそれらのサーバを再起動する必要があったため，結果的に同社の最大顧客であるNetflixを含むAWSユーザ，およびその提供するサービスに影響が及んだ。
Netflixでクラウドデータベースエンジニアリングマネージャを担当するChristos Kalantzis氏は，メンテナンス作業実施について初めて聞いたときのショックについて，次のように語っている。
EC2の緊急リブートの知らせを聞いたときには，開いた口が塞がりませんでした。影響を受けるCassandraノード数のリストを受け取った時はぞっとしましたが，そこで，これまでやってきたChaos Monkeyのエクササイズをすべて思い出したのです。思わず"かかってこい！"と言ってしまいました。
Netflixでは，システム全体の挙動の確認や復元力の向上を目的としたサーバの強制的な再起動を行うため，サル系の武器 – Chaos Monkey, Gorilla, Kong – には長い利用キャリアを持っている。今回問題だったのは，作業が同社のデータベースサーバ，正確には218のCassandraノードに影響するだろうという点だ。ビデオをストリーミングしているサーバの無停止再起動も難題のひとつだが，同じことをステートフルなデータベースで実行するのはさらに困難なのだ。
"幸運にも"Netflixは，1年前からCassandraノードにChaos Monkeyの投入を始めていて，必要時にノードを別のマシンに移行するための自動ツールを開発していた。今回のAWSメンテナンスの最終的な結果は次のようになった。
運用している2,700以上のCassandraノード中，218がリブートされました。その内の22ノードは，正常に起動しなかったハードウェア上にありました。それらのCassandraノードはオンラインに復帰しませんでしたが，私たちの自動監視が障害を起こしたノードを検出して，最小限の手作業介入でそれらをすべてリプレースしたのです。その週末，Netflixのダウンタイムは０でした。
InfoQはこの事件とNetflixの対処について詳しく知りたいと思い，同社でChaosを担当するエンジニアリングマネージャのBruce Wong氏に話を聞いた。
InfoQ: 先頃のAWSメジャーメンテナンスでは，マシンの約10%がリブートの対象でした。リブートされなかった残り90%は非Xenマシンだったのですが，事前にCassandraインスタンスの少なくとも一部を，そちらに移動しておくことはできなかったのでしょうか？
BW: それについてはAWSとも検討しましたが，他の90%のインスタンスを前もってターゲットにすることはできないと判断しました。Cassandraインスタンスの移動は可能だったのですが，新しいインスタンスが影響を受けないという保証がなかったからです。根本的な原因やリブートの詳細についての高度な情報は，事前には何もありませんでした。私たちの手元にあったのは，その時点で影響を受けていて，再起動の予定されていたインスタンスのスナップショットだけだったのです。ただし，影響度を予測するために，事前にCassandraノードの再起動をする機会は設けていました。
InfoQ: マシンの10%をChaos Monkeyでダウンさせて，システムが処理可能かどうか試したという経験はありますか？
BW: ゾーン停止時のシステムの挙動を確認するために，Chaos Gorillaを使って，マシンの33%をダウンさせたことはあります。ですが1台ずつ，数日間に渡って全体の10%をダウンさせるという，タイプの違った障害のシミュレーションは，これまで行った試しがありません。
InfoQ: AWSのメンテナンス作業は，Chaous GorillaやChaos Kongで起こした障害と比べてどうでしたか？
BW: AWSが行うメンテナンス作業とChaos GorillaやChaous Kongを比べるのは，リンゴとオレンジを比較するようなものです。Gorillaはゾーン全体のトラフィックを取り除きますが，メンテナンス作業では，メンテナンス中のゾーンへのトラフィック送出が停止されることはありません。Kongも，リージョン全体のトラフィックが取り除かれる点では同じです。
InfoQ: CassandraをChaos Engineeringプロセスに統合するのが難しかったのはなぜですか？
BW: ひとつはツーリングの問題です。私たちのCassandra Clusterの管理方法は，ステートレスなアプリケーションのそれとはかなり違います。ですから，すでに出来上がっていた仕事に便乗することができませんでした。最も大きな課題は心理的なものでした。データベース層にChaosを導入するという精神的ハードルを乗り越えられていれば，あとはまさに自動化とツーリングを書くだけの問題だったのです。完了していれば，CassandraもChaos Engineeringプロセスの立派な一員になっていたはずです。
InfoQ: ダウンしたデータベースのステートは，どうやって処理するのですか？
BW: 私たちのCassandraは，すべてのデータのコピーを３つ持つように設定されています。どの時点においても，クラスタの2/3まで失ったとしても機能することができます。ノードを失って交換が必要な場合でも，新しいノードは所持すべきデータを知っていて，ピアにそのデータを要求します。データの受信が完了すれば，クラスタに再結合して，クラスタは元の強さに戻るのです。