Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

【デブサミ2012】16-C-2 レポート
ピグライフのスケ―ラビリティを支える2つのインフラ「MongoDB」「Chef」

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2012/03/29 14:00

 本稿では、「Developers Summit 2012」(デブサミ2012)において、2月16日に行われた株式会社サイバーエージェント 桑野章弘氏、並河祐貴氏によるセッション「大規模化するピグライフを支えるインフラ ~MongoDBとChefについて~」の内容を紹介する。  ピグライフは、サイバーエージェントがアバターチャット「アメーバピグ」内で提供するソーシャルゲームで、ガーデニングや料理・裁縫、ティーパーティー、牧羊などを楽しむことができる。2011年5月31日のオープンから3週間で100万ユーザを獲得し、2012年1月現在の会員数は360万人。サーバーサイドJavaScript(node.js)など先進的な技術の取り組みでも知られるが、本セッションではその一端が開発者自身によって語られた。

株式会社サイバーエージェント 桑野章弘氏
株式会社サイバーエージェント 桑野章弘氏
株式会社サイバーエージェント 並河祐貴氏(インフラエンジニア)
株式会社サイバーエージェント 並河祐貴氏(インフラエンジニア)

大規模環境でもスケーラビリティや冗長性を確保するMongoDB

 ピグライフはアメーバピグのサービス内ゲームであるが、まったく別のシステムで動作しており、アーキテクチャもまったく異なる。アメーバピグがJava+MySQLという従来型のWebアプリケーションであるのに対し、ピグライフはアプリケーションサーバがNode.js、データベースサーバにはMongoDBを採用している。

 MongoDBは、オープンソースのドキュメント指向データベースで、米10gen社によって開発・提供されている。いわゆるNoSQLの一種だが、KVSほど単純ではなく、JSONをベースとした「BSON(バイナリJSON)」によるスキーマレスで柔軟なデータモデルであることが特長だ。

 本セッションの前半では、ビグライフでMongoDBを採用した理由とその運用成果について桑野章弘氏が発表した。その理由としては、次のようなアーキテクチャの課題を解決するためだという。

  • 開発スピード
  • サービスアーキテクチャの課題
  • システムアーキテクチャの課題
  • 冗長化
  • スケーラビリティ

 開発スピードの面で桑野氏がまず挙げたのは、Node.jsとの相性の良さである。データモデルがJSONベースで統一されるためシリアライズが不要になる。また、データ管理が柔軟に行えるため、機能追加時にSQLサーバならカラム追加が必要になるところが、スキーマにオブジェクトを追加してやることで、新しい機能に必要なデータセットをすぐに追加できる。

 また、データベースサーバーにつきものの課題である冗長化とスケーラビリティに関しては、それぞれSharding(シャーディング)とReplicaSets(レプリカセット)という機能によって解決できる。

 Shardingはデータ分散の仕組みで、データを自動でChunk(チャンク)に分割し、複数のmongodに分散して配置してくれる。これによってサーバの負荷を分散することができ、サーバを「横に増やしていく」スケーラビリティが実現できる。どのサーバにどのチャンクがあるかというシャード情報はmongocが管理している。

 なお、MongoDBは、mongos、mongoc、mongodから構成される。mongodはShardingされたデータベースサーバー、mongocはその管理情報を持つサーバー、mongosはクライアントとShardingされたサーバー群を仲介し、ここではアプリケーションサーバに同居する形になっている。

 ReplicaSetsは非同期レプリケーションの仕組みで、自動でプライマリ/セカンダリ構成を取ることができる。プライマリ昇格の決定のために実サーバが3台は必要になる(ただし投票権のみを持っているプロセスを利用してサーバを少なく保つことも可能)。

 こういった機能により、アプリ側の実装コストは軽く、スケーラビリティと冗長性を確保したシステムが構築できた。現在は、140台という大規模のMongoDB群を運用している。ここで得られた障害対応などのノウハウが説明された。

 まず、各サーバプロセスのキャパシティ・プランニングについて。mongocでは冗長性は同期書き込み(2フェーズコミット)で確保されているが、スケーラビリティがないので潤沢なリソースを使える状態しておくほうがよいという。

 mongodは定期的にディスクに書き出すので、ディスクI/Oにはある程度の性能が必要だという。また、データをメモリキャッシュするため、メモリは多ければ多いほどよい。mongostatで状況を確認し、エラーが多くなったらメモリやShardingを追加する運用が必要だ。

 そのほか運用のポイントとしては、explain()でクエリの確認をし、必要な箇所にindexを貼る。それにより、クエリの高速化を図ることができる(例では最大100倍の高速化が見られた)。2.0で高速化・コンパクト化されているのでバージョンアップしたほうがよい。

 バックアップでは、fsyncコマンドでレプリケーションを一時停止してdumpを取得する。シャードごとに実行することで完全なデータが取れること。グローバルロックを避けるためには、書き込みの多いコレクションを別のクラスタに分ける。今後、コレクションレベルロックが実装されれば対応されること。

 Chunkの偏りはAutoBalanceで勝手に移動してくれるが、データアクセス頻度ではないので、新しく入ってきたデータが頻繁にアクセスされると負荷分散にならない。手動でChunkを移動してバランスすると、全mongosの再起動が必要となるため運用が必要になる。今後の課題だが、2.0系ではAutoBalanceが改善されているようだ。

 このように仕様や改善の余地はあるものの、 MongoDBはスケーラビリティを確保する要素は十分に持っており、ソーシャルゲームやモバイルゲームで開発するにはよいプロダクトで、サービスを安定運用しながら成長させるために大切な要素になる、というのがサイバーエージェントでの認識だ。

MongoDBの構成
MongoDBの構成

急なサーバ増設の負荷を軽減する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で処理が柔軟に書けることなど多くの利点があり、今後はクラウド基盤とも連携して、インフラ構築・運用を完全に自動化する仕組み作りを進めたいとした。

Node、Role、Cookbookの関連
Node、Role、Cookbookの関連
お問い合わせ

株式会社サイバーエージェント

東京都渋谷区道玄坂一丁目12番1号 渋谷マークシティ ウエスト17階

http://www.cyberagent.co.jp/

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

All contents copyright © 2005-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5