ミドルウェアのチューニングでは、様々なパラメータを目にし、操作し、検証することになる。
データの特性やリソースなど現在の状況と目標を照らしあわせ、正解に近い値を求める作業だ。
Riakにもパラメータはたくさんある。
しかしそれは、既存のRDBとは異なる概念に基づくものが多い。
ドキュメントなどに書いてある運用に関わるパラメータの一部をまとめただけだが、今まであやふやだった部分を改めて理解しに行くきっかけになれば良いと思う。

物理ノード

クラスタを構成する物理的なマシンの数は、Riakクラスタのキャパシティを決定する大きな要因だ。
数千数万という多数のマシンで構成されたクラスタが機能するかは分からないが、1台ぼっちで動かすよりは多いほうが良いだろう。
後述するn_valのデフォルト設定値が3になっているため、最低3台、本番環境では5台以上での構成が推奨されている。

vnode

Riakは物理ノードをパーティションで更に分けており、それをvnodeと読んでいる。
物理ノード5台で構成されるRiakクラスタのvnode総数が25に設定されていた場合、マシン1台につき5つのvnodeが割り当てられることになる。
例えばある1台が持つvnodeのidは、[1, 6, 11, 16, 21]となる。
Riakは異なる物理ノードに属するvnodeを選定してデータを保存する。
この計算アルゴリズムはConsistent Hashingを呼ばれている。
vnodeを物理ノードで割り切れない時は、物理ノードが受けもつvnode数が一つだけ違う、ということになる。

n_val

vnodeへのデータ複製数を指す。
Consistent Hashingによりデータ保存先のvnodeが決定される際、その数はn_valの設定数に従う。
ここで、n_valは「最終的に」レプリケートされるvnode数ということに注意する必要がある。
変更完了のリプライがあった時点で、その変更がn_val設定値まで伝搬しているわけではない。

w

n_valが最終的にレプリケートされるvnode数なのに対し、wは成功を返す時点のレプリケート数だ。
つまり、wの設定値まで書き込みができれば、成功とみなされるということになる。
なんでレプリケート数でnとwがあるのかというと、ボトルネックをユーザが決められるようにするためである。
当然ながら、書き込みにはI/Oとネットワークに伴うコストが発生する。
クラスタとしてのRiakの応答性を最高にするためには、1台という最小台数にだけデータを書き込ませ成功を返し、それを受け取った時点でアプリケーションは次の処理を行うべきだ。
一方で、データの確実な書き込みを保証するためには、クラスタを構成する全物理ノードにデータを配置する必要がある。
これならデータ損失の確率を最低限にできるが、ネットワークを通してデータを配置する時間は最大になってしまう。
そして、応答と堅牢性、どちらが要求されるかはアプリケーションによって異なる。
どのユースケースにも対応できるよう、Riakは選択をユーザに委ねている。

r

wが書き込みを成功とみなすvnode数であるのに対し、rは読み込みを成功をみなすvnode数である。
r設定数のvnodeから同じvalueを読み込むことができれば、riakは成功とvalueを返す。
もちろん、r設定数が大きければ信頼性は高く、応答は遅くなる。逆もまた然り。
Riakがとっている書き込みと読み込みのバランスは、”結果整合性”というキーワードで表される。
書き込みコストを許容できるのであれば、読み込みは最小ノードでも良いので、読み込みの応答を上げることができる。
極力失ってはならないデータで、整合性も最大限確保しなければならないのであれば、n, w, r全てを最大にする必要があるだろう。
レプリケート数n、書き込み数r、読み込み数wを組み合わせ、アプリケーションとデータの特性に応じた適切なパフォーマンスを発揮させるという考え方を実現するパラメータだ。

まとめ

実際にはさらに多くのパラメータがあるが、最低限考慮すべきパラメータはこれくらいだろう。
要は、どこでリスクを取るかというだ。
そして重要なのは、それを自分で選べるという自由なのだろう。
パラメータを組み合わせ、最適なパラメータを求め続けるという仕事（そして奥の深さ）自体は、NoSQLも典型的なRDBも変わらないのだ。