運用って、あまりいいイメージはなかったけれど：システム開発プロジェクトの現場から（14）（2/2 ページ）

開発現場は日々の仕事の場であるとともに、学びの場でもある。先輩エンジニアが過去に直面した困難の数々、そこから学んだスキルや考え方を紹介する。

[新楽清高，アクセンチュア・テクノロジー・ソリューションズ] PC用表示

LINE

Hatena

前のページへ | 　　　　　　

共有プールが不足したのはなぜ？

　まずは、システムの使用状況に何か変化がなかったかを調査しました。すると1週間前から、システムを使用するユーザーの数が20％ほど増加していることが判明しました。

　「利用ユーザー数が20％増えた」ので「共有プールが不足した」のでしょうか。でも、それが原因だといい切れるだけの根拠がまだありません。そもそも共有プールはどのような仕組みで使われ、どういうことが起こると枯渇してしまうのか。とても基本的なことですが、そこの認識がずれていると、無駄な調査をしたり誤った結果を出したりしてしまうかもしれないと考え、仕組みをきちんとまとめました。理解しているつもりでも、きちんと知識として体系化することが大切ですね。

　いろいろ調べるうちに、「バインド変数化されていないSQLがアプリケーションから大量に発行されていないかどうかを、きちんと調査する必要がある」と判断することができました。インターネットで調べただけでも同じような記述はたくさん出てきましたが、きちんと調査することで技術的な裏付けが取れたので、無駄ではなかったと思っています。

バインド変数化されていないSQLを探せ

　次の問題は、バインド変数化されていないSQLが発行されている個所をどうやって特定するかです。ソースコードは膨大な量であり、一から調べるのは至難の業。そもそもバインド変数化されていないSQLが存在するのかどうかさえ定かではないのです。

　ただ共有プールの仕組みを体系化したことで、実はバインド変数化されていないSQLを特定する方法についても整理されていました。共有プールに蓄えられているSQL文を確認できることが分かったのです。

　そこで共有プール内を調べてみたところ……何とこれが大当たり。共有プール内に蓄えられているSQLのうちの50％近くが、バインド変数化されていないSQLだったのです。

　SQLが分かってしまえば、ソースの特定は難しいことではありません。特定されたソースは非常に分かりにくいところに存在していました。

　バインド変数をきちんと使用しているかは、開発・テスト時に入念なチェックをしていたはずでした。ところがこのソースは、ストアドプロシージャ内で動的にSQLを発行している部分に存在していたのです。これはとっても探しにくいですね。

　問題のソースが特定できたので、後は対応して結果を見て、というふうにすんなりいきました。そして最終的には、今回のトラブルを「同一のプログラムから実行されているバインド変数化されていないSQLが、共有プールを占有してしまっていた。1週間前から利用ユーザー数が増えたこともあって共有プールが不足し、ORA-04031が発生してしまった」とまとめることができました。

トラブルは起こらないのが一番だけれど

　トラブルは、起こらないのが一番です。が、今回の経験から、トラブル対応を通して学ぶことが多いのもまた事実だと思いました。トラブルの解決には、技術的にかなり深い部分まで理解する必要があります。今回のトラブルはその機会を与えてくれました。物事を論理的に組み立てなければいけないということも、とても勉強になりました。

　ですが最も強く感じたことは、「やっぱり人だなぁ」ということです。

　問題が発生したとしても、すぐにみんなで集まって対応策を考え、実行に移すことができる。責任の所在をどこか別のところに探すのではなく、自分が当事者となって、率先して対応する。原因は徹底的に調査し、決して妥協はしない。方向性を合わせ、論理的なアプローチで、一丸となって対応する。そして、一度起こった失敗は二度と繰り返さない。失敗を繰り返さないためにどうしたらよいかを計画し、実行する。

　私の周りには、そういった文化があります。この中で仕事ができることを、とても楽しく感じています。

　1人ではやはり面白くありませんし、限界もあります。やらされている感があったり、ネガティブな気持ちを抱いていたりしては、いい仕事はできないと思います。

　私はこの出来事をきっかけに、運用という仕事の大切さ・重み・やりがいをあらためて考え直すことができたと思います。そして「運用」に抱いていたネガティブなイメージを完全に取り去ることができました。

　ATSに入社して以来、私が携わるシステムの規模は格段に大きくなりました。社会に与えるインパクトも計り知れないぐらいだと思います。ですが、システムが止まるということについては、大小は関係ありませんよね。運用しているシステムが停止することの重大さを意識し、最善策を考えることの重要性を強く認識することができたのも、運用（特に、その中でのトラブル対応）を経験したからだと思います。

筆者紹介

アクセンチュア・テクノロジー・ソリューションズ

新楽清高

1973年生まれ。東京生まれの東京育ち。大学で都市計画を専攻後、社員100人ほどのシステムインテグレータにてSEとしてセールス～要件定義～開発・テスト～運用までを行う。その後2003年11月にアクセンチュア・テクノロジー・ソリューションズに入社。Java、.NET、SAPにて大規模な基幹システムの構築に携わり、現在に至る。基本ポリシーは「楽しく」。趣味はトラブル対応。

「次回」へ

「システム開発プロジェクトの現場から」バックナンバー