[レポート] カオスエンジニアリングによるレジリエンスの向上 #DOP309 #reinvent

AWS re:Invent 2019

#AWS

森田桂介

2019.12.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

「DOP309 Improving resiliency with chaos engineering」についてレポートします。

セッション情報

スピーカー

Adrian Hornsby - Principal Evangelist, Amazon Web Services
Olga Hall - Senior Manager, Tech Program Management

セッション概要

Failures are inevitable. Regardless of the engineering efforts put into building resilient systems and handling edge cases, sometimes a case beyond our reach turns a benign failure into a catastrophic one. Therefore, we should test and continuously improve our system’s resilience to failures to minimize impact on a user’s experience. Chaos engineering is one of the best ways to achieve that. In this session, you learn how Amazon Prime Video has implemented chaos engineering into its regular testing methods, helping it achieve increased resiliency.

失敗は避けられません。復元力のあるシステムの構築とエッジケースの処理に費やされたエンジニアリングの努力に関係なく、時には、手の届かないケースが良性の障害を壊滅的な障害に変えることがあります。したがって、システムの障害に対する回復力をテストし、継続的に改善して、ユーザーエクスペリエンスへの影響を最小限に抑える必要があります。カオスエンジニアリングは、それを達成するための最良の方法の1つです。このセッションでは、Amazon Prime Videoが通常のテスト方法にカオスエンジニアリングを実装し、弾力性を高める方法を学習します。

レポート

"Simian Army to keep our cloud safe, secure, and highly available." 2011 Netflix blog

猿の軍団がクラウドを安全、安全、高可用性に維持します。 2011 Netflix blog

スケジュールされたエージェントのセット

ランダムなサービスシャットダウン
パフォーマンスの低下
適合性の確認
リージョン全体を壊す
spinnaker(CI/CD)と統合

カオスエンジニアリングとは

Netflixによって形式化された (mid-2015)
Principles of Chaos Engineering
カオスエンジニアリングは目的なしにランダムに破壊することではない
カオスエンジニアリングとは、制御された環境で物事を破壊し、十分に計画された実験を通して、さまざまな条件に耐えるためのアプリケーションの信頼性を構築すること

障害となる部分

ソフトウェア
- 証明書の期限切れ
- メモリーリーク
- ライセンス
- バージョン
インフラストラクチャ
- Redundancy (Multi-AZ)
- Self-healing
- Isolation (bulkheads)
- Infrastructure as Code
アプリケーション
- タイムアウト
- リトライ
- 例外ハンドリング
- サーキットブレーカー
- Load shedding
運用
- 人による運用
- モニタリングとobservability
- インシデントへの応答
- 計測、計測、計測

カオスエンジニアリングのフェーズ: STEADY STATE(定常状態)

定常状態とは？
- システムの「通常の」動作
- システムの内部のことではない (CPU、メモリ、その他)
- カスタマーエクスペリエンスと結びついた運用上のメトリックは、最高の結果をもたらす
- 緩和されていない障害が予期しない問題を引き起こした場合、定常状態は変化し、カオス実験は中止されます

カオスエンジニアリングのフェーズ: HYPOTHESIS (仮設)

何かがおきたら...
- ロードバランサーに障害が発生したら？
- Redisが遅くなったら？
- Cassandraのホストが停止したら？
- レイテンシが300msになったら？
- データベースが停止したら？

カオスエンジニアリングのフェーズ: RUN EXPERIMENT (実験を行う)

障害の注入
- 小さく始めて自身をつける
  - アプリケーションレベル (例外、エラー、etc)
  - ホストレベル (サービス、プロセス、etc)
  - リソースアタック (CPU、メモリ、etc)
  - ネットワークアタック (依存関係、レイテンシ、パケットロス、etc)
  - AZアタック
  - リージョンアタック
  - 人々アタック
実験を行う上での注意事項
- 緊急停止または適切なロールバックが必要
- ロールバックできない状態に注意する(破損または不正なデータが発生しないようにする)

カオスエンジニアリングのフェーズ: VERIFY (確認)

実験結果の定量化
- 検出時間
- 通知、エスカレーションまでの時間
- 情報公開までの時間
- グレースフル・デグラデーションが始まるまでの時間
- 自己修復までの時間
- 部分的または完全なリカバリまでの時間
- 安定するまでの時間
分析 - COE (correction of errors)
- 何が起こったのか
- ビジネスや顧客にとってどのような影響があったのか
- 原因は何か
- 分析するためのデータは何か (メトリクスやグラフ)
- 何を学んだか
- どのような是正措置をとっているか
2つのルールを覚えておく
- 間違いで人を責めない
- 孤立した原因はない

カオスエンジニアリングのフェーズ: IMPROVE (改善)

監査と検査
- 毎週の運用指標のレビュー
  - 継続した検査の仕組み
  - 業務に集中する
  - 健全な運用プログラムの基盤
- 典型的な議題
  - サクセスストーリー
  - すべきことのフォローアップ
  - COEのレビュー
  - 主要なサービスメトリクスのレビュー

カオスエンジニアリングの大きな課題

カオスエンジニアリングでは、システムの堅牢性は向上しない。人が向上させる
カオスエンジニアリングは残りのすべて(テスト、品質、etc)を置き換えるものではありません
ロールバックは難しい
それでもシステムは障害を起こす
始めることが難しい
文化
- 障害をシミュレートする時間がない
- チームに時間がない
- 非常に政治的になりやすい
- 深い議論が必要
- 特定の技術ロードマップに深く投資し、カオスエンジニアリングテストは当初の予測よりも障害に対して回復力がない