はじめに
この記事は株式会社アイスタイルアドベントカレンダー 3日目の記事です。
やっと入社2年目に突入したインフラエンジニア @imaiy がゆるい感じで2回に分けてお届けします。
導入の背景
弊社 アイスタイルグループで運営しているWebサイトは、
@cosme上とそこで姉妹サイトと表示されているものだけでも15、その他も含めると20程度のサイトを運営しています。
サイト数が多い分、サーバも用途や言語・バージョンが異なるものも多いため、そこそこ数があります。
サイトごとにMemcachedが乱立していたり、Webサーバ内に同居しつつMemcachedクラスタ化していたり、日に日にメンテナンス性が損なわれていく状態です。。。
ココで一念発起して、サイト横断で使えるKVSクラスタを作ろう！ というのが事の始まりでした。
しかしCouchbaseを本当に導入するのかどうかは決まっていません。
検証中のため間違ったことも書いているかもしれません、予めご承知おきください。
Couchbaseについて
Couchbase公式(http://www.couchbase.com/)
Developerサイト(http://developer.couchbase.com/)
オープンソースの分散型NoSQLドキュメント指向データベースです。
JSON形式のドキュメントでスキーマレスにデータベースを利用できます。
ドキュメントのキャッシュ方式はメモリとディスクのハイブリッドで、利用頻度に応じて使い分けます。
すべてのデータをディスクに保管することで永続性も確保できます。
個人的に面白いなーと思ったのはそのままMemcachedのClientライブラリが利用出来る点です。
残念ながらMemcacheのほうは対応していなさそうで、うまく動かせていません。
導入の検討
では「なぜCouchbaseなのか」という点についてですが、主に3つの理由が挙げられます。
1. 構築・運用が容易であること
- 特にデータのReplicationやログ出力とローテート周り
- 運用に必要な情報が幅広く取得できること(クラスタやバケットの情報など)
2. オンラインで大きな影響なくクラスタノードを増減出来ること - 多少キャッシュ側の処理速度が落ちたとしても、ヒットレートが下がらない方が良い
- ヒットレートが落ちてバックエンド側に大きな負荷がかかる想定でシステムを組むと無駄が増える
3. 開発側のメンバーが取っ付き易いこと - 基本CLIでステータス見る運用はなかなか浸透しない
- でもすべて可視化していくプロセスは結構面倒くさい
- 最初からBucket毎にグラフ化されていたり、アクセスの多いKeyが見れたりするのは助かる
特に、Memcachedはログ出力やそのローテートにも癖があり、トラブルシューティングは割と面倒くさい傾向にあります。
主に使う情報も大体はSTATSなどで、Couchbaseのようにリアルタイムに更新されるグラフなどが予め可視化されていて簡単に確認出来るのは結構嬉しい。
あとでデータの取り方を調べて弊社内のリソース監視に統合しないと行けないって考えると結構大変ですが。。。
また、以下のスクリプトを利用することでコマンドラインベースの運用も可能です。
出力はJSON形式なので管理者の方々はGUIが使えない時のために慣れておくと良いです。
root@couch-test01 ~]# /opt/couchbase/bin/couchbase-cli help
couchbase-cli - command-line cluster administration tool
CLUSTER:
--cluster=HOST[:PORT] or -c HOST[:PORT]
OPTIONS:
-u USERNAME, --user=USERNAME admin username of the cluster
-p PASSWORD, --password=PASSWORD admin password of the cluster
-o KIND, --output=KIND KIND is json or standard
-d, --debug
-s, --ssl uses SSL for communication with secure servers
NOTE:
USERNAME can be set in environment variable CB_REST_USERNAME and/or
PASSWORD can be set in environment variable CB_REST_PASSWORD instead
COMMAND:
bucket-compact compact database and index data
bucket-create add a new bucket to the cluster
bucket-delete delete an existing bucket
bucket-edit modify an existing bucket
bucket-flush flush all data from disk for a given bucket
...(長過ぎるので割愛)...
デメリットは今のところ以下の様な感じでしょうか。。。検証が進むと増える恐れがあります。
- Enterprise向けらしいのである程度大規模な構成からスタートしないとメリットが出ない。
- 他サイトの比較を見る限りレスポンス速度自体はMemcachedのほうが速い。
- どうも公式に乗っているドキュメントにデメリットみたいのが載っていないのが気になる。
- Memcachedに比べるとどうしても一般的なノウハウは少ない。公式の英語ドキュメントを頑張って読みましょう。
- でも読んでてもう少しわかりやすく書いて欲しい面もある。
- Memcached互換のBucketを作成・削除する際に、そのBucket周りの動作が不安定なことがある。（再現性はなし）
予告
後編では、実際にデータベースにクエリ(NiQL)を発行してみたり、
PHPに組み込んでアクセスログ解析を試行した際のテストコードを公開していきます。