カオスエンジニアリングのススメ

2020/6/26の「Developers.IO 2020 CONNECT」での発表資料です。

Transcript

1. 「動いてるからヨシ︕」よりも実験してみませんか︖ カオスエンジニアリングのススメ AWS事業本部 コンサルティング部 2020/06/26 Kyo
2. 3 Who am I? Kyo • AWS事業本部コンサルティング部 • ソリューションアーキテクト • 趣味はライフサイエンス
3. 4 Part 1 カオスエンジニアリング とはなんですか︖
4. 5 よくあるイメージ
5. 6 イメージ１ なんかカオス
6. 7 イメージ２ なんか壊す
7. 8 イメージ３ ランダムにインスタンスを停⽌
8. 9 何のためにそんなことするの︖
9. 10 予期しない重⼤な障害に対する 最善の防御策は頻繁に失敗することです - Netflix Tech Blog
10. 11 障害を頻繁に引き起こすことで サービスの復元⼒を強化します - Netflix Tech Blog
11. 12 カオスエンジニアリングのゴール システムの安定性と回復⼒を強化すること - Gremlin white paper
12. 13 つまり…
13. 14 カオスエンジニアリングとは • システムの安定性と回復⼒を強化する • 障害注⼊実験によりシステムの弱点をあぶり出す • 弱点を改修することで回復⼒を強化 • 弱点でなかった場合、そこには⾃信が持てる • 障害注⼊は⽬的ではなく⼿段
14. 15 カオスエンジニアリングのメリット • どんなシステムもダウンすると役割を果たせない • 安定性と回復⼒は全システムにとって重要 • ECサイトはシステムダウン = 売上低下 • ブランドイメージはプライスレス（特に⾦融系）
15. 16 よくある質問
16. 17 Q1. AWSを使っていれば システムは壊れないのでは︖
17. 18 おぼえていますか︖ 2019/08/23
18. 19 AWS東京リージョンの⼤規模障害
19. 20 ベストプラクティス「故障のための設計」 クラウドのためのアーキテクチャ設計 - ベストプラクティス (2011) - AWS re:Invent 2019 Keynote with Dr. Werner Vogels https://www.slideshare.net/kentamagawa/ss-8023416 https://youtu.be/OdzaTbaQwTg
20. 21 Q2.マイクロサービスでないと ⾏えないのでは︖
21. 22 モノリスでのカオスエンジニアリング モノリスでも多くの場合可能です。 • コンポーネント（Web, DB, Cache etc. ）は分かれている ことが多い • それぞれのコンポーネントやコンポーネント間に対して障 害テストに近い形で実施
22. 23 2000万⾏を超えたPHPアプリケーションの事例 https://speakerdeck.com/chaosconf/think-big-chaos-testing-a-monolith
23. 24 Q3. 障害テストと同じなのでは︖
24. 25 カオスエンジニアリングと障害テスト 重複はありますが、⽬指すものが異なります。 • カオスエンジニアリングはシステムに関する新しい知識を ⽣み出す • 障害テストはシステムの既知の特性についての真偽を確認 • 障害注⼊はカオスエンジニアリングの実践として、ある条 件をテストするアプローチ Chaos Engineering by Casey Rosenthal, Lorin Hochstein, Aaron Blohowiak, Nora Jones, Ali Basiri
25. 26 システムに起こる障害の分類 Unknown Known 考えつかない、 対処法は分かる Known Known 考えつく、 対処法も分かる Unknown Unknown 考えつかない、 対処法も分からない Known Unknown 考えつく、 対処法は分からない 理解 経験
26. 27 カオスエンジニアリングとテストの棲み分け Unknown Known 考えつかないが、 対処法を知っている Known Known 考えつくし、 対処法を知っている Unknown Unknown 考えつかないし、 対処法も知らない Known Unknown 考えつくが、 対処法は知らない 理解 経験 テスト カオス カオス カオス
27. 28 Part 2 カオスエンジニアリング を実践するために
28. 29 カオスエンジニアリングの原則: 基本原則 • 通常の動作を⽰すシステムの測定可能な出⼒として「定常状態」を定義することから始めます • この定常状態は、対照群および実験群の両⽅で継続すると仮定します • サーバーのクラッシュ、ハードドライブの誤作動、ネットワーク接続の切断など、現実世界のイ ベントを反映する変数を導⼊します • 対照群と実験群との間の定常状態の違いを調べることによって仮説を反証しようとします https://principlesofchaos.org/?lang=ENcontent
29. 30 カオスエンジニアリングの原則: 詳細原則 • 定常状態における振る舞いの仮説を⽴てる • 実世界の事象は多様である • 本番環境で検証を実⾏する • 継続的に実⾏する検証の⾃動化 • 影響範囲を最⼩化する
30. 31 具体的には︖
31. 32 カオスエンジニアリングのサイクル 1.定常状態の把握 2.仮説の構築 3.実験の実施 4.結果の分析 5.改善 Applying chaos engineering principles for building fault-tolerant applications より引⽤ https://speakerdeck.com/adhorn/applying-chaos-engineering-principles-for-building-fault-tolerant-applications
32. 33 定常状態の把握の前に…
33. 34 可観測性 (Observability) • 「システム運⽤上、判断に必要な情報が取得できる」状態に あること • アーキテクチャの複雑化により重要性が認識され始めた カオスエンジニアリングにおいて • 定常状態の把握に必須 • 実験においても定常状態の変化の観測に必須 https://ymotongpoo.hatenablog.com/entry/2019/03/25/084500
34. 35 1. 定常状態の把握 • 定常状態 = システムが正常に動作している状態 • システムの重要な機能に関するビジネスメトリクスに注⽬ • この値が普段と変化しなければシステムは正常 https://medium.com/netflix-techblog/sps-the-pulse-of-netflix-streaming-ae4db0e05f8a 毎秒ビデオのストリーミングを開始するユーザー数@Netflix
35. 36 1. 定常状態の把握 ビジネスサイドとの会話 • システムにどのような役割や数値を期待しているか • 関連するシステムメトリクスも洗いだす モニタリングツールによる可視化 • CloudWatch, New Relic, Datadog, etc. • メトリクスに合わせたツールを選択
36. 37 2. 仮説の構築 • 構成図等を参考に、システムに起こりうる障害を洗いだす • 障害について、注⼊によってシステムの動作は定常状態から 変化しないという仮説を⽴てる • この仮説が⽴てられない障害については、実験を⾏う前にシ ステムを改修する
37. 38 2. 仮説の構築 準備 • システム構成図 • 過去の障害記録（可能であれば） 参加者 • 開発担当 • 運⽤担当 • ビジネスサイド 成果物イメージ
38. 39 実験を⾏うにあたって…
39. 40 実験の⼤前提 影響範囲を最⼩化する
40. 41 3. 実験の実施 選択した仮説に基づき、実験⽅法をデザイン • 障害注⼊⽅法 • どこに、どのように、どのくらい、ツールは︖ • 実施⽇時 • 関係者が参加＆対応しやすい営業時間 • ⾮常時のロールバックプラン • 必要事項をドキュメントにまとめて関係者に共有
41. 42 3. 実験の実施 当⽇は安全第⼀で実験 • 開始と終了は関係者全員に通知 • 仮説に反する事態が発⽣したら、実験は即中⽌ • 事前に準備してあった⼿順でロールバック 中⽌された実験こそ最も学びを得られる （Unknownが含まれる）
42. 43 4&5. 分析と改善 実験終了後、すぐに振り返りを実施 仮説通り、定常状態は変化しなかった • そこに⾃信が持てる • アップデート等に対応するため、実験の⾃動化を検討 仮説と異なり、定常状態が変化した • どのように、なぜ、変化したかを分析 • 弱点を改修することで回復⼒を強化 • 改修後は実験で確認
43. 44 ⾝近な仮説ってなんだろう︖
44. 45 フェイルオーバー 最後に動作確認できたのはいつですか︖ AWS blog より引⽤ https://aws.amazon.com/jp/blogs/apn/making-application-failover-seamless-by-failing-over-your-private-virtual-ip-across-availability-zones/
45. 46 仮説 DBが停⽌してもフェイルオーバーにより、 定常状態は変化しない
46. 47 Part 3 カオスエンジニアリング やってみる
47. 48 Developers.IO 概要 • 「やってみた」系技術メディア • ⽉間 290万PV, 90万UU • 22,000件を超えるブログ記事 • カオスエンジニアリングに関する 記事は現在約50件 https://dev.classmethod.jp/
48. 49 「やってみた」系技術メディア
49. 50 カオスエンジニアリングを Developers.IOでやってみる
50. 51 Developers.IO アーキテクチャ https://dev.classmethod.jp/articles/renewal-devio-2020-2/
51. 52 強みを活かしたパートナーシップ ⼀緒にやってみる!
52. 53 仮説の構築 詳細はブログをご覧ください。 https://dev.classmethod.jp/articles/chaos-eng-hypothesis-backlog/
53. 54 定常状態を把握したいので、 New Relicのエージェントを導⼊しよう
54. 55 あれ…だれと調整すればいいんだっけ︖
55. 56 Developers.IO関係者 • 有志のエンジニアによって運営 • 皆、重要視するポイントが異なる ビジネス カオス インフラ アプリ
56. 57 話がまとめられない…!
57. 58 解決⽅法（︖）
58. 59 銀の弾丸はなかった… • 企画書による意識合わせ • ⽬的 • 期待される成果 • 各チームにお願いしたい事 • 検証とデータで語る
59. 60 とりあえずプルリクは出せた"
60. 61 プロダクトオーナーが必要かも
61. 62 そういえば
62. 63 組織だってシステムだ
63. 64 ということは…
64. 65 組織のカオスエンジニアリング • ⼀番複雑なのは⼈間 • 組織の弱点、特にSPoF (単⼀障害点)をあぶり出す • 障害注⼊も⾏う • 重要⼈物に発⾔させない・嘘をつかせる • メール等のレスポンスを極端に遅くする https://speakerdeck.com/chaosconf/keynote-chaos-engineering-for-people-systems
65. 66 システムの安定性と回復⼒は 普遍的なテーマ
66. 67 次回予告
67. 今後の展望 • 7⽉中にはカオス実験@DevIO の第⼀弾を発信したい︕ • 関連ツールの情報も発信して いきたい︕ • 我々と⼀緒にカオスエンジニ アリングやってみませんか︖