2018年 秋期 応用情報技術者試験 問10
キャパシティ管理
K 社は，ガス会社 G 社の情報システム子会社であり，G 社に顧客管理サービス（以下，本サービスという）を提供している。本サービスは，G 社が家庭用電力事業に新規参入したときに，K 社がその事業の顧客管理を支援するためのシステム（以下，本システムという）を導入して開始されたものである。G 社は本サービスを利用して，営業部門の電力料金計算・請求業務，及びコールセンタでの顧客からの問合せ対応・新規顧客受付業務を行っている。
K 社では，年に数回の計画停止期間以外は，毎日 9 時から 22 時まで，本サービスのオンラインサービスを提供している。
本システムの概要
本システムは，サーバ 1 台で稼働し，表 1 に示す五つの機能をオンライン処理又はバッチ処理で実現している。
| 項番 | 機能名称 | 処理形態 | 概要 |
|---|---|---|---|
| 1 | 顧客情報照会 | オンライン処理 | 顧客データベース（以下，顧客 DB という）を参照する。 |
| 2 | 検針データ取込み | 日中バッチ処理1) | 検針会社のシステムから検針データを受信し，顧客 DB を更新する。 |
| 3 | 顧客 DB バックアップ | 夜間バッチ処理2) | 顧客 DB のバックアップを取得する。 |
| 4 | 電力料金計算・請求 | 夜間バッチ処理2) | 顧客ごとの電力料金計算及び請求処理を行い，顧客 DB を更新する。 |
| 5 | 顧客情報登録・変更 | オンライン処理 | 新規顧客の登録や既存顧客の情報の変更などで顧客 DB を更新する。 |
注1) 日中バッチ処理は，オンラインサービス提供時間帯の 9～22 時に 1 時間間隔で起動され，数分間で完了する。日々の検針データが検針に影響する契約もあるので，障害が発生した場合でも，当処理は，当日の当初予定から 3 時間以内に実行する必要がある。
注2) 夜間バッチ処理は，オンライン処理終了後の 22 時から，顧客 DB バックアップ機能，電力料金計算・請求機能の順番に実行する。通常，全ての夜間バッチ処理が終了してからオンライン処理を開始する。夜間バッチ処理中は，他の処理では顧客 DB の参照はできるが更新はできない。
本サービスのキャパシティ管理
K 社の L 氏は，IT サービスマネージャとして本サービスのキャパシティ管理を担当し，具体的には次の業務を行っている。
キャパシティ計画
① 毎年 1 回，G 社営業部門から本サービスに対する需要予測を入手し，G 社と合意したサービスを考慮して資源の使用量を見積もる。これを基に，キャパシティを拡充するための期間，監視項目，監視項目のしきい値などのキャパシティ計画を作成し，G 社に説明している。
キャパシティ監視
① オンライン処理の監視項目は，サーバの CPU 使用率，オンライン応答時間及びオンライン処理件数であり，1 分間隔で集計し，測定値として収集する。ここで，オンライン応答時間とは，サーバが要求を受け付けてから応答するまでの時間のことである。バッチ処理の監視項目は，1 分間隔で集計するサーバの CPU 使用率及び毎日のバッチ処理時間である。
② 監視項目の測定値が，あらかじめ決められたしきい値を超えた場合は，インシデントとして対応する。
なお，社内及び社外のネットワークには十分なキャパシティがあり，サービス提供に支障がないので，監視項目を設定していない。
分析及び対策
① 監視項目の測定値について，キャパシティ計画で見積もったとおりに資源が使用されているかなどの視点から毎月 1 回分析を行う。また，夜間バッチ処理時間については，毎月 1 回妥当性を確認する。
② キャパシティに関わるインシデントの対応を終了した後は，キャパシティ計画の妥当性を検討し，必要に応じてキャパシティ計画を見直す。
オンライン応答時間の悪化
本サービスの提供を開始してから 6 か月後のある日，9 時 15 分にオンライン応答時間の測定値がしきい値を超えたことから，K 社はインシデント対応を開始した。また，コールセンタから K 社に "オンライン処理の応答が遅い" というクレームがあった。このときは，数分後にオンライン応答時間の悪化は解消されたので，K 社では解決策は必要ないと判断し，インシデント対応を終了した。
翌日 L 氏は，前日のオンラインサービス提供時間帯のサーバの資源使用状況について分析することにした。このときのサーバの CPU 使用率とオンライン処理件数は図 1 に示すとおりである。
処理件数は，オンライン処理の 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 社のキャンペーンの実施などに関する情報を事前に入手することにした。