簡易http分散ファイルシステム(Simple http based Distributed File System)

SHDFS は httpd + php のみでWEBの静的コンテンツの冗長化とスケールアウトを行います。

SHDFSが得意なもの
・動画など大きなファイルのダウンロードサーバ

SHDFSが苦手なもの
・htmlやgifなど小さくて多数のアクセスがあるもの

SHDFSが使えないもの
・動的コンテンツを含むもの

注意:プロジェクトの名前に「ファイルシステム」が含まれて居ますが、ZFSやbtrfsのようなストレージレベルのファイルシステムではありません。

GoogleFileSystemやHadoop(HDFS)など、多数のサーバを連携させて可用性の向上や大規模なデータの保存を実現する技術が出てきました。これらは「サーバは壊れるもの」という前提で、安いストレージを多数用意するというコンセプトです。

それらの技術は高度ではあるのですが、単にダウンロード型サーバのストレージとして使うには複雑すぎて不満でした。

機能

• n台のサーバで任意個の冗長化が可能。
• スケールアウトが可能
• キャッシュサーバの追加でトラフィックの増大に対応
• ノード撤去時にはアクティブなノードが足りなくなったコピーを自動的に補う
• 帯域制限(予定)
• PHPセッション認証(予定)
• HTTP302による転送(予定)

効果

• 安価なサーバを多数用意することでコスト削減と可用性を両立できる
• OSの実ファイルそのものが構成要素なので運用が楽

SHDFSの仕組みを理解するために、図を使って概要を説明します。

ステップ1 冗長化の仕組み

仮にサーバが3台あったとします。これらは独立した単なるWEBサーバです。 ドキュメントディレクトリはサーバのローカルディスクを指しています。 コンテンツはローカルファイルシステムにある単なるファイルです。

SHDFSにおける冗長化とは、隣のサーバにある同一のファイルです。 すごくシンプルでしょう。

図を見ていただければ分かりますが、全てのサーバに全てのファイルのコピーがある必要はありません。 「データA」は「サーバA」と「サーバB」にありますが、「サーバC」にはありません。 これは冗長化数を決めるパラメータを「2」にした場合をあらわしています。

冗長化数とサーバ数を同じにすると、どのサーバにもだいたい同じコンテンツファイルが存在することになりますが、スケールアウトのメリットは活かせません。 ここで「だいたい」と表現するのは後で説明しますが、サーバ数よりも冗長数を少なくすることがスケールアウトの基本です。

この図を見ればスケールアウトの方法が容易に想像できると思います。

ステップ2 スケールアウト

その方法とは単にサーバを追加するだけです。追加されるサーバにはコンテンツファイルが在っても無くてもかまいません。 4台目のサーバ「サーバD」が追加された図2です。

もちろんこの「サーバD」も単なるWEBサーバです。 ただしこの例では、サーバA～Cには無い「データD」をたまたま持っていました。 この後この「データD」が冗長化される様子をみて見ましょう。

ステップ3 冗長化

先に残念なお知らせがあります。SHDFSは能動的には冗長化を行いません。 「サーバD」が接続された瞬間には冗長化は開始されません。冗長化される条件は、

他のサーバに自分が持っていないファイルのリクエストがあったとき

なのです。

図の例ではクライアントから「サーバA」に対して「データD」のリクエストがありました。 「サーバA」は「データD」を持っていないので、仲間のサーバに問い合わせます。 「サーバD」が持っていることを知ると「サーバA」は裏で「サーバD」から「データD」を取得し、あたかも自分が持っていたかのようにクライアントに応答します。

そしてこのときに冗長化は達成されます。

アクセスが無い限り冗長化は行われないので、これは受動的な冗長化です。 しかしこれでは1回もアクセスが無いファイルは永遠に冗長化されません。それで良いのでしょうか?

誤解を恐れずに言えば、答えは「YES」です。 SHDFSの各WEBサーバは弱い結びつきで成り立っています。弱いからこそのメリットがあるのです。

• 簡単に切り離せる

• データは単なるファイル

• 人気のあるファイルならば早めに冗長化される

ステップ4 データキャッシュ

SHDFSはデータキャッシュを持つ機能があります。

冗長化数が「2」の場合、「データB」は「サーバB」と「サーバC」にあるので既に冗長化は達成されています。 「サーバD」に「データB」のリクエストがあると、ステップ2で説明したように代替取得が行われます。必要な冗長化数は達成しているので「サーバD」は冗長化は行いません。 このとき「サーバD」は「データB」のキャッシュを持つことが出来ます。

キャッシュの利点は、もう一度同じリクエストが会ったときに、代替取得を行う必要が無いということです。 頻繁にリクエストされるファイルほどキャッシュに残りやすくなるので、キャッシュを持っているサーバは自分のリソースだけでファイルを送信できるようになります。

SHDFSではこのキャッシュですらも単なるファイルです。キャッシュなのでいつ消えてしまうか分からない儚い存在ですが、もしものときに .cache というディレクトリを探してみると助けになるかもしれません。

ステップ5 ロードバランサとの組み合わせ

どのサーバにリクエストしても良いという特徴はロードバランサと相性がぴったりです。 図の例では「データB」は大人気のようです。このように多数のサーバのキャッシュに乗ると最大のパフォーマンスを発揮できるでしょう。

ステップ6 大規模化への展開

SHDFSはアイデア次第で独自の構成が可能です。 例えば複数のデータセンタで運用する場合、あるデータセンタは送信専用と割り切って、キャッシュのみのサーバで構成することも可能です。

その他のアイデア

• 既存WEBサーバの取り込み

• パケットシェーパー、認証機能(開発中)

• 他の送信ポイントへ転送(開発中)