Chaos Engineeringメモ
Posted on 2018-10-31
今さらながらChaos Engineeringについて勉強した。
背景
最近Chaos Engineeringという単語を日本語の記事でもよく見かけるようになったので、概要だけでも知っておこうと思い、勉強してみることにした。
今回読んだのはこの論文である。
ポイントだと理解したところ
- Chaos Engineeringとは、分散システムにおいて実世界での可用性や耐障害性を測るための方法
- CPUロードなどマイクロな指標ではなく、ユーザーから見たときのシステムを表す指標を計測する
- 本番環境で試験する
以下は個人的なメモで内容は保証しない。そこまで難しい内容を書いているわけではないので、ちゃんと勉強したい人は原文を読むとよいと思う。
Chaos Engineeringとは
Chaos Engineering
- 定義: Chaos Engineeringは分散システムにおいて可用性や耐障害性を確認するために試験を行っていく訓練である
- 障害はハードウェア障害から予期せぬ大量アクセス、悪意ある攻撃も含む
- AmazonやGoogle, Microsoft、Facebookといった大きな企業が似たような手法を取っていることに気づいた
- この手法にChaos Engineeringと名前をつけた
Chaos Monkey
- Netflixですでに数年間運用中
- production環境のvirtual machineをランダムに選び、停止する
- エンジニアに障害に強いソフトウェアサービスをデザインすることを奨励する
- エンジニアがすぐに対応できる営業時間内だけ起動している。
Chaos Kong
- Amazon EC2のリージョン1つが全て落ちた場合を想定してエラーをおこす
システム全体で見る
- Chaos Engineeringの真髄はたくさんのサービスをひとつのシステムとして見ることにある
- 実世界からシステムへの入力を理解し、システム境界において何がおきているのかを理解するのに役立つ
- 古典的なアプローチでは、 y=f(x) というように関数でシステムをあらわす
- 分散システムでは古典的なアプローチでは不十分
- ユーザーのスケールの大きさや複雑さ
- システム全体をひとつのサービスとみなし、典型的なユーザーフローを計測する必要がある
- steady-state(定常状態) behavior
Chaos Engineeringの原則
- Chaos Enginneringは試験を中心にまわる。試験の設計には以下の要素が必要
- hypotheses (仮説)
- indendent variables (独立変数)
- dependent varibles (従属変数)
- context
- Chaos Engineeringの4つの原則
- steady state behaviorについての仮説をたてる
- 実世界で起こりうることで試験する
- 本番で試験する
- 継続的に試験するために自動化する
1. steady state behaviorについての仮説をたてる
- Netflixではレコメンドやブックマークなどたくさんの機能がある
- システム内部的にはフォールバックの機能がある
- たとえばキャッシュ用のサーバーAがコンテンツサーバーBの前段にあり、Aに障害がおきた場合はBに直接リクエストがくるようになる
- Netflixではシステム全体が「ちゃんと動いているか」の指標として「SPS」を使っている
- (Stream) starts per second
- 毎秒どのくらいのユーザーが動画を見始めたか
- SPSはsteady state behaviorのよい指標になる
- 他にも毎秒どのくらいのユーザーがサインアップしたか、も計測している
- Chaos Engineeringの試験の前に、試験がSPSにどの程度のインパクトを与えるかの仮説をたてる
- たとえば、Netflixが使っている複数リージョンのうちの一つがおちてもフォールバックがうまくはたらけば、SPSの変動はごく軽微だろう、という感じ
- CPU loadなどの粒度の細かい指標ももちろん採っているが、最終的にSPSが変わらない=ユーザーへの影響がないことがChaos Engineeringの目的になる
2. 実世界で起こりうることで試験する
- happy path: エラーやコーナーケースをひきおこさないプログラムの実行順序(正常系のスモークテスト)
- エンジニアが開発するときはhappy pathに注力しがち
- 実世界では想定してなかったコーナーケースがおこる
- ユーザーが悪意のあるリクエストをおくってきたり
- ディスクがいっぱいになったり
- メモリが枯渇したり etc…
- 最近の研究で、92%の壊滅的なシステム障害は、元は致命的ではないエラーのとりまわしが不適切だったことによって引き起こされている
- 実世界で起こりうることで試験することが必要
- 例えば、前回の障害自のログなどを参考に、試験でどういうinputがを与えるかを設計する
- ポストモーテムも参考になる
- Netflixでの例
- virutal macineのインスタンスの停止
- サービス間のリクエストのレイテンシーの増大
- サービス間のリクエストの失敗
- 内部サービスの障害
- Amazonのリージョンの利用不可
- Netflixではハードウェアやソフトウェアの障害を重点的に試験しているが、他のinputも考えられる
- リクエスト数の増大
- ランタイムのパラメータの変更
- システム全体で使用されるメタデータの変更
- 実際に実現させるのが難しい障害もある
- 実際にAWSのリージョンをおとすことはできない
- リアリズムとのトレードオフとなるが、仮想的に障害を発生させることもある
- ユーザーへの影響を制限するため、ユーザーのサブセットについて試験を行う
3. 本番で試験する
- 分散システムにおいては古典的なソフトウェアテストのアプローチでは不十分
- サービス間の連携によって引き起されるような問題は検知できない
- キャッシュサーバーにエラーがキャッシュされ、バックエンドのサーバが復活しても以前としてエラーが返ってしまう、など
- 試験の再現性のため、本番環境で試験する
4. 継続的に試験するために自動化する
- Netflixでは日々新機能が追加されている
- 何度も継続的に試験を行うために、自動化は必須
- Chaos Monkeyを平日に毎日、Chaos Kongを月に1回まわしている
Chaos試験の運用
- 上記原則をもとに、試験を定義する
- steady state(定常状態)を定義する。システムの通常の状態を計測可能にする
- コントロール群と実験群で同じsteady stateとなることを仮説としてたてる
- サーバーのクラッシュやハードドライブの故障、ネットワーク接続の不通などの実世界のイベントを発生させる
- コントロール群と実験群でsteady stateの違いがないことを確認する
