コンテナは、業務をこなすために必要な最低限のリソースのみを配備したアプリケーションロジックのコンポーネントを格納する。仮想マシン(VM)と異なり、コンテナはOSを必要としない。OSリソースはAPI経由で呼び出される。(続きはページの末尾にあります)
レガシーシステムをコンテナでマイクロサービス化することがトレンドの一つになっているが、それが常に最良の方法というわけではない。企業はコンテナとどう向き合うべきなのか?
「マイクロサービスアーキテクチャ」に基づくアプリケーションを開発する際、重視すべきこととは何だろうか。主要な3つの項目を紹介する。
Dockerは優れた技術だが、開発者個人が使うだけなら問題なくても企業レベルになると問題が生じる可能性がある。Dockerのメリットを最大限に引き出し、リスクを回避するため、企業が注意すべきこととは?
コンピューティングはこの数年で進化し、アジャイルな仕組みに重点が置かれるようになった。DevOpsとマイクロサービスが、いかにITアーキテクチャを進化させているかを紹介する。
ソフトウェアのコンテナ化、コンポーネント化、コンパートメント化のアプローチは、企業の顧客対応を向上させる助けになる。だがCIOには、さらに複雑な環境を管理するという課題が生じる。
コンテナ化は、実質的にはOSレベルの仮想化といえる(これに対してVMはハイパーバイザー上で実行され、それぞれフル機能のOSを伴う)。コンテナはパッケージ化が簡単で、軽量かつ実行場所を選ばない。複数のコンテナを1つのVMにデプロイすることもできる。
マイクロサービスは、例えばネットワークトラフィックのルーティングやオンライン決済、医療結果分析といった単一機能のアプリケーションを指す。その概念は新しいものではなくWebサービスから進化したもので、複数のマイクロサービスを連結してアプリケーションとして機能させるのは、数年前に流行したサービス指向アーキテクチャ(SOA)の進化形だ。
コンテナとマイクロサービスは同じではない。マイクロサービスはコンテナの中で運用することもあれば、プロビジョニングされたVMとして運用することもある。コンテナはマイクロサービスのために使われるとは限らない。だが、コンテナはマイクロサービス開発とデプロイの優れた手段であり、コンテナ運用のツールとプラットフォームはマイクロサービスベースのアプリケーションを管理する手段として優れている。多くの場合、これらの用語は相互に入れ替えることもできる。
コンテナは何年も前からUNIXやLinuxに統合されてきた。最近は総合的なサポートのエコシステムが成長してきた。
これに関わるサプライヤーは数多い。だが「Docker」が市場の中心で主導していることに異論はない。Dockerは、何百万というデベロッパーや数万もの組織がその技術を使っていると説明する。ただ、多くの組織にとってコンテナ化が目新しいものであることを示す統計もある。Dockerの顧客のうち、コンテナを本番環境で運用しているのは40%にとどまる。
Docker の優位は、必ずしも独占状態にあることを意味しない。むしろそれとは程遠い。コンテナのエコシステム全体を見渡すと、選択肢は豊富に存在する。
複数のコンテナはクラスタにデプロイされ、幅広いツールを使って管理される。そうしたコンテナの多くは事前に構築されたコンポーネントとなり、積み重ねてアプリケーションイメージを構成する。主なメリットは、アプリケーションを運用した状態で個々のコンテナを簡単に「上書き」できる点にある。定期的なダウンタイムが減れば、事業継続性が向上する。
これは「DevOps」の概念の台頭につながってきた。DevOps では、より速いペースで新しいソフトウェア機能を直接 OS 環境にデプロイできる。
中核的なコンテナ技術の多くはオープンソースであり、VMware のようにかつてはこれを避けていたサプライヤーも引き込まれている。その中心にあるのが 2015 年に発足した「Open Container Initiative」(OCI)だ。OCI は LinuxFoundation の傘下でコンテナ形式とそのランタイム環境に関するオープンな業界標準を策定する。Docker はその土台とするために、自らの形式とランタイムを OCI に提供した。
コンテナ化されたコンポーネントの多くは「GitHub」「Docker Hub」のようなオープンソースコラボレーションプロジェクトからダウンロードできる。全てのオープンソース技術にいえることだが、市場に進出しているサプライヤーは、安定したバージョンを関連サポートサービスと併せて提供することによって収益を確保している。