NetflixやAmazonでカオスエンジニアリングを実践し、カオスエンジニアリングの第一人者であるGremlin社のCEOから情報がつまったカオスエンジニアリング概要が聞けました。
富士通の事例は、Gremlinを使って、モノリスの古いシステムをお試し環境でやってみた事例。モノリスでも効果があるとのこと。
ドワンゴの事例は、本番環境で実施した事例。メトリクスをしっかり検討していて、すばらしい第一歩のカオスエンジニアリング報告でした。
講演1-1:「カオスエンジニアリング概要」Kolton Andrus(Gremlin, Inc.)
当日流れた動画
---
カオスエンジニアリングはコラボレーティブに行うもので、むやみに打ちまくるものではない。
カオスエンジニアリングという名前は、やんちゃな印象の「カオス」と洗練された印象の「エンジニアリング」が組み合わせっている。
なぜ今なのか。今は昔と違って、様々なソフトウェアに依存し、内部でマイクロサービスと連携し、外部SaaSと連携し、完全にコントロールできない。障害を予測するのは天気の予測と似ている。予測が難しい。ただ、天気と違って、ソフトウェアは実験ができる。
カオスエンジニアリングを実施するプロセスをGameDayとよんでいる。第一ステップは全員を集めること。ホワイトボードにアーキテクチャーを書く。エクサザイズの１つとして、ネットワークのあるところをみて、障害が起きたらと考える。こんな風に、異常がおきそうなところをリストアップする。
2013年のNetflixの１日の停止は非常に損害の大きい障害。稀にしか起きないが損害の大きい障害とのバランスも考慮したい。
カオスエンジニアリングに開発が必要ならやらないと言われたら、ダウンタイムでどのくらいの損害があるか考えさせる。
進め方。１つめは、関係者全員とのコミュニケーション。コマンドセンターが用意されるのが望ましい。Slackでもよい。ダッシュボードでメトリクスをみる。
基本的に本番環境からははじめない。開発環境、ステージング環境、シングルコンテナから始める。そして、測定する。中止の条件も定義する。カスタマーに被害を与えない。
実験の成果は予想していなかったこと。よく調査し、修正する。うまくできたら実験をスケールする。自信を持てたら広げる。スモールスタートでスケールさせていく。システムが正しく設定され、正しく動作することを確認することが重要。
午前２時にやるのではなくて、日中にやる。カオスをおこしても影響がないように。休みの前に上司に大丈夫かと聞かれたら自信を持ってYESと答えられるように。
講演1-2:「Gremlinご紹介」Matt Fornaciari(Gremlin, Inc.)
- Gremlinは３つのコアでちょっとしたパラダイム変化をおこした。
- Safety
- Security
- Simplicity
- ３つのコマンドでインストールできる。
- ２番目のステップはsyscheckコマンド。
- ３番目のステップはクライアントの登録。
講演1-3:「SREcon Americas 最新動向報告」Tammy Butow(Gremlin, Inc.)
- SREコン2018のトレンド。k8s & コンテナ、カオスエンジニアリング、SREチームの育成など６つ。
- カオスエンジニアリング・ブートキャンプは250人くらい参加。その中で経験者は３人。
- SLOはSREの重要なコンセプト。詳細はGoogle SRE本で。
- SREコンの内容はWebサイトからみれる。
- カオスエンジニアリングのslackコミュニティがある。
- はじめてのカオス・コンが９月にサンフランシスコで開始される。
講演2:「ProjectWEBでのカオスエンジニアリング実践」延川 隆(富士通株式会社)
- 1998年から続いている富士通のサービスProjectWEB。古いが利用者は多い。
- システム構成はクラウドへの完全移行の過渡期で、オンプレとクラウドのハイブリッド
- クラウド移行と信頼性を両立させるため、カオスエンジニアリングに注目
- 原則で注目すべきは、本番環境で実施と影響を最小限にするということ
- といっても、開発環境からはじめて、成熟してから本番環境へ
- 海外では、金融機関などでも実施
- 見える化、優先順位づけ、仮説立て、実施、測定、学習と改善 のループをまわす
- プラクティス
- チーム横断コミュニケーション
- スモールスタート
- ポストモーテム
- ツール
- コマンドセンター
- ダッシュボード
- 中止の条件を明確にしておくことが重要
- マイクロサービスでは、サービス同士の接合点が増える。ここでカオスエンジニアリングが有効
- モノリスでやって意味があるの？と思いつつ実施するはめに
- とりあえず、簡単な環境を用意してGremlinを使ってみた
- 簡単
- できることも多い
- DBにレイテンシを起こすアタックのデモ
- Gremlin使うと簡単にはじめられる
- やってみると面白い！でも、本番環境ではそうはいかないだろう
- メンバーは新規と古参とどちらもいるとよい。お互いに補完できるから。
- 新規はシステムの勘所がわからない、あるべき姿を提言しやすい
- 古参はシステムの勘所がわかる、敬意を知りすぎているので、課題を課題と感じない
- ただし、対立の構図にならないように注意
- 次は冗長構成をつくって試した
- GameDayのテンプレートを使った
- 準備万端でGameDayに臨む
- 環境の準備が大変。本番と違うので、動作が違うので、確認作業に時間がかかる。同時に、本番環境でやりたいと自然に思い、成熟度モデルは必然だと感じた
- モノリスだから用意に制御できると考えるのは過信で、モノリスでも意味がある
- 一目でわかるモニタリングは必須。技術のない人でもわかるレベルに
- ミラーリングシステムで不整合が発生した場合の復旧作業が煩雑であることが判明
- 煩雑な職人技こそ自動化する意義が大きい
- 今後は、Docker環境でやりたい
- まとめ
- 分散システムでなくても効果がある
- 必要なものは実施環境とモニタリング
講演3:「The Road to Chaos - Great First Step」本間 正大(株式会社ドワンゴ)
- ドワンゴのシステム障害との戦い
- SPFをつくらない、冗長構成に
- マスターが落ちたり、再起動で同期が切れたり
- テスト環境で障害テスト
- 冗長構成では防げない問題がある、より洗練された障害テストが必要
- そこでカオスエンジニアリングと出会った
- 実践の４ステップ
- 定常状態を定義
- 障害を発生させても定常状態は変わらないという仮説を立てる
- 障害を発生させる
- 仮説を反証する
- 定常状態とは正常稼働している状態
- メトリクス
- システムメトリクス
- ビジネスメトリクス
- 定常状態を定義するのに重要な特徴
- カスタマの満足度と強い相関
- リアルタイム性が高い
- 計測が簡単
- Netflixでは動画再生回数をメトリクスに、先週の波形を定常状態に
- ５つの原則
- 定常状態の振る舞いに仮説を立てる
- 多様なイベントを取り入れる
- 本番環境で実験
- 継続的実行のため自動化する
- 爆発半径を最小限にする
- ドワンゴジェイピー、楽曲配信サービスで実践
- SLA: 99.95%
- 年商: 約70億
- 機会損失率 x 単位営業実績 + 工数 = カオスコスト
- カオスコストを教育費として承認をもらった
- メトリクス
- コンテンツのDL数：3つの特徴全てOK
- システムの稼働率：3つの特徴全てOK
- Apdex Score：3つの特徴全てOK
- レスポンスタイムやエラーを考慮してユーザー満足度を測る指標
- コンテンツデリバリーシステムのWebサーバを対象に
- メインクラスタが96%、コントロールクラスタ2%、エクスペリエンスクラスタ（カオスを起こすクラスタ）2%でトラフィックをわける => 爆発半径の最小化
- コントロールクラスタと比較する
- 仮説
- Chaos Lambda: AWSのEC2インスタンスを停止するツール
- EC2の突然死を選んだ理由
- よく発生する
- 実験が簡単
- ツールがすでにある
- 予想&制御しやすい
- 障害を発生させる
- 前準備 => 実験実施 => 実験終了
- 前準備
- メトリクス選定の仕組みを実装
- コントロール/エクスペリメントクラスタの作成
- R53でトラフィックを制御
- 実験実施
- 12:00 - 18:00に30分感覚で実施
- 既存監視のアラートがあがったら強制終了
- メトリクスの逸脱は目視
- 実験終了
- 準備の逆
- 仮説を反証する
- コンテンツのDL数：障害がなくても定常状態が一致せず、定常状態に使えず
- システムの稼働率：障害による変化なかった
- Apdex Score：障害がなくても定常状態が一致せず、定常状態に使えず
- ドワンゴジェーピーのコンテツデリバリーシステムはEC2の突然死に強い
- 得られた知見
- 物分かりのよいマネージャーが必要
- コストのコンセンサス
- 組織的なやりとりや文化づくりが重要
- 安全な実験の責任を持つ
- R53の設定でサービスに影響がでてしまった
- 実験環境セットアップの自動化が必要
- 正常に実験できていることを確認できる機構が必要
- 緊急停止の自動化が必要
- 実施前に実験手法の妥当性を確認すべき
- R53のトラフィック分散は１日単位ではよいが、30分ではばらつく
- 本番環境でやるべき
- テスト環境とは差異がある
- トラフィックが違う
- 今後の課題
- トラフィックのルーティング方法の見直し
- イベント選定とツールの再検討
- 実験の自動化
- セットアップ
- 緊急停止
