ITサービスマネージャ 2024年 午後1 問03

解答の導き方

誤りやすいポイント

• 「正しく整備できる」「依頼漏れや作業漏れを防止できる」といった内容だけを書くと、設問が除外している利点を答えたことになります。
• 開発部の試験が中断しなくなることは開発部側の利点です。設問では運用部にとっての利点を答えます。
• コンテナをあらかじめ用意しても、運用部の作業が完全になくなるわけではありません。廃棄や起動の作業に置き換わることで、環境整備に掛かる時間や手間が減る点が要点です。

FAQ

解答の導き方

1. 下線（ア）が問うているのは、インシデント発生前の状態に戻るまでの時間を、コンテナ技術によってなぜ短縮できるかです。
2. 現在の運用では、APが停止すると「原因を調査」し、「原因となった問題を除去」した後に、APを再度起動しています。そのため、APを再び稼働させるまでに時間が掛かります。
3. 一方、コンテナ技術には、環境の「準備、起動、廃棄などを迅速に行うことができる」という特徴があります。また、本文では複数のコンテナを稼働できることも述べられています。
4. したがって、停止したAPの原因調査や問題の除去に時間を掛けてから再起動するのではなく、コンテナを迅速に起動してAPを稼働させられることが、時間短縮につながります。

誤りやすいポイント

• コンテナ技術がAPの不具合そのものを修正すると考えないようにします。時間短縮の理由は、APを稼働させるためのコンテナを迅速に起動できることです。
• 「複数のコンテナを稼働できる」ことだけでは、時間短縮の直接的な理由になりません。設問が問うているのは、インシデント発生前の状態に早く戻せる理由です。
• 原因調査や問題の除去に掛かる時間が短くなる、と答えるのも適切ではありません。本文で示されているのは、コンテナの起動を迅速に行えることです。

FAQ

解答の導き方

誤りやすいポイント

• 「サービスを一切停止せずにデプロイできる」と断定すると、切替時に短時間の停止が生じる可能性を考慮できていません。
• 最新版のAPを準備することだけを述べ、利用者が使う稼働環境を切り替える点を見落とすと、停止時間を減らせる理由が不明確になります。
• 「開発期間を短縮できる」など、項番3の課題であるサービス停止とは異なる効果を答えないようにします。

FAQ

解答の導き方

1. 問われているのは、新しい版に問題が見つかったとき、1世代前のAPに戻すまでの時間をなぜ短縮できるかです。ポイントは、旧版を戻すための作業を、問題発生後に一から行う必要があるかどうかです。
2. ブルーグリーンデプロイメント方式では、「現状の稼働環境（ブルー）」とは別に「新しい稼働環境（グリーン）」を用意し、グリーン側で最新版を起動してから、利用者が使う環境を切り替えます。図2の例では、ブルー側に「コンテナ（1.0版）」、グリーン側に「コンテナ（2.0版）」があります。
3. 2.0版に問題が発生した場合、1.0版の環境をコンテナとして残してあれば、旧版を改めて準備・起動する作業を待たずに、利用者が使う環境を1.0版の側へ戻せます。そのため、旧版への復旧に掛かる時間を短縮できます。
4. したがって、短縮できる理由は、1世代前の稼働環境をコンテナとして残しておき、必要時に切り替えられることです。旧版を再構築する時間が不要になる点が重要です。

誤りやすいポイント

• コンテナの起動が速いことだけを理由にしないでください。この設問では、旧版の稼働環境をあらかじめ残せることが、復旧時間の短縮につながります。
• 「最新版を停止する」だけでは、旧版に戻す手順の説明として不十分です。利用者が使う環境を旧版側へ切り替えられることが要点です。
• 旧版の環境をすでに廃棄した後まで、同じ時間で戻せるわけではありません。旧版への切戻しに備えて、必要な間は環境を保持しておくことが前提です。

FAQ

解答の導き方

1. 問われているのは、2.0版のコンテナに問題が起きたとき、利用者が使う環境をどう戻すかです。
2. 図2では、ブルーに1.0版のコンテナ、グリーンに2.0版のコンテナが配置されています。デプロイ時には、利用者が使う稼働環境をブルーからグリーンに切り替えます。
3. 本文には、2.0版の動作に問題がないと確認できた場合に、1.0版のコンテナを停止・廃棄するとあります。したがって、2.0版に問題が見つかった場合は、ブルー側の1.0版が残っている段階です。
4. このため、1.0版を再構築するのではなく、利用者が使う稼働環境をブルーに戻します。操作としては、接続先を1.0版のコンテナに切り替えることになります。

誤りやすいポイント

• 1.0版のコンテナを新たに作り直す、と考えないようにします。問題がないと確認するまでは、ブルー側の1.0版が残っています。
• 問題のある2.0版を停止するだけでは、利用者が使う環境は1.0版に戻りません。利用者の接続先をブルー側へ切り替える必要があります。
• 「ブルー」と「グリーン」を取り違えないようにします。この例では、ブルーが1.0版、グリーンが2.0版です。

FAQ

解答の導き方

1. 今回の検証では、APのエラーログなどを「コンテナ内に出力する設定」としています。つまり、解析に必要な情報がコンテナの中にだけ保存される状態です。
2. その後、APが異常終了し、コンテナが廃棄されています。コンテナと一緒に内部のログ情報も失われるため、運用部は原因調査に必要な情報を取得できませんでした。
3. したがって、コンテナが廃棄されてもエラーログが残るよう、コンテナの外に保存する必要があります。具体的には、エラーログの情報を外部記憶装置に保存する運用にすれば、廃棄後も原因の調査に利用できます。

誤りやすいポイント

• コンテナ内にログを保存し続けるだけでは、コンテナの廃棄時にログも失われる可能性があります。
• コンテナを再起動することと、異常終了前のログを残すことは別の対策です。原因調査には、廃棄後も参照できる保存先が必要です。
• エラーログを「出力する」だけでは不十分です。コンテナの外に保存し、廃棄後も利用できるようにする点が重要です。

FAQ

解答の導き方

1. 本文の計算式は、「現在のコンテナ数×現在の平均CPU使用率／期待するCPU使用率」です。期待するCPU使用率は本文で50%とされています。
2. 今回は現在のコンテナ数が4、現在の平均CPU使用率が80%なので、式に当てはめると、スケーリング後のコンテナ数は $4\times 80÷50=6.4$ となります。使用率は割合同士の比として計算するため、80%と50%の「%」は相殺されます。
3. 問題文では、小数が発生した場合は切り上げるよう指定されています。したがって、6.4を切り上げて整数にします。最大8個まで稼働できる環境ですが、計算結果はその範囲内です。

誤りやすいポイント

• 6.4を四捨五入して6にしないようにします。指定されているのは切り上げです。
• 分母には、しきい値ではなく本文で設定された「期待するCPU使用率」の50%を使います。
• 「%」を付けたまま計算して混乱しないようにします。80%と50%の比は $80÷50$ です。
• 最大8個という上限を、今回の計算結果に適用して値を変える必要はありません。計算結果は上限を超えていないためです。

FAQ