モバイルファクトリーの技術者の松野です。

今回はWassr（ワッサー）の技術的な側面についてのお話をさせていただきます。

フレームワーク

Wassr開始以来，「WassrってRailsでできてるんですか？」とよく聞かれるのですが，WassrはRailsではなくSledgeというフレームワークでできています。Sledgeはlivedoorが公開しているフレームワークで，弊社では創業以来一貫してSledgeを使いつづけています。Sledgeの魅力はその柔軟性にあり，公開されてから数年たった今の現状でも十分実用に耐えるフレームワークです。

サーバ構成

Wassrは2007年6月20日現在，16台構成で動いています。詳細は図1を参照してください。使用しているソフトウェアはすべてオープンソースです。これは，何か問題が起きたときや，そのソフトウェアについていない機能を追加したいときなどに，自分で対応したいからです。

実際，弊社で利用しているロードバランサのPerlbalには，2つのプラグインを追加して運用しており，両方ともオープンソースで提供しています。

アプリケーションサーバはApache 1.3＋mod_perl，静的コンテンツの配信にApache 2，ロードバランサにPerlbalを使って配信しています。ごくごくありふれた構成です。

データベースにはMySQL 5を使っています。弊社では初の5系の採用でしたが，とくに問題なく運用できています。

キャッシュ用のサーバとしてmemcachedを使っています。かなり高速に動き，複数アプリケーションサーバでキャッシュを共用できるため便利に使っています。非常に高速に動くので，セッションの保存用サーバとしても利用しています。

非同期な処理を行うためにTheSchwartzというライブラリを用いています。これはSixApartがオープンソースとして提供しているJobQueueシステムです。MySQLを使用した素朴な実装となっているため非常に扱いやすいです。

Wassrでは，RSSの生成やIMでの通知，ブログパーツ用の画像の合成などに利用しています。これらのものはほぼ静的なコンテンツなので，アプリケーションサーバで毎回生成するのも馬鹿馬鹿しいですし，キャッシュするにしても初回はアプリケーションサーバで処理することになってしまうため，ヒトコトが更新されるタイミングでJobQueueにenqueueして，TheSchwartzの常駐プロセスが随時処理する構成にしています。

API

WassrはAPIをサービス開始時から備えています。APIを用意することにより，クライアントソフトやマッシュアップサービスの登場を期待することができます。すでにいくつかのサービスで利用されています。

JSONP，JSON，RSS，CSVの各フォーマットに対応しており，Webサービスで使いやすい仕様になっています。

また，一部APIにおいては，Twitterとの互換性を持っています。これにより，Twitter向けのアプリケーションの移植はAPIのURLを変えるだけで良いので，非常に容易になっています。

絵文字

Wassrでは絵文字を非常に重視しています。

絵文字は3キャリア＋ウィルコムに対応しています。絵文字は3キャリアで，同じ意味の絵文字があるものは相互変換しています。

この処理にはEncode::JP::MobileというPerlのライブラリを使っています。これはSixApartのmiyagawaさんが開発されたライブラリですが，相互変換機能は私が追加してcommitした機能です。

SLのAPI

SecondLife用のAPIも用意しています。SecondLifeでは，RSSなどを読むことはできませんので，SecondLifeで扱いやすいCSV形式でフィードを配信しています。

また，そのAPIを利用した公式のSecondLife用HUD（ヘッドアップディスプレイ）も配布しています。一般ユーザに提供しているAPIをそのまま使っていますので，一般ユーザも同等のものを作成することができます。

SecondLife用APIに機能を追加する場合には，APIのほうを先にリリースし，公式HUDへの機能追加を少し時間を空けて行うことにより，API開発者のモチベーションアップを図っています。