応用情報技術者 2018年 秋期 午後 問10

　 　K社は、ガス会社G社の情報システム子会社であり、G社に顧客管理サービス（以下、本サービスという）を提供している。本サービスは、G社が家庭用電力事業に新規参入したときに、K社がその事業の顧客管理を支援するためのシステム（以下、本システムという）を導入して開始されたものである。G社は本サービスを利用して、営業部門の電力料金計算・請求業務、及びコールセンタでの顧客からの問合せ対応・新規顧客受付業務を行っている。 　K社では、年に数回の計画停止期間以外は、毎日9時から22時まで、本サービスのオンラインサービスを提供している。 　 〔本システムの概要〕 　本システムは、サーバ1台で稼働し、表1に示す五つの機能をオンライン処理又はバッチ処理で実現している。

〔本サービスのキャパシティ管理〕 　K社のL氏は、ITサービスマネージャとして本サービスのキャパシティ管理を担当し、具体的には次の業務を行っている。 　(1) キャパシティ計画 　　① 毎年1回、G社営業部門から本サービスに対する需要予測を入手し、G社と合意したサービスを考慮して資源の使用量を見積もる。これを基に、キャパシティを拡充するための期間、監視項目、監視項目のしきい値などのキャパシティ計画を作成し、G社に説明している。 　(2) キャパシティ監視 　　① オンライン処理の監視項目は、サーバのCPU使用率、オンライン応答時間及びオンライン処理件数であり、1分間隔で集計し、測定値として収集する。ここで、オンライン応答時間とは、サーバが要求を受け付けてから応答するまでの時間のことである。バッチ処理の監視項目は、1分間隔で集計するサーバのCPU使用率及び毎日のバッチ処理時間である。 　　② 監視項目の測定値が、あらかじめ決められたしきい値を超えた場合は、インシデントとして対応する。 　　なお、社内及び社外のネットワークには十分なキャパシティがあり、サービス提供に支障がないので、監視項目を設定していない。 　(3) 分析及び対策 　　① 監視項目の測定値について、キャパシティ計画で見積もったとおりに資源が使用されているかなどの視点から毎月1回分析を行う。また、夜間バッチ処理時間については、毎月1回妥当性を確認する。 　　② キャパシティに関わるインシデントの対応を終了した後は、キャパシティ計画の妥当性を検討し、必要に応じてキャパシティ計画を見直す。 　 〔オンライン応答時間の悪化〕 　本サービスの提供を開始してから6か月後のある日、9時15分にオンライン応答時間の測定値がしきい値を超えたことから、K社はインシデント対応を開始した。また、コールセンタからK社に“オンライン処理の応答が遅い”というクレームがあった。このときは、数分後にオンライン応答時間の悪化は解消されたので、K社では解決策は必要ないと判断し、インシデント対応を終了した。 　翌日L氏は、前日のオンラインサービス提供時間帯のサーバの資源使用状況について分析することにした。このときのサーバのCPU使用率とオンライン処理件数は図1に示すとおりである。

　CPU使用率が高い9～11時を詳細に調査したところ、一時的にCPU使用率が100%となっているときがあることが判明した。9～11時の120分間の1分間隔のCPU使用率は、図2に示すとおりである。

　調査結果から、CPU使用率が100%に達している時間帯が、a機能の処理を実行している時間帯と一致した。また、過去1か月の状況を調査したところ、9～11時の時間に100%に近いCPU使用率を記録することが数回あったので、L氏はすぐに実施する暫定策として、午前中は、a機能の処理を実行せず、12時に実行することにした。また、恒久策として、3か月後にサーバのCPU能力向上を行うことにした。 　 〔夜間バッチ処理の終了時刻の遅延〕 　オンライン応答時間の悪化から数日後に、夜間バッチ処理の終了時刻が遅延するインシデントが発生し、オンラインサービスの開始が遅れた。その結果、顧客情報照会ができないことから、コールセンタの業務に支障を来した。 　そこで、インシデント対応のbとして、機能を縮退してオンライン処理を行うことをG社と合意し、c機能だけでオンライン処理を行うことにした。その間、コールセンタで顧客情報登録・変更があった場合は、夜間バッチ処理が終了し、オンラインサービスが正常に回復した後に対応することにした。 　L氏は、インシデントの発生原因を調査し、次のように整理した。 　・夜間バッチ処理では、顧客DBに登録された全顧客を対象に処理を行っている。夜間バッチ処理の設計では、顧客の登録数（以下、顧客登録数という）が50万件になるまでは処理が9時までに終了するとしていた。 　・本年度当初にG社営業部門が提示したシステム要件では、顧客登録数が前述の50万件に達するのは1年半後となっていた。しかし、G社営業部門では2か月前から臨時キャンペーンを行い、顧客登録数が予測よりも早く50万件を超えたので、夜間バッチ処理の終了時刻に遅延が発生した。 　そこで、L氏は、①顧客DBの顧客登録数を監視項目として追加し、日常的に監視することにした。さらに、G社の協力を得て不要な顧客情報を顧客DBから削除し、顧客登録数を減らした。 　L氏は、今後の顧客登録数の増加について、次のように整理した。 　・G社営業部門の見通しでは、2年後に顧客登録数が100万件に達する。 　・顧客登録数が100万件に達するまでは、9時までに夜間バッチ処理を終了できるように検討し、3か月後に予定しているサーバのCPU能力向上計画に反映する。 　 〔キャパシティ管理の強化〕 　L氏は、サーバのCPU能力を向上させるまで、オンライン応答時間の悪化が起きない方策を検討した。CPU使用率とオンライン応答時間の関連性を分析した結果、CPU使用率が95％を超えるとオンライン応答時間が急激に悪化する傾向があることが分かった。そこで、L氏は、オンラインサービスへの影響を軽減するためにCPU使用率のしきい値を、95％よりも低い値に設定し、応答時間の遅延が発生する前にdとして対応することにした。また、今回の夜間バッチ処理の終了時刻の遅延に関連して、今後は②G社営業部門と定期的に打合せを行い、本サービスに対する需要予測に影響を与える、G社のキャンペーンの実施などに関する情報を事前に入手することにした。