Amazonの中の人によるAWS re:Invent 出張報告会での注目スライドサマリ(Netflix)

こんにちは。

前回に続き、お勧めスライドを見ていきます。
2つ目はARC305、NetflixがマルチAZにおいていかに高い可用性を確保したかの内容です。
・・・意外に、日本語情報がぱっと検索して見つからなかったのでどうせなのでサマリしてみます。

2.ARC305 how netflix leverages multiple regions to increase availability an isthmus and active-active case study（スライド）（動画）

まずはじめの前提として、様々な要素が素早く変化するという前提の大規模システムにおいては、
ソフトウェア障害、ハードウェア障害も常時発生するという前提に立ってシステムを構築する必要がある。

これらの障害の影響を抑え、サービスを提供し続ける必要がある。
尚、各単位ごとの障害原因は以下のようなものがある。
・インスタンス障害：計画停止、不正なコード／設定の投入、潜在的な問題、ハード障害
　→　これらはChaos Monkeyというテストツールでランダムでプロセス障害、インスタンス障害を発生させ、確認する。
・ゾーン障害（稀ではあるが、以前発生したことがある）：ルーティング問題、ＤＣ固有問題、Zone固有のアプリケーション問題
　→　これらはChaos Gorillaというテストツールでルーティング等を操作して実現し、確認する。
・リージョン障害（ありそうになく、非常にまれ）：基本的にはリージョンレベルの設定誤り位？
　→　これらはChaos Kongというテストツールで障害を再現し、確認する。

上記の事情の中、Netflixはクラウドネイティブな新たな技術的チャレンジを行った。
「一時的な、かつ故障が想定されるコンポーネントを組み合わせていかにして機敏で高信頼なサービスを提供するか？」
その中で重要となる２要素を定義する。
・分離性
1リージョンの変更が他リージョンに影響を与えない
1リージョンの停止が他リージョンに影響を与えない
リージョン間のネットワークが遮断された場合に機能的／オペレーションに影響を出さない
・冗長性
様々な要素を1つより多く用意する
特に、AZ、リージョンをまたいで存在するようにするようにする

障害履歴：2012クリスマスイブ
Netflixは数時間停止してしまった。US-East1リージョンのElastic Load Balancing(ELB)の問題であった。
ミスにより起動したメンテナンスプロセスにより、プロダクション環境のELBのデータを消してしまった。
影響を受けたELBは稼働中の7%だったが、他のELBのスケールアップを阻害し、障害となった。
下記のように正常動作していたシステムが・・・

障害により、下記の状態になった。

結果、1サービスを提供するのに必要なコンポーネントが揃わなくなり、サービスが停止した。
（ELB/Zuul/InfrasructureとCassandraレプリカ群という１サービス提供可能なものが揃わなくなった）
　→　1リージョンのELBの障害でリージョンをまたいだ障害を招いてしまった。

上記の反省を踏まえ、下記のような1リージョン内でサービスが完結する構成にした。
そうすればリージョン間のネットワークが遮断された状態でもサービスに影響が出ることは無い。

尚、データストアにはCassandraを使用している。
hi.4xlargeインスタンス×16を1AZに、それを6AZ分配置することで総計192TBのSSDを確保して稼働している。
　→　起動してデータが同期しきるまでには20分かかる。
尚、リージョンをまたいだ性能試験の際は東リージョンに100万件の書き込みをCL.ONEの一貫性で書き込んだ際に、
西リージョンで0.5秒後に100万件の読み取りを行った結果、1件も欠落は発生しなかった。

その際、SQSを用いて書き込みを行ったことを管理している。

このようなシステムを運用するにあたっては、「リージョン間でデプロイ失敗、設定の違い、リソースの違い」を検知するMultiregional Monkeysを用いて常時監視を行っている。
また、リソースの監視も行って「リージョン毎」のメトリクスを取得して統合し、異常検知を行っている。

その上で障害が発生した時にはフェールオーバーとフェールバックのアプローチで対応する。
DNSの切り替えを行い、データの一貫性を確保して対応する。
また、Cold Cacheやオートスケールといった取り組みも行っている（オートスケールはAWSのものではなく、独自のものを使用しているようですね）。
後はひたすら自動化すること。

後はクロスリージョンでのDevOpsを行う際のポイント。
・ベストプラクティス：デプロイはピークタイムには行わない（→Netflixは時間帯で大体のトラフィックの傾向がわかっているからこそ可能）
・問題は早期検知／切り戻しを行う
・障害検知と継続的デリバリは自動的に行う

尚、これらの機能の一部はGitHub上でソースが公開され、どうやって行っているかが見れる。
https://github.com/Netflix

＝＝＝＝＝
「1リージョンでサービスは完結するようにする」というのは見てみればなるほどという形なんですが、
実際に出くわしてみないとそうしないような気はしますね・・・クラウドネイティブだからこそ発生する観点ではあると思います。
後はひたすら自動化する所でしょうか。