Free online consultation available. Please feel free to contact us.

コンテナ

「コンテナ」

データ活用やDX成功に必要な考え方を、各種キーワードの解説で理解できる用語解説集です。
今回は、現在におけるソフトウェア開発、特にクラウド上でのソフトウェア開発において広く使われるようになっている技術「コンテナ」について考えてみましょう。

コンテナとは

コンテナとは、一つのOS実行環境内で、複数の独立したアプリケーションシステムの実行環境を作り出す技術のことです。それまで利用されてきた仮想マシンによるハードウェアレベルの仮想化に対して、OSレベルでの仮想化（OS-level virtualization）を行います。
仮想マシンを用いる場合と比べ環境を仮想化するオーバーヘッドが少ないことから、リソース効率が高く起動も高速にできることが期待できます。そのことから、マイクロサービスの実現手法として、クラウドネイティブなソフトウェアアーキテクチャを実現する基盤技術として活用されることが多くなってきています。

コンテナが登場するまでの、アプリケーションを実行する環境の経緯

「コンテナ」はクラウド時代の新しい技術としてよく話題にされますが、実質的にどのようなものなのかなかなか理解しづらいところがあります。どういう仕組みなのか理解できても、それがなぜ話題になっているのか解りにくいところもあります。一方でその反対に、実態を理解せずにこれからはコンテナである、と無用に騒いでいるようなこともあるかと思います。

まずは、コンテナが出現するまでの技術的な経緯についての説明、それを踏まえてなぜ今話題になっているのかを説明します。

最初：ハードウェアの上で直接ソフトウェアが動いている利用形態

ITを使って何かをするときには「ソフトウェア」と「ソフトウェアを動かす環境」が必要になります。ゲームソフトが一本も無いゲーム機に意味がないようにソフトウェアがなければ意味がありませんし、ソフトウェアだけがあっても動かすことが出来なければ意味がありません。

ゲーム機の例を出しましたが、ゲームソフトウェアとゲーム機のように、旧来はソフトウェアとそれを実行するハードウェアがセットで考えられてきました。例えば自社に業務システムを導入するなら、パッケージソフトウェアを購入するか開発し、それを動かすハードウェアであるサーバマシンを買ってきてインストールして利用しました。

つまり物理的な実行環境を、各ソフトウェアシステムがそれぞれ占有するような使い方です。

しかし問題点があった

しかしながらこの方法では、システムを導入するたびにハードウェアの導入が必要になってきます。また、ソフトウェアシステムが必要とする処理能力とハードウェアの能力に過不足があると無駄や不便が生じやすくなります。

例えば、経理部門がITシステムを導入してサーバマシンも配置したとします。次に生産管理システムが導入され、新たにサーバマシンが配置されたとします。ITが導入されるとどんどんサーバマシンが増えることになるのでは大変ですし、導入後にしっかり使えるようにとスペックをよくするとお金がかかり、コストを抑制すると導入後にスペック不足に陥り業務に差し支えて困ることもあります。

導入後、経理システムはハードウェアのスペックが余っていてサーバの性能が無駄になっており、その一方で生産管理システムは導入後に予想外に活用されたためスペック不足で遅くて困っているようなことは起こりがちでした。

それならば例えば、経理システムと生産管理システムを一台のサーバに入れて整理すればいいのではないか、と思えるかもしれませんが、なかなかそうはいきませんでした。各システムは違うアプリケーションと同じ環境で同時に動かしてもきちんと動く前提で作られている（動作保証されている）わけではないからです。

ハードウェア仮想化技術による「仮想マシン」

このような無駄や不便は、企業のITシステムでは多く発生していました。そこで活用されるようになったのが、ハードウェアの仮想化技術でした。物理的なサーバでソフトウェアを実行するのではなく、ハードウェアの仮想化技術を用いた「仮想マシン」上でソフトウェアを実行する取り組みです。例えば上記の例では、

  • 物理サーバ上でのソフトウェアの直接実行をしない
  • ハードウェアの仮想化技術を用いて、仮想マシン上での実行にする
  • 経理システム：専用に作った仮想マシン内にインストールする
  • 生産管理システム：こちらも別途、専用に作った仮想マシン内にインストールする

仮想マシンとは、PCのハードウェア環境（CPUやメモリ、ハードディスクなど）をソフトウェア上で仮想的に再現したものです。各アプリケーションからは物理マシンで実行しているのとほとんど変わらない状態でありつつ、仮想化されたハードウェアはデータであるため物理的に管理する必要がなくなり管理も簡単になります。例えば、「マシン丸ごと」のバックアップなども簡単にできるようになります。

たとえば一台の物理マシン上で、経理システムの仮想マシンと生産管理システムの仮想マシンを動かすことができます。それぞれ別の仮想マシンなので実行環境はそれぞれ独立しているので、同じ物理マシンで動かしても動作が干渉する心配もありません。

生産管理システムのスペックが足りず、経理システムでスペックが余っているのなら、経理システムの仮想マシンに割り当てている物理リソースを減らして、生産管理システムの割り当てを増やすことができ、仮想マシン間でスペックを融通できてマシンスペックを無駄なく活用しやすくなります。

  • 物理的な実行環境と、アプリケーションシステムの実行環境の直接の依存関係を、仮想マシンを使って切り離す
  • 一台の物理マシンで、複数の仮想マシンを動作させれば、複数の実行環境を同居させることができる
  • 仮想マシンごとにハードウェア資源の割り当てを調整できるため、スペックが余っているところから足りないところへの融通ができる。スペックが余ってしまう無駄も、スペックが足りなくなって動作に支障がでる問題も防ぐことができる
  • バックアップや動作環境の引っ越し（高いスペックの実行環境への引っ越しなど）も容易にできる

ポイントは仮想化技術により「物理的な実行環境と、アプリケーションから見た論理的な実行環境を切り離した」ことです。

仮想マシンの欠点をなくした「コンテナ」の登場

このような仮想マシンによる「仮想化」は一般の方のPC利用では稀だと思いますが、ここまで説明した長所以外にも多くのメリットがある技術であり、クラウドサービスにおいてはもはや物理的なリソースを直接利用することは少ないほどになっています。

しかしながら、仮想マシンにはオーバーヘッド（無駄）が多い問題がありました。つまり、旧来的に物理マシンでの実行なら、物理ハードウェアでロス無くソフトウェアが実行できるところ、

  • 物理マシン上のエミュレーションで仮想ハードウェアを実現し実行するために費やされるリソース
  • 仮想マシン上でも実行されるLinuxやWindowsなどのOSにより追加で消費されるリソース

オーバーヘッドは実際に大きく、仮想マシンを使うと物理マシンが持つ本来のスペックを存分に発揮できないようなことも起こりがちでした。

仮想マシンは便利な技術でしたが、冷静に考えてみると我々は別に個別にハードウェア環境を利用したいわけではなく（ハードウェアレベルで分離したいわけではない）、ただ「アプリケーションの実行環境を分離したい」だけです。ならば、環境だけ切り離せばいいじゃないか、として作られたのが「コンテナ」です。

  • 仮想マシンではなく、同じ物理ハードウェアを共有します（オーバーヘッドなし）
  • OSも同じLinuxを共有します（オーバーヘッドなし）
  • しかし、そのアプリケーション環境内部から見たときに「自分はこのLinuxを占有して利用している」かのような「環境にいるように見える」ようにします。

例えばファイルシステムの場合なら、アプリケーションAとBをインストールしたら、AからBのファイルが見え、BからもAのファイルやデータが見えます。AがLinuxに対して行った設定やAの実行プロセスなどもBから見えます、あるいはAとBを一緒に動かすと困るというのは、こういうことを通じてAとBの動作が干渉して正常動作しない懸念があることです。

それならば、例えば

  • AからはBのファイルは見えません。OS自体が持っているファイルとA自身のファイルしか存在しないように見える。
  • AからはBのプロセスは見えないし、Bが行った変更がBの世界以外に及ぶことがないようブロックされている。AからはA以外が環境中に存在しない感覚で利用できる。

「見え方」「見える範囲」「変更できる範囲」を制限しただけですが、これで仮想マシンのような大掛かりな仕組みは使わなくても「アプリケーションの実行環境を分離する」ことが実現できていますよね。このようなことをLinux（やUNIX）に備わっている機能を利用することで実現したものが「コンテナ」になります。

「実行環境だけを分離する」「アプリケーションごとに実行環境が分離できて便利」「オーバーヘッドがとても少なく効率的である」ことが特徴です。

なぜコンテナは話題になっているのか

技術的にどういうものかは最低限理解いただけたかと思います。あるいは「環境だけ」の話は何となく聞いたことがある人も多かったかもしれません。仕組みは解った、しかしこれがどうして世間で大きな話題になっているのでしょうか。

「マイクロサービス」などの先進的な開発スタイルを実現する基盤になった

仮想マシンは便利な技術でしたがオーバーヘッドも大きかったために、要所要所で利用するにとどめる必要がありました。しかしコンテナはオーバーヘッドが少ない技術でした。大量の仮想マシンを生成するような使い方は現実的ではない一方、「大量のコンテナ」を活用したシステムなら技術的に実現可能でした。

その結果、大量のコンテナを使ったアーキテクチャでシステム開発を行う新しい開発スタイルが生まれることになります。「マイクロサービス」と呼ばれる技術がその一例になります。アプリケーションの実行環境全体を互いに干渉しないように分離する利用方法にとどまらず、システム自体を文字通り大量の小さいコンテナで構成する従来とは異なるスタイルでした。

このようなシステムアーキテクチャを、AWSやNetflixなどの先進的なクラウドサービスが採用したことが広く世間で話題になり、クラウド方面での先進的な取り組みでは、コンテナでマイクロサービスであるという話になってゆきました。つまり、「今風の先進的なシステムアーキテクチャ」の前提となる基盤技術として話題になっているところがあります。

新しい「ソフトウェアの共通実行環境」

コンテナ技術はそれ自体も標準化され、「Windows10での実行に対応したアプリケーション」があるように「コンテナ環境での実行に対応したアプリケーション」が整備されるようになりました。

例えば、世間でWindows10の利用者が増え、Windows10向けのアプリが多数リリースされるようになっているのなら、経営としてもWindows10への対応は必要だと判断すると思います。同じように、コンテナ環境の利用者が増え、コンテナ環境向けのソフトウェア資産が沢山作られている状況があります。

またエンジニアも、コンテナ環境があることを前提にスキルを身につけていますから、コンテナが使える状況を前提にしたスキルセットの人が増えることになります。同じくクラウドサービスにおいても、コンテナが広く利用されていることを前提にしたサービスを整備するようになりつつあります。コンテナのエコシステムがあることも、コンテナに注目すべき理由になります。

しかしコンテナは究極の技術ではない

執筆時点においては話題になっているコンテナ技術ですが、あらゆる状況で利用すべき究極の技術ではありませんし、今後別の技術が主流になる可能性もあります。以下、コンテナ技術以外の可能性について少し紹介します。

「仮想マシン」でも同じようなことができる

物理環境から実行環境を切り離すことは仮想マシンでも実行でき、コンテナで取り組まれていることには仮想マシンでも実現できることは多くあります。

また仮想マシンはハードウェアレベルで仮想化されて切り離されているために高度に環境が分離されており、例えばセキュリティ的には強固な分離が実現しています。同一環境に悪意のあるコンテナ利用者が混在してしまい攻撃を受ける可能性に比べ、仮想マシンによる分離の方がより安全だと言えます。

また、よりオーバーヘッドが小さい仮想マシンの開発が進められており、仮想マシンもコンテナ並みに気軽に利用できるようになるかもしれません。同じく、仮想マシン並みにセキュリティ的な配慮がなされたコンテナ技術も開発されつつあります。

WebAssemblyなど他の技術

将来、コンテナ以外の技術が主流になっている可能性があり、また用途によっては別の技術が優れるケースもあるでしょう。

コンテナはLinuxの環境レベルでの仮想化を行っていますが、別のその水準で仮想化しなければならないわけではありません。Javaが使えればいいのであれば、Javaの実行環境レベルで分離していればいいかもしれませんし、PHPでWebアプリケーションを書いているだけならPHPから見て分離されていればそれで足りることになりますし、その方が合理的な可能性があります。

また現在コンテナのような利用ニーズに関連して、WebブラウザのJavaScript実行エンジンの技術をルーツに持つ「WebAssembly」という技術が、今後に向けて「環境を切り離す」技術として注目されるようになっており、もしかすると今コンテナがクラウド時代の技術として騒がれているように、近い未来にはWebAssemblyがこれからの技術だとして話題になっていることもあるかもしれません。

関係するキーワード（さらに理解するために）

  • コンテナオーケストレーション
    • コンテナ技術を用いたシステム開発や運用において、多数のコンテナを管理し運用し制御する自動化技術のこと。
  • マイクロサービス
    • コンテナ技術により実現し流行するようになった、新しいシステム開発のスタイルです。システムの構成要素を積極的に独立した小さい単位であるマイクロサービスとして作り、システム全体を多数のマイクロサービスで構成する考え方。
  • クラウドネイティブ
    • クラウドサービスの開発、あるいはクラウドサービス上でのシステム開発では、個別のマシン上でそれぞれ実行されるソフトウェアを開発することが多かった従来のシステム開発とは前提となる事情が大きく違うため、これまでとは違う考え方や違う手法、違う手段を用いたクラウド時代に即した取り組みが求められるようになりました。

クラウド時代、コンテナの時代でも活躍するファイル連携ミドルウェア「HULFT10」

HULFTはメインフレームの時代からクラウド時代の現在まで、様々なITシステム開発のスタイルや技術的環境の違いを超えたシームレスなデータ連携を実現してきました。

ファイル連携ミドルウェアの国内デファクトスタンダード「HULFT10」

国内で圧倒的な実績がある、国産MFT製品の最高峰にして「ファイル連携基盤のデファクトスタンダード」である「HULFT（ハルフト）」を是非お試しください。

HULFTはメインフレーム時代からUNIX時代への技術移行の時期に、新旧技術環境を非常に実用的に、また徹底的な高信頼性で金融機関のシステムでも採用される連携できる技術として登場し、その後WindowsやLinuxへも対応してあらゆる環境の違いを吸収してデータ連携できる手段への進化、現在ではクラウドサービスとのシームレスな連携にも対応しています。

ファイル連携は古い技術の印象もあるかもしれませんが、今ではクラウドサービスでの利用にも配慮がなされており、コンテナ環境での利用がスムーズに行える最新バージョンの「HULFT10」も開発されています。

今でもメインフレームが活躍している一方、WindowsやLinuxはもちろん、Amazon S3などクラウド上のオブジェクトストレージとの連携、さらにはコンテナ技術を用いた開発の世界など、技術も違えば考え方も重視されることも違う分野があります。それぞれの分野のエンジニアが苦労することなく互いにデータ連携する手段として、HULFTを活用ください。

⇒ ファイル転送の仕組みを学ぶ HULFT 製品紹介・オンラインセミナー
⇒ HULFT-WebConnect 製品紹介・オンラインセミナー
⇒ HULFT10（ハルフトテン）for Container Services

用語集 コラム一覧

英数字・記号

あ行

か行

さ行

た行

な行

は行

ま行

や行

ら行

わ行

» データ活用コラム一覧

Recommended Content

Related Content

Return to column list