最も一般的なWebサイトのスケーラビリティの落とし穴


8

私たちは高いユーザー数と一般的に多くの使用を達成することを望んでいるウェブサイト/ウェブアプリケーションを設計しています。具体的には、プログラミング/スクリプト言語としてPHPを使用し、リレーショナルDBのMySQLを最初に使用する予定です。NoSQLデータベースを使用するかどうかはまだわかりません。

これに関連して、スケーラビリティを考慮して設計したいと考えています。Webサイトの最も一般的なスケーラビリティの落とし穴は何ですか?システムを簡単にスケーラブルにできるようにするために、考慮する必要がある主要な領域は何ですか?


どのホスティングプラットフォームを検討していますか?
mhoran_psprep 2012

1
これはリスト/ちょっとした質問のように感じます。
Michael Brown、

PHPのスケーラビリティ?幸運を。Zendをよりよく使用してください。
ジョーダン

@Jordan:月に何十億ものページビューを行うPHPを実行しているサイトがいくつかあります。(netlog、wikipedia、facebook、tumblr、flickr)
Joeri Sebrechts

1
はい、そしてそれらのそれぞれはそれをサポートするための大規模なインフラストラクチャを持っているか、少なくともFacebookとTumblrの場合はそれを完全にバイパスしています。
ジョーダン

回答:


11

それに加えて、非常に一般的なことを1つ追加します。それは、間違った場所での最適化です。PHP構文の構成要素のナノ秒の違いを取り上げた記事はたくさんありますが、アプリケーションのキャッシングインフラストラクチャを適切に設計する方法についてはあまり取り上げていません。すでに述べたように、テストしてください。しかし、テストだけではありません-プロファイルして正確に何を見つけるか遅いです-それはCPUバウンドですか?I / Oバウンド?メモリバウンド?ダウンさせるのはデータベースクエリですか、それともファイルの読み取りですか、それとも計算ですか?あなたはそれを取り除くか、それをやり直すことができますか?など「最初はNoSQLを使用してみましょう」「これを実行したいのですが、ボトルネックは何でしょうか。どのようにしてそれらを排除しますか?100人のユーザーを取得した場合、どのように動作しますか?」ワークロードとアプリの詳細を知らなければ、具体的なことを言うのは難しいですが、キャッシュできるものと、ファイルシステム/データベースなどを削減する方法を考えることから始めます。アクセスと特に変更(これらもキャッシュを無効にするため)。


6

最も一般的なスケーラビリティの落とし穴は、早い段階で負荷テストを行わないことです。開発の初期段階で予想される負荷に匹敵するものをシミュレートするテストを設定すると、技術的または構造的な障害を検出して修正し、コストがかかりすぎて修正できなくなる前に、スケーラビリティを阻害できます。


5

PHPでのスケーリングの良い例:TumblrFlickrNetlog

スケーラビリティに関する一般的なアドバイス:

  • 複雑にしないでおく!
    過剰設計したり、ベンダー固有の豪華なソリューションを購入したりしないでください。
  • シェアード・ナッシング・アーキテクチャー
    データベースに状態を保持し、アプリケーション・サーバーから切り離します(サーバー上のセッション・データでさえ避けます)。このようにして、必要に応じて簡単にアプリサーバーを追加できます。
  • フロントエンド(静的ファイル)キャッシングに重点を置く
    リバースプロキシを使用し、後でCDNで使用します。アプリサーバーからサービスを受ける必要がないものは、そのサーバーの負荷が少なくなります。
  • 実際のシステム
    ビルドイン監視を測定して、ボトルネックがどこにあるかを把握します。成長曲線に基づいて将来の負荷を予測できることを確認してください。
  • DB設計に注意する
    クエリを調整し、memcachedを使用してクエリをまったく行わないようにし、1つのDBインスタンスの空き容量がなくなったときにインスタンス間でデータをシャーディングします(これを事前に確認してください)。

いくつかの落とし穴:

  • NoSQL対SQLは、レッドニシンです。
    すべての大物がSQLデータベースでコアを実行しています。意味があると確信している場合はNoSQLを使用してください。ただし、スケーリングの問題を解決できると想定して使用しないでください。それはしません。
  • ORMに注意してください。
    アプリサーバーでは状態が重く(シェアードナッシングアーキテクチャと矛盾します)、SQLクエリを調整する方法だけでなく、SQLクエリの上にORMを調整する方法(つまり、パフォーマンスが重要でない場合のみ、物事を簡素化します)。代わりに、手動で設計したクエリとmemcachedの自由な使用を優先してください。
  • サーバー上の重いテンプレート/ルーティングシステム。サーバースタックは意図的に軽量にしてください。
  • 行ごとのコードのパフォーマンスについて心配する必要はありません。
    いつでもアクセスしてホットスポットを修正できます(xdebugまたは同様のプロファイリングツールを使用)。スケーラブルなアーキテクチャを持つことは、コードのパフォーマンスよりも重要なので、それに応じて頭脳力を投資します。

ORMに注意するための+1。アプリケーション層にORMを追加すると、DBクエリが4倍になり、DBが最大のボトルネックになります
CamelBlues '27

1

スケーラビリティの問題があるかどうかを確認する唯一の実際の方法は、それをテストすることです。そのため、Michael Borgwardtが言うように、早期にテストし、頻繁にテストします

それ以外に、システムがスケーリングしない一般的な理由は、リソースの競合です。そして、それは通常、データベースに表示されます-同時に読み書きしようとします。したがって、読み取り(クエリ)側と書き込み(コマンド)側を切り離すCQRSアプローチの使用を検討することをお勧めします。


1

すべてをシャーディングする準備をしてください。複数のホストに分割できる場合は、拡張可能な何かを構築することに非常に近いです。

また、100万人のユーザー向けに設計し、スケールダウンします。1,000ユーザー向けに設計してスケールアップしないでください。

正直なところ、PHPとMySQLは私の選択ではありません。MySQLでシャーディングされたデータを実行しようとすると、頭が痛くなります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.