LinkedInのカオスエンジニアリング - "LinkedOut"障害注入テストフレームワーク

LinkedIn Engineeringチームが先日、自らの“LinkedOut”障害注入テストフレームワークについて、その詳細を説明した。このフレームワークは、アプリケーションとサービスのレジリエンスに関する仮説の生成をサポートし、LinkedIn LiX A/Bテストフレームワークまたはクッキー内のデータを通じて、特定のリクエストへの障害の注入を可能にする。テスト可能な障害シナリオはエラー、遅延、タイムアウトなどである。このLinkedOutプロジェクトは、LinkedInのすべてのチームがレジリエンスエンジニアリング活動に取り組む、“Waterbear”活動の一環として運用されている。

サイト信頼性を担当するシニアエンジニアのLogan Rosen氏は先頃、LinkedIn Engineeringブログに、“LinkedOut: A Request-Level Failure Injection Framework”と題した記事を書いた。記事はまず、複雑な分散テクノロジスタックにおいては、障害の発生し得るポイントを理解することに加えて、これらの障害がエンドユーザに対してどのような形で現れるかを知ることが重要である、と指摘する。“発生する可能性のある問題は発生する”ということを、エンジニアは想定しなければならない。

分散システムに障害を注入する方法はたくさんあるが、最も詳細な方法は要求レベルである。Netflixのカオス/レジリエンスエンジニアリングチームは以前、同社がFIT(Failure Injection Testing)フレームワークを開発し、最終的にこのレベルで障害を注入するChaos Automation Platform (ChAP)に発展した経緯について論じている。同社のサイト信頼性エンジニアリング(SRE)チームも同じように、2017年後半にWaterbearプロジェクトを立ち上げ、システム障害のレプリケーションと障害を安全かつ透過的に処理可能なフレームワークの提供を通じて、開発者が“レジリエンスの問題に正面から立ち向かう”ことを支援する活動を行なっている。この活動の中で、要求レベルの障害注入を可能とするLinkdOut障害注入フレームワークが誕生したのだ。

LinkeOutの核となるのは、RESTスタイルの通信を行うクライアントとサーバの開発を容易にするJavaフレームワークであり、同社のRest.liスタック内に配置された“ディスラプタ(disrupter)”要求フィルタである。この開発のオープンソース部分が、同プロジェクトGitHubリポジトリのr2-disruptorおよびrestli-disruptorモジュールにある。現在のLinkedOutは、3タイプの障害を生成することが可能である。エラー -- Rest.liフレームワークには、通信あるいは要求されたリソースに関わるデータに障害が発生した場合にスローされる、いくつかのデフォルト例外がある。遅延 -- フィルタが要求をダウンストリームに送る前に、一定量のレイテンシを指定することが可能である。タイムアウト -- フィルタが指定されたタイムアウト時間を待機する。

LinkedOutフレームワークを使えば、コードの堅牢性を開発時に検証することが可能になる。この検証は運用シナリオにも拡張され、外部関係者に提供可能な信頼性と堅牢性の証拠となる。エンドユーザエクスペリエンスへの影響を制限しながらディスラプタを起動するために、おもに２つのメカニズムが存在する。ひとつはLinkedInのA/Bテスト用フレームワークであるLiXとLinkedInのフィーチャーゲートであり、もうひとつは要求にキー/バリューを渡して、その処理に関連するすべてのサービスに伝搬させることを可能にする、LinkedIn独自のRest.liフレームワークの内部コンポーネントであるInvocation Context(IC)である。

LiXを使うことで、単一メンバによる個々の要求から、指定した割合のメンバによるダウンストリームクラスタ全体に対する要求まで、複数のレベルの障害を対象とすることが可能になる。

LinkedInのサービスコールグラフは巨大かつ複雑である -- 最新のホームページは依存関係ツリー上に550以上のエンドポイントを所持する -- ため、この多数のエンドポイントが関わるホームページのすべての障害シナリオにおいて、“安全(graceful)”な縮退を期待するというのは極めて難しい。そのためSREチームは、(実在メンバに関連しない)サービスアカウントを用意して、すべてのLinkedInサービスにアクセス可能としている。

Webページを自動テストするため、同チームでは、Seleniumテストを大規模に実行可能なLinkedinの社内フレームワークを活用した。クッキーを介して中断情報を呼び出しコンテキスト(IC)するためにコマンドを送信し、ユーザ認証を行った上で、テストで定義したURLをロードする。障害注入後の成功の判断にはいくつかの方法を検討したが、フレームワークの最初のイテレーションで、“oops”(エラー)ページとブランクページのデフォルトマッチャを提供する単純な方法に落ち着いた。Seleniumがロードしたページがこれらデフォルトパターンのいずれかにマッチした場合、そのページは安全に縮退していないものと判断される。

ここで得た教訓として、Rosen氏は、作成したサービスアカウントがLinkedInにおける実在メンバのエクスペリエンスを必ずしも反映していない点を指摘している。例えば、SREがProfile Viewsページの安全な縮退を確認するテストを作成し、最初のひとつのダウンストリーム障害がテストの失敗を発生させ、結果としてページがエラーを返す。しかし、テストユーザとしてログインしている場合には問題が発生する。このテストユーザがLinkedInに接続されておらず、プロファイルに誰もアクセスしていないため、障害を注入しなくてもProfile Viewsページがエラーを返すのだ。この問題に対処するためには、テストユーザのプロファイル画面を表示して関連データを設定する必要があるが、そうすると今度は、“テストユーザがLinkedInの実在ユーザを常に表現しているとは限らない”、という問題が浮上する。将来的には、LinkedOutのユーザが独自のテストユーザを用意して、事前にデータを設定可能にすることで、この問題を解決する予定である。

LinkedInでは、LiX試験フレームワークの完成度と機能を活かすことで、特定機能を対象(フラグ付け)にした障害発生のメカニズムの簡略化に成功している。エンジニアは、指定した障害パラメータに基づいた標的試験(targeting experiment)を作成する。この試験がアクティブになると、中断フィルタ(disruption filter)がLiXクライアント経由で変更を感知し、対処となる要求をフェールさせる。LiXを使用することで、誤った、あるいはエンドユーザに不適切な影響を及ぼす障害計画を(“数分以内に”)停止することも簡単である。

IC注入メカニズムでは、クッキーを介して中断データを指定することにより、ブラウザ内の単発的なテストを短時間で行なうことができる。Webページ生成に関わるダウンストリームサービスを見つけるためには、“Call Tree”と呼ばれるLinkedInのサービスを使用する。Call Treeは、サービスが要求を処理して、関連するすべてのステップを示すコールツリーを構築する際に生成するKafkaイベントを参照する。Call Treeを使用することで、その要求で見つけられたすべてのコールツリーをリンクしたグループキーを、要求に含まれるクッキーとして設定することが可能になる。テストを実行するエンジニアのために、サービスディスカバリとIC障害注入を容易にするChrome拡張機能が用意されている。適用可能なリソースに対するすべての障害モードを選択すると、拡張機能が障害用のJSON blobを生成し、ICに注入するためのクッキーをセットした上で、障害を適用するページをリフレッシュする。

先日のブログ記事では障害注入の技術的な面を中心としていたが、前回の記事“Resilience Engineering at LinkedIn with Project Waterbear”では、協力的な文化を構築する重要性について議論し、レジリエンス試験の人間面に焦点を当てるとともに、科学的手法と仮説の設定によるカオステストの設計と実施の必要性を論じている。

LinkedInのSREはサービスオーナによって構成され、“Waterbear”(真空の宇宙空間などでも生存可能な、極めて耐性の高い生物であるtardigrade(クマムシ)の別名)と命名されたプロジェクト内での自らのチームと、クロスファンクショナルに活動している。記事では、Waterbearは“アプリケーションレジリエンス”・アズ・ア・サービスを提供するものと考えるべきだ、と示唆している。SREチームがドメインと問題を所有し、“各アプリケーションを測定し、分析し、ベストプラクティスを提供することによって、アプリケーションオーナおよびエンジニアチームによるアプリケーションのレジリエンス改善を支援”するのだ。LinkedIn SREの中核をなす価値観のひとつは、“人ではなく問題を攻撃する”ことだ。これは同社の価値観である、“オーナのように行動する”と“関係性が重要”とを反映したものだ。

問題が発生した場合に、サービスオーナ個人がそれを恥じたり、あるいは攻撃的な言葉で責められることがないという認識は、問題解決のための非常にポジティブな環境を作り出します。また、これによって、SRE組織が共有インフラストラクチャを変更する上で、エンジニアリングチーム全体の意思決定プロセスに対して影響を与えやすくなります。

先般のブログ記事では、WaterbearおよびLinkedOutの活動が、開発チームとリーダシップチームから大きな支持を受けていることを述べて、その結論としている。

障害シナリオに対する仮説を検証する科学的アプローチ、障害の爆発半径を制限する能力、システムのレジリエンスを改善するための明確なアクションアイテムを導き出す能力、これらのテストを究極的な容易さで実行可能にする優れたツーリングとシステム – これらが私たちにある限り、LinkedInのすべてのチームは、レジリエンスエンジニアリングの取り組みに貢献することができるのです。

LinkedOutに関する詳細な情報は、LinkedIn Engineeringブログの他、関連するRest.li GitHubリポジトリで確認することができる。