 |
1. 272台のサーバー機を11台に統合後，性能劣化が頻発 2. プロジェクト・チームを発足させ，目標と期限を設定した 3. JVMの再起動やリクエストの効率的な振り分けで，障害発生を収束 |
 |
「なぜ画面の反応がこんなに遅いんだ」「これじゃあ，仕事にならない」──。いつもは静かな大阪ガスのシステム部門のヘルプデスク。その電話が2006年の夏ごろ，冒頭のようなクレームで，毎日ひっきりなしに鳴り響いた。
電話の主は，社内のさまざまな部門の社員。販売管理，顧客管理，在庫管理といった広範なアプリケーションで性能劣化が発生し，社内の至るところで業務に支障を来していた。
「サーバー統合の副作用に違いない」。原田昌治氏（大阪ガス 情報通信部 インフラ技術チーム）をはじめとする運用チームには，性能劣化の原因に心当たりがあった。それは，2003年9月から3年がかりで進めてきた，サーバー統合だった。運用コストの大幅な削減を狙い，メインフレームやWebサーバー，APサーバー，ファイル・サーバーなど全272台のサーバー機を順次統合し，11台にまで減らした（図1）。
最大の山場は，APサーバーの統合だった。従来19台のUNIXサーバー機で稼働させてきた社内向けアプリケーションを，2台のUNIXサーバー機に集約した。その直後から，クレームの電話が一気に増えた。
実際に，クレームの対象は社内向けアプリケーションに集中していた。別系統のUNIXサーバー機で動作するグループ会社向けアプリケーションでは性能劣化が軽微だったことから，APサーバーに問題があることは容易に推測できた。
ただし性能劣化は，さまざまなアプリケーションで頻発した。それまで何も問題がなかったアプリケーションに突然クレームが集中することもあった。どういう条件下で性能劣化が起こるのかがはっきりしないので，障害原因の特定は一筋縄では行かなかった。
その後，運用チームは性能劣化の原因分析と解決に乗り出すが，問題解決までに約2年を要した。前半の1年は，少人数で場当たり的に対応したこともあり，原因究明が進まなかった上に，応急処置も効き目が薄かった。そこで後半の1年では，プロジェクト・チームを発足させ本腰を入れて取り組んだ。その結果，2008年4月，メモリーなどのリソースを有効利用する仕組みによって性能劣化の障害発生を収束させた。以下で，運用チームが問題解決に挑んだ軌跡を紹介する。
