[ITリーダーが知るべきコンテナ技術]

2017年3月24日(金)三木 雄平（レッドハット）

　現在、EC（電子商取引）やWebサービスといったビジネスの現場では、「より多くの試行錯誤が、より良い結果を導く」という考え方が浸透しています。そのためにリーンスタートアップやA/Bテストといった考え方が一般的な手法の1つとしてとらえられ、広く実践されています。常にシステムを改良し、リリースし続ける「CI/CD（継続的インテグレーション／継続的デリバリ）」や、開発と運用を一貫させ開発から運用に至る時間を極限まで短くする「DevOps」なども同様です。

　「いったい何のことだ」「自分には関係ない」と思われる読者もいるかも知れません。しかし、こうした考え方や手法を使ったシステムやサービスは、私たちの身の周りに既にあふれています。Amazon.comやGoogle、あるいはYahoo！といったサービスは、停止することなく、いつの間にか見た目（UI：ユーザーインタフェース）が変わり、機能も日々進化しています。その裏側ではA／Bテストをはじめ、より多くの試行錯誤が繰り返され、サービスを実現するアプリケーションプログラムが改良されているのです。これは、ビジネスや顧客ニーズ、技術、デバイスなどで起こっている様々な変化に、いち早く対応するための努力でもあります。

　試行錯誤の重要性は、企業のITシステムも例外ではあり得ません。ITリーダーは当然、ビジネスの変化に迅速に追随し、リードする存在になるべきでしょう。特に消費者向けのサービスやIoTシステム、つまり「SoE（Systems of Engagement）」と呼ばれる新たなシステム群においては、変化への対応性を備えることは不可欠になります。そのための重要な技術の１が「コンテナ（Container）」なのです。

新たなアプリケーション群「SoE」がDevOpsを求める

　コンテナを解説する前に、前提知識としてSoEとDevOpsについて簡単に解説しておきます。業務システムやグループウェアなど、企業が業務を効率化したり合理化したりするためのシステム群を一般に「SoR（Systems of Record）」と呼びます。これまで構築されてきた情報システムの大半はSoRに分類され、その利用者は主に社員です。社内システムのため構築前に要求仕様を定義できます。

　これに対しSoEは、顧客やモノに直接的かつ積極的に関与する、新しいタイプのシステム群を意味します。少し前までは顧客やモノに関与するといっても、人を介するなど間接的にしか行えませんでした。それが今日では、スマートフォンやIoTなどが広く普及し、顧客やモノに直接関与できるようになったことで、SoEの構築が容易になってきたのです。つまりSoEが対象にするのは顧客や消費者、モノであり、従って要求仕様や求められる機能は常に変化します（表1）。

　その具体例が、消費者や顧客向けのWebサービスやスマートフォン用のアプリです。これらは使い勝手や機能を常に向上させなければならないことは容易に推察できるでしょう。こうしたソフトウェアでは、例えばユーザーエクスペリエンス（顧客体験）の向上という非常に仕様化しにくい要求を実現し、提供し、改良し続ける必要があるのです。でなければ顧客や消費者は、より優れた他のサービスに乗り換えるでしょう。それだけではなく、開発やテスト、運用（デプロイやリリース）といった工程に時間をかけてしまうと、その間に利用者が去ってしまいます。Webサービスでは「スピードが決定的に重要」と言われるゆえんです。

　まとめると、「開発から運用（＝サービス提供）、利用者のフィードバックをもとに改良してリリース」というサイクルを、迅速かつ頻繁に繰り返せなければなりません。言い換えれば、リードタイムの短縮こそが、早期に新しいアイデアやユーザーのフィードバックの受け入れを可能とします。そのためには開発と運用を同一チームで構成するのが最良とされており、このような「開発（Dev）と運用（Ops）の担当者が横断的に協調して、システムやサービスを高速かつ継続的に改良するための習慣および方法」が、DevOpsです（図1）。

　DevOpsの必要条件はいくつか考えられます。開発チームと運用チームを融合させる組織編成の根本的な見直しが、その1つ。そして技術的なアプローチも重要です。図2に示すように、クラウドを含む様々な技術がDevOps実現を後押ししています。中でも新しいアプリケーションの実行環境であるコンテナは、非常に重要な技術に位置付けられます。

コンテナがデプロイメントの問題を解決

　アプリケーションの開発・運用に関わる作業の中で、時間を要するものはいくつかあります。当然、開発はその1つですが、これは外部のAPIを呼び出したり、ミドルウェアを利用したり、既存モジュールを利用したり、といったやり方でずいぶん短縮されてきています。リリース後のアプリケーションを修正・強化する場合は一般に記述量が多くないので、優秀なプログラマーなら時間はそれほどかかりません。

　一方、開発したプログラムをテストする工程は慎重を期せば期すほど時間がかかるのは事実です。しかし詳しくは説明しませんが、テストを自動化したり簡略化したりする技術もあります。テストがボトルネックになるケースは減っています。

　そんな中で、作業の定型化が進まず、従って自動化も進まない工程が、アプリケーションのデプロイメント（配置、展開）です。デプロイメントとは、開発したアプリケーションを用意されたIT環境にインストールする、もしくは既にインストールしてあるアプリケーションを変更する作業を指します。どんな作業なのか、もう少し具体的に見てみましょう。

　よく知られているように、アプリケーションを開発する場合、「開発 → テスト → 実行」という工程を踏みます。それぞれ何らかのIT環境上で行うわけですが、開発のためのIT環境とテストのためのIT環境、実行のためのIT環境は、OSやミドルウェアのバージョン、IPアドレスなどが異なっているのが普通です。もちろんCPU性能も異なる場合が多いでしょう。