巷で話題のDockerとは？
Dockerが利用される背景
今、世界中の開発者やIT部門において「Docker」（ドッカー）が注目されています。もともと、DotCloud社（現 Docker Inc.）が、開発者やIT部門をターゲットとしたアプリケーションやOSの開発・配備を行うための基盤ソフトウェアとして開発され、2013年にリリースされました。このソフトウェアは、オープンソースソフトウェアの「Docker」として公開され、その使い勝手の良さから、多くの開発者、IT部門の管理者で瞬く間に利用されることになりました。Dockerは、仮想化ソフトウェアにみられるような性能面での劣化を極力排除したコンテナ技術の採用により、仮想化ソフトウェアに比べ、極めて集約度の高いITシステムを実現することができます。しかし、このDockerが注目される理由は、ハイパーバイザー型の仮想化ソフトウェアに比べてのハードウェア資源の消費や性能劣化が小さいというだけではありません。
Dockerが注目される背景には、アプリケーション開発者にとって足かせになる「ハードウェアの調達やメンテナンス、ITシステムのチューニング」などの隠蔽があげられます。ハードウェアなどのアプリケーション開発にあまり関係がない作業については、開発者にとって重要ではなく、むしろ担当範囲外であってほしいと願うものです。一般的に、アプリケーションの開発者は開発に専念したいという欲求あります。なぜならば、開発以外での作業工数が、開発した成果物の単価を押し上げ、ソフトウェアの価格競争力を低下させる原因になりかねないからです。また、アプリケーションのインストールすら煩わしいと感じる開発者も数多く存在します。このようなアプリケーション開発者の悩みを背景に、Dockerのようなアプリケーション単位での分離や開発環境の作成と廃棄が容易にできる仕組みが発展し、アプリケーションのメンテナンスの簡素化がより一層進んでいます。これは、システム管理者よりもアプリケーション開発者にとってのメリットが非常に大きいことを意味します。従来のKVM等によるハイパーバイザー型の仮想化環境は、アプリケーション開発者にとってのメリットというよりもむしろ、ITシステムの管理者にとってのメリットが大きいものでした。しかし、Dockerの仕組みによって、アプリケーションの開発と実環境への素早い展開と運用の両立がいよいよ現実のものとして見えてきました。これは、近年、開発者やIT部門の間で話題になっている「DevOps環境」の実現に他なりません。アプリケーション開発者やIT部門にとっては、ハードウェア資源を意識しない環境、すなわち、本当の意味での「雲」の上でアプリケーションの開発、運用、廃棄等を迅速に行える環境がDockerによって手に入れることができるのです。
使い勝手の優れたDocker
Dockerは、柔軟なアプリケーションの開発環境を提供しつつも、IT部門にとっては、OS環境を簡単に構築し集約して利用できることから、仮想化ソフトウェアにとって代わるというイメージがありますが、実は、それだけではありません。複数のOS環境とアプリケーション環境をパッケージ化し、インターネットを通じて世界中の開発者やIT部門のメンバーが作った環境をすぐに利用できるといったメリットがあります。ネットワークを通じて、IT部門が用意した環境をすぐに使うという構想は、クラウドコンピューティングにおけるIaaS（Infrastructure as a Service）を想像するかもしれません。クラウド基盤としては、ハードウェアやOSを提供するOpenStackなどのIaaS向けのソフトウェアが有名ですが、基盤が迅速にサービスとして利用者に提供されたとしても、それらの基盤上で動くアプリケーションの開発や実行環境の使い勝手や柔軟性がないとITシステム全体としてあまり意味がありません。Dockerが注目される理由の1つは、このアプリケーションの開発環境と実行環境をパッケージ化し、迅速な配備や廃棄が可能である点があげられます。また、IaaSのようなクラウド基盤を構築できなくても、マルチOS環境を手軽に作ることができる点は、Dockerの大きな魅力の1つと言えるでしょう。アプリケーションの開発とマルチOSの実行環境をクラウドソフトウェアに依存せずに簡単に配備できることは、初期投資が限られるようなITシステムに携わる開発者と管理者の双方にとって大きなメリットです。
Dockerは、アプリケーションとOSをパッケージし、イメージ化する機能だけでなく、コンテナの機能に加えて、APIの提供やインターネットを通じて世界中の開発者の成果物を入手したり、逆に成果物をアップロードしたりすることで、成果物を効率よく管理、利活用する仕組みや、それらの一連の作業を自動化する機構などが備わっています。クラウド基盤ソフトウェアに比べ、導入のハードルも比較的低く、これらの魅力的な機能を簡単に試すことができるため、多くの開発者やIT部門の管理者での利用が急激に広まっています。
Dockerは、高性能なアプリケーションの開発・実行環境の提供だけでなく、それらのOSやアプリケーションを世界中で共有し、ITシステムがある目的を達成するために必要な工程を自動化するサービスを提供する点が革新的と言えます。世界中の開発者やIT部門のシステム管理者が共通して理解できる同じITシステムを使えば、他者が作ったシステムを少し変える、または、そのまま使うことで、開発、システムテスト、実システムへの配備の工数を大幅に削減することができるようになります。具体的には、例えば、Webアプリケーションの開発において、その動作に必要となるライブラリや、起動、停止、監視用のスクリプトを新たに調査・別途開発するといった“追加の作業”を極力おさえることができます。
このような考え方が生まれる背景には、クラウドコンピューティングといった「ITシステムをサービス化する」という時代の流れももちろんありますが、それだけではなく、ITシステムが支える企業のビジネス（顧客ニーズ）がグローバル化とともに多様化し、その変化が激しくなっていることがあげられます。このことから、欧米では、寿命が来るまで目的を固定化してITシステムを設計・利用するといった考え方から、革新的なビジネスを生み出すために必要な新しいITシステムを柔軟でかつ安定的に作成・変更・廃棄できる仕組みを持つという考え方に注目が集まっています。また、それに伴い、システムの開発においても、要件を100パーセント定義した上で、システム開発、テスト、配備を行うといった方法から、ある程度短い期間で部分的に開発・テストを行ったものをリリースし、必要に応じて追加の開発や外部になる既存のOSとアプリケーションがパッケージ化されたものを必要に応じて調達するといった、いわゆる「アジャイル開発」の必要性も同時に高まっています。欧米において、このような柔軟性の高いITシステムに積極的に取り組み、実戦投入しているのは、オープンソースの技術に明るい非常に先進的な一部の企業といえますが、このような新しい開発手法や運用の在り方を取り入れようとする中小企業も徐々に増えてきています。
イミュータブル・インフラストラクチャ
Dockerのように、システムの開発者と運用管理者の双方が連携してITシステム全体の開発行う、いわゆる“DevOps（Development：開発、Operation：運用）”の考え方は、旧来の要件定義を明確化し固定化した個別システム計画では、あまり見られません。仮想化技術が成熟し、仮想化ソフトウェア製品の採用が当たり前になった昨今、仮想化基盤が実際に導入されたシステムを見渡してみると、柔軟性に富んでいるはずのシステムが、導入後、あまり変更が行われずに運用されていることが少なくありません。仮想化基盤において、システムに変更を加えると言っても、仮想化ソフトウェアのライブマイグレーション機能によって、別の物理サーバーに仮想マシンを稼働させたまま移動させることにより、日常のメンテナンスを無停止で行うといった運用上の工夫がみられる程度がほとんどです。いったん、仮想化ソフトウェア上で稼働するアプリケーションの開発が完了し、稼働試験にパスし、実運用で稼働すると、よほどの理由がないかぎり、そのアプリケーションのバージョン、仕様、ソースコード、起動・停止、監視等に関連する周辺のスクリプト等は、そのままにしておく場合が少なくありません。OSやライブラリに対するセキュリティパッチの適用といったクリティカルな作業でも、現在利用しているアプリケーションの稼働可否の判断が困難であるという理由から、パッチを適用せずにセキュリティホールをそのままにしておくといった重大な問題を放置している場合も少なくありません。
また、仮想化ソフトウェアの導入により、ハードウェアとOSの間にハイパーバイザーが介入することで、ハードウェア基盤、ハイパーバイザー、仮想マシン、ドライバー、監視エージェント、ゲストOS間における障害発生時の問題解決を複雑化させることなどがサービスプロバイダー等で問題視されています。
さらに、日本の場合は、物理基盤や仮想化基盤のどちらにおいても、欧米に比べて、業務要件ごとの個別最適化（企業内のガラパゴス化）の傾向があるため、どうしてもITシステムを固定的に構築してしまい、柔軟性に欠ける傾向が顕著です。逆にビジネス要件の変化に伴って、ITシステムの柔軟性を維持・拡大するために、システムの更新、改良を行う必要性を認識できたとしても、様々な技術的課題に直面します。特に問題視されているのが、OSの更新作業や現行システムへのバグ修正パッチ等の適用、ミドルウェアやアプリケーション、スクリプトの更新などを行うと、現行のオープンソースソフトウェア群の連携が崩れてしまい、結果的に業務アプリケーションがうまく動作しなくなる恐れがあるという点です。
そこで、現在注目を浴びているのが、サービスプロバイダーなどで導入されているイミュータブル・インフラストラクチャ（Immutable Infrastructure）と呼ばれるITインフラのアーキテクチャです。本番用のシステムには一切手を加えず、「不変の状態である」ということから、イミュータブルという名前が付けられています。イミュータブル・インフラストラクチャは、本番系システムと開発系システムの合計2系統のシステムを持ちます。開発用のシステム上で稼働するコンテナの環境においてソフトウェアを開発した後、負荷分散装置の通信の向きを切り替えて本番用のシステムに変更する運用形態をとります。
イミュータブル・インフラストラクチャでは、開発系システムに対して、新しい要件が加わる等により、サービスやアプリケーションが新たに必要になった場合は、コンテナを新規に作成し、その代わりに不要となった既存の旧システム（旧コンテナ等）を廃棄するという特徴を持ちます。この特徴は、イミュータブル・インフラストラクチャにおけるディスポーザブル・コンポーネンツ（廃棄可能な部品、構成要素）と呼ばれます。
例えば、アプリケーションの動作テストを繰り返すたびに新しいコンテナを作成し、すべてのテストが終了したら、途中で作ったコンテナは廃棄するといった方法があげられます。従来の固定的な個別最適化されたシステムの場合、導入当初は安定的に稼働していたものであっても、パッチの適用や機能追加を施すと、そのシステムは、大量のパッチが適用された状態になってしまいます。管理者が厳密に大量のパッチ適用や変更履歴を追跡できたとしても、システムが正常に稼働できるかどうかの判断もあやふやになりがちになり、誰もそのシステムの挙動を正確に把握できなくなる可能性があります。したがって、パッチの適用状況の把握といったサーバー環境の現在の状態を管理することが非常に煩雑になるならば、“サーバーの状態を管理しない運用方法”を取ることで、開発者も管理者も煩雑なシステム管理から解放されるべきであるというのがこのイミュータブル・インフラストラクチャの考え方と言えます。
イミュータブル・インフラストラクチャでは、古い状態のものを廃棄し、サーバー環境を毎回新しい状態にするため、常に「パッチのつぎはぎがない綺麗な状態」で使用することができます。このため、サーバーのパッチ適用、状況確認などの煩雑な作業できるだけ排除した運用が可能となるのです。
また、従来であれば、システムの構築に関連する自動化スクリプトは、アプリケーションやその時のハードウェア構成やシステムの状態によって様々な場合分けのロジック（システムの現在の状態に応じた条件分岐のロジック）を組み込むため、運用が非常に複雑になる傾向がありますが、イミュータブル・インフラストラクチャの場合は、毎回新しいシステムで稼働するため、自動化スクリプトのロジック内の場合分けの数を減らすことができ、確実に動作するシステムを構築できるといったメリットも享受できます。
イミュータブル・インフラストラクチャの場合、アプリケーションの開発が進んだ時や、新しいバージョンのOSやアプリケーション等がリリースされるたびに、開発系のサーバー環境でそれらを配備する必要があります。この配備作業を、物理サーバー環境の追加調達なしに行うためには、集約度の高いコンテナによる仮想環境が必要になります。また、開発者やIT部門の要求に応じてサーバー環境を迅速に配備するためには、先述の自動化も必須になります。このように、イミュータブル・インフラストラクチャは、開発や運用が頻繁に更新されるため、もし、コンテナ技術を使わずに、物理サーバー上に紐づいた非仮想化環境においてイミュータブル・インフラストラクチャを構築しようとすると、ハードウェア機器自体の調達とサーバーのファームウェアやOSのベアメタル配備が頻繁に発生するという特徴をおさえておく必要があります。もしハードウェア調達が頻繁に発生してしまうと、データセンターのスペースの圧迫と消費電力の増加につながるため、注意を要します。また、コンテナを使わないでイミュータブル・インフラストラクチャの配備を行う場合、ハードウェアに依存したファームウェアとOSの配備手順や廃棄手順が必要になるため、コンテナを使う場合に比べて、アプリケーションの開発者だけでなく管理者側から見た場合の可搬性も大きく損なわれてしまいます。イミュータブル・インフラストラクチャは、まさに、非常に軽量、かつ、OSとアプリケーション環境の作成と廃棄が容易で、可搬性が高いコンテナ技術があってこそ実現できるアーキテクチャと言えます。
イミュータブル・インフラストラクチャのポイント
- 開発系システムにてアプリケーションを配備後、負荷分散装置における通信の向きを切り替える
- 本番系システムにパッチを当てていくようなシステムの改良、改変は、一切行わず、不変である
- 新規本番系に問題が発生した場合は、負荷分散装置の通信の向きを旧システムに戻す
- サーバー、OS、アプリケーション環境の構築を自動化する仕組みが必要である
- 開発者と管理者の双方にとって、環境の作成や廃棄が容易な軽量のコンテナ技術の組み合わせが推奨される
Dockerに向くシステム、向かないシステム
一方で、ビジネス要件が目まぐるしく変化しないのであれば、Dockerのような革新的なソフトウェアなど必要ないのではないかという意見もあります。ある業務目的を達成するために、要件定義を正確に行い、要員確保、ハードウェア、OS、アプリケーションのバージョンの決定、カットオーバー日の決定、パッチ適用可否、運用方法、廃棄の期日まで厳格に決められているITシステムは、世界中に山のようにあります。例えば、銀行のオンラインシステム、原子力発電所などの制御システム、鉄道や航空機のチケット予約・販売システム、量販店の通信販売システムやクーポンシステム、通信インフラなど、絶対に停止しては困るようなミッションクリティカルシステムなどがこれに相当します。このようなシステムは、構成を少しでも変化させると、業務に多大な影響が出ることが考えられるため、ビジネスの変化が多少あるといっても、ITシステム自体を大きく変化させることはほとんどありません。いわば、「Docker向きではない頑健な社会インフラの供給基盤システム」といってもよいでしょう。
逆にDockerに向く環境は、サービスプロバイダー、ホスティングなどのITサービスが日々変化するようなシステムと言えます。ITシステムが変化するというと、先述のように軽量のコンテナ上でアプリケーション開発が頻繁に行われ、革新的なサービスが次々と提供されるというイメージがありますが、開発が頻繁に行われないような環境でも、ITシステムは変化します。例えば ITシステムの運用面で考えてみると、アプリケーションの開発が行われないようなシステムでも、複数のOSやミドルウェアの新規導入、新しいアプリケーションへの切り替えの手間を減らしたいというニーズがあります。さらに、それらの複数のOS環境を同時に稼働させる場合、自社で所有するデータセンターの設置スペースや消費電力の都合により、性能劣化を極力減らした形で集約率を大幅に向上させたいというニーズもあります。Dockerのような基盤があれば、アプリケーションの開発だけでなく、このようなITの運用面でのニーズにも対応でき、そのメリットの享受は、決して無視できるものではありません。
Dockerの課題
Dockerは、2015年時点において、先進的な企業において次々と導入されており、事例も次第に公開されはじめていますが、多くのユーザーは大量のDockerコンテナの管理の簡素化を課題にあげています。Dockerは、シンプルなコマンドラインを提供していますが、GUIを提供する管理ツール類はまだ発展途上であるのも否めません。すなわち、Dockerだけでシステムがすべて完結することはなく、効率化のための周辺ソフトウェアの整備をある程度視野に入れなければなりません。海外などのDocker事例では、開発部門やIT部門の簡素化がDockerによって達成できたことが紹介されていますが、実際には、大量のコンテナを正常に稼働させるシステムにするためには、Linuxコンテナや、チューニングを含めたLinux OS上のプロセスの挙動に関する知識が必要になります。コンテナにどのようなアプリケーションをいくつ搭載すべきかという指針についても、現在コミュニティで活発な議論が行われています。1つのコンテナに搭載するアプリケーションの数をあまり多くすると可搬性が損なわれますが、1つのコンテナに1つのアプリケーションのみを搭載すると、コンテナの数が指数関数的に増加してしまい、管理が複雑になるのではないかという意見もあります。さらに、複数のコンテナが連携するためのオーケストレーションソフトウェアも現時点では発展途上と言えます。
現在、Dockerに適用可能な構成管理・自動設定ツールとして、オープンソースソフトウェアのAnsible、Chef、Puppetなどがあげられますが、一方で、企業においては、ビジネスアプリケーションのワークフロー管理を行う商用ソフトウェアなどがすでに導入されている場合も多く存在しており、それらの商用ソフトウェアが、Dockerにうまく対応できるかどうかも明確になっていません。いくつかのベンダーは、Dockerにおけるワークフロー管理やオーケストレーションにすでに取り組みを見せていますが、米国Hewlett-Packardは、Dockerで構築された複数のビジネスアプリケーションのオペレーション管理にOperations Orchestrationと呼ばれるソフトウェアを対応させ、さらに、Cloud System Automationと呼ばれるヘテロのクラウド環境の統合管理ソフトウェアなどをDockerに対応させるといった先進的な取り組みを見せています。しかし、依然としてDocker自体が機能追加や仕様変更などを短時間に頻繁に繰り返している現状において、これらのオーケストレーションソフトウェアとDockerの組み合わせをビジネス系の本番システムへ採用するかどうかは、慎重に検討を行う必要があります。また、ミッションクリティカルなビジネス系システムでは必須となるHAクラスターソフトウェアとDockerの連携についても、ベンダーが提供する商用のHAクラスターソフトウェアがDockerコンテナを正式にサポートしていない状況を考慮すると、ミッションクリティカル領域でのDockerの採用は控えるべきです。
仮想化基盤をすでに導入されているシステムでは、日常のメンテナンスを無停止で行うためにゲストOSのライブマイグレーションが行われることが少なくありませんが、Dockerでは、現時点でライブマイグレーションをサポートしていません。Docker以前から存在し、コンテナを実現するオープンソースソフトウェアにOpenVZが存在します。もし、現行の業務が稼働している仮想化基盤のゲストOSのライブマイグレーションの要件（ゲストOSを別の物理サーバーに無停止で移動させる）がある場合は、無停止型サーバー（通称FTサーバーなどと呼ばれます）やハイパーバイザー型の仮想化ソフトウェアを使い続けるか、OpenVZや商用製品のVirtuozzoなどの採用を検討すべきです。現在、DockerやLinuxコンテナにおけるライブマイグレーション（コンテナのチェックポイントとリストア機能の実現）は、CRIUプロジェクトと呼ばれるコミュニティで開発が進められていますが、現時点では、商用利用のレベルではありません。
また、Dockerの大きな課題の1つとして、ホストOSがLinuxの場合には、その上で稼働するコンテナもLinuxに限定されることがあげられます。これは、ホストOSがLinuxの場合に、LinuxコンテナとWindowsコンテナを混在させることができないことを意味します。Windowsアプリケーションを業務で利用しており、それをコンテナで稼働させたい場合は、次期Windows Serverで搭載が予定されている「Windows Server Container」を検討する必要がありますが、現時点で、単一の物理サーバー上において、ハイパーバイザー型の仮想化ソフトウェアを使わずにWindowsのコンテナとLinuxのコンテナを混在させて同時に稼働させることはできません。
Dockerは、従来の個別システムに比べると、非常に革新的であり、ITシステムの在り方を根本から変えるものであることから、世界的に注目が集まっていますが、性能の出ないシステムや不具合のある既存のシステムを蘇らせる魔法の杖ではありません。現在のIT基盤が盤石である状態であってこそ、Dockerのようなコンテナ技術とDockerコミュニティの成果物の活用の威力が発揮されます。ハイパーバイザー型の仮想化ソフトウェアには当たり前のようにできることが、Dockerではできないことも少なくありません。Dockerに向くシステムもあれば、Dockerでは実現不可能なシステムも存在しますし、先述のように、Dockerに向かないシステムも存在します。Dockerのようなコンテナ型のシステムを本当に導入すべきなのか、今一度、システムの現状を把握し、慎重な検討を怠らないようにしてください。Dockerに関する課題やよくある誤解については、以下のURLにあるブログ記事「Docker Misconceptions」が参考になります。英語ですが、一読をお勧めします。
Docker Misconceptions
https://devopsu.com/blog/docker-misconceptions/
