Netflixから“しなやかさ"を学ぶ - カオスエンジニアリングを論じたQCon NYでのHaley Tucker氏の講演より

QCon New YorkでHaley Tucker氏は、“UNBREAKABLE: Learning to Bend but Not Break at Netflix”と題して講演し、Netflixでのさまざまな役割を担当して学んだカオスエンジニアリングの経験について論じた。おもな内容は次のとおりだ - 障害分離のための機能シャーディング(functional sharding)の使用、RPC呼び出しの継続的なチューニング、小さなイテレーションでのカオス試験の実施、テスト環境と運用環境で異なる可能性のある要因への注意、カナリアデプロイメントの活用、可観測性への投資、サポートツール実装時の”カオスの原則”の適用。

Tucker氏の講演は、Netflixエンジニアリングチームの主要業績評価指数(KPI)が再生開始秒数(SPS)である、という話題から始まった。Netflixは全世界に1億8,500万の顧客を抱えており、いつでもコンテンツストリーミングを開始できることは、同社の成功において不可欠である。Netflixのシステムがマイクロサービスアーキテクチャで実装されていることは有名だ。各サービスは、顧客がコンテンツをストリーミングできるための基本的な操作に不可欠かどうかによって、クリティカルと非クリティカルに分類される。高可用性は、機能シャーディング、リモートプロシージャコール(RPC)チューニング、バルクヘッドとフォールバックによってNetflixのシステム内に実装されている。設計と実装の検証には、カオスエンジニアリング(レジリエンスエンジニアリングと呼ばれる場合もある)が使用される。

Tucker氏はNetflixで、5年間にわたって数多くのエンジニアリングの役割を担当している。そのため、プレゼンテーションの残りの部分は、非クリティカルサービスのオーナ、クリティカルサービスのオーナ、カオスエンジニアという３つの主要な役割に分けて、それぞれを通じて学んだ教訓が紹介された。非クリティカルサービスのオーナとしてのおもな課題は、障害時に問題を起こさないことであり、クリティカルサービスのオーナのテーマは、変更や混乱時にも動作を続けることだ。そしてカオスエンジニアとしては、他のチームがよりレジリエントなシステムを構築するための支援が必要となる。

非クリティカルサービスでの最初の疑問は、“非クリティカルであるとなぜ分かるののか?”、という点である。“move badging”サービスを例として、それが説明された。UIにバッチとして表示するために、“HDR”や“Dolby 5.1”といった映画の音声/画像メタデータを提供するという、それほど重要ではないと思われるサービスである。この非クリティカルサービスは、Hystrixフォールトトレランスライブラリ経由でダウンストリームサービスから呼び出されるもので、ユニットテストおよびレグレッションテスト済みのフォールバックを備えているが、テストされていないデータセットは一部のユーザアカウントにおいて例外を発生させ、それがコールスタックを上昇し、最終的には重要なAPIサービスに障害を発生させる。この結果、一連の再生開始障害が発生し、一部の顧客が影響を受けることになる。

非クリティカルサービスのオーナになることで得られたものは - コンフィギュレーションやデータのように、テスト環境と運用環境で環境要因が異なる場合があること。システムは、負荷の下では、単一ユニットあるいは統合テストでの実行とは異なる挙動をする場合があること。そして、ユーザは、こちらの期待とは異なる反応をすることが多々あることだ。ここでは、フォールバックが期待どおりの動作をすることを(現実世界のシナリオ下で)検証する必要がある点と、”従来のテスト方法のギャップを埋める”ためにカオスエンジニアリングが利用可能である点について強調されていた。

次のセクションでは、クリティカルサービスのオーナに焦点が当てられた。ここでの重要な疑問は、“障害の爆発半径を減らすにはどうすればよいのか？”、というものだ。Netflixのエンジニアリングチームでは、クリティカルおよび非クリティカルなクラスタシャードにシャーディングサービスを導入して、すべての非クリティカルなシャードに(コントロールされた方法で)障害を発生させる方法を用いている、とTucker氏は説明した。クリティカルサービスはすべて運用状態を保ったが、クリティカルサービスのシャードではトラフィックが25パーセント増加した。調査によって、この増加したトラフィックは、非クリティカルなサービスが当初実行していたタスクをクリティカルサービスが実行する必要が生じた結果であることが判明した。例えば、非クリティカルサービスは一般的に、近い将来に必要と予測したコンテンツのプリフェッチやプリキャッシュを行っている。

クリティカルサービスオーナのもうひとつの疑問は、“[RPC]システムが適切に構成されていることをどうやって確認するのか？”、というものだ。リトライやタイムアウト、ロードバランス方法、並行処理制限が最適に設定されていることは、どうすれば分かるのだろうか。その答は、カオス試験を実行して、レイテンシや障害をサービスコールに注入し、何が起こるかを観察することにある。Netflixのように展開の早い企業では特にこれが難しく、コードベースやサービスコールグラフが定常的に変更されているため、試験を継続的に実行する必要がある、とTucker氏は警告している。

クリティカルサービスのオーナとしての教訓は、次のようなものだ – 障害分離のために機能シャーディングを使用すること。カオステストを使用するが、レグレッションを簡単に分離できるように、各試験での変更数は少なく留めること。“目くらまし(red herrings)”の多い実際の障害とは違って、きめの細かいカオス試験は調査範囲を限定することができること。

講演の最後のセクションでは、カオスエンジニアとしての役割が論じられた。ここでの大きな疑問は、”よりレジリエンスなシステムの構築を支援するには、何をすればよいのか？”という点だ。その答は、“力仕事をたくさん”行って、ツールやガイダンスをサービスチームに提供することである。カオスの原則を紹介した後の議論は、テスト環境と(注意深く)運用環境の両方でカオス試験を実行することの重要性へと移行した。Netflixのエンジニアは試験による爆発半径を常に最小限に留めようと努めており、押下することですべてのカオス試験を即時停止可能な“全カオス停止”ボタンを用意している。

カナリアデプロイメントとテストは広範に使用されており、運用トラフィックの数パーセントが、制御バージョンと試験バージョンのサービス用に分離されている。最大5パーセントのトラフィックがカオス用への展開を許可されているとともに、試験の実施は休暇期間(顧客の需要がピークになる)を避けるように制限されている。重要なのは、試験中に特定された障害に対処することだ。Netflix ChaosチームのWeb UIでは、手動操作による確認と承認を行わない限り、障害が発生した試験の再実行は許可されていない。Tucker氏は安全のために、カオス試験を“フェールオープン”にすることを推奨している。この状況は、コントロールサービスのエラーが重度であったり、試験とは関連のないサービスでエラーが発生したり、あるいはプラットフォームのコンポーネントがクラッシュした場合に起動される必要がある。

カオス試験は仮説から始めなければならない。ここで前提条件として、システムの定常状態が既知であることが必要となる。これを実現する最善の方法は、効果的な監視や分析や洞察といった、包括的な可監視性を用いることだ。講演ではNetflixがオープンソースとして提供する継続的デプロイメントツールのSpinnakerと合わせて、ACA(Automated Canary Analysis)統合ツールである”Kayenta”が論議された。NetflixのChAP(Chaos Automation Platform)についても簡単な説明があった。これはカオス試験実行中のプラットフォームを検証するもので、障害のインジェクションが適切に行われていることの検証、KPIが期待値の範囲であることの検証、KPIに現れないようなサービス障害のチェック、テスト中のサービスのヘルスチェックなどを行う。

十分に配慮して設計され、優先付けられた試験を用いれば、実際のイベントを自動検証することが可能になる。テストするシステムは十分に理解され、テストの潜在的影響が把握されていなければならない。例えばChAP Web UIでは、フォールバックしないサービスが強調表示されて、エンジニアに警告される。実行する試験に優先度を設定する場合は、サービスが受信するトラフィックの割合やサービスコールの再試行回数、試験のタイプ(障害かレイテンシか)、前回の試験実行からの期間などを考慮する必要がある。ただし、安全性(顧客への影響の回避)は常に最優先事項だ。

このセクションの結論として、運用環境でChAPを実行することで14の脆弱性を発見(重要なツールのギャップも特定されている)し、システム停止が観測されなかったというケーススタディが手短に紹介された。カオスエンジニアの立場から学んだ教訓は、カオスの原則をツールに適用することと、セルフサービスツールを提供して、サービスチームが自身でカオス試験を行なうという“重労働”を回避することだ。

講演の最後にTucker氏は、どのような企業であっても、カオスプラクティスの開始を通じて価値を得られる可能性がある、と論じた。仮説を立て、基本的なレジリエンステストを設計し、テスト環境と運用環境で実行する企業が、Netflixの企業規模で運営されている必然性はないのだ。自身の好きなNetflixのショーのひとつである“Unbreakable Kimmy Schmidt”を引き合いに出しながら、不可避な障害シナリオに対処するためには、“体を縮こめる、死を待つ、... もうひとつ、立ち上がって、‘私たちは違う、私たちは強い、私たちを打ち破ることはできない！’と言うこともできるのです”と論じて、氏は講演を締め括った。

Haley Tucker氏のQCon New Yorkでの講演の詳細は同カンファレンスのWebサイトにある。講演のビデオはInfoＱで、今後数ヶ月以内に公開される予定だ。