Droonga Meetup 1 参加レポート
2014/7/30 に開催されたDroonga Meetup 1の参加レポートです
前半
- Droongaクラスタ
- Droongaノードが複数ぶら下がるイメージ
- Groongaと互換性がある
- httpコマンドが同じものを使える
データベースを分散
- レプリケーション
- こちらに注力
- パーティショニング
- こちらは一部
今現在得られるメリット
- レプリケーションができる
- ノードの追加・削除が簡単にできる
クラスタ構成の変更
- コマンドラインで行う
- joinさせると、自動的にデータを取得して、準備ができたらノードとして加わる
Droongaのインストール
- apt-get ではインストールできない
- インストール方法はサイト参照
- 各ノードに同じJSONファイルを用意する必要がある
- どこかで作ってコピるとか
デメリット
- レイテンシーが低下する
- Groonga非互換の部分もある
Groongaとの性能比較
- まだGroongaのほうが性能がたかい
- オーバーヘッドが大きいため
今わかっている遅くなる理由
- ドリルダウンがあると遅くなる
- レスポンスのサイズが大きくなると遅くなる
- クラスタ構成に合わせた処理の最適化が不十分
互換性
- スキーマ変更系
- load, delete
- —ifexists 未対応
- select
- 但し検索の細かい部分は未対応
- 上記以外は未対応
Groonga管理画面がそのまま使える
- 一部未対応ではあるが
内部データ通信はfluentd互換のプロトコル
- fluentdでengineに直で投げるのが一番早い
- droonga-clientがそこをやってる
- groonga-clientとは使い勝手が全然違う
- droonga-clientがそこをやってる
まだ死活監視などはできていない
- バランサとかで。
Groonga互換の場合、catalog.jsonのスキーマと誤差が出てしまう
- バルクのloadはない
- 必ず1コマンド1データの登録
- パーティショニングを意識している。
- 必ず1コマンド1データの登録
- 更新はほぼ同時に各ノードに伝搬される
- 複数ノードに別々にデータを更新すると、サーバごとにデータが異なってしまう可能性がある
ソート順を指定しない場合、各ノードで結果が異なる場合がある
- データが登録された順番になるため
各ノードがjobキュー持っているのでworkerが順次処理する
- ので、1台だけ負荷が上がっていてその場でさばけなくても、負荷が下がれば順次処理される
Droonga移行後の世界
運用方法
死活監視
HTTPサーバ
- 一番ユーザーに近い
- ここで正常動作を確認
n台構成推奨
実態はただのプロキシ
観点
- HTTP話せるか
- /をGETして200かどうか
- プロキシできているか
- 検索して結果が返ってくればOK
- HTTP話せるか
エンジンクラスター
クラスター内にnレプリカが存在している
- 低：100%サービス利用可
- 2つ以上のレプリカが生存
- 構成を考慮した死活チェックが必要
- 2つ以上のレプリカが生存
- 中：構成変更中の書き込み不可
- 1つ以上のレプリカが生存
- 検索してヒットするか監視
- 1つ以上のレプリカが生存
- 高：
エンジン
- データを持ち、処理する
- 1エンジンnワーカー
- 自律的に構成変更を検知
監視しなくて良い
レプリカの数が減っているかどうかを見る
パフォーマンス監視
監視項目
監視方法
- 検索時間
- アプリケーション側で計測
- キャッシュヒット率
- /statics/cache をみる
CPU
- muninとか
クエリーログは未実装
- HTTP
- 数を増やして負荷分散
- エンジン
- CPUのコア数までワーカーを増やす
- リクエスト受信エンジンを分散
- ルーティングが重いらしい
クラスター構成の変更方法
- シャーディングはレプリカごとに設定可能
- 動的に設定できる
- 構成変更などは運用中に可能
特有の機能
- 多段ファセット
- 制限はない。当然負荷かかるけど。
- ファセット内のレコードを取得
今後の開発
- Groongaとの互換性強化
- 検索処理の高速化
- 導入の簡易化
- パッケージの提供
- Chefとの連携
- 運用支援機能の開発
- ダッシュボード
- リクエスト受信エンジンを自動で負荷分散
まとめ
- GroongaからDroongaの移行は簡単。
- 但し、Groongaの機能すべてをそのまま使えるわけではないので、アプリの作りによっては厳しい。
- Droongaの方がまだ性能出ない。
