最近では、スケーラブルであることについて大きな騒ぎがあり、何百万ものリクエストを処理できるアプリケーションを構築しています。スケーラブルなアプリケーションの開発を支援することを目的としたライブラリは多数ありますが、結局のところ、アプリケーションをスケーリングする方法はわずかしかありません (ライブラリはそれらのラッパーを提供するだけです)。
それだ。その仮定は正しいですか？または、「スケーラブルな」アーキテクチャを実装する他の方法はありますか? 質問のポイントは、アプリケーションをスケーリングするためのセットが (基本的に) 限られており、ライブラリ/ツールがそれらを実装するのに役立つことを確認することです。
私が以前行ったことのある会社には、そのようなアーキテクチャがあったので、
その仮定は正しいですか？
私はイエスと思う。同社は比較的大きく、印象的なノウハウで運営されています。以下に示すように、最も重要な製品アーキテクチャの 1 つを考えることができます。
______________
-> API1: 1000
--------------
______________ ______________ ______________ | |
LoadBalancer -> API2: 1000 -> CacheServer -> | DB |
-------------- -------------- -------------- | |
______________
-> API3: 1000
--------------
スケーラブルなアーキテクチャは、N 層モノリシック アプリケーションで非常に一般的な結合の問題に対処する必要があり、SOA はこの問題を解決しようとしています。
非同期通信 (メッセージングを使用) を使用して分散し、(自律的な) コンポーネントを垂直にスライスし、リソース (データを含む) を共有しないことで、スケーラビリティと耐久性を実現できます。これは大きなトピックです...
Udi Dahan のブログを読むことをお勧めします。
NServiceBusは、SOA に合わせた 1 つのソリューションであり、スケーラブルで耐久性のあるシステムを構築するのに役立ちます。
ロードバランサーから一歩下がって個々のサーバーに入ります。
どのようなアプリケーションでも、使用するスレッド数を節約して、OS のスケジューラが最も優先度の高いスレッドを決定するために費やす CPU サイクルをできるだけ少なくする必要があります。これを行うためのメカニズムの 1 つは、Windows および一部の Unix フレーバーで見られる I/O Completion Ports です。SO で IOCP を検索してください。
共有リソース (通信、データベース、バス、RAM、L3 キャッシュなど) へのアクセスを節約し、非共有リソース (L2 および L1 キャッシュ) 内にスレッドとデータを収めようとすることで、アプリケーションのスケーラビリティが向上します。これらのアクセスが無視された場合よりも。マルチスレッド アプリケーションの実行速度がシングル スレッド アプリケーションよりも遅い例は数多くあります。
SOAP 形式または XML 形式の要求が何を行うべきかを判断することは、CPU を非常に集中的に使用します。テキストが多ければ多いほど、ジョブは大きくなります。アプリケーションがバイナリ リクエストを利用する場合、リクエストを実行するためにより多くのリソースが残され、リクエスト自体の理解に費やす時間が少なくなります。冗長な要求と応答のもう 1 つの側面は、通信帯域幅を食い尽くすという事実です。1 メガバイトの応答には、およそ 10 メガビットの帯域幅が必要です。これは、100 Mbps 接続の 1 秒間の容量の 10 分の 1 です。そのため、応答容量が毎秒最大 10 応答に制限されます。1万欲しい？10 kB 以内の応答が必要です。
アプリケーションが十分に高速な場合、リクエストの一部を実行するために別のサーバーに移動する必要がある場合、アプリケーションは停止します。これは、ファイバー相互接続にも当てはまります。SAN は、物理的に接続されたストレージよりも低速です。