私は現在約500,000人のユーザーがいるWebアプリケーションを持っており、1時間あたりの平均ページビュー数は約500であり、来年中には最大2,000万人のユーザーにスケールアップする必要があると予想しています。
現在のシステムではその規模を処理できないため、処理できるシステムに移行する必要があります。
私は、サービスベースのアーキテクチャがより堅牢になり、コンポーネントサービスを相互におよびメインアプリケーションから独立して拡張できるようになると考えていました。
しかし、拡張性の低いサービスアーキテクチャを簡単に設計できると警告されています。そのようなシステムの設計経験はほとんどないため、推奨されるリソースを確認する方が、単に「それを試してみるよりも良いでしょう。 「」
では、適切なスケーリングシステムを設計するために推奨されるリソースは何でしょうか。プラットフォームは.Netですが、プラットフォームに関係なく、同じ情報がすべてのサービスベースのアーキテクチャに当てはまると思います。
Ebayのアーキテクチャ原則のプレゼンテーションと、プレゼンテーションに関する優れた記事をお勧めします。実際、Ebay は典型的なサービス指向のアプローチを採用しました。サービスは関数ごとに抽出されるため、各サービスは個別にスケーリングできます。学べるポイントもあると思います。
理論的にはスケーリングしますが、レイテンシーに注意する必要があります。モジュールを外部化すると、1つではなく2つのサービスを利用できるようになりますが、外部サービスで1つのリクエストを送信、処理、返信するのにかかる時間で、100の内部リクエストを処理できた可能性があります。 100台のサーバーは実際にはスループットが低下しますが、どちらの場合も、100台のサーバーでは、メンテナンスとスペースにはるかに多くの費用がかかります。通常、大量のサーバーを送信する必要がある場合は、経験則として、レイテンシと処理のバランスを測定する必要があります。データの場合、そのステップをサービスに分割しない方がよい場合があります。幸いなことに、あなたはあなたが測定するための実行中のシステムを持っています、ほとんどの人はスペックだけからこれを推測しなければなりません。
したがって、データフローのパターンを考慮し、ローカリティを優先します。これは、アプリをサービスに分割することであり、それに反対することではありません。
要約すると、同時パターンについて読むことに興味があるかもしれません。