lestrratです。本日めでたく正式にSTFがオープンソースとしてlivedoor ラボ EDGE上でリリースされました！
いままでちょこちょこと先出し先出しで情報をだしていましたが、これで本当に本当の正式公開です。一応上記のサイト以外に「公式」サイト的なものも用意しました。ソースコードはgithub上に公開されています。ということで使って欲しいので紹介記事です。
STFは分散オブジェクトストレージです。Perlメインの似たようなシステムとしてはMogileFSが有名ですが、STFは後発のメリットを生かしてPSGI互換にしたり、使用するプロトコルを基本的にHTTPというオープンで枯れた技術を採用したりとメンテナンス・運用の利便性があがっていると考えています。
STFは元々ApacheモジュールといくつかのPerlワーカーで書かれていましたが、ひょんなことから自分がPSGIに移行させてそれ以降面倒を見ています。基本的にはすでに動作していたCベースのコードがあったのでそれをふむふむと読んでガリガリポーティングしました。
結果、アプリ部分はPerlになり拡張・修正しやすくなり、それ以外はApache(or nginx)、MySQL、Q4M (or TheSchwartz)、Memcached等のミドルウェアを駆使して動作する現在の形になりました。
この改良版は2011年中盤くらいに本番適用され、ロケタッチやライブドアブログ宇の画像アップロード等に使われています。2011年末の時点でオブジェクト数4億個、13億エンティティ、70TB程度のデータを管理しています。データ転送量もピーク時に400Mbpsを特になんの問題なくさばいています。
なお、PSGI移行以前のSTFについてはこちらの資料が詳しいです。実装が変わっていますが、やっていることはかわりません。
STFで管理するデータはオブジェクトと呼ばれます。オブジェクトはユーザーからみた1 ファイルに相当しますが、STFはデータの冗長性のために複数のエンティティを持ちます。すなわち、STFではオブジェクトとは論理的なファイル、エンティティが物理的なファイルに相当します。
オブジェクトは全てバケットに属する必要があります。S3と一緒ですね。
エンティティはストレージと呼ばれるサーバーに格納されます。任意のストレージには1 オブジェクトにつき最大1 エンティティが格納されます。ストレージはGET/PUT/DELETEを理解できるHTTPサーバーであればなんでもかまいません。STF本体にも一応PSGI互換のアプリケーションがついてきますが、この部分に関しては使用状態に合わせて他のサーバーで置き換えても構いません。
オブジェクトの追加・削除・取得はディスパッチャーというコンポーネントを通して行います。ディスパッチャーとの通信もHTTPで行います。
ディスパッチャーはなるたけ素早く通信を返すように処理をしますので、それ以外の処理はキューを通して別サーバーで動作しているワーカーに渡します。比較的ビジーなシステムではQ4Mをキューとして使うのがオススメですが、現在のバージョンではTheSchwartzでも動作します。
ワーカーはエンティティの数の増減や、壊れたオブジェクトの修理などを行います。例えばディスパッチャーでとりあえず最低限の数のエンティティを作成したのを見届けたらクライアントに成功を返し、その後ワーカーで必要な冗長性を確保するといった具合です。
ざっくりSTFの使用の流れを追ってみましょう。
まずバケットを作成します
PUT /lestrrat-bucket HTTP/1.0
その後、オブジェクトを作成します
PUT /lestrrat-bucket/photos/super-secret-photo.jpg HTTP/1.0
X-STF-Consistency: 2
X-STF-Replication-Count: 3
... ファイルの中身 ...
X-STF-Consistencyはオブジェクト作成時に作られるエンティティの数を指定します。PUTリクエストが成功を返すと、最低これだけのエンティティが作成されたことが保証されます。X-STF-Replication-CountはPUTの後、ワーカーの処理が終わった時点で作成されるエンティティの総数です。このリクエストの場合は最終的に3個のエンティティが作成されます。
これでオブジェクトが作成されたのであとは取得するだけですね
GET /lestrrat-bucket/photos/super-secret-photo.jpg HTTP/1.0
秘密の写真を消したくなったらDELETEを発効します
DELETE /lestrrat-bucket/photos/super-secret-photo.jpg HTTP/1.0
簡単ですね！
なおこの辺りの処理をまとめたNet::STF::ClientもCPANにアップされていますのでそちらもご覧下さい。
dotcloudでのデプロイ方式を前のエントリで書きましたが、ここでは実際に動いているシステムのデプロイの特徴を軽く説明します。
デプロイするプロセス自体は社内用にガリガリと書いたツールでやっています。最初のうちは何回か失敗はしましたが、今ではWeb画面からぽちっとするとServer::Starterなどを駆使してゼロダウンタイムでデプロイできるようになっています。
特にServer::Starterの素晴らしい点は ついうっかりtypoとかを混入したりした状態で（てへ☆）そのままデプロイしちゃったりした場合に新しい世代のコードが走り始めるまで前の世代が死なない点ですね。これのおかげで一瞬ログがひどい事になってもシステムとしては動き続けますので急いで書き忘れてたセミコロンを入れて再度デプロイをかければノープロブレムです。
ゼロダウンタイムです。すばらしいですね。
設定も環境によって切り替えできるようになっていて、なんとかblog、なんとかpics、に複数サービスが混在している共用のものなどへのデプロイもその環境名を変えるだけでデプロイ先を変更できます。
このあたりもApacheモジュールからPSGIアプリに変更したおかげで大分楽になりました。今ではSTFのオープンソース版に変更を入れたら、社内用の設定ファイルと一緒にまとめてあるレポジトリ内のgit submoduleのrefを一個ちょいと変更して、デプロイボタンを押すだけでシステムの更新ができます。まったくもって楽になりました。
STFはオープンソースプロジェクトとして公開されました。誰でも利用できます。
枯れた技術とオープンなプロトコルばかりを使っているのでメンテナンスやトラブルシューティングもかなり楽です。パフォーマンスも申し分ないです。ゼロダウンタイムのデプロイまわりをうまく設定できてしまえばシステムアップデートもまったくストレスなく行えます。おすすめです！
セットアップに関してはSTFの資料を見て下さい。ドキュメントにわかりにくいところや追加したほうがよい点に関してはgithub issuesで報告していただくか、ソースにたいしてpull reqを送って下さい。なるたけ早く反映します！
というわけで是非使ってみて下さいね！使ったらtwitterとかで意見を教えていただければ幸いです。