新たな仮想化技術として近年注目を集めている「コンテナ」。情報システムの開発や運用を内製化する傾向にある米国では、ユーザー企業が中心となって採用を進めている。ユーザーの視点では、サーバー仮想化よりも、コンテナにメリットがあるとの判断だ。一方、システム開発を外注するのが一般的な日本では、SIerがコンテナまわりを担うと考えられる。いずれ来たるコンテナ時代、日本のSIerはどう取り組むべきなのか。（取材・文／谷川耕一）
米ユーザー企業を中心に
コンテナは、1台の物理サーバー上でホストOSを起動し、その上で独立したアプリケーションの動作環境を構築する技術やプラットフォームを指す。物理サーバーやOSに依存しない形でアプリケーションが動作するため、物理サーバー上で複数の仮想サーバーを動かす「サーバー仮想化」よりも運用環境がシンプルになる。開発環境やテスト環境なども用意しやすいため、システム開発の高速化が期待される。コンテナを実現するプラットフォームでは「Docker」、コンテナの管理ツール（オーケストレーションツール）では「Kubernetes」が代表的だ。
コンテナが注目を集めているのは、ユーザー企業が自社データセンターの利用を減らし、外部のクラウドサービスなどを利用するようになったことが背景にある。クラウドの利点を最大限に生かすには、クラウドネイティブなアプリケーションの開発・運用が必要となる。それは物理サーバーやOSに依存しない環境と言い換えることができ、さらにクラウドベンダーにも依存しないコンテナが最適だとみられているのだ。先進的な米ユーザー企業ではコンテナの活用を開始しており、また、その多くはシステム開発を内製化しているといわれている。ユーザー企業の開発現場から、高い支持を受けているということだ。
一方、日本企業の多くは、アプリケーションの開発や運用をSIerなどに委託している。アプリケーション開発の内製化が進むとしても、日本では多くの部分を引き続きSIerが担うと考えられる。そうであるならば、SIerは今後、どのようにコンテナに取り組めばよいのだろうか。
日本におけるコンテナは
米国を中心にコンテナの採用が進んでいるが、日本での事例も増えてきている。レッドハットの須江信洋・テクニカルセールス本部ミドルウェアソリューションアーキテクト部OpenShiftスペシャリストによると、「最近では日本でもコンテナの利用は確実に増える傾向にある」という。同社の国内の顧客においても、PoC（概念実証）を行い、開発環境としてコンテナを利用するケースが出てきているとのことだ。
レッドハット
レッドハットは企業向けコンテナアプリケーションプラットフォーム「Red Hat OpenShift」を提供しており、その利用企業数はグローバルで600社を超え、ほとんどが本番環境で運用。米国では競争の激しい金融や通信業界などにおいて、変化に対応するためのプラットフォームとしてコンテナの採用が進んでいる。
一方、欧州のアプリケーション開発事情は、日本と似ているとされる。アプリケーション開発の外部委託も多いが、内製化に取り組むユーザー企業を中心に、コンテナの採用が徐々に進んでいるという状況だ。「OpenShiftを大規模に利用しているドイツ銀行でも、パートナーと組んで内製化に取り組んでいる」と須江氏は欧州の状況を分析している。
日本ではまだ、エンジニアの個人的な興味や勉強用としての利用が多い。そのため、新しい技術に関心を持つエンジニアを抱える企業が、社内開発環境の一部でコンテナやオーケストレーションツールを利用し始めている程度である。エンタープライズ用途で本番運用環境として使うには、まだ至っていない。
エンジニアの勉強や先進企業の実験的な開発の場合は、オープンソースソフトウェア（OSS）でコンテナ環境を構築している例が多い。一方、「エンタープライズ用途で本番環境として使う際には、サポートが得られるOpenShiftなどを選んでいる。そうした製品をSIerが担ぐようになれば、日本でもコンテナの利用が一気に進む」と須江氏は期待している。
コンテナを活用することが
広く普及した仮想化サーバーに対し、コンテナは新たな担い手となるのか。仮想化サーバー環境とコンテナ環境では、いったい何が違うのか。須江氏は「システム開発におけるアーキテクチャーが変わる。コンテナではアプリケーションとインフラが完全に分離される」と違いを強調する。クラウドネイティブなアプリケーションと同様の考え方である。
オンプレミスでは、物理サーバーやミドルウェアは基本的に止まらないものとしてアプリケーションを構築する。障害などの停止に対しては非機能要件とし、アプリケーションの外で対処している。
それに対し、クラウドでは、ネットワークが切れたり、サーバーがパッチ適用で停止したりすることが、ユーザー企業の予期しないタイミングで発生する可能性がある。しかも、ユーザー側では通常、クラウドインフラ自体をコントロールすることができない。クラウドネイティブなアプリケーションでは、インフラ停止を機能要件として考慮する必要がある。
「クラウドネイティブなアプリケーションは、技術ではなく哲学的なところがある。コンテナやサーバーレス技術を使えばクラウドネイティブになるのではなく、クラウド環境が停止してもサービスを継続できるような設計が必要」（須江氏）。クラウドやオンプレミスの環境に依存しないコンテナは、クラウドネイティブなアプリケーションで必要とされる理由がそこにある。
クラウドネイティブなアプリケーションがトレンドだからといって、Javaなどで構築された「SoR（System of Record）」のレガシーシステムまでコンテナ化するのは無理がある。頻繁に変更されることなく、部品化してもほとんど再利用されないのであれば、コンテナ対応よりも、API化などで軽やかにモダナイズするべきだろう。
SIerは自社の開発環境の
SIerに対して、「企業の内製指向に対応するために、請負型ではなく開発パートナーとしてスクラムチームの一員になるべき」とは、ありがちな論調である。現場をよく知るSIerとしては、言いたいことがあるはず。それはともかく、前述したとおり、米国ではユーザー企業を中心として、コンテナの採用が進んでいる。SIerは、そのことを知り、対処できるようにしておくべきだろう。
「コンテナ環境になれば、今までとは違い、アプリケーションのセキュリティー対策が必要。その実装もSIerの役割となるはずだ」（須江氏）。
これらを進めるためにはSIerが自社にコンテナやオーケストレーションツールの環境を用意し、それを自分たちで利用していち早くノウハウをためるべき。そういったアプローチが、コンテナ環境活用時代にSIerとして新たな価値を提供できるようになる近道となるだろう。
[次のページ]SIer2社に聞いた！「コンテナ時代」どう備える？
