システム運用の常識が大きく変わる。クラウドを前提にした全く新しい運用スタイル、「イミュータブルインフラストラクチャー」がそれだ。従来のように同じ本番環境を使い続けない。設定変更時には、丸ごと新規に環境を構築し、バトンタッチする。OSやミドルウエアを含むITインフラを使い捨てるわけだ。
安定的な更新を可能にし、変化の速い新規事業などで威力を発揮。「Docker」の登場で実現が容易になった、新時代の知恵を紹介する。
「秘伝のたれ」――。長年使われ続けているITインフラを例えてこう呼ぶことがある。料理に使う秘伝のたれとは異なり、ITインフラの形容詞としては悪い意味で使われる。
うなぎや焼き鳥店などで数十年前の世代から“継ぎ足し”で受け継がれた「つけだれ」は、同じものを作ろうとしてもなかなか作れるものではない。同様にITインフラも「長い期間をかけて少しずつ変化した結果、誰もその中身を把握できず、同じ構成を再現できない状況になることがある。変更の内容は手順書や設計書に反映されておらず、開発環境では問題なかったのに、なぜか本番環境では動かない、といった事態が起こる」（NTTデータ 技術開発本部ALMソリューションセンタの佐藤聖規シニア・エキスパート）。
ここで言うITインフラとは、サーバー、OS、ミドルウエア、アプリケーションのフレームワークなどを指す。通常、本番システムのITインフラは変更を余儀なくされる。サーバーであれば名称やアクセス権限などを変えたり、OSやミドルウエア、フレームワークであればバージョンアップしたりパッチを適用したりする。プログラミング言語のライブラリのバージョンを変更することもある。
「使い続ける」ことをやめる
ITインフラの“秘伝のたれ化”を防ぐための、新しいシステム運用の考え方が登場した。「イミュータブルインフラストラクチャー」がそれだ。イミュータブルとは「不変」という意味で、ITインフラに変更を加えないことを意味する。もし、アプリケーションやミドルウエアに変更を加えたいときは、その変更が反映されたシステムをITインフラごと新規に構築。ロードバランサーなどで切り替えた後に旧システムを廃棄する。いわば、変更のたびにシステムを「使い捨て」にするのだ。ITインフラの変更状況をトレースする必要がなくなり、常にITインフラの状態を把握できる（図1）。
上記のように、システムを簡単に廃棄する考え方を「ディスポーザブルコンポーネント」と呼ぶ。ディスポーザブルは廃棄可能という意味で、イミュータブルインフラストラクチャーとセットで語られることが多い。あるいは両方の概念を包含して、イミュータブルインフラストラクチャーと呼ぶこともある。本記事では、単にイミュータブルインフラストラクチャーと記述した場合は両方の意味を包含するものとする。
クラウドと環境構築ツールで実現
イミュータブルインフラストラクチャーの実現の仕方について、もう少し詳しく見てみよう。大前提となるのはクラウドである。クラウドによって、簡単に仮想サーバーを立ち上げたり廃棄したりできるようになった。「サーバーだけでなく、ミドルやアプリまで含めて、一からきれいなものを作ればよい、という発想の転換がイミュータブルインフラストラクチャーである」（富士通 SI技術本部ニューテクノロジービジネス統括部の原桂介シニアーマネージャー）。
次に必要となるのが、「ツールによる自動化」だ。例えば、オープンソースの「Chef」や「Puppet」といった「環境構築ツール」を使えば、サーバー、OS、ミドルウエアなどの設定やバージョンを管理し、その通りに自動で環境を構築できる。具体的には、それらをセットアップするための手順を設定ファイルにソースコードとして記述する。
こうした環境構築ツールに加え、アプリを本番環境に自動で配備する「デプロイツール」や、ITインフラの設定状況をテストする「インフラテストツール」も普及し始めた。
これらのツールを組み合わせて使うことにより、設定変更前のシステムを廃棄しても同じシステムを再現可能になった。つまり、クラウド上でツールによる自動化を進めることで、イミュータブルインフラストラクチャーが実現できるわけだ（図2）。
さらに近年では、コンテナ型仮想化技術の「Docker（ドッカー）」が登場し、イミュータブルインフラストラクチャーをより実現しやすくなった（解説記事参照）。Dockerは、ビルド後のアプリとインフラの状態を独自形式のファイルに記述し、独自の実行環境上に再現できる。「設定手順を記述していたChefやPuppetに比べ、同じ環境を立ち上げるスピードが圧倒的にDockerの方が速い。このため、よりイミュータブルインフラストラクチャーに向く」（Dockerに詳しい、トップゲート ソリューション事業本部システムソリューション事業部の森和之システムエンジニア）。
一般的な業務システムでもメリットあり
イミュータブルインフラストラクチャーが提唱される前から、似たような考え方はあった。本番系と待機系の2系統の同じ構成のシステムを用意しておく「ブルー・グリーン・デプロイメント」だ。ITインフラを変更する場合、待機系に変更を適用した後、本番系と待機系をロードバランサーなどによって切り替え、待機系を新たな本番系として使う。変更時にトラブルが発生したときに変更前の構成にすぐ戻せるというメリットがある。
このメリットはイミュータブルインフラストラクチャーでも当てはまるが、ブルー・グリーン・デプロイメントでは、「変更を加えない」「ITインフラを使い捨てる」といった特徴は含まない。このため、“秘伝のたれ化”が進む可能性が残る。また、全く同じシステムを用意しなければならないため2倍の調達・運用費がかかることが問題だった。イミュータブルインフラストラクチャーは一時的に2系統になるものの、その後に旧システムを廃棄するためコストを抑えられる。
イミュータブルインフラストラクチャーが効果を発揮する領域は「インターネットを使った新事業など、アプリやインフラの更新が頻繁に求められるシステム」（野村総合研究所 コンサルティング事業本部ICT・メディア産業コンサルティング部の木下貴史グループマネージャー）。
このほか、一般的な社内向けの業務システムでも「変更リスク低減や、テスト工数の削減などのために適用する価値はあるとみている」（富士通の原シニアーマネージャー）。
以降で、イミュータブルインフラストラクチャーはどのような場面で使われているのか、実際の事例を紹介しよう。
気軽に捨てて三つの恩恵
プロジェクト管理のSaaS（ソフトウエア・アズ・ア・サービス）などを手掛けるヌーラボの染田貴志テクノロジー・エバンジェリストは「“秘伝のたれ化”を防ぐ取り組みを進めた結果、イミュータブルインフラストラクチャーの考えに近づいた」と説明する。
システムをAmazon Web Services（AWS）上で稼働させるヌーラボでは、Webアプリケーションサーバーを変更する際に以下のような手順を取る。まず、変更を適用したサーバーを1台構築する。この作業は、サーバーの設定に「Ancible」、アプリケーションのデプロイに「Fabric」といったツールを使って自動化している。
次に、変更を適用したサーバーを本番環境に追加する。10台のWebアプリケーションサーバーが動作しているサービスであれば、一時的に11台にし、変更前と変更後のサーバーが混在している状態になる。変更後のサーバーの様子を見て問題がなさそうであれば、変更前のサーバーを1台削除する。これを繰り返し、最終的に全サーバーを変更後のサーバーに入れ替える。
この運用方法は、複数台のWebアプリケーションサーバーを1台ずつロードバランサーから切り離し、更新後に再接続する「ローリングアップデート」という手法に似ている。異なる点は、同じサーバーに変更を加えないことだ。「変更を重ねたサーバーを使い続けない分、より安心して更新できる」（染田テクノロジー・エバンジェリスト）。
インフラ更新時の安全を確保
イミュータブルインフラストラクチャーには、“秘伝のたれ化”を防ぐこと以外のメリットもある。インフラ更新時の安全性を高めるために採用したのが電通国際情報サービス（ISID）だ。同社はインターネットサービスを実店舗の購買促進などにつなげるO2Oプラットフォームサービスの「＋fooop!」でイミュータブルインフラストラクチャーを採用している。
システムをAWS上に構築するこのサービスでは3～6カ月おきに、OSのLinuxやWebアプリケーションサーバーのTomcatなどを最新のものに更新する。その際、更新を適用した新たなサーバー群を構築。ロードバランサーの接続先を切り替えることで刷新する。変更前のシステムは1週間ほど並行稼働させた後、廃棄する（図3）。トラブルが発生しやすい変更直後は、変更前のサーバー群を並行稼働しているのでいつでも元に戻せる。
ただし、イミュータブルインフラストラクチャーの考え方を適用するのは、比較的大きな変更のみ。パッチ適用など比較的小さい変更に関しては、Chefを使い現行システムに直接変更を加える。直接変更する際はChefを使い、変更状況が分からなくなることを防いでいる。
開発環境の待ち時間をゼロに
イミュータブルインフラストラクチャーの考え方は、開発環境でも効果を発揮する。この点に着目して活用しているのがERPパッケージ開発のワークスアプリケーションズや教育分野のプラットフォームサービスを提供するクイッパーだ。
ワークスやクイッパーは開発者がソースコードに変更を加えると、そのアプリケーションが動作する環境を新規に構築し、変更後のソースコードをデプロイする。動作環境は、ワークスはDockerで、クイッパーは米ヘロクのPaaS（プラットフォーム・アズ・ア・サービス）「Heroku」を使う。「たとえ1行のソースコードを変更しただけでも、新たにコンテナを構築し、確認後に廃棄する」（クイッパーの藤村大介Webデペロッパー）（図4）。
このように開発環境を使い捨てることで、開発者の待ち時間を短縮することができた。以前は、一つの動作環境を複数の開発者で共用していたため、事業責任者が変更内容を確認するまで別の開発者は待たなければならなかった。
データベースは対象外
イミュータブルインフラストラクチャーの適用は広がっているものの課題も残る。
第1に、データベースサーバーは基本的には対象外である。「検証しているが、まだ実用段階ではない。データベースを使い捨てにしようとすると、現状ではメリットよりも技術的難易度のほうが上回る」（NTTデータの佐藤シニア・エキスパート）。
第2に、全ての既存アプリケーションが対応できるわけではない。「セッション情報を保持しているようなアプリケーションでは対応できない」（イミュータブルインフラストラクチャーを採用するウォンテッドリーの川崎禎紀CTO）。
第3に、イミュータブルインフラストラクチャーに向く運用管理ツールが未成熟である。ただし、この点に着目した製品も登場し始めている。はてなの運用管理ツール「Mackerel（マカレル）」だ。サーバーを入れ替えても、役割が同じであれば継続して情報を取得できる。はてなの田中慎司執行役員最高技術責任者は「イミュータブルインフラストラクチャーを想定して作った」と話す。
イミュータブルインフラストラクチャーを実現しやすくする技術として、注目を集めているDockerについて解説する。DockerはGo言語で記述された、オープンソースの「コンテナ」実行環境だ。ここでいうコンテナとは、アプリケーションのソースコードと、そのアプリケーションに必要なバイナリーコードやライブラリ、アプリケーションと一緒に動作するミドルウエアなどを、一つのファイルに“固めた”もの。例えば、オープンソースのCMSであるWordPressであれば「WordPressのソースコード＋PHPの実行環境＋データベースのMySQL＋WebサーバーのApache」などを、一つのコンテナに含むことが多い。
上記のような構成でWordPressを運用していると、「Apacheだけをアップデートしたい」という状況が起こることがある。Dockerを使わずに、Apacheだけをバージョンアップした場合、しばしば「ローカルの開発環境ではApacheのバージョンを上げても動作したのに、実際に本番環境にデプロイしてみたら動かない」といった問題が発生する。PHPのバージョンが本番環境と開発環境で微妙に違っていた、などの理由からだ。
Dockerのコンテナでは、ローカルの開発環境で動作確認したコンテナと、全く同じ構成のコンテナをそのまま本番環境に持っていくことができるので、このような問題を避けられる。
仮想化ソフトより軽い
同じ環境を再現できるという点だけを見ると、「VMware」や「KVM」などの仮想化ソフトと同じではないかと思う読者もいるかもしれない。実行環境を丸ごと“固める”のは、Dockerも仮想化ソフトも共通している。しかし、Dockerは仮想化ソフトと比べて、実行速度と容量の点において圧倒的に優れている。それは、どの単位で“固めて”いるかの違いである（図A）。
仮想化ソフトにおける単位は、ハイパーパイザー上で動作するゲストOSを含めたアプリケーション全体だ。バイナリーコードやライブラリも全て含んでいる。これにより、仮想マシンを立ち上げる際の速度、実行速度、ディスク/メモリーの消費量が問題になりがちだ。
これに対しDockerのコンテナ内に含むのは、ホストOS上に動作する実行環境の「Docker Engine」上のアプリケーションだ。ゲストOSはない。しかも、バイナリーコードやライブラリをアプリケーション間で共有する。このため、オーバーヘッドが少なくなり、立ち上げ時の速度も実行速度も仮想化ソフトより速くなる。必要となるディスクやメモリー容量も格段に少なくて済む。
開発、本番、レジストリーで動作
Dockerを実際に使う際の手順は以下のようになる。用意するのは、ローカルの開発環境、本番環境、「Dockerレジストリー」用のサーバーの3点である（図B）。Dockerレジストリーとは、コンテナを保存し本番環境に配布するサーバーである。それぞれにDockerをインストールする。
開発者は開発環境で「Dockerfile」を作成する。Dockerfileは、動作させるアプリケーションやミドルウエアの設定に関する一連の作業手順を記述したものだ。Dockerfileを用意したら、開発環境で「docker build」コマンドを実行すると、そのアプリケーションのコンテナを作成（ビルド）できる。
docker buildコマンドを実行してコンテナをDockerが作成するとき、DockerはLinuxカーネルの「AUFS」というユニオンファイルシステムを使う。AUFSは、内部ストレージにインストールすることなくLinuxを起動できるLive CDなどに使われている仕組みである。
AUFSは、OSイメージをリードオンリーで読み込み、メモリー上に書き込み可能な領域を作る。その二つを重ね合わせて使うことで、ホストOSのファイルシステムにアクセスすることなく、アプリケーションを動かすことができるようになる。
次に、開発環境で「docker push」コマンドを実行し、Dockerレジストリーにコンテナを配布する。最後に、本番環境のサーバーで「docker pull」コマンドを実行し、Dockerレジストリーからコンテナを取得し、「dockerrun」コマンドで実行する。これにより、開発環境で構築したコンテナが、そのまま本番環境の各サーバーで動くことになる
先にビルドするのがChefとの違い
「Chef」や「Puppet」などの環境構築ツールを使ったことがある読者は、それらの環境構築ツールとDockerは何が違うのかと思うかもしれない。確かに、ファイルに環境を構築する作業手順のコードを記述して、その状態の実行環境を構築するという点では、共通している。
両者の最大の違いは、環境を構築するのにかかる時間だ。単に作業手順をコード化しただけの環境構築ツールでは、全ての作業が実行されるまで相応の時間が掛かる。これに対してDockerは、ビルド後のコンテナを配布するので、docker runコマンドを実行すれば即座にコンテナを立ち上げられる。気軽に本番環境を立てたり廃棄したりするイミュータブルインフラストラクチャーでは、この高速性が大きな差になる。
＊ ＊ ＊
2013年3月に公開されたDockerは、その後1年で急速に普及している。Dockerを公開した米ドッカーは2014年1月に1500万ドルの資金を調達。米アマゾン・ウェブ・サービス、米グーグルなどの大手クラウドベンダーもサポートを開始した。
Dockerの動作環境はLinuxに限られるもののオンプレミスでもクラウドでもアプリケーションのポータビリティーが確保できるため、ベンダーのロックインから逃れられる。
トップゲート ソリューション事業本部システム事業部 システムエンジニア
