読者です 読者をやめる 読者になる 読者になる

てっくめも

主に技術的なことをつらつらと

Droonga Meetup 1 参加レポート

Groonga

2014/7/30 に開催されたDroonga Meetup 1の参加レポートです

前半

  • Droongaクラスタ
    • Droongaノードが複数ぶら下がるイメージ
  • Groongaと互換性がある
    • httpコマンドが同じものを使える

データベースを分散

今現在得られるメリット

クラスタ構成の変更

  • コマンドラインで行う
    • joinさせると、自動的にデータを取得して、準備ができたらノードとして加わる

Droongaのインストール

  • apt-get ではインストールできない
    • インストール方法はサイト参照
  • 各ノードに同じJSONファイルを用意する必要がある
    • どこかで作ってコピるとか

デメリット

Groongaとの性能比較

  • まだGroongaのほうが性能がたかい
    • オーバーヘッドが大きいため

今わかっている遅くなる理由

  • ドリルダウンがあると遅くなる
  • レスポンスのサイズが大きくなると遅くなる
  • クラスタ構成に合わせた処理の最適化が不十分

互換性

  • スキーマ変更系
  • load, delete
    • —ifexists 未対応
  • select
    • 但し検索の細かい部分は未対応
  • 上記以外は未対応

Groonga管理画面がそのまま使える

  • 一部未対応ではあるが

内部データ通信はfluentd互換のプロトコル

  • fluentdでengineに直で投げるのが一番早い
    • droonga-clientがそこをやってる
      • groonga-clientとは使い勝手が全然違う

まだ死活監視などはできていない

  • バランサとかで。

Groonga互換の場合、catalog.jsonスキーマと誤差が出てしまう

  • バルクのloadはない
    • 必ず1コマンド1データの登録
      • パーティショニングを意識している。
  • 更新はほぼ同時に各ノードに伝搬される
  • 複数ノードに別々にデータを更新すると、サーバごとにデータが異なってしまう可能性がある
  • ソート順を指定しない場合、各ノードで結果が異なる場合がある

    • データが登録された順番になるため
  • 各ノードがjobキュー持っているのでworkerが順次処理する

    • ので、1台だけ負荷が上がっていてその場でさばけなくても、負荷が下がれば順次処理される

Droonga移行後の世界

運用方法

死活監視

HTTPサーバ
  • 一番ユーザーに近い
    • ここで正常動作を確認
  • n台構成推奨

  • 実態はただのプロキシ

  • 観点

    • HTTP話せるか
      • /をGETして200かどうか
    • プロキシできているか
      • 検索して結果が返ってくればOK
エンジンクラスタ

クラスター内にnレプリカが存在している

  • 低:100%サービス利用可
    • 2つ以上のレプリカが生存
      • 構成を考慮した死活チェックが必要
  • 中:構成変更中の書き込み不可
    • 1つ以上のレプリカが生存
      • 検索してヒットするか監視
  • 高:
エンジン
  • データを持ち、処理する
  • 1エンジンnワーカー
  • 自律的に構成変更を検知

監視しなくて良い

レプリカの数が減っているかどうかを見る

パフォーマンス監視

監視項目
  • 検索時間

    • スロークエリを発見
  • キャッシュヒット率

    • 検索処理の削減
  • CPU使用率

監視方法
  • 検索時間
    • アプリケーション側で計測
  • キャッシュヒット率
    • /statics/cache をみる
  • CPU

    • muninとか
  • クエリーログは未実装

CPU使用率

  • HTTP
    • 数を増やして負荷分散
  • エンジン
    • CPUのコア数までワーカーを増やす
    • リクエスト受信エンジンを分散
      • ルーティングが重いらしい

クラスター構成の変更方法

  • シャーディングはレプリカごとに設定可能
    • 動的に設定できる
  • 構成変更などは運用中に可能

特有の機能

  • 多段ファセット
    • 制限はない。当然負荷かかるけど。
  • ファセット内のレコードを取得

今後の開発

  • Groongaとの互換性強化
  • 検索処理の高速化
  • 導入の簡易化
    • パッケージの提供
    • Chefとの連携
  • 運用支援機能の開発
    • ダッシュボード
    • リクエスト受信エンジンを自動で負荷分散

まとめ

  • GroongaからDroongaの移行は簡単。
  • 但し、Groongaの機能すべてをそのまま使えるわけではないので、アプリの作りによっては厳しい。
  • Droongaの方がまだ性能出ない。