さて信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計
前エントリのブコメなどでもKVSでいいんじゃね？ってあった。
たしかに分散KVSは素晴らしい発明品だと思う。しかしながらRDBと同じように使ってはいけないしRDBの代替と考えてもいけない。
「KVSでいいんじゃね？」ってなノリで導入すると痛い目を見る。
RDBはよくできた製品である。RDBを正しく設計して使えば良いのだ。
RDBには人類がこの数十年で蓄積した沢山のノウハウがある。
KVSをやってみるとRDBの素晴らしさを改めて再認識することが多々あるだろう。
僕らは検討中、何度となく「RDBでいいんじゃね？」と口にした。
とは言えKVSも面白く、意義深い。要は使い分けである。
自分で言っていながらなんと多方面に気を使った回りくどいエントリだろう。
はじめに 分散KVSとは何か？メリットは？
いまさらながら、そもそも分散KVS*1とはというところから始める。
KVSとは"キー"と"値"のペアでデータを管理するデータストアだ。
これだけならMapや連想配列と変わりないのだが「分散」とあるのがポイントで、
サーバを横並びにつなげて1つのデータストアであるかのように見せかけることができ、
容易にサーバーを増設が可能なのだ。
また多くのKVSはデータをメモリ上で保持し続ける為、ディスクI/Oが発生せず高速である。
メリットだけをまとめると以下のようになる。
・スケールアウト（サーバー増設）が容易に可能
・ディスクI/Oの極端な低減
我々のプロジェクトでのKVS導入の背景
KVSのプロダクトはオープンソースでもいくつかあるが、僕らは有償のOracle Coherenceを利用していた。
サービスの内容はあまり詳しく言えないが、KVSを導入しようとしたサービスは以下のようなSLAを持っていた。
・秒間300〜2000の認証が発生
・ユーザ数は1000万
・データ量は1億レコード以上
※ 先日の固定長RDBのサービスとは異なるサービスだ。
KVSは、スケーラビリティーとパフォーマンスとアベイラビリティ（可用性=止まらない事）を求められるサービスで導入されることが多い。
僕らの場合もミッションクリティカル（24×365）なシステムで、さらには二重障害までは耐え切ることがSLAに加えられていた。
KVS導入に伴う苦労というのは、実はSLAの高さ故であるとも言える。
つまり、KVS云々抜きでそもそも難しい要件なプロジェクトでKVSが使われることが多いのであり、
RDBで同じ事をする苦労と比べると技術的な難易度が高まっているとは言い切れない。
はじめに
ということで分散KVS導入に関わって苦労したことを独断で上げたいと思う。
と考えて色々苦労を思い出していたが、ありすぎてちょっと整理がつかなくなった。
ということで、4位〜2位までの分散KVSの”技術的な”苦労ポイントは、またまた先送りして次回とする。
※ Top4のタイトルは釣りとして残すwww。
ちょうど下記のような記事も出ているので、参照してみてほしい。
NoSQLをRDBの代わりに使うと、どういう恐ろしいことが起こるか。PARTAKEの作者が語る － Publickey
分散KVSには「トランザクションの厳密性がないこと」や「検索条件の設定が非常に困難なこと」はよく知られているが、このぐらいのことは、あらかじめ予想もつくレベルではある。
のにもかかわらず、実際に設計すると本当に苦労する。が、細かい話はとりあえず割愛。
さて僕が最も苦労した話をしよう。
（タイトルで釣られた人に対しては、スカシてしまったが）
第1位 ミドルウェアとアプリケーションの垣根がほぼなくなること
KVSを導入するにあたって、もっとも困難だったことは技術的なことではない。
技術的な面では苦労のしがいがあるのではないかと思っている。
先述の通り、KVS導入に伴う技術的な苦労というのは、実はSLAの高さ故であり、そもそも敷居の高い案件だからだ。
ただ、もしかしたら僕らのプロジェクトではCoherenceに強いOracleコンサルさん達が沢山居てくれて、提案から詳細検討まで色々聞けたから技術面で苦労が少なかっただけかもしれないが。
ともかく、新規開発の案件や自社サービスなどのシガラミの少ない案件であれば、
コンシューマ向けサービスにKVSを使うのは理にかなっていると思う。
しかし僕らが参画したプロジェクトのように、歴史のある大規模なサービスにおいてKVSを持ち込もうとすると大変な調整の苦労が発生する。
問題提起したいのは、
「分散KVSは、ミドルウェアでありながらアプリケーションとの垣根がほとんどない。」
ということだ
それに対して、大手のSI企業の開発体制では、インフラとアプリケーションの部隊は異なる事が多い。
なのでKVSのような垣根のない製品が出てくると、誰の管轄なのかで大いにもめるのだ。
ミドルウェアとアプリケーションの両方の性質を持つKVS
KVSに保存されたオブジェクトをバックエンドへ永続化するには、結局ORマッピングのようなコードを自前で書かなくてはならない。
そして、そのORMコードをKVS（僕らの場合Coherence）の起動シェルでクラスパスに通してやって、CoherenceのXMLでロードする設定を書いて。。と
結構手間をかけてマッピングをする。
これらは明らかにアプリケーション開発部隊の仕事の一部である。
ところが製品自体はインフラ・サーバー製品的な要素を強く持っている。
ノード間で生存確認を取りあうために、各ノードは同一セグメントに居なくてはいけないが、
アプリケーションを専門にやっているメンバーからすると、ネットワーク構成など知ったこっちゃない、というか手が出せない領域だ。
サーバーを何台買うべきか？容量の見積りは？どれぐらいのスペックのサーバが必要か？など
やはりサーバーミドルウェアの世界でもある。
実装面は、アプリケーション開発者が担当する。
設定面・キャパシティプランニングは、インフラ構築担当者が担当する。
では、設定ファイルはどうだろう？
僕らのプロジェクトでは、サーバーに配置する全てのファイルに持ち主が決められている。
WeblogicのようなJavaEEサーバの設定ファイルならインフラである。
Oracleの設定もインフラが担当する。DIコンテナのDIファイルならアプリケーションの領域だ。
そうしておかないと、トラブルが発生した時に責任分界点があいまいになる。
多数のSI企業が、大手SI企業の下で請け負って、合同でプロジェクトを進めているから、
責任分界点があいまいだと、障害発生などでお見合い状態になってしまうのだ。
CoherenceのようなKVSの設定ファイルは色んな設定が混在してる。
これを誰が管理するのかは、プロジェクトがスタートしてから問題としてあげられてしまったために大いに紛糾した。
本来は、DBAdministrator(DBA)ならぬKVSAdministrator(KVSA)のような、ポストが必要になるんだろう。
ということで、僕が仕切るミーティングで
常に「誰の持ち物か？」という話題と「そんなのウチでは見積もってないから出来ない。」という話題で、毎日のように揉めたのが、個人的な苦労ポイントの第1位だった。
幸い、300日ぐらいなら徹夜してもへちゃらな漢気のあるメンツが揃っていたため事無きを得たが、そういうメンツがいないプロジェクトでは、体制面をよく考えて導入した方がいいだろう。
つづく
