Droongan移行後の世界¶ ↑
: author
須藤功平
: institution
株式会社クリアコード
: content-source
Droonga Meetup 1
: date
2014/07/30
: allotted-time
30m
: theme
.
目指すこと¶ ↑
Droonga移行後のn システムをn 想像できること
話題¶ ↑
* 運用方法(('note:(重点的に説明)')) * 特有の機能(('note:(軽く説明)')) * 今後の開発(('note:(軽く説明)'))
質疑応答時間アリ¶ ↑
* 気になったら… * メモ→最後に質問 * その場で質問 * 気になることは聞いて欲しい * 何が気になるか知りたい
話題1¶ ↑
* ((*運用方法*)) * 特有の機能 * 今後の開発
運用方法¶ ↑
* 死活監視 * パフォーマンス監視 * ノード構成の変更方法
死活監視¶ ↑
* システムが正常動作しているか\n 継続的に確認 * →システムの構成要素は? * →正常動作とは? * Droongaの場合 * クラスターの構成要素は? * それぞれの提供サービスは?
Droongaクラスター¶ ↑
# image # src = images/droonga-system.svg # relative-height = 100
ポイント¶ ↑
* SPOFなし * 管理ノードなし * すべてのエンジンは同列 * 管理情報はすべてのエンジンが持つ * ユーザーはHTTPでアクセス
HTTPサーバー図¶ ↑
# image # src = images/droonga-http-server.svg # relative-height = 100
HTTPサーバー¶ ↑
* 1番ユーザーに近い * ここで正常動作を確認 * →Droongaクラスターは正常動作 * n台構成推奨 * 冗長化・負荷分散 * ロードバランス対象
HTTPサーバー:役割¶ ↑
* HTTPのAPIを提供 * 実体はプロキシ * バックエンドは\n Droongaエンジンクラスター * プロトコルを変換 * データを持っていない
HTTPサーバー:監視図¶ ↑
# image # src = images/droonga-http-server-monitor-items.svg # relative-height = 100
HTTPサーバー:監視項目¶ ↑
* HTTPを話せるか? * 基本的な監視 * "/"をGETして200か監視 * プロキシできているか? * 詳細な監視 * 検索してヒットするか監視
HTTPサーバー:監視効果¶ ↑
* HTTPを話せるか? * サービスは生きている * 役割を果たしているとは限らない * プロキシできているか? * 役割を果たしている * 実現方法はデータに依存
HTTPサーバー:監視効果図¶ ↑
# image # src = images/droonga-http-server-monitor-items.svg # relative-height = 100
エンジンクラスター図¶ ↑
# image # src = images/droonga-engine-cluster.svg # relative-height = 100
エンジンクラスター¶ ↑
* エンジンが連携して動作 * クラスター内にnレプリカ存在 * 障害度合いとサービスレベル * 低: 100%サービス利用可 * 中: 構成変更中の書き込み不可 * 高: サービス不可(参照も不可)
監視項目¶ ↑
* 2つ以上のレプリカが生存? * 障害度合い:低(('note:(100%サービス利用可)')) * 構成を考慮した死活チェック * 1つ以上のレプリカが生存? * 障害度合い:中(('note:(構成変更中の書き込み不可)')) * 検索してヒットするか監視
監視効果¶ ↑
* 2つ以上のレプリカが生存? * 障害なし or * サービスレベル低下なしで復旧可能 * 1つ以上のレプリカが生存? * サービスは提供できている * サービスレベル低下するが復旧可能
監視効果図¶ ↑
# image # src = images/droonga-engine-cluster-monitor-items.svg # relative-height = 100
エンジン図¶ ↑
# image # src = images/droonga-engine.svg # relative-height = 100
エンジン¶ ↑
* データを持ち、処理する * 1エンジンnワーカー * マルチプロセス * 自律的に構成変更を検知 * 管理ノードなし * あるエンジンがダウンしたら\n 自分が持つクラスター情報を更新
監視項目¶ ↑
* 監視しなくてよい * エンジンクラスター監視で十分
死活監視のおさらい¶ ↑
* 目的 * システムの正常動作を確認 * システムの構成要素 * HTTPサーバー(('note:(監視対象)')) * エンジンクラスター(('note:(監視対象)')) * エンジン
Droongaクラスター¶ ↑
# image # src = images/droonga-system.svg # relative-height = 100
HTTPサーバーの監視¶ ↑
# image # src = images/droonga-http-server-monitor-items.svg # relative-height = 100
エンジンクラスターの監視¶ ↑
# image # src = images/droonga-engine-cluster-monitor-items.svg # relative-height = 100
死活監視¶ ↑
* HTTPサーバー * HTTPの機能をチェック * プロキシの機能をチェック * エンジンクラスター * 生存レプリカ数をチェック * エンジン * 死活監視しなくてよい
運用方法:死活監視¶ ↑
* ((*死活監視*)) * パフォーマンス監視 * クラスター構成の変更方法
パフォーマンス監視¶ ↑
* 死活監視 * ((*パフォーマンス監視*)) * クラスター構成の変更方法
パフォーマンス監視¶ ↑
* 監視項目 * 監視方法
監視項目¶ ↑
* 検索時間 * 目的:スロークエリを発見 * キャッシュヒット率 * 目的:検索処理の削減 * CPU使用率 * 目的:ボトルネックの解消
監視方法¶ ↑
* 検索時間 * アプリケーション側で計測 * キャッシュヒット率 * "/statistics/cache"をGET * CPU使用率 * 既存の統計情報可視化ツール * 例:Munin
検索時間:計測場所と粒度¶ ↑
* アプリケーション * 全体の時間 * HTTPサーバー * Droonga側の処理全体の時間\n (('note:(X-Response-Time HTTPヘッダー)')) * エンジン * 各処理の時間\n (('note:(クエリーログ:未実装)'))
キャッシュヒット率¶ ↑
((‘tag:center’)) …/statistics/cache
# coderay json { "nGets": 8, "nHits": 6, "hitRatio": 0.75 }
CPU使用率¶ ↑
* ボトルネックはCPUになるはず * HTTPサーバーの場合 * 数を増やして負荷分散 * エンジンの場合 * CPUのコア数までワーカーを増やす * リクエスト受信エンジンを分散
HTTPサーバーの負荷分散¶ ↑
# image # src = images/droonga-http-server-cpu-performance.svg # relative-height = 100
エンジンの負荷分散¶ ↑
# image # src = images/droonga-engine-cpu-performance.svg # relative-height = 100
おさらい¶ ↑
* 目的 * 高速化 * ボトルネックの解消 * 監視項目 * 検索時間(('note:(ボトルネックの解消)')) * キャッシュヒット率(('note:(高速化)')) * CPU使用率(('note:(ボトルネックの解消)'))
構成変更¶ ↑
* 死活監視 * パフォーマンス監視 * ((*クラスター構成の変更方法*))
Droongaクラスターの構成図¶ ↑
# image # src = images/droonga-engine-cluster-data-architecture.svg # relative-width = 100
Droongaクラスターの構成¶ ↑
* シャーディング構成 * レプリカ毎に設定可 * シャーディング構成変更 * 運用しながら変更可 * レプリカの増減 * 運用しながら変更可
構成変更の基本作戦図¶ ↑
# image # src = images/droonga-engine-cluster-change-architecture.svg # relative-height = 100
構成変更の基本作戦¶ ↑
* レプリカを1つ外す * ↑からデータをダンプ * ↑を新しいレプリカに投入 * 外したレプリカを戻す * 新しいレプリカを追加
運用方法のおさらい¶ ↑
* 死活監視 * 構成要素毎に紹介 * パフォーマンス監視 * 項目と目的を紹介 * クラスター構成の変更方法 * 特徴と流れを紹介
特有の機能¶ ↑
* 運用方法 * ((*特有の機能*)) * 今後の開発
特有の機能¶ ↑
* 多段ファセット * Solrでいうピボットファセット * Elasticseachでいうaggregations * ファセット内のレコードを取得 * 利用例:スレッドでグループ化し、\n 各スレッド内のコメントを数件表示
今後の開発¶ ↑
* 運用方法 * 特有の機能 * ((*今後の開発*))
今後の開発1¶ ↑
* Groongaとの互換性強化 * 未実装の機能を実装 * よく使われている機能から順に * 検索処理の高速化 * 通信量を減らす * ルーティング周りの処理の軽量化
今後の開発2¶ ↑
* 導入の簡易化 * パッケージの提供 * Chefとの連携 * 運用支援機能の開発 * ダッシュボード * リクエスト受信エンジンを\n 自動で負荷分散
まとめ¶ ↑
* 運用方法 * 監視・構成変更方法 * 特有の機能 * Groongaのコアができることを解放 * 今後の開発 * いろいろ * ユーザーの声を考慮して優先度決定