GREE Engineering

HaskellのPersistentライブラリのZooKeeperバックエンドの開発

HaskellのPersistentライブラリのZooKeeperバックエンドの開発

こんにちは!インフラストラクチャ本部の橋本です。

このエントリは GREE Advent Calendar 2014 12日目の記事です。

読者のみなさまの一助となる知見が少しでも提供できれば幸いです。

はじめに

HaskellのO/RマッパーであるPersistentのZooKeeperバックエンドを開発しました。

Persistentのいいところは以下のようになります。

  1. HaskellのデータとDBのデータの変換が自動(O/Rマッパなので当たり前ですね。)
  2. 型安全に加えて、構造的に安定(DB[“user”]とか文字列でDBから値をとってくることはできません。クエリでも同様です。)
  3. コネクションがプールされます
  4. SQLだけでなくNoSQLも扱えます
  5. よく使われています(Yesodのフレームワークに組み込まれていることが大きいと思います。)

開発の動機は、以下の通りです。

GreeではKVS(Flare)のクラスタマネージメントのためZooKeeperを使っています。
上記マネージメントシステムはユーザ向けapi-server(Yesod+Persistent)をもっています。
api-serverのPersistentのバックエンドはSQLiteでした。
冗長構成をとるためバックエンドをMySQLやMongoDBを新しく立ててもよかったのですが、
KVS(Flare)以外のデータベースを別に管理したくなかったため、PersistentのZooKeeperバックエンドを開発しました。

開発にあたり、
https://github.com/yesodweb/persistent
のライブラリはもちろんのことRedisバックエンド
https://github.com/yesodweb/persistent/tree/master/persistent-redis
(作者はHaskell Financial Data Modeling and Predictive Analyticsの本の方です。)
を参考にしました。

開発は手探り状態でしたが、その経過をご報告します。

ZooKeeperに繋げましょう(PersistConfigを実装)

ZooKeeperにコネクションを開いて、そのハンドルを後の処理にわたすだけのはずなのですが、つなげるところが難しい(わかりにくい)です。
ZooKeeperにつなぐためにPersistConfigの実装が必須なのですが、PersistConfigの定義は以下の通りで、
Persistentのドキュメントやコードを見てみましたが、
開発当初の僕にはまったく意味不明でした。

特に重要そうな”(* -> *) -> * -> *”がわかりません。
実際には”(ReaderT -> (バックエンドのハンドル)) -> モナド -> 戻り値”な感じで使われます。
Haskellなのに全然型は現れてこないですね。

そこで、persistent-redisの実装を見ました。
http://hackage.haskell.org/package/hedis-0.6.5/docs/src/Database-Redis-Core.html
をみるとどうやら
createPoolConfigでPersistConfigPool cとなっているところをData.PoolのPool型で返して、
runPoolでPool型のデータとDBのアクション(PersistConfigBackend c m a)を渡して結果を戻せばいいことが分かりました。
ほとんどpersistent-redisの実装をコピペして
https://github.com/yesodweb/persistent/blob/master/persistent-zookeeper/Database/Persist/Zookeeper/Config.hs
を作りました。Z.connectのところはhzkパッケージの
https://github.com/dgvncsz0f/hzk/blob/master/src/Database/Zookeeper/Pool.hs

のconnectでData.PoolのPool型が戻ります。やりたいことはシンプルなのですが、型が分かりにくいですね。

とりあえずPersistStoreとPersistUniqueのモックをつくりましょう

型を合わせるのは難しいですし、はじめから全部作るのは大変です。
定義しないといけない関数も多いし、むずかしそうだなと思っていましたが、
他のバックエンドを見るととerrorとかfailとかで実装されてないコードが入っています。
はじめはとりあえずerror “not support”って書いて、あとで中身を書きました。

ビルドして、Yesodに組み込んでみましょう

バックエンドの切り替えは、YesodのファイルのModel.hsのファイルの

となっているところを

にします。
ConTはTemplate-Haskellのものらしいですが、なぜ必要なのかよく分かってません。

次に、

となっているところを

にします。これでビルドは通るようになります。(まだ実装してないので動かないです。)

PersistStoreとPersistUniqueの実装

get、insert、deleteといった操作にPersistStoreの実装が必要です。
PersistStoreの定義は以下の通りですが、
一見するとgetやinsertの中のモナドでテーブル名を引く方法がわかりません。

PersistEntityからテーブル名を引く方法もpersistent-redisから借用しました。
以下の通りです。

PersistEntity valからテーブル名を引く方法です。

PersistEntity val => Key valからテーブル名を引く方法です。
dummyFromKeyを使いますが、実際にはvalのところは評価されないので、これでテーブルの名前を引くことができます。

次にZooKeeperにデータをいれるためのキーを何にするのか決める必要があります。
PersistStoreのinsertは同じキーの重複を許しますが、PersistUniqueのinsertByでは許しません。

KVSなので妥協が必要になります。

  1. エンティティにプライマリキーがある場合と無い場合
  2. エンティティにユニークなキーがある場合と無い場合

これらのケースを考えて、下記の表にしたがってキーをエンティティから取り出してZooKeeperのキーを作成しました。

ユニークキー有 ユニークキー無
プライマリーキー有 ユニークキー プライマリーキー
プライマリーキー無 ユニークキー 連番キー(番号はZooKeeperが発行)

PersistQueryの実装(掃除はどうしましょうか)

PersistStoreにはキーを列挙する機能はありません。このままでは期限切れのデータやいらなくなったデータがいつまでも残ってしまいます。
キーをリストアップして掃除するにはPersistQueryの実装が必要です。
PersistQueryにはFilter(条件文みたいなもの)とSelectOpt(Orderby,Limitといったもの)という型安全なwhere文があります。
削除ではFilterだけ実装すればいいですが、残念ながらZooKeeper自体にはまったく条件文相当の機能がなく、persistent-redisにもないので困りました。

しかし、Filterの値からSQLのクエリをつくる関数があったので、
https://github.com/yesodweb/persistent/blob/master/persistent/Database/Persist/Sql/Orphan/PersistQuery.hs#L239
それをもとに値をフィルタできる関数(filterClause)を作りました。
https://github.com/yesodweb/persistent/blob/master/persistent-zookeeper/Database/Persist/Zookeeper/Query.hs#L118

これで以下のような削除(deleteWhere)が書けました。

persistent-testへの対応(テストは充分なの?)

persistent-testで他のバックエンドとの互換性が確保されています。
KVSでこのテストを行っているのはpersistent-mongoDBだけでしたので、persistent-mongoDBのテストを元にpersistent-testに対応しました。
はじめは2/60個しか通らず以下の問題がありました。

  1. insertKey(プライマリキーがIDでないケース)のバグ
  2. deleteWhereのバグ
  3. SelectOptの未実装
  4. idの問題

1,insertKey(プライマリキーがIDでないケース)のバグは、

ユニークキー有 ユニークキー無
プライマリーキー有 ユニークキー 連番キー(ここ間違い)
プライマリーキー無 ユニークキー 連番キー

とつくっていたことが問題でした。テストで見つかってよかったです。

2,deleteWhereのバグは、テーブルがないときに実行すると例外が飛ぶようになっていたことが問題でした。他のバックエンドに合わせて例外が出ないようにしました。

3,SelectOptはselect文のwhereのOrderbyやLimitに対応します。テストから除いてもよかったのですが、SelectOptの実装をしました。値にしたがって結果をソートする関数を用意しました。実装がリストのリストをソートしているのは複数のOrderbyに対応するためです。
https://github.com/yesodweb/persistent/blob/master/persistent-zookeeper/Database/Persist/Zookeeper/Query.hs#L247

4,idの問題はSQLのauto incrementのidやmongoDBのobjectIDに相当するものがZooKeeperにはないことが原因です。実装できないのでテストをスキップしました。

無事、手元でpersistent-testをパスしました。

Travis CI

しかし、Travis CIでpersistent-testはほとんどFailしました。
原因は、Travis CIのpreciseで立ち上げるZooKeeperのmax clientの設定が10だったこととlibzookeeperのバグでした。

preciseで入るlibzookeeperのバージョンが3.3.5なのですが、create(libzookeeperのAPI)で戻ってくるパスに深刻なバグがあります。これです。
https://issues.apache.org/jira/browse/ZOOKEEPER-1027
作ったノードのパスが戻ってこない問題です。createしたときのキーが関数から戻ってきません。特に連番のキーを作った場合にどこのキーに入ったか分かりません。
どうしようもないので、ppaからlibzookeeperの3.4.5のライブラリをインストールするように直しました。

最後に

無事にZooKeeperをPersistentのバックエンドにでき、本家にマージされました。
(persistent-testをZooKeeper用にカスタマイズしたのでメンテナンスがやりやすくなるため、うれしいです。)
本開発にあたり素晴らしいパッケージを提供してくれたhzk、persistent、persistent-redis、persistent-mongoDBの開発者のみなさんに感謝します。

ところで、git-annexはhaskellでかかれているのですが、拙作のs3のmultipart uploadがサポートされました。
この話は別の機会にできたらいいです。

Haskellに興味をもっていただけると幸いです。

明日は山本さんによるグリーのQA(品質保証)とその背景の技術の記事です。お楽しみに!

関連記事