スケーラビリティと弾力性の違いは何ですか？
多くの人が両方の用語を同じ意味で使用していると聞きました。しかし、私の意見では、それらの間には違いがあります。
[〜＃〜] scalability [〜＃〜]-現在のハードウェアリソースのワークロードを増やすシステムの能力（scale up）;
[〜＃〜] elasticity [〜＃〜]-現在および追加の（オンデマンドで動的に追加される）ハードウェアリソースのワークロードを増加させるシステムの能力（スケールアウト）;
弾力性は、クラウド上にデプロイされたアプリケーションに強く関連しています。
これら2つの機能しないソフトウェアの特性に違いはありますか？誰かが具体的な例を挙げて、これら2つの用語の間に、より明確な境界線を引くことができますか？
スケーラビリティとは、リソースを追加するだけでハードウェアを強化する（スケールアップ）か、ノードを追加する（スケールアウト）だけで、システムがより大きな負荷に対応できることです。
弾力性とは、通常スケールアウトに関連して動的に負荷に対処するために必要なリソースに適合する機能です。そのため、負荷が増加すると、リソースを追加してスケーリングし、需要が減少すると、縮小して不要なリソースを削除します。弾力性は、従量課金制で、現在必要のないリソースに対しては支払いを望まず、一方で必要に応じて増大する需要に対応したいクラウド環境で最も重要です。
_
スケーラビリティ：「増加する」ワークロードに合わせて容量を「増加させる」。
弾性：「増加または減少」ワークロードを満たすために容量を「増加または減少」します。
スケーラビリティ：スケーリング環境では、「将来の需要」を満たすために利用可能なリソースが超過する場合があります。
弾性：弾性環境では、利用可能なリソースは「現在の需要」に可能な限り一致します。
スケーラビリティ：スケーラビリティは、リソースを「増分」方式で「プロビジョニング」することにより、「ワークロードの増加」のみに適応します。
弾性：弾力性は、「自律的」な方法でリソースを「プロビジョニングおよびプロビジョニング解除」することにより、「ワークロードの増加」と「ワークロードの減少」の両方に適応します。
スケーラビリティ：ワークロードの増加は、単一のコンピューターリソースの処理能力の増加、またはコンピューターリソースのグループによる処理能力の増加によって提供されます。
弾性：さまざまなワークロードは、コンピューターリソースの使用の動的なバリエーションで提供されます。
スケーラビリティ：スケーラビリティにより、企業は「長期的で戦略的なニーズ」を備えたサービスに対する期待される需要を満たすことができます。
弾性：弾性により、企業は「短期的で戦術的なニーズ」を持つサービスの需要の予期せぬ変化に対応できます。
スケーラビリティ：ワークロードが増加している環境にサービスを提供するためのキャパシティが「増加」しています。
このスケーラビリティは、「スケールアップ」または「スケールアウト」です。
（例：
スケールアップ-個々のサーバーの能力を向上させる
スケールアウト-個々のサーバーに複数のサーバーを追加することで機能を向上させます。）
弾性：自由にサービスを提供する能力を「スケールアップまたはスケールダウン」する能力です。
スケーラビリティ：スマイルを使用する場合、「スケールアップ」とは、増加する要求を満たすために力を高める個人のことであり、「スケールアウト」とは、増加する要求を満たすためのチームを構築することです。
弾性：映画業界のさまざまなニーズを満たすために、体重を増加または減少させる映画俳優の直を使用します。
_
通常、誰かがプラットフォームまたはアーキテクチャ scales と言うとき、ハードウェアコストは需要に比例して増加することを意味します。たとえば、1台のサーバーで50人のユーザーを処理できる場合、2台のサーバーで100人のユーザーを処理でき、10台のサーバーで500人のユーザーを処理できます。 1,000人のユーザーごとに2倍のサーバーが必要な場合、ユーザー数が増えるとすぐにお金がなくなるので、設計は not スケールすると言います。 。
弾力性は、アーキテクチャがリアルタイムでワークロードに adapt どれだけうまく適応できるかを示すために使用されます。たとえば、サイトに1時間ごとに1人のユーザーがログオンしている場合、これを処理するのに実際に必要なサーバーは1つだけです。しかし、突然50,000人のユーザーがすべて一度にログオンした場合、アーキテクチャはこの負荷を処理するために新しいWebサーバーをその場で迅速に（および場合によっては自動的に）プロビジョニングできますか？もしそうなら、あなたのデザインは elastic と言えるでしょう。
[〜＃〜] aws [〜＃〜] に関して：
スケーラビリティは、リソースがサイズまたは量を増減できることを意味します。
このようなことを実現するには、多くのインフラストラクチャが関与するため、簡単な作業ではありません。
AWSのサービスの多くはデフォルトでスケーラブルです。これがAWSが非常に成功している理由の1つです。
スケーラビリティの定義は非常に簡単です。そのため、弾性のいくつかの側面がスケーラビリティに起因することがよくあります。
弾性は、指定された基準（多くの場合 CloudWatch ルール）に応じてリソースがスケーリングできる能力です。
これは、Webアプリケーションが大量のトラフィックを取得するたびにロードバランサーがインスタンスを追加すると発生します。
スケーラビリティは弾力性に必要ですが、その逆ではありません。
すべてのAWSサービスが弾力性をサポートしているわけではありません。
冗長に見えるかもしれませんが、弾性で始まるAWSのサービスは弾性をサポートすることがよくあります。
-
resumeでは、スケーラビリティによりリソースを増減することができ、弾力性により設定されたルールに従ってこれらの操作が自動的に行われます。
それらの概念の私の限られた理解から、例：
5台のワークユニットを実行する5台のコンピューターのシステムがあるとします。もう1台のワークユニットを実行する必要がある場合は、もう1台のコンピューターを使用する必要があります。これはスケーラブルなシステムですが、弾力的ではありません。誰かが他のコンピューターを手に入れなければなりません。また、新しいコンピューターを購入し、余分なワークユニットが不要になった場合、システムは冗長リソースでスタックします。
ここで、同じシステムが独自のコンピューターではなく、ニーズに合ったクラウドサービスを使用しているとしましょう。理想的には、ワークロードが1つのワークユニット上にある場合、クラウドはシステムに別の「コンピューティングユニット」を提供し、ワークロードが下がった場合、クラウドはそのコンピューティングユニットの提供を正常に停止します。これは、システムがスケーラブルで弾力性のある状況です。
Elasticityは、計算能力、ストレージ能力、ネットワーク能力などに基づいてシステムの能力を増加（または減少）する能力です。システムの総負荷などの指定された基準。
たとえば、クラスター内に最初に1つのサーバーがあるバックエンドシステムを実装できますが、クラスター内のすべてのサーバーの1分あたりの平均CPU使用率が所定のしきい値（たとえば70％ ）。
同様に、システムの負荷が減少し、1分あたりの平均CPU使用率がユーザーが定義したしきい値（30％など）を下回った場合、バックエンドクラスターからサーバーを削除するようにシステムを構成できます。
別の例として、現在使用可能なストレージの合計の80％以上が使用されている場合、バックエンドクラスターの合計ディスク領域を2桁増やすようにシステムを構成できます。何らかの理由で、後でデータがストレージから削除され、使用済みストレージの合計が20％を下回る場合、使用可能なディスクスペースの合計を元の値に減らすことができます。
ただし、一部のシステム（レガシーソフトウェアなど）は分散されておらず、1つのCPUコアしか使用できない場合があります。したがって、オンデマンドで利用可能なコンピューティング能力を増やすことができても、システムはこの追加の能力をどのような形や形式でも使用できません。そのようなシステムはnotscalableです。しかし、scalableシステムは、システム全体のパフォーマンスに影響を与えることなく、計算容量を増やしてより多くの負荷を処理できます。
ただし、スケーラブルなシステムは弾力性に依存しません。従来、IT部門は、既存のサーバーをより多くのCPU、RAM、ストレージを備えた新しいサーバーに置き換え、システムを新しいハードウェアに移植して、利用可能な追加の計算能力を使用することができました。
クラウド環境（AWS、Azure、Googleクラウドなど）は弾力性を提供し、それらのコアサービスの一部はすぐに拡張可能です。さらに、スケーラブルなソフトウェアを構築する場合、これらのクラウド環境に展開でき、オンデマンドで利用可能なコンピューティングリソースを自動的に増減する弾力性のあるインフラストラクチャを利用できます。
弾力性は、サービスまたはアプリケーションの短期的な要件とそのバリエーションに関連していますが、スケーラビリティは長期的なニーズをサポートします。