はじめに
こんにちは、ZOZOMO部OMOバックエンドブロックの長野です。普段はZOZOMOのサービスであるブランド実店舗の在庫確認・在庫取り置き（以下、店舗在庫連携）の開発・保守を担当しています。
店舗在庫連携はAWS上にシステムを構築しており、システムにはAWSの各サービスを利用しています。AWS上で構築するシステムは、マルチAZなどの冗長構成をとることで可用性を高めることができます。しかし、実際に障害が起こった際に、意図していなかった箇所でシステムが停止してしまう可能性は否定しきれません。
OMOバックエンドブロックでは、このような未知の障害を防ぐためのアプローチとしてカオスエンジニアリングを実施しました。本記事ではカオスエンジニアリングの説明とチームで行った結果を紹介します。
目次
カオスエンジニアリングとは
カオスエンジニアリングは、稼働しているシステムに対して意図的に障害を発生させることでシステムの堅牢性・回復力を高める手法です。特にクラウド上で構築されるシステムは、各コンポーネント同士が疎になっていて、障害時の挙動の予想がより困難になっています。そこで、意図的に障害を発生させることで、システムの未知の挙動を発見することが期待できます。
カオスエンジニアリングは主に4つのステップで構成されます。
- 定常状態を定義する
- 仮説を立てる
- 実験する
- 検証する
それぞれのステップについて説明します。
1. 定常状態を定義する
障害を注入する前にシステムの通常時の振る舞いを定義します。
定常状態は、障害発生中にシステムが問題なく稼働していることの確認や、停止状態からの復帰の判断に利用します。スループット・エラーレート等のメトリクスやSLOの値などが用いられます。
2. 仮説を立てる
定常状態を破壊できる事象を考え、その事象が発生してもシステムが停止しないという仮説を立てます。
いきなり仮説を立てることが難しい場合には、先ず起こりうる事象を考えるところから始めるのがやりやすいと思います。仮説を立てる中で課題を発見した場合は、実験の対象にはせずに改善します。
カオスエンジニアリングは未知の発見が目的になるので、既知となった問題は実験対象として扱いません。
3. 実験する
定常状態を破壊できる事象を実際に発生させます。
カオスエンジニアリングによる実験は、本番環境で実施することが推奨されますが、まずは開発環境で実施することをおすすめします。仮説が正しいことを開発環境で確認した後に、本番環境で実施するようにした方が安心出来ますね。
4. 検証する
仮説が正しかったか確認します。
もし仮説が誤っていた場合は、未知を発見できたということになるので、システムのどの部分が停止したかを確認して改善していきます。
カオスエンジニアリングの目的
前述のとおり、カオスエンジニアリングは未知を発見することが目的ですが、それだけではありません。定常状態を破壊できる事象を考えることや検証することは、開発者のシステムへの理解を高めることにもなります。
例えば、定常状態を破壊できる事象を考えるためにシステムのアーキテクチャ図を眺めることや、仮説が誤っていた場合に実際にはどうだったのかを調査する必要があります。これらを繰り返すことでチームはシステムに対する理解を深め、システムはより堅牢なものになっていきます。
チームで実施したこと
チーム内にカオスエンジニアリングの実施経験のあるメンバーがいなかったため、まずはカオスエンジニアリングの目的や期待できる効果について、前述した内容をチーム内で会話して共通認識にしました。その後、仮説をもとに実験と検証を実施したのでそれぞれお話しします。
仮説を立てる
仮説を立てるにあたり、まず発生し得る事象を洗い出しました。下記は洗い出した事象の一例です。
- ECSのタスクが落ちる
- 特定AZで障害が発生してAZ内のリソースが利用不可になる
次に、事象発生の際にどのような影響があるかを考えました。例えば、ECSのタスクが落ちた場合、サービススケジューラで設定してある必要タスク数まで自動復旧する等です。
このような仮説を立てた後はサービスへの影響度を考えます。その仮説が間違っていて問題が発生してしまった場合の影響度を考えることで、カオスエンジニアリングによる実験の優先順位を決定します。
最終的には、すべての仮説を検証して、システムの安全性に自信をもてる状態を目指しますが、まずは優先順位の高いものから手を付けていきます。仮説は上記の例以外にも挙げられましたが、今回は影響度が高いAZ障害への耐障害性を実験することに決定しました。
実験する
AZ障害を発生させるにあたり、障害を注入するツールとしてAWS Fault Injection Service(以下、FIS)を利用しました。FISの詳細はAWSのドキュメントをご確認ください。
FISでは、VPCサブネットを出入りする通信を妨害する障害を注入できます。特定AZのサブネットのみ通信を妨害することで、各AWSサービス間の通信を失敗させ、AZ障害を再現しました。
店舗在庫連携では、主にALB、ECS、RDSを用いてシステムを構築しているため、この3つのサービスでAZ障害を起こし、耐障害性を検証します。
下図に各リソースがどのように配置されているかの簡単な図を示します。画像内の赤い枠線で囲まれたサブネットが今回障害を発生させる対象になります。
下の画像のようにFISは実施したいアクションと、そのターゲットを組み合わせることで障害を発生させます。画像では、サブネット通信を妨害するアクションを disrupt-connectivity に、特定AZのサブネットを選択したグループのターゲットを Subnets-Target-1 に設定しています。このアクションとターゲットを紐づけることで、障害を発生させることが出来ます。
FISでは、複数のアクションやターゲットを組み合わせることも可能です。その他、適切なIAMロールを設定することで、不要なリソースへのアクセスを拒否することや、CloudWatch Alarmを用いてメトリクスをもとに実験を停止させる等、安全面も考慮されています。
今回、店舗在庫連携のAPIでは、下記内容で実験しました。
- 前提
- 実験環境：検証環境
- AWSの各リソースは3AZに配置
- 10req/sで店舗在庫連携のAPIを7分間実行する
- 実験
- APIを実行中に特定AZのサブネット通信を妨害し、AZ障害を発生させる
- 仮説
- 各リソースでマルチAZの冗長構成にしているためサービス提供は止まらない
下図はAPIの実行結果になります。15:59:20から16:01:50の2分30秒間で504エラーが発生していることがわかりました。
検証する
実験結果が仮説通りだったか、もし仮説通りでなければ実際には何がおこっていたのかを確認していきます。
今回の実験では「各リソースでマルチAZの冗長構成にしているためサービス提供は止まらない」でした。これ自体は間違いではありませんでしたが、詳しく見ると一部のリクエストが数分間エラーになる状態でした。
カオスエンジニアリングは実験してシステムの安全性を確認して終わりではなく、何が起こっていたのかを確認して開発者の知識を増やすことも目的の1つです。
今回の実験で2分30秒間エラーが発生した理由を調査すると、ALBのターゲットグループに登録してあるECSタスクのうち、障害が発生中のECSタスクにもリクエストが割り振られているためでした。これは考えれば分かる事だと思いますが、ではなぜ2分30秒なのかということも確認してみます。
これは、ターゲットグループのヘルスチェックで異常を検知するための設定に依存していました。店舗在庫連携では、その設定が2分30秒だったためで、2分30秒という時間の元となる設定内容は、ヘルスチェックの回数や間隔です。
カオスエンジニアリングを実施して良かったこと
今回の実験で分かったことは、AZ障害が発生してもサービス提供は停止しないが、2分30秒の間で一部エラーが発生してその後自動復旧するということでした。実験前は「マルチAZでやっているから大丈夫」という軽い認識でしたが、「2分30秒間は一部エラーが発生するものの、その後自動復旧するから大丈夫」という根拠を持った自信になりました。
また、インフラ構築の経験者や知識がある人は最初から結果の想像が付いていましたが、普段インフラを触る機会が少ない開発メンバーにとっては、新しい知識が増える機会の多い良い学びの場になりました。カオスエンジニアリングを継続することで、システムと開発者が共に強くなっていくということも実感しました。
まとめ
本記事では、弊チームのカオスエンジニアリングへの取り組みを紹介しました。カオスエンジニアリングを実施することで、システムの安全性の確認と開発者のシステムへの理解を深めることができました。カオスエンジニアリングの実施を検討している方がいれば、ぜひ参考にしてみてください。今後は洗い出した仮説をすべて検証することと、本番環境で実験していきたいと考えています。
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
