【レポート】Chaos Engineering が合うもの/合わないもの – ChaosConf2019 recap –

Chaos Engineering が合うもの/合わないもの

2019年11月11日（月）に、アマゾン ウェブ サービス ジャパン株式会社主催の「ChaosConf2019 recap」が開催されました。

ChaosConf2019 recap

ChaosConf2019というのは、Chaos Engineering のサービスを展開する Gremlin 社主催のカンファレンスで、このイベントでは Chaos Engineering に取り組む多数の企業がこれまで、そして現在の取り組みについて知見や経験を披露しました。

本記事では、畑 史彦氏によるセッション「Chaos Engineering が合うもの/合わないもの」をレポートします。

登壇者

Amazon Web Services Japan K. K. 畑 史彦氏

Solutions Architect

登壇スライド

掲載可能な状態になった時に更新します

レポート

どんな業界やシステムに向いているのか、

向いている業界

• どんな業界と相性がいい？
  • ChaosConf2019登壇企業の統計から見ると、IT企業だけが活用しているわけではない
  • ECをやっている企業、小売業界と相性がいい
    • スターバックス
    • アンダーアーマー
    • Backcountry

なぜECとの相性が良いのか？というと、以下の項目が当てはまるからと言われていました。

• 可用性が事業の収益に直接的に影響する
• 比較的ボラティリティの低い事業モデル
  • ボラティリティ: 銘柄の価格変動の大きさを示す変動率です。 価格の変動幅が大きいほどボラティリティが高く、変動幅が小さいほどボラティリティが低くなります。
• サービスがx時間ダウンすると、y円の機会損失

• ECではないですが、UberもChaos Engineeringを行なっています

  • 彼らは uDestroyという独自のツールを使っているとのこと
    • NetflixのChaos Monkeyをインスパイア
    • 1000を超えるマイクロサービス群、オンプレミスもある
• あと、意外に多いのが金融業界
  • ChaosConfの会場でGremlinの人と話してわかった
  • 銀行などの金融機関も入れば、FinTechと呼ばれるハイテク金融プレイヤーも入る
  • 事例は表に出て来にくい

マイクロサービス or モノリス

マイクロサービス：

• 個々のサービス間でFailureの影響を分離しやすい
• Chaos Experimentの実施の調整においても、小さい粒度のチームになりがちなので、文化を根ずかせることがやりやすい
• サービス間をまたがったアプリケーションレイヤでのFailure Contextの伝播(レイテンシを増加させるとか)などの仕組みを試みるなら、全体としての統制は必要となる

モノリス:

• 2000万行を超えたPHPアプリケーションの事例もあります
  • モノリスといっても、コンポーネントは分かれている(Web, DB, Cacheなど)
• コンポーネント間に対して行う。障害試験に近いやり方で実施できる

Server-based or Serverless

• コンピューティングの進化
  • 物理マシン、仮想マシン、コンテナ、serverless(AWS Lambdaのような)　というように、時代は流れて来ている。
• Server-based
  • インフラレイヤへの直接的なFailureのinjectionが可能
    • シャットダウン
    • レイテンシを増加させる
  • アプリケーションレイヤーでのFailureも可能
• Serverless
  • インフラレイヤへの直接的な操作が困難
    • ただ、それはインフラレイヤを意識する必要がないから
    • そもそもそのようなChaos Experimentが必要ないとも言える
  • 必然的にアプリケーションレイヤでのInjectionの仕組みが必要になる
• より精緻なマイクロサービスレベルでの障害注入を行うため、Netflixは FIT: Failure Injection Testingという手法も用いるようになった
  • (Chaos Monkey)インフラレイヤを直接扱うシャットダウンやレイテンシの増加の障害注入はワイルドすぎる時があり、開発者に噛み付いてしまう
    • 影響範囲が大きい
    • 作用範囲を特定の何かに限定しづらい
  • (FIT) 例えばあるUAのクライアント端末だけに障害を注入する、テストフラグのあるユーザー通信においてのみ遅延させるなどのアプリケーションレイヤで情報を伝搬させ、アプリケーションレイヤの情報を解釈する
    • 狙ったポイントで極めて限定した範囲に対して行う

Cloud or オンプレ

• オンプレミスでのChaos Experiment事例はほぼ見当たらない
• そもそも、NetflixがオンプレからAWSに移行した際に猿の軍団を開発、利用したことを詳細に公表したのがChaos Engineeringの大きなターニングポイントであった。

• Netflix名言(畑さんが好きな言葉)

  • 障害(failure)を避ける最も良い方法は、継続的に障害を起こ(fail)させること
• AWSのChaos Experimentに活用できるAPIの紹介
  • EC2
    • Stop, Reboot, Kernel Panic
  • ElastiCache
    • Stop, Reboot
  • ECS
    • Stop Task
  • RDS(mysql)
    • Reboot, Failover
  • RDS(Aurora)
    • Reboot, Failover, Fault Injection Queries
  • Network
    • Switch Security Group, Network ACL Allow/Deny

Production or Non Production

PRINCIPLES OF CHAOS ENGINEERINGでは、

本番環境でやることが大切だと定義されている

が、

dev環境や検証環境,GameDayから始める方が良い。

• トラブルが起きた時しかトラブルシュートしなくて、いざトラブルが起こった時にスムーズに対応できるでしょうか？
• 本番と同様の環境で、異常事態の対応を訓練

AWS GameDayに参加しよう!!の流れ -> 上手でした。

まとめ

• Chaos Engineering、理念や考え方はすでに確立されている。歴史も長くベストプラクティスの知見や事例も豊富
• 近い思想はごく身近にもある: 障害試験
  • 導入している企業の特徴として、それぞれやりやすいところや自社のシステムにあった箇所から手をつけて拡張している
• これから取り組む方は、開発環境やGameDayからやってみてはどうだろう

感想

事例を踏まえた向いている向いていない、現在のChaos Engineeringの流れがどうなって来ているのか、導入を考えている人たちはどこから始めればいいのか　といったことがわかりとても為になるセッションでした。

そしてAWS GameDayに参加するといいですよの流れがお上手でした。

Chaos Engineeringといえば本番環境に行うもの　といった狂気じみた考えが最初に出て来がちだったのですが、自分たちの持っているシステム特性にあった箇所から試してみることが良い　と認識できました。 まずは障害試験の延長線上にあるものとして導入を提案していけるように行動を起こしたい。

ではでは