本記事は英語版ブログで公開された記事の翻訳版です。
シリーズ前回の記事では、クラウドサーバアーキテクチャの新しいとらえ方としてペットと家畜の例えを紹介しました。絶えず個別の世話を必要とし仕様もばらばらな「ペット」に代わり、共通仕様を持ち均質で、群れ単位で気軽に追加や削除ができる「家畜」を使っていこう、というのがクラウドの考え方です。家畜サーバーは取り替えの利くリソースと言うこともできます。
「1匹の仔犬の世話は家族3人がかりですが、家畜は数万頭いてもカウボーイ数人で管理できますし、そばに付きっきりでいる必要もありません」
Piston CloudのCTO、Joshua McKenty
これは家畜のマインドセット、時にnoflakeアプローチとも呼ばれる考え方をうまく説明してくれています。ペットサーバーだと管理者が四六時中コンソールに貼り付いて面倒を見るのですが、家畜サーバーはこちらが途中で一切手を出さなくても構成できることが望ましいわけです。
構成管理ツール
ペットサーバーは手動で管理されます。管理者がSSHでアクセスし、構成ファイルをいじり、新しいパッケージをダウンロードしてインストールし、各種保守タスクを走らせてメモリやネットワーク使用量を見ることで、挙動のおかしいプロセスがないか確認します。
家畜サーバーはそうではありません。ペットサーバーでは、構成は後から（起動後に）行うものです。まず立ち上げ、動かしながら各部を調整していきます。いっぽう家畜サーバーでは、構成は前もって（起動前に）準備しておく作業です。サーバーを作成する前に、起動後にやっておきたい設定作業をすべて構成ファイルに書き出します。それをサーバーに送信したら、あとの作業は自動実行でお任せです。
こうした作業を実行する役目を担うのが、PuppetやChefといった構成管理（CM）ツールです。起動後にやってほしいことをCMツールが理解できる形でリスト化したのが構成ファイルで、記述には特化された、時には宣言型の、ドメイン固有言語を使います。
プログラミング言語Rubyに慣れている方なら、PuppetもChefもすぐなじめるでしょう。どちらもそれぞれのドメイン固有言語でRuby文法オプションが使えるからです。Engine YardではChefが使えますので、GithubでオープンソースのChefレシピも公開しています。Chefのレシピがどんなものか感じをつかみたい方はそちらをどうぞ。
長所と短所
ここまでを簡単にまとめておきましょう。
| デプロイメント | 構成を行う時点 | サーバーモデル |
|---|---|---|
| 手動 | 事後 | ペット |
| 自動 | 事前 | 家畜 |
どちらのアプローチにも長所と短所があります。事後構成の明らかな長所はリアクティブであるという点です。セットアッププロセスの途中で問題が発生しても、管理者がその場でリアルタイムに修正できます。事前構成を行う家畜サーバーの場合は、まず完璧な構成ファイルを作ってからCMツールに送らなければなりません。
しかし構成ファイルさえ正確であれば、家畜サーバーは断然有利です。構成は標準化されていますから、同じファイルは他のサーバーにも使い回せますし、できたサーバーはすべて完全に同一の構成を持ち、しかもハードウェア不良とは無縁です。つまり、高速かつ効率的に複製ができるわけです。複製ができるということはスケーラビリティがあるということで、サーバー交換が必要になっても再プロビジョニングが簡単です。
CMツールを使うもう一つの利点は、構成ファイルをチームで共同利用できることです。ファイルはコメントを付け、共有し、バージョン化し、差分を取り、属性を追加できます。Gitなどでバージョン管理しておけば、変更履歴の記録も取れます。こうしたCMツールの機能を活用することで、チームの規模にかかわらず、製品構成の共同管理が可能です。しかも構成は特定のペットサーバーが現在どういう状態にあろうと無関係なので、デバッグもずっとやりやすくなります。
構成のライフサイクル
CMツールを使うにしても、構成をどのように適用するかについては色々な選択肢があります。仮想化環境なら構成を適用するタイミングは主に2つ、マシンイメージをコンパイルする前か後かです。
コンパイル後
一つの方法は、どんなサーバーのベースにも使えるような、ごく基本的なマシンイメージから始めることです。AWSなどでは無数に公開されている既製イメージを利用できます。オリジナルのセットアップを作るにしても、そうした既製のOSイメージをベースにすれば簡単です（たいていのUNIX系ディストリビューションはブータブルISOを提供しており、これが実質上ベースイメージの役割を果たします）。
この場合CMの構成ファイルは、ローカルパッケージをすべてアップデートし、必要な追加パッケージをインストールし、その他マシンイメージがカバーしていない設定を行う内容でなくてはいけません。この方法だとベースイメージはまず変更する必要がないので、開発チームの負担が軽くなるのが利点です。新しい構成ファイルはローカルでテストし、リポジトリにプッシュすれば、それで完了です。
難点はインスタンスを起動するたびに構成を実行する必要があることです。問題が起きやすくなり、何かあったときのデバッグも面倒です。それに構成でカバーしなければならない作業の量によっては、新しいインスタンスがリクエストを受け付けられる状態になるまで時間がかかってしまう場合もあります。
コンパイル前
逆に、ベースイメージに前もって構成を適用しておき、そこから改めてイメージをコンパイルするという方法もあります。インスタンスの起動には、構成適用済みのイメージを使うのです。こうすれば1バイト1バイト完全に同一構成のインスタンスを作れますし、起動後の構成作業なしですぐに稼働できます。
当然、起動してからリクエストに応答できる状態になるまでの時間はぐっと短縮されますし、突然のトラフィック増加に対応してクラスターをスケールアウトするような場合にはそれが重要です。
この場合、構成を何か変えるたびに新しいイメージをコンパイルしてCMツールにインストールしなければならないのが難点になります。開発チームにとっては余分な時間と手間がかかります。おまけに、実行中のクラスターインスタンスに変更前のイメージを使用しているものがあった場合、それを全部新しいイメージに置き換えなければいけません。そのため、管理がたいへん煩雑になる場合があります。
ハイブリッドアプローチ
上に挙げた2つの中間的なアプローチも多種多様に存在します。例えば、インスタンスの起動時間が長くかかるのなら、その時間を見越して事前に起動しておくことでクラスターを「ウォームアップ」する、という方法があります。大きな発表をする前など、トラフィックが急増することが分かっている状況では特に効果的です。
Engine Yardで採用しているのもハイブリッドアプローチの一種です。当社では、標準的構成の大部分を適用した状態からイメージをコンパイルします。そしてマシンが起動した後に、事前に行えない、顧客別のカスタム構成を適用します。実際には、このプロセスは丸ごとユーザーダッシュボードの［Apply］ボタンにまとめられており、これですべてのChefレシピがクラスター全体に再適用されます。
大丈夫、Chefレシピは冪等な設計になっているので、何回適用しても副作用はなく、常に同じ結果になります。
結論
「構成してから起動する」方法は、ペット型のサーバー管理モデルに慣れている人には奇妙に見えるかもしれません。しかしクラウドコンピューティング環境では、多数のサーバーインスタンスを含むクラスターを迅速かつ均質に立ち上げる必要があります。したがって、CMツールによるサーバー事前構成は明らかに有利です。クラウドアーキテクチャをシームレスに利用できるようになるだけでなく、構成をバージョン管理できるというメリットも生まれます。
アプリケーションの規模によっては、構成管理のセットアップは複雑な作業になることもあります。幸い、ほとんどのプラットフォームプロバイダでは自動でやってもらえます。IaaSではなくPaaSを利用するメリットの一つがこれです。煩雑な作業のかなりの部分をおまかせにできるのです。
さてシリーズ次回の記事では、家畜型サーバーへのデプロイメントを前提としたアプリケーションを設計するときに開発者が受ける制約について見ていこうと思います。
あなたがふだん扱っているサーバーはペットモデルですか、それとも家畜モデルですか？デプロイメント手法としては、イメージにもろもろ焼き込んでおくのと、起動後に構成を適用するのと、どちらが好きですか？それとも、まったく違う手法をとっていますか？ぜひコメントをお寄せください。ご意見をお待ちしています。
(翻訳:福嶋美絵子)