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

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

カオスからレジリエンスへ

• マニュアルカオスから自動レジリエンスの旅
  • 手動負荷テスト
  • 終わらないGameDay
  • エンジニアリングブランチを追加
  • 完全に自動化された内部カオス製品を構築
  • コミュニティ

負荷試験

• サービスは現実的なテストを処理できるか
  • 主は正常系のテスト
  • 本番を想定した動作に重点を置く

性能テスト

• 負荷が性能に影響するか
  • レイテンシ
  • エラー
  • スループット

ストレステスト

• いつ、どこに障害ポイントが現れるか
  • システムの破壊を目的とする
  • 本番の動作ではない

カオステスト

• サービスが根本的な障害をどのように処理するか？
  • データセンターのダウン
  • 依存関係の失敗
  • ネットワークの輻輳
  • CPUまたはメモリの上限

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

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

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

• GameDayを実行するためのコントロールプレーン
• 負荷生成器を制御する機能
• スマートなスケジューリングと自動実行

レジリエンスプロダクトスイート

• 予測
• 弾性実験
• レポーティング、分析
• 実際のトラッフィクとGameDay
• 負荷可視化

障害注入テスト（適合）ユースケース

• 問題：ダウンストリームの依存関係の調整と制限の調整
• 解決策：Fast-Fail Circuit Breakerを実装
• 適合テスト：適合を使用して、依存関係の調整と制限の調整をシミュレートします
• 結果：サーキットブレーカのパフォーマンス、再試行、および遅延の影響の測定

insights

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

自動ポートフォリオ

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

まとめ

• とくていの目標から始める
• 最初のステップが最も重要です。 プログラムに焦点を当てます。
• レジリエンスはカオスよりも大きく、未知のものに備えます。
• 顧客について学習し続け、学習と顧客の間にフィードバックループを作成します。
• カオスは楽しい！ 今日から旅を始めましょう。

さいごに

カオスエンジニアリングを行う上での考え方がよくわかるセッションでした。どなたかの参考になれば幸いです。