CIOが掲げるIT課題とコンテナー採用で検討される技術要素（前編）

今回は「CIOが掲げるIT課題とコンテナー採用で検討される技術要素（前編）」についてご紹介します。

関連ワード （クラウド、古賀政純「Dockerがもたらすビジネス変革」等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、ZDNet Japan様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

　こんにちは。日本ヒューレット・パッカードのオープンソース・Linuxテクノロジーエバンジェリストの古賀政純です。前回は、レガシーITから脱却したい最高情報責任者（CIO）とベンダーの技術コンサルタントが交わすクラウドネイティブ化の検討会議について、ざっくりとした内容を取り上げました。

　今回は、今までの連載で取り上げた内容も含みますが、改めて、欧米のCIOがITベンダーと協議する際に掲げるITの課題と技術要素、コンテナー技術のメリットを前編と後編の2回に分けて紹介します。

　現在、欧米では、エンタープライズ領域の本番環境においてコンテナー技術の導入が加速しています。軽量なアプリケーション環境をパッケージ化し、いつでもどこでも簡単に動かせるという魅力から、従来のハイパーバイザー型の仮想化技術で提供される仮想マシン環境（Virtual Machine：VM）を併用しつつも、ユーザーにOS環境やアプリケーション開発環境を素早く提供するコンテナー基盤を部分的にスモールスタートで採用する企業が増えています。

　また、社内の複数部門が相乗りして利用するマルチテナント対応の商用コンテナー基盤ソフトの導入にも非常に前向きで、企業における導入事例も増えています。具体的には、複数のコンテナーをまとめて管理するコンテナーオーケストレーションエンジン「Kubernetes」を搭載した、いわゆる“オープンソースソフトウェアで構成された商用コンテナー基盤ソフト”が導入されています。

　一方、日本国内におけるエンタープライズレベルでの商用コンテナー基盤ソフトの本格導入は、少しずつ増えているとはいえ、従来のハイパーバイザー型の仮想化基盤に比べて非常に少ないのが現状です。ITベンダーが主催するアンケートなどの調査結果によると、コンテナーという単語を知っているものの、本番採用を検討していない、あるいは、そもそもコンテナーが何かよく分かっていないという企業や組織体がかなりの数を占めています。

　欧米と日本で、そもそも何か根本的に事業課題やITの課題が異なるのでないかと思われるかもしれませんが、実際、コンテナー基盤導入に関して抱える悩み、不安、誤解は、欧米と日本でそれほど差異があるわけではありません。欧米のCIOが感じるコンテナー技術採用における悩み、不安、誤解として代表的なものは、以下が挙げられます。

　まず、複数部門が相乗りするコンテナー環境は、VM環境に比べて、構築や運用も難しそうに感じるというものです。従来の仮想化環境では、普通のOSがVM上で動くため、従来の物理マシンでOSを動かすのと変わりなく運用ができます。一方で、コンテナーは、物理マシン上で動く1つのOS上に分離された空間が複数あり、それらがコンテナーとして動作するため、複数部門が相乗りする環境をセキュリティも含めて本当に問題なく運用できるのか不安に感じるという人も少なくありません。

　また、現在稼働中のVM環境がうまく機能しているという理由で、コンテナー採用の必要性を感じない、あるいは差し迫った状況にはないのでコンテナーを採用しないという意思決定を下すCIOもいます。中には、業務がVMで動いているので、VM上にコンテナーは導入できないと誤解されているCIOもいますが、自社のIT戦略上、VMからの脱却の必要性を感じないというのが大半を占めるといっても過言ではないでしょう。

　ITの仕組みが急激に変化してしまうと、今までのシステムで使い慣れた各部門の利用者が反発し、部門ごとにシャドーITがまん延し、サイロ化するかもしれないといった不安を口にするCIOもいます。また、コンテナーだと開発環境をすぐに作成できるからという理由で、IT部門管理外の簿外品のマシンなどでアプリケーション開発部門が作ったコンテナー環境を日常的に動かしてしまうといったシャドーITの乱立も不安だという声もあります。

　ビッグデータや人工知能（AI）の活用でコンテナー技術の利用が急拡大していることを海外メディアなどで見聞きしているものの、そういった専門知識を持つ人材や育成体制が全く整っていないというケースを多く見かけます。データ分析のできる人材をなんとか確保しても、データ基盤が十分に整備されていないため、データの収集、整理、加工が非常に煩雑になり、コンテナー技術の導入まで話が進まないといった状況は、国内外問わず、少なくありません。また、コンテナー基盤でそうしたデータを操作したり、AIを稼働させるためのアプリケーションを開発したりするスキルの問題もあります。

　稼働中のレガシーアプリケーションが膨大かつ複雑であり、それらをコンテナー環境へ移行する手間が煩雑であるのは容易に予想できるため、なかなかコンテナーに手出しできないといった声も多く存在します。

　エンドユーザーに対して提供するサービス品質の維持に対する不安は、海外だけでなく、日本でもよく耳にする話です。例えば、セルフサービス型の自動化されたIT基盤が挙げられます。社内にセルフサービスポータル画面を提供しても、IT部門の人員の都合上、限られた種類のアプリケーションや非常に大雑把なサービスメニューを提供せざるを得ず、ユーザーにとって使いやすいサービスにならないという問題です。

　結果的に、全社ITの自動化やセルフサービス化を行っても、現場の細かい要求に応えられず、利用者の不満だけが残り、使用率の低いITシステムになってしまうのではないかといった不安がつきまとうのです。また、以前の記事でも紹介したコンテナー技術を使ったコードによるIT基盤の自動化（Infrastructure as Code：IaC）によって手間が省ける一方で、自動化に必要なコード自体が肥大化し、保守に余計な工数が発生するのではないかといった不安の声も多くあります。

　また、コンテナー化によって軽量のOS環境やアプリケーション環境を素早く配備できるという特徴は知っているものの、現在稼働中のVM環境でも、IT部門が用意した独自のスクリプトなどによって素早く配備できているため、コンテナー化は不要ではないかといった意見もあります。加えて、それらの自動化技術に支えられたセルフサービス化では、新しいメニューが増える度に自動化に必要なコードの開発や保守が面倒になるのではないかといった声もあります。

　オープンソースソフトウェアそのものの品質が心配という声は、日本だけではありません。物理マシンで稼働するLinuxや仮想化ソフトウェアの保守契約が必須というITシステムでは、コンテナー基盤ソフトにも同等のベンダー保守サポート契約が必要になる場合がほとんどです。

　ハードウェアベンダーは、LinuxのOEM版をソフトウェア製品として提供しているため、ハードウェアベンダーで物理マシンとOSの両方の保守が可能であるため、ハードウェア、OS、ドライバーまで含めて障害切り分けを行います。OSに非常に近いレイヤーのコンテナー基盤ソフトでも、ハードウェアベンダーが問題の切り分けを行い、保守対応してくれるか心配という声は、意外と少なくないのです。

　特に、コンテナー基盤ソフトに含まれるコンテナーオーケストレーションを行うKubernetesエンジンと、それを取り巻くオープンソースのソフトウェアコンポーネントの障害切り分けの範囲を事前に明確にしておきたいのです。オープンソースソフトウェアの世界は、ご存じの通り、どのベンダーの製品でも、品質維持やバグ修正に追われるという話は尽きることがありません。そういう点で、不安を感じる、あるいは責任範囲を明確にしたいという思いがあるのは当然のことです。

　コンテナー技術の採用において、何が導入の障壁になっているのかを正しく理解するには、CIOのこれらのさまざまな声をひも解いていく必要があります。上記で紹介したように、コンテナー技術の導入に対する漠然とした悩みや不安、誤解は挙げれば切りがありませんし、それらを完全に払しょくすることはできません。

　しかし、何かしらITを使った事業改革を前進させるためには、現時点でのビジネス、IT、人的資源などの状況を踏まえて、優れたコンテナー技術を自社に適用できるかどうかの見極めが必要です。そのためにはまず、CIOが導入の際に注目するコンテナー技術の基本的な特徴を理解しておく必要があります。