先日の、「 2012-01-04Sekka* [Sekka]を公開サービスにするという思考実験(サービスイメージ)」というエントリの続き。 今回はsekka-serverをホスティングする側のアーキテクチャをどうするかを書いてみたいと思う。

データベース(案1)

Redisで1台のサーバでスループットの総量を確保する。 最初はメモリを1GByte程度用意しておけば、数人程度のユーザ辞書は入るだろう。 スケールしたくなった時は、Redis clusterを使う。

データベース(案2)

Amazon SimpleDBで最大容量と最大処理量を確保する。 処理量とユーザー辞書容量はSimpleDB側で自動的にスケールする。30から50ユーザーくらいは収容できるのではないかな？

課題は、SimpleDBには1024byte以上のvalueが保存できないという制限があるので、sekka-serverを変更しないといけないことだろう。

Rack

sekka-serverはRackで動いてるが、こちらもスケールする必要がある。 一番CPUリソースを使う処理は曖昧文字列検索なので、そこがスケールアウトする必要があるだろう。 sekka-serverのサーバ台数を増やす、またはCPUコアが多いマシンにスケールアップして対応する。

ユーザー用管理ページ

フレームワークはRailsかSinatra データベースは何らかのRDBで良いのではないかと思う。 機能は辞書の登録状況と、登録状況のリセットのみ。 ユーザー語彙のマスターデータはユーザーのローカルマシンに ~/.sekka-jisyoとして持っているので、問題があればホスティング側は何度でもリセットすることもできる。

ここまで書いてみて、大袈裟かなー、そこまで使われるかなー、というのが正直な感想。

そこまでしなくても、公開サイトは自分のローカルにsekka-serverをインストールする前にデモ的に使うためのものにするというのが落としどころか。 それなら、何の認証も無い状態でsekka-serverのデモをWebAPIで公開するというのが実は落としどころかな。 インストールが面倒という問題は、sekka-server専用のVirtualBox仮想マシンイメージで公開するというのがいいのかも…

思考実験をしてみると、スケールするにはまだ考慮が足りないという事実と、実際にスケールさせるためにはかなりランニングコストがかかりそうという事実がわかってくる。 なかなか難しい。