３つある。
マシンイメージを手軽に生成できて、環境構築ができる世界を作る
１つ目は、担当授業でのフィードバックからの気付きだった。2010年頃、Immutableや、Blue-Green Deploymentと言うキーワードが無かったものの、その都度マシンイメージから新規環境を構築して、環境を丸ごと切り替える手法は、2010年に私が国立情報学研究所(NII)で担当するクラウド関連の授業で教えていた。これがもっともクラウドらしいデプロイメントだと考えていたためだ。しかし、当時の受講生の反応の大半は、これは実用的ではないと言うものだった。どこに課題があるのかを考えてみたが、結局のところ次のような点に集約される。
- マシンイメージをどう作り直すか
- 新規環境をどう本番環境へ昇華させるか
これら２点に良い手法があれば、アプリケーションデプロイは大きく変わるのだろう、と言う感覚が十分にあった。
状態管理を放棄しても差し支えない
２つ目は、VMの状態管理が大変だと言うことだ。同じくして2010年頃、その頃はChefはまだ新しくて日本ではそんなに有名ではなかったが、Puppetを使っている人がちょっと先を行っているぞ、みたいな雰囲気だった。我々もアプローチは異なるが、2009年4月に似たような手順エンジンとしてWakame-fuelと言うものをリリースしていて、オートスケールの手順をサンプルに、簡単な状態管理をしたりしていた。
状態管理が大変なのは、頭の中では同じ状態のVMだと思っているだけであって、厳密には全てのVMは状態が異なっていると言うところにある。LBの下には「同じWebサーバ用のVMが複数動いている」と思いこんでいる。しかし実際は違う。細かいが、簡単なところでは、メモリやディスクの使用容量は一致しない。LBが均一にバランスしているわけではないので、準じてログのサイズなどに偏りが出る。例えば、ディスク上のワーキングエリアが十分ある前提でスクリプトを組んで走らせると、タイミングによっては失敗するWebサーバも出てくると言うことだ。
同じWebサーバなのに、違う結果を返す。生きているサーバを管理している以上、それぞれは稼動した瞬間から違う状態になると思っていた方が良い。ChefやPuppetでそれを封じ込めるのには限度がある。スクリプトを走らせる時は、それが状態の違うものに対する差分の手順であることを、常に意識しなければならない。僕らがWakame-fuelの開発をあるときから止めた要因のひとつは、そこに限界を感じたからだ。システムを外部から「維持しよう」とする設計である以上、必ずこの限界にぶち当たるのだ。（ちなみにそうじゃないアプローチが必要だと考え、プロトタイプした結果は、とある研究成果として利用されているが、その話はまた別途…）
それ以降、当時から「ChefやろうかPuppetやろうか、今ならどっちが良いですかね？」と相談される度に「どちらでもない。同じ状態になるマシンイメージを、いつでもポンと作れるようにした方が良い」と言うようになった。
環境をスクラップ＆ビルドできるようにしてみたら快適だった
３つ目は、CIとクラウド基盤の運用ノウハウこそが答えだったと言うことだった。僕達には、2009年の秋くらいから開発を始め、2010年4月にリリースしたWakame-vdcと言うIaaSの基盤ソフトウェアがある。これを実際お客様に向けて機能追加し、運用もする中で、僕らは色々と苦労をしてきた。
特に、テストが大問題だった。理由の一つは、お客様毎にインストールする環境が異なること。これらを本気で網羅的にテストをやろうとしたら、それぞれの物理環境が必要になってしまうので、仮想で何とかしたかった。その上で様々な構成をテストしよう、と。 通常のWebアプリケーションのテストの場合、デプロイが繰り返しできれば良くて、足回りが何パターンもあるとかあまり無い。IaaS基盤ソフトウェアは、Webアプリケーションを稼動させるための文字通り基盤であるため、これをテストしようとするとインストールのパターンがいくつか必要になる。
テスト環境はお客様に持っていただいているものもあるが、これはお客様都合で用途が変わることがある。お金の問題もあって、テスト環境の一部がいつの間にか別のものに利用されるなど、融通されることは良くある話だ。毎日動いていて欲しいが、保証はない。
そこで、僕達は小企業ではあるが、ある程度はオンプレでテスト環境を持つことにした。潤沢なリソースがあるわけではないので、その上を仮想化して環境ごとのテストをスクラップ＆ビルドしようと言う目論見だ。
結局出来上がったのは、以下のようなCI環境だった。
- リポジトリへコード修正が上がる
- rpmなどのパッケージを自動生成する
- テスト環境が無い場合、
いくつものマシンイメージを自動生成し、rpmパッケージも自動インストールする - 上記マシンイメージをテスト環境でVMとして起動し、コンフィグする
- テスト環境があれば、そこにデプロイスクリプトが走り、rpmなどが更新される。
- テストスクリプトが走る
- 上記プロセスの進捗がHipchatに逐次報告される
- 必要なければ好きな時にテスト環境を廃棄できる
僕達の場合は、テストをどうするかと言う観点から始まったが、これは当然一般のアプリケーションのデプロイと言う視点でも捉えられる。Webアプリケーションの場合、テストのための環境をVMで再度構築するようなプロセスは大げさすぎるかもしれない。しかし、このプロセスがあれば、いつでもアプリケーションをゼロから構築しなおせる。上流のネットワークで切り替えれば、このテスト済みの環境をそのまま本番環境に仕立てることもできる。あとはデータベースなどのデータをどうマイグレートするかを検討すれば良さそうだ。
ImmutableでBlue-Green Deploymentをやろう
ここまでで、パッケージを基にマシンイメージを作り、起動したらテストを流して確認し、本番環境として切り替えて利用する、そんなプロセスが出来上がった。この過程でまた細かなツール群が誕生し、僕達の中でも、何だか全部こんな感じで良いんじゃないかって言う気がしてきたわけです。
あとは、いかにマシンイメージをオンデマンドに作るかと言う手軽さが論点になってくる。望む状態のマシンイメージが好きな時に手に入りさえすれば、現在稼動中のサーバを維持する必要がなくなる。
マシンイメージの作成って面倒くさいけど、もし、簡単に好きなイメージがポンと作れたら、生きているインスタンスを触ってミドルウェアをちまちまとインストールする現在のスタイルは変わる気がする。
— Yasuhiro Yamazaki (@sparklegate) December 25, 2012そして、色々議論して約1年前の2013年春には、こんな結論に達した。
当時のWakame-Fuelやめた理由は、環境の差分をコードで表現するのに限界を感じたから。某パペも某シェも、結局良い答えが見つかっていないと思う。最近、僕らのなかでは、もうマシンイメージから作り直すのが一番合理的って事になってる。
— Yasuhiro Yamazaki (@sparklegate) May 27, 2013それが、Immutableな発想に基いて準備されたマシンイメージを用いて、Blue-Green Deploymentが日常的になされている世界なんだね。