求人情報で、応募者は「スケーラブルな」アプリケーションの作成経験が必要であることがわかります。アプリケーションをスケーラブルにする理由と、コードが数百万のユーザーに拡張できることをどのように知ることができますか？
この質問を表現するより良い方法は、次のとおりです。スケーラビリティを備えたコードを作成するにはどうすればよいですか。念頭に置いて？そのため、コードは後から考えるのではなく、最初からスケーラブルです。特定の設計手法はありますか？それとも、単にジョブに適したアルゴリズムを選択するだけの問題ですか？
回答
スケーラビリティには2つの方向があります。
- 垂直（別名スケールアップ）：より高速なCPU、より多くのRAM、より多くのディスクスペース;
- 水平（別名スケールアウト）：CPUのコア数、CPU数、サーバー数;
1つ目は、任意の制限がないように注意する必要があります。これらは、整数サイズが小さすぎるか、構造が固定/制限されているためです。これらの構造は、基盤となるOSに関連している可能性があります。たとえば、より多くのスレッドまたはプロセスを使用してスケールアップしようとすると、ある時点で「OSの制限に達する」ことになります。そのため、現在、高スケーラビリティのために構築されているサーバーは、非同期イベントに基づいて同時実行を行っています。この問題は、有名な C10Kで説明されています。 ドキュメント。
2つ目はもっと難しいです。2つのことを念頭に置いてプログラミングする必要があります。データは並列処理され、データはノード間の通信は制限する必要があります。実際には、通常、ACIDの一部を犠牲にすることを意味します（完全なACIDとスケールアウト機能を同時に持つことはできないことが証明されています）。データの最もよく知られているソリューションそのパラダイムのストレージは、 NoSQL ソリューションです。これらは、非常に単純なキー値ストアから、RDBMSのような、結合を実行する機能を取り除いたシステムまでさまざまです。キー値ストアは非常にスケーラブルですが、それは代償として発生します。基本的にはプライマリキーでのみクエリを実行できます。ただし、解決策はあります。つまり、マップリデュースです。累積的な複雑さの観点から見ると、非常に最適ではないように見えるかもしれませんが、超並列で実行されていることを覚えておく必要があります。
実際の例でスケーラビリティについて詳しく知りたい場合、 HighScalability.com ブログをご覧ください。 p>
コメント
- スケールアウトについて言及するための+1。リソースを追加することは、意思決定者にとって非常に迅速で魅力的です（いくつかの16進コアを購入し、メモリを2倍にします！ ）。しかし、アプリケーションが'それらに圧力をかけることができない場合は、より大きな問題が発生します。
回答
スケーラビリティは、いくつかの変数に基づいてスループットの観点から測定されます。たとえば、 X ユーザーの1秒あたりのリクエスト数。スケーラビリティを説明する最も簡単な方法は次のとおりです。
負荷の増加に伴う効率の指標。
スケーラビリティを設計する際に最初に理解する必要があるのは、アプリケーションにとってどの測定が最も重要かということです。スケーラビリティの重要な要素である効率を測定する方法はいくつかあります。
- 1秒あたりの同時リクエスト数
- リクエストあたりの平均応答時間
- 1秒/分あたりに処理されるレコードの数
使用できる効率測定は他にもありますが、これらはWebベースのシステムまたはバッチ処理システムで一般的です。
スケーラビリティの次の側面は、負荷が増加したときに効率がどうなるかを測定することです。負荷を増やす一般的な方法は次のとおりです。
- サーバーにアクセスするユーザーが増える（つまり、Webトラフィックが増える）
- データベース内のデータが増える（つまり、クエリに時間がかかる、または処理に時間がかかる）より長い）
- RAIDのハードドライブ障害（ストレージのパフォーマンス/信頼性に影響があります）
- ネットワークの飽和
スケーラブルなアプリケーションの目標は負荷の問題に対処する際に、効率を維持または改善するため。つまり、応答時間が長すぎる場合は、別のサーバーを追加して負荷を均等に分散できますか？このアプローチにより、1台のサーバーが実行する作業量が削減され、効率を高めるためにサーバーがその「スイートスポット」で動作し続けます。
アプリケーションは、拡張できるように特別に設計する必要があります。セッションデータに注意し、要求を適切なサーバーにルーティングして、アプリケーションの拡張機能を制限するボトルネックを減らす必要があります。
回答
基本的に、ユーザー数を増やしたり、より大きなデータセットを処理したりするときのパフォーマンスのボトルネックを回避する必要があります。 、および/またはより多くの言語などでインターフェースを提供します。
基本的に、データベーススキーマ、アルゴリズム、およびソフトウェア開発プロセスを調べて、将来の問題を予測しようとします。また、パフォーマンスモニタリングを設定して、問題が発生し始めたときに問題を特定する必要があります。
これがお役に立てば幸いです！
回答
アプリケーションを使用する唯一の方法真にスケーラブルである可能性があります。これは、通過できない（または非常に高価な）制限がないことによるものです。
典型的な例は、使用可能なCPUサイクルが不足した場合にどうなるかです。プログラムがマルチトレッドの場合、複数のコアを備えたボックスで実行できますが、より大きなボックスを購入できなくなった場合はどうなりますか？アプリケーションは単純に拡張できなくなるため、スケーラブルではありません。
真にスケーラブルなアプリケーションは、複数のコンピューターに透過的に分散でき、目立った問題が発生することなく拡散できる必要があります。これは簡単なことではなく、Googleがこれほど成功した理由の1つです。
回答
固有の問題があります大規模なアプリケーションのサポートが付属しています。求人情報は、そのような環境で働き、そのような問題を解決しなければならなかった応募者を探しています。
高レベルのアプリケーションから」は、このコードが非常に短い期間に数千回実行されるように要求された場合にどうなるかを常に質問することでスケーラブルになります。これは、メモリフットプリントの管理を意味します。 、合計とデータのキャッシュを利用する、それ自体がスケーラブルなデータソースを使用するなど。
回答
検索するDBに100行あり、一度に10人のユーザーが使用する場合にパフォーマンスが向上する検索機能を構築します。100人のユーザーが同時に使用し、検索する行が10万行ある場合のパフォーマンスはどれくらいですか。
何があっても同じように機能する場合は、非常に優れています。ユーザー/データの量に比例して機能する場合（つまり、処理するデータが10倍多い== 10倍長い）、それは良いことです。データが多いほど（10xモードデータ== 10x ^ 10処理時間が長くなります）、拡張性が低くなります。
私の例は実際にはBigO表記で表示されるはずですが、私はcuです。 Big Oで例を書き出すのに十分な知識はありません。
ダミーデータをDBにダンプすることで、より多くのデータをシミュレートできます。また、ApacheABなどのより多くのユーザーをシミュレートするツールがあります。