Netflix障害中
Netflixが障害中です。
Downdetectorによれば、今日（2019/11/21）の22:55ごろから発生し継続しています。
https://downdetector.jp/shougai/netflix/
https://downdetector.jp/shougai/netflix/mappu/
「Cannot play title. Please try again later. (5003)」というエラーがでてストリーミング再生できないというツイートが相次いでいます。
Netflix Down : Due to outage user getting Unexpected Error https://babblesports.com/tech/netflix-down-due-to-outage-user-getting-unexpected-error/ … #Netflixdown #netflixoutage #netflixstreamingoutage MSL:5003
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="600" height="314"><rect fill-opacity="0"/></svg>)
どうも、世界中で・・という状況です。
公式のヘルプセンターでも、お知らせが出ています。
Netflixの運用保守は有名だった
運用エンジニアとして、Netflixの先進的な障害予防の取り組みは何度も聞かされましたとも。
世界に1億人超のユーザーを抱えるネット動画配信サービス大手の米Netflix。障害がつきもののクラウドで、数千のマイクロサービスに分割したアプリケーションを15万台以上の仮想マシンによって安定稼働させる。このことは、同社にとって極めて重要な課題だ。
Netflixは、わざと本番障害を起こしてすぐ復旧させることを繰り返し、本当の障害発生に備える、という驚くべき手法「カオスエンジニアリング」を実践している。
その効果は実証されている。Netflixが全面的に採用しているAmazon Web Services（AWS）で、2017年2月に中核施設の一つ、米バージニア北部リージョン（広域データセンター群）にて大規模障害が起きたとき、別のリージョンに速やかに切り替えたという。
普通は考えられない。本番障害を起こしたとしてもすぐに復旧できる。これを前提してわざと本番障害を起こす。
カオスエンジニアリング！
本番システムにカオスエンジニアリングを取り入れた企業が、Netflixのほかに存在するのか興味を持ちました。
サービスやシステムに意図的にトラブルを発生させることで、実際にトラブルが発生した際に的確な対処ができるような訓練を行うことを「カオスエンジニアリング」といいます。Googleが従業員に対して行っている4つのカオスエンジニアリングについて、Googleのエンジニアリングディレクターであるデイブ・レンジン氏が語っています。
内容を読むと、フェイルセーフというか、うまくいかなくても深刻な障害を引き起こさない部分に対して、積極的に利用しているようですね。
クックパッド
クックパッドが2018年8月2日に公開したブログエントリ「Chaos Engineering やっていく宣言」に大きな反響があった。米国を中心に多くの企業で実践されているが、疑似的とはいえ本番環境に障害を起こさせるというカオスエンジニアリングを日本で実践するのは、まず不可能という向きが多かったからだ。なぜ、クックパッドでは実践することが可能になったのか。
日本国内でもクックパッドがやっていたことにびっくり。
これを読んだとしても、私は勇気が持てないなあ。本番リリース時にすべてのテストを通しておくこと、また修正時は修正部分を網羅してテストすること。というあたり前の方法しかやる勇気が出ない。
ヤフー
塚氏 SREの観点から「カオスエンジニアリング」に注目しています。私は、エンジニアほど自分以外のことのために脳を使っている職業はないと考えています。それだけに、他の煩わしいこと、例えば人がやらなくていいものは機械に任せたい。いわゆるNoOpsを実現することが重要だと思っています。その一つが障害対応で、何らかの障害が起こったときに、自動的に動いて対処してくれるシステムを用意しておけば、運用負荷は大幅に軽減できます。ここに、カオスエンジニアリングが重要な役割を担うと期待しています。
Netflixのカオスエンジニアリング事例が鮮烈だっただけに、国内の運用エンジニアは注目が集まっていたのがわかります。
著しく先進的－－それでも起こる障害
22:55から一時間ほど経過していますがまだ復旧していないことがTwitterからもわかります。
ほどなくニュースになるでしょう。
昨日のOffice 365もそうですが、クラウドの世になって、障害が世界規模で起こるようになっています。
AWS基盤自体のステータスは全てグリーンですので、アプリ側の問題と言えるでしょう。https://status.aws.amazon.com/にて確認しました。
Netflixの技術力については、先進的なことで有名でした。
NetflixはパブリッククラウドサービスのAmazon Web Services（AWS）を、2009年に大規模導入した先進ユーザーとしても知られる。2017年末時点で、利用する仮想マシンは15万台超という。
AWSを大規模に利用しているだけではない。システムを適切な単位に分割して独立性を高めることで頻繁な機能変更を可能にする「マイクロサービスアーキテクチャー」の全面採用や、自動復旧の仕組みを整えたうえで常態的にわざと本番環境の障害を起こして耐障害性を向上させる「カオスエンジニアリング」の実践など、システム開発・運用の最先端をひた走る。
Amazon Web Services（AWS）のユーザーのなかでも開発・運用の先進性で別格といえる存在の米Netflix。システムの開発では「マイクロサービスアーキテクチャー」を全面採用し、機能変更の頻度を高めている。
自社のサービスをAWS上の仮想マシンで運用するNetflixは、コンテナベースの開発とデプロイメントモデルのメリットを活用するため、システムの一部をコンテナに移行する作業を開始した。その中で同社に固有の課題となったのが、既存のクラウドネイティブなアーキテクチャの存在だ。コンテナモデルへの移行によって、あまりにも大きな変化があることは許されない。VMとコンテナを併用するハイブリッドなデプロイメント、マイクロサービスとバッチジョブの混合、コンテナに伴って導入される新たなレイヤの信頼性の保証といったものが、技術的な面での課題であった。
これらの課題に対処するため、Titusと呼ばれる独自のコンテナ管理プラットフォームが開発されることになった。Netflixは現在、ビデオストリーミング、レコメンデーション、マシンラーニング(ML)、ビッグデータ、コンテントエンコーディング、スタジオテクノロジ、および社内エンジニアリングツールをコンテナで運用しており、その数は１日当たり50万コンテナと20万クラスタに及ぶ。
・・とまあ、一技術者として、Netflixの先進性は突き抜けていて、（マネしたいとは全く思いませんが）すごいなあと思ってはおりました。
今回の件、何が引き起こしたのか。またなぜ、カオスエンジニアリングの手法で防げなかったのか。とても興味をもっています。クラウドサービスの障害が、Office365に続きNetflixと来ましたから、クラウド運用だから安全というのはウソです。かといってオンプレなら安全かと言うことこれもウソです。システム運用はリスクとの戦いです。それは場所を選びません。そこに運用エンジニアがいてリスクを最小化すべく戦っているのです。
Netflixは今回の件から何を体験し何を学ぶのか興味は尽きません。
一刻も早く復旧できることを願っています。
※追記
80分ほどで回復したそうです。カオスエンジニアリングの功績かどうかはわかりませんが素早い復旧かと思います。