令和4年秋期試験午後問題　問4

問4　システムアーキテクチャ

⇱問題PDF
コンテナ型仮想化技術に関する次の記述を読んで，設問に答えよ。
広告
　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に示す。
pm04_1.gif
　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に示す。
pm04_2.gif
〔コンテナイメージの利用〕
　Webアプリ開発部のEさんは，機能Xの変更を行うために，Dさんが作成したコンテナイメージ"img-dev_oct"を社内リポジトリからダウンロードし，開発用PCでコンテナを起動させた。Eさんが用いたコンテナの起動コマンドの引数(抜粋)を図2に示す。
pm04_3.gif
　図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日リリース向け開発で変更を加えた機能Xに処理ロジックの誤りが検出された。この誤りを12月中に修正して本番環境ヘリリースするために，Eさんは③あるコンテナイメージを開発用PC上で起動させて，機能Xの誤りを修正した。
　その後，Dさんはコンテナ型仮想化技術を活用した開発環境の構築を完了させ，開発者の開発環境へのパッチ適用作業を軽減した。
広告

設問1

〔コンテナ型仮想化技術の調査〕について答えよ。
  • 本文中のa～cに入れる適切な字句を解答群の中から選び，記号で答えよ。
  • 今回の開発で，サーバ型仮想化技術と比較したコンテナ型仮想化技術を用いるメリットとして，最も適切なものを解答群の中から選び，記号で答えよ。
a，b，c に関する解答群
  • アプリケーション
  • ゲストOS
  • ハイパーバイザー
  • ホストOS
  • ミドルウェア
(2) に関する解答群
  • 開発者間で差異のない同一の開発環境を構築できる。
  • 開発用PC内で複数Webアプリ開発案件用の開発環境を実行できる。
  • 開発用PCのOSバージョンに依存しない開発環境を構築できる。
  • 配布するイメージファイルのサイズを小さくできる。

解答例・解答の要点

  • a：ウ ※順不同
    b：エ ※順不同
    c：イ
  • エ

解説

仮想化を実現するコンピュータアーキテクチャは、どのような仮想化ソフトウェアを用いるかによって、ハイパーバイザー型、ホスト型、コンテナ型に大別されます。
pm04_4.gif
上図において、ハイパーバイザーとはハードウェア上に直接インストールされ仮想化環境を管理するソフトウェアを指します。ホストOSはハードウェア上にインストールされるOSを、ゲストOSはホストOS上の仮想マシンにインストールされるOSを指します。

本問で取り上げられているコンテナ型仮想化とは、ホストOS上にコンテナという互いに独立したアプリケーション空間を用意し、その空間上でライブラリやアプリケーションを動かす仕組みです。コンテナ型仮想化の代表的なオープンプラットフォームとしてDockerがあります。

コンテナを利用するには、アプリケーション実行に必要なコマンドや変数、ライブラリ、依存関係などの動作環境をまとめたコンテナイメージを、コンテナレジストリ（さまざまなソフトウェアのコンテナイメージの保管と配布を行う。DockerではDocker Hubが該当）からダウンロードし、これを元にコンテナを起動します。既存のコンテナイメージをダウンロードして利用できるだけでなく、一からコンテナイメージを作成することもできます。また、起動したコンテナにミドルウェアなどを適用し作業を行った後、そこからさらにコンテナイメージを作成することができます。作成後のイメージは、元となったイメージのバージョン違いなどとしてグループ化し、レジストリ上のリポジトリに登録することができます。

ハイパーバイザー型やホスト型のサーバ型仮想化と比較したとき、コンテナ型仮想化は、ゲストOSをインストールする必要がなく低リソースで利用可能であり、ゲストOSの起動がないためアプリケーションの起動が早く、仮想環境の作成及び廃棄がしやすいなどの特徴を持ちます。しかし、ホストOSとは別のOSの仮想環境を構築することができないという制約があります。
  • ハイパーバイザー型・ホストOS型ともに、仮想マシン(VM)のゲストOS上でアプリケーションを動かしますが、コンテナ型はコンテナ上でアプリケーションを動かすので、ゲストOSをインストールする必要がありません。したがって、空欄a・bには「ウ：ハイパーバイザー」と「エ：ホストOS」が当てはまります。そして、空欄cには「イ：ゲストOS」が当てはまります。

    ∴ab＝ウ：ハイパーバイザー、エ：ホストOS（順不同）
    　c＝イ：ゲストOS

  • 3つの仮想化技術の特徴を踏まえて、記述の正誤を考えます。
    • 誤り。ハイパーバイザー型やホスト型では仮想マシン上に、コンテナ型仮想化はコンテナの中に開発に必要な環境をまとめます。どちらも物理的なハードウェアの違いなどに影響されることなく、開発者間で差異のない同一の開発環境を構築することができます。よって、コンテナ型だけのメリットということはできません。
    • 誤り。どの方式でも一つのハードウェア上に複数の開発環境を構築することができます。よって、コンテナ型だけのメリットということはできません。
    • 誤り。ゲストOSを使用しないコンテナ型仮想化技術では、ホストOSのカーネル（プロセス管理・ファイルシステム等のOSの中核機能）を利用して隔離空間を作りアプリケーションを動かします。OSのバージョンが異なってもカーネルの機能に互換性があれば問題はありませんが、そうでなければ影響がでます。ホストOSのバージョンに依存するのは、コンテナ型のデメリットと言えるため不適切です。
    • 正しい。コンテナイメージは、コンテナの実行に必要なプログラムや設定ファイルなどの必要最低限の情報をレイヤ（層）として積み重ねて構成します。コンテナイメージのデータ量は、ゲストOSを含むサーバ型仮想マシンのイメージファイルと比べるとかなり小さいものです。配布するイメージファイルが小さければ、開発用PCへの適用に要する時間や各PCの起動時間を短縮することができます。本問で仮想化技術を用いた開発環境の導入を検討しているのは、開発環境へのミドルウェアのパッチ適用工数を削減するためなので、その目的と合致するメリットであると言えます。
    ∴エ：配布するイメージファイルのサイズを小さくできる。
広告

設問2

〔コンテナイメージの作成〕について答えよ。
  • 本文中の下線①について，なぜDさんはソースコードやロードモジュールについてはコンテナイメージに含めずに，バージョン管理システムを利用して管理するのか，20字以内で答えよ。
  • 表1中のd，eに入れる適切なミドルウェアのバージョンを答えよ。

解答例・解答の要点

  • 開発期間中に頻繁に更新されるから (16文字)
  • d：10.1.2
    e：15.3.3

解説

  • 問題文冒頭の2段落目に「ソースコードやコンパイル済みロードモジュールは，開発期間中に頻繁に更新される」とあります。コンテナイメージにソースコードやロードモジュールを含めると、更新される都度コンテナイメージを再構築し、社内リポジトリに登録し、開発者がダウンロードするというプロセスを繰り返すことになり、作業がとても大変になってしまいます。これではパッチ適用工数の削減という目的を達成することは到底できません。そこでこのような場合は、ソースコードやロードモジュールはコンテナイメージには含めずにホストOS側で管理し、コンテナ内からホストOS側のファイルやディレクトリを利用できるようにマウントします。本問では、コンテナ外のバージョン管理システムをコンテナから利用するということになっています。

    ∴開発期間中に頻繁に更新されるから

  • 〔dについて〕
    表1中のコンテナイメージ img-dev_nov は、11月1日リリース向け開発用コンテナイメージとなっています。図1でパッチ適用のリリーススケジュールを見ると、11月1日時点においてミドルウェアAはリリース済み、ミドルウェアBはテスト段階ということがわかります。

    次にバージョン番号について確認すると、両方のミドルウェアがパッチ適用後である12月1日リリース向けでは、ミドルウェアAは10.1.2、ミドルウェアBは15.3.4となっています。ミドルウェアAは11月1日時点でリリース済ですから同じ10.1.2となります。その一方、ミドルウェアBは11月1日時点においてまだリリースされていませんから、一つ前のバージョンということになります。問題文中に「パッチ提供の場合にはバージョン番号が0.0.1ずつ上がる」とあるので、15.3.4の一つ前のバージョン番号は15.3.3です。したがって、空欄dには「10.1.2」、空欄eには「15.3.3」が当てはまります。

    ∴d＝10.1.2
    　e＝15.3.3
広告

設問3

〔コンテナイメージの利用〕について答えよ。
  • 本文中の下線②について，Webブラウザに入力するURLを解答群の中から選び，記号で答えよ。
  • 本文中のfに入れる適切な字句を，パス名/ファイル名の形式で答えよ。
  • 本文中の下線③について，起動するコンテナイメージ名を表1中の字句を用いて答えよ。
解答群
  • https://localhost/
  • https://localhost:10443/
  • https://www.example.jp/
  • https://www.example.jp:10443/

解答例・解答の要点

  • イ
  • f：/app/FuncX/test/test.txt
  • img-dev_dec

解説

  • 【ドメイン名について】
    〔コンテナイメージの利用〕には「Webアプリのテストを行う場合，開発用PCのホストOSで実行されるWebブラウザから②テスト用のURLヘアクセスすることで"img-dev_oct"内で実行されているWebアプリにアクセスできる」とあります。テストの際にはWebブラウザから同一開発用PC上に存在するコンテナ内のWebアプリにアクセスすることになりますから、アクセス先として自コンピュータを指定する必要があります。自コンピュータ上にアクセスするにはIPアドレス 127.0.0.1（ループバック・アドレス）を指定するか、127.0.0.1を参照する特別なドメイン名 localhost を指定することになります。

    【ポート番号について】
    ドメイン名に続いて記載されている「:xxxxxx」の部分は、サーバのどのポートにアクセスするか指定するものです。デフォルト値はHTTPでは80、HTTPSでは443です。
    コンテナは443番ポートでWebアプリへのアクセスを待っているので、コンテナ上の443番ポートにリクエストを届ける必要があります。図2の起動オプションでは、ホストOSの10443番ポートをコンテナの443番ポートにバインド（結びつける）ことになっていますから、ホストOSの10443番ポートにリクエストを投げれば、コンテナ上の443番ポートに届くことになります。

    したがって、ドメイン名 localhost とポート番号 10443 を組み合わせた「イ」のURLが適切です。

    「ウ」「エ」は本番環境のURLなので誤り、「ア」はポート番号の指定がないためホストOSの443番ポートにアクセスすることとなり、コンテナにリクエストが届かないので誤りです。

    ∴イ：https://localhost:10443/

  • 〔fについて〕
    問題文に「-vオプションは，ホストOSのディレクトリ"/app/FuncX"を，コンテナ内の"/app"にマウントするオプションである」とあるので、"/app/FuncX"と"/app"が同一ディレクトリだと考えることになります。したがって、"/app"の部分を"/app/FuncX"に置き換えた「/app/FuncX/test/test.txt」が適切です。

    ∴f＝/app/FuncX/test/test.txt

  • 誤りが発見されたのは10月1日リリースの機能Xです。機能Xの開発にはコンテナイメージ img-dev_oct を使われていたことになりますが、このコンテナイメージはミドルウェアA、Bともにパッチが適用されていませんから、そのまま使うのは不適切です。修正版をリリースするのは12月の本番環境なので、12月の本番環境と同じ「img-dev_dec」を用いて開発をする必要があります。したがって、開発に用いるコンテナイメージは「img-dev_dec」が適切です。

    ∴img-dev-dec
広告
模範解答

前の問題次の問題

▲
Pagetop