【ITニュース解説】How I Fixed a 100% Disk Usage Issue Caused by Stuck etcd Backups in Kubernetes

この出来事は、Kubernetes環境で運用されるシステムの信頼性を守る上で、バックアップがいかに重要であり、同時に注意が必要であるかを教えてくれる事例だ。システムエンジニアを目指す人にとって、日々の運用で起こりうるトラブルとその解決策、そして予防策を学ぶ良い機会となるだろう。

ある日、Kubernetesの基盤を構成するマスターノードの一つで、ルートファイルシステムの使用率が100%に達していることが発覚した。マスターノードとは、Kubernetesという複数のコンピューターを連携させて一つの大きなシステムとして動かすための仕組みにおいて、全体の管理や指示を行う司令塔のような役割を担う重要なコンピューターだ。ディスク使用率が100%になると、新しいファイルが保存できなくなり、システムがログを書き込めなくなったり、一時ファイルを作成できなくなったりするなど、正常な動作ができなくなる可能性がある。これは、システム全体に深刻な影響を及ぼしかねない緊急事態であった。

最初に疑われたのは、一般的なディスク容量不足の原因、例えばログファイルの肥大化やコンテナイメージの増加などだった。しかし、詳細な調査を進めると、問題の根源は「etcd」のバックアップにあることが判明した。etcdは、Kubernetesクラスターのすべての設定情報や状態を保存する、非常に重要なデータベースだ。このetcdのデータが失われると、Kubernetesクラスター全体が機能しなくなるため、定期的なバックアップは災害復旧の要となる。

調査の結果、マスターノードの/home/k8-node5/etcd-backupsというディレクトリに、数カ月前からの古いバックアップファイルが大量に蓄積されていることがわかった。それぞれのバックアップファイルは約693MBと決して小さくないため、これらが数百個も溜まれば、あっという間にディスク容量を圧迫してしまう。さらに悪いことに、.db.partという一時ファイルが多数見つかり、複数のetcdctl snapshot saveというバックアッププロセスが途中で停止したままになっていることも判明した。これは、バックアップが正常に完了せず、リソースを占有し続けている状態を示していた。

この状況は、単なるディスク容量不足の問題ではなく、バックアップの自動化における信頼性の問題だった。元々設定されていたcronジョブ（指定した時間にコマンドを自動実行する仕組み）は、毎日午前3時にetcdのバックアップを実行するようになっていたが、もしバックアップ処理に時間がかかりすぎたり、途中で停止してしまったりした場合に、それを強制終了する仕組みがなかった。また、複数のバックアップが同時に実行されるのを防ぐための排他制御も不足していた。さらに、古いバックアップファイルを自動的に削除する「保持ポリシー」が設定されていなかったため、バックアップはただ蓄積され続ける一方だったのだ。

問題の原因が特定できたため、まずは緊急対処として、停止してディスクを圧迫しているバックアッププロセスを安全に終了させた。pkill -TERM -fというコマンドを使って、特定のバックアッププロセスのみを対象に終了シグナルを送ることで、他の重要なプロセスに影響を与えることなく停止させたのだ。その後、バックアップディレクトリ内の古いスナップショットファイルと、途中で作成された一時ファイルを削除してディスク容量を回復させた。これにより、ディスク使用率は100%から11%へと大幅に改善し、約165GBの空き容量が確保され、システムの正常な動作が回復した。

しかし、これは一時的な対処に過ぎない。根本的な解決のためには、バックアッププロセスそのものを改善する必要があった。そこで、元のcronコマンドをより堅牢なシェルスクリプトに置き換えた。新しいスクリプトには、以下の重要な改善が加えられた。

第一に、「タイムアウト機能」を導入した。timeoutコマンドを使うことで、バックアップ処理が30分を超えても終わらない場合に、強制的に終了させるようにしたのだ。これにより、プロセスが途中で停止したままになり、リソースを占有し続ける事態を防ぐことができる。 第二に、「排他制御」としてflockコマンドを利用した。これは、スクリプトが実行されている間、ロックファイルを作成することで、同じスクリプトが同時に複数起動するのを防ぐ仕組みだ。これにより、複数のバックアップ処理が重なることによるシステム負荷の増加や、データの整合性に関する問題を回避する。 第三に、「保持ポリシー」を設定した。最新の7日間のバックアップのみを保持し、それより古いものは自動的に削除するルールを導入したのだ。これにより、バックアップファイルの無制限な蓄積を防ぎ、ディスク容量を適切に管理できるようになった。ただし、保持ポリシーの運用は慎重に行う必要があり、削除する前にバックアップが正常であることを確認するステップも重要だ。 第四に、「ロギングの改善」を行った。スクリプトの実行状況やエラーメッセージを専用のログファイルに記録するように設定し、バックアップの成功・失敗や、途中で何が起きたのかを後から簡単に確認できるようにした。

これらの変更を適用した後、cronジョブも新しいシェルスクリプトを実行するように更新した。そして、新しいバックアップスクリプトが正しく動作するかを実際に手動で実行し、生成されたバックアップファイルが正常であることをetcdctl snapshot statusコマンドで検証した。これは、バックアップが単に「作成された」というだけでなく、「いつでも復元できる状態である」ことを確認する上で不可欠なステップだ。

この解決策を他のマスターノードにも適用する際にも、安易なコピー＆ペーストは避けられた。各ノードのetcdのエンドポイントや証明書の設定は異なる場合があるため、一つ一つ慎重に確認し、そのノードに適した設定を行うことが重要だと判断された。

この一連の出来事から、いくつかの重要な教訓が得られた。まず、ディスク使用率が異常な場合は、df -hやduコマンドを使って、何がディスクを占有しているのかを具体的に調査することが肝心だ。次に、cronジョブのような自動化された処理には、単にスケジュールするだけでなく、処理が長引きすぎた場合のタイムアウト、重複実行を防ぐ排他制御、そして古いデータを自動で削除する保持ポリシーといった「運用上の安全策」が不可欠だということがわかった。そして、バックアップが成功したというメッセージだけで安心せず、実際にそのバックアップが壊れていないか、いざという時に復元可能かを定期的に検証することの重要性も再認識された。さらに、バックアップファイルは、万が一のサーバー故障に備えて、バックアップ元とは別の安全な場所にコピーしておくことも忘れてはならない。

結論として、今回のディスク使用率100%の問題は、表面上は単純な容量不足に見えたが、その裏にはバックアッププロセスの信頼性に関わる深い問題が潜んでいた。適切な調査、一時的な対処、そして根本的な改善策の導入を通じて、問題は解決され、システムの信頼性は大きく向上した。信頼できるバックアップシステムとは、単なるスケジュールされたコマンドではなく、継続的な監視、障害発生時の対応、データの検証、適切な保持ポリシー、そしていつでも復旧できるという確信に裏打ちされたものであることを、この経験は強く示唆している。