ベストアンサー
スケーラビリティとは、システムを比較的簡単に、当初または当初の意図よりも幅広いユーザーベースに適応できることを意味します。 。アプリケーションのスケーラブル性を決定する要因には、次のものがあります。
- 優れたプログラム構造（プログラムが理解し、新しい役割をサポートするために拡張するのがどれほど簡単か）
- プロビジョニング複数のユーザーとデータベースへの同時アクセスと編集（データベースのロックアップ、アクセス拒否、破損、データ損失を回避するため）
- ユーザーアクセスとデータベースの整合性の両方に対するセキュリティ対策
- 複数のサーバーおよび複数のタイムゾーンにまたがるデータベース上の分散アプリケーション
- データベースのバックアップ、修正、復元
- 言語と文化の規定
- サードパーティとの相互通信のプロビジョニング適切に管理されたプログラムインターフェイスを公開するか、業界標準にサブスクライブすることにより、アプリケーション
- リソースの使用状況とハードウェア/オペレーティングシステムの依存関係
- リアルタイムのパフォーマンス
特定のビジネスドメインに依存する他の要因がありますが、これらは私たちが日常的にiになる要因です企業がアプリケーションを「スケーリング」または「拡張」しようとすると、問題が発生します。
スケーラビリティは通常、次のいずれかまたは両方の場合に低下します。
- プログラムは、アプリケーション開発の分野に精通している
- プログラムを作成する責任は、顧客の将来のニーズに適したすべての要素を調査していない仕様と契約しています（仕様が弱いと、拡張性のないソリューションにつながることがよくあります） ）
- ビジネスドメインを理解している熟練したソフトウェアエンジニアによる監視はありません
拡張に失敗した簡単な例は、私が取り組んだ倉庫在庫プログラムです。 1990年（ish）。
元のプログラムは、1人のユーザー、1台のサーバー、および夜間のバックアップ用に作成されました（その間、システムは使用できませんでした）。連続した注文で、顧客は次のことを望んでいました。
- ユーザー数を1人から50人以上に増やし、各ユーザーにさまざまな役割とアクセス権限を付与します。
- 同じ国内の複数の倉庫をサポートするようにアプリケーションを拡張します
- 複数のタイムゾーン、言語、法的基準、および運用手順のサポートを意味する新しいオフショア倉庫を考慮に入れるようにアプリケーションを拡張します
元のプログラムは、このような強力なスケーリング要件に対応するように構成されたことはありませんでした。データベースは頻繁な「致命的な抱擁」のロックアップ、データの喪失、データベースのバックアップ手順による許容できないダウンタイムに悩まされていた。アプリケーションには「オフライン」データ入力の規定はなく、もちろん通信の問題に対してフォールトトレラントになるように書かれていなかった。プログラムを更新しようとすることも悪夢であることが判明しました。基本的に、グローバル更新をインストールするのにかかった数時間、システム全体が停止しました。
コンサルタントとして呼び出される前は、プログラム
パッチを適用すると、コードの構造と機能がわかりにくくなりましたが、プログラムが適切に構造化または文書化されたことはないと思います。これが会社にもたらすリスクを理解するのに十分な知識を持っている人は誰もいませんでした。コードはC ++で記述され、業界標準のマルチバイト文字セット（MBCS）文字列の代わりにバイト配列を使用していました…一般的な考え方がわかります！
私たちは「修正」するために呼び出されました問題。真実は、顧客を商用在庫管理製品に切り替える方が簡単で安価だったでしょうが、彼らはシステムに財務モデリングを深く組み込んでおり、これらの機能を商用に転送する方法について十分に理解していませんでしたプログラム（少なくとも重大なリスクなし）。
最終的に、より費用効果の高いソリューションを指摘したにもかかわらず、製品をリバースエンジニアリングし、アプリケーションを完全に書き直す必要がありました。製品を書き直すには、2人のシステム設計者、4人のリードエンジニア、20人のソフトウェアエンジニア、5人の検証、2人のツール/方法論エンジニアが必要でした。アプリケーションを一般リリースにするには、ほぼ2年の経過時間がかかりました。
スケーラビリティをどのように達成しますか？
- スケーラビリティ要件を製品仕様に記述していることを確認することから始めます。一般に、時間のプレッシャーと最低コストは、仕様で適切に義務付けられていない領域で犠牲を引き起こします。
- （おそらく）将来のニーズを満たす構造の開発を支援できるドメインの専門家と協力してください。
- スケーラビリティの問題を回避するためにゼロから作成されたデザインパターン、ライブラリ、4GL / AIアプリケーション、およびアーキテクチャを利用します（その多くは苦い経験から開発されました）。
- 並行性の高いアプリケーション向けの分散型のフォールトトレラントデータベース、組み込みセキュリティアーキテクチャ、データベースレプリケーション、クラウド処理など、すべての主要分野を確認してください。
- 必ず採用してください。重要なポジションにいる経験豊富で経験豊富なエンジニア。私たちが行った救助プロジェクトのほぼ50％は、経験の浅いリードエンジニアとシステム設計者の結果だったと思います。残りは、管理の失敗またはエンジニアリングと顧客間の不適切なコミュニケーションが原因でした。最近では、中規模から大規模な企業ではスケーラビリティの問題に対する言い訳はない。その後、会社は成長し、スケーラビリティは本来あるべき秩序だった進歩ではなく悪夢になります！
回答
ソフトウェアエンジニアリングのスケーラビリティとは、通常、次のような方法でソフトウェアシステムを設計することを指します。 、システムのユーザー数が増えると（100倍以上でも）、ソフトウェアは同等の応答時間で機能し続けます。さて、次の質問は「これはどのように達成されるのか」です。これは簡単なスケーラビリティの形式です。
クライアントサーバーおよびWebベースのソフトウェアシステムは、ただし、コンピューターであるサーバーに依存しています。複数のユーザーにサービスを提供します。 1つのサーバーが処理できる範囲を超えてシステムを拡張できるようにする2つの一般的な手法があります。高度にスケーラブルなシステムは、両方の手法を組み合わせます。
ープ1つ目は、機能をさまざまな部分に分割することです。一般的な分割の1つは、システムが依存するデータベースをホストするための別個のサーバーを用意することです（ほとんどの場合、永続的な情報を保持するための何らかのデータベースがあります）。データベースサーバーには、大量のメモリと非常に高速なディスクまたはRAIDアレイが提供されますが、他のタイプのサーバーでは、必要なメモリが少なく、ディスク容量が比較的少なくて済みます。
これは、n層アーキテクチャに拡張できます。ますます多くの機能（およびデータベースの場合はデータ）が異なるプロセス間で分割されます。負荷が増加すると、パフォーマンスを維持するためにプロセスが別々のサーバーに移行される。これらのサーバーはすべて物理的に同じサーバーファーム内にあり、非常に高速なネットワーク接続で接続されていることに注意してください。
スケーラビリティに使用される他の手法は、レプリケーションです。 。これは、複数のWebサーバーが使用され、各ユーザーがそのうちの1つにのみ接続されていることを意味する。より多くのユーザーをサポートするために、システムはより多くのハードウェアを必要とする（この例ではウェブサーバシステム）。データベースはレプリケーションも可能であるため、複数のデータベースサーバーがデータベースのクローンをサポートできます（データベースのさまざまなコピーを最新の状態に保つのは難しい場合がありますが、dbaはこの問題を何年も処理してきました）。大規模なシステムの場合、スケーラブルに設計されたデータベースがあり、データを複数のサーバーに分散します。
A2A：「ソフトウェアエンジニアリングにおける「スケーラブル」とはどういう意味ですか？」