訳：Netflixが 6.29のAWSと嵐から学んだこと

2012年6月は、立て続けにUS EASTリージョンでダウンタイムが発生している。

NetflixのようにマルチAZの構成にして、常に擬似的に障害を発生させる仕組み( Chaos Monkey)を導入していても、ダウンする場合があることが明らかになった。さらなる可用性向上のためのツール(Chaos Monkey Family)やアーキテクチャ設計ノウハウがNetflixから出てくることを期待。

The Netflix Tech Blog: Lessons Netflix Learned from the AWS Storm

＝＝＝

概要

2012年6月29日(金)、ここ1年で最も大きな停止障害を経験した。太平洋時間午後8:00に始まり、復旧まで約3時間かかり、アメリカのNetflix会員に影響を及ぼした。弾力性のあるインフラに向けた努力にとAmazonクラウドでの経験をよく書いている。過去にも、AWSのAZ停止障害に対して最小限の影響で済むようにしていた(withstand)。なぜ特定ゾーンの停止障害がこのような影響を与えたのか？について分かったことを共有する機会としたい。

背景として、まずはAmazonが出している停止障害の原因分析(http://aws.amazon.com/message/67457/ )を読んでほしい。簡単にまとめると、非常に激しい嵐による停電の影響でAmazonのAZが停止した。電源は20分後に復旧したが、Elastic Load Balancer(ELB)がキャパシティ問題に直面し、APIのバックログが溜まり、復旧が遅れた。

興味深い我々独自の原因分析結果としては、内部の中間層ロードバランサーも含まれていた。不正常なインスタンスがロードバランサーから切り離され、膨大なトラフィックが、不正常なゾーン(unavailable zone)に吸い込まれた(black-holed)。更に、不正常なゾーンにあるインスタンスへのネットワーク通信が、no routeではなくハングした。

この停止障害を通して、我々とAmazonで改善できる多くの点を見つけ、その改善に取り組んでいる。

中間層ロードバランス

中間層のロードバランスで、別種類障害の原因となる機能により連鎖的な障害が起きてしまった。同時にダウンするような特殊な障害時に、非正常なインスタンスを切り離さないようなフェイルセーフ状態を維持していた。ネットワーク分断によって発動し、大規模障害時には誰かが原因調査するまでの間はフリーズしてしまう。不幸なことに、この状態を解析するのがやっかいで時間を浪費してしまうことが分かり、電源障害でサーバが使えなくなってしまった。

Gridlock

クライアントが使えないサーバに接続しようとしていることが、2番めの問題として導出された。全クライアントスレッドが、不完全な接続で実行され、ほんの僅かなスレッドがリクエストを処理していた。内部システムで複数層をトラバースしようとするgridlockを引き起こしていた。このような種類のケースに対して対応できるようにシステムを改善している。これらの接続が、接続できないと即座に判断せずに、タイムアウトするまで接続を維持したか？を解析している。

まとめ

Netflixは数年前に、自前のデータセンターからクラウドに移行することを決めた（http://techblog.netflix.com/2010/12/four-reasons-we-choose-amazons-cloud-as.html）。

クラウドの障害は制御できないので、クラウドの障害を批判することはとても簡単で一般的だが、ここ数年の可用性に対する取り組みから、安定した改善できる事がわかっている。最も大きな停止障害の原因を掘り下げると、サービス障害を軽減するためのアーキテクチャパターンを見つけることがわかっている。

我々の弾力性のあるアーキテクチャが正しく動作したという側面はある。リージョン隔離には、会員がUS-EASTリージョンにアクセスしている、という問題も含んでいる。ヨーロッパの会員には影響がなかった。分散クラウド永続化ストアとして全ゾーン・全リージョンをまたいで使っているCassandraは、1/3のノード喪失があっても、データや可用性を失わないようにしている。

あるAZを無くすシミュレーションを行うChaos Gorillaというサル軍団(Simian Army)の１つは、まさにこの目的のために作られた。今回の停止障害で、さらなるツールの追加が必要であることと、Chaos Gorillaやその他のSimian Army用のユースケースが必要であることが強調された。

クラウドの状態は成熟を続けるだろうし、時間とともに改善するだろう。Amazonがシステムを改善する方法について、Amazonと密に動き続けている。我々は、リージョン全体の停止障害になるような単一障害点を無くすことと、特定のゾーンの障害を隔離することに注力する。

我々にとって可用性はとても重要(seriously)であり、全会員に途切れないサービスを提供することに努力(strive)している。我々は未だにクラウドに期待(bullish)しており、我々のインフラで提供するサービス障害から会員を守るために努力を続けている。

クラウド運用・信頼性向上チームを作り、今回のような多くの問題に取り組んでいる。各サービスチームもサービスの可用性に対応している。