応用情報技術者 2022年 秋期 午後 問04
コンテナ型仮想化技術に関する次の記述を読んで、設問に答えよ。
C社は、レストランの予約サービスを提供する会社である。C社のレストランの予約サービスを提供するWebアプリケーションソフトウェア(以下、Webアプリという)は、20名の開発者が在籍するWebアプリ開発部で開発、保守されている。C社のWebアプリにアクセスするURLは、“https://www.example.jp/”である。
Webアプリには、機能X、機能Y、機能Zの三つの機能があり、そのソースコードやコンパイル済みロードモジュールは、開発期間中に頻繁に更新されるので、バージョン管理システムを利用してバージョン管理している。また、Webアプリは、外部のベンダーが提供するミドルウェアA及びミドルウェアBを利用しており、各ミドルウェアには開発ベンダーから不定期にアップデートパッチ(以下、パッチという)が提供される。パッチが提供された場合、C社ではテスト環境で一定期間テストを行った後、顧客向けにサービスを提供する本番環境のミドルウェアにパッチを適用している。
このため、Webアプリの開発者は、本番環境に適用されるパッチにあわせて、自分の開発用PCの開発環境のミドルウェアにもパッチを適用する必要がある。開発環境へのパッチは、20台の開発用PC全てに適用する必要があり、作業工数が掛かる。
そこで、Webアプリ開発部では、Webアプリの動作に必要なソフトウェアをイメージファイルにまとめて配布することができるコンテナ型仮想化技術を用いて、パッチ適用済みのコンテナイメージを開発者の開発用PCに配布することで、開発環境へのミドルウェアのパッチ適用工数を削減することについて検討を開始した。コンテナ型仮想化技術を用いた開発環境の構築は、Webアプリ開発部のDさんが担当することになった。
〔Webアプリのリリーススケジュール〕
まずDさんは、今後のミドルウェアへのパッチ適用とWebアプリのリリーススケジュールを確認した。今後のリリーススケジュールを図1に示す。

C社では、ミドルウェアの公開済みのパッチを計画的に本番環境に適用しており、本番環境のミドルウェアAのパッチ適用が10月中旬に、ミドルウェアBのパッチ適用が11月中旬に計画されている。また、10月、11月、及び12月に向けて三つのWebアプリ開発案件が並行して進められる予定である。開発者は各Webアプリ開発案件のリリーススケジュールを考慮し、リリース時点の本番環境のミドルウェアのバージョンと同一のバージョンのミドルウェアを開発環境にインストールして開発作業を行う必要がある。
なお、二つのミドルウェアでは、パッチ提供の場合にはバージョン番号が0.0.1ずつ上がることがミドルウェアの開発ベンダーから公表されている。また、バージョン番号を飛ばして本番環境のミドルウェアにパッチを適用することはない。
〔コンテナ型仮想化技術の調査〕
次にDさんは、コンテナ型仮想化技術について調査した。コンテナ型仮想化技術は、一つのOS上に独立したアプリケーションの動作環境を構成する技術であり、aやb上に仮想マシンを動作させるサーバ型仮想化技術と比較してcが不要となり、CPUやメモリを効率良く利用できる。C社の開発環境で用いる場合には、Webアプリの開発に必要な指定バージョンのミドルウェアをコンテナイメージにまとめ、それを開発者に配布する。
〔コンテナイメージの作成〕
まずDさんは、基本的なライブラリを含むコンテナイメージをインターネット上の公開リポジトリからダウンロードし、Webアプリの開発に必要な二つのミドルウェアの指定バージョンをコンテナ内にインストールした。次に、コンテナイメージを作成し社内リポジトリへ登録して、C社の開発者がダウンロードできるようにした。
なお、Webアプリのソースコードやロードモジュールは、バージョン管理システムを利用してバージョン管理し、①コンテナイメージにWebアプリのソースコードやロードモジュールは含めないことにした。Dさんが作成したコンテナイメージの一覧を表1に示す。

〔コンテナイメージの利用〕
Webアプリ開発部のEさんは、機能Xの変更を行うために、Dさんが作成したコンテナイメージ“img-dev_oct”を社内リポジトリからダウンロードし、開発用PCでコンテナを起動させた。Eさんが用いたコンテナの起動コマンドの引数(抜粋)を図2に示す。

図2中の-pオプションは、ホストOSの10443番ポートをコンテナの443番ポートにバインドするオプションである。なお、コンテナ内では443番ポートでWebアプリへのアクセスを待ち受ける。さらに、-vオプションは、ホストOSのディレクトリ“/app/FuncX”を、コンテナ内の“/app”にマウントするオプションである。
EさんがWebアプリのテストを行う場合、開発用PCのホストOSで実行されるWebブラウザから②テスト用のURLへアクセスすることで“img-dev_oct”内で実行されているWebアプリにアクセスできる。また、コンテナ内に作成されたファイル“/app/test/test.txt”は、ホストOSのfとして作成される。
12月1日リリース向け開発案件をリリースした後の12月中旬に、10月1日リリース向け開発で変更を加えた機能✕に処理ロジックの誤りが検出された。この誤りを12月中に修正して本番環境へリリースするために、Eさんは③あるコンテナイメージを開発用PC上で起動させて、機能✕の誤りを修正した。
その後、Dさんはコンテナ型仮想化技術を活用した開発環境の構築を完了させ、開発者の開発環境へのパッチ適用作業を軽減した。
設問1:〔コンテナ型仮想化技術の調査〕について答えよ。
(1)本文中のa〜cに入れる適切な字句を解答群の中から選び、記号で答えよ(aとbは順不同)。
解答群
ア:アプリケーション
イ:ゲストOS
ウ:ハイパーバイザー
エ:ホストOS
オ:ミドルウェア
模範解答
a:ウ
b:エ
c:イ
解説
解答の論理構成
- 問題文の該当箇所
“コンテナ型仮想化技術は、一つのOS上に独立したアプリケーションの動作環境を構成する技術であり、aやb上に仮想マシンを動作させるサーバ型仮想化技術と比較してcが不要となり、CPUやメモリを効率良く利用できる。” - サーバ型仮想化の特徴
・物理マシン(ホスト)上に“ウ:ハイパーバイザー”を導入し、その上で“イ:ゲストOS”を持つ仮想マシンを動かす。
・したがって、比較対象として列挙すべき語は「ハイパーバイザー」と「ホストOS」。 - コンテナ型仮想化の特徴
・コンテナはホストOSのカーネルを共有するため、仮想マシンのように“イ:ゲストOS”を持たない。
・従って “cが不要” に入るべき語は “イ:ゲストOS”。 - 空欄の割当
・aとbは順不同なので、- a=“ウ:ハイパーバイザー”
- b=“エ:ホストOS”
・c=“イ:ゲストOS”
- 結論
a:ウ、b:エ、c:イ となる。
誤りやすいポイント
- ハイパーバイザーとゲストOSの役割を取り違え、“ゲストOS上にハイパーバイザーが載る”と誤解する。
- コンテナでも独立したOSが動いていると思い込み、“ゲストOSが必要”と判断してしまう。
- aとbの順不同という指示を見落とし、記号の入れ替えによる失点。
FAQ
Q: ハイパーバイザーとホストOSはどちらも必ず存在しますか?
A: タイプ1(ベアメタル)ではハイパーバイザーが直接ハードウェア上で動作しホストOSは存在しません。問題文は一般的に多いタイプ2を想定し、両方を列挙しています。
A: タイプ1(ベアメタル)ではハイパーバイザーが直接ハードウェア上で動作しホストOSは存在しません。問題文は一般的に多いタイプ2を想定し、両方を列挙しています。
Q: コンテナ型仮想化では全くOSが不要なのですか?
A: コンテナ自身は独自のOSを持ちませんが、ホストOSのカーネルを共有して動作します。したがって“ゲストOSが不要”という表現になります。
A: コンテナ自身は独自のOSを持ちませんが、ホストOSのカーネルを共有して動作します。したがって“ゲストOSが不要”という表現になります。
Q: ミドルウェアをコンテナに入れる利点はパッチ適用以外にもありますか?
A: 依存関係を一元管理できるため、環境差異による動作不良を防ぎ再現性の高い開発・テスト環境を構築できます。
A: 依存関係を一元管理できるため、環境差異による動作不良を防ぎ再現性の高い開発・テスト環境を構築できます。
関連キーワード: コンテナ型仮想化、ハイパーバイザー、ホストOS, ゲストOS, 仮想マシン
設問1:〔コンテナ型仮想化技術の調査〕について答えよ。
(2)今回の開発で、サーバ型仮想化技術と比較したコンテナ型仮想化技術を用いるメリットとして、最も適切なものを解答群の中から選び、記号で答えよ。
解答群
ア:開発者間で差異のない同一の開発環境を構築できる。
イ:開発用PC内で複数Webアプリ開発案件用の開発環境を実行できる。
ウ:開発用PCのOSバージョンに依存しない開発環境を構築できる。
エ:配布するイメージファイルのサイズを小さくできる。
模範解答
エ
解説
解答の論理構成
- 問題文には
“サーバ型仮想化技術と比較してcが不要となり、CPUやメモリを効率良く利用できる。”
と記載されています。 - サーバ型仮想化では各仮想マシンごとにゲスト OS を含むためイメージが大きくなります。
一方、コンテナ型仮想化はホスト OS のカーネルを共有するのでゲスト OS(c)が存在せず、アプリケーションと必要最小限のライブラリだけを格納した小さなイメージで済みます。 - この特徴が直接表れている選択肢は
“エ:配布するイメージファイルのサイズを小さくできる。”
です。 - したがって正解は【エ】となります。
誤りやすいポイント
- 「開発者間で差異のない同一の開発環境を構築できる」はサーバ型でも可能でありコンテナ特有の優位点とは言い切れません。
- 「開発用PC内で複数Webアプリ開発案件用の開発環境を実行できる」も両方式で実現できます。
- 「開発用PCのOSバージョンに依存しない」は Docker Desktop などを使う場合はホスト OS 依存が残るため決定打になりません。
- コンテナの軽量性=イメージサイズと CPU・メモリ効率を結び付けて考えると選択を誤りにくくなります。
FAQ
Q: ゲスト OS が不要になる具体的な利点は何ですか?
A: イメージの容量削減だけでなく、OS 起動処理が省略されるためコンテナの起動時間が短くなり、リソース使用量も小さく抑えられます。
A: イメージの容量削減だけでなく、OS 起動処理が省略されるためコンテナの起動時間が短くなり、リソース使用量も小さく抑えられます。
Q: コンテナでもホスト OS とのカーネル互換性は考慮すべきですか?
A: はい。同じカーネルを共有するため、ホスト OS のカーネルとコンテナ内バイナリの互換性が前提になります。ディストリビューションをまたぐ場合は glibc などに注意が必要です。
A: はい。同じカーネルを共有するため、ホスト OS のカーネルとコンテナ内バイナリの互換性が前提になります。ディストリビューションをまたぐ場合は glibc などに注意が必要です。
Q: イメージサイズをさらに削減する方法はありますか?
A: マルチステージビルドでビルド用ツールを最終イメージから除外したり、Alpine などの軽量ベースイメージを用いるとさらに小さくできます。
A: マルチステージビルドでビルド用ツールを最終イメージから除外したり、Alpine などの軽量ベースイメージを用いるとさらに小さくできます。
関連キーワード: コンテナ、ゲストOS, オーバーヘッド、イメージサイズ、リソース効率
設問2:〔コンテナイメージの作成〕について答えよ。
(1)本文中の下線①について、なぜDさんはソースコードやロードモジュールについてはコンテナイメージに含めずに、バージョン管理システムを利用して管理するのか、20字以内で答えよ。
模範解答
開発期間中に頻繁に更新されるから
解説
解答の論理構成
- 問題文には「そのソースコードやコンパイル済みロードモジュールは、開発期間中に頻繁に更新されるので、バージョン管理システムを利用してバージョン管理している。」と明記されています。
- コンテナイメージにこれらを含めると、変更のたびにイメージを再作成・再配布する必要が生じ、開発効率が低下します。
- したがって、更新頻度の高い成果物はイメージに入れず、バージョン管理システムで取り扱う方が合理的であると導けます。
- よって解答は「開発期間中に頻繁に更新されるから」となります。
誤りやすいポイント
- 「パッチ適用の手間を減らすため」とだけ書くと主語がミドルウェアになり、設問の焦点であるソースコード管理の理由が欠落します。
- セキュリティや容量削減などを主因に挙げると、問題文の根拠とズレます。
- コンテナとバージョン管理システムの役割を混同し、「コードもイメージで一元管理すべき」と誤解するケースがあります。
FAQ
Q: ソースコードをコンテナに入れてはいけないのですか?
A: 技術的には可能ですが、更新のたびにイメージを再配布する手間が増えるため、問題文のように頻繁に変更がある場合は不利です。
A: 技術的には可能ですが、更新のたびにイメージを再配布する手間が増えるため、問題文のように頻繁に変更がある場合は不利です。
Q: ロードモジュールもバージョン管理システムで管理する理由は?
A: ロードモジュールもソースと同様に更新頻度が高く、差分管理や履歴追跡が容易になるためです。
A: ロードモジュールもソースと同様に更新頻度が高く、差分管理や履歴追跡が容易になるためです。
Q: コンテナを再作成するタイミングはいつが適切ですか?
A: ミドルウェアのパッチ適用など、基盤ソフトウェアのバージョンが変わるときに行うのが一般的です。
A: ミドルウェアのパッチ適用など、基盤ソフトウェアのバージョンが変わるときに行うのが一般的です。
関連キーワード: バージョン管理、コンテナイメージ、更新頻度、効率化、デプロイ
設問2:〔コンテナイメージの作成〕について答えよ。
(2)表1中のd、eに入れる適切なミドルウェアのバージョンを答えよ。
模範解答
d:10.1.2
e:15.3.3
解説
解答の論理構成
-
リリース時点の本番環境に合わせる
- 問題文に「開発者は…リリース時点の本番環境のミドルウェアのバージョンと同一のバージョンのミドルウェアを開発環境にインストールして開発作業を行う必要がある。」とあります。
- したがって、img-dev_nov には「11月1日リリース時点」の本番環境バージョンを設定します。
-
本番環境のパッチ適用予定
- 「本番環境のミドルウェアAのパッチ適用が10月中旬」「本番環境のミドルウェアBのパッチ適用が11月中旬」と記載されています。
- 11月1日は、ミドルウェアAだけがパッチ済み、ミドルウェアBは未パッチの状態です。
-
バージョン番号の増え方
- 「二つのミドルウェアでは、パッチ提供の場合にはバージョン番号が0.0.1ずつ上がる」と明示されています。
- 12月1日向けイメージ img-dev_dec には「10.1.2」「15.3.4」が設定済みです。これは両方がパッチ済みの状態を示しています。
-
バージョンを逆算
- ミドルウェアAは10月中旬にパッチ適用済みなので、12月1日向けと同じ「10.1.2」が11月1日時点でもそのまま使用されます。
- ミドルウェアBは11月1日時点ではパッチ前です。12月1日版「15.3.4」からパッチ1回分戻すと「15.3.3」になります。
-
結論
- d:10.1.2
- e:15.3.3
誤りやすいポイント
- 「11月中旬パッチ=11月1日には反映済み」と早合点し、15.3.4 を入れてしまう。
- 「12月1日版より前は1世代だけ巻き戻せば良い」と思い込み、ミドルウェアAまで 10.1.1 に下げてしまう。
- パッチが「0.0.1」上がるという規則を見落とし、桁違いの数値を記入する。
FAQ
Q: なぜミドルウェアAは11月1日でも「10.1.2」のままなのですか?
A: 本番環境では「10月中旬」にパッチ適用が完了しているため、11月1日リリース時点でも既に適用済みだからです。
A: 本番環境では「10月中旬」にパッチ適用が完了しているため、11月1日リリース時点でも既に適用済みだからです。
Q: ミドルウェアBのバージョンを「15.3.2」にする可能性はありませんか?
A: ありません。「15.3.4」がパッチ後、1回分戻すだけで「15.3.3」になると問題文の「0.0.1ずつ上がる」規則で確定します。
A: ありません。「15.3.4」がパッチ後、1回分戻すだけで「15.3.3」になると問題文の「0.0.1ずつ上がる」規則で確定します。
Q: 2回分以上パッチを飛ばして適用するケースは考えなくて良いのですか?
A: 「バージョン番号を飛ばして本番環境のミドルウェアにパッチを適用することはない」と明示されているため、連続して1段階ずつしか上がりません。
A: 「バージョン番号を飛ばして本番環境のミドルウェアにパッチを適用することはない」と明示されているため、連続して1段階ずつしか上がりません。
関連キーワード: コンテナイメージ、バージョン管理、パッチ適用、リリース計画
設問3:〔コンテナイメージの利用〕について答えよ。
(1)本文中の下線②について、Webブラウザに入力するURLを解答群の中から選び、記号で答えよ。
模範解答
イ
解説
解答の論理構成
- 【問題文】には
“図2中の-pオプションは、ホストOSの10443番ポートをコンテナの443番ポートにバインドするオプションである。なお、コンテナ内では443番ポートでWebアプリへのアクセスを待ち受ける。”
とあります。 - コンテナ内の待ち受けは443番ポート(HTTPS の標準ポート)ですが、ホストOS側では10443番ポートにフォワードされています。
- テストは“開発用PCのホストOSで実行されるWebブラウザ”から行いますので、ホスト名はローカルループバックを示すlocalhostになります。
- 以上より、ブラウザがアクセスすべき URL の構成要素は
・スキーム:https://(443番ポートをHTTPSで待受け)
・ホスト名:localhost(自分自身=ホストOS)
・ポート番号:10443(‐p オプションで公開したホスト側ポート) - この条件に一致する選択肢は
“イ:https://localhost:10443/”
となるため、解答はイです。
誤りやすいポイント
- ポート番号の対応先を逆に考え、https://localhost/を選んでしまう。-p ホストポート:コンテナポートの左側がブラウザから指定すべき番号です。
- ドメイン名“https://www.example.jp/”を使いたくなるが、これは本番環境用 URL であり、ローカルテストとは無関係です。
- HTTP/HTTPS の区別を忘れ、http://localhost:10443/と入力して証明書エラーや接続失敗になるケースもあります。
FAQ
Q: ホスト名を127.0.0.1にしても良いですか?
A: はい、localhostの別表記としてhttps://127.0.0.1:10443/でも接続できます。試験では選択肢にないためlocalhostで答えます。
A: はい、localhostの別表記としてhttps://127.0.0.1:10443/でも接続できます。試験では選択肢にないためlocalhostで答えます。
Q: ポート番号を省略するとどうなりますか?
A: HTTPS で番号を省略すると既定値443が使われます。今回ホスト側は10443なので省略すると正しくルーティングされません。
A: HTTPS で番号を省略すると既定値443が使われます。今回ホスト側は10443なので省略すると正しくルーティングされません。
Q: -p 10443:443ではなく-p 443:443にすれば URL も変わりますか?
A: はい、その場合ホスト側も443になるのでhttps://localhost/でアクセスできます。今回は10443をバインドしているため数字指定が必要です。
A: はい、その場合ホスト側も443になるのでhttps://localhost/でアクセスできます。今回は10443をバインドしているため数字指定が必要です。
関連キーワード: ポートフォワーディング、ループバックアドレス、コンテナ、HTTPS, バインド
設問3:〔コンテナイメージの利用〕について答えよ。
(2)本文中のfに入れる適切な字句を、パス名/ファイル名の形式で答えよ。
模範解答
f:/app/FuncX/test/test.txt
解説
解答の論理構成
- 問題文には「-vオプションは、ホストOSのディレクトリ“/app/FuncX”を、コンテナ内の“/app”にマウントするオプションである。」と明記されています。
- さらに「コンテナ内に作成されたファイル“/app/test/test.txt”は、ホストOSのfとして作成される。」とあります。
- マウントの仕組みより、コンテナ内パス“/app”に対する操作はホスト側の“/app/FuncX”に反映されます。
- よって、コンテナ内で作成された“/app/test/test.txt”に相当するホスト側のフルパスは“/app/FuncX/test/test.txt”となります。
- 以上より、fに入る適切な字句は「/app/FuncX/test/test.txt」です。
誤りやすいポイント
- 「ホストOS」と「コンテナ内」のディレクトリを混同し、元の“/app”をそのまま書いてしまう。
- マウント元とマウント先を逆に覚えてしまい、/app/FuncX をコンテナ側と誤認する。
- ファイルパスを途中で省略して「/app/FuncX/test/」のみを書いてしまう。
FAQ
Q: -v オプションで指定するパスは常にホストOS側が先ですか?
A: はい。Docker など一般的なコンテナ実装では「ホスト側パス:コンテナ側パス」の順序で指定します。
A: はい。Docker など一般的なコンテナ実装では「ホスト側パス:コンテナ側パス」の順序で指定します。
Q: コンテナ内でディレクトリを再帰的に作ってもホスト側に自動で作成されますか?
A: マウント先のディレクトリが存在すれば、その下に作成したファイル・ディレクトリはホスト側に同一構造で即時反映されます。
A: マウント先のディレクトリが存在すれば、その下に作成したファイル・ディレクトリはホスト側に同一構造で即時反映されます。
Q: シンボリックリンクを作るときも同じパス変換規則が適用されますか?
A: マウントで透過的に共有されるため、リンク先がマウント領域内であればホスト側にも同じリンクが見えます。
A: マウントで透過的に共有されるため、リンク先がマウント領域内であればホスト側にも同じリンクが見えます。
関連キーワード: コンテナ、ボリュームマウント、仮想化、パス変換、開発環境
設問3:〔コンテナイメージの利用〕について答えよ。
(3)本文中の下線③について、起動するコンテナイメージ名を表1中の字句を用いて答えよ。
模範解答
img-dev_dec
解説
解答の論理構成
- 本番環境の状態の確認
- 問題文には「“本番環境のミドルウェアAのパッチ適用が10月中旬に、ミドルウェアBのパッチ適用が11月中旬に計画されている。”」とあるため、12月中旬時点では両ミドルウェアともパッチ適用済みです。
- 開発環境に求められる条件
- 「“リリース時点の本番環境のミドルウェアのバージョンと同一のバージョンのミドルウェアを開発環境にインストールして開発作業を行う必要がある。”」と明示されています。
- したがって、12月中に行う修正作業は、パッチ適用後の本番環境と同じバージョンで行わなければなりません。
- コンテナイメージ一覧の参照
- 表1より
• “img-dev_oct” はパッチ適用前の状態。
• “img-dev_nov” は途中までの適用状態(de のまま)。
• “img-dev_dec” は「ミドルウェアA バージョン 10.1.2」「ミドルウェアB バージョン 15.3.4」と、両方のパッチが反映された最新版である。
- 表1より
- 結論
- 12月中旬~下旬に本番へ反映する修正には、両パッチが入った “img-dev_dec” を使う必要がある。
- よって③に入るコンテナイメージ名は img-dev_dec です。
誤りやすいポイント
- 「10月リリース向けの修正だから“img-dev_oct”を使う」と短絡し、リリース時点(12月末)の本番環境バージョンを見落とす。
- 表1のdeを読み替えずに“img-dev_nov”を選んでしまう。
- パッチ番号の増分が「“バージョン番号が0.0.1ずつ上がる”」ことから、どのイメージに何個パッチが入っているかを数え違える。
FAQ
Q: 過去のリリース案件を修正するときも最新版ミドルウェアで開発するのですか?
A: はい。問題文のとおり「“リリース時点の本番環境のミドルウェアのバージョンと同一”」という原則があるため、過去案件の修正でもリリース予定日に合わせた最新版を使います。
A: はい。問題文のとおり「“リリース時点の本番環境のミドルウェアのバージョンと同一”」という原則があるため、過去案件の修正でもリリース予定日に合わせた最新版を使います。
Q: “img-dev_nov” にはなぜ選ばれなかったのですか?
A: “img-dev_nov” ではミドルウェアBがパッチ適用前(e)のままです。12月時点の本番環境ではBにもパッチが入っているため条件を満たしません。
A: “img-dev_nov” ではミドルウェアBがパッチ適用前(e)のままです。12月時点の本番環境ではBにもパッチが入っているため条件を満たしません。
Q: コンテナ内にソースを入れない方針のメリットは?
A: 「“コンテナイメージにWebアプリのソースコードやロードモジュールは含めない”」ことで、コード変更時にイメージを作り直す手間を省き、ミドルウェア更新とアプリ更新を独立して管理できます。
A: 「“コンテナイメージにWebアプリのソースコードやロードモジュールは含めない”」ことで、コード変更時にイメージを作り直す手間を省き、ミドルウェア更新とアプリ更新を独立して管理できます。
関連キーワード: コンテナイメージ、パッチ管理、バージョン管理、リリース運用、開発環境一致


