CodeZine(コードジン)

特集ページ一覧

Kubernetesでカオスエンジニアリング ~サーキットブレーカーパターンで回復性の高いシステムを構築する

クラウドネイティブ時代の実践カオスエンジニアリング 第6回

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2021/11/10 11:00

 前回は、Kubernetesクラスタのマネージドサービスである、Azure Kubernetes Serviceへのカオス挿入を紹介しました。今回は、Kubernetesクラスタで動くアプリケーションへのカオス挿入について説明します。

目次

はじめに

 分散システムで信頼性・回復性を高めるには、インフラレベルだけでなくアプリケーションレベルまで踏み込んた考慮が必要です。

 ここでは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も用意されています。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:クラウドネイティブ時代の実践カオスエンジニアリング

著者プロフィール

  • 阿佐 志保(アサ シホ)

    金融系シンクタンクなどで銀行/証券向けインフラエンジニア、製造業向けインフラエンジニアとして従事。都市銀行情報系基盤システム構築やシステム統廃合、証券会社向けバックオフィスシステムの共通基盤開発プロジェクトを経験。結婚・出産を経て現在は、日本マイクロソフトで法人向けにクラウド導入支援やプリセールスな...

あなたにオススメ

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5