急なサーバ増設の負荷を軽減するChef
桑野氏の発表にあったように、MongoDBはスケールするため、実運用では定常的なサーバ追加を行うための構築ツールが必要になる。サイバーエージェントで利用しているChef（シェフ）について、ここから並河祐貴氏が発表した。
並河氏によると、アメーバピグ・ピグライフはサービス・システム規模ともに右肩上がりに成功しているという。想定以上にサービスが成長することや、大きなイベントに合わせる必要もあり、サーバ台数を急に増設するよう求められることもあるという。
そこで、ミドルウェアの設定管理やプロセスの状態管理も含めて「Chef」で自動化している。Chefは、米Opscode社がオープンソースで開発・公開しているコンフィギュレーション管理ツールで、37signalsやEngine Yardといった企業で採用されている。Rubyで書かれており、Recipe（レシピ）やCookbook（クックブック）をDSLで記述できる。
多数のサーバーを同時に展開する際には、役割ごとに異なる設定のサーバーをセットアップしなければならなかったりするため、手作業では時間もかかり、人為的なミスも発生する。作業漏れやオペレーションミス、また作業者のスキルのバラつきも問題となる。こういったことでサーバーの投入が遅れると、機会損失が発生することにもつながる
そこで、システムの「あるべき状態」をあらかじめ設定しておいて、サーバの構築作業やシステム管理を自動化することが求められる。Chefでは内部DSLを採用しているため、サーバーの設定においてRubyで柔軟に記述でき、プラットフォームごとの違い、Linuxディストリビューションによるコマンドに違いなども吸収できる。
Chefでサーバーの状態を設定する際には「Node」「Role」「Cookbook」の関係を把握しておくことが必要だ。Node（ノード）とは管理対象のサーバーで、NodeごとにRoleやCookbookと関連できる。Roleは、Nodeを役割でグルーピングしたもの。
実際にどう管理するかはCookbookに定義されている。Cookbookのレポジトリには、Recipe（レシピ）とTemplate（テンプレート）とAttribute（アトリビュート）が置かれる。Recipeは設定内容を実際に記載したRubyスクリプト。Templateはサーバに配置する設定ファイルのテンプレートで、eRubyで記述される。Attributeはパラメータの設定値だ。
Cookbookには、拠点ごとのネットワーク設定、ハードウェアに必要な設定、ハードウェア固有のドライバやRAIDチェックスクリプトなど、サーバ共通の設定、DNS、NTP、LDAP、監視ライブラリ、鍵交換など、そしてRoleごとにで必要な設定を記述する。
一方で、並河氏は「Chefのいけていないところ」として3つの点を挙げた。1つはサーバのセットアップが面倒臭いことがある。しかしこれは最初だけなので許容できるとした。また、ソフトウェア名がSEO的に致命的で、例えばproxyサーバの「Squid」のレシピが知りたいときに「Squid Recipe」で検索すると本当のイカ料理の写真がたくさん出てきてしまう。
3つめとして、dry-runができないことがある。設定したものを反映しないでテストさせることができないため、テスト環境が必要になる。
そういった点はあるが、Chefを活用することで多くのサーバの増設・管理にかかる負担を軽減することができ、自動であるべき状態に設定され、また維持できること。少しのルールを覚えれば誰でも設定が簡単に書けること。内部DSLなのでRubyで処理が柔軟に書けることなど多くの利点があり、今後はクラウド基盤とも連携して、インフラ構築・運用を完全に自動化する仕組み作りを進めたいとした。
