令和6年度 春期 ITサービスマネージャ試験 午後Ⅰ 問3 コンテナ環境の運用管理とデプロイ改善

本設問では、新たにコンテナ型仮想環境を導入することで、運用部が得られるメリットについて問われています。

解答の根拠

コンテナ技術はOSレベルの仮想化であり、アプリケーションとその実行環境をひとまとめにしてパッケージ化するため、ポータビリティに優れています。この特徴により、開発環境で構築したコンテナイメージをそのまま試験環境や本番環境に展開でき、環境構築（ミドルウェアのインストールや設定など）の手間が省かれます。その結果、運用部にとっては試験環境整備の作業時間を削減できることや、迅速な環境整備が可能になるという利点が生まれます。

高得点のポイント

• 単なるコンテナの機能的特徴（「起動が速い」「ポータビリティがある」）に留まらず、それが「運用部にとってどのような業務上のメリット（時間削減、迅速化）をもたらすか」を明確に記述する。
• 開発部のメリット（「開発効率が上がる」など）を混同して記述しないよう注意する。
• 20字以内という制限の中で、端的に「作業時間の削減」や「迅速な整備」といった効果を表現する。

本設問では、インシデント発生時の復旧時間短縮に寄与するコンテナ技術の具体的な特徴を答えます。

解答の根拠

従来の仮想マシン（VM）では、環境を起動する際にゲストOSの起動プロセスから実行する必要があるため、復旧に時間がかかりました。一方、コンテナはホストOSのカーネルを共有しており、ゲストOSを起動するプロセスが不要なため、アプリケーション（AP）を非常に迅速に起動できます。この「起動の速さ」が、インシデント発生時のサービス復旧時間を短縮する直接的な理由となります。

高得点のポイント

• 時間短縮に関連する直接的なコンテナの特徴である「APの迅速な起動」にフォーカスして記述する。
• 時間短縮に関係しない別の特徴（リソース消費が少ない、環境の差異が少ないなど）を解答に含めない。
• 「〜だから」「〜ため」といった、理由を問う設問に呼応する文末で記述する。

本設問では、ブルーグリーンデプロイメント方式を採用するメリットについて問われています。

解答の根拠

ブルーグリーンデプロイメント方式は、稼働中の現行環境（ブルー）とは別に、新バージョンを展開した新しい環境（グリーン）を用意し、ロードバランサ等でトラフィックのルーティングを切り替えることでリリースを行う手法です。この方式を採用することで、切り替えの瞬間にのみトラフィックの向き先が変わるため、サービスをほとんど停止させることなく新しいアプリケーションのデプロイが可能になります。

高得点のポイント

• 「サービスを無停止（またはほとんど止めず）にデプロイできる」という最大のメリットを明示する。
• 単に「デプロイが簡単になる」などの抽象的な表現ではなく、ユーザー視点やサービス提供の観点からの効果を具体的に記述する。

本設問では、ブルーグリーンデプロイメント方式が、緊急メンテナンス時の旧バージョンへの切り戻し（ロールバック）時間をなぜ削減できるのかを問われています。

解答の根拠

ブルーグリーンデプロイメントでは、新環境（グリーン）へ通信を切り替えた後も、旧環境（ブルー、すなわち1世代前の稼働環境）をコンテナとしてそのまま残しておくことが可能です。もし新環境で不具合が発生した場合、バックアップデータからリストアしたり、旧バージョンのコンテナを新たに再構築・デプロイしたりする手間が不要になります。単純にロードバランサ等のルーティングを元の環境に戻すだけで復旧が完了するため、復旧時間が劇的に短縮されます。

高得点のポイント

• バックアップからのリストアや再デプロイを行うのではなく、「1世代前の稼働環境がそのまま残存している」という状態に着目して解答する。
• 講評にもある通り、現状の稼働環境を保持したまま新たな版を用意できるというブルーグリーンデプロイメントの仕組みの理解を示す。

本設問では、ブルーグリーンデプロイメント環境において、新バージョン（2.0版）で問題が発生した際に、旧バージョン（1.0版）へ切り戻すための具体的な手順を問われています。

解答の根拠

ブルーグリーンデプロイメント環境では、新旧の両環境が同時に存在しており、ユーザーからのリクエストはルータやロードバランサによって現在のアクティブな環境へ振り分けられます。したがって、問題発生時に旧バージョンに戻すためには、コンテナの再起動や再デプロイを行う必要はなく、単純に通信の接続先（ルーティング先）を1.0版のコンテナ（またはブルー環境）に切り替えるだけで完了します。

高得点のポイント

• 手順として「コンテナの操作（再起動など）」ではなく、「接続先（トラフィックの振り分け先）の切り替え」であることを明示する。
• 切り替え先として「1.0版のコンテナ」あるいは「ブルー」といった具体的な環境を指定する。

本設問では、コンテナ環境特有の揮発性（コンテナ破棄と共に内部データも消滅する性質）に対応するためのログ運用方法について問われています。

解答の根拠

コンテナ内に保存されたデータ（エラーログなど）は、コンテナが再起動や破棄されるタイミングで失われてしまいます。そのため、事後調査ができるようにするには、コンテナのライフサイクルに依存しない場所にログを退避させる必要があります。具体的には、ホストOS上のディレクトリをマウントした永続ボリュームや、クラウド上のオブジェクトストレージなど、外部記憶装置にログ情報を保存する運用が求められます。

高得点のポイント

• コンテナ内部に保存するのではなく、「外部の記憶装置」へ保存または転送することを明示する。
• 何を保存するのか（エラーログの情報）を簡潔に記述する。

本設問では、コンテナのスケーリング（オートスケール）時の必要コンテナ数を算出します。

解答の根拠

オートスケーリングでは、全体の負荷の総量を目標となる「しきい値」で割ることで、必要なリソース数（コンテナ数）を算出します。

1. 現在の総CPU負荷は、稼働しているコンテナ数と平均CPU使用率の積で求められます。
   $$4 \text{ (台)} \times 80\% = 320\%$$
2. スケーリングの目標となるしきい値（本文で指定されている値を仮に $50\%$ とします）で全体の負荷を割ることで、必要なコンテナ数が算出されます。
   $$320\% \div 50\% = 6.4 \text{ (台)}$$
3. コンテナ数は整数である必要があり、また負荷を目標しきい値以下に抑えるためには、計算結果の小数を切り上げる必要があります。
   $$6.4 \rightarrow 7 \text{ (台)}$$
   したがって、スケーリング後のコンテナ数は 7 となります。

誤答の解説

• 6 と解答した場合: 小数点以下を切り捨て、または四捨五入してしまっています。6台の場合、全体の負荷320%を6で割ると平均CPU使用率は約53.3%となり、しきい値の50%を上回ったままとなってしまうため誤りです。
• しきい値の読み取りミス: 本文中の目標となるしきい値を見落とし、異なる値で計算してしまった場合は不正解となります。