1. 全学部の学生がネット経由で利用する履修科目の申請システム 2. 過去に経験した性能不足のトラブルの原因を分析し,1年かけて性能を改善 3. 多重リクエスト対策やアプリケーションのチューニングなど,6つの対策を実施 |
「ようやく終わった」――。2005年4月25日,学生2万2930人,27万9769科目のインターネットからの履修科目登録をトラブルなく完了した時,早稲田大学 メディアネットワークセンター マネージャーの久保田学氏は,2年間を思い返してこう感じた。
この「履修科目申請システム」は2年前の2003年3月,トラブルを起こしていた。システムの稼働日である3月20日から性能不足のトラブルが相次ぎ,稼働から8日後の28日早朝に利用停止の決断をせざるを得なかった(図1)。メディアでも報じられる中,「トラブルを乗り越えるたびに次のトラブルが起こるという,不眠不休の1週間だった」(当時の開発リーダーだった教務部 情報企画課 神馬豊彦氏(現,早稲田総研))。
その後すぐ,早稲田大学はプロジェクトを仕切り直した。プロジェクト・チームは,大学職員向けシステムを開発する情報企画課から,学生や教員向けのシステムを開発するメディアネットワークセンターに移管した。同時にプロジェクト・マネージャには,それまで社会科学部事務所に所属し,ユーザー側で仕様を取りまとめていた久保田氏が異動し就任した。
久保田氏がまず実行したのは,疲れきった現場を1カ月間休ませることだった。1カ月の休息で神馬氏も元気に復帰。共同開発会社のNECから4人のオープンソース開発者も合流し,プロジェクトは再び動き始めた。久保田氏はシステムの再開時期を当初は半年後の2003年秋と考えたが,「今度こそ失敗できない」という慎重論が大半を占めていたため,1年後の2004年春を再開時期に定めた。
2つの原因はトラブル直後から指摘
プロジェクト・チームは,性能不足を起こしたトラブルの原因解明から取り掛かった(図2左)。
図2●性能不足のトラブルの主な原因は6つあったと分析し,それぞれに対して対策を実施 [画像のクリックで拡大表示] |
最初に原因としてとらえたのが,処理性能の要件を決めていなかったこと(原因1)と,負荷テストが不足していたこと(原因2)だ。この2つはシステムを分析するまでもなく,トラブル直後から指摘されていた。
次に,トラブル時の状態からユーザーの動きを分析して原因を探った。トラブル時はリクエストが殺到して性能不足が発生していた。どうやらリクエスト数はユーザー数を大きく上回り,1台のPCで同時にリクエストを発行する多重リクエストが発行されていたと考えた。
Webブラウザは,Webサーバーから応答が無ければタイムアウトになる。タイムアウトにならずともWebブラウザに何も描画されないまま数分待たされれば,ユーザーはリロードを繰り返したり,Webブラウザを再起動して接続したりする。Webサーバーはブラウザを閉じても検知できないため,サーバーのプロセスは残ったままであり,再接続によってまたプロセスが立ち上がる。こうして,多重リクエストになる悪循環に陥り,処理性能の不足を招いたと分析した(原因3)。