【ITニュース解説】500 Spark Tasks Finished. One Didn’t.

システムエンジニアとして、大量のデータを効率的に処理する技術は非常に重要だ。近年では「ビッグデータ」という言葉を耳にする機会も増え、それに伴い大量のデータを複数のコンピューターで分担して処理する「分散コンピューティング」という考え方が広く使われるようになった。今回取り上げる内容は、まさにこの分散コンピューティング環境で発生した、非常に興味深いパフォーマンス問題の事例だ。

この事例では、「Apache Spark（アパッチ スパーク）」という、まさに大量データを高速に処理するための分散処理フレームワークが使われていた。Sparkは、一つの大きな処理を「タスク」と呼ばれる小さな単位に分割し、それらを複数のコンピューター（「ノード」と呼ぶ）に分散させて並行して実行することで、全体の処理時間を短縮する。今回のケースでは、合計500個のSparkタスクが実行されたが、そのうち499個は問題なく、非常に短時間で完了した。しかし、たった1個のタスクだけが異常に時間がかかり、最終的にはシステムが定めた時間内に終わらず、タイムアウトしてしまったのだ。他のほとんどのタスクがスムーズに完了している中で、なぜ特定の1タスクだけがこのような事態に陥ったのか。これは、システムを運用する上で直面しうる、非常に現実的で困難な問題の一つと言える。

この問題の解決に向けて、まず最初に疑われたのはいくつかの一般的な原因だった。一つは「データスキュー」と呼ばれる現象だ。これは、処理すべきデータが特定のノードに偏ってしまい、そのノードだけが過剰な負荷を背負うことで処理が遅れるというもの。しかし、今回のケースでは異なる種類のデータでも同様の問題が発生したため、データスキューが原因ではないと判断された。次に考えられたのは、Java言語で書かれたプログラムが動く「JVM（Java Virtual Machine）」における「ガーベージコレクション（GC）」の問題だ。GCは不要になったメモリを自動的に解放する仕組みだが、これが頻繁に発生しすぎると処理速度が低下することがある。しかし、GCのログを詳しく調べても、特に異常は見つからなかった。さらに、ノード間のデータ通信に問題がある「ネットワークの問題」も疑われたが、他の大量のタスクが正常に動いていることから、これも有力な原因とは考えられなかった。

このように、一般的な原因を一つずつ潰していく中で、事態はより深掘りした調査へと移っていった。Sparkには「Spark UI」という管理画面があり、これを使うと各タスクやノードの実行状況を詳細に確認できる。このSpark UIや、システム全体の監視に使われる「Ganglia（ガングリア）」というツールを使ってノードごとのCPU使用率を監視したところ、問題のタスクが割り当てられた特定のノードで、なぜかCPUの使用率が非常に低いという奇妙な状況が発見された。これは、Sparkタスクが十分なCPUリソースを使えていないことを示唆していた。

そこで、問題のノードに直接ログインし、さらに詳細なリソース状況を調べるために「dstat（ディースタット）」というコマンドが実行された。dstatはCPU、メモリ、ディスクI/O、ネットワークなど、システムのさまざまなリソース利用状況をリアルタイムで表示できる強力なツールだ。この調査により、当該ノードのCPUはアイドル状態に近く、SparkプロセスがCPUをほとんど使っていないことが明確になった。さらに、システムの動作ログを確認するために「systemd（システムディー）」のログを調べたところ、興味深い警告メッセージが目に留まった。それは、「kubelet（キューブレット）」というプロセスがCPUリソースを大量に消費している、という内容だった。

kubeletは、コンテナを管理するプラットフォームである「Kubernetes（クバネティス）」の一部として動作するエージェントだ。Kubernetesは、たくさんのコンテナ化されたアプリケーションを効率よく動かすための技術であり、kubeletはその中の各ノードでコンテナの起動や停止、リソースの監視などを担当する重要な役割を担っている。つまり、Sparkタスクを実行しているノードで、Kubernetesの管理エージェントであるkubeletが何らかの理由でCPUを大量に消費し、本来Sparkタスクに割り当てられるべきCPUリソースを横取りしていた状態だったのだ。さらに詳しく調べると、kubeletが大量のログファイルを生成しており、その処理にCPUを使いすぎていたことが判明した。大量のログがディスクに書き込まれ続けることで、CPUがログ処理に忙殺され、結果として本来のSparkタスクが十分なリソースを受け取れず、遅延していたのである。

原因が特定された後、解決策は比較的シンプルだった。問題のノードに蓄積されていたkubeletの大量のログファイルを削除し、その後ノードを再起動した。これにより、kubeletは正常な状態に戻り、Sparkタスクが十分なCPUリソースを使えるようになった。結果として、全てのSparkタスクは以前のように迅速に完了するようになり、パフォーマンス問題は解消された。

この事例は、システムエンジニアを目指す上で非常に重要な教訓を与えてくれる。分散コンピューティング環境では、一見すると全体が正常に見えても、たった一つのノードやプロセスで発生した問題が、システム全体のパフォーマンスに深刻な影響を与える可能性がある。今回のように、500個のうち499個が正常でも、残りの1個がボトルネックとなるケースは珍しくない。そのため、全体的な監視だけでなく、個々のノードやプロセスの詳細なリソース使用状況やログを丹念に分析する能力が不可欠だ。表面的な症状だけに囚われず、複数のツールや情報源を組み合わせて根本原因を特定する粘り強い調査が、複雑なシステムの問題解決には求められる。今回の経験は、分散システムにおけるトラブルシューティングの奥深さと、詳細な分析の重要性を改めて教えてくれるものと言えるだろう。