アプリケーションエンジニアがChaos Engineeringに調べたまとめと得られた知見

マイクロサービスを作っていく上で調べたChaos Engineeringについて、自分の理解や考えについてまとめ、アプリケーションエンジニアだけでChaos Engineeringの恩恵を得られるためにはどうしたら良いかについて書きたいと思います。


なぜ必要か

ここは僕の理解では、分散システムを不安定にしかねない外的要因、例えばネットワークや、他の依存するミドルウェア(Database、メッセージキューなど)であったり、外部サービス(Github APIなど)、社内のマイクロサービス(ユーザー管理サービスなど)などがダウンもしくはレスポンスが遅くなるなどした際、システム全体にどういった影響が出るか、またそれを利用するユーザーにどういった影響が出るか、について確認をするためのものだと思っています。

ここで重要なのはこの「不安定にしかねない外的要因」にもレベルがあることだと思っています。

1. ある外的要因が発生することを想定し対策しており、何が起きるか知っている

2. ある外的要因が発生することを想定し対策しているが、何が起きるか自信が持てない

3. ある外的要因が発生することを想定しておらず、何が起きるかわからない

高頻度で発生する場合は「1」に、稀にしか発生しないものに関しては「2」や「3」になると思います。

この「2」や「3」について継続的に問題をあえて発生させることで「1」と同じ状態に持っていき、システムを安定な状態に持っていくのがChaos Engineeringが必要な理由だと思っています。

また別の側面としては、ある障害が起こったとき、その再発防止策としてはアプリケーションレイヤーの問題であれば、コードを書く際に注意することであったり、レビュー時に注意する、といった人に依存する形になりがちだと思っています。それを人に依存しない形で再発防止をする、といったことが可能になる方法だと思っています。


何をすべきか

カオスエンジニアリングの原則を見てみると次のように書かれています。


  • 定常状態における振る舞いの仮説を立てる

  • 実世界の事象は多様である

  • 本番環境で検証を実行する

  • 継続的に実行する検証の自動化

  • 影響範囲を局所化する

それぞれ例を踏まえて僕の理解を説明します。


定常状態における振る舞いの仮説を立てる

まず定常状態については難しいと思っています。これはマイクロサービスなどの定常状態ではなく、システム全体の安定性を指していると思っています。

なので、Netflixから出されたChaos Engineeringによると、Netflixでは「ユーザーが動画を見つけ、それを再生できること」としており、そのための指標としてSPS(1秒間の動画再生数)を採用しており、その変化がないことを定常状態としています。

まずはこういった値を決めることで、影響がユーザーに出ているか・出ていないかの判断ができます。

原文


Ultimately, what we care about is: "Are users able to find some content to watch, and

successfully watch that content?" We operationalize this concept by observing how many users

start streaming a video each second. We call this metric SPS, for (stream) starts per second [9].

We use SPS as our primary indicator of the overall health of the system. While the term “chaos”

evokes a sense of unpredictability, one of the fundamental assumptions of Chaos Engineering is

that complex systems exhibit behaviors that are regular enough that they can be predicted.

Similarly, the SPS metric varies slowly and predictably over the course of a day, as shown in

Figure 2. Engineers at Netflix spend so much time looking at SPS that they have developed an

intuition about whether a given fluctuation is within the standard range of variation or whether it

is cause for concern. If engineers observe an unexpected change in SPS, we know there is a

problem with the system.



実世界の事象は多様である

実世界の事象は、例えばハードディスクの故障や、あるマイクロサービスのダウンや遅延などです。

これらは多種多様で、全てを網羅することはできないと考えています。

システムに影響を与える実世界の事象には2つ種類があると思います。

1. 自分の管理できるもので発生する事象

2. 管理できないもので発生する事象(例: GCPやAWSなどのサービス)

例えば、「1」であれば比較的簡単に事象を再現できると思います。

問題なのは「2」で、さらに言えば管理外のものへの接続がライブラリなどで行われているケースです。

これに関しては結局接続はhttpやgRPCなどで行われているはずなので、そこにProxyを噛ませ、不安定にさせることが重要だと思います。

また、別の問題として想定していなかった問題については発生させることができないことです。

これについては仕方がないので、発生してからその対応として、発生させるべき事象にするべきだと思っています。


本番環境で検証を実行する

これはQAなどで行う検証というのは、リクエストの順番やパターンなどある程度想定している事象でしかテストができないです。

また、QA環境は本番環境の性質(例: DNSの設定、クライアントの挙動など)を完璧に再現するのは困難なので、本番環境のほうが好ましいです。

ただ、僕個人の意見として、QAでもある程度の再現はできるはずなので、ある一定の安定性の確認という意味では本番環境である必要は必ずしもないのではないかと思っています。


継続的に実行する検証の自動化

これはそもそも検証を人手でやることはトイルにあたりますし、漏れや不測の事態を引き起こしかねないので自動化する必要があります。

継続的に行う必要としては今日大丈夫だったとしても、1ヶ月後、2ヶ月後と日を追うごとに「ある外的要因が発生することを想定し対策しているが、何が起きるか自信が持てない」状態になってしまうのを避けるために必要です。


影響範囲を局所化する

これは全世界に影響を出すのではなく、例えば国や特定のユーザーなど影響が出る人数を最小限にしたり、問題が起こった際検証を即座に終了させること重要だと思っています。

また、少し意味合いは違いますがFault Injectionを行いテストをする際、Linkedinでは本物のユーザーではないService Accountを使いテストしています https://engineering.linkedin.com/blog/2018/05/linkedout--a-request-level-failure-injection-framework


アプリケーションエンジニアだけで行えることは何か

先程の5つの原則のうち、アプリケーションエンジニアに強く関係することは


  • 定常状態における振る舞いの仮説を立てる

  • 実世界の事象は多様である

の2つだと思っています。

定常状態に関しては、アプリケーションエンジニアが一番詳しく、また、それに紐づくサービスなども知っているはずだと思います。

また、実世界の事象についても、ある一定以上、例えばあるサービスがダウンしたらどうなるか、などについて知っているはずです。

この2つを組み合わせ、例えばFault InjectionをQAなどである程度確認はできると思います。

そうすることで分散システム上の自分の開発する部分や、それを利用するサービスに対してある一定の安定性を出すことができると考えています。

※ただし、これは推奨をしているわけではなくアプリケーションエンジニアだけでもしもやるとしたら、という話です


参考URL