Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2013年05月14日

kunihira

Chef vs Fabric 使用感比較レポート

こんにちは。国平です。

前回の記事で、最後に「viの記事を書こうか」とか書いてましたが、個人的にもっと熱いネタが見つかったので急遽ネタを変更して、ChefとFabricを比較してみます。

目的

本記事の目的は、複数のサーバマシンで全く同じ環境を用意するためのツールの検証です。

Webサービスの開発/運用では、複数のサーバを用意して冗長化を図ります。 また、AWSのようなクラウドサーバを利用していると、サービスの拡大に合せて柔軟にスケールアウトする事が可能となります。

弊社でもこちらの記事にあるように、複数台のサーバでサービスを運用し、更に負荷状況に合せてサーバのスケールアウトが出来るように環境を用意しています。

当然、サービスのリリース時には全てのサーバが同じ設定で動くように用意されていますが、運用が長く続くと各サーバ環境が同じである事を保証するのが難しくなってきます。 例えば、あるサービスの初期リリースでは2台のサーバで運用し、サービスの拡大に合せて新たにサーバを追加する際などに、インストールするツールのバージョンが微妙に異なったり、微妙にパスの通し方やファイルのユーザ権限の設定がズレていたいたりといった問題が発生しがちです。

こういった問題を回避するために、各サーバで全く同じ環境を用意できるツールが必要になります。 そのツールとしてChefとFabricを取り上げ、比較を行ってみます。

Chefとは

http://www.opscode.com/chef/

Chefとは最近話題の構成管理ツールです。 Chefを利用する事により、サーバの環境構築を自動化する事が出来ます。 Ruby製のツールで、Rubyのコードでサーバの環境設定を設定ファイルにまとめる事が出来ます。 (※ Chefではこの設定をレシピと呼びますが、今回はFabricと比較するため設定ファイルと記述します。)

設定内容をソースコードとして残す事が出来るので、何度でもサーバを同じ状態に構築する事が出来ます。 設定内容はDDLとして用意されており、読みやすいだけでなく、Rubyになじんだ人なら拡張もしやすいかもしれません。

Chefの利用方法には2通りあります。 ひとつは単一マシン上で動作するChef-Soloで、環境構築を行いたいマシン上に設定ファイルを配備しそのマシン上でChefを実行します。そのため、各マシンに対して設定ファイルを配備して、Chefを実行することになります。

もうひとつはChef-Serverを利用する方法です。この方法では、設定ファイルを配備するChef-Serverマシンと、Chefを実行して環境構築するChef-Clientマシンを分離することができます。Chef-ClientはChef-Serverから自動的に設定ファイルを取得して実行します。この方法だと、複数のマシンに対する設定ファイルを一元管理できます。さらに、Chef-Serverの設定が変更されると、Chef-Clientは自動的に同期をとるので、変更の反映を各サーバに対し実行する必要がありません。

Chef-Solo、Chef-Server/Clientのどちらを利用するにしても、各マシンに対してChefのインストールが必要になります。

また、今回の調査の範囲に含んでいませんが、自動テストを書くこともできるようです。作成した設定ファイルを保守することを考えると、テスト可能であることは非常に重要ですね。

Fabricとは

http://docs.fabfile.org/en/1.6/

Fabricはアプリケーションのデプロイツールです。 Fabricも自動でサーバを操作する事の出来るツールで、リモートサーバに対して、ファイルの転送・コマンドの実行を行う事が出来ます。

Pythonで作られており、サーバに対する操作内容をPythonで記述します。 Fabricの設定ファイルは、シェルスクリプトに似たコマンド、もしくは直接シェルスクリプトを実行するため、シェルスクリプトを書いた事がある人はなじみやすいかもしれません。

Fabricは、Fabricの実行サーバから実際に環境を構築するリモートサーバにSSH接続を行い、設定ファイルに書かれた処理を実行します。 そのため、Fabricをインストールするマシンは1台だけで済みます。

ChefとFabric

共通点

ChefとFabricでは、どちらでも「サーバに対する操作をソースコードとして記述」するので、Gitなどでバージョン管理する事が可能です。 そのため、複数のサーバを用意する際、サーバ間の微妙な誤差をなくす事が出来ます。

異なる点

前述のように、Chefは構成管理ツール、Fabricはデプロイツールとそもそも対象とする領域が異なっています。

構成管理ツールではサーバ環境の構築を目的としており、デプロイツールではサーバ上にアプリケーションの配備を行う事を目的としています。 ただし、主目的が異なっているだけで、どちらでもそれぞれが得意とする事は実現可能となっています。

また、Chefによる環境構築を行うためには対象となるサーバ全てにChefをインストールする必要がありますが、Fabricでは1台にインストールすればリモートサーバにはインストールの必要がありません。

利用してみる

今回、ChefとFabricを比較するにあたって、試しにNginxのインストール手順をそれぞれのツールで書いてみました。 Nginxインストールの要件として、以下を設定しました。

  • Nginxをソースからビルドする
  • ビルドに必要なライブラリなどもインストールする(g++など)
  • nginx.confを配備する
  • nginx.confはテンプレートを用意し、本番環境/開発環境で設定内容を書き換えられるようにする

本番環境と開発環境でサーバのマシンスペックが異なるということはよくあると思います。 nginxのチューニングでは、マシンのCPU数に合わせてworker_processを設定します。 (Nginx+Play2.0利用時のNginxとAkkaのパフォーマンスチューニング)

ここでは環境に合わせてconfファイルを書き換えて配備できるようにしてみます。 想定しているサーバのマシンスペックは、開発環境がコア数1、本番環境がコア数2を想定しています。 (AWS EC2インスタンスの、m1.smallとm1.largeインスタンスをイメージしています)

ちなみに、nginxをインストールするマシン環境は前回の記事で紹介したVagrantを使って用意しました。 やっぱりVagrantは便利ですね。

Chef

今回、Chef-Serverを用意するのが面倒だったので、Chef-Soloを利用しました。 そのため、1つのサーバですべての作業が完結しています。

設定ファイル

Chefの設定ファイル群の構成は下記の通りです。

これらのうち、主要な部分をgistに載せました。実行は、_run chef-soloのシェルになります。 https://gist.github.com/Kuchitama/5547882

Fabric

Chefは1サーバで完結しましたが、こちらは折角なのでFabricをインストールしたサーバ(サーバA)とNginxをインストールするサーバ(サーバB)を分割しました。 サーバA上でFabricのタスクを実行すれば、サーバBにNginxがインストールされます。

設定ファイル

gistはこちらです。 _run fabricのシェルで実行できます。 https://gist.github.com/Kuchitama/5548125

使った上での比較

実は、どちらのツールでもNginxのインストール設定は既に公開されているのですが、今回は比較のため自分の手を動かして設定ファイルを全て書いてみました。 公開されている設定は下記になります。

私は、RubyもPythonもなじみが無かったのですが、ドキュメントを漁りながら書いて行く事でどちらも2,3時間で作成出来ました。

Chefについて

メリット

実際に触ってみたChefのメリットは以下の点が挙げられます。

  • べき等性が保証される
  • 公開されている設定ファイル(レシピ)が豊富
  • 日本語の資料が多い

べき等性とは、何度実行しても同じ結果になるということです。 複数のマシン上でChefを実行しても同じ設定で動作させれば同じ状態になることが保障されています。

今回は、設定ファイルを自作しましたが、主だったツール、アプリケーションのインストール設定ファイルはGitHubなどで公開されていて、CloneしてChefを実行するだけで環境構築を行うことも可能です。

また、Chefはここ最近で非常に注目を浴びているツールなので日本語の情報も多くあります。

はまりポイント

触ってみてハマったポイントとして、現状のChefではRuby2系に対応していない点です。 今回、rvmを利用してRubyの最新バージョンをインストールしてから利用したのですが、エラーが発生してChefが動作しませんでした。

あと、設定の記述がRubyのDSLのため、慣れるまでは読み書きがしづらいかもしれません。

Fabricについて

メリット

  • インストールするマシンが1台で良い
  • シェルスクリプトの知識がそのまま使える

FabricはPush型の構成になっているので、リモートマシンが増えた際の対応手順が少なく済みます。

また、いくつかのコマンドはPythonの関数として用意されていますが、ほとんどシェルを書くのと同じ感覚で記述できます。 そのため、初期の学習コストはかなり少なくできると思います。 新しく設定ファイルを作成するのも、既にあるシェルスクリプトを元に設定ファイルを作成するのも、それほど難しくはないと思います。

はまりポイント

今回初めてPythonを触ったのですが、FabricのインストールについてはPythonからインストールしなくてはならず、Chefのインストール以上に手間取りました。

ただ、1台にインストールしてしまえば、リモートサーバにはインストールの必要が無いので、全体としてはそれほど手間がかかるということもないのかもしれません。

また、ツールとしてべき等性が保証されているわけではないので、設定ファイルの作成者が保証するか、Fabricの実行者が手順を守る必要があります。

今回作成した設定ファイルですと、g++が既にインストールされていた場合について考慮されていないので、g++のインストールタスクが複数回実行されると予期しない動作を起こしてしまいます。

比較表

項目 Chef Fabric
構成 Chef-Solo Fabricサーバ → リモートマシン
言語 Ruby(1.9系) Python(2.5~)
設定ファイル DSLで記述 Pythonで記述(シェルライク)
日本語ドキュメント 豊富 少ない
サンプル 豊富 少ない
サーバ追加の作業 多少多い: Chefインストールの手間がかかる 少ない:タスクの実行先を追加するだけ

まとめ

今回、ChefとFabricをそれぞれ利用して、比較してみました。 どちらも1度設定を書いたら実行するだけで、がりがりとインストールが進むのが楽しかったです。

使ってみた所感ですが、それぞれの向き不向きとして、Chefはツールなどのインストールに強く、Fabricはシェルコマンドの実行に強いという印象でした。

それぞれを試してみる前は、今後の利用をどちらか一方に絞るつもりでしたが、両方を使い分けるのもいいかもしれません。

どちらにしても、サーバに対する作業内容をソースコードとして管理できるのは非常にメリットが大きく、サーバの運用工数の削減につながると思います。


2013年05月8日

Hashimoto Naoto

ソーシャルゲーム交流会 レポート

こんにちは。ソフトウェア開発部の橋本です。

去る4月9日、KLabさん、クラウドクリエイティブスタジオさんを弊社にお招きしてソーシャルゲーム交流会を開催しました。

交流会の目的としては、開発の拠点を関西にもつ各社の開発メンバー同士交流を深めること、 蓄積されたソーシャルゲーム開発のノウハウや課題点の共有、今後の昇華の足がかりとすることです。

また、今回交流会に参加の3社(弊社含む)は、関西に開発拠点をおいており、 今後もこのような情報共有の場を持つ先駆けとする狙いもありました。

結果から申し上げますと、開発者間の交流を深めたり、今後の情報共有の土台作りという目的に対して望んだ成果が得られました。

興味深いやりとりがたくさんできたので、今回はその交流会の様子をレポートしたいと思います!


交流会の流れは、次のように行いました。

  1. スライドを交えた簡単な自己紹介
  2. グループディスカッション
  3. 軽食を交えて懇親会

簡単な自己紹介というわりにはガチなものもちらほらあり、 そのままの流れでグループディスカッションが開始されました。

 

グループディスカッション議題その1:パズル付きのソーシャルゲームがヒットしたのはなぜなのか?

この議題の背景としまして、従来のカードバトルものとは一線を隔した、ゲーム性のあるソーシャルゲームが大ヒット中です。 この成功に関しては、いろいろな場で考察が繰り広げられています。

KLabさんの社内でも考察をする機会が何度かあったとか。

しかし「これだ!」というような、いわゆる秘訣は見つからない状態とのことで、 それならばソーシャルゲーム関連に従事する人の集まるこの場で意見交換を行ってみよう! という趣向でした。

ディスカッションするなかで出た意見を、以下にまとめました。

■ 人に勧めやすい

  • 課金しなくても十分遊べる
    • 運営から頻繁に課金商品が配られるため
  • デザインはかわいいものからカッコいいものまで
    • 大人向けの過激なデザインは、人に勧めるには向かない
  • わかりやすく、シンプルなゲームデザイン

■ 電車で遊ぶのに適している

  • 一戦がだいたい一駅を移動する時間と同じくらい
  • プレイしているのを他人に見られても恥ずかしくない
  • 通信状態が悪くなっても、一戦終了まで遊べる

■ 課金して損した感じがしない

  • 課金商品は1種類のみというシンプルさ
    • いつ使っても良いし、無駄にならない
    • 1プレイ100円感覚で遊べるゲーム、という感覚
      • ソーシャルゲームという括りと異なるのでは説
    • 運営から課金品がよく配布されるので、使うことへのハードルが下がっている

ディスカッション:パズドラ

■ もし自分たちが最初にこのようなデザインのゲームを作ることができたら、同じように成功したか?

  • おそらくは無理。課金品を配りまくるという運用の発想がなかったし、仮に構想があったとしても実現できないと思う。 その結果、同じように成功するかと問われると、おそらくそうはならないだろう。

■ 親子でも遊べるというのは大きい

  • 親は子どもにソーシャルゲームをさせたくない人も依然多いが、一緒に楽しめるものとなれば別。
  • 広い年代に受け入れられるイラスト、ゲーム性があるが単純さも損なわれていない。

グループディスカッション議題その2:ソーシャルゲーム開発における自慢話

■ フリュー:

 ペアプログラミングの実施。

  • チーム内でペアを作り、作業者とレビュアーに分かれて開発を行う。
  • 限りなく短いスパンでレビュー、手直しができる。また、情報の共有にもなる。
  • バグの発生率が下げられるし、一人しか触ることができないコードにならない。

ペアプログラミングに対するよくある誤解として、 「人が2人必要なので、1人の開発の倍コストがかかるのでは?」というものがあります。

ペアプログラミングでは上記の通り、完成度が高く手入れがしやすいコードが書けます。

バグ修正の時間や、コードリーディングにかかる時間が減るので、 コストが純粋に倍になったりはしません。

また、作業者・レビュアーともに、たくさんの学びがあります。

 残業が少ない。

  • 開発チームで見積もり・振り返りを行う。
  • リリース直前などで立て込むことはあるが、それでも残業は少ない。
  • 無理なスケジュールを組まないことが浸透してきている。

■ クラウドクリエイティブスタジオさん:

 Jenkinsを用いたビルドを行っており、BGMが鳴る。

  • ビルドが開始されるとRPGの戦闘の音楽が流れる。
  • ビルドが無事成功すると勝利のファンファーレが流れる!
  • 失敗すると、全滅したときのBGMが流れる……。

日々のビルドが楽しくなりますね!

日常を楽しむという姿勢が現れていて面白いです。

また、ビルドが自動化されているので、作業を減らせたり、人の手によるミスの可能性を低減できます。

 お菓子駆動

  • お菓子担当者が、予算内でお菓子を用意してくれる。担当は持ち回り。
  • 自分では買わないようなお菓子にもお目にかかれて面白い。
  • お菓子のためにがんばる。
  • 予算は一ヶ月ごとに一定ということで、月の頭に豪勢なお菓子だと月末はうまい棒のために頑張ることになるのだとか。

■ KLabさん:

 コードレビューに対する意識が高い。

  • チーム外からでも、積極的にレビューしてもらったりする。
  • ノウハウの共有化によって、より良いコードが書ける。
  • チーム外からプルリクエストが飛んでくることもある。

開発がチーム内だけで完結しないで、知識や技能を共有できます。

他のチームにいるスペシャリストの力を活かせると、効率も良いうえに開発メンバーのレベルアップにもつながるそうです。

軽食を交えての懇親会

グループディスカッション後の懇親会でお聞きしたお話をリストアップします。

■ 開発と企画でロケーションが離れている件について

  • 関西の開発チームと、関東の企画チームといったようにロケーションが離れている。
  • ささいな行き違いや伝達ミス、情報が共有されていなかったなどといったことが起こる。
  • IRCチャットや、TV会議を用いて円滑な意思疎通を計っている。
  • TV会議での音質と画質の向上は、感覚的な距離を縮める働きがある。
  • 高品質にするだけでTV会議の快適さが全然違う。

  • Webカメラでお互いのオフィスを写しながら仕事をするのはオススメしない。 お互いに気を使って、忙しくないときでも帰りづらい空気ができてしまったりする。

■ ログ解析について

  • ログ解析の重要性は企画にも認知されてきた。
  • ログを解析する専門のチームを作り、分析に当たっている(KLab,フリュー)。
  • EMR、fluentを駆使して、出来るだけ短いスパンで解析結果を届けられないか模索中。
  • ただ、ログ解析チームのリソースに対して案件が多く、案件ごとに個別にログを出力しているケースもある。
  • ログ基盤だけですべてを賄えるようにはなっておらず、今後の課題である。

交流会全体を通して

各社、各参加者とも、同じような悩みや問題を抱えているようだと感じました。

問題点に対しての前提の説明があまり必要なく、

「○○みたいな問題がありまして…」というと「うちもうちも」といった感じでした。

(ロケーションの問題や、ログ解析の問題然り)

「ソーシャルゲーム開発はまだ認知度が低く、オープンな場で話が通じない事もある。このような場だと、そういう居心地の悪さは無い。誇りというほど厳かなものではないが、自分が頑張っている仕事を楽しく話せるというのは、やはりいいものだ」

という旨のお話を伺ったのが、私にとっては特に興味深かったです。

今回の交流会の内容としては以上で終了ですが、 この第一回で終わりとならず、これからへと繋がっていくことを望みます。

また、今回の交流会は会社間で行いましたが、もっとオープンな場でのソーシャルゲーム勉強会も開催されています。

少しでも興味が湧きましたら、是非とも覗いてみてください!