最近、興味深い傾向が概説されました-Webプロジェクトの無限への急速な「膨張」。 多くの人気サイトのデータ量はどんどん増えており、どこかに配置する必要があり、バックアップするのが効果的です(500Tのファイルが失われたら楽しいでしょう:-))、そしてもちろん、誰にでもダウンロード、ダウンロード、ダウンロード...高速で。
システム管理者にとって、このような大量のファイルのまれな毎日のバックアップでさえタスクは自殺の想いを呼び起こし、Webプロジェクトマネージャーはデータセンターの6時間の予防を考えて冷や汗で目を覚まします(1つのデータセンターから別のデータセンターにファイルを転送するには、トランクをロードする必要があります車のウィンチェスター:-))。
賢い同僚は、 NetAppからソリューションの1つを購入することをお勧めしますが、プロジェクトの予算が1000倍少ないことは残念ですが、それはまったくのスタートアップです...私たちは何をしますか?
記事では、この問題に対する安価で高価な解決策の単純な例から複雑な例まで頻繁に見られるケースを調べたいと思います。 記事の最後に、私たちの主力製品で問題がどのように解決されるかをお伝えします-オープンソースのソリューションを市販のものと比較することは常に有用です。脳には体操が必要です。
HighLoadワードローブアクセス
HighLoadカンファレンスに参加したことがあるなら、おそらく入り口で質問に答えなければならないことを知っているでしょう-なぜ彼らはnginxをApacheの前に置くのでしょうか? そうでなければ、ワードローブより先に行く方法はありません;-)

そうです、nginxまたは同様のリバースプロキシを使用すると、特に低速チャネルでファイルを効率的に配布し、サーバーの負荷を大幅に削減し、Webアプリケーションの全体的なパフォーマンスを向上させることができます。nginxは、多数のファイル、apacheまたはphp-fpmプロセスリクエストをアプリケーションサーバーに配布します。
このようなWebアプリケーションは、ファイルサイズが数十ギガバイトに増加するまで、つまり数百のクライアントが同時にサーバーからファイルのダウンロードを開始し、RAMにファイルをキャッシュするのに十分なメモリがない場合、ディスク、そしてRAIDが死ぬまで生き続けます。
静的サーバー
この段階では、多くの場合、最初は仮想的に開始してから、別のドメインから静的ファイルを物理的に配布します。できれば余分なCookieを大量に配布しないでください。 そして当然のことです。クライアントのブラウザではサイトの1つのドメインの接続数に制限があることを誰もが知っています。サイトが突然2つ以上のドメインから離れると、クライアントのブラウザへのダウンロード速度が大幅に向上します。
彼らは次のようなことをします:
- www.mysite.ru
- img.mysite.ru
- js.mysite.ru
- css.mysite.ru
- download.mysite.ru
- など
異なるドメインからより効果的に静的を配布するために、それらは別のサーバーの静的に送信されます。

このサーバーでnginxキャッシングモードと「高速」RAIDを使用すると便利です(そのため、ディスクを「膝」に設定するにはより多くのクライアントが必要です)。
CDN-配布
この段階で、Webプロジェクトのオーガナイザーは、非常に高速なディスクやSANからでもデータセンターから配布することが必ずしも効果的ではないことを理解し始めます。
- 貴重なクライアントがウラジオストクのモスクワサーバーからファイルをダウンロードし始めました。都市からではなく、ヨットの側面からダウンロードしました。 もちろん、チャネルは狭いことが判明しました。
- 災害が発生し、クリーナーが誤って静的配布サーバーから電源コードを抜いて、新しい配布をダウンロードしている10,000人のクライアントを切断しました。 さて、またはデータセンターでは、予防が終了するのは「不明」です。つまり、2台のディーゼル発電機のうち3台の同時故障の原因を見つけるために働いています。
- それどころか、このようなクライアントの流入により、サーバーの容量があまりに多くの静的を同時に分散するのに十分でなかったり、チャネルがすでに限界までロードされていたりする可能性があります。
一般に、サーバーからどれだけ与えることができるかではなく、クライアントにできるだけ近づけて、可能な限り高速で必要なだけ静的にクライアントを与える必要があることを誰もが理解しています。
最近、CDNテクノロジーがこれらの問題を効果的に解決し始めました。

クライアントがどこからダウンロードしても、赤の広場やサハリンから-あなたのファイルは本当に自由に利用できるようになります-ファイルは最も近いCDNプロバイダーサーバーから転送されます。
静的分布の「垂直」スケーリング
この時点で、Webプロジェクトは徐々に膨らんでいます。 配布用にますます多くのファイルを保存して保存すると、たとえば、1つまたはサーバーのグループの1つのDCに一元的に保存できます。 非常に多くのファイルをバックアップすることは、より高価で、より長く、より難しくなっています。 完全バックアップは1週間行われます。スナップショット、増分、および自殺のリスクを高めるその他のことを行う必要があります。

次のことを考えることを恐れていますか:
- ファイルストレージ上のディスクは壊れます(raid10は、ミラー化されたディスクを一度に2枚使用すると死ぬことがありますが、これはめったに起こりません)。2〜3週間以内にバックアップからファイルを取得する必要があります。
- データセンターはついにディーゼル発電機の数を数える方法を学びましたが、朝、ディスクが散らばっており、ソフトウェアエラーの結果としてのバックアップが回復不能な損傷を受けたというメッセージに満足しました(これはAmazonで一度起こりました)。
- 広告キャンペーンが行われ、極東またはヨーロッパからの顧客の流入が始まります-そして、あなたは非常に多くの静電気の効果的な配布に対処することができなくなります。

とにかく、あなたはすでにインフラストラクチャに多くのお金を投資しましたが、リスクとかなりのリスクは残っています。 どういうわけか不誠実に取得。
サークルとホイール-分散ファイルシステム
現時点では、ロジックを担当する左半球が多くの電源をオフにし、いくつかのデータセンターに分散ファイルシステムを展開するための神秘的な巨大なソリューションに惹かれます。 多分、予算の大きいプロジェクトの場合、これが解決策となります...

次に、このすべての経済を自分で管理する必要がありますが、これには明らかに運用部門全体の存在が必要です:-)
仮想ファイルシステム
最も効果的で、最も重要な、安価なソリューションの1つは、非常においしいでレンタルする有名なクラウドプロバイダーの機能を使用することです。特に、大量のデータ、価格で、非常に高い信頼性で無制限の量のファイルをクラウドに保存する方法(巨大なDropBox) 。 上記の分散ファイルシステムを施設で組織化したプロバイダーは、信頼性が高く、地理的に分割された複数のデータセンターに配置されています。 さらに、これらのサービスは通常、このプロバイダーのCDNネットワークに緊密に統合されています。 つまり ファイルを便利かつ安価に保存するだけでなく、クライアントにできるだけ便利に配布することもできます。
問題は小さい-Webプロジェクトでレイヤーまたは仮想ファイルシステム(またはクラウドディスクのアナログ)を構成する必要があります。 無料のソリューションの中で、 s3fsなどのFUSEツール(Linux用)は区別できます。

ただし、現在のWebアプリケーションをビジネスの観点からこの安価で非常に効果的なテクノロジーに移行するには、既存のコードとアプリケーションロジックをプログラミングし、多くの変更を加える必要があります。
モジュール「クラウドストレージ」プラットフォーム「1C-Bitrix」
私たちの製品では、上記のWebプロジェクトのケースを慎重に分析しました。これはファイルをクライアントに、場合によっては数テラバイト以上、迅速に配信する必要があり、これらの機能を「クラウドストレージ」モジュールに「すぐに」実装しました 。

私は、システムの個々のモジュールのデータを異なるクラウドストレージに保存できることを正直言っています:-)。 それは本当にあなたのファイルストレージを多様化します。 クライアントのアドレスまたはタイプに応じて、それらを分散できます。 または、情報の種類から-誰かが効果的に軽い静的なものを、誰かが重いコンテンツを与える
まとめ
Webプロジェクトを何に書くかは関係ありません。遅かれ早かれ、ストレージと配布用のファイルの量が雪崩のように増加するという恐ろしい問題に必ず遭遇し、適切なアーキテクチャを決定する必要があります。
この記事では、あらゆるサイズのWebソリューションでファイル配布を整理する主な段階と原則を検討し、賛否両論を検討し、1C-Bitrixプラットフォームでこれがどのように実装されるかを調べました。 Webプロジェクトによって配信される情報の量が急速に増加しているという事実を考えると、この知識は関連性があり、Webアプリケーションアーキテクトとプロジェクトマネージャーの両方にとって確実に役立ちます。
そしてもちろん、私たちはBitrix24クラウドサービスに皆さんを招待します。ここでは、上記のテクノロジーを積極的に使用しています。 皆さんに幸運を!