さくらインターネット研究所の大井です。

7月1日より、研究所にてKVSアルファテストサービスが始まりました。現時点ではKVSをバックエンドに活用した既存のアプリケーションパッケージは非常に少なく、ほとんどの場合は既存のソフトウェアをKVS対応に変更する、もしくはKVSを有効活用できるソフトウェアを最初から作成するものと思います。

そこで、KVSを活用したアプリケーションの例として何かアプリケーションが作れないかと考えてみたところ、最近のTwitter人気で目にする事も多くなったURL短縮サービスを思いついたので、余っていたドメインの有効活用も兼ねて「douj.in」という名称で作成してみました。

1. URL短縮サービス「douj.in」の概要

URL短縮サービス「douj.in」は、任意の長いURLを「http://douj.in/????」の形式で発行するサービスです。????部については、現在はランダムな大小英数字が4文字固定長で生成される設定にしています。長いURLと短いURLの格納用のデータベースとして、KVSアルファテストサービスで提供するKVSサーバを利用しています。

※本サービスは期間限定のKVS実証実験のため、2010年8月末日までの運用となる予定です。期間終了後は発行された短いURLの永続性を保証できませんのでご注意ください。また、期間中でも予告なくサービスを停止する場合がありますのでテスト用途以外でのご利用はお控えください。

1-1. システム構成

まず、douj.inを構成するシステムについて説明します。システムとして構成される要素としては

• データベースとなるKVSサーバ一式
• URL登録フォームや短いURLのホストとなるWebサーバ1台

の2つがあります。このうち、ユーザ側の立場となる私の方で用意したものはWebサーバ1台のみです。KVSサーバ一式はPaaSの形で提供されているため、ユーザ側では何の設定も行う事なく、memcachedプロトコルを通してすぐに使用可能となります。当然のことながら、KVSシステム内部のサーバ構成や負荷制御についても提供者側が対応してくれますので、ユーザはKVSを利用するフロントエンド側に集中することができます。

WebサーバのOSにはCentOSを使用し、PHPとmod_rewriteをモジュールとして組み込んだApacheが動作しています。URL登録スクリプトにはPHPを、mod_rewriteがURL書き換えマップとして使用するデータベースをmemcachedプロトコルで外部に問い合わせするラッパースクリプトにはPerlを使用しています。KVSサーバとのmemcachedプロトコルでの通信はPerlモジュールCache::Memcached::Fastを介して行っています。

また、転送先のURLが隠蔽されてしまうという短縮URL特有の安全性の問題も鑑み、フィッシングサイト登録防止機能として、新規URL登録時にAPI経由でPhishTankのフィッシングサイトデータベースを参照し、リストに存在するURLは登録できないようにする機能も付けました。

1-2. 短いURLにアクセスされた際の流れ

例えば、http://www.sakura.ad.jp/というURLはhttp://douj.in/dCWUという短いURLに変換されています。それでは短いURLにアクセスした際、ブラウザが元の長いURLに転送してページを表示するまでの流れを説明します。

1. ブラウザがdouj.inサーバに対して/dCWUをリクエスト
2. Apacheがmod_rewriteを通して/dCWUのURL書き換えを試行
   1. mod_rewriteがラッパースクリプトに文字列「dCWU」を渡す
   2. ラッパースクリプトがKVSサーバにmemcachedプロトコルでキー「dCWU」のバリューを問い合わせ
   3. KVSサーバはキー「dCWU」のバリュー「http://www.sakura.ad.jp/」をラッパースクリプトに返答
   4. ラッパースクリプトがmod_rewriteに「http://www.sakura.ad.jp/」を返答
3. Apacheはmod_rewriteの書き換えに従い、クライアントにレスポンスヘッダ「Location: http://www.sakura.ad.jp/」を送信
4. ブラウザではLocationヘッダに従い、http://www.sakura.ad.jp/にリダイレクト

このように、KVSにはキーとして短いURLのホスト部以降の英数字の文字列、バリューとして元のURLを格納してURLの変換が行えるようにしています。

1-3. 短いURL登録時の流れ

また、新しくURLを登録した時の流れは以下のようになります。

1. http://douj.in/のURL登録フォームにURLを入力
2. KVSサーバに対し、フォームに入力されたURLをキーとしてバリューを問い合わせ
   1. キーが見つかったらそのバリュー(短いURL)をフォーム画面に表示
   2. キーが見つからなければ新たにKVSに登録
3. PhishTankのAPIを使用し、フィッシングサイト判定
4. 英数字で構成されたランダムな文字列を生成(現在は4文字固定長で設定)
5. KVSサーバに生成されたランダムな文字列とURLを、それぞれキーとバリュー、バリューとキーの組みを登録
6. 生成された短いURLをフォーム画面に表示

登録時は、短いURLアクセス時に使用する「キーに短いURL、バリューに元のURL」の組だけではなく、キーとバリューを逆にした「キーに元のURL、バリューに短いURL」の組も登録しています。KVSではバリューに対する検索を行えないため、バリューが存在するかどうかの確認用としてこのようなレコードも登録しています。これにより、登録時に元のURLをキーとして検索を行い、バリューが取得できるかどうかを確認する事で、同じURLに対して短いURLが重複して発行されないようにしています。

2. バックエンドデータベースのKVS化で感じたこと

今回作成したURL短縮サービスですが、プロトタイプではBerkleyDBをデータベースとして使用していました。mod_rewriteではURL書き換えマップとして直接BerkleyDBファイルを指定可能なため、KVSを利用した本番前の開発環境でテストしやすいという利点があります。

BerkleyDBはKVS同様、キーとバリューの組(ハッシュ)でデータを保存しているため、本番環境向けのコード書き換えはデータベースのアクセス部分のみの変更で済みました。このように、現在BerkleyDBなどのDBM系データベースを使用している場合は簡単に移行する事ができるかと思います。

その上で、BerkleyDBにはない、以下のようなメリットを享受することができます。

• ネットワーク分散機能(多数のホストからひとつのデータベースを参照・更新可能)
• 水平方向へのスケールアウト機能(台数を増やしてデータベース容量や接続数の増加に対応)

特にスケールアウト機能については従来バックエンドとしてしばしば利用されてきたSQLサーバが苦手とする部分であり、Webアプリケーションサーバなどのクラウド化されたフロントエンドに接続する場合に大きな効果を得られそうです。ネットワークの遅延やセキュリティなど、考慮すべき問題も増えてしまいますが、もともとSQLサーバよりも軽量で高速なKVSへの置き換えも進んでいき、これまでにないような面白いサービスも生まれてくるのではないでしょうか。

皆様もぜひKVSアルファテストサービスをご活用ください！