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

javaeestudy chaosengineering

learning.oreilly.com

javaee-study.connpass.com

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

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

次回は 8/15(土曜日)で、CapitalOne の事例から。

javaee-study.connpass.com

対象

  • 6 Microsoft Variation and Prioritization of Experiments
    • 6.3 Prioritization of Failures
    • 6.4 Degree of Variation
    • 6.5 Deploying Experiments at Scale
    • 6.6 Conclusion
  • 7 LinkedIn Being Mindful of Members
    • 7.1. Learning from Disaster
    • 7.2. Granularly Targeting Experiments
    • 7.3. Experimenting at Scale, Safely
    • 7.4. In Practice: LinkedOut
    • 7.5. Conclusion

トピック

  • 便乗してマイク買った! SHURE MV88+ VIDEO KIT
  • オーディオミキサー買った! MAONCASTER
  • エンジニアの情報発信スキルに動画制作スキルが加わる未来が来る
    • 「ブログエンジンを書く」から「いい感じの動画を公開する」へ
  • テキストと比べた動画の（発話の）難しさ
    • 滑舌や言い間違い、つっかえたり
  • Evernote から Notion へ移行した
  • Twitter の障害に巻き込まれた
  • やっぱり座椅子じゃなくてアーロンチェア買うことにした

ディスカッション

6. Microsoft Variation and Prioritization of Experiments

6.3 Prioritization of Failures

6.4 Degree of Variation

  • もしMicrosoftやAmazonやAakamaiがニュースになるような障害を起こしても顧客はそんなに気にしないかもしれません。彼らは彼らのサービスの回復のみを望むでしょう。
    • 契約を変えるか金を出すのか、どちらかの選択肢しかない
    • CDN がエッジコンピューティング機能を持つようになってきてるからいろいろと不安感が増してる気がする
  • DataDog を使うとどういうふうに依存関係を見れるようになるの
    • 分散トレーシングのメトリクスからサービスマップを生成するとかそういう感じで見れる

6.5 Deploying Experiments at Scale

  • そもそもだけど、カオスエンジニアリングに取り組む前提になっているのは、監視ができているとかそういう状態なのかな？
    • そうだと思う
    • 定常状態を定義できることが前提だから
  • メトリクスとしてログを見れる人が限定されている環境がほとんどだと思うけどそれってどうなんだという
    • それぞれのサービスのログを見れるのはサービスの担当者だけってなってる
      • 必要な情報は最近の分なら DataDog に集約して見えるようにしてる
  • 公開されてるカオス実験のレポートって見ないけどログも入ってるのかなぁ
    • 障害報告書と同じような構成になるから入ってるんじゃないかな
    • システムの内部から見た場合と外部から見た場合で求める粒度が違いそう

6.6 Conclusion

はい

7. LinkedIn Being Mindful of Members

7.1. Learning from Disaster

  • 1986 年のチェルノブイリ原子力発電所事故の事例から学びましょう
    • カオスエンジニアリングに興味を持った人は皆知っておいた方がいい事例だった
    • 実験は、ユーザーへ影響を与える可能性を最小化するため、安全第一でやらないといけない

7.2. Granularly Targeting Experiments

7.3. Experimenting at Scale, Safely

  • 連鎖障害しそうな分散システムで緊急停止ボタンはどうあるべきなんだろう
    • サーキット・ブレーカーがどうあるべきか、みたいな
    • 定常状態の定義によって変わってきそう
      • メンテナンスページ出して終わり、なんてことはない
    • 実験のために細工したことを戻すだけじゃ済まないだろう
    • リクエスト注入型なら割合を変更するだけでよさそう
    • kill -KILL で回復する状況って何
      • ツールを止めるとかそういう
      • サービスプロセスを再起動させるようなものかなと
    • 壊れたデータは取り返しがつかないような
    • 実験を中止するだけで、障害自体の復旧は別なのかもしれない

7.4. In Practice: LinkedOut

  • 他の事例だとすごいコストがかかる活動をイメージしがちだったけど、LinkedIn の事例はフレームワークやツールや自動化に触れていてイメージしやすい
    • 余剰でやる活動、というより、普通に行う活動に一体化してるのがよい
  • 実験することを念頭に設計したフレームワークで開発し、実験することを前提に利用者を考慮したツールを整備する考え方は今後大切になってくる

参考情報

いろいろ並べたけど全部は読めてない。

トピックより

ディスカッションより