計画概要

趣旨

Droongaの実用性を高めるための開発プロジェクト。

目標

as-isでDroongaを導入・運用できる。

具体化された目標

追記型の設定のDroongaクラスタを構築して、Wikipediaのデータを投入し、全文検索できる。 また、そのような形で運用できる。

運用形態のプラン

3つの指標がある。

• 性能。検索のスループット（qps）が高いこと。
• コスト。サーバの台数が少なく済むこと。
• 運用のしやすさ。見通しがよい、粗結合な構成であること。

これらのどれを優先するかによって、3つの運用形態案がある。

共通要素

[192.168.X.11, id:0〜99   ] [192.168.X.12, id:0〜99   ]
[192.168.X.21, id:100〜199] [192.168.X.22, id:100〜199]
[192.168.X.31, id:200〜299] [192.168.X.32, id:200〜299]
...

このような構成で、検索用のDroonga Engineノード群を用意する。 レコード数が増えてきた時は、X.41とX.42を1組として追加する。

A案：運用の簡単さとコストの低さを優先するパターン

デメリットとして、スループットが低いと予想される。

+------------------+ +------------------+    +--------------------+
|192.168.X.11      | |192.168.X.12      | ← |LVS                 |
|[D.E. id:0〜99]   | |[D.E. id:0〜99]   |    |・各ノードの死活監視|
|[P.A.]            | |[P.A.]            |    |・リクエストを      |
+------------------+ +------------------+    |  各ノードに振り分け|
+------------------+ +------------------+    +--------------------+
|192.168.X.21      | |192.168.X.22      |
|[D.E. id:100〜199]| |[D.E. id:100〜199]| → Webアプリサーバへ直接レスポンス
|[P.A.]            | |[P.A.]            |
+------------------+ +------------------+
...

• 各ノードはProtocol Adapter、masterプロセス、workerプロセスを兼任する。
• masterプロセスがCPU資源を消費するために、 workerプロセスによる検索のスループットが上がらない可能性がある。

B案：運用の簡単さとスループットの高さを最優先するパターン

デメリットとして、コストが高い。

+------------------+    +-------------------------+    +----------+
|192.168.X.11      | ← |192.168.X.101[D.E.][P.A.]| ← |LVS       |
|[D.E. id:0〜99]   | → |・masterプロセスとして   |    |・死活監視|
+------------------+    |  リクエストを           |    +----------+
+------------------+    |  各ノードに振り分け     |
|192.168.X.12      |    +-------------------------+
|[D.E. id:0〜99]   |    +-------------------------+
+------------------+ ← |192.168.X.102[D.E.][P.A.]| → Webアプリサーバへ
+------------------+ → +-------------------------+
|192.168.X.21      |    ...
|[D.E. id:100〜199]|
+------------------+
+------------------+
|192.168.X.22      |
|[D.E. id:100〜199]|
+------------------+
...

• masterプロセス専用のノード群を用意する。
• masterプロセス専用のノードが出来るため、A案よりは性能が出ることが期待される。

C案：スループットの高さとコストの低さを優先するパターン

デメリットとして、運用に手間がかかる。

+------------------+    +-------------+    +----------+
|192.168.X.11      | ← |192.168.X.101| ← |LVS       |
|[D.E. id:0〜99]   | → |[D.E.][P.A.] |    |・死活監視|
+------------------+    |[Webアプリ]  |    +----------+
+------------------+    +-------------+
|192.168.X.12      |    +-------------+
|[D.E. id:0〜99]   | ← |192.168.X.102| → クライアントへ
+------------------+ → |[D.E.][P.A.] |
+------------------+    |[Webアプリ]  |
|192.168.X.21      |    +-------------+
|[D.E. id:100〜199]|    ...
+------------------+
+------------------+
|192.168.X.22      |
|[D.E. id:100〜199]|
+------------------+
...

• B案の派生。
• B案でmasterプロセスのCPU資源に余裕があるのであれば、この構成が可能となる。
• そこそこのスループットを達成できそう。
• アプリケーションサーバも含めたサーバの台数は最も少なくなる（コスト面でのメリットが大きい）
• アプリケーションサーバとmasterプロセスのサーバが一体になるため、 CPU資源を大量に使うアプリケーションの場合はこの構成は取れない。
• アプリケーションサーバとAPIサーバが密結合になるため、運用が煩雑になる。 （職人が一つ一つ手作業で管理するとか、職人技によって作られたChefのレシピがあるとか、そういう形になりうる）

進め方

開発開始前の段階

• きちんとした追記型のクラスタの設定は、現在はできない。
• ノードの追加を伴わないで、最初からあるスライス群にデータを投入して パフォーマンスを計測するに留める。

ある程度開発が進んだ段階

ある程度開発が進んだ時点で、A〜Cのどの運用方針をターゲットとして後の開発を進めるかを決める。 （どの方針も実用的ではないという結論に至る可能性もあるので注意する）

また、ベンチマークでは各ノードについて以下の状況を監視する。

• CPU資源
• メモリ資源 →メモリを32GB積んだマシンを1台調達するのと、8GB積んだマシンを4台調達するのとどっちがいいのかといった判断を下すための材料に出来る。
• ネットワーク帯域 →あまりに消費が激しいようならSuperStepの実装も本格的に考える必要がある。

運用方針を絞り込んだ後の段階

運用方針を絞り込んだら、その方針の下での導入や運用を楽にするための周辺機能の開発を行う。

• Disk Full、Slice Fullなどの警告は何か既存の監視専用のツールとの連携を前提とする。 （例えば、Muninプラグインを提供するのみにとどめるなど。）
• Droonga自体では、各種警告の通知は今のところはやらない。

Droongaプロジェクトの責任範囲について

• Droongaとしては、以下を要件と定める。
  • Disk Fullなどについて適宜警告を上げることができる。
  • どの役割のノードであるかを指定された新しいノードが追加された時に、それを受け入れることができる。
• Droongaクラスタを抽象化してクラウドっぽく見せるのは、GCSなど別プロジェクトの役割とすし、Droongaでは行わない。