サイトがソーシャル ブックマーク/共有サイトにアクセスする場合、システム/ネットワーク管理者はどのような技術的な考慮事項を考慮する必要がありますか?
-
09-06-2019 - |
解決
残念ながら、これが起こる前に計画を立てていなかった場合は、おそらく手遅れとなり、ユーザーのエクスペリエンスは低下するでしょう。
スケーラビリティが当面の最初の懸念事項です。1 秒あたりのヒット数が、1 か月あたりのヒット数よりも多くなる可能性があります。防御の第一線は、適切なプログラミングと設計です。データをキャッシュする代わりに、リクエストごとにデータベースから複数回リロードするなど、愚かなことをしていないことを確認してください。スパイクが発生する前に、かなり現実的な負荷テストを実行して、ボトルネックがどこにあるのかを確認する必要があります。
トラフィックが異常に多い場合は、一部の動的ページを静的ページに切り替える機能を検討してください。
拡張可能なサーバー アーキテクチャを持つことも役立ちます。共有ホストは通常、拡張できません。通常、単一の専用マシンは拡張できません。Amazon の EC2 などをホストに使用すると、特に最初からサーバーのクラスターを計画している場合に役立ちます (クラスターが単一のコンピューターであっても)。
次に懸念されるのはセキュリティです。あなたは突然、悪者にとってより大きなターゲットになります。適切なセキュリティ計画を必ず立ててください。これは常に備えておくべきものですが、使用頻度が高くなるほど重要になります。
他のヒント
まず、起こらないかもしれないこと、そして起こったとしても5時間ほどかかることの計画に、本当に何週間も何千ドルも費やしたいかどうかを尋ねてください。
最も簡単な解決策は、サインアップを許可するページに切り替える適切な方法を用意することです。人々はサインアップし、嵐が去ったときにメールを送信できます。
より複雑なソリューションは、迅速に拡張できるかどうかに依存します。それはまずソフトウェアの問題です (別のサーバー上のデータベースに接続できるか、負荷分散を行うことができますか)。次に、ホスティング ソリューションは高速拡張をサポートする必要があります。Amazon EC2、あるいはスライスホストが思い浮かびます。どちらのサービスでも、新しいインスタンスを簡単に開始したり (「データベースを別のサーバーに移動しましょう」)、インスタンスを拡張したり (「DB サーバーを 4GB RAM にアップグレードしましょう」) ことができます。
すべてのデータ (セッションを含む) をデータベースに保存すると、複数のフロントエンド サーバーを簡単に構築できます。データベースの場合、私は通常、利用可能な最大のリソースを備えた単一サーバーを試しますが、それは私が DB レプリケーションを扱ったことがなく、少なくとも mysql ではそれを行うのが非常に難しかったからです。状況は改善されたかもしれません。
アプリの設計者は、スケールアップ (より多くのコアとより高いパフォーマンスを備えた大規模なマシン) および/またはスケールアウト (複数のシステムにワークロードを分散する) について考える必要があります。IT 担当者は、それを最適にサポートする方法を考え出す必要があります。明らかにネットワーク上にすべてが乗っているため、最初に目に入るのはネットワークです。境界から始まることは、通常、複数のプロバイダーによってサービスを提供されるネットワーク ロード バランサーと冗長ルーターを意味します。また、cachefly などの地理的キャッシュ サービスやアプリも確認できます。
ボトルネックをできる限り軽減したいと考えています。また、あまり手間をかけずに必要に応じてスケールアウトできるように環境を設計することも必要です。事前にデザイン作業をしておくと、実際に問題が発生したときの頭痛の種が減ります。
いくつかのアイデア (過去および現在のプロジェクトで使用したもの):(必要に応じて) パフォーマンスを向上させるために、サーバーの前にリバースプロキシ、キャッシュの Squid を配置できます。もちろん、これはセッションキーがなく、ページがある程度静的である場合にのみ機能します(次のことを意味します)。変更されるのは 1 時間に 1 回程度です)、パーソナライズされていません。Squid を使用すると、typo3 のような肥大化して遅い CMS を強化できるため、CMS の快適さで静的 Web サイトのパフォーマンスを得ることができます。
大きなファイルを Amazon S3 などの外部サービスにアウトソーシングして、サーバーの帯域幅を節約できます。
また、数ドル (月あたり 3 桁) のお金を使えるのであれば、コンテンツ配信ネットワークを使用することもできます。これを導入すると、ユーザーは自動的にスケーリング、高可用性、低遅延を実現できます。もちろん、ページはキャッシュ可能である必要があるため、セッション キーやパーソナライズされたページは使用できません。CDN を念頭に置いて慎重に設計すれば、少なくとも写真やビデオ、静的なコンテンツなどの一部のコンテンツをキャッシュできます。
他の回答にも記載されているように、負荷が増加します。
また、荒らし行為にしか興味がない退屈な人々からの新規ユーザー、ブログのコメント、投票が殺到するでしょう。これは主に、完全に匿名でコメントできるブログで問題になることが多く、恐ろしい内容が書き込まれてしまいます。ブログ プラットフォームには、スパム フィルターをブロックするのに十分なスパム フィルターがある可能性がありますが、残っている悪意をクリーンアップするには手動による介入が必要になることがよくあります。
認証が行われていない場合でもユーザー名や電子メール アドレスの入力を要求するなど、少しでも参入障壁を設けるだけで、破壊行為の量は大幅に減少します。