Twillioにおけるカオスエンジニアリング

Twilioチームがカオスエンジニアリングへの進出について説明している。Gremlinを使って自社製のキューシステムの一部に障害を注入し、自動回復のテストを行なう。

Twilioは、アプリケーション開発者がコードから呼び出し可能なAPIを通じて、SMSおよび電話へのゲートウェイサービスを提供している。そのアーキテクチャの中核をなすのは、分散キューとレート制限システムである。これらはメッセージ処理におけるシステム障害や遅延を処理し、メッセージ消失を防ぐための永続的なキューを提供する。Twilloチームが構築したこのシステムはRatequeueと呼ばれる。Ratequeueは、多数の一時待ちキュー – 電話番号毎に独自のキューがある – に対するデキュー率を制限する。レート制限が必要なのは、開発者が可能な限り速くTwillio APIを呼び出せるようにするためだが、Twilloがこれら電話ネットワークにプッシュする速度をコントロールする必要がある。RatequeueはRedis上に構築されており、アイソレーションとロードバランシングの目的から水平方向に分割されている。ひとつの分割単位(シャード)の障害が他に影響することはない。各シャードはマスタと、HAのためのレプリカで構成されている。

プライマリシャードがRatequeue内で障害を起こした場合、従来は人が介在して、手動でレプリカをマスタに昇格させていた。このためには、プライマリと同じシャード番号を持ったホストを見つけ出して、それをLBに追加する必要があった。この手動プロセスを廃止するため、チームは２つのシステム – 自動フェールオーバシステムと、それをテストするための障害注入システムを開発した。カオスエンジニアリングの実例として紹介されたのは、この障害注入システムである。このシステムは、さまざまなレベルの障害をランダムに発生させて、障害復旧の能力をテストする。

試験の最大の目標はデータ消失をゼロにすることだった。その他、障害の自動検出と新マスタの導入も目標とされた。チームはAmazon KinesisとNagios、そして同社のクラスタ自動化サービスであるLazarusを使って、独自のソリューションを構築した。各Ratequeueのレプリカがマスタの正常性に関するハートビートをNagiosにプッシュする。それがしきい値を越えると、Nagiosが通知をKinesisにプッシュする。LazarusはこれらのイベントをKinesis上で監視していて、クラスタの状態を独自にチェックし、必要であればフェールオーバのプロセスを起動する。

自動障害回復をテストするため、チームはRatequeue Chaosというツールを開発した。このツールは選択したシャードのプライマリを強制終了し、リカバリを監視する。障害を発生させてシステムに注入し、フェールオーバを発生させるのには、Gremlinというサービスを使用する。GremlinはAPI経由でRatequeue Chaosによって起動され、スタックの任意の部分にコントロールされた障害を注入することができる。このプロセスが、Twillioのステージング環境で4時間毎に実行される。

一連のプロセスで得られた知見として、チームは、仮説ベースのテストモデル、テストを実行するフレームワーク、実環境で実行する場合のロールバック計画についても公開している。