カオスエンジニアリングで本当にカオスにならないための進め方をグラレコで解説

2021-10-05
AWS グラレコ解説

Author : 金森 政雄
イラスト : 伊藤 ジャッジ向子

皆さん、「カオスエンジニアリング」という言葉を聞いたことがあるでしょうか ? カオスエンジニアリングは Netflix 社がクラウド上で分散したアプリケーションを構築していく中でスタートした、本番環境に意図的に障害を注入し、その影響を観察する実験を通して、システムの可用性、信頼性を高めていく取り組みです。この記事では、グラレコを使ってカオスエンジニアリングの基本的な進め方をご紹介しつつ、AWS Fault Injection Simulator というカオスエンジニアリングの実験を支援するサービスをご紹介します。


カオスエンジニアリングってランダムにマシンを止めるあれ ??

「カオスエンジニアリング」という言葉を聞いたことがある方は「EC2 インスタンスをランダムに止めて、テストするやつでしょ ?」と考えたかもしれません。これには少し誤解があります。

確かに、初期には仮想マシンをランダムに停止していたようで、OSS の “Chaos Monkey“ もそのような機能を保持していました。しかし、その後の様々な改善や学びを得て、現在ではそのような方法は主流ではなく、きちんと影響範囲 (”Blast Radius : 爆発半径“と呼ばれます) をコントロールした上で実験を行うようになっています。Netflix のエンジニアがリードして記述した、「カオスエンジニアリングの原則」でも、”カオスエンジニアリングは、分散システムにおいてシステムが不安定な状態に耐えることの出来る環境を構築するための検証の規律です“ と書かれているように、制御下においてシステムの挙動を実験するプラクティスです。

img_awsgeek-fault-injection-simulator_01

また、カオスエンジニアリングは従来のテストとは違う観点でシステムを検証します。従来のテストの基本的なアプローチは特定の既知の条件において「システムが期待通りに振る舞う」ことを確認するプロセスでした。例えば単体テストにおいては、対象の関数に対して、特定のインプット、もしくはその組み合わせが入力された場合に期待される振る舞いが決まっており、テストでは現在の実装が期待通りに振る舞うことを確認します。もちろん、テストの重要性はクラウドや分散システムにおいても変わりません。

一方で、クラウドを活用した分散システムは複雑化し、変化し続けるという特性をもっています。そのため、システムが取りうる振る舞い全てのパターンを事前に予測し、テストすることは不可能です。このような予測不可能なシステムに対して、実環境において実験を行うことでシステムの振る舞いを学び、改善点を見つけたり、理解を深め、さまざまな問題が起こり得る本番環境において「システムを安定して運用していくことができるという自信」を構築する取り組みがカオスエンジニアリングです。


カオスエンジニアリングの進め方

では、実際にカオスエンジニアリングを進めるにはどのようにすると良いでしょうか ?ここでは、カオスエンジニアリングの原則も参考に、下記のようなプロセスで進め方を考えてみたいと思います。

  1. 定常状態の定義
  2. 仮説の構築
  3. 変数を導入し実験する
  4. 検証
  5. 改善

なお、カオスエンジニアリングを始める前にやっておいていただきたいこと、やっておくと良いこともあります。この点についてはこの記事では解説しきれないので、ご興味ある方は こちらの AWS Summit の動画 も合わせてご参照ください。

1. 定常状態の定義

まず最初に「定常状態 (Steady State) 」と呼ばれる、システムが通常の動作をしていることを示す指標を定義します。この時、定常状態には測定可能な具体的な数値を定義する必要がありますが、CPU やメモリの使用率のような単純なシステムのメトリクスではなく、「システム全体としてサービスを正しく提供できているか」を計測できる指標を定義しましょう。

例えば EC サイトであれば、“一定期間中のカートに商品が入った数” などビジネス的な KPI に関連する値が良いでしょう。ここで重要なのは、お客様にサービスが正しく提供されていることを確認でき、また、問題発生時にお客様へ影響が出てしまっていることを確認できる値であることです。例えば “CPU の使用率が 90 % 以下である“ という指標は、CPU の使用率が一時的に高くなっていてもユーザーに直接的な影響が発生していないことは十分に考えられますし、逆に CPU 使用率には関係のない理由により、ユーザに意図しない影響を与えてしまっていても気づけない可能性もあります。

img_awsgeek-fault-injection-simulator_02

2. 仮説の構築

定常状態が定義できたら、次は実験対象の事象が発生した時にもその定常状態が継続できる、という仮説を立てます。即ち「何らかのトラブルが発生しても正常にサービス提供を継続できる」ことを説明します。この仮説は関係者とよく協議することをお勧めします。

この仮説を立てる中で考慮不足や問題が見つかることもあります。その際は実験に進まず、先に問題を解決していきましょう。これもシステムの改善への貢献になるはずです。

img_awsgeek-fault-injection-simulator_03

3. 変数を導入し実験する

仮説を構築したら、実験を行います。

ここで言う「変数」とはサーバーのクラッシュやソフトウェア的な障害など、現実世界に発生するイベントを反映したものです。サービスを構成するシステムを対照群と実験群にわけ、実験群にのみ変数 (Chaos) を注入します。この際、変数の導入作業を自動化して人的ミスを極力排除したり、致命的な問題が発生したときにすぐに実験を停止できるような仕組みを用意し、実験自体を安全に実施できるようにすることが重要です。後述する、AWS Fault Injection Simulator はこのような実験を簡単に実施できるようにお客様を支援するマネージドサービスです。

img_awsgeek-fault-injection-simulator_04

4. 検証 / 5. 改善

実験結果に対して、対照群と実験群の間で定常状態に差異があるかを確認し、構築した仮説の反証を試みます。

ここで、仮説が反証される挙動が発見された場合、それを「学び」としその問題点が現実にお客様に影響を与える前に対応できるようにシステムの改善を検討します。反証されないということはシステムが仮説通り安定した挙動を示したということなので、システムの可用性や信頼性に対する自信を深めることができます。一般にシステムの定常状態を崩しずらいほど、安定したシステムということができます。また、仮説が完全に反証されなくても、運用手順の見直しなど改善できるポイントが見つかることもあります。

このプロセスを繰り返し、システムの理解を深めながら改善を繰り返していくことによって、様々な問題が起こり得る本番環境においても安定した運用が可能であるという自信を構築していく方法が、カオスエンジニアリングです。

img_awsgeek-fault-injection-simulator_06

AWS Fault Injection Simulator の紹介

ここまでご説明したプロセスの中で、「3. 変数を導入し実験する」を実施する際には、実験群に変数を導入 (障害を注入) し、実験が終了したあとや想定外のトラブルが発生したときに速やかに実験を停止し元の環境に戻す仕組みが必要です。AWS クラウドを使えば、マネジメントコンソールを使って数クリックで簡単にインフラの状態を変更したり、API を利用してそれらを自動化することも可能です。しかし、自分たちでこれらのスクリプトを作成して管理することは大変ですし、アプリケーションレイヤーでのより細かな障害の再現では、コマンド実行などの操作も必要になります。そのため、これらを自動化するためのツールが OSS や SaaS などの形態で提供されています。そのようなツールを使うことで、実験やその前後の処理を自動化することにより、より安全かつ簡単にカオスエンジニアリングを実施することができます。

一方でこれらのツールは一般的に Agent のインストールが必要だったり、導入するためのコストや障壁がありました。カオスエンジニアリングに本格的に取り組んでいく際にはとても強力なツールでも、カオスエンジニアリングの取り組み自体が試験的な段階でそれらを導入するのは難しいと考える方もいらっしゃったかもしれません。

AWS Fault Injection Simulator (AWS FIS) は AWS が提供するフルマネージドの障害注入サービスです。AWS の各種サービスと統合されており、Agent のインストールなどをせずに実験を開始することが可能です。事前に定義されたアクションに基づいた実験だけでなく、AWS Systems Manager (AWS SSM) の Run Command とも統合されており、障害注入用に事前に定義した Document を実行することで、さまざまな実験が可能になっています。

もう一つ、AWS FIS の強力な機能として、「停止条件」という機能があります。これは実験を安全に実行するためのガードレールとして利用できる機能で、事前に設定した Amazon CloudWatch アラームにより、サービスが定常状態を逸脱した場合などに自動的に実験を停止できます。これにより、実験中に想定外の問題が発生した際に、ユーザーへの影響を最低限に抑えて実験を停止することが可能になります。

AWS FIS のより詳しい利用方法については ドキュメント をご確認ください。

img_awsgeek-fault-injection-simulator_05

まずは、本番じゃないところから

AWS FIS でカオスエンジニアリングを試してみたい、と思っていただけましたでしょうか ? ただ、ちょっとお待ちください。いきなり本番環境で AWS FIS の実験を実行しようとしていないですよね ? 

“カオスエンジニアリングの原則“ でも本番環境での実施が推奨されていますし、カオスエンジニアリングの真の価値を引き出すには本番環境での実験は是非チャレンジしていただきたいところですが、いきなり本番で実施しなければいけないわけではありません。まずは開発環境や STG 環境などユーザーや他のチームへの影響を最小限にした安全な環境で試してみましょう。ツールの使い方やサービスの挙動を理解し、自信がついてきたら本番環境で実施にもチャレンジしてみてください。


まとめ

最後に、全体の図を見てみましょう。

img_awsgeek-fault-injection-simulator_full

カオスエンジニアリングに取り組むことで、複雑化する分散システムを安定して運用していく自信を構築することができます。定常状態を定義し、仮説を構築して実験を行い、結果を検証するというプロセスによって、よりシステムの理解を深めていきましょう。実験の際は AWS FIS を利用することで、実験をより効率的かつ安全に実施することも思い出していただき、試してみていだけると嬉しいです。

「やってみたよ」という皆様からの報告お待ちしております!!


builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

この連載記事のその他の記事はこちら

↓ AWS グラレコ解説 バックナンバー ↓
  • ↓ AWS グラレコ解説 バックナンバー ↓
  • 今話題のブロックチェーンをAWSで実現する仕組みをグラレコで解説 »
  • サーバーレスって何が便利なの ? AWS でサーバーレスを構築するためのサービスをグラレコで解説 »
  • 機械学習のワークフローってどうなっているの ? AWS の機械学習サービスをグラレコで解説 »
  • 外部から AWS のバックエンドサービス利用を実現する仕組みをグラレコで解説 »
  • AWS でデプロイの自動化を実現するベストプラクティスをグラレコで解説 »
  • コンテナを使ってモノリスを分割する方法をグラレコで解説 »
  • クラウドへ移行する理由とそのステップをグラレコで解説 »
  • Windows ワークロードをクラウドへ移行するためのベストプラクティスをグラレコで解説 »
  • サーバーレスのイベントバスって何 ? Amazon EventBridge をグラレコで解説 »
  • サーバーレスで SaaS を構築する方法をグラレコで解説 »
  • 「あなたへのおすすめ」はどう生成するの ? Amazon Personalize で簡単に実現する方法をグラレコで解説 »
  • クラウド設計・運用のベストプラクティス集「AWS Well-Architectedフレームワーク」をグラレコで解説 »
  • 特定の顧客セグメントにメッセージ送信。「Amazon Pinpoint」の仕組みをグラレコで解説 »
  • アプリにユーザー認証機能を簡単に追加できる「Amazon Cognito」をグラレコで解説 »
  • わずか数分で WordPress サイトを構築できる「Amazon Lightsail」をグラレコで解説 »
  • 異なるアプリケーション同士の疎結合を実現。「Amazon SQS」をグラレコで解説 »
  • Web アプリを高速に開発できる「AWS Amplify」をグラレコで解説 »
  • 機械学習の知識ゼロでもテキストデータを分析。Amazon Comprehend をグラレコで解説 »
  • ビジネスデータをまとめて可視化 & 分析。Amazon QuickSight をグラレコで解説
  • 人工衛星の地上局を 1 分単位で利用。AWS Ground Station をグラレコで解説
  • カオスエンジニアリングで本当にカオスにならないための進め方をグラレコで解説

筆者プロフィール

photo_kanamori-masao

金森政雄
アマゾン ウェブ サービス ジャパン株式会社
デベロッパースペシャリスト ソリューションアーキテクト

Web、モバイル向けの自社サービスの開発やクラウドを活用したシステムの請負開発を経験後、パートナーソリューションアーキテクトとして、アマゾン ウェブ サービス ジャパン株式会社に入社。2021 年から DevAx チームとして、開発者の方に向けたイベントやワークショップの提供を中心に活動。
最近の個人的ニュースは家の近くのラーメン屋で、「まさお」という自分の名前と同じメニューがあったこと。

イラスト作成者プロフィール

photo_ito_judge

伊藤 ジャッジ向子 (さきこ)
アマゾン ウェブ サービス ジャパン株式会社
ソリューションアーキテクト

2016 年にアマゾン ウェブ サービス ジャパン株式会社テクニカルサポート部入社。AWS Snowball 等のストレージ系サービスのサポート、ならびに IoT サービスをメインにサポートを行い、2019 年にソリューションアーキテクト部門のテクニカルライターを経験後、2020 年より現職。
趣味はインドアでは小さなセンサーと Raspberry Pi でおもちゃを作ること。アウトドアでは犬を連れてのハイキングとキャンプ。

AWS のベストプラクティスを毎月無料でお試しいただけます

さらに最新記事・デベロッパー向けイベントを検索

下記の項目で絞り込む
絞り込みを解除 ≫
フィルタ
フィルタ
1

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する