アプリケーションをスケーラブルにするものは何ですか？

求人情報では、応募者が「スケーラブル」な申請書を作成した経験を持っている必要があります。アプリケーションをスケーラブルにする理由は何ですか？また、コードが何百万人ものユーザーに対応できることをどのように知るのですか

この質問を表現するより良い方法は、スケーラビリティを念頭に置いてコードを作成するにはどうすればよいでしょうか そのため、コードは後から考えるのとは対照的に、導入から拡張可能です。特定の設計手法はありますか？それとも、単に仕事に適したアルゴリズムを選ぶだけの問題ですか？

スケーラビリティには2つの方向があります。

• 垂直（別名、スケールアップ）：より高速なCPU、より多くのRAM、より多くのディスクスペース。
• 水平（別名、スケールアウト）：CPUのコア、CPU、サーバーを増やします。

最初のものは、arbitrary意的な制限がないように注意する必要があります。これらは、整数サイズが小さすぎるか、長さが固定または制限されているためです。これらの構造は、基盤となるOSに関連している可能性があります。たとえば、より多くのスレッドまたはプロセスを使用してスケールアップしようとすると、ある時点でOSの制限に到達することになります。そのため、現在、高いスケーラビリティのために構築されているサーバーは、非同期イベントに基づいて同時実行を行っています。この問題は有名なC10K文書で説明されています。

二番目はもっと難しいです。データを並列処理することと、データを物理的に分散させることの2つのことを念頭に置いてプログラミングする必要があります。ノード間の通信を制限する必要があります。実際には、通常、ACIDの一部を犠牲にすることを意味します（完全なACIDとスケールアウトの能力を同時に持つことはできないことが証明されています）。そのパラダイムで最もよく知られているデータストレージソリューションは、NoSQLソリューションです。それらは、非常に単純なキーと値のストアから、RDBMSに似た、結合を実行する能力が剥奪されたシステムにまで及びます。キーと値のストアは、超スケーラブルであるが、それは価格として提供されます。基本的には主キーでのみクエリできます。しかし、それに対する解決策があります、それはマップを減らす。累積的な複雑さの観点から見ると、非常に最適ではないように思えるかもしれませんが、超並列で実行されていることに留意する必要があります。

実際の例でスケーラビリティについて詳しく知りたい場合は、HighScalability.comブログをご覧ください。

スケーラビリティは、いくつかの変数に基づいてスループットの観点から測定されます。たとえば、Xユーザーの1秒あたりのリクエスト数。スケーラビリティを記述する最も簡単な方法は次のとおりです。

負荷が増加したときの効率の尺度。

スケーラビリティを設計する際に最初に理解する必要があるのは、アプリケーションにとって最も重要な測定値です。スケーラビリティの重要な要素である効率を測定する方法はいくつかあります。

• 1秒あたりの同時リクエスト
• リクエストごとの平均応答時間
• 1秒あたりの処理レコード数/分

使用できる効率測定値は他にもありますが、これらはWebベースのシステムまたはバッチ処理システムに共通です。

スケーラビリティの次の側面は、負荷が増加したときに効率がどうなるかを測定することです。負荷を増加させる一般的な方法は次のとおりです。

• サーバーにアクセスするユーザーが増える（つまり、Webトラフィックが増える）
• データベース内のデータが多い（クエリに時間がかかる、処理に時間がかかる）
• RAIDのハードドライブ障害（ストレージのパフォーマンス/信頼性に影響します）
• ネットワークの飽和

スケーラブルなアプリケーションの目標は、負荷の問題に対処するときに効率を維持または改善することです。要するに、応答時間が長すぎる場合、別のサーバーを追加して負荷を均等に分散できますか？このアプローチは、1台のサーバーが行う作業量を削減し、効率のためにサーバーをその「スイートスポット」で動作させ続けます。

アプリケーションは、特にスケールに合わせて設計する必要があります。つまり、セッションデータに注意し、要求を適切なサーバーにルーティングし、アプリケーションのスケーリング能力を制限するボトルネックを減らす必要があります。

基本的に、ユーザー数を増やしたり、より大きなデータセットを処理したり、より多くの言語でインターフェイスを提供したりする場合に、パフォーマンスのボトルネックを回避する必要があります。

基本的に、データベーススキーマ、アルゴリズム、およびソフトウェア開発プロセスを見て、将来の問題を予測しようとします。また、パフォーマンスモニタリングをセットアップして、問題が蓄積し始めるときに問題を特定することもできます。

スケーラブルなWebサイトの構築（Amazonへのリンク）を読んだときに、これらのヒントを取り上げました。

お役に立てれば！

アプリケーションを真にスケーラブルにする唯一の方法は、通過できない（または非常に高価な）制限がないことです。

典型的な例は、利用可能なCPUサイクルを使い果たすとどうなりますか？プログラムがマルチトレッドの場合、複数のコアを持つボックスで実行できますが、それ以上大きなボックスを購入できない場合はどうなりますか？アプリケーションは単純に成長できなくなるため、スケーラブルではありません。

真にスケーラブルなアプリケーションは、透過的な方法で複数のコンピューターに広がり、目立ったバンプなしでそれを行える必要があります。これは簡単なことではなく、Googleがこれほど成功した理由の1つです。

大規模なアプリケーションのサポートには固有の問題があります。求人情報は、その環境で働いており、そのような問題を解決しなければならなかった応募者を探しています。

高レベルのアプリケーションは、このコードがごく短い期間に何千回も実行されるように要求された場合にどうなるかを常に質問することにより、スケーラブルになります。つまり、メモリフットプリントの管理、合計とデータのキャッシュの利用、スケーラブルなデータソースの使用などを意味します。

DBに検索する行が100行あり、一度に10人のユーザーがそれを使用している場合に良好なパフォーマンスを発揮する検索機能を構築している場合。100人のユーザーが同時にそれを使用していて、検索する行数が10万行である場合、どれだけうまく機能しますか。

それが何であっても同じことを実行する場合、それは非常に良いです。ユーザー/データの量に比例して実行する場合（処理するデータが10倍多い== 10倍長いことを意味します）、それは良いことです。処理するデータが多いほどパフォーマンスが低下する場合（10xモードデータ== 10x ^ 10処理時間が長くなる）、適切にスケーリングされません。

私の例は、実際にはBig O表記で示されるべきですが、現在、Big Oで例を書くのに十分な知識がありません。

ダミーデータをDBにダンプすることで、より多くのデータをシミュレートできます。ApacheABなど、より多くのユーザーをシミュレートするツールがあります。