はじめに
分散システムで信頼性・回復性を高めるには、インフラレベルだけでなくアプリケーションレベルまで踏み込んた考慮が必要です。
ここではKubernetesクラスタで動くアプリケーションに対してカオス挿入を行う方法について説明します。そして、アプリケーションにアクセスできなくなった場合、サーキットブレーカーパターンを用いて閉塞させることで、システム全停止を防ぐにはどうすればよいかを解説します。
システムの回復性とは
クラウド環境でアプリケーションを動かす場合の多くは、自律的に動作する複数のサービスによって構成されます。例えばメインとなるWebアプリケーションサーバだけでなく、キャッシュサービスやCDN、サーバーレス、外部REST APIの呼び出しなどを組み合わせてシステムアーキテクチャを設計します。これは、アプリケーションは高い性能を発揮したり、新機能を素早く取り込んだりできるためクラウドのメリットでもあります。
クラウドに限らず分散システムの場合、システムの障害をゼロにする、というのは現実的ではありません。「サーバ・ネットワークを絶対に止めてはいけない」ではなく、「障害が発生するという事実を受け入れ、素早くシステム回復させるためにはどうすればよいか」を考えることが重要です。
「サーキットブレーカーパターン」は分散システムにおける回復性を高めるためのデザインパターンの1つです。
あるサービスに大規模な障害が発生し、短時間で復旧の見込みがないにもかかわらず、リトライをしてしまうとその間ブロックが発生してリクエストが詰まったり、リトライストームが発生したりすることがあります。
サーキットブレーカーは、対向のサービスが応答しない場合はリクエストを辞め、成功する可能性があればリクエストを送るという動きをします。サーキットブレーカーは、失敗する可能性のある処理のプロキシとして動作します。
このような障害を想定したテストについて、具体的にChaos ToolkitとKubernetesを使って簡単なJavaサンプルアプリをもとに説明していきます。
Chaos Toolkit Kubernetes拡張機能とは
Chaos Toolkit Kubernetes拡張機能は、Kubernetes APIに対してカオスエンジニアリングを実行できる拡張機能です。
Kubernetesリソースに対してChaos Toolkitで挿入可能なカオスは下記になります。また、Custom Resourcesに対しても実験ができます。
- Deployment
- Node
- Pod
- ReplicaSet
- Service
- StatefulSet
さらに、Chaos ToolkitをKubernetesクラスタ上で動かすためのOperatorも用意されています。
