米動画配信のNetflix、Chaos MonkeyのおかげでAmazon EC2のメンテナンスリブートを難なく乗り切る

2014年10月7日

Amazon EC2は9月末、その内部で使用しているXenハイパーバイザのセキュリティリスクに対処するため、全インスタンスの約10%にあたるインスタンスに対して段階的にリブートを行うメンテナンスを実行していました

The Netflix Tech Blog: A State of Xen - Chaos Monkey & Cassandra

リブートをユーザーが回避する手段はなく、AWSから事前に通知を受けたユーザーはリブートによってデータを失ったりシステムがダウンしたりしないように、何らかの処置をする必要がありました。

AWS上で大規模なシステムを運用しつつもこのメンテナンスリブートを難なく乗り切ったのが、米国で動画配信サービスなどを運用するNetflixです。その理由は同社が開発したChaos Monkeyというツールにありました。

同社のブログにポストされた記事「A State of Xen - Chaos Monkey & Cassandra」で、その顛末が紹介されています。

Chaos Monkeyによって鍛えたシステムが本当に試されるときが来た

Chaos Monkeyとは、以前Publickeyの記事「サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開」でも紹介した、人工的にシステム障害を引き起こすツールです。

具体的には、Amazon EC2のインスタンスをランダムに落としまくることで、サービスに対して仮想的な障害を引き起こしてくれます。これにより、サービスがきちんと冗長化され、耐障害性を持つように作られているかどうかを日常的に検証できるわけです。もちろん営業時間中だけ動作させるとか、必要以上にインスタンスを落とさないようにするなど、Chaos Monekyそれ自身が大きな問題を引き起こさないように設定できます。

NetflixがChaos Monekyをオープンソースで公開したのがいまから2年前の2012年、同社内ではそれ以前からこれを利用して不意のサーバダウンに対するシステムの動作を検証し続けてきたはずです。まさに今回のAmazon EC2のリブートは、そのChaos Monkeyによって検証され続けてきたシステム全体の安定性が本当に試されるときだったと言えるでしょう。

その結果について同社のブログでは「私たちのシステムは、このリブートを驚くほどうまく扱っているように見えた」と書いてあり、同社のシステムがリブートを難なく乗り越えたことが示されています。

Cassandraも復旧を自動化してリブートに耐えた

NetflixがChaos Monkeyで試していたシステムの中には、同社がバックエンドデータベースとして採用しているNoSQLのCassandraも含まれていました。実は同社の今回のブログはこの部分がいちばんの見所になっています。

Last year we decided to invest in automating the recovery of failed Cassandra nodes. We were able to detect and determine a failed node. With the cloud APIs afforded to us by AWS, we can identify the location of the failed node and programmatically initiate the replacement and bootstrap of a new Cassandra node.

昨年、私たちは落ちたCassandraノードの自動リカバリに取り組むことを決断した。落ちたノードを検出することは可能であり、AWSによるクラウドAPIでそれがどのロケーションなのかを判別できるため、それを置き換え、新しいノードを立ち上げるプログラムを実現した。

この自動化を実現した上で、Chaos MonkeyによるテストにはCassandraが加わり、サーバが落ちても動作し続けるように検証が続いたそうです。

この結果、今回のAmazon EC2のメンテナンスでは、運用中の2700を超えるCassandraノードのうち218がリブートされ、そのうち22ノードのリブートが失敗したにもかかわらず自動的に復旧が行われ、全体としてはダウンタイムゼロでAmazon EC2のメンテナンスリブートを乗り切ったと報告されています。

Netflixのブログは、「パーシステントレイヤー(データベースのような永続的データを担当するレイヤー)であっても、レジリエンス(障害などへの対応力や回復力)の計画を持つべきだ。もしCassandraをChaos Monkeyのテストに加えていなかったら、今回の話は別の結果に終わっていただろう」と結んでいます。クラウド上に展開したシステムをどのように設計し、テストすべきなのか、大きな示唆を与えてくれているのではないでしょうか。

関連記事

このエントリーをはてなブックマークに追加
follow us in feedly

タグ : Amazon , IaaS , クラウド



≫次の記事
ブロケード、SDNコントローラ「Vyatta Controller」を発表。OpenDaylightベースのオープンソースで、シスコ、ジュニパーなどマルチベンダー対応も
≪前の記事
米ヒューレット・パッカードが会社分割を発表。サーバ、クラウドなどは「Hewlett-Packard Enterprise」、PCやプリンタは「HP Inc.」に

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール


Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed



Publickey 最新記事 10本

Publickey Topics 最新記事 10本


PR - Books


fig

fig

fig

fig



blog comments powered by Disqus