インフラエンジニアのブログ

CentOS6から7へアップデートしたついでに、mongodbも2.xから3.4へアップデートしてみたら、ユーザー関連の設定方法が違ってて少しハマったのでメモとして残しておきます。

参考
https://docs.mongodb.com/manual/tutorial/enable-authentication/
など

mongodb 2.xの時は、簡単な設定しかなかったんだけど（後DB毎にユーザー設定するとか、ちょっと変だったw）
mongodb 3.xではコマンドが変更されて、一元管理的になってました。

・ユーザー登録例
まずは管理者権限のユーザー登録です。

use admin
db.createUser(
  {
    user: "myUserAdmin",
    pwd: "abc123",
    roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
  }
)

mongodb 3.4ではデフォルトでユーザー認証が有効になっている模様（2.xの時はデフォルト無効）
ですので最初に管理者権限のユーザーを登録する必要があります。
2.xの時と違って、認証なくてもmongodbに入れるようになっているので、それから admin DBへ移動してユーザー登録します。
その後 admin で認証すれば管理者になれます。

認証例

use admin
db.auth("myUserAdmin", "abc123" )

・一般ユーザーの登録例

use test
db.createUser(
  {
    user: "myTester",
    pwd: "xyz123",
    roles: [ { role: "readWrite", db: "test" },
             { role: "read", db: "reporting" } ]
  }
)

mongodbへログインするには以下のようにもできます。

# mongo "mongodb://myTester: xyz123@localhost:27017/test"

・その他
ユーザー登録をアップデートするときは db.updateUser でやるらしい。

追加
さくらのVPSでcappedに3000件登録するテストをしたら
CentoOS6 mongodb 2.4 : 約13秒
CentoOS7 mongodb 3.4 : 約6秒
とパフォーマンスがアップされてました。
mongodb 3.4の方もほとんどチューニング等してないけど、WiredTigerのおかげかも？

便利な MongoDB ですが、デフォルトは認証無し、誰でもパスワード無しでアクセス出来てしまいます。
これでは本番運用するにはちょっと・・・やっぱり最低限のユーザ認証は必要ですね。
もちろん MongoDB もユーザ認証に対応しているのですが、設定が少し面倒なので、簡単な設定の仕方をメモっておきます。

○MongoDBのインストール
rpm でのインストールを前提
設定ファイル /etc/mongodb.conf
デフォルトは、ユーザ認証無し、IPアドレス（127.0.0.1）でのアクセス制限あり

○管理用ユーザの登録
まず MongoDB の管理者の登録をします。
最初に管理者を登録しておかないと、設定変更した時にアクセス出来なくなってしまいますからね（試してみた、というか間違った経験あり(^^;）

管理者登録方法

$ mongodb
> use admin
> db.addUser("admin","password");

※もちろんユーザ名とパスワードはちゃんと設定しましょう。

○ユーザ認証ありで再起動
/etc/mongodb.conf を変更します。

auth = true　　# コメントアウトされているので有効にする
#bind_ip = 127.0.0.1　　# ネットワークからアクセス出来るようにする場合はコメントアウトする

MongoDB を再起動することでユーザ認証がないとアクセス出来なくなります。

○管理者でログインしてみる。

$ mongo
> use admin
> db.auth("admin","password");

ちなみに、adminデータベースは管理者というよりも、デフォルトのユーザ認証に使われるデータベースです。ここでは管理者と書いたけど、実際はadminデータベースで認証した場合は何でも出来るってことで、特に管理者って権限があるわけではないようです。

追加
adminにユーザを作ってしまうと何でも出来てしまうので、アクセス制限したい場合は、データベース毎にユーザを作りましょう。
さらに、読み取り専用ユーザというものも作れて、書込む必要がないユーザにはこちらの方が便利かも
読み取り専用ユーザを作るには、trueを追加するだけ

> db.addUser("readonly","password", true);

最近注目のスキーマレスデータベース：MongoDB
NoSQLとかいろいろ出てきたけど、使いやすくてパフォーマンスが良い MongoDB は一押しですね。

単純な性能比較だと、構造が単純なKVSの方が良いことも多いけど
ソーシャルゲームで使ってみた感想では、やっぱり開発しにくくなることが多い。
どうしても MySQL と比べて、性能よりも開発のしやすさ（デバックのしやすさ）が劣る製品は使いにくいです。やっぱり phpMyAdmin のようなツールがないと不便なんだよね。

MongoDB だと、コマンドラインから簡単に操作出来るし、検索もいろいろ出来るのは便利。実際デバックする時にコマンドラインから簡単にアクセスできないと不便ですから。でも phpMyAdmin のような便利なツールがない（似たようなツールはいろいろあるけど、まだまだ発展途上、今後に期待）

インフラエンジニア的には、管理ツール系がまだまだだけど（あとノウハウもないし、まぁこれは使ってみないことには）スキーマレスというのは慣れると非常に便利です。
特にちょっとしたツールとか作る時、まじめに設計から・・ほとんどしないですよね(^^;
思いついたものから作って行くので、途中でいろいろ変更が入ることが当たり前なので、その度にスキーマの変更とか面倒だし・・スキーマレスの MongoDB なら変更が楽！

まぁ動機が不純だけど、実際楽だし、プログラムを作ることが仕事ではなく、そのプログラムで楽をしたいということなので、なるべく楽に作れるツールは嬉しいです。

でも、MySQL の代わりに使えるものではないと思います。
まだまだ実績も少ないし、本番の大事なDBは実績重視ですからね。

【送料無料】MongoDB: The Definitive Guide 価格：7,728円（税込、送料別）

今回はソーシャルゲームのインフラネタから
データベースのチューニングについて

MySQLを使うことが多かったが、一般的なチューニングの話は他のブログなどにゆずるとして、ソーシャルゲームならではのお話です。
MySQLの具体的なチューニングでなくてごめんなさい(^^;

１、ボトルネック
一番大事なのは、どこがボトルネックになっているのかを知ること。
これなくしてチューニングしても、的外れな努力に終わることになるからね。

特にソーシャルゲームの場合は、イベントなども多いし、データも増え続けて行くので、最初に想定していたボトルネックと違ってくることがあるので注意
イベントの種類によっても別のボトルネックが出てくることもあるし、データが増えてきてメモリが足らなくなってくることもあります。
運用中も常に新しいボトルネックが発生していないか確認することが重要になってます。一度チューニングしたからそれで終わりってことにはなりません。

２、最適化しすぎない
アプリ毎に、そのアプリの特性に合わせてチューニングすることも重要ですが、アプリの特性は時間とともに変わってくることも多いし（特にイベントは、外れたイベントを続けていても意味ないし）現状に合わせすぎると逆にそこがボトルネックになることもありますからね。

あとソーシャルゲームでの特徴としては、レスポンスタイプが重要ってことかな。
まぁ他のシステムでも一緒ですが、より重要であり、例えば平均レスポンスタイムを改善するよりも一番時間のかかる処理を改善することを優先することもあります。

そしてもっと大事なのが、落ちないこと！！
想定よりもアクセスが増えてスワップするようなことがないようにすることです。
スワップしちゃうと落ちてしまいますからね。
例えばグローバルバッファも少し少なめにしたり、フリーメモリを少し多めに見積もっておきます。もちろんデータが増えても直ぐに落ちたりしないように余裕を持たせておくことも重要ですね。

◆そして・・・
当たり前ですが、ずっと運用を続けて行くので、状況を常に確認しておくことが重要。
正常時の負荷（どのくらいのアクセス時にどのくらいの負荷になるとかの目安を覚えておいたり）負荷が増えていたらその増加ペースがどのくらいかとか。
特定のイベント時の負荷の傾向とかも知っていた方がいいですね。

そうすれば、負荷で問題がおこってから慌てて対策をするようなこともなくなるでしょう。
問題が起こる前に、問題を予想して、先に対策をしておけば問題がでることもなくなります。