古賀政純「Dockerがもたらすビジネス変革」

HPE開発部門におけるDocker導入事例--3つの決意表明へ - (page 2)

古賀政純(日本ヒューレットパッカード)

2017-09-26 07:15

仮想マシンを使った開発・テスト環境

 以前は、開発、ビルド、テスト環境に仮想化技術(VMware、KVM、Hyper-V)を採用することで、多くの課題を排除することができました。例えば、仮想マシンのテンプレートを用意し、そのテンプレートから様々な開発環境を用意するといった「テンプレートの繰り返し利用」によって、アプリケーション開発とテスト環境の複製を容易に行うことができました。

 しかし、仮想化基盤を導入してから数年経過すると、開発対象のソフトウェアの規模と複雑さが増大し、かつ、短期リリースの要求が厳しくなる状況において、開発用の仮想マシンそのもののファイルサイズの肥大化や、テンプレートの準備時間(各部門への払い出し処理にかかる時間)の増大、開発ソフトウェアがインストールされたゲストOS自体の起動時間やシャットダウン時間、さらには、ゲストOS自体の管理に手間がかかるといった運用上の問題が出てきました。

 ハイパーバイザ型の仮想化基盤における仮想マシンは、「テンプレート」と呼ばれる用途に応じた構成情報を含んだOS環境のイメージファイルで管理されることが少なくありません。このテンプレートには、ゲストOSのイメージファイル内にOSとアプリケーションがインストールされた形で存在します。

 別のユーザーが利用する場合や、別の用途にカスタマイズする、さらには、テンプレート内に含まれるアプリケーションを変更し、新しいテンプレートを作るといった場合は、テンプレートをコピーする必要があります。テンプレートをコピーすると、その分だけゲストOSのファイルをコピーすることになり、外部ストレージの容量を消費します。また、ゲストOSに組み込むソフトウェアなどが増える、あるいは、過去の状態に戻したいという理由から、スナップショット(その時点でのゲストOSの状態を記録したもの)を取得し、その数が増えると、ゲストOS自体のファイルサイズが肥大化する傾向にあります。(※)

(※)一般に、仮想化基盤におけるゲストOSのスナップショットは、非常にファイルサイズが小さいといわれますが、実際には、仮想化ソフトウェアの種類や取得の仕方によって、そのサイズは大きく異なります。Linux OSに標準で搭載されている仮想化ソフトウェアとして有名な「KVM(Kernel Virtual Machine)」では、スナップショットのサイズだけでも数ギガバイトから数十ギガバイトになることも少なくありません。スナップショットは、過去の状態に戻すことができるため非常に便利な機能ですが、大量に取得するとそれだけストレージを消費しますので注意が必要です。また、LinuxのKVM環境では、稼働中のゲストOSのスナップショットを取得すると、そのゲストOSは、スナップショットの取得処理が完了するまで長時間停止することもあるため、本番運用では、運用面で注意が必要です。

 個人で使う小規模で簡単な仮想化環境では、それほど問題にはなりませんが、HPE社内の開発部門では、非常に多くの人員で開発にあたるため、膨大な人数で開発を行う場合に、仮想化基盤のゲストOSの肥大化、起動・シャットダウンに掛かる手間、待機時間、開発ツールの導入にかかる手間、仮想化基盤やゲストOS自体のトラブルへ対応といったさまざまなオーバーヘッドが少しずつ積もり、結果的には、開発プロジェクト全体に無視できないレベルでの遅延が発生してしまいます。従来に比べて非常に高速な開発や膨大なテスト項目を迅速に実施することを実現するには、もはや仮想化基盤での効率化が限界に近づいていたというのが現実だったのです。


図. Docker採用以前の仮想マシンによる開発・テスト環境

 一般に、開発チームの生産性向上を実現するためには、プロジェクトの進捗管理、ソフトウェア工学に基づいた設計、コーディング技術、さらには、ソフトウェアのビルド作業の時間短縮などがあります。ビルド作業は、人間が記述したソースコードをコンピュータが理解できる実行ファイルに変換する作業だけでなく、さまざまなコードからなる複数のソフトウェアモジュールを組み合わせて1つのソフトウェアとして成立させる作業もビルドに含まれます。また、大勢の開発要員がしかるべきコードの提出を行っているかのチェックや、コードの変更管理、開発した本番用コードの承認作業、本番とほぼ同様の環境でのステージング作業なども必要です。

 ビルド作業の時間短縮や開発要員の作業効率向上というと、プロジェクト管理ツールや開発ツールの選定に話が終始しがちです。しかし、それだけでなく、開発者と運用担当者の両方にとっての共同利用のためのハードウェア基盤配備、アクセス手段自体の自動化や、ビルド処理の自動化がもたらす長所・短所など、開発ツールやプロジェクト管理ツールの使い勝手や機能以外のさまざまな検討が必要です。また、開発対象となるソフトウェアのスケールテストや開発基盤自体のメンテナンス効率なども加味し、開発用ハードウェア基盤の選定が必要となります。


図. 開発基盤導入では、多面的な考慮が必要

ZDNET Japan 記事を毎朝メールでまとめ読み(登録無料)

ホワイトペーパー

新着

ランキング

  1. セキュリティ

    「デジタル・フォレンジック」から始まるセキュリティ災禍論--活用したいIT業界の防災マニュアル

  2. 運用管理

    「無線LANがつながらない」という問い合わせにAIで対応、トラブル解決の切り札とは

  3. 運用管理

    Oracle DatabaseのAzure移行時におけるポイント、移行前に確認しておきたい障害対策

  4. 運用管理

    Google Chrome ブラウザ がセキュリティを強化、ゼロトラスト移行で高まるブラウザの重要性

  5. ビジネスアプリケーション

    技術進化でさらに発展するデータサイエンス/アナリティクス、最新の6大トレンドを解説

ZDNET Japan クイックポール

注目している大規模言語モデル(LLM)を教えてください

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]