この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
本記事はAWS re:Invent 2019のセッション「Improving resiliency with chaos engineering」のレポートです。
概要
日本語訳
失敗は避けられません。回復力のあるシステムの構築とエッジケースの処理に費やされたエンジニアリングの努力に関係なく、時には、手の届かないケースが良性の失敗を壊滅的なものに変えることがあります。したがって、ユーザーのエクスペリエンスへの影響を最小限に抑えるために、システムの障害に対する回復力をテストし、継続的に改善する必要があります。カオスエンジニアリングは、それを達成するための最良の方法の1つです。このセッションでは、Amazon Prime Videoがどのように通常のテスト方法にカオスエンジニアリングを実装し、弾力性の向上に役立つかを学びます。
原文
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
レポート
AmazonでのGameDay
消防士は訓練に膨大な時間を費やしている。プロの消防士は、本番（火事現場）に行く前に数千時間の訓練をしなければ火が消せないという研究がある。
2000年
ジェシー・ロビンス（元ボランティア消防士）がAmazon.comに雇われた。Amazon.comが所有するウェブサイトの可用性を担当。 消防士のアイデアを持ち込み、システムが本番昇格する前に障害を訓練し、本番環境で復旧できるようにしたいと望んだ。
2004年
信頼性を高めるために、意図的に障害を発生させる「GameDay」を作成。 データセンターへランダムに行き、サーバーの取り外し等を行い、障害回復の練習を行った。
（chaos）monkeysの台頭
2010年ー11年
Netflixがインフラストラクチャ全体をAWSに移行。 マイクロサービスアーキテクチャを採用し、システムが回復力があることを望みchaos monkeysを作り始めた。
- サービスをランダムにシャットダウン
- パフォーマンスをシャットダウン
- 適合性を確認
- リージョン全体を壊す
- Spinnakerと統合
2015年
Netflixがカオスエンジニアリングと呼ばれている分野を策定。
障害に備えてトレーニングする必要がないように、カオスエンジニアリングを実施。実稼働環境で問題が発生する前にすべてをテストする非常に良い方法。
カオスエンジニアリングのいくつかの前提条件
本番環境で最も多く発生する停止の原因。
- ソフトウェア
- 証明書の有効期限
- メモリーリーク
- ライセンス
- バージョニング
- アプリケーション
- バックオフ付きの再試行
- 例外処理
- サーキットブレーカー
- 負荷制限
- インフラ
- 冗長性（multi-AZ)
- セルフヒーリング
- 分離
- Infrastructure as code
- オペレーション
- 人間のオペレーター
- 監視と可観測性
- インシデント対応
- 測定、測定、測定
カオスエンジニアリングを行いたい場合は、何が起きているのかを監視する必要がある。回復力に自信をもつためのベースラインが必要。AWS Well-Architected、Amazon Builders' Libraryが参考になる。
カオスエンジニアリングのフェーズ
カオスエンジニアリングには、以下のサイクルがある。
- 定常状態（STEADY STATE）
- 仮説（HYPOTHESIS）
- 実験(RUN EXPERIMENT)
- 確認（VERIFY）
- 改善（IMPROVE）
定常状態
- システムの「正常」な動作
- amazon.comを例にすると、注文数を指標にするなど
- 実験を行う時に正常な状態であることの確認が必要なため、定常状態を知ることが重要
- CPU、メモリ等のシステムの内部属性ではない
- カスタマーエクスペリエンスと結びついた運用上のメトリクスが最良の結果をもたらす
仮説
- 仮にこのロードバランサが壊れたら？
- 仮にRedisが遅くなったら？
- 仮にCassandraのホストがなくなったら？
- 仮にレイテンシが300ms増加したら？
- 仮にデータベースが停止したら？
ロードバランサー配下のインスタンスにCPU攻撃を実行し、意図した通りスケールするか確認することもひとつではあるが、CPU攻撃のような単純な実験を行う場合は組み合わせが必要。小さな問題ひとつでシステム停止が発生することはあまりない。
実験
通常カオスエンジニアリングでは、障害の注入を実行して実験を行う。
- アプリケーションレベル
- 例外またはエラーを生成しキャッチするかどうか確認
- ホストレベル（サービス、プロセス..)
- リソース攻撃（CPU、メモリ..)
- ネットワーク攻撃（依存性、レイテンシ、パケットロス..)
- AZ攻撃
- リージョン攻撃
- 人的攻撃
- 必ずしもソフトウェア攻撃ではなく、文化攻撃など人々は非常に興味深いものを攻撃する
重要なのは、なんらかの破損によって実稼働環境が停止してしまわないように、実験の停止またはロールバックする方法を考えておくこと。
確認
事後分析を行う必要があるので、できるだけ多くのデータを取得しておくことが重要。
- 検出時間
- 通知時間、エスカレーション時間
- パブリックへの通知時間
- 劣化始まるまでの時間
- セルフヒーリングまでの時間
- 部分、全体がリカバリーするまでの時間
- 全てがクリアされ、安定するまでの時間
事後修正につなげるために、以下を掘り下げて確認する。
- 何が起こったか？
- 顧客、ビジネスにどのような影響があったのか？
- 原因は何か？
- サポートするにはどのようなデータが必要か？
- どのような教訓を学んだか？
- どのような是正措置を取ったか？
覚えておくべき2つのルール
- 間違いで人を責めるな
- 事故に孤立した「原因」はない
改善
- 毎週の運用メトリクスのレビュー
- 継続的な検査メカニズム
- オペレーションに集中
- 健全な運用プログラムの基盤
- 典型的なアジェンダ
- 成功事例
- アクションアイテムのフォローアップ
- エラーの修正ののレビュー
- 主要なメトリクスのレビュー
カオスエンジニアリングへのチャレンジ
- カオスエンジニアリングでは、システムの堅牢性は向上しない
- カオスエンジニアリングはテストや品質を置き換えるものではない
- ステートによってロールバックが困難になる
- 開始は難しい
私たちの旅（レジリエンスエンジニアリングチームのジャーニー）
手動から自動化された回復まで
- 手動負荷テスト
- GameDay
- ブランチを追加
- 内部カオス製品を構築
- 自動化されたスケーリング
- コミュニティ
- 必然的に組織、業界内にコミュニティが形成される
- さらに良い技術を生み出すことについて話し始めるエンジニア
よく設計されたフレームワークのラインに沿ってプログラムを作成。各チームには情熱的な人がおり、目標を達成した。長年にわたってライブストリーミングが非常に難しく、ライブストリーミングの水準が非常に高いことを学んだ。
ライブストリーミングは高いハードル
顧客は次の場合に満足する。
- ストリーミングに障害が起こらないこと（not 99.9%）
- ブロードキャストと同じかそれ以上のパフォーマンス
- 楽しめるクオリティのビデオ（UHD、HDR、HFR)
- 顧客体験は直感的
最初に顧客を理解する。その後、カオスツールキットを作成する。
Resilence framework
負荷テスト／予想される現実的な負荷を処理できるか
- もっともポジティブなテスト
- 製品の動作を重視
パフォーマンステスト／負荷はパフォーマンスをどのように変るか
- レイテンシ
- エラー
- スループット
テストを行うと、許容できるものを特定するのに役立つ。
ストレステスト／いつどこでブレークポイントが表示されるか
- システムの破壊を重視
最初はベータ版とテスト環境で行うことがオススメだが、これも実稼働環境で実行が必要。
カオステスト／サービスは根本的な障害をどのように処理するか
- データセンター停止
- 依存関係の失敗
- ネットワーク遅延
- CPU、メモリ枯渇
ツールキット（使用しているツールの紹介）
プラットフォーム全体で自動化されたGameday
- 特定のターゲットを維持する能力をテスト
- 停止中に発生したトラフィックセグメントを再生
- 意図的に障害を引き起こし、システムが期待どおりに動作したか判断
- アラームと構成を確認
- 新しいサービスまたは新しい機能の検証
パフォーマンスを測定するためのツール
- Gamedayを実行するためのコントロールプレーン
- 多数の負荷ジェネレーター
- スマートスケジューリングとハンドオフ実行
追加の製品を作成
- 予測
- 回復力の実験
- レポートと分析
- 実際のトラフィック vs Gameday
- 荷重表現
重要なことは、仮説があり検証を行うこと。
重要なポイント
- 特定の目標から始める
- 最初のステップが最も重要（焦点を保つ）
- レジリエンスはカオスよりも大きく、未知のものに備える
- 顧客について学習し続け、学習と顧客の間にフィードバックループを作る
- カオスは楽しい、今日から旅を始めよう
さいごに
「Improving resiliency with chaos engineering」のセッション概要でした。既に動画も公開されていますので、詳しく知りたい方は直接確認してみてください。
7
