第3回 Chaos Engieering 読書会@リモートのログ

learning.oreilly.com

javaee-study.connpass.com

引き続き Discord によるオンライン開催。

合計 300 ページくらいのところを毎回 30 ページくらい進んでるので、全部で 10 回くらいになるのかなぁ。

次回は 7/18(土曜日)です。

javaee-study.connpass.com

対象

  • 4. Slack’s Disasterpiece TheaterGetting Management Buy-in から

トピック

ディスカッション

4. Slack’s Disasterpiece Theater

Getting Management Buy-in

Impossibility Result

  • 設定変更を司るサービスを停止しても本体機能には何も影響しないと期待していた
  • 実際は本体機能の設定変更 API をつついたら応答が返ってこなかった
  • 本体は設定変更ができないときはエマージェンシーモードで動くようになっていたけど、通常モードのときと同じく Slack Channel に投稿して何かを待機する状態になっていた
  • ということで設定の不整合があるのは残念な結果だった、ということかなと

そのほか

  • この文章書いたの誰だっけ

  • 結構前から仕事でも Slack 使ってるけどときどき意味不明なエラーが起きることがあった

    • もしかして実験してたのかな
    • 人によって問題に対する感度が違うような気もする

5. Google DiRT: Disaster Recovery Testing

LEGENDS: テックリードが休暇に入るとコード検索が途切れる

  • あるあるすぎて辛い

The Rules of Engagement

What to Test

  • 項目の粒度がばらばらなのが気になる
  • 分散サービスだとバックアップからのリストアがとてもややこしい問題になりそう
  • Kafka のバックアップについて
    • 伝統的には別々の SAN を用意するんだけどできない
    • バックアップクラスタを用意するのが無難
  • 結果整合性に基づくシステムではどこにバックアップの断面を設定することになるのか
    • サーガしてるならその辺でどうにかする
    • Event Sourcing してるならメッセージングブローカーでどうにかする
  • 孤立したそれぞれのリージョナルネットワークで発生したトランザクションを同期するのは難しそう
    • それぞれの水準でどこまで何を保証するのか設計しないといけないね

How to Test

  • かなり影響を気にしながらやっているんだなという雰囲気

全体

  • この水準の取り組みができる会社はそれなりにあると思った派と、この水準の取り組みができてるのが恐ろしいと思った派の会話
  • lottery factorトラックナンバーバスファクター より配慮されたフレーズだなと思った
    • 流行って欲しい

Scope of Tests at Google / Conclusion

  • Borg のケーススタディで言いたいこと

    • ユーザーはタスクがエビクションされないことに慣れきっている
    • それでは信頼性のあるタスクを開発できない
    • 強制的にエビクションする実験をすればどういうふうに対応したらいいか学んでくれるはずだ
  • 嫌なことを頑張る印象があったけど、前向きに取り組むような記述に感動した

Microsoft Variation and Prioritization of Experiments

  • Varying real-world events in Chaos Engineering is exactly what we’re concerned about here. の解釈
  • カオスエンジニアリングでは多様な現実世界の事象こそが,ここでの私たちの関心事です。 のほうが妥当かなと

参考: カオス原則

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

カオス変数は実世界の事象を反映します。潜在的な影響または推定頻度のいずれかで事象の優先順位付けを行います。サーバーが落ちているようなハードウェア障害、不正な応答のようなソフトウェア障害、トラフィックやスケーリングイベントの急増など障害ではない事象に対応する事象を考えましょう。定常状態を破壊することができる事象は、カオス実験において潜在的な変数となります。

参考情報