パフォーマンスチューニングの罠

パフォーマンスチューニングの罠

次に紹介するのも、I氏と同様30代 SEの男性、K氏からいただいた話だ。やはり30代ともなると、トラウマ体験を持つ方は多いようだ。

「これは、つい先日、ようやく解決したばかりのホヤホヤの話ですよ。この間簡単にお話した大規模システムでの話しなんですけれどね、『導入したシステムが仕様よりも遅いのだがどうにかしてくれ』とお叱りの連絡があったんですよ。

ハードウェアとネットワーク、アプリケーションサーバといったインフラストラクチャはL社が担当していて、こちら側はソフトウェアの開発を行っていたわけです。もちろん導入先はL社にも連絡しているわけですが、『こちら側には問題ありません』の一点張りです。

そういわれてしまうとどうしようもないわけで、こちらとしては技術者を何十人単位で動員して、ソフトウェア側の見直しを行うことになりました。やっぱりどうしても、求めるパフォーマンスが出ないんですよ。正直かなり青くなってました。

ソフトウェアのルーチンをしらみつぶしに見直し、さらにデータベースのインデックスの再チューニングも行いました。それでも一向にパフォーマンスは向上しないのですから」

「期日は迫るし、パフォーマンスは向上しない状況の中で、やはり疑わしいのはL社が担当しているアプリケーションサーバでした。ここを自社で手がけていたのであれば、真っ先に疑う場所だからです。

アプリケーションサーバはTomcatで動作していました。最初は導入先を経由して、最終的にはL社に直接『Tomcatのチューニングの問題の可能性が高い。お願いだからそちらのチェックをお願いしたい』と打診しました。しかし『何の問題も無い』の一点張りです。

最終的な期日の延長を導入先に願い出るかどうしようか、とモヤモヤとした気分のままチェック作業を続けたある日、導入先経由でTomcatのパラメータが1点、設定上の不備があった、と連絡が入りました。

実際にL社側でそのパラメータを修正した後で、改めてソフトウェア側のパフォーマンスチェックをしたところ、何の問題もなくシステムは本来の速度で稼働するようになっていました…。

…後日、色々と荒れましたね」

「もっと早くL社がチェックしてくれていれば」そう思わずにはいられない話だ。この話の教訓としては、自分自身がL社のごとき対応をしないように注意しよう、ということにつきる。

さて、第3回の最後を締めくくるのは、きっと誰もが共感し、涙する話に違いない。