【 Kong 】カオスエンジニアリングを使用した API ゲートウェイの最適化

2022.08.10 Kong翻訳記事

エンジニアやアーキテクトとしては、無意識のうちに、プラットフォームにできる限りレジリエンス (回復力)を持たせようとします。では、未知の障害についてはどうでしょうか? プラットフォームの未知の動作についてはどうでしょうか? 哲学者ソクラテスは、「無知の知」とかつて言いました。もし、このような未知のものを既知のものにする方法、つまり、特定の障害イベント (事象) に対してどのように動作するか推察する方法があるとしたらどうでしょうか。

マネージャーや CTO がサーバールームに入り、サーバーの電源プラグを抜いて「カオス」をシミュレートするといった時代は終わりました (これは実話で、かつて IT チームにこれをやっていた同僚と私は一緒に働いていました)。どのサポートエンジニアも、自分たちがサポートしているプラットフォームが未知の動作を起こしたために午前 2 時に起こされ、そのプラットフォームはこうした事象に耐えられるように設計されていない、とは言われたくはありません。

この 2 部構成のブログシリーズでは、まずカオスエンジニアリングに触れ、次に、それが分散システムのレジリエンスを検証するのにどのように役に立つのかを見ていきます。その後、Kong Gateway を使用して検証すべきいくつかのシナリオをご紹介し、皆さんが利用しているプラットフォームが、障害に対処できるように適切に設定されているかどうかを確認します。フォローアップのブログ記事では、これを元に書き上げる予定で、上記のシナリオを実験として実施するチュートリアルが掲載されます。そしてカオスエンジニアリングツールを実際に使用して、Kong Gateway のデプロイメントを検証します。

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

分散システムへの移行により、高可用性や堅牢性に対する信頼は、疑心暗鬼状態になっています。しかも、ベアメタルインフラストラクチャからクラウドサービスに移行することで、複雑さがさらに増しています。さらに、マイクロサービスという次元が加わることで、システム内のサービス数によっては、極めて複雑な (障害点が指数関数的に増える可能性がある) エコシステムになる可能性があります。

カオスエンジニアリングの実施とは、コントロールされた障害をシステムに注入し、システム全体のレスポンスを改善することです。このような障害に対応するシステムがどのように動作するかが、監視と改善の良い機会となります。

カオスエンジニアリングのメリット

人生で起こるほとんどの出来事と同じく、自分ではコントロールできない出来事を想定した練習をすることは、実際にそれが起こったときのために筋肉に記憶させるうってつけの方法です。この良い例が火災避難訓練です。オフィスビルで働いたことがある人であれば、非常階段を通って、建物内の全員が外に避難する火災避難訓練を受けたことがあるでしょう。この訓練を何度も実施することで、万が一ビル内で火災が発生した場合であっても、全員が何をなすべきか、どこに集合するべきか、そしてどのようにすれば全員が安全にビルから避難できるかがわかるようになります。このプロセスで起こった失敗は、週単位で実施される訓練で特定されているはずです。

同様に、コントロールされた手法で障害をプラットフォームに注入することは、障害による未知の動作の解決につながるため、非常に理にかなっています。また、チームがドキュメント、システムアクセス、プレイブック（設定ファイル）、スクリプトが正しいかどうかを確認し、実際のクリティカル (優先度 1) なイベントに対する反射的な対応を作り上げることもできます。

「State of Chaos Engineering Report」によると、カオスエンジニアリングの実験を一貫して実施しているチームは、実験を行ったことがないチームや、アドホック (その場限りの) 実験のみを実施しているチームと比較して、高いレベルの可用性を維持しているとのことです。[1] これは必ずしも高レベルの可用性を保証するわけではありませんが、明らかにベストプラクティスと言えます。

このレポートには、次のような重要な調査結果が記載されています。

「可用性の向上と平均修復時間 (MTTR) の短縮が、カオスエンジニアリングで見られる主な 2 つのメリットです。」
ネットワーク攻撃は、最も多く報告されている障害であり、実験が最も多く実施されています。[1]

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

2008 年

Netflix は、3 日間もの大規模な障害に見舞われ、当時の DVD 出荷業務に影響がおよびました。多くのフォレンジック分析を行った後、この問題の解決に 3 日を要し、結局ハードウェア障害であると結論づけました。そこで、同社はアーキテクチャを見直し、分散型クラウドアーキテクチャに移行することになりました。

2010 年

Netflix がクラウドに移行すると、ホストはいつでも停止や障害が発生したりする可能性があるため、障害に備えた設計をもとめられました。同社ではこのことを念頭に置き、これらの障害をコントロールされた方法で検証し、アーキテクチャの弱点を特定できるようにするためのツールが必要になりました。そこで、Chaos Monkey というツールを開発しました。このツールは、インスタンスとサービスを意図的に停止させるために使用されました。Netflix は、このツールを使用したお陰で、システムがこの障害にどのように対応するか確認する機会が得られ、このような障害を解決する自動化レベルが設計できるようになりました。

この成功により、Netflix は Chaos Monkey をオープンソース化し、カオスエンジニアリングに特化した新たな職種を創出しました。

2020 年

カオスエンジニアリングは主流となり、Bloomberg でヘッドラインを飾りました。また、AWS も独自のカオスエンジニアリングツールである AWS Fault Injection Simulator をリリースしました。[2]

2022 年

過去5年間で、Google 検索では、『カオスエンジニアリング』のトピックに関するものが爆発的に増え、24倍になりました。

カオスエンジニアリングの原理について[1]

前述のように、カオスエンジニアリングとは、システムに障害を注入し、システムがどのようにレスポインスをするかを観察することです。

このプラクティスの原理は次のように単純です。

仮説を立てる：プラットフォームにどのような問題/エラーを注入し、どのような動作が見られることが期待されることなのかを決定します。
実験する：この仮説を検証するために使用できる最小限の実験を設計します。
測定し改善する：各ステップでの成功と失敗を識別して、実験に対するプラットフォームの対応を監視します。次に、障害が発生している部分を改善して、スケールまたは自己修復を行うことで、システム全体の対応を改善できるようになります。

Kong を用いたカオスエンジニアリング: サンプルシナリオ[2]

では、これを Kong にどのように適用するのでしょうか? Kong Gateway の導入環境では、さまざまなシナリオを検証できます。ここでは、次に挙げる 2 つの例を見てみましょう。

シナリオ 1 – Kong のハイブリッド環境での動作

仮説

ハイブリッド環境では、コントロールプレーンとデータプレーンが分離し、設定は WebSocket を使用して転送されます。これらのコンポーネントを分離することで、プラットフォームのレジリエンスが向上します。この展開モードは、データプレーンがコントロールプレーンから分離され、レジリエンスがより向上するように設計されています。コントロールプレーンとデータプレーンの間の接続がダウンした場合、次のような理由が考えられます。

コントロールプレーンがダウンした。
データベースまたはデータベースへの接続がダウンした。
コントロールプレーンとデータプレーンの間の WebSocket がダウンした。

この実験では、コントロールプレーンに接続されたデータベースの障害を検証します。

実験

コントロールプレーンのデータベースをダウンさせ、コントロールプレーンに障害を発生させます。これで、データプレーンとコントロールプレーンの間の接続が切断されます。

測定と改善

データベースがダウンすると、コントロールプレーンは動作に必要なデータベース接続がないため、正常動作しませんが、データプレーンの方は影響を受けません。これを検証するには、次の条件を満たす必要があります。

Admin API にアクセスできない (接続に失敗しました：接続が応答を拒否しました、という応答を返す)
データプレーン (プロキシ) にアクセスできる (200 HTTP レスポンス、を返す)

シナリオ2 – 可用性ゾーンが停止

仮説

クラウドアーキテクチャを設計する際は、アプリケーションやプラットフォームの障害だけでなく、プラットフォームが稼働しているデータセンターの停止を含め、障害を想定した設計を行うことが常に重要です。クラウドプロバイダーは、地域 (リージョン) ごとに異なる可用性ゾーン (AZ) を提供して、これに対応できるようにしています。各 AZ は異なる物理データセンターのことです。つまり、万が一AZ 全体がダウンする可能性を想定して、システムを設計する能力が問われます。

次の実験では、過去に何度か発生した障害を正確に想定して検証します。