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

今回は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開発者のモチベーションアップを図っています。