ファイルサーバーとウェブサーバーを分ける

質問

こんにちは。

ふと気になったので教えていただきたいのですが、

例えば、イラスト系SNSのような画像が大量にあるサイトにおいて、

DBサーバーとウェブサーバーを分ける方法は分かるのですが、画像ファイルを取り扱うファイルサーバーを別途用意する場合、一般的にはどのような方法で画像格納先を指定するのでしょうか。

思いついた方法としては、ファイルサーバーのIPにサブドメインを割り振っておいて、ウェブサーバーで書き出す画像の格納先をhttp://サブドメイン/画像の名前.jpgのようにする、というものなんですが・・・。
ただ、これだとファイルサーバーを複数台数にしたい場合はどうするんだろう・・・。などの疑問点が残っています。ファイルがどのファイルサーバーに保存されているかをDBに記録しておいて、ウェブサーバーで動的にサブドメインを指定して吐き出す、というような方法になるのでしょうか。

雑多な質問で申し訳ありませんが、全体的なところを教えていただけますと幸いです。

宜しくお願い申し上げます。

回答No.2

OrangeCup150 · ベストアンサー

ドメインの構成例としては example.com が www.example.com と contents.example.com に分かれているとします。
WEB サーバとコンテンツサーバはそれぞれ2台ずつあるとし、以下のように呼びます。
WEB サーバA, B
コンテンツサーバA, B

クライアントがアクセスするときには、ドメイン名をDNSに問い合わせするのでこのときに返すIPアドレスをWEBサーバA とコンテンツサーバAのセット、WEBサーバB とコンテンツサーバBセットで返します。このようにすると、負荷分散が実現できます。静的コンテンツならこれが簡単にできる方法だと思います。
また、プロバイダが提供する映像配信では、各プロバイダにコンテンツサーバ（ミラーサーバ）を持たせることで、ネットワーク負荷を大きく下げられることが想像できると思います。一方、ニコニコ動画のようなサービスはネットワーク負荷が高くなることも想像できると思います。

クライアント－ＩＳＰ内のミラーサーバ

クライアント－ＩＳＰ－ＩＳＰ－ニコニコのサーバ

ようするに、ドメイン名に対してサーバは複数指定することができます。

>思いついた方法としては（略）

ファイルを分散して格納する場合には当然コストがかかりますので、ファイルサーバとそのミラーサーバを用意する構成のほうが単純なのでいいと思いますが、これは格納しているファイルへのアクセスに偏りがあると無駄なディスクスペースを消費しがちになるという欠点があります。
たとえのＳＮＳ系では（イラストに限らず、写真、音楽、映像なども含めて）、常識的に考えて最新のコンテンツへのアクセスが多く、過去のコンテンツへのアクセスは少ないと考えられるので、ファイルを年、年月または年週単位にフォルダ分けして格納します。
ミラーのファイルサーバは比較的新しいコンテンツのみを持ち、アクセス頻度の低いコンテンツはシンボリックリンクなどで本ファイルサーバへ繋げるなんてどうでしょう？
あるいはアクセスログなどの統計情報をもとにミラーサーバの持つコンテンツとリンクを自動で分けるようにするなど。（ＬＲＵを応用したようなかんじですかね。ここまでやると本格的ですので割と大変ですので、大容量ディスク（またはＲＡＩＤ）買った方が安上がりですかね。）

ミラーサーバ多数－シンボリックリンク→本ファイルサーバー

上記の構成では、ＤＮＳのラウンドロビンとシンボリックリンクによって透過的なアクセスが実現できます。

>（略）画像ファイルを取り扱うファイルサーバーを別途用意する場合、一般的にはどのような方法で画像格納先を指定するのでしょうか。

さて、結論は
画像へのＵＲＬはそのままに、多数のサーバに処理を振り分ける
です。
まあ、ネットワークのお勉強をするとＮＡＴ、ＩＰマスカレード、プロキシサーバ、リバースプロキシサーバなどなど割と透過的にアクセスできる技法が何となく分かりますよ。

お礼

実用的なアドバイスありがとうございます！

DNSラウンドロビンくらいなら分かるのですが、シンボリックリンクやネットワーク関連の知識が薄いので、そのあたりを勉強してみることにします。

だいぶ道筋がみえてきました。ありがとうございます。m(_ _)m

回答No.3

lupin-333333

Webサーバーから見ると、No1,2 さんのようなやり方がでてくるのでしょう。

ただ、ファイル管理ソフトとしては、通常、ＤＢには、コンテツＩＤで（ユニークな暗号化された乱数）登録され、実態は別ファイルシステムに存在します。もちろんＤＢに内包（バイナリとして）するやり方もあるが、ＤＢとして管理が大変になるので、通常、ＯＳのファイルシステムを使用します。

その見せ方をＬＤＡＰを使用するか、ファイルシステムとして扱うかは設計思想による。

クライアントツールからの呼び出しには、Ｗｅｂアプリから見ると、ＣＧＩ（サーバーサイドスクリプト）の戻り値としてバイナリーでかえされるだけなので、クライアントからも正式なファイル名（ファイルシステムに格納されているファイル名）は、実態として分かりません。業務Ｗｅｂアプリなんかは、通信経路でもＳＳＬ、ＳＳＬ－ＶＰＮを使用し見えませんが、呼び出し元でも、どこに、何が格納されているか見えないようになっています。

そう、サブドメインとして見えているのは、単なるＷｅｂサーバーのレプリカで、ファイルの実態格納場所でないことに注意。

そうなってくると、

＞ファイルサーバーを複数台数にしたい場合はどうするんだろう・

なんて考える事自体無駄。ＰＫＩの公開鍵と同じで、ＣＧＩが吐き出すものは単なるキーにすぎなく、ＣＧＩが動作するマシンからアクセスできる状態であれば、どうにでもなる。

なんてね。不特定多数に対しては、当然ロードバランサーを含め、いくつも、アクセスポイントを持っているのが当たり前。それぞれ、実態ファイルサーバーのレプリカをもつか、同じＵＲＩを使うかは、設計次第ですね。というか、かね次第（予算）。

Ｏｒａｃｌｅには、質問者が考えたような事を提供しているシステムがありますので、参考にしてください。

http://search.yahoo.co.jp/search?b=1&n=10&ei=UTF-8&fr=ie8sc&p=Oracle+RCA

http://www.atmarkit.co.jp/fdb/rensai/basics_rdb/07/basicrdb07_01.html

ＯｒａｃｌｅのサーバーをWEBサーバー　コンテンツサーバーと見立てれれば、発想しやすいでしょう。

お礼

なるほど・・・。こういった製品もあるんですね。
ぱっと見ですべて理解できなかったので、これから研究してみることにします！

ありがとうございましたm(_ _)m

回答No.1

IDii24

一般的にはＤＢを利用して目次の管理と格納先の管理をします。呼び込むときはＤＢから格納先を読み取ってそのフォルダーから読み込むようにします。
その他にＤＢに直接画像を取り込んでしまう場合もあります。そうすることで画像に対して検索が出来るからです。でもこの方法はＤＢの性能で左右されますから今はあまり使われないと思います。
今の一般的な方法は、ＸＭＬを利用してタグを作成し、そこにリンク先を記述する方法です。このＸＭＬをうまく処理すればタグ検索によってあらゆる検索も可能です。
このＸＭＬ自体をＤＢ化する手もあります。画像データーベースとはこのようなＸＭＬによる階層管理されている物が多いです。
簡単なものではＸＭＬ定義だけでＤＢを使わず処理をすることもできます。

お礼

なるほど・・。

DBに格納先を指定しておくというのは、簡単に実現できる方法のひとつのようですね。

ありがとうございました。m(_ _)m