ITサービスマネージャ 2024年 春期 午後I 問題

共通の文章

サービスの予算業務及び会計業務に関する次の記述を読んで,設問に答えよ。 Q社は,個人投資家を対象とした証券会社で,東京の本社にサービス事業本部と情 報システム本部があり,全国に営業店がある。サービス事業本部にはT事業部とU事 業部があり,情報システム本部にはシステム開発部とITインフラ部がある。システ ム開発部は,システムの開発と保守を担当している。ITインフラ部は,システム運 用を担当し,サーバやストレージなどのハードウェア及びソフトウェア(以下,こ れらをITインフラ群という)を管理している。ITインフラ部は,サービス事業本部 に対して,運用しているシステムをITサービスとして提供している。 Q社のITインフラ群は,V社が運営するデータセンター(VE,DCという)にハウ ジングされている。0社は,DCの施設・設備をハウジングサービスとして利用してい る。TITインフラ部の提供しているITサービスの概要を表1に示す。 表1 ITインフラ部の提供しているITサービスの概要(2023年4月時点) ー営業店での販売,相平日の6時から21|サーバ860台 呈示サービス(DEER,Ba= っ|口座管理,SHE,決1“a 注記1TB(テラバイト)は,1,000GB(ギガバイト)とする。 SEXサービスコンポーネントのサーバ及びストレージは,当該ITサービス専用に割り当て られており,サーバは全て同じ能力のサーバを使用している。 ITインフラ部は,ITサービスを運用するために掛かる費用を算出し,顧客に課金 している。WHE,顧客に課金している費用の一覧を表2に示す。 表2顧客に課金している費用の一覧 |1|ハードウェアリース料|サーバ及びストレージのリース料 サー及びストレージの保き間 |3|ソフトウェア使用料ソフトウェアのライセンス費及び保守費 運用人件費運用要員!の人件費 |5|DC使用料。。。|V社ハウジングサービスを利用する費用 SE?運用要員は本社に常駐しており,ネットワークを介して運用をしている。 ーー2_ ITインフラ部は,表2の費用を次のように管理している。特定事業部のITサービ スで専用に使用されている費用を,直接費として当該事業部に割り当てる。直接費 にはハードウェアリース料,ハードウェア保守費及びソフトウェア使用料がある。 運用人件費及びDC使用料は費用の総額を各事業部に拓分し,間接費として配購し ている。なお,DC使用料は固定料金制の長期契約となっており,2026年3月まで費 用の変動はない。 [情報系サービスの移行計画〕 2023年度未である2024年3月に,情報系サービスを構成するサービスコンポーネ ントのITインフラ群が保守期限切れになる。これに伴い,ITインフラ部は,2023年 6月までにITインフラ群の移行方針を策定することになり,ITサービスマネージャ S氏が担当となった。0社を利用する個人投資家は年々増加しており,情報系サービ スが対象とするデータ量も増加している。2023年4月,S氏は,今後の情報系サービ スの需要見込みについてT事業部と協議した。S氏は,協議した需要見込みを基に, 2024年度期初に2023年度期初に比べて209%の容量・能力増加が必要で,その後も順 次容量・能力の増加が必要となると予測した。ITインフラ部は,需要の変化に対応 iする迅速な容量・能力変更の必要性及び費用の抑制を考慮し,情報系サービスで専 用に使用するITインフラ群を外部のクラウドサービスに移行し,2024年3月から利 用を開始する移行方針を立てた。なお,運用要員はITサービスのシステム運用業務 を行っており,移行後も運用業務量の変動はない予定である。 S氏は,複数のクラウド事業者に提供サービスについてヒアリングした上で評価し, R社のクラウドサービス(以下,Rクラウドという)を候補として選定した。Rクラ ウドでは,利用者の要求に応じて,サーバとストレージのリソース使用量を動的に 割り当てること(以下,リソースオンデマンドという)ができる。R社から管理ツー ルとその使用権限が与えられ,これによってリソースオンデマンドの機能を使うこ とができる。 [Rクラウド利用料の見積り] S氏は,ITインフラ部における情報系サービスの予算管理者としての役割を担って いる。S氏は,クラウドサービス移行後の予算案策定に向け,Rクラウド利用料の見 ー3一 積りを行うことにした。まず,ソフトウェア使用料については,移行後も費用の変 動がないことを確認した。次に,Rクラウドには,サーバとストレージのリソースに 対応したサービスがあり,それぞれ次の価格モデルがあることを確認した。 ①従量制料金:サーバは時間単位ストレージは月単位に割り当てたリソース使 用量に応じて課金額が決まる方式 ②使用量予約:一定のリソース使用量を,1日24時間で365日分年間予約するこ とで,予約した年単位のリソース使用量分の従量制料金に年間割引|を適用する。 Rクラウドのサービス料金を,表3に示す。 表3 Rクラウドのサービス料金 サービス本 名称“ORAS@使用量予約 サーバサーバ能力を提供する。0Sの設定は利用|1台当たり従量制料金を25%割引 サービス者が行う。109円時間|して年単位に換算 ストレージ|静的コンテンツ,アプリケーションプロ|106GB当たり|従量制料金を259%割引 サービスGoh,データを保存するストレージ|1600円月!|して年単位に換算 注記サーバサービスの従量制料金における1台とは,ITインフラ部が現在使用しているサーバ 能力に換算した場合の値である。 注”ストレージサービスの場合は,確保した使用量が月額固定で課金される。 情報系サービスのサーバは,“①従量制料金"の価格モデルの場合,サービス時間 だけ利用するので,1台当たりの年間リソース使用時間は| 。|時間となる。 したがって,価格モデルとして| b|を適用した方が,他方の価格モデルよ りも低額となる。また,情報系サービスのストレージは,価格モデルとして“②使 用量予約′を適用し,予算案を策定する方針とした。S氏は,2024年度に情報系サー ビスで使うRクラウドの利用料を外部委託費として見積もり,表4にまとめた。ここ で,2024年度は,期初の需要見込みに対応した容量・能力を確保し,2024年度中は, 容量・能力に変動がないものとした。 表4 2024年度情報系サービスで使うRクラウド利用料の見積り 年額(FAR) nase[RBRTTE ae 情報系サービスのストレージのRクラウド利用料金 =4= ITインフラ部は,S氏の見積りをレビューし,費用を抑制できると評価した。そこ で,ITインフラ部は,クラウドサービス移行についてシステム開発部及びサービス 事業本部と協議を開始した。 〔[サービス事業本部への費用の提示〕 S氏は,クラウドサービス移行後のT事業部への情報系サービスの課金額を検討し た。S氏は,表4で示す費用以外に,表2の費目のうち,クラウドサービス移行後も ソフトウェア使用料,運用人件費及びDC使用料は継続して発生するとの前提をおい て,課金すべき直接費と間接費を算出した。 ITインフラ部では,直接費は実績に基づき各事業部に課金している。TOMI, 関連する作業負荷,容量・能力の情報も報告し,予算及び需要見込みに対して実績 が適切かどうかを各事業部も把握できるようにしている。S Kit,(ア)新たに割り 当てる直接費についても関連するリソース実績をT事業部に報告することにした。 次にS氏は,移行後の間接費について,配肛額を検討し,ITインフラ部内でレビ ューをした。Rクラウドに移行した場合,“(イ)FEDER OAR OAK Clad HRA がある"との指摘があり,$氏は,配肛の方法の見直しを検討し,2024年度にT事業 部が支払う費用の見込み案(以下,2024年度課金案という)を作成した。 ITインフラ部は,2024年度課金案をサービス事業本部に提示し,合意を得た。そ の後,ITインフラ部は,0社の変更管理プロセスに従い,Rクラウドへの移行につい て変更要求を提出した。変更要求は規定に従って審査され,Rクラウドへの移行が決 定された。0社では,Rクラウドを使って情報系サービスが正常に稼働することを, 機能面・性能面から確認する必要があるので,システム開発部を中心として関連部 署からメンバーが招集され,移行プロジェクトが発足し,2023年8月から2024年3 月まで活動を行うことになった。なお,2024年3月までのRクラウドの利用料・移行 作業費などは,移行プロジェクトの費用とする予算措置がとられた。 また,2024年度課金案は,移行プロジェクトの結果を反映して見直しを行い, 2024年度の予算を策定することになった。策定された予算は,規定に従って承認さ れた後,2024年3月に利害関係者に通知される。 as B we [予算と費用実績の管理に向けた検討〕 S氏は,予算管理者として,予算がどのように執行されるかを監視する責任がある。 S氏は,移行後のRクラウドを含む予算と費用実績の管理について,検討を開始した。 2024年1月に,S氏は,移行プロジェクトの状況えをヒアリングした。ヒアリングの 結果は,次のとおりである。 ・システム開発部とITインフラ部のプロジェクト担当者が,Rクラウド上で情報 系サービスが正常に稼働することを,機能面と性能面で確認できた段階である。 ・0社では,2024年度後半に個人投資家向けに,新商品の販売キャンペーンを行う 計画があり,計画の実施に当たって情報系サービスの需要が急増する見込みが HS.事業部とITインフラ部のプロジェクト担当者は,リソースオンデマン ドを使って迅速にリソース拡張を行うことで,急増する需要に対応できること を確認している。 S氏は,販売キャンペーンを行う計画を織り込んで情報系サービスの席要を見直し, 2024年度予算に反映することにした。しかし,2024年3月時点で,販売キャンペー ンの規模などは不透明で,販売キャンペーンの規模を拡大して実施することになっ た場合に,現時点の販売キャンペーンの計画よりも需要は増加することが考えられ SS Kid,このような事業環境の中で本番運用を開始した場合,(ウ)予算管理上 のリスクがあると認識した。S氏は,リスクが顕在化することを想定し,事業環境変 化に対応してタイムリーにリソースオンデマンドを活用できるように(ZL)必要な 対策を検討し,本番運用開始までに利害関係者に徹底することにした。

共通の文章

TIoTを活用した駅務サービスの可用性に関する次の記述を読んで,設問に答えよ。 E社は,関西圏を中心とした中堅の鉄道事業者である。大阪の本社を中心として, 3路線50駅の運営を行っている。E社本社には駅業務部と情報システム部がある。駅 業務部は,E社が運営する各駅の業務を統括している。情報システム部では,発売し た乗車券などの集計を行う駅務システムを運用している。 駅では,ハードウェアメーカーの「社が提供する自動改札機,自動券売機及び窓口 端末(以下,これらを駅務機器という)を導入して,駅の出改札業務を行っている。 窓口端末は全ての駅に最低1台設置されており,自動券売機で取り扱う全ての出改札 業務に対応するほか,駅員が窓口端末を使って駅務システムを利用できる。また., 自動改札機と自動券売機は,駅構内のLANを経由して窓口端末と接続されており,駅 Alt,窓口端末を使って,当該駅の駅務機器の稼働状態を確認することができる。 窓口端末で駅務機器の稼働状態の異常を検知し,故障などで保守員による対応が必 要と判断した場合,駅員は駅業務部に電話連絡し,駅業務部経由で『社保守員の手配 が行われる。 情報システム部は,駅務機器及び駅構内のLANの管理を行っており,駅業務部及び 各駅に対して,駅務システムの運用を含めて,駅務サービスとして提供している。E 社では,全ての駅の営業時間は同じ時間帯であり,駅務サービスでは,駅の営業時 間をサービス提供時間としている。 情報システム部では,駅務機器のシステム保全・点検作業の計画を立て,全ての 駅の駅務機器に対して定期的にシステム保全・点検作業を行うことで,故障前に対 応を行う予防保全に取り組んでいる。システム保全・点検作業はF社に業務委託され THY,駅務機器のシステム保全・点検作業の対象部品(以下,部材という)に対 して,必要に応じ,図1に示す交換作業が行われる。 ・臨時交換:点検作業を実施する作業員が目視などで確認を行って交換が必要と判断した 部材がある場合に,当該部材を交換する作業 注"部材が,最も高い頻度で使用され続けたときに,故障が発生する確率が高まるまでの 期間を,F社が独自の統計的手法に基づいて算出し,部材ごとに耐用年数や耐用時間とし て定めたもの 図1システム保全・点検作業時に実施される交換作業 ーg一 システム保全・点検作業は,自動券売機と窓口端末については夜間の営業停止時 間帯に行われているが,自動改札機は点検作業の回数と台数が多く,営業時間内に 行われている。自動改札機のシステム保全・点検作業に伴う計画停止については, 駅の利用者に事前案内され,利用者は他の自動改札機を使うか駅員による改札を受 ける。 [現状の課題と改善策の検討〕 情報システム部では,駅務機器の安定稼働を維持するために,F社に業務委託して システム保全・点検作業で必要となった部材の交換を行っているが,一部の駅務機 器では故障が発生しており,予防保全に取り組む情報システム部の課題となってい た。駅務サービスの可用性の一つの指標として駅務機器の稼働率を採用している。 2023年度の状況を表1に示す。 表1 2023年度の駅務機器の故障と稼働率の状況 Sse 種類総台数|1台当たり|1台当たり|故障1回当|1台当たりの|年間稼働率 (台)|の年間稼働|の年間平均|たりの平均|年間平均計画|(%) (時間/台)|(回/台)|(時間/回)|(時間/台) lmwzsal ml zw|:|wl|ぃにココ Laowsl wl wl 4||wl ww SE)自動改札機は営業時間中に計画停止時間を設けているので,自動券売機と窓口端末 に比べて稼働予定時間が少ない。 駅務機器の年間稼働率は,年度ごとに種類別に次の式で計算する。ここで,年間 稼働率(%)は小数第3位を四捨五入するものとする。 全台の年間稼働予定時間の合計一全台の年間故障修復時間の合計 全台の年間稼働予定時間の合計 2024年度,情報システム部では,システム保全・点検作業コストの削減に取り組 む方針が示された。そこで,ITサービスマネージャのG氏を中心に,現状の課題及 びコスト削減の方針への対応を検討することにした。 ー9一 まず,G Ald,課題となっている駅務機器の安定稼働の維持について,駅務機器の 稼働率の数値を確認した上で,駅務機器の故障発生を減少させる必要があると考えた。 次に,6G氏は,システム保全・点検作業コストの削減について考えた。現在の定期 交換の対象部材には,実際にはまだ使えるものがあって,無駄が多い。そこで,デー タ分析を活用したCBM(Condition Based Maintenance:状態基準保全)システムを道 入することでコストを削減できないかと考えた。G氏は,機器の動作状況を取得する lolセンサーを設置し,収集したデータを分析して故障の可能性が高まった時点で, 対象部材を交換することによって無駄なコストを抑えることができると考えた。また., CBMシステムを導入した場合,現在行っているシステム保全・点検作業と比べて,(ア) サービス提供者としてのサービス可用性管理の観点からもメリットを期待できる。G 氏は,これらの仕組みをCBMシステムとして構築し,社内で活用する検討に着手した。 (CBMシステムの構築準備] G氏は,CBMシステムの構築に当たって,EF,どのデータをどのように取得する かを検討するため,F社に相談した。その結果,駅務機器の中でも故障頻度が高く, 全ての駅務機器に含まれている券片の搬送機構に着目し,券片が搬送機構を通過す る速度(以下,搬送速度という)のデータを取得対象に決めた。また,搬送速度を 取得するにはlolセンサーの設置が必要となるが,F社からは,既存の駅務機器を大 きく改造することなく設置が可能であり,少額の投資で搬送速度データを駅務シス テムに送信する仕組みを実現できるとの回答があった。 次に,G氏は,取得したデータから搬送速度の低下を検知するための(1)しきい 値を設け,継続的に監視する仕組みを構築した。搬送速度がしきい値を下回った場 合には,アラームリストを出力し,その情報を,駅業務部及び当該の駅務機器が稼 働する駅に対して速やかに通知されるようにした。 また,現行の駅務機器のシステム保全・点検作業について,今回は点検対象の一 部にCBMシステムを導入することで,点検対象を削減し,点検作業時間も削減できる と考えた。 G氏は,社内の変更管理規程に従って,CBMシステムを構築する変更要求を提出し た。情報システム部長は,“CBMシステムは,(ウ)点検対象の機器数の削減及び点検 作業時間の削減以外のコスト削減効果も期待できる。また,今後対象機器を拡大し, ー19一 点検作業の頻度を減らしたり,無くしたりできれば,将来的に大きなコスト削減に もつながる"と評価した。変更要求は承認され,CBMシステムの構築が開始された。 [SNSデータの分析を活用した障害検知] CBMシステム構築中のある日,行楽イベントで混雑するある駅で,駅務機器が故障 するインシデントが発生し,駅構内が混雑した。当該駅では,駅の利用客対応を優 先し,駅業務部への障害連絡が遅れてしまった。インシデントの初動対応が遅れて 解決までに時間を要し,駅務サービスの可用性が悪化した。 情報システム部では,インシデント対応中にインシデントの影響の大きさを把握 するために,E社が提供する不特定多数の人が閲覧可能なSNSへの投稿内容から利用 者の反響を調査した。SNSへの投稿は,“情報源が不特定多数であって現場からの情 報より正確性は低いが,情報の早さは現場よりも早い場合がある”といった特性が HS,調査を担当したG氏は,調査の過程で,E社が当該インシデントの対応を開始 する前に,障害に関する幾つかの投稿があることに気付いた。当該インシデント対 応が終了した後日,投稿を時系列に整理して1分ごとに集計したところ,投稿件数が 図2のように推移していることが分かった。 件 80-ーー 40= 20生ここと記きこここここここさらごさこここニここごここごここごューニンニニここここ。 20:00 20:05 20:10 20:15 20:20 20:25 ーー障害発生日の投稿件数===通常日の平均投稿件数 図2障害発生日と通常日の投稿件数の推移 情報システム部では,障害当日29:19に駅業務部からの障害連絡を受け,20:15に インシデントの対応を開始していた。また,SNS上では障害に関する最初の投稿は 20:00であった。この結果を見て,G氏は,SNの特性に着目し,自社の駅務機器に 関する障害発生を検和できないか検討することにした。 G氏は,SNSの情報を使って障害を検知する仕組みを,次のステップで考えた。 ①SNS上における障害に関する投稿(以下,障害投稿という)を定義する。 ②障害が発生したと推定するための条件(以下,検知条件という)を定義する。 G氏は,①の障害投稿の定義として,“「E社」「(E社の)駅」などのE社に関する情 報と“「通れない」「使えない」「障害」などのネガティブワード"の両方が含まれ る投稿とした。また,②の検知条件として,次のような条件を抽出した。 ・1分当たりの投稿件数が基準値以上であること ・1分当たりの障害投稿件数が基準値以上であること ・1分ごとに5分連続で障害投稿件数が増加傾向にあること G Kilt,三つの検知条件の全てを採用すると検知遅れや検知漏れが増え,(エ)一 つだけに絞ると誤検知が増えると考えた。そこで,三つの検知条件のうちの二つを 満たす場合に障害が発生していると判定することにした。

共通の文章

コンテナ型仮想環境における運用管理に関する次の記述を読んで,設問に答えよ。 W社は,オンラインゲームのアプリケーションソフトウェア(以下,ゲームアプリ という)を企画,開発及び運用している。W社の開発部は,開発環境と試験環境を利 用して,ゲームアプリの開発と保守を行っている。W社の運用部は,開発されたゲー ムアプリを乏働環境で運用し,Wサービスとしてスマートデバイスからインターネッ トを経由してゲームを行う利用者に提供している。開発環境の管理は開発部が,試 験環境及び稼働環境の管理は運用部が担当している。Wサービスの提供時間帯は,ゲ ームアプリ改修に必要な計画停止時間を除いた24時間365日となっている。 [ゲームアプリの開発と運用における課題] ゲームアプリの競争が激しく機能追加のための改修が多いので,新たな版のゲー ムアプリを週1回の頻度で稼働環境にデプロイする必要がある。開発部と運用部では, 開発に掛かる期間を短縮し,リリース頻度を高めているが,ゲームアプリの開発と 運用には表1に示す課題がある。 表1ゲームアプリの開発と運用における課題 試験項目に応じて試験環境を整備する必要があるので,開発部は,具体 試験の中断的な整備内容を指定して運用部に試験環境の整備を依頼する。運用部 ーーは,手順書を用いて試験環境を開発部が指定する状態にする。運用部が 試験環境を整備している期間,開発部の試験が中断する。 信頼漏れ・項番1の試験環境の整備において,開発部からの依頼漏れや運用部の作 2 yesh業漏れなどが発生すると,十分に整備された試験環境で開発部が試験を x実施できずに,正しい試験結果を得られないことがある。 a稼働環境にデプロイする作業は,Wサービスを停止する必要があること 3 ose DS,Wサービスの停止時間が発生し,利用者に対して不便をかけてい る。また,運用部の作業に負荷が掛かっている。 稼働環境に適用されている0Sやミドルウェアのパッチの版が試験環境に 4|版のネー致適用されている版と異なっていたことから,試験環境で実施した試験で 全|はゲームアプリは正常に稼働したが,乏働環境にデプロイした後,イン シデントが発生することがあった。 SR BICデプロイ後にゲームアプリの不具合を発見した場合や項番4のようなイ 6使う利用者ンシデントが発生した場合,1世代前の版のゲームアプリに戻すための への連絡RaeBP VEC,緊急変更に伴うWサービス停止の利用者への連絡が =停止時間帯の直前となってしまう。 開発部のY Kid,アプリケーションが稼働する環境を,高速かつ簡単に生成できる コンテナ技術を導入することによって,表1の項番1や項番2の課題を解決できない かと考えた。 [コンテナ技術]〕 コンテナ技術とは,アプリケーションプログラム(以下,APという),ミドルウェ ア(以下,MMという)などを一つにまとめたもの(コンテナ)をホスト0Sのコンテ ナ管理ソフトウェア上で仮想環境として動作させる技術のことで,次のような特徴 がある。 ・開発者が自らに必要な環境を専有して開発できる。 ・サーバのリソースを有効利用でき,環境の準備,起動,廃棄などを迅速に行う ことができる。 ・別の環境への移行が簡単にできる。 コンテナ型仮想環境とハイパーバイザー型仮想環境の構成例を図1に示す。 コンテナ型仮想環境ハイパーバイザー型仮想環境 Wy Ay oy ay 図1コンテナ型仮想環境とハイパーバイザー型仮想環境の構成例 [コンテナ型仮想環境の導入検討 Wサービスは,運用部が運用するWシステムによって実現されている。Wシステム の稼働環境及び試験環境は,2台の物理サーバ,通信装置,外部記憶装置など,W社 =14= の設備を使って構成されている。物理サーバのうち1台では,APの不具合によって APが停止した場合でもWサービスを継続できるようにハイパーバイザー型仮想環境 C,二つのアプリケーションッサーバ(AE,アプリサーバという)を稼働ざぜてい る。他の物理サーバでも,同様につのデータベースサーバが稼働している。 Y氏は,運用部のITサービスマネージャであるZ氏にコンテナ技術の導入について 意見を求めた。Z氏は,試験項目に応じたコンテナをあらかじめ用意しておくことで, 現在のコンテナの廃棄と用意されたコンテナの起動を行うことができるので,試験 環境の整備を迅速かつ正確に行うことができると考えた。また,APの不具合によっ てAPが停止するインシデントが発生した場合,現在の運用では,原因を調査後,原 因となった問題を除去して再度APの起動を行っているが,その間は2台のアプリサ ーバのうち1台だけしか稼働していない状態となる。コンテナ技術を導入すれば,複 数のコンテナを稼働させることができることに加えて,(ア)コンテナを稼働させて インシデント発生前の状態に戻すまでの時間を短縮できると考えた。 〔デプロイ方法の改善 Z氏は,ゲームアプリの開発と運用における課題に対して,コンテナ型仮想環境を 活用したデプロイ方法を,ブルーグリーンデプロイメント方式にすることにした。 この方式では,二つの稼働環境を用意して,利用者が使う稼働環境を切り替えられ るようにする。具体的には,現状の稼働環境(ブルー)とは別に,新しい稼働環境 (グリーン)を構築して最新版のAPを準備しておき,デプロイする日時に合わせて, 利用者が使う稼働環境を切り替える運用方法のことである。 ブルーグリーンデプロイメント方式の例を図2に示す。 現状の稼働環境(ブルー) ソフトウェアpom [ジジorm| 新しい稼働環境(グリーン) 図2ブルーグリーンデプロイメント方式の例 =ye 図2の例では,現状の稼働環境(ブルー)で1.0版のコンテナが稼働している。新 しい稼働環境(グリーン)に2.0版のコンテナを起動させておき,コンテナ管理ソフ トウェアを使って,現在の稼働環境をブルーからグリーンに変更する。(イ)2.0版 のコンテナの動作に問題がないことを確認できた場合,1.6版のコンテナを停止し, 1.6版のコンテナを廃棄する。 [コンテナ型仮想環境の検証] Z氏とY Kit,コンテナ型仮想環境の検証を実施するための環境を新たに用意して, コンテナ型仮想環境の検証を開始した。 開発部では,APが出力するエラーログの情報などを,稼働環境に影響を与えない ようにアプリサーバに保存する設定としていた。そこで,今回の検証におけるAPの エラーログなどの情報も,コンテナ内に出力する設定とした。検証のために,コン テナを起動したところ,しばらく稼働していたがその後APが異常終了し,コンテナ が廃棄される事象が発生した。運用部が原因を調査するためにエラーログ情報の内 容を確認しようとしたところ,解析に必要な情報を取得できていなかったことが判 明した。そこで,|a|する運用方法を検討することとした。 Z氏は,コンテナオーケストレーションツールを導入し,コンテナの運用管理を自 動化することにした。Z氏が検討したコンテナオーケストレーションツールでは,起 動されているコンテナの負荷状況によって,自動的にコンテナのスケーリングが人行 われる。スケーリングでは,CPU使用率が一定のしきい値を上回る又は下回る場合に, コンテナ数の増減を行う。これによってCPU能力を最適化するとともに,CPU能力不 足によってシステムがダウンする事象の発生を防ぐ。必要となるコンテナ数は,次 の計算式によって求めることができる。 スケーリング後のコンテナ数=現在のコンテナ数X OE 期待するCPU使用率 現在の平均CPU使用率は,コンテナオーケストレーションツールが定期的に自動 的に測定を行う。Z氏は,検証で最大8個どまでコンテナを稼働できる環境を用意し, 現在の稼働環境の稼働状況を踏まえて,期待するCPU使用率を59%とした。 ={%=