デジタルトランスフォーメーションで迫られる「開発・運用スタイルの変革」：コンテナ技術、導入の課題と解決策とは？（1/2 ページ）

近年、DevOps実践のカギになるテクノロジとしてコンテナ技術が注目されている。2016年10月5日に開催された「Red Hat forum 2016」でのパネルディスカッション「来たるコンテナ時代に向けて」の模様から、コンテナ技術の今と課題、真のメリットを探る。

[伊藤真美]

　デジタルトランスフォーメーションが進む中、ビジネスの優位性を獲得する上では、ITサービス開発・改善の「スピード」が前提条件になるとされている。そうした開発・改善サイクルのスピードアップに大きく寄与するとして、近年注目されているのがコンテナ技術だ。2016年10月5日、東京都内で開催された「Red Hat forum 2016」で、そのコンテナ技術をテーマにしたパネルディスカッションが行われた。本稿ではその模様から、コンテナ技術のメリットや活用する上での課題など、ポイントをピックアップして紹介したい。

それぞれ異なる立場でコンテナ技術に関わっている5人のプロフェッショナルが登壇

Dockerの登場で急速に普及し始めたコンテナ技術

　「来たるコンテナ時代に向けて」と題されたパネルディスカッションでは、Publickeyの新野淳一氏がモデレーターを務め、グーグルのイアン・ルイス（Ian Lewis）氏、ディー・エヌ・エーの小俣裕一氏、さくらインターネットの前佛雅人氏、レッドハットの木村貴由氏が登壇。ルイス氏はオープンソースソフトウェア（以下、OSS）の開発やデベロッパー支援に関わる立場、小俣氏はソフト開発を行うユーザー、前佛氏はDockerの元トレーナーかつコンテナ製品のエバンジェリスト、木村氏はコンテナプラットフォームの提供者というそれぞれ異なる視点から、コンテナ技術に対する活発な議論が展開された。

モデレータを務めたPublickeyの新野淳一氏

　まず議論の前提として確認されたのが、「コンテナ技術とは何か」というテーマだ。これについて木村氏は、「ハイパーバイザー型のサーバ仮想化とコンテナ仮想化の共通点は、『隔離されたアプリケーション実行環境を提供するもの』であること。ただサーバ仮想化の場合、ハイパーバイザー上の各仮想マシンに1つのゲストOSが必要であるのに対し、コンテナ仮想化は1つのホストOS上で複数のコンテナを稼働させられる。このため処理のオーバーヘッドが少なくリソース効率が良い、起動・停止が早い、デプロイサイズが小さく軽量といったメリットがある」ことを解説した。

　また昨今、注目を集めている理由として、「“軽さ”が一定の閾値を超えたことが挙げられる」という。一般に、仮想マシンの構築には分単位の時間がかかるが、「コンテナの場合は瞬時に環境を構築でき、ストレスを感じないレベルになった」（木村氏）。特にOSSのコンテナ型仮想化ソフトウェア「Docker」は、周知の通りOSやアプリケーションの設定をそのままDockerイメージとして保存し、レジストリで共有できる。そのイメージをホストOSに展開するだけでアプリケーションの実行環境を構築できる利便性から、多くの企業に注目されている。

　「以前はアプリケーションの実行環境構築といえば、手順書を読みながらアプリケーションや必要なミドルウェアなどをインストール、セットアップする必要がありましたが、Dockerによって、“セットアップ済みのポータブルなコンテナイメージ”を展開するだけでアプリケーションを実行できるようになったのです。こうした利便性と軽さがコンテナが普及した要因といえるでしょう」（木村氏）

環境の差異を考慮せず、スピーディな構築が可能

　では実際の開発現場では、コンテナ技術をどう受け止めているのだろうか。新野氏に水を向けられた小俣氏は、ユーザーかつ開発者である立場から、まず「テストにおいて、ユーザーの実行環境の差異を考慮する必要がないこと」をメリットとして挙げた。

ディー・エヌ・エー　SWET Gr, Quality Management Dept, System Management Unit Software Engineer in Test 小俣裕一氏

　「開発環境下では、OSやデータベースのバリエ―ションが多く、ツールもさまざまなものが混在しています。テスト対象も非常に多岐にわたるため、それぞれに対応したテスト環境の準備には数日かかることも少なくありません。さらに手間だけではなく、各環境を準備するための知識を学ぶ必要もありました。しかしDockerによってそうした負荷から解放され、テスト環境を簡便に構築できるようになりました。時間とコストの削減は大きなメリットです」（小俣氏）

　さらに小俣氏は、スマートフォンの実機を用いたテストファームにもコンテナを活用していることを紹介。「フロントエンドサービス、バックエンドともにOSが異なり、1サービス当たり10〜20種類ものデバイスに対応する必要がある」となれば、テストに掛かる工数は想像に難くない。もっとも、Dockerを使う以前から環境構築を自動化しているため、手間自体は変わらないそうだが、Dockerによって「環境構築や自動化の技術を学ぶコスト」が省かれたことで、「実感として5分の1〜10分の1のコスト削減につながった」と見ているという。

　ただし、小俣氏は「開発環境とテスト環境で使っているため、規模的にはコンテナの“軽さ”というメリットを感じるまでには至っていない」という。これを受けて木村氏は、「軽量化のメリットを実感できるのは一定規模を超えてから。また、その際にはサーバ仮想化の倍とまではいかずとも、それを上回る高い集約率というメリットが得られる」と解説した。

運用管理の負担が障壁に

　ここで新野氏は「話がうま過ぎる（笑）」と方向変換。「コンテナで困っているユーザーは本当にいないのか」と質問すると、木村氏は「そうしたケースもある」と回答。具体的には「Linuxに特殊なカーネルが入っていることで、アプリケーションをコンテナ化できないケース」「商用アプリケーションのサポートを受ける条件として、コンテナが含まれてないことを挙げているケース」などが挙げられるという。

　これを受けて小俣氏は、DeNAゲームサービスの本番環境にDockerの導入を検討しながら、一度諦めた経験があることを告白した。理由の1つはセキュリティに対する不安。また、データセンターに既存サーバを大量に保有している他、AWSも採用していることから、「コンテナを“第三の環境”とした場合の学習・導入コスト、運用管理負荷に対する懸念があった」という。監視やデプロイ、セキュリティスキャンやデータベースのケアなど、何から何まで“自前”で用意するのは負担が大きいというわけだ。そこで現在は、Dockerに対応しており、サポートもある「Google App Engine（GAE）」を採用しているという。

　では、本当にコンテナの運用・管理負荷は大きいのか。新野氏の問いに、前佛氏は「率直に言えばその通り」と即答。そもそもオープンソースである上にバージョンアップが頻繁に行われ、3カ月に1度は仕様が変わるという。最新情報を入手するにはDockerのブログの他、現在は同社のスライドシェアを見る必要もあり、ユーザーが知見を伝える「Docker キャプテン」という制度も開始された。これらをマメにチェックし、情報に追従できるかどうかが、自前でコンテナを扱うかどうかの1つの基準になるというわけだ。