Pumbaとは何か？カオスエンジニアリング向けツールの概要・特徴とできること【入門者必見の完全ガイド】

Pumbaとは何か？カオスエンジニアリング向けツールの概要・特徴とできること【入門者必見の完全ガイド】

Pumbaは、Dockerコンテナ環境におけるカオスエンジニアリングを実践するためのオープンソースのツールです。システムに意図的に障害を発生させることで、サービスの耐障害性や信頼性を検証する目的があります。たとえば、Pumbaを使用するとコンテナを強制停止したり、ネットワーク遅延を発生させたりといった「障害注入」を簡単に行えます。Netflix社のChaos Monkeyに着想を得て開発されたこのツールは、コンテナ環境に特化しており、マイクロサービス環境での堅牢性テストに活用されています。

本節ではPumbaの基本概要や特徴、できることについて詳しく解説します。Pumbaがどのような課題を解決し、他のツールと比べてどのようなメリットがあるのかを理解することで、効果的に活用できるでしょう。

Pumbaの概要と役割

Pumbaはコンテナ向けのカオスエンジニアリングツールとして2017年頃に公開されました。その役割は、Dockerコンテナに対して意図的に障害を発生させ、システムの堅牢性をテストすることです。従来、Chaos MonkeyなどクラウドVM向けのツールはありましたが、Dockerコンテナに特化した手軽なツールが求められており、Pumbaはそのニーズに応える形で登場しました。開発者はAlexei Ledenev氏で、現在GitHub上でオープンソースプロジェクトとして公開されています。

役割としては、本番さながらの環境でコンテナの障害シナリオを再現し、サービスがそうした障害に耐えられるかを検証することにあります。例えば、コンテナをクラッシュさせてもサービス全体が継続するか、ネットワークが遅延してもタイムアウト処理が適切に行われるかなど、Pumbaを使って事前に試すことで問題点を洗い出すことができます。

Pumbaが解決する課題

現代のマイクロサービス環境では、多数のコンテナが連携してサービスを提供しています。その中で一部のコンテナに障害が起きた場合、システム全体に予期せぬ影響が及ぶことがあります。Pumbaはこのような課題に対処するために、生産環境に近い状態で障害を人工的に発生させる手段を提供します。これにより、普段は顕在化しないシステムの弱点やボトルネックを事前に発見でき、サービスの信頼性向上につなげることができます。

具体的にPumbaが解決する課題としては、障害対応手順の検証があります。例えばコンテナが突然停止した際に、自動再起動やフェイルオーバーが正常に機能するかを確認することは重要です。また、ネットワークが部分的に不安定になった場合にリトライ処理やタイムアウト設定が適切かどうかもPumbaで試験できます。このように、事前に障害を起こしておくことで、本番障害時に慌てず対処できるようになるという効果があります。

Pumbaの主な特徴

Pumbaの大きな特徴は、コマンドラインツールとしてシンプルに使える点です。単一のバイナリまたはDockerコンテナイメージとして配布され、容易に導入できます。さらに、以下のような特徴を備えています。

• 多様な障害注入: コンテナのプロセス停止（killやstop）、ネットワーク遅延やパケットロスの挿入、CPUやメモリに負荷をかけるストレステストなど、幅広い種類の障害を発生可能です。
• 高度なフィルタリング: コンテナ名やラベル、正規表現(RE2)で対象コンテナを柔軟に指定できます。さらにランダム選択オプション（--random）により、複数コンテナから無作為に1つを選んで障害を与えることも可能です。
• スケジュール実行: --intervalオプションを指定することで、一定間隔で障害を繰り返し注入するスケジュール実行ができます。長時間にわたる耐久テストや、常に障害を起こし続けるカオスモードの試験にも対応します。
• 安全なドライラン: --dry-runオプションで実際には障害を発生させず計画のみをログ出力する機能があります。これにより、本番環境で実行する前に影響範囲を確認できます。

これらの特徴により、Pumbaは開発・運用チームが手軽にカオスエンジニアリングを始めるための強力なツールとなっています。

Pumbaで可能なことの一覧

Pumbaを使うことで具体的にどのような障害注入が可能か、主要な機能をまとめます。

• コンテナの強制終了・停止: 実行中のコンテナプロセスを即座に終了させたり（kill）、正常終了させたり（stop）できます。これにより突然のプロセス消失に対するシステムの挙動を確認します。
• コンテナの再起動: 指定したコンテナを再起動させることで、一時的な障害からの自動復旧シナリオをテストできます。
• コンテナの一時停止: pauseコマンドでコンテナ内のプロセスを一時停止させ、フリーズ状態になった場合の影響を観察できます。
• ネットワーク遅延・パケット損失: netemコマンドを使用してネットワークに遅延（latency）を発生させたり、パケットロスを注入できます。通信が不安定になった際のリトライ処理やユーザー影響を評価します。
• ネットワーク帯域制限: netemのrate機能により通信帯域を制限し、低速ネットワーク下での動作検証が可能です。
• CPU/メモリ負荷: stressコマンドを使って対象コンテナにCPU負荷やメモリ消費を発生させます。高負荷状態でシステムの応答性やリソース監視が適切に機能するか確認できます。
• コンテナの削除: rmコマンドで実行中のコンテナそのものを削除し、サービス構成から消失した場合の影響をテストします。

以上のように、Pumbaだけでコンテナに対する様々な障害シナリオを網羅的に試すことができます。詳細なコマンド内容については後述の「主なコマンド一覧」で解説します。

Pumbaのメリットと注意点

Pumbaを利用するメリットは、まず手軽にカオスエンジニアリングを始められる点です。Dockerコンテナさえ動いていれば、単一のバイナリまたはコンテナイメージで実行できるため、学習コストが低くすぐに試せます。また、オープンソースで無料で利用できる点も魅力です。小規模なチームでも導入しやすく、自社システムの弱点発見に寄与します。

一方、注意点として本番環境での使用リスクがあります。Pumbaは意図的に障害を発生させるため、誤った使い方をすると本番サービスに深刻な影響を与えかねません。本番で試す際は必ず十分な検証を経て、影響範囲を限定した上で実行すべきです。また、KubernetesなどDocker以外のコンテナランタイム環境では、そのままでは動作しない場合があります（Dockerエンジンへの直接アクセスが必要なため）。Kubernetesで使う方法は後述しますが、環境によっては追加設定（例えば権限付与やDaemonSetの利用）が必要となる点にも留意が必要です。

Pumbaの想定ユースケース

Pumbaは主に開発・運用フェーズにおいて、システムの堅牢性を高めるために使われます。具体的なユースケースとしては以下のような場面が考えられます。

• マイクロサービスの耐障害テスト: 複数コンテナで構成されたサービス群で、一部のコンテナがダウンした際に全体として正常動作を維持できるかを検証。
• ネットワーク不安定時の挙動確認: 一定のネットワーク遅延やパケットロスが発生した状況で、サービスの応答時間やエラーハンドリングが期待通りかテスト。
• リソース逼迫への耐性評価: CPUやメモリに負荷がかかったときに、システムがスローダウンしないか、適切にスケーリングするかをチェック。
• 障害対応訓練: 運用チームが実際に障害が起きた際の対応手順を身につけるための演習に利用。定期的に擬似障害を発生させ、手順書通り対処できるか確認。

このように、Pumbaは開発現場だけでなく運用現場での訓練用途にも有用です。以上がPumbaの概要と特徴、そして想定される活用シーンとなります。

カオスエンジニアリングとは何か？世界的に注目される手法の目的・重要性とその実践例を初心者向けに徹底解説

カオスエンジニアリングとは、システムに意図的に障害を起こす「実験」を行い、その挙動や弱点を明らかにする手法です。平常時には見えない問題をあぶり出し、信頼性を高めることを目的としています。具体的には、本番環境またはそれに近い環境で一部のサービスを停止させたり、ネットワーク遅延を発生させたりして、システム全体がどのように振る舞うかを観察します。これにより、障害発生時の予期せぬ挙動やボトルネックを事前に見つけ出し、改善につなげることができます。

カオスエンジニアリングはNetflix社が提唱し始めたことで注目を集め、現在では世界中の大規模サービスで採用されています。その基本的な考え方から具体例まで、以下で詳しく解説します。

カオスエンジニアリングの定義と目的

カオスエンジニアリングは正式には「本番環境における擾乱試験」とも言えます。定義としては「分散システムにおいて、現実に起こり得る障害をシミュレーションする実験を通じて、システムの耐障害性を評価・改善する手法」です。その目的は、障害に強いシステムを構築することにあります。

近年のクラウドネイティブなアプリケーションは多数のマイクロサービスから構成され複雑化しています。従来のテストではカバーしきれない予期せぬ相互作用や故障パターンが存在するため、実際の障害シナリオを試すカオスエンジニアリングが重要視されています。「システムは必ず壊れる」という前提に立ち、あえて壊してみることで事前に備えるーーこれがカオスエンジニアリングの根幹です。

システム信頼性向上のための重要性

なぜカオスエンジニアリングが重要なのでしょうか。それは、ユーザーに継続的なサービス提供を行う上でシステムの信頼性とレジリエンス（回復力）が不可欠だからです。障害が起きないシステムを作ることは現実的に不可能であり、むしろ障害が起きても迅速に回復しユーザー影響を最小化できる仕組みが重要です。

カオスエンジニアリングを実践することで、開発チームと運用チームはシステムの弱点を客観的に把握できます。例えば冗長化が不十分なサービスや、障害時にタイムアウト設定が適切でない箇所など、通常のテストでは見逃しがちな問題点が明らかになります。結果として、事前対策や設計改善が施され、信頼性向上につながります。ユーザーから見ればサービスダウンの頻度が下がり、万一の障害時にも迅速に復旧するサービスとなるため、ビジネス上の損失軽減や信用向上の効果も期待できます。

NetflixにおけるChaos Monkeyの事例

カオスエンジニアリングの代表的な実践例として有名なのが、NetflixによるChaos Monkeyの導入です。Chaos MonkeyはNetflix社内のシステムでランダムにサーバーインスタンスを停止させるツールで、2010年代初頭に公開され大きな話題となりました。当初は本番環境の任意のサーバーを意図的に落とすという大胆な試みでしたが、これによりNetflixのサービスは個々のサーバー障害に耐えられるよう設計・改良されていきました。

Chaos Monkey成功の背景には、Netflixの文化として「常に障害が起こることを前提にせよ」という考え方が浸透していたことがあります。同社はChaos Monkeyを皮切りに、Chaos Gorilla（データセンター全体の停止を模擬）など一連の「Simian Army」と呼ばれるカオスツール群を開発し、システム全体の強靭性を飛躍的に高めました。このNetflixの事例は他社にも大きな影響を与え、今日ではGoogleやAmazonなど多くの企業が独自のカオスエンジニアリング手法を取り入れるに至っています。

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

カオスエンジニアリングを実践するメリットは数多くあります。まず第一に、システムの隠れた欠陥を早期に発見できることです。定期的な障害シナリオの注入により、問題が顕在化する前に対応策を講じることができます。また、実践を通じて開発者・運用者の障害対応スキルが向上する効果も見逃せません。実験を重ねることで、チームは障害時の挙動に精通し、いざ本当の障害が起きた際にも慌てず対処できるようになります。

さらに、システムの設計そのものが改善されるという効果もあります。カオスエンジニアリングのフィードバックによって、冗長性の追加やフォールトトレランス設計の見直しが行われ、結果的にシステム全体の品質向上につながります。ビジネス的にも、サービス稼働率（SLA）の向上や顧客満足度の維持に寄与します。つまり、カオスエンジニアリングは一種の保険投資であり、将来的な大規模障害による損失を未然に防ぐ効果があると言えるでしょう。

カオスエンジニアリング実践の注意点

一方で、カオスエンジニアリングを行う際にはいくつかの注意点も存在します。まず、計画と検証を十分に行うことです。漠然と障害を起こすのではなく、「どのような仮説を検証するのか」「期待されるシステムの挙動は何か」を事前に明確にします。実験後は得られたデータを分析し、学習を次に活かすサイクルを回すことが重要です。

また、実験は段階的に実施すべきです。初めから本番環境で大規模な障害を起こすのはリスクが高すぎます。まずはステージング環境や一部トラフィックのみを使ったカナリアリリースで試験し、問題がなければ本番への適用範囲を広げるのが望ましいでしょう。そして必ずモニタリングとアラートの体制を整え、予期せぬ影響が出た場合は即座に実験を中断できるようにしておくことも大切です。

最後に、組織的な合意と文化の醸成も不可欠です。カオスエンジニアリングは一歩間違えれば「自ら障害を起こす悪い行為」と捉えられかねません。経営層や関係部署にその意義を理解してもらい、小さな成功体験を積み重ねて信頼を得ることで、継続的な実施が可能になります。

以上がカオスエンジニアリングの概要とその重要性、メリットおよび注意点です。Pumbaはこのカオスエンジニアリングをコンテナ環境で実践するための具体的なツールであり、次章以降ではその使い方に焦点を当てて解説していきます。

Pumbaのインストール方法: バイナリダウンロード・Homebrew・Dockerイメージによる導入手順を解説

Pumbaを利用するには、いくつかのインストール方法があります。公式には単一バイナリが提供されており、それをダウンロードして使用するのが一般的です。また、macOSユーザーであればHomebrew経由のインストールも可能です。さらには、DockerコンテナとしてPumbaを実行し、ホストに直接インストールしない方法もあります。それぞれの手順とポイントを解説します。

Pumbaの入手先とバイナリダウンロード方法

最も基本的な方法は、Pumbaの実行ファイル（バイナリ）を直接ダウンロードして設置するやり方です。公式の配布はGitHubのリリースページから行われています。以下に手順を示します。

1. GitHubリリースページにアクセスし、お使いのOSに合ったバイナリファイルをダウンロードします。例えばLinuxならpumba_linux_amd64.tar.gz、Windowsならpumba_windows_amd64.zip、macOSならpumba_darwin_amd64.tar.gzといったファイルが用意されています。
2. ダウンロードしたファイルを展開し、中に含まれる実行ファイル（Linux/macOSならpumba、Windowsならpumba.exe）を取り出します。
3. （Linux/macOSの場合）ターミナルで実行ファイルに実行権限を付与します: chmod +x pumba。
4. 実行ファイルをPATHの通ったディレクトリに配置します。例えば、/usr/local/bin/にコピーまたは移動します: sudo mv pumba /usr/local/bin/。
5. コマンドラインからpumba --helpやpumba --versionを実行し、ヘルプやバージョン情報が表示されればインストール成功です。

以上でPumbaのバイナリ設置は完了です。バイナリ版の利点は、依存関係が少なく単独で動作するため、環境を汚さずに利用できる点にあります。

Homebrewを利用したPumbaインストール（macOS）

macOSユーザーであれば、パッケージマネージャーのHomebrewを使って簡単にPumbaをインストールできます。Homebrewによりバイナリのダウンロードや配置を自動化できるため便利です。手順は以下の通りです。

1. ターミナルを開き、Homebrewがインストールされていない場合は事前に導入してください（/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"）。
2. Homebrew経由でPumbaをインストールします: brew install pumba と入力して実行します。
3. インストールが完了したら、pumba --version などのコマンドで正常にPumbaが呼び出せることを確認します。

Homebrewを使うことで、バージョン管理やアンインストールも容易になります。brew upgradeでPumbaを最新バージョンに更新したり、brew uninstall pumbaでクリーンに削除したりできるため、macOS環境では推奨の方法です。

Dockerイメージを使用したPumbaの利用方法

Pumba自体をDockerコンテナとして実行する方法もあります。これはホストに直接Pumbaをインストールしなくても、Docker上でPumbaコンテナを動かし、そのコンテナからホスト上の他のコンテナに対して障害を注入する形になります。公式Dockerイメージ（gaiaadm/pumbaなど）がDocker Hubで提供されています。

Dockerイメージ版を利用するには、ホストのDockerデーモンにアクセスできるよう設定する必要があります。具体的には、Pumbaコンテナ起動時にDockerソケットをマウントします。例として、以下のコマンドでPumbaコンテナを一時的に起動しヘルプを表示できます。

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock gaiaadm/pumba:latest --help

上記のように、-v /var/run/docker.sock:/var/run/docker.sockオプションでホストのDockerソケットをコンテナ内に共有することで、Pumbaコンテナがホスト上のDockerを操作可能になります。--rmはコンテナ終了時に削除するオプションです。

実際に障害を与える際は、上記と同様にPumbaコンテナを起動しつつ必要なコマンドを指定します。例えば、毎秒1回コンテナを停止する場合、docker run --rm -v /var/run/docker.sock:/var/run/docker.sock gaiaadm/pumba:latest --interval=1s kill 対象コンテナ名 のように実行します。Dockerイメージを使う利点は、Pumbaの依存環境をコンテナ内に閉じ込められるためホストを汚さないことや、Kubernetes環境でDaemonSetとして展開しやすいことです（Kubernetesでの利用方法は後述）。

Windows/Linux環境でのインストール手順と注意点

Linux環境では、基本的に先述したバイナリダウンロード手順で問題なく動作します。特にUbuntuやCentOSなどディストリビューション固有のパッケージは提供されていませんが、GitHubのLinux向けバイナリをダウンロードしてパスに置けば使用可能です。また、HomebrewをLinuxに導入している場合はbrew install pumbaが利用できるケースもあります。

Windows環境では、GitHubから配布されている.exeファイルを使用します。手順としては、ZIP形式のアーカイブを展開し、中のpumba_windows_amd64.exeを任意のフォルダに配置します。そのフォルダへのパスを環境変数PATHに追加しておけば、コマンドプロンプトやPowerShellからpumbaコマンドを直接実行できます。Windowsでは直接Dockerデーモンを操作する場合、Docker Desktop経由で実行されるため、適切にDockerが起動していることを確認してください。

なお、WindowsでPumbaを使うよりは、WSL2上のLinux環境やDocker Desktop内でLinuxコンテナとしてPumbaを動かす方が一般的です。Windowsで実行する場合も基本的な機能は同じですが、動作検証はLinux/macOSほど広く行われていないため、可能ならLinux系環境での利用が推奨されます。

インストール後の動作確認方法

Pumbaのインストールが完了したら、必ず動作確認を行いましょう。基本的な確認方法は、コマンドラインでpumba --helpまたはpumba --versionを実行することです。これらを実行してPumbaのヘルプが表示されれば、インストールは成功しています。

さらに一歩踏み込んだ確認として、試験的に簡単なコマンドを実行してみることをおすすめします。例えば、テスト用に立ち上げたDockerコンテナに対してpumba pause コンテナ名 --duration 5s（5秒間一時停止）を実行し、停止と再開が期待通り行われるか観察します。またpumba netem --duration 2s delay --time 1000 コンテナ名（1秒のネットワーク遅延を発生）などを試し、特にエラーなく完了すれば導入は問題ありません。

以上で、Pumbaのインストールとセットアップは完了です。次の節では、実際の基本的な使い方について解説していきます。

Pumbaの基本的な使い方: Dockerコンテナに対するコマンド構文と実行例（コンテナ停止やネットワーク遅延など）

ここでは、Pumbaコマンドの基本的な使い方を説明します。PumbaはCLI（コマンドラインインターフェース）ツールであり、コマンド一つ一つに対してオプションや対象コンテナ名を指定して実行します。基本構文と主要なオプションの使い方、そして実際の使用例を順に見ていきましょう。

Pumbaコマンドの基本構文と主要オプション

Pumbaのコマンド実行構文は以下のようになります。

pumba [グローバルオプション] サブコマンド [サブコマンド固有オプション] 対象コンテナ指定

例えば「特定のコンテナを停止する」場合、pumba stop コンテナ名 のように実行します。「5秒後に再起動させる」場合は、pumba --interval=5s restart コンテナ名 のようにグローバルオプションを付けて繰り返し実行も可能です。

主なグローバルオプションとしては次のようなものがあります。

• --interval, -i <時間>: カオスを繰り返す間隔を指定します（例: --interval 10sなら10秒おきに繰り返し）。既定では0で、一度きりの実行です。
• --random, -r: 対象コンテナが複数マッチした場合に、その中からランダムで1つだけ選んで障害を与えます。複数コンテナへの同時実行を避けたいときに便利です。
• --log-level, -l <レベル>: ログ出力の詳細度を指定します。デフォルトはwarningですが、デバッグ目的なら-l debugにすると詳細なログが得られます。
• --dry-run: ドライランモードです。実際には障害を発生させず、「計画されたカオス内容」をログに出力します。

これらのオプションを組み合わせることで、例えば「30秒おきにランダムなwebコンテナを停止し続ける」といった高度なシナリオもワンライナーで実行できます。

対象コンテナの指定方法（名前・リスト・正規表現）

Pumbaでは、コマンドの最後に対象とするコンテナを指定します。指定方法はいくつか柔軟に用意されており、用途に応じて使い分けます。

• コンテナ名を直接指定: 単一のコンテナに対して操作する場合、そのコンテナ名またはコンテナIDを直接書きます。例: pumba kill my-app-container
• コンテナ名のリスト: 複数のコンテナに同じ操作を行いたい場合、空白区切りで複数の名前を指定できます。例: pumba pause web1 web2 db1（web1, web2, db1の3コンテナを同時に一時停止）。
• 正規表現で指定: コンテナ名のパターンで対象をまとめて指定可能です。RE2形式の正規表現を"re2:パターン"の形で渡します。例: pumba stop "re2:^frontend" とすれば名前が”frontend”で始まる全てのコンテナが対象になります。
• ラベルでフィルタ: --label key=valueオプションを使って、特定のラベルを持つコンテナだけを対象にすることも可能です。複数の--label指定にも対応しています。

このように柔軟な指定方法が用意されているため、環境に合わせて狙ったコンテナ群に対して効率的にカオスを実行できます。多数のコンテナが稼働している場合は正規表現やラベル指定を活用すると便利です。

基本的な使用例: コンテナを停止する

それでは具体的な使用例として、コンテナを停止してみましょう。ここでは「myapp」という名前のコンテナを一時停止（stopではなくpauseを使用）し、数秒後に再開するシナリオを試します。

まず、単純に一度だけ停止する場合です。コマンドは以下のようになります。

pumba pause myapp --duration 5s

このコマンドは、コンテナ「myapp」を5秒間一時停止します。--duration 5sのオプションにより、一時停止の持続時間を5秒と指定しています。5秒経過すると自動的にコンテナは再開されます。実行中、別のターミナルでdocker psを見れば、対象コンテナがPaused状態になるのが確認できます。

一方、コンテナを完全に停止 (stop)させる場合はpumba stop コンテナ名を使います。stopコマンドは停止を指示するだけで、durationオプションは不要です（stopの場合コンテナは終了状態になり自動再開されません）。例えばpumba stop myappと実行すれば、myappコンテナは終了します。試しに停止後にdocker ps -aで状態を確認すると、myappがExitedになっているはずです。

このように、単純なコンテナ停止操作であればkill（強制終了）やstop（正常終了）、pause（一時停止）コマンドを使い分けることで実現できます。サービスの挙動を確かめたい目的に応じて、適切な方法を選びましょう。

基本的な使用例: ネットワーク遅延を発生させる

次に、コンテナのネットワークに遅延を注入する使用例を紹介します。データベースコンテナ「mydb」に対して、ネットワークの応答を人工的に遅らせ、その影響を観察するシナリオを考えます。

Pumbaではネットワーク関連の障害注入にnetemコマンドを使用します。netemはLinuxのネットワークエミュレーション機能を利用しており、遅延（delay）、パケットロス（loss）、帯域制限（rate）など様々なネットワーク異常を再現できます。ここでは遅延を与えるdelayサブコマンドを使います。

pumba netem --duration 10s delay --time 1000 --jitter 100 mydb

このコマンドは、「mydbコンテナに対し、10秒間、1000msの遅延（ジッタ±100ms付き）を発生させる」という意味になります。内訳を見てみましょう。

• --duration 10s: 障害を持続させる時間を10秒に設定。
• delay --time 1000 --jitter 100: netemのdelay機能を使い、遅延時間を1000ms（1秒）、変動幅を±100msに設定。
• mydb: 対象コンテナ名。

このコマンドを実行すると、mydbコンテナが外部と通信する際、すべてのネットワークパケットに約1秒の遅延が追加されます。例えばアプリケーションがmydbにクエリを投げると、通常より1秒遅れて応答が返ってくるようになります。10秒経過すると自動的に遅延は解除されます。

ネットワーク遅延の効果として、アプリケーション側でタイムアウトが発生したり、全体のレスポンスが悪化したりするかもしれません。そうした挙動を確認し、タイムアウト値の適切さやリトライロジックの有無などを検証できるのがこのテストの狙いです。

周期的な障害注入（–intervalオプションの活用）

Pumbaの強力な機能の一つに、障害注入を定期的に繰り返すオプションがあります。それが--intervalオプションです。これを指定すると、単発ではなく指定した間隔でコマンドが何度も実行されます。

例として、「webという名前を含むコンテナ群の中から1つをランダムに選んで30秒ごとに停止し続ける」というシナリオを構築してみます。コマンドは次のようになります。

pumba --random --interval=30s kill "re2:web"

ここでは、"re2:web"で名前に”web”が含まれる全コンテナを対象としつつ、--randomオプションにより毎回その中から1つだけを選んでいます。さらに--interval=30sを指定しているため、このkill操作が30秒おきに実行され続けます。すなわち、30秒ごとにどれか一つのWeb系コンテナが強制終了される状態です。

このような設定を一定時間動かしておけば、システムが常時どこかで障害に見舞われているカオス状態を再現できます。耐障害性のテストとして、長時間運用して問題がないかチェックすることが可能です。実験終了時には手動でこのPumbaプロセスを停止すれば、障害注入も止まります。

なお、intervalを使う際は--durationと併用することもできます。例えば--interval 1m --duration 10sとすれば「毎分10秒間の障害を発生させる」という繰り返しになります。目的に応じてパラメータを調整しましょう。

ドライラン実行（–dry-runオプションの活用）

Pumbaには、安全に実行計画をテストするためのドライラン機能が備わっています。--dry-runオプションを付けてコマンドを実行すると、実際には障害を起こさずにログメッセージだけを出力します。これにより、「本当に実行したらどうなるか」をシミュレーションできます。

たとえば、pumba --dry-run kill frontendと実行してみます。すると端末上に「特定のコンテナに対しkillコマンドを実行する予定である」旨のログが表示されます。しかし実際にはfrontendコンテナは止まりません。ドライランではDocker APIへの破壊的なコールを抑制しており、計画の確認専用モードとなっています。

この機能は、本番環境に対してPumbaを実行する前のリハーサルとして有用です。「対象の指定が正しいか」「コマンドオプションの指定ミスがないか」などをdry-runでチェックし、問題なければ--dry-runを外して本番実行する、という手順を踏めば安全性が高まります。また--dry-runの出力ログは運用ドキュメントとして残しておくことで、どういったカオス実験を実施したかの記録にもなります。

以上、Pumbaの基本操作として、コマンド構文やオプション、そして基本的な使用例を紹介しました。次章では、より具体的な障害シナリオごとの使い方や、Pumbaが提供する各コマンドの詳細について見ていきます。

Pumbaを用いたコンテナ障害・ネットワーク障害のシミュレーション方法: 具体的なシナリオと実行手順を紹介

ここからは、Pumbaで再現できる具体的な障害シナリオを「コンテナ障害」と「ネットワーク障害」に大別して解説します。コンテナそのものに対する障害（プロセスの強制終了やリソース逼迫など）と、ネットワークに関する障害（遅延やパケット損失など）では対策も異なるため、それぞれのシミュレーション方法を押さえておきましょう。

コンテナ障害の種類とPumbaでのアプローチ

コンテナ障害とは、コンテナ内で動作するアプリケーション自体に影響を与える障害のことです。代表的なものに以下があります。

• プロセスの突然死: コンテナ内のプロセスがクラッシュまたはkill信号により終了する。
• 正常終了: コンテナが通常のシャットダウン手順で停止する。
• プロセスのフリーズ: コンテナ内プロセスがハングし、応答しなくなる（一時停止状態）。
• リソース逼迫: CPUやメモリ、I/Oが異常に消費され、パフォーマンスが低下する。
• コンテナ消失: コンテナが削除され、存在しなくなる。

Pumbaでは、これらのコンテナ障害を再現するために各種コマンドを提供しています。killやstopコマンドでプロセス終了、pauseでフリーズ状態、stressでリソース逼迫、rmでコンテナ削除といった具合です。次節以降で、それぞれの具体的なシミュレーション方法と手順を見ていきます。

コンテナの強制終了や停止のシミュレーション（kill/stopコマンド）

システムの堅牢性検証で最も基本となるのが、コンテナの突然の終了をシミュレーションすることです。Pumbaではkillコマンドとstopコマンドを使ってこれを実現します。

killコマンドは、コンテナに対してSIGKILLシグナル（強制終了）を送り、即座にプロセスを終了させます。例えばpumba kill api-serverと実行すれば、「api-server」という名前のコンテナは警告なく終了します。SIGKILLのためアプリケーション側でのグレースフルシャットダウン処理は行われず、文字通り突然死となります。

stopコマンドは、Dockerの停止シグナル（既定ではSIGTERM）を送り、一定の猶予期間後にコンテナを終了させます。pumba stop api-serverを実行すると、まずコンテナ内プロセスに終了要求が送られ、プロセスが自主的に終了しなかった場合はタイムアウト後に強制終了されます。stopはgracefulな終了プロセスを経る点がkillと異なります。

これらをテストすることで、「コンテナが予告なく落ちた場合」と「通常のシャットダウン手順で落ちた場合」の両方について、システムの挙動を検証できます。例えば、killで突然落としてもコンテナオーケストレーター（DockerやKubernetes）が自動再起動してサービス継続するか、stopで順次停止した場合に他の依存サービスがタイムアウトなく終了を検知できるか、といった確認が可能です。

また、複数コンテナを対象にすることも重要です。例えば「全てのアプリケーションコンテナが同時に再起動したら」を試すには、対象コンテナを複数指定してpumba kill app1 app2 app3のように実行します。Pumbaはデフォルトで指定された全コンテナに対し同時にコマンドを適用するため、一斉障害のシナリオも再現できます。

コンテナリソース逼迫のシミュレーション（stressコマンド）

次に、CPU使用率やメモリ消費が急上昇するようなリソース逼迫障害を再現する方法です。これにはPumbaのstressコマンドを使用します。stressコマンドは、対象コンテナのcgroupに対して負荷をかけることで、コンテナ内のリソースを消費させる特殊な手法を取ります。

具体的には、Pumbaが内部でstress-ngという負荷発生ツールを用いて実現しています。pumba stress --duration 30s --stressors "--cpu 2 --vm 1 --vm-bytes 256M" web-server のように実行すると、web-serverコンテナに対して30秒間、2CPUコアを100%使い、メモリ256MBを確保し続ける負荷をかけます。--stressorsオプションで与えている引数はstress-ngのパラメータで、CPU負荷やメモリ確保など様々な負荷を組み合わせ指定可能です。

このコマンドにより、web-serverコンテナではCPU使用率が急上昇し、メモリも指定量消費されます。その間、アプリケーションの応答時間が著しく悪化したり、場合によってはOOMキラーが発動してプロセスが落ちたりするかもしれません。こうした挙動をチェックし、負荷時の性能プロファイルや自動スケーリングの挙動を検証するのが目的です。

stressコマンド実行には、Pumbaが別途Dockerイメージ（alexeiled/stress-ng:latest-ubuntuなど）を利用して負荷を注入していることに留意してください。そのため初回実行時には該当イメージのダウンロードが発生します。負荷テスト完了後は、--duration経過により自動的に負荷が解除され、コンテナは通常状態に戻ります。

リソース逼迫シミュレーションを通じて、アプリケーションが高負荷に耐えられるか、リソース監視やアラートが適切に機能するか、といったポイントを事前に確認できます。

ネットワーク障害の種類とPumbaでの手法

次にネットワーク障害のシミュレーションです。ネットワーク障害として考えられるパターンには、

• 遅延: 通信に通常以上の時間がかかる（高レイテンシ）。
• パケットロス: 一部のパケットが途中で失われる。
• 重複・乱序: パケットが重複したり順番が入れ替わったりする。
• 帯域制限: 通信速度に上限がかかり帯域が狭まる。
• 接続断: 特定のIPやポートへの通信が通じなくなる。

Pumbaでは、これらをエミュレートするためにnetemコマンドとiptablesコマンドを提供しています。netemコマンドはLinuxカーネルのネットワークエミュレーション機能を活用し、主に遅延・パケットロス・重複・帯域制限など、出力方向の通信に影響を与える障害を再現します。一方、iptablesコマンドはLinuxのパケットフィルタリング機能を利用し、入力方向の通信に障害を発生させる際に用います（例えば特定ポートをブロックする等）。

一般的なシナリオではnetemコマンドだけで事足りることが多いですが、より精細なネットワークカオス実験を行う際にはiptablesコマンドと組み合わせることで、双方向の通信異常を発生させることも可能です。それでは主要なネットワーク障害シナリオである「遅延」と「パケットロス・帯域制限」について、具体的なPumbaの使い方を見てみましょう。

ネットワーク遅延のシミュレーション（delayオプション）

ネットワーク遅延のシミュレーションは、先述の使用例でも紹介したようにnetem delayサブコマンドで行います。例えば、あるサービス間通信に常に50msの遅延が発生する状況を再現したい場合、以下のようなコマンドになります。

pumba netem --duration 1m delay --time 50 --jitter 5 service-container

この例では、「service-container」コンテナに対し、1分間、平均50ms（±5ms）のネットワーク遅延を付与しています。結果として、そのコンテナが送信する全てのパケットは本来より50ms遅れて届けられるようになります。

遅延シミュレーションによって確認すべき点は、タイムアウトやリトライの挙動です。例えばマイクロサービス間のAPIコールで50msの遅延が入った場合、ユーザー体感では大きな問題にならなくても、内部でチェーンがあるとトータルの遅延が積み重なり応答時間が増大する可能性があります。また、遅延が予想以上に大きい場合に適切にタイムアウトしてエラー処理するかも重要な観点です。

このように、delayを用いることでネットワーク品質が劣化した状況でもサービスが許容範囲内で動作し続けるか検証できます。

パケットロス・帯域制限のシミュレーション（loss/rateオプション）

次はネットワークのパケット損失や帯域制限を再現する方法です。Pumbaのnetemコマンドには、lossサブコマンドでパケットロス、rateサブコマンドで帯域制限を行う機能があります。

パケットロスの例として、「10%のパケットロスが発生するネットワーク」を作るには以下のようにします。

pumba netem --duration 20s loss --percent 10 payment-service

このコマンドは、payment-serviceコンテナから送信されるパケットの10%をランダムにドロップします（20秒間継続）。これにより、通信相手から見ると、時折リクエストや応答が届かない状況が再現されます。システム側では再送処理やエラー処理が正常に機能するかを検証できます。

帯域制限の例として、「帯域幅1Mbpsに制限されたネットワーク」を再現するには以下のようにします。

pumba netem --duration 30s rate --rate 1mbit cache-server

これにより、cache-serverコンテナのネットワーク送信速度は1メガビット/秒に制限されます（30秒間継続）。大量データ転送時にスループットが低下した場合のシステム挙動や、ユーザーへの影響を観察できます。

パケットロスや帯域制限は、遅延とはまた異なる影響をシステムにもたらします。パケットロスでは再送が発生するため遅延以上に処理時間が読みにくくなったり、場合によってはプロトコル上エラーとなることもあります。帯域制限ではバッファリングが発生し、データ処理が追いつかなくなるケースも考えられます。これらをPumbaで手軽に試せることで、ネットワーク品質が低下した際のアプリケーションの堅牢性を評価できるわけです。

なお、非常に高度なシナリオとして、Pumbaのiptablesコマンドとnetemコマンドを組み合わせ、例えば「特定IPへのパケットだけドロップ」なども実現できます。しかし一般的にはここまで細かい制御は必要なく、上記の遅延・ロス・帯域制限の組み合わせで十分なケースが多いでしょう。

以上、コンテナ障害およびネットワーク障害をPumbaでシミュレートする代表的な方法を紹介しました。次の節では、Pumbaが提供する具体的なコマンド群について一覧形式で整理し、各コマンドの詳細と使い所を説明します。

Pumbaでできる主なコマンド一覧: コンテナ停止・再起動・ネットワーク遅延・リソース負荷など代表的な機能を解説

Pumbaが提供する具体的なサブコマンドとその機能について整理します。以下に主なコマンドを挙げ、その概要と使いどころを説明します。これを把握しておけば、目的に応じて適切なコマンドを選択できるようになるでしょう。

コンテナを停止・再起動するコマンド（kill / stop / restart）の概要と使いどころ

kill、stop、restartは、いずれもコンテナの稼働状態を変化させるコマンドです。先述の通り、killはコンテナプロセスにSIGKILLを送り即座に強制終了させるもので、stopはSIGTERMによる正常停止（グレースフルシャットダウン）の指示、restartは一旦停止した後に自動で再起動させます。

使いどころ:
killは最も過激な停止方法で、障害シナリオとして「予告なくプロセスが消える」ケースに対応します。stopは一般的なシャットダウンシーケンスをテストしたい場合に向いています。restartは停止と起動の組み合わせで、一時的な障害からサービスが復旧する流れを検証する際に便利です。例えば、pumba restart webとすればwebコンテナが再起動し、アプリケーションが再起動時に正しく初期化されるか確認できます。

kill/stop系コマンドはいずれも無停止運用の検証に欠かせません。どの方法でもオーケストレーションツール（Docker/Kubernetes）が適切に対処するか、サービスにどんな影響が及ぶかを調べるのに役立ちます。

コンテナを一時停止するコマンド（pause）の概要とユースケース

pauseコマンドは、対象コンテナ内の全プロセスを一時的に停止（凍結）させます。コンテナ自体はRunning状態のままですが、中のプロセスがCPU実行を止められるため、外部から見ると応答がなくなります。

使いどころ:
pauseは「プロセスがハングした状態」をシミュレートする際に有効です。例えばデッドロックや無限ループ等でアプリが応答しなくなった場合、システム全体にどんな影響が出るか観察できます。pumba pause api-service --duration 15sのようにdurationを指定すれば、15秒間ハングしてから自動再開する動きを試せます。これにより、タイムアウト設定や監視プロセス（例えばKubernetesのLiveness Probe）が機能するか検証可能です。

pauseはkill/stopと異なりプロセスを殺さないため、一時停止中の状態から再開したときに正常動作に戻るかも含めてテストできます。

コンテナを削除するコマンド（rm）の概要と使いどころ

rmコマンドは、実行中のコンテナを削除します。これはDockerのdocker rm -fに相当し、コンテナを停止させた上でリソースごと取り除きます。

使いどころ:
rmは「コンテナそのものが消滅する」ケースに対応します。例えばKubernetesでPodがまるごと消えたり、スケールインでコンテナが減る状況です。pumba rm worker1のように実行すると、対象コンテナworker1は停止・削除されます。オーケストレーションが有効なら代替の新規コンテナが生成されるかもしれません。そうした再スケジューリングの挙動や、セッション情報が失われた場合の影響を知るのに有用です。

注意点として、削除したコンテナは同じ名前では二度と起動しません（新規に立ち上げ直す必要があります）。従って本番同様の自動復旧シナリオが組まれていないとサービスから永久に消えることになるため、rmコマンドのテストはオーケストレーションの仕組みとセットで考える必要があります。

コンテナ内でコマンドを実行するコマンド（exec）の概要とユースケース

execコマンドは、対象コンテナ内で任意のコマンドを実行させる機能です。Dockerのdocker execと同様に、コンテナ内のシェルでコマンドを走らせることができます。

使いどころ:
execはカオスエンジニアリングそのものよりも、補助的な操作に使われることが多いです。例えば障害シナリオを発生させる前準備としてコンテナ内のログレベルを変更するコマンドを実行したり、任意のスクリプトを投入して状態を変化させるなどが考えられます。また、ストレージ障害を模擬するためにexecでコンテナ内のファイルを大量生成する、といった使い方も可能です。

例として、pumba exec db-server -- touch /tmp/testfile と実行すれば、db-serverコンテナ内に/tmp/testfileというファイルを作成します。このようにexecは汎用性が高く、カオス実験の前後にコンテナ内部で環境を整える用途に適しています。

コンテナに負荷をかけるコマンド（stress）の概要と使いどころ

stressコマンドは、前述したようにコンテナに対してCPUやメモリの負荷を注入するための機能です。内部でstress-ngツールを利用し、コンテナのcgroupを操作することでリソース使用量を高めます。

使いどころ:
stressは高負荷時のシステム安定性を検証する際に使います。例えばトラフィック急増でCPUが飽和した場合にサービスがタイムアウトしないか、メモリ不足に陥った際にOutOfMemoryエラーへの対処ができているかをテストできます。pumba stress --cpu 2 --duration 60s appとすれば、appコンテナに2コア分のCPU負荷を60秒間与えます。複数リソースの同時負荷（CPUとメモリ両方など）も--stressorsオプションで指定可能です。

実運用では、負荷テストツールと組み合わせて行うことで効果を発揮します。例えば、通常の外部からの負荷試験を実施しつつ、裏でPumbaのstressコマンドで一部コンテナに負荷をかければ、より現実的なピーク時障害状況を再現できます。

ネットワーク障害を発生させるコマンド（netem）の概要とユースケース

netemコマンドは、ネットワーク関連の障害を発生させるための強力なコマンドです。delay（遅延）、loss（損失）、duplicate（重複）、corrupt（破損）、rate（帯域制限）といったサブコマンドを持ち、それぞれ異なるネットワーク異常を再現します。

使いどころ:
netemはマイクロサービス間の通信障害を検証する際の主役となるコマンドです。例えば、pumba netem --duration 2m delay --time 200 web-frontとすれば、フロントエンドコンテナからの通信に200msの遅延を2分間与えられます。これによりユーザーへのレスポンス時間がどの程度悪化するか評価できます。同様に、lossサブコマンドでパケットロス率を設定すれば再送発生時の影響を測れます。

netemコマンドは単発でも役立ちますが、--intervalと組み合わせて間欠的なネットワーク障害を繰り返すこともできます。定期的に遅延が発生したり回復したりする環境で、システムが適応できるかを見るテストも可能です。

ネットワークの質がサービスに与える影響は大きいため、netemを駆使したカオス実験は必須と言えるでしょう。

ネットワークパケットをフィルタリングするコマンド（iptables）の概要と使いどころ

iptablesコマンドは、名前の通りLinuxのiptablesを利用してパケットをフィルタリング（破棄や拒否）するためのコマンドです。主に受信側の通信に対する障害シナリオを作る際に使われます。

使いどころ:
iptablesコマンドは特定の通信を遮断するケースで有用です。例えばデータベースへの接続が突然切れた場合を試すには、pumba iptables --protocol tcp --port 3306 --drop app-server のように実行します。これはapp-serverコンテナに対し、TCPポート3306（典型的にはMySQLのポート）へのパケットをドロップさせる設定です。結果としてapp-serverからデータベースへの通信が通らなくなり、アプリケーション側でDB接続エラー処理が正しく動作するか検証できます。

iptablesは細かな条件設定（プロトコル、ポート、送信元/宛先IPなど）が可能なため、特定のサービス間のみ通信遮断するような絞り込みもできます。ネットワーク分断や部分的なネットワーク障害シナリオ（例えば片方向通信不能）など、netemでは表現しきれない状況を作り出せます。

以上、Pumbaの主要コマンドについてその機能と使いどころを説明しました。これらを組み合わせることで、多彩な障害シナリオを自由に設計できることがお分かりいただけたと思います。次章では、Kubernetes環境でPumbaを活用する際のポイントについて解説します。

Kubernetes環境でのPumbaの利用方法: DaemonSetを用いた全ノードへのデプロイとPodへの障害注入の手順

Docker単体での使用だけでなく、PumbaはKubernetesクラスタ上でも活用できます。ただしKubernetes環境特有の注意点や設定が必要です。ここでは、Kubernetes上でPumbaを使うメリットと、典型的な導入手順（DaemonSetによる展開）、さらにPodを対象に障害を注入する方法やセキュリティ上の考慮事項について説明します。

Kubernetesクラスタ上でPumbaを利用するメリットと注意点

Kubernetes上でPumbaを使う主なメリットは、クラスタ全体に対して統一的にカオス実験を仕掛けられることです。複数ノードにまたがるPod群に対し、一括で障害注入シナリオを適用できるため、大規模な耐障害テストが容易になります。また、Kubernetesネイティブのカオスツール（後述するChaos Mesh等）を導入しなくとも、既存のDocker向けツールであるPumbaを再利用できる点も利点です。

一方で注意点として、Pumbaは基本的に各ノードのDockerエンジンにアクセスしてコンテナ操作を行うため、コンテナランタイムがDockerで動作している必要があります。近年のKubernetesではデフォルトランタイムがcontainerd等Docker以外の場合も多いため、その環境ではPumbaは直接機能しません（Dockerデーモンがないため）。Dockerランタイムを使用しているクラスタ、または別途ノードにDockerデーモンを用意しているケースでPumbaを使うのが前提となります。

また、Kubernetes上でPumbaを動かすには各ノードで特権的なアクセス権限が必要となるため、セキュリティポリシー上の配慮も必要です。次項から具体的な展開方法を説明していきます。

DaemonSetでPumbaコンテナを各ノードに配置する方法

Kubernetes上でPumbaを継続的に使うには、各ノードにPumbaのインスタンスを動かすのが効率的です。そのためにDaemonSetを利用します。DaemonSetを使用すると、クラスタ内の全ノード（または特定のラベルのノード）上でPumbaコンテナを1つずつ実行できます。

DaemonSetによる展開のポイント:

• Pumbaの公式Dockerイメージ（例: gaiaadm/pumba:latest）を用いてPodを作成する。
• 各Podにホストの/var/run/docker.sockをマウントする。これによりPod内のPumbaがホストのDockerにアクセスできます。
• Pumbaコンテナを特権モード（securityContext.privileged: true）で実行する。ネットワーク操作やcgroup操作に必要です。
• 必要に応じて、特定のNamespace内のPodに限定して影響を与えるためDaemonSet Podに適切なラベルを付与したり、RBACで実行を制限したりすると良いでしょう。

DaemonSetのマニフェスト例としては、下記のようなイメージです。

apiVersion: apps/v1 kind: DaemonSet metadata: name: pumba spec: selector: matchLabels: app: pumba template: metadata: labels: app: pumba spec: containers: - name: pumba image: gaiaadm/pumba:latest securityContext: privileged: true volumeMounts: - name: dockersock mountPath: /var/run/docker.sock volumes: - name: dockersock hostPath: path: /var/run/docker.sock

このDaemonSetを適用すると、各ノードでPumbaが待機する状態になります。あとは各Pumba Podに対してkubectl execなどでコマンドを送り、障害注入を実行させることができます（後述）。

障害を注入する対象Podの指定方法（ラベルや正規表現の活用）

Kubernetes環境では、「どのPod（コンテナ）に障害を発生させるか」を指定する必要があります。前述のようにPumba自体はノード上のDockerコンテナ名で対象を選択するため、Kubernetesの文脈に合わせた工夫が必要です。

一般的なアプローチの一つは、Pod名のパターンで指定する方法です。Kubernetesの各コンテナ名は通常、k8s_<コンテナ名>_<ランダムID>という形式のDockerコンテナ名になります。そこで、Pod名やコンテナ名に含まれるユニークな部分を正規表現でマッチさせることで対象を絞り込めます。例えばデプロイメント”frontend”のPodに属するコンテナ全てを狙うなら、Dockerコンテナ名に”frontend”が含まれるため、"re2:frontend"と指定すれば該当コンテナを捕捉できます。

また、Pumbaの--labelオプションを利用する方法もあります。Kubernetesではデフォルトで各コンテナにいくつかのDockerラベル（例えばio.kubernetes.pod.nameにPod名が入る）が付与されています。--label io.kubernetes.pod.name=frontend-abcdeのようにPod名でフィルタすることも可能ですし、Namespace名や他のメタ情報もラベルとして使えます。DeploymentやStatefulSetでPodに任意のラベルを注入しておき、それをコンテナのDockerラベルに反映させる設定をすると、より直感的に対象指定ができます。

DaemonSetで動いているPumbaに対しては、kubectl execでコマンドを送り実行させます。例えば、”frontend”という文字を含むコンテナをランダムに落とす場合、DaemonSetの各Podで以下を実行します。

kubectl exec pumba-<ノード名> -- \ pumba --random kill "re2:frontend"

各ノード上のPumbaが自分のノード内で該当するコンテナを探し、ランダムにkillを実行します。このようにしてKubernetes上でもPod単位の障害注入が可能となります。

Kubernetes環境での障害注入例（Pod強制終了のシナリオ）

具体的なシナリオ例として、KubernetesのDeploymentで稼働中のPodを一つ強制終了させ、その自動復旧を確かめるケースを考えます。

前提: フロントエンドアプリケーションのDeploymentがレプリカ3で稼働中とします（Podが3つある）。

シナリオ: 任意の1つのfrontend PodをPumbaでkillし、Deploymentコントローラが速やかに新しいPodを再生成するか確認する。

手順:

1. Pumba DaemonSetを適用し、各ノードでPumbaが動作していることを確認。
2. 任意のPumba Pod（例えばノード1上の）に対し、frontend Podのコンテナをkillするコマンドを実行。
   例: kubectl exec pumba-node1 -- pumba --random kill "re2:frontend"
   *ここで–randomを付与しているのは、仮にノード1上にfrontend Podが複数いても1つだけを対象とするため。
3. 実行後、kubectlでPodの状況を監視。対象のPodが消えて、新しいPodがRunning状態で立ち上がるか確認する。
4. サービス全体としてリクエストがエラーなく処理され続けているか（Pod消失中に一時的なエラーがなかったか）をモニタリングデータなどでチェック。

このような実験を通じて、Kubernetesの自己修復機能が正常に動作すること、アプリケーションが一部Pod喪失に耐えられることを実証できます。さらに高度な例では、ネットワーク分断をシミュレートするために、特定ノード上のPod全てに対しiptablesコマンドで通信遮断を行う、といったシナリオも可能です。

Pumba利用時のセキュリティと権限設定の注意点

Kubernetes環境でPumbaを運用する場合、セキュリティ面でも注意が必要です。PumbaはDockerソケットに直接アクセスしコンテナを制御するため、特権コンテナとして動作させる必要があります。これは潜在的にホストへのフルアクセス権を与えることになるため、悪用されれば危険です。従って、PumbaのDaemonSetには適切なRBAC設定やNetworkPolicyを適用し、信頼できる権限範囲内でのみ動作させることが重要です。

具体的には、Pumba Podが不要な場合に外部から操作されないよう、kubectl execを許可するユーザを限定したり、Namespaceを隔離したりすると良いでしょう。また、試験環境やステージング環境でまず実施し、本番環境で行う場合も影響範囲を段階的に広げるなど慎重な計画が求められます。

最後に、前述したようにKubernetesのコンテナランタイムがDocker以外の場合、Pumbaはそのままでは利用できません。その際はCNCFが提供するChaos MeshやLitmusChaosなど、Kubernetesネイティブに作られたカオスエンジニアリングツールの利用を検討してください。

以上の点に留意すれば、Kubernetes環境でもPumbaを用いたカオスエンジニアリングを安全かつ効果的に実践することができます。次章では、実際にPumbaを使った実験例を取り上げ、その結果と考察を紹介します。

実際にPumbaで試してみる: コンテナ障害シミュレーションの実験・検証例とその結果を詳しくレポート

ここでは、Pumbaを使ったカオスエンジニアリングの簡単な実験例を紹介します。小規模な環境を用意し、実際にコンテナ障害やネットワーク障害を発生させ、その結果を観察してみます。これにより、Pumbaの効果やシステムの応答を具体的にイメージできるでしょう。

検証環境の構築: テスト用コンテナの準備

まず、実験に使用する環境を整えます。単一ホスト上でDockerコンテナをいくつか立ち上げ、Pumbaを実行する形にしました。

• Webサーバーコンテナ: Nginxを使用（コンテナ名: web-test）。
  起動コマンド例: docker run -d --name web-test --restart=always -p 8080:80 nginx:alpine
• クライアントコンテナ: HTTPリクエストやpingを投げるためのAlpine Linux（コンテナ名: client）。
  起動後、このコンテナ内からweb-testへ定期的にHTTP GETおよびpingを実行し、応答をモニタ。
• Pumba実行環境: ホスト上にPumbaバイナリをインストール済み（前節の手順通り）。

上記のようにNginxが常時稼働してリクエストを捌き、クライアントがその応答を監視する仕組みを用意しました。Nginxコンテナには--restart=alwaysを付与し、万一停止しても自動再起動する設定にしています。これにより、障害発生時の自己復旧も確認できます。

シナリオ1: Pumbaでコンテナを強制終了させる実験

目的: Webサーバーコンテナweb-testが突然終了した場合に、自動再起動が機能しサービスが継続するか確認する。

手順: クライアントコンテナからの監視を開始した状態で、ホスト上で以下のPumbaコマンドを実行しました。

pumba kill web-test

これにより、web-testコンテナ（Nginx）は即座に強制終了されました。Dockerの再起動ポリシーalwaysが設定されていたため、約2秒後に自動的に新しいコンテナとしてweb-testが再起動しました。

結果: クライアントの監視ログによれば、Pumba実行直後のリクエストで一度だけエラー（接続失敗）が発生しましたが、その後すぐにNginxの応答が復旧しました。停止から再起動までのダウンタイムはごく短時間（約2〜3秒）で、クライアントのリトライ機構によりユーザーにはほとんど影響が出ない程度で済みました。

この実験から、Dockerの自動再起動設定が有効に機能し、単一コンテナのクラッシュ程度であればサービス継続性が保たれることを確認できました。一方で、再起動の瞬間にはやはりリクエスト障害が発生するため、アプリケーション側でリトライ処理や複数インスタンス構成による冗長化が望ましいこともわかります。

シナリオ2: Pumbaでネットワーク遅延を発生させる実験

目的: Webサーバーweb-testとクライアント間のネットワークに遅延が発生した場合、応答時間とシステム挙動がどう変化するかを確認する。

手順: Web-testコンテナは先ほどと同じ状態で稼働中とし、Pumbaで以下のコマンドを実行しました。

pumba netem --duration 30s delay --time 500 --jitter 100 web-test

このコマンドにより、web-testコンテナから出るパケット全てに平均500ms（±100ms）の遅延が30秒間加えられました。クライアントコンテナはこの間も5秒おきにHTTPリクエストを送り、応答時間を記録しました。

結果: 遅延注入中、クライアントから見たHTTP応答時間は平常時の数十ms程度から、一気に約550〜600ms程度に跳ね上がりました。しかし全てのリクエストで一応応答は返ってきており、タイムアウト（デフォルトでは設定なし、または数秒程度）は発生しませんでした。ただし、遅延注入が終了した直後の1回だけ、蓄積していた遅延の影響か応答に約1.2秒かかったケースがありました。

この実験で、アプリケーション自体は500ms程度の遅延には耐えて動作するものの、応答速度は明らかに低下することが確認できました。今回の遅延は意図的に大きめ（0.5秒）を入れましたが、それでもタイムアウトしなかったのは幸いでした。仮に1秒以上の遅延を入れた場合、クライアント側でタイムアウトエラーとなる可能性が高いことも示唆されます（一般的なWebクライアントは1秒以上遅いとユーザビリティに影響が出ます）。

実験結果の観察: Pumba実行後のコンテナ挙動

シナリオ1では、コンテナの強制終了に対して自動復旧が働く様子を観察しました。Docker単体の再起動機能でも短時間の障害なら対処可能ですが、例えばこれがKubernetesのDeploymentであれば、Podが再スケジュールされる間の短い間も他のPodが健在ならサービスは無停止である可能性があります。つまり、今回の単一コンテナ環境では一瞬エラーが発生しましたが、より冗長化された環境ならエラーすら発生しなかったでしょう。

シナリオ2では、ネットワーク品質の低下が即座にサービス体感に影響することを確認しました。500msの遅延でもレスポンスタイムが5倍以上に悪化しています。幸いエラーにはなりませんでしたが、これ以上の遅延やパケットロスが加わればアプリケーション側でタイムアウトや例外処理が走るでしょう。実験後にログを分析したところ、遅延注入中は内部でいくつかのDBクエリの処理時間が遅くなり、警告ログが出力されていました。これは本番環境で起きればアラートに繋がる可能性があるため、有用な発見と言えます。

得られた知見とベストプラクティス

今回の試行から、いくつかの知見が得られました。

• 自動復旧機構の重要性: コンテナが突然停止する事態に備え、Dockerの--restartやKubernetesのReplicaSetによる再起動機能が有効に働くことでダウンタイムを最小限に抑えられることを確認しました。無停止サービスを目指すなら冗長化と自動復旧は不可欠です。
• 遅延やネットワーク劣化への耐性: アプリケーションはある程度のネットワーク劣化には耐えられるものの、遅延が大きくなると性能低下やタイムアウトリスクが高まることが分かりました。ユーザビリティを損なわない範囲でのタイムアウト設定や、リトライ戦略の実装が重要であると再認識しました。
• モニタリングとログ: Pumbaによる障害注入中に出力されたログやメトリクス情報は、平常時には現れないシステムの挙動を示してくれました。例えば遅延時のDB警告ログなど、本番で潜在的な問題となり得る箇所を洗い出すヒントとなります。カオスエンジニアリング実施時は必ず十分なモニタリングをセットし、観測データを蓄積・分析することが重要です。

最後に、Pumbaを含むカオスエンジニアリングを安全かつ効果的に行うベストプラクティスとして、小さく始めて徐々に範囲を広げることが挙げられます。今回のようにまず単一コンテナで試し、次にステージング環境全体、本番でも一部トラフィックのみ、と段階を踏むことで、予期せぬ大事故を防ぎつつ信頼性向上を図れます。

以上の実験により、Pumbaは比較的簡単な操作で実践的な障害シナリオを再現できる有用なツールであることが実感できました。この経験を踏まえ、次章ではPumbaと他のカオスエンジニアリングツールを比較し、それぞれの特徴について考察します。

他のカオスエンジニアリングツールとの比較: Chaos MeshやGremlinなど主要ツールとの機能・用途の違いを解説

最後に、Pumbaとその他の代表的なカオスエンジニアリングツールを比較し、それぞれの特徴や適した用途について整理します。ここでは、オープンソースのChaos Mesh、商用サービスのGremlin、CNCFプロジェクトのLitmusChaosを取り上げ、Pumbaとの違いを見てみましょう。

Chaos Meshとの比較: Kubernetesネイティブなカオスツールとの機能差

Chaos Meshは、PingCAP社が開発し現在はCNCFサンドボックスプロジェクトとなっているKubernetes向けカオスエンジニアリングツールです。Kubernetes上で動作するCRD（カスタムリソース定義）を用いて、Podの障害、ネットワーク遅延、さらにKernelレベルの故障（IOエラーやシステムコールの失敗など）まで幅広くシナリオを設定できます。

Chaos Mesh vs Pumba:
Chaos MeshはKubernetes環境に深く統合されており、GUIダッシュボードで実験を管理できるなど高機能です。対してPumbaは単純なDockerコンテナ向けツールで、Kubernetesへの統合は自前で行う必要があります。Chaos Meshでは例えば「指定したDeploymentの任意のPodを毎秒50ms遅延」といったシナリオをYAMLで宣言的に記述でき、結果もCRDとして取得可能です。一方Pumbaはコマンドベースで手動実行が主体となります。

機能面では、Chaos Meshの方がサポートする障害の種類が多岐にわたります。例として、Chaos MeshはPodの故障以外に、Kubernetesコントロールプレーンの一部（例えばEtcd）を停止する実験なども可能です。また、チュートリアルやコミュニティサポートも充実しています。ただしその分学習コストやセットアップはPumbaより高く、まずシンプルにDockerコンテナレベルで試したい場合はPumbaが手軽です。

まとめると、Kubernetes環境における本格的なカオスエンジニアリングにはChaos Meshが適していますが、導入ハードルはやや高めです。Pumbaは規模の小さい実験やDocker単体の環境で素早く試したい場合に有用と言えるでしょう。

Gremlinとの比較: 商用カオスエンジニアリングサービスとの特徴の違いを徹底比較

Gremlinは、商用のカオスエンジニアリングプラットフォームです。専用のエージェントをサーバやコンテナにインストールして使用し、Web UIやAPI経由で様々な障害を注入できます。CPU飽和、メモリ消費、ディスクIO障害、ネットワーク障害、さらには特定プロセスのクラッシュなど幅広い攻撃（Attack）をサポートしています。

Gremlin vs Pumba:
Gremlinはエンタープライズ向けサービスらしく、洗練されたUIとワークフロー管理機能を備え、複数チームでのコラボレーションやスケジュール実行、安全装置（フェイルセーフ機能）などが充実しています。一方Pumbaは単機能なOSSツールであり、UIはなく手動実行が基本です。GremlinはKubernetes、VM、ベアメタルなど様々な環境に対応し、統一的に管理できるのに対し、PumbaはDockerコンテナに限られます。

例えばGremlinでは「新規攻撃シナリオ」をGUI上で作成し、サーバグループを選択して一斉にCPU使用率100%の障害を5分間与える、といった高度なスケジューリングも可能です。また攻撃終了後のレポートも自動生成され、SLA指標との比較なども容易です。Pumbaで同様のことをする場合、スクリプト等で各ホストにコマンドを配布し、手動で結果を集計する必要があります。

ただしGremlinは商用であるため利用にはコストが発生します。一方PumbaはOSSで誰でも自由に使用できます。予算や求める機能レベルに応じて選択が分かれるところです。総じて、小規模環境や予算制約下ではPumba、大規模かつ組織的な実践にはGremlinがフィットすると言えるでしょう。

LitmusChaosとの比較: CNCFサポートのカオスツールとの機能差異

LitmusChaosは、CNCFインキュベーション段階にあるオープンソースのカオスエンジニアリングツールセットです。LitmusもKubernetes上で動作し、CRDを通じて「カオスエクスペリメント」を管理します。特徴的なのは、あらかじめ用意された多数の実験シナリオ（ChaosHub）が提供されており、ユーザはそれらを組み合わせてカオスを実行できます。

Litmus vs Pumba:
LitmusChaosはChaos Meshと同様にKubernetesネイティブで、GUI（Litmus Portal）から実験をスケジューリングし結果を分析する仕組みが用意されています。Pumbaとの違いは、Litmusは一連の実験をワークフローとして繋げられる点や、結果をChaosResultリソースに蓄積して可視化できる点です。一方Pumbaは単発のコマンドベースで、結果の取得や分析は利用者側で工夫する必要があります。

また、Litmusはプラットフォームに依存せずカスタム実験を作成できる柔軟性があり、例えば特定アプリケーションに特化した障害シナリオを自作スクリプトで組み込むことも可能です。Pumbaは主にDocker操作に限られるため、シナリオの種類ではLitmusの方が拡張性があります。例えばKubernetesノードを強制再起動させる実験など、Pumbaでは扱えない範囲もLitmusならカバーできます。

総合すると、LitmusChaosはKubernetes上で体系的にカオスエンジニアリングを実施・管理したい場合に適し、Pumbaはその前段階としての簡易な実験や、Docker Swarm/単体環境での利用に適しています。

Pumbaと他ツールの使い分け: ユースケースに応じた選定ポイントを解説

以上を踏まえ、どのツールを選ぶべきかはユースケースによって決まります。選定のポイントをまとめます。

• 対象環境: Dockerコンテナのみの環境やDocker SwarmであればPumbaがシンプルで有効。一方、Kubernetes環境全体を網羅したいならChaos MeshやLitmusChaosが候補になります。VMやマルチクラウドを含む広範なインフラではGremlinなどの方が適しています。
• 学習コストと即時性: まず手元で試してみたい、という場合Pumbaの低い学習コストは魅力です。コマンド一発で始められるので導入のハードルが低いです。対してChaos Mesh/Litmusは環境構築に時間がかかりますが、一度整えば自動化・複雑なシナリオに強みを発揮します。
• 機能の網羅性: システム全体をまたぐような高度な障害（例: データセンター障害の模擬、外部サービスのフェイルなど）まで行いたい場合、Chaos MeshやGremlinの方が適しています。Pumbaは基本的にコンテナレベルの障害に限定されます。
• 予算とサポート: オープンソースでコストを抑えたいならPumba/Chaos Mesh/LitmusChaosが選択肢です。企業でサポート付きの安心感が欲しいならGremlin等の商用サービスが候補になります。コミュニティも、Chaos MeshやLitmusは活発で情報入手がしやすいです。

まとめると、小規模でスタートするならPumba、Kubernetesに深く組み込むならChaos Mesh/LitmusChaos、エンタープライズで包括的に行うならGremlin、といった棲み分けになります。それぞれのツールに強みがあるため、段階に応じて使い分けることも可能です。重要なのは、どのツールを使うにせよカオスエンジニアリングを継続的に実施し、得られた知見をシステムの堅牢化に反映させていく姿勢です。

以上、Pumbaと主要なカオスエンジニアリングツールとの比較を解説しました。本記事全体を通じて、Pumbaの概要から具体的な使い方、そして他ツールとの差異まで俯瞰できたことで、皆様の環境に適したアプローチを検討する一助になれば幸いです。