[レポート] サーバーレスの世界でカオスエンジニアリングを実行する #CMY301 #reinvent

CX事業本部の佐藤です。

AWS re:Invent 2019 セッション「Performing chaos engineering in a serverless world」のレポートです。

セッション概要

The principles of chaos engineering have been battle-tested for years using traditional infrastructure and containerized microservices. But how do they work with serverless functions and managed services? In this session, we cover the motivations behind chaos engineering, how we perform chaos experiments, and what some of the common weaknesses are that we can test for in our serverless applications. We also run some actual experiments in a serverless AWS environment. Join us as we move from talking about principles to performing real chaos-engineering experiments for serverless.

カオスエンジニアリングの原則は、従来のインフラストラクチャとコンテナ化されたマイクロサービスを使用して、長年にわたってテストされてきました。 しかし、サーバーレス機能やマネージドサービスとどのように連携するのでしょうか？ このセッションでは、カオスエンジニアリングの背後にある動機、カオスエンジニアリングの実行方法、サーバーレスアプリケーションでテストできる一般的な弱点について説明します。 また、サーバーレスAWS環境でいくつかの実際の実験を実行します。 原則の話から、サーバーレス向けの実際のカオスエンジニアリング実験の実施に移りましょう。

レポート

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

• カオスエンジニアリングとは、システムに失敗（障害）を注入し、どのような振る舞いになるか実験を行うこと
• システムに失敗を注入後、システムの弱点を見つけ、それらが壊れる前に修正する
• システム及び組織の信頼性を向上させる

カオスエンジニアリングを行う動機

・Are your customers getting the experience they should?

・Is downtime or issues costing you money?

・Are you confident in your monitoring and alerting?

・Is Your organization ready to handle outages?

・Are you learning from incidents?

Everything fails, all the time！ Amazon CTO Werner Vogels

カオスエンジニアリングを行う動機としては、そもそもすべてのシステムは常に失敗（障害）が起こる想定でいなければならないという前提。監視とアラートだけで本当に良いのか（運用に自信があるのか）、顧客の障害の経験を得る、停電の場合どのように対処するのか、インシデントから学ぶことができるなど数多くのメリットがある。

カオスエンジニアリングの実行方法

ステップ1 正常状態の定義

• 時間の経過に伴うシステムの通常の振る舞い
• システムメトリックとビジネスメトリック
• ビジネスメトリックが有用である
• 通常状態は必ずしも連続的であるとは限らない

ステップ2 仮説を立てる

• 障害はスタックのどのレイヤーにも注入できます
• 既知の問題を常に最初に修正する

ステップ3 計画と実行実験

• ホワイトボードに実験の詳細を書く
• Blast radius
• 組織に通知する
• システムを停止させる

ステップ4 測定と学習

• メトリックを使用して仮説を証明または反証する
• 注入された障害に対して回復力のあるシステムか
• 予期しないことが起こるか
• 進捗と成功を共有する

ステップ5 スケールアップまたは修正

• 学習して改善する
• 自信を持ってスケールアップできます
• スコープの拡大により新しい効果が明らかになる可能性があります

カオスエンジニアリングにおけるサーバーレス

サーバーレスにより、サーバーについて考えることなくアプリケーションとサービスを構築および実行できます。サーバーについて考えることなくというのが重要です。

• 管理するサーバーはありません
• より少ない重荷
• 選ぶべきたくさんのサービス
• 機能ごとおよびサービス構成

カオスエンジニアリングはサーバーレスに最適です

サーバーレスの世界でカオスエンジニアリングを実行する

一般的なサーバーレスにおける、障害を注入する部分

• エラー処理
• タイムアウト値
• イベント
• フォールバック
• フェイルオーバー

• コードにエラーを挿入する
• ダウンストリームサービスを削除する
• 関数の並行性を変更する

• セキュリティポリシーエラー
• CORS構成エラー
• サービス構成エラー
• 機能ディスク容量の障害

• 関数にレイテンシーを追加する
• コールドスタート
• クラウドプロバイダーの問題
• ランタイムまたはコードの問題
• 統合の問題
• タイムアウト

デモ

AWSのサーバーレスでのカオスエンジニアリングのデモがセッション中にありました。以下のURLで公開されているので誰でもサーバーレスのカオスエンジニアリングを体験できます。

https://demo.serverlesschaos.com/

• 関数が呼び出しごとに余分に300ミリ秒かかる場合はどうなりますか？
• 関数がエラーコードを返すとどうなりますか？
• コードに例外がある場合はどうなりますか？

まとめ

• まとめすべてが常に失敗する
• サーバーレスでは、アプリケーションに回復力がありません
• カオスエンジニアリングは、弱点を見つけて修正するのに役立ちます
• カオスエンジニアリングとは自分たちが開発、構築したシステムに自信をつけること

感想

サーバーレスの世界でカオスエンジニアリングを実施するにはどうするべきかというセッションでした。カオスエンジニアリングという言葉自体は聞いたことはありましたが、なぜ行うか、どのように行うかがわかるとても参考になるセッションでした。その中でも特にカオスエンジニアリングを行う動機について、「自分達が構築したシステムに自身をつけること」というのが印象に残りました。