【レポート】 カオスエンジニアリングによる回復力の向上 #DOP309-R #reinvent

こんにちは。AWS事業本部のKyoです。

セッション「Improving resiliency with chaos engineering (DOP309-R) 」についてレポートします。

概要

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.

登壇者

Adrian Hornsby - Principal Evangelist, Amazon Web Services

Olga Hall - Senior Manager, Tech Program Management

Adrian Hornsby

Rise of the monkeys

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

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

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

• 目的のないランダムな破壊ではない
• コントロールされた環境において、アプリに自信をつけるためのよくプランされた実験

Chaosのためのいくつかの前提条件

ソフトウェア

• メモリーリーク
• ライセンス
• バージョニング

インフラ

• 冗長性（multi-AZ)
• セルフヒーリング
• 分離
• Infrastructure as code(IaC)

アプリケーション

• タイムアウト
• バックオフ付きの再試行
• エクセプションハンドリング
• サーキットブレイカー
• 負荷制限

オペレーション

• 人間によるオペレーション
• モニタリングと観測性
• インシデント対応
• 計測！！！

実はこれら、Well-Architedで言ってる事。

カオスエンジニアリングの段階

• 定常状態
• 仮説
• 実験
• 確認
• 改善
• （定常状態へ）

定常状態とは？

• ノーマルな状態
• システムの内部属性ではない（CPU, メモリ etc.)
• ベストな顧客体験に紐づいたメトリクス

「what if」 - 仮に

• 仮にこのロードバランサが壊れたら？
• 仮にRedisが遅くなったら？
• 仮にCassandraのホストがなくなったら？
• 仮にレイテンシが300ms増加したら？
• 仮にデータベースが停止したら？

みんなの問題にする！

障害の注入

小さく始めて自信をつける

• アプリケーションレベル（exception、エラー etc.)
• ホストレベル（サービス、プロセス etc.)
• リソース攻撃（CPU, Memory, IO etc.)
• ネットワーク攻撃（依存性、レイテンシ、パケットロス etc.)
• AZ攻撃
• リージョン攻撃
• 人的攻撃

経験則

• 緊急停止または適切なロールバック戦略がある
  • ロールバックできない状態(破損または不正データ）には要注意

実験結果の定量化

• 検出時間
• 通知時間、エスカレーション時間
• パブリックへの通知時間
• graceful degradation が始まるまでの時間
  • graceful degradation: システム（またはプログラム）において、グレードを落とさざるを得ない場合に、劣化を最小限に抑えられるように、大きな支障を来しにくい代替手段（fallback）を用意するという意味で用いられる表現
• セルフヒーリングまでの時間
• 部分もしくは全体がリカバリーするまでの時間
• 全てがクリアされ、安定するまでの時間

postmortem-COE (correction of errors)

※ postmortem: 〈ラテン語〉で、「死後の、事後の」

• 何が起こったか
• 顧客および自分たちのビジネスへのインパクトは？
• なぜ起こったのか？（トヨタ式でwhyを5回。）
• どのデータがこれをサポートするか（主にメトリクスとグラフ）
• 何を学んだか
• あなたが取れた正しいアクションは？

Blast radius （爆炎半径）

• どのくらいの顧客？
• どのような機能
• どのくらいのロケーション？

監査と検査

毎週の運用メトリクスのレビュー

• 継続的な検査メカニズム
• オペレーションに集中
• 健全な運営プログラムの基盤

典型的な議題

• サクセスストーリー
• アクションアイテムのフォローアップ
• COE(correction of errors)のレビュー
• キーサービスメトリクスのレビュー

カオスエンジニアリングへのチャレンジ

• Chaosそのものがシステムのロバスト性を高めるのではない。人がやる
• Chaosはテストや品質を置き換えるものではない
• ステートによってロールバックが困難になる
• 開始は難しい

文化面

• 障害をシュミレートする時間や柔軟性がない
• チームはすでにすべての時間を物事の修正に費やしている
• 非常に政治的なことができる
• 深い会話を強制するかもしれない
• 当初の予測ほど障害に対する回復力がないという技術ロードマップに深く投資した

Olga Hall - カオスからレジリエンスへ

我々のジャーニー

• マニュアルテスト
• Gameday
• ブランチの追加
• インターナルなカオスプロダクトの構築
• 全自動スケーリング
• コミュニティ

Evergreen programs

• 可用性
• スケーリング
• レジリエンス
• 高速なイベント
• 覚悟
• パフォーマンス

Program structure

• 中央エンジニアチーム
• インフラのTPMチーム
• インフラ効率と最適化
• SPOCに各チームがオプトイン

ライブストリーミングは高いバー

顧客は以下の際にハッピー

• ストリームに障害が起こらない（100%起こらないこと。99.9%ではダメ）
• ブロードキャストと同じかそれ以上のパフォーマンス
• 楽しめるクオリティのビデオ（UHD, HDR, HFR)
• 顧客体験は直感的

障害（または不明）を処理する準備は機能ゼロ

Resilence framework

Load testing: サービスは予想される現実的な負荷を処理できるか

• もっともポジティブなテスト
• 製品の動作を重視

Perfomance testing: 負荷はパフォーマンスをどのように変えるか

• レイテンシ
• エラー
• スループット

Stress testing: いつどこでブレイクポイントが見えるか

• システムの壊れを強調

Chaos testing: サービスはどのように障害を処理するか

• データセンタ-のダウン
• 依存関係の失敗
• ネットワークが遅い
• CPU or メモリを使い切った

実践のために

プラットフォーム全体の自動Gameday

• ターゲットの持続をテストする能力
• 停止中に発生したトラフィックセグメントを再生する
• 意図的に障害を引き起こし、システムが期待どおりに動作したかどうかを判断する
• アラームと構成を確認する
• 新しいサービスまたは新しい機能の運用準備のレビューを検証する

パフォーマンスを測定するためのツール

• Gamedayを実行するためのコントロールプレーン
• 任意の数の負荷ジェネレーターを制御する機能
• スマートなスケジューリングとハンドオフ実行

resilience product suite

• 予測
• Resilience 実験
• レポートと分析
• 実際のトラフィック vs Gameday

ユースケース

• 問題：可溶性の低下による下流の依存性のスロットリング
• ソリューション：fast-failサーキットブレーカーの実装
• テスト：依存関係の調整をシミュレートし、スロットリングを調整する
• 結果: サーキットブレーカーのパフォーマンス、リトライとレイテンシのインパクトの測定

Insights

1. 単一のプラットフォームではなくツールセットが必要
2. ユースケースに最適なものを選ぶ

Automation portfolio

• 予測
• 障害注入
• レポートと学び
• 実験レポジトリ
• サービスディスカバリー/レポジトリ

重要なポイント

• 特定の目標から始める
• 最初のステップがもっとも重要。プログラマティクな焦点を維持
• レジリエンスはカオスよりも大きく、未知のものに備える
• 顧客について学習し続け、あなたの学びと顧客のフィードバックループを作る
• Chaosは楽しい！今日からジャーニーをスタート！

おわりに

詳細が含まれており、とても参考になりました。Gameday、企画してみたいですね。

以上、何かのお役に立てれば幸いです。