Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
カオスエンジニアリングのススメ
Search
KyoheiSaiki
June 26, 2020
Programming
1
1.6k
カオスエンジニアリングのススメ
2020/6/26の「Developers.IO 2020 CONNECT」での発表資料です。
KyoheiSaiki
June 26, 2020
Tweet
Share
More Decks by KyoheiSaiki
See All by KyoheiSaiki
Grafana OnCallによる通知
kyo1024
0
170
New Relic と Classmethod で実践するカオスエンジニアリング
kyo1024
0
2.5k
ANGEL_Dojo_最終発表_問題とミニブログで技術を学ぶ_エンジニア向け学習サービス_Loop_I_O.pdf
kyo1024
0
2.6k
問題とミニブログで技術を学ぶ エンジニア向け学習サービス Loop I/O
kyo1024
0
7k
カオスエンジニアリングへの招待
kyo1024
1
1.7k
Other Decks in Programming
See All in Programming
PipeCDのプラグイン化で目指すところ
warashi
1
210
20250628_非エンジニアがバイブコーディングしてみた
ponponmikankan
0
520
明示と暗黙 ー PHPとGoの インターフェイスの違いを知る
shimabox
2
380
PHPでWebSocketサーバーを実装しよう2025
kubotak
0
230
NPOでのDevinの活用
codeforeveryone
0
460
地方に住むエンジニアの残酷な現実とキャリア論
ichimichi
5
1.4k
Blazing Fast UI Development with Compose Hot Reload (droidcon New York 2025)
zsmb
1
260
Discover Metal 4
rei315
2
100
deno-redisの紹介とJSRパッケージの運用について (toranoana.deno #21)
uki00a
0
160
Composerが「依存解決」のためにどんな工夫をしているか #phpcon
o0h
PRO
1
240
Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール? 〜
yodakeisuke
0
120
なぜ「共通化」を考え、失敗を繰り返すのか
rinchoku
1
600
Featured
See All Featured
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
Bash Introduction
62gerente
614
210k
Thoughts on Productivity
jonyablonski
69
4.7k
Music & Morning Musume
bryan
46
6.6k
Practical Orchestrator
shlominoach
188
11k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
490
Become a Pro
speakerdeck
PRO
28
5.4k
Designing Experiences People Love
moore
142
24k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
BBQ
matthewcrist
89
9.7k
Transcript
「動いてるからヨシ︕」よりも実験してみませんか︖ カオスエンジニアリングのススメ AWS事業本部 コンサルティング部 2020/06/26 Kyo
3 Who am I? Kyo • AWS事業本部コンサルティング部 • ソリューションアーキテクト •
趣味はライフサイエンス
4 Part 1 カオスエンジニアリング とはなんですか︖
5 よくあるイメージ
6 イメージ1 なんかカオス
7 イメージ2 なんか壊す
8 イメージ3 ランダムにインスタンスを停⽌
9 何のためにそんなことするの︖
10 予期しない重⼤な障害に対する 最善の防御策は頻繁に失敗することです - Netflix Tech Blog
11 障害を頻繁に引き起こすことで サービスの復元⼒を強化します - Netflix Tech Blog
12 カオスエンジニアリングのゴール システムの安定性と回復⼒を強化すること - Gremlin white paper
13 つまり…
14 カオスエンジニアリングとは • システムの安定性と回復⼒を強化する • 障害注⼊実験によりシステムの弱点をあぶり出す • 弱点を改修することで回復⼒を強化 • 弱点でなかった場合、そこには⾃信が持てる
• 障害注⼊は⽬的ではなく⼿段
15 カオスエンジニアリングのメリット • どんなシステムもダウンすると役割を果たせない • 安定性と回復⼒は全システムにとって重要 • ECサイトはシステムダウン = 売上低下
• ブランドイメージはプライスレス(特に⾦融系)
16 よくある質問
17 Q1. AWSを使っていれば システムは壊れないのでは︖
18 おぼえていますか︖ 2019/08/23
19 AWS東京リージョンの⼤規模障害
20 ベストプラクティス「故障のための設計」 クラウドのためのアーキテクチャ設計 - ベストプラクティス (2011) - AWS re:Invent 2019
Keynote with Dr. Werner Vogels https://www.slideshare.net/kentamagawa/ss-8023416 https://youtu.be/OdzaTbaQwTg
21 Q2.マイクロサービスでないと ⾏えないのでは︖
22 モノリスでのカオスエンジニアリング モノリスでも多くの場合可能です。 • コンポーネント(Web, DB, Cache etc. )は分かれている ことが多い
• それぞれのコンポーネントやコンポーネント間に対して障 害テストに近い形で実施
23 2000万⾏を超えたPHPアプリケーションの事例 https://speakerdeck.com/chaosconf/think-big-chaos-testing-a-monolith
24 Q3. 障害テストと同じなのでは︖
25 カオスエンジニアリングと障害テスト 重複はありますが、⽬指すものが異なります。 • カオスエンジニアリングはシステムに関する新しい知識を ⽣み出す • 障害テストはシステムの既知の特性についての真偽を確認 • 障害注⼊はカオスエンジニアリングの実践として、ある条
件をテストするアプローチ Chaos Engineering by Casey Rosenthal, Lorin Hochstein, Aaron Blohowiak, Nora Jones, Ali Basiri
26 システムに起こる障害の分類 Unknown Known 考えつかない、 対処法は分かる Known Known 考えつく、 対処法も分かる
Unknown Unknown 考えつかない、 対処法も分からない Known Unknown 考えつく、 対処法は分からない 理解 経験
27 カオスエンジニアリングとテストの棲み分け Unknown Known 考えつかないが、 対処法を知っている Known Known 考えつくし、 対処法を知っている
Unknown Unknown 考えつかないし、 対処法も知らない Known Unknown 考えつくが、 対処法は知らない 理解 経験 テスト カオス カオス カオス
28 Part 2 カオスエンジニアリング を実践するために
29 カオスエンジニアリングの原則: 基本原則 • 通常の動作を⽰すシステムの測定可能な出⼒として「定常状態」を定義することから始めます • この定常状態は、対照群および実験群の両⽅で継続すると仮定します • サーバーのクラッシュ、ハードドライブの誤作動、ネットワーク接続の切断など、現実世界のイ ベントを反映する変数を導⼊します
• 対照群と実験群との間の定常状態の違いを調べることによって仮説を反証しようとします https://principlesofchaos.org/?lang=ENcontent
30 カオスエンジニアリングの原則: 詳細原則 • 定常状態における振る舞いの仮説を⽴てる • 実世界の事象は多様である • 本番環境で検証を実⾏する •
継続的に実⾏する検証の⾃動化 • 影響範囲を最⼩化する
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
33 定常状態の把握の前に…
34 可観測性 (Observability) • 「システム運⽤上、判断に必要な情報が取得できる」状態に あること • アーキテクチャの複雑化により重要性が認識され始めた カオスエンジニアリングにおいて •
定常状態の把握に必須 • 実験においても定常状態の変化の観測に必須 https://ymotongpoo.hatenablog.com/entry/2019/03/25/084500
35 1. 定常状態の把握 • 定常状態 = システムが正常に動作している状態 • システムの重要な機能に関するビジネスメトリクスに注⽬ •
この値が普段と変化しなければシステムは正常 https://medium.com/netflix-techblog/sps-the-pulse-of-netflix-streaming-ae4db0e05f8a 毎秒ビデオのストリーミングを開始するユーザー数@Netflix
36 1. 定常状態の把握 ビジネスサイドとの会話 • システムにどのような役割や数値を期待しているか • 関連するシステムメトリクスも洗いだす モニタリングツールによる可視化 •
CloudWatch, New Relic, Datadog, etc. • メトリクスに合わせたツールを選択
37 2. 仮説の構築 • 構成図等を参考に、システムに起こりうる障害を洗いだす • 障害について、注⼊によってシステムの動作は定常状態から 変化しないという仮説を⽴てる • この仮説が⽴てられない障害については、実験を⾏う前にシ
ステムを改修する
38 2. 仮説の構築 準備 • システム構成図 • 過去の障害記録(可能であれば) 参加者 •
開発担当 • 運⽤担当 • ビジネスサイド 成果物イメージ
39 実験を⾏うにあたって…
40 実験の⼤前提 影響範囲を最⼩化する
41 3. 実験の実施 選択した仮説に基づき、実験⽅法をデザイン • 障害注⼊⽅法 • どこに、どのように、どのくらい、ツールは︖ • 実施⽇時
• 関係者が参加&対応しやすい営業時間 • ⾮常時のロールバックプラン • 必要事項をドキュメントにまとめて関係者に共有
42 3. 実験の実施 当⽇は安全第⼀で実験 • 開始と終了は関係者全員に通知 • 仮説に反する事態が発⽣したら、実験は即中⽌ • 事前に準備してあった⼿順でロールバック
中⽌された実験こそ最も学びを得られる (Unknownが含まれる)
43 4&5. 分析と改善 実験終了後、すぐに振り返りを実施 仮説通り、定常状態は変化しなかった • そこに⾃信が持てる • アップデート等に対応するため、実験の⾃動化を検討 仮説と異なり、定常状態が変化した
• どのように、なぜ、変化したかを分析 • 弱点を改修することで回復⼒を強化 • 改修後は実験で確認
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/
46 仮説 DBが停⽌してもフェイルオーバーにより、 定常状態は変化しない
47 Part 3 カオスエンジニアリング やってみる
48 Developers.IO 概要 • 「やってみた」系技術メディア • ⽉間 290万PV, 90万UU •
22,000件を超えるブログ記事 • カオスエンジニアリングに関する 記事は現在約50件 https://dev.classmethod.jp/
49 「やってみた」系技術メディア
50 カオスエンジニアリングを Developers.IOでやってみる
51 Developers.IO アーキテクチャ https://dev.classmethod.jp/articles/renewal-devio-2020-2/
52 強みを活かしたパートナーシップ ⼀緒にやってみる!
53 仮説の構築 詳細はブログをご覧ください。 https://dev.classmethod.jp/articles/chaos-eng-hypothesis-backlog/
54 定常状態を把握したいので、 New Relicのエージェントを導⼊しよう
55 あれ…だれと調整すればいいんだっけ︖
56 Developers.IO関係者 • 有志のエンジニアによって運営 • 皆、重要視するポイントが異なる ビジネス カオス インフラ アプリ
57 話がまとめられない…!
58 解決⽅法(︖)
59 銀の弾丸はなかった… • 企画書による意識合わせ • ⽬的 • 期待される成果 • 各チームにお願いしたい事
• 検証とデータで語る
60 とりあえずプルリクは出せた"
61 プロダクトオーナーが必要かも
62 そういえば
63 組織だってシステムだ
64 ということは…
65 組織のカオスエンジニアリング • ⼀番複雑なのは⼈間 • 組織の弱点、特にSPoF (単⼀障害点)をあぶり出す • 障害注⼊も⾏う •
重要⼈物に発⾔させない・嘘をつかせる • メール等のレスポンスを極端に遅くする https://speakerdeck.com/chaosconf/keynote-chaos-engineering-for-people-systems
66 システムの安定性と回復⼒は 普遍的なテーマ
67 次回予告
今後の展望 • 7⽉中にはカオス実験@DevIO の第⼀弾を発信したい︕ • 関連ツールの情報も発信して いきたい︕ • 我々と⼀緒にカオスエンジニ アリングやってみませんか︖
None