【AWS Dev Day Tokyo 2019 セッションレポート】 Chaos Engineering 〜入門と実例〜

AWS Dev Day Tokyo 2019 のセッション Chaos Engineering 〜入門と実例〜 に関してのレポートです。

登壇者

株式会社Cygames

和田 明久 様

アマゾン ウェブ サービス ジャパン株式会社

畑 史彦 様

セッション概要

Chaos Engineering と聞くと皆さんは何を思い浮かべますか? Netflix 社の Chaos Monkey による VM のシャットダウンなどが有名かもしれませんが、これは Chaos Engineering のかなり初期から存在するツールの1つでしかありません。現在はそこからエコシステムが拡大し、インフラストラクチャ・レイヤではなくアプリケーション・レイヤで注入し故障をより精緻に制御する方法論やサービスメッシュ・レイヤへオフロードする仕組みなど、多様な発展を見せています。このセッションでは、これら Chaos Engineering の歴史やエコシステムを整理しご紹介するとともに、株式会社 Cygames の和田氏に、実際にオンラインゲーム開発の現場で Chaos Engineering を実践してきた事例と、AWS サービスを活用した Chaos Engineering への今後の取り組みについてお話いただきます。

前半パート ~ カオスエンジニアリングの進化と今

  • AutoScaling

    アプリをモニタリングしリソース量を自動で調整する機能

    実際にインスタンスを安心して停止できますか?

    -> 自信があっても怖いよね

    だったら本番環境でテストしよう これが幅広く実践されるようになってきている

    これがカオスエンジニアリング

カオスエンジニアリングの歴史

  • 2010.12.14

    Netflixのブログ: AWSのクラウドを選択した4つの理由

  • 2010.12.16

    Netflixのブログ: AWSを使って学んだ5つのレッスン

    そのうちの1つ、 障害を避ける最も良い方法は継続的に障害を起こさせること

    カオスモンキー(インスタンスをランダムに停止) というシステムを構築

    故障しても正常に機能する能力を常にテストしないと、最も重要な時、予期しない機能停止が発生した場合に機能する可能性が低くなる -> オートスケールが設定されていれば自動で復旧できる

  • 2011.06: 猿(モンキー)の仲間が増える

    The Netflix Simian Army

  • 2014.10: FIT Microservicesレベルでの障害注入

    FIT: Failure Injection Testing

    Request Contextというメタデータ情報を伝播させることで、ダウンストリームのコンポーネントなどの狙い澄ましたポイントに障害をおこさせる

    猿たちとFITの違い

    いくつかの猿は、設計上ワイルドすぎる。インスタンスを落としたり、レイテンシを追加する など

    • 猿: インフラレイヤを直接的に扱う(インスタンスを落とす、ネットワーク遅延を追加)

      作用範囲を特定の何かに限定しづらい

      影響範囲を小さくしづらい

    • FIT: アプリケーションレイヤで情報を伝搬させ、アプリケーションレイヤの情報を判断(狙った範囲に限定的に)

      特定のUAのクライアントだけに障害を注入する。

      テストフラグのあるユーザー通信のみDBアクセスを遅延させる

  • 2015.09: カオスエンジニアリングの5原則、リージョンの停止をシミュレートするKong

    Principles of Chaos Engineering

    「対象とするシステムが本番環境における不安定な状況に耐えることができる」という自信を構築するために該当システムにおいて実施する実験の規律

    エンジニアリングとして立て付けを作る。業界全体でやっているんだということを示す

    • システム全体を反映しビジネスのコアを表現するシンプルな指標を定める

      Netflixの場合はSPS(Start Per Second): 動画の再生開始ボタンを押された回数。これは定常的なはず。

    • 本番環境で実行する

    • 自動化されていないとつらい
  • 2017.07: ChAP 自動化と他ツールとの連携

    ChAP (Chaos Automation Platform)

    chap-chaos-automation-platform

    CI/CDと統合する(Spinnakerと連携している)

    • テストが想定以上の影響を与えた場合、やっぱり自動的に検知して停止させたい
  • 2019.05: 実施の自動化と作成の自動化

  • 2020.06: 書籍出版予定

前半パート まとめ

  • クラウドではサーバの故障率をさげることはできない
  • Netflixはカオスエンジニアリングのイノベーター

    他の多数の組織で同様の取り組みはあった

    AWS Gameday とか  

  • Gremlin, OSS toolも登場している

    • ChaosToolkit
    • Awesome Chaos Engineering
    • Serverless
    • aws-lambda-chaos-injection

基本的な設計も重要

最低限の可用性設計ができていることが好ましい、特に本番で望むならね

後半パート

  • Chaosconfの紹介

    登壇企業の統計を見てみると、 IT業界に限らない、マイクロサービスに限らない

  • サイゲームズでの取り組み

  • なぜやるのか?

    システムは壊れる

    色々な要素が引き金となる

    障害は不可避(AWSでも大規模な障害はどこかしら発生)

内部でも

  • ほぼ毎日何かが起きている

  • 運用作業の低減

  • 障害により影響を与えるもの

    • 機会、時間、顧客、ブランド信頼

これらを回避したい

  • アプローチのしかた

principlesをベースとした4step - chaos loop

-- step1: 定常状態

システムのふるまいを示す指標を用いて定常状態を定義

-- step2: 仮説構築

実験グループで継続する仮説を構築

-- step3: 故障発生

実際に起きうるイベントをシステムに負荷

  • インスタンス停止
  • ネットワーク遮断
  • CPU Usage 100%

    手法

  • AWS API

  • Linuxコマンド(stressなど

-- step4: 仮説反証

通常と実験グループのシステム出力を振り返り反証をあげる

  • 事例紹介
    • ElastiCache Reboot
      • 障害の種を事前に発見、対策まで出来た1例
    • 詳細はCygamesテックブログを
  • Next Action
    • よりアグレッシブに実験をするために
      • プロダクションでの実施
      • オートメーション
      • 影響の最小化
  • 影響の最小化を深掘り
    • 時短、トラフィックコントロール、VM>コンテナ>APp
  • トラコンに着目
    • canary deploymentを応用
  • 安全のメカニズム
    • ビジネスアワーに制限
    • 異常なインパクトを検知したら自動停止
    • 実験トラフィックのサワー等は全体の5%未満
    • failover
  • AWSでトラフィックを制御するには
    • Route53
    • Lambda
    • AppMesh
    • ALB
    • 本番で実施するためには必須
      • ユーザにクリティカルなインパクトを与えない

安全に行う土台がAWSにはある

感想

カオスエンジニアリングという言葉は聞いたことあるけど、中身はイマイチ といった人にもよくわかる内容だったと思います。

障害を避ける最も良い方法は継続的に障害を起こさせること

これを本番環境で実施するというかなり挑戦的な手法です。最低限の可用性を用意するといった準備を行った上でやらないとビジネスに重大な影響を及ぼしますものね。

SaaSやToolも出てきているので、開発環境などで試すといったことから始めても良いかと思います。

私個人、GremlinというSaaSを試してブログを書いています。ご興味のある方は是非読んで、実行してみてくれると幸いです。