「MongoDB」は，スキーマレスであることやスケールアウトが容易なこと，さらにレプリケーションのしくみが用意されているといった特徴から急速に人気を集めている，オープンソースのドキュメント指向データベースです。第21回で，MongoDBの基本的なしくみや開発時における注意点などをサイバーエージェントの技術者に解説していただきました。今回は後編ということで，運用時におけるポイントについて伺っていきます。

Ameba PicoやピグライフでMongoDBを実運用

サイバーエージェントにおいて，MongoDBはすでにいくつかのプロジェクトで活用されていますが，その1つにアメリカ向けのアメーバピグであるAmeba Picoが挙げられます。松下雅和氏は2011年1月に入社し，このAmeba Picoの運用にアサインされたことでMongoDBを使うことになったと話します。

「前職ではMongoDBを使ったことはなかったので，サイバーエージェントに入社してから勉強し始めました。最初は前任者の使い方を見つつ使い方を覚える，という感じですね。ちなみに私が運用を担当することになったAmeba Picoでは，実はKey/Valueストア的な使い方がメインで，Valueにはバイナリに変換されたデータを保持しています」（⁠松下氏）

アメーバピグの新たなソーシャルゲームとして注目を集めるピグライフでもMongoDBは使われています。その運用を担当する並河祐貴氏は，事前に十分な検証を行い，これなら大丈夫だと判断したうえで導入に踏み切ったと言います。

「運用面から事前に検証したのは，安定して運用ができるのか，トラブルが発生した際にリカバリが問題なく行えるかといった点です。たとえばMongoDBには，障害発生時に自動的にハードウェアを切り替えるレプリカセットと呼ばれるしくみが用意されています。そこで実際にサーバの電源をいきなり引き抜き，きちんとフェイルオーバーするかどうかなどを確認しました。こうした機能や仕様をひとつずつ実際に確認して，最終的に実際に使っても大丈夫だという判断に至りました」（⁠並河氏）

実際に運用に入っても，今までのところ問題なく動作しているとのこと。本番環境において，ハードウェア障害によりサーバがダウンしたというケースもあったそうですが，そのときも自動的にバックアップ機に切り替わり，サービスも問題なく継続できたということで，可用性に関しての心配は少ないようです。

シャーディング利用時はデータのバランシングが鍵

実際にデータストアを運用する際，可用性とともに気になるのはパフォーマンスでしょう。このパフォーマンスの観点で重要になるのは，やはり搭載しているメインメモリの容量だと並河氏は指摘します。

「メインメモリ上にデータがある間はそれなりのパフォーマンスが得られますが，そこから溢れてディスクに落ちていくと，どうしてもパフォーマンスは低下してしまいます」（⁠並河氏）

さらにポイントになるのは，シャーディング構成におけるそれぞれのハードウェア構成です。シャーディングとはMongoDBに搭載されている負荷分散のためのしくみであり，サーバの増設によるスケールアウトを可能にします。ただ，このシャーディングを利用する際は，それぞれのサーバの性能をできるだけそろえるべきだと松下氏は指摘します。

「Ameba PicoはAmazon EC2を使って運用しているのですが，一時期ハイスペックなインスタンスとスペックの低いインスタンスが混在する状況になったのです。そのとき，MongoDBの動作が安定しないという状況に陥り，最終的に各インスタンスのスペックを合わせるという作業を行いました。実はMongoDBのシャーディングにおけるバランシングはけっして賢いものではなく，サーバのスペックに関係なくデータを分散します。そこでサーバのスペックが違うと，このシャードだけが遅いといった状況が発生してしまうわけです」（⁠松下氏）

サーバのスペックやデータのアクセス頻度などを鑑み，適切に各シャードにデータを分散してくれるのが理想ですが，現状のMongoDBにはそこまでの機能はありません。そのため，どのように分散されてもパフォーマンスを維持するために，サーバのスペックをそろえておくべきということです。

ただ，いくらサーバのスペックをそろえても，アクセス頻度の高いデータが特定のサーバに偏ってしまうという状況は起こりえます。こうした場合には，データの偏りに合わせて高性能なサーバを配置するのもポイントの1つだと話すのは並河氏です。

「ピグライフでは現在46シャードあり，サーバの種類は基本的にそろえています。ただ，どうしても偏りが出ている部分があって，バランシングがうまくできていない，一部のシャードにクエリが集中するという状況は起こってしまいます。そうしたシャードに対してはメモリやストレージをフルに活用できるハイスペックなサーバを配置するといったことも検討してもよいかもしれません」（⁠並河氏）

アクセス頻度の高い複数のデータが特定のシャードに集中してしまうと，パフォーマンス上のボトルネックが発生します。そこで手運用でデータの配置をコントロールすることもあるとのこと。

「MongoDBの運用において，シャーディングを構成している各シャードをモニタリングし，今どれくらいクエリが来ているのか，あるいはロックがどれくらいかかっているのかというのは，けっこうチェックしています。それでデータの状況を見て，あるシャードに偏りが発生しているということがわかれば，メンテナンスの時間を利用して手動でデータ（チャンク）を移動する，といった対応も行っています」（⁠並河氏）

各シャードへのデータの分散については，開発時点から考えておくべきだと話すのは松下氏です。

「MongoDBでは，どのシャードにデータが配置されるかはシャードキーによって決まります。たとえばユーザ情報のようなデータはできるだけ各シャードに均等に分散させるべきなので，なるべくランダムな数値をシャードキーとして設定しておきます。逆に，履歴情報で日付をシャードキーにしてしまうと，同じサーバに連続して書き込みが行われるといったことになるので，それ以外の値をキーとして使うといったことを考えておくべきだと思います」（⁠松下氏）