手早く構築できるアプリケーション環境として注目されているコンテナ化。中でもDockerはコンテナ型仮想化技術のデファクトスタンダードといえます。コンテナの特性を活かすにはどのように活用するのが良いのか。キーワードは「マイクロサービス」と「可搬性」にありるようです。 どんなものか見ていくことにしましょう。

さらなる発展のカギ!? コンテナ型仮想化技術とは？

従来のハイパーバイザー型仮想化技術がOS単位での仮想化を行える技術だったのに対し、コンテナ型仮想化技術はホストサーバーのOSの上にユーザー空間を作りそこでのアプリケーション動作を可能としたアプリケーション実行環境単位のものとなります。ちなみに最近よく耳にするDockerとはDocker社の提供するオープンソースのコンテナ型仮想化ソフトウェアで、いくつかあるコンテナ型仮想化技術の中でもシェアNo.1です。（参考：使える! 情シス三段用語辞典62「Docker」）

図1：一般的な「サーバー仮想化」とDockerによる「コンテナ型仮想化」の違い

Dockerアーキテクチャとして、ホストのOSの上に１つのDockerエンジンが搭載されその上に1～n個のコンテナが載ります。

OSはホストのOSを共有して使うため、アプリケーション実行に必要なもののみをコンパクトにまとめたコンテナはファイルサイズも軽量で、起動にも時間がかかりません。 この「コンテナ」とは、文字通り、船の積み荷をまとめて運びやすくした「コンテナ」が語源となっています。 どのような形・質の積み荷でも、コンテナに格納することで持ち出しやすく、また、内容物が壊れにくくなります。
アプリケーションも同じで、コンテナにまとめることで可搬性が良くなり、ホスト間で移動をしてもどこでもアプリケーションが実行できるようになっているのです。

Dockerがコンテナ型仮想化技術のシェアを広げた要因として、「Docker Hub」というコンテナイメージ共有の仕組みがあることが挙げられます。「Docker Hub」というコミュニティにコンテナイメージがアップロードされており、世界中のユーザーが使用できる状態となっています。このイメージには、Jenkins、WordPressなどのアプリケーション公式のイメージもあり、それらを利用すればめんどうな設定もなく簡単にそのアプリケーション実行環境を手に入れることができます。

このように、コンテナ型仮想化は、インフラやOSの環境にこだわらなくても“アプリケーションをすぐに実行できる環境”を目的として実現した技術なのです。
SaaS/クラウドサービスは、シンプルで使いやすく、利用料金が安いという魅力がある反面、単一のサービスでは社内業務すべてをカバーできないことやこの先、社内の基幹システムとして採用した際に未来永劫サービスを提供してくれるのかわからないという不安も付きまといます。 しかしながら、前者はAPIエコノミーがすでに解決する方向にありますし、後者はDockerなどのコンテナ型仮想化技術により、事業継承がしやすい環境となることで利用者の不安も解消されるかもしれません。

コンテナ型仮想化の向き/不向き

コンテナに向いていること

では、コンテナ型仮想化は実際にどのような用途に向いているのでしょうか。 コンテナは、“高速なアプリケーション実行環境”であり、同じ環境をいくらでも簡単に複製することができます。 そのため、アプリケーション開発時のテスト環境などによく用いられています。
コンテナを使えばテスト要員ごとに同じ環境を配れるため、環境が競合してしまい、待ちが発生することや、環境要因でテストが遅れるというリスクを大きく減らすことができます。もし環境が壊れた場合にも、原因を探って修正をしたりバックアップからリカバリしたりする必要はなく、単純に壊れた環境を捨てて新しいコンテナを用意すればいいだけです。
データセンターの引っ越し（乗り換え）など、大きな環境変化にも対応しやすい構成であると言えるでしょう。

もちろんこれらはVMでも実現できますが、コンテナの方がより高速に環境の再現ができ、何より、インフラ・OSなどの設定の必要がないためアプリケーション周りのみに集中できます。

2013年にDockerが登場して以来2016年頃までは、こうした特長から開発環境・テスト環境に主に使用されていましたが、商用環境適用にはまだまだ課題が残っているという状態でした。 Kubernetesなどの運用ツールの進歩やコンテナ設計技術の広がりにより、実際の商用環境に適用されるようになったのは2017年頃からです。

また、商用でのコンテナの特性を活かした使い方として「マイクロサービス」があります。 これは小分けにしたサービスを組み合わせて大きなサービスを作り上げることを意味しています。

マイクロサービスとは？

「マイクロサービス」とは、独立した小さな機能をいくつも組み合わせて大きなサービス機能を提供することを指します。この“独立した”機能ということが重要で、ひとつひとつの機能が独立していることで機能ごとに改修や更新が簡単にできることというのがこの手法の大きなメリットとなります。

例えば、Webサービスにおけるユーザー要望やアップデートで頻繁に機能追加を行う場合では、このメリットにより簡単で確実にサービスを向上させていくことができます。COOKPADやLINE、メルカリなどの企業は既に実際のサービス環境にてマイクロサービスを導入しています。 他にも、特定の機能だけでもスケールしやすい、局所的な障害が全体に及びにくい、サービス単位の開発効率が良いなどの特徴があります。

また、余談かもしれませんがマイクロサービスの対義となることを「モノリシック」と言います。これは従来のアプリケーションアーキテクチャであり、必要な機能を全て包括した一体構造として開発されていることを指します。

コンテナは1コンテナ1アプリケーションとする使い方が基本です。そのためマイクロサービスとの相性がとても良く、マイクロサービスを採用する企業が増えればコンテナを採用する割合も高いことでしょう。

コンテナに向いていないこと

クラウドサービスの救世主のようなコンテナ型仮想化にもデメリットはあります。コンテナ技術の登場後、商用環境での利用がすぐに広まらなかった原因として、以下のような理由がありました。

・アプリケーションのコンテナ対応が必要
Dockerで運用するにはコンテナ用に開発されたアプリケーションである必要があり、すぐに移行するということはできなかった

・サービス設計の難しさ
商用環境では多くのアプリケーションを連携させる必要があるがそのサービス分割の設計の難易度が高かった

・運用の煩雑さ
多数のコンテナの配置管理、一つ一つのコンテナの状態管理を統合的に運用することが困難だった

・セキュリティ問題
Docker Hubからイメージをダウンロードして利用するとき、そのイメージ自体にウイルスや脆弱性が含まれている場合があるなどセキュリティの確保に困難な面があった

設計ができなければそもそも導入できません。 そういった意味でサービス設計の難しさの問題は大きく、コンテナ型仮想化はインフラ基盤とアプリケーション開発を人的にも明確に分けることができて効率がよい反面、インフラとアプリケーションの全体を管理して設計を行える高スキル人材が必要となります。
導入事例が少なく経験の共有ができなかった当初は、コンテナの良さを活かす設計のハードルがかなり高かったといえるでしょう。

しかしながら、現在は運用する技術も蓄積され、これらの問題をクリアしている事例も増えてきましたが、そもそものデメリットが無くなったわけではありません。特にセキュリティに関しては、別々のコンテナが一つのOSを共有するため、コンテナ間の確実な分離を必要とする場合にはあまり向いていないかもしれません。 しかしながら、コンテナ型仮想化環境に対応したセキュリティ製品も登場しており、そのリスクはミニマイズすることも可能です。

OSを共有することのデメリットとして、ホスト上にはホストと同じOSのコンテナしか作れないということです。さまざまなOSのテナントが混在するような環境では、コンテナよりも従来のハイパーバイザー型仮想化（VM）のほうが向いています。

また、コンテナをうまく配置すればリソースの効率的な集約にもつながりますが、それはあくまでも配置など運用の問題であり、コンテナそのものがリソース効率化の解決策とはなりません。

コンテナ市場のこれから

コンテナ型仮想化は技術と事例が蓄積されていくにつれ、商用利用も増えていきました。米451 Research社の調査結果では、コンテナ市場は2016年には7億6200万ドルであったが2018年には 15億3100万ドル、2020年には26億8800万ドルへ成長するとの予測が発表されています。

そんな拡大傾向が予想されるコンテナ市場において、技術の優位性をとるため各企業がしのぎをけずっている状況です。顕著な例ですが、2018年10月、IBMは340億ドルでレッドハットを買収することを発表しました。 日本円にして、なんと約3兆8000億円（発表当時の換算）にもなります！この超高額な買収劇はハイブリッドクラウド・マルチクラウド事業の強化目的がメインとみられますが、レッドハットは「OpenShift」というDockerやKubernetesの運用管理サービスを有しており、IBMはそれを取り込みコンテナ市場での存在感をも向上させる狙いがあるとみています。

今後はマルチクラウドとコンテナを併せて利用する形態が主流となるかもしれません。

Dockerは、サーバー間移動が容易という特性があります。移動先サーバーはクラウド上でもよく、マルチクラウド環境で別のクラウドプラットフォーム上に移動することも可能です。そのため、プラットフォームを選択する際に機能の制約でベンダーロックインされることがなく、各サービスのリソース状況やコストなどの要件に合わせて自由に選べることになります。（但し、クラウドベンダーが提供しているDocker連携サービスなどを利用する場合は、機能面でベンダ―ロックインが発生する場合もあります。）

以前に、大手携帯電話通信会社の全国的な通信障害が大きな話題となりました。 もちろん常日頃からキャリアは障害が起きないよう二重三重にカバーをしていることでしょう。 しかしながらその会社に万が一障害が起きれば、一社に依存している状態では全てのサービスが止まってしまいます。 または、障害が起きなくても、価格や仕様の変更などベンダ―ロックインによる負の影響を受けることもあるでしょう。

マルチクラウドとコンテナを活用することで、例えばパフォーマンスが落ちてきたデータセンタからの乗り換えもしやすくなります。

コンテナは、企業の有するシステムの更新頻度の向上や利便性に加え、その可搬性を活かし事業持続性への貢献という面においても優れた技術なのです。

【執筆：編集Gp　星野 美緒】