スケーラビリティとは、増加する負荷にソフトウェアが適応する能力を指します。システムが処理できる同時ユーザー数とリクエスト数を決定します。リアルタイムの音声、ビデオ、またはチャットアプリケーションをスケーリングするには、スケーラブルなソフトウェアが不可欠です。スケーラビリティがなければ、運用が制限され、その結果、収益も制限されます。それはまた、企業が貴重な機会を失うことを意味します。
たとえば、eコマースサイトが大規模なセール中に100,000人の同時ユーザーに対応するように拡張できないとします。その場合、スケーラビリティの欠如は、システムのスローダウンによる売上の損失や顧客体験の低下につながります。さらに重要なことに、スケーラブルなソフトウェアアーキテクチャは、システムのスローダウンによるセキュリティ上の欠陥や悪用を防ぐのに役立ちます。
スケーラビリティには、水平スケーラビリティと垂直スケーラビリティの2種類があります。
水平スケーラビリティ(スケール アウト) は、より多くのコンポーネントまたはリソースをシステムに追加して、より大きな需要に対応するアプローチです。たとえば、企業は既存のサーバーと一緒にサーバーを追加して、システムの負荷を共有することができます。水平方向のスケーリングは、アプリケーションをスケーリングする最も簡単な方法ですが、最もコストがかかります。また、ハードウェアを追加することはより困難であり、維持するためのコストも高くなります。
もう1つのタイプのスケーラビリティは垂直スケーリングと呼ばれ、アプリの既存のコンポーネントの容量またはパフォーマンスを向上させます。垂直方向のスケーリングは、ハードウェアへの大きな投資を必要としないため、水平方向のスケーリングよりも安価です。ただし、垂直スケーリングは複雑になる可能性があります。さらに、互換性の問題や積み重なったコンポーネントがシステムのパフォーマンスに影響を与え、出力がより遅くなる可能性があります.
このように、スケーラビリティは主にハードウェアの問題です。サーバーを追加したり、コンポーネントをアップグレードしたりすることで、アプリケーションをスケーラブルにすることができます。ただし、ソフトウェアで解決することもできます。優れたプログラミング手法を使用してコードを最適化し、コードをより効率的に実行して、消費するリソースを減らし、同時により多くのユーザーに対応することができます。
もう1つの適切なアプローチは、クラウドベースのソリューションを使用することです。これらのプラットフォームでは、必要に応じてリソース (CPU やストレージなど) を割り当てるだけで垂直方向のスケーリングが容易になるからです。また、アプリケーションを柔軟かつスケーラブルにすることもできます。しかし、2つの違いは何でしょうか？
スケーラビリティの議論は、弾力性に言及せずには完了しません。これは同様の指標ですが、意味が少し異なります。
スケーラビリティは、時間の経過とともに徐々に増加するシステムの負荷に関係しています。たとえば、企業が着実に顧客を増やしている場合、追加された需要に対応するために Webサイトをスケールアップする必要があります。多くの点で、スケーラビリティは、システムが対応できるワークロードのしきい値を設定します。また、本質的にプロアクティブです。中断のない運用を確保するために、実際に必要になる前に、スケールアップして将来の需要を考慮する必要があります。
一方、弾力性は、動的ワークロードを考慮してリソースを増減するシステムの能力です。言い換えれば、需要の急激な急増や急落に適応するシステムの柔軟性を指します。たとえば、eコマースアプリでは、ブラックフライデーやクリスマスなどのピーク時には50,000人の同時ユーザーがいるかもしれませんが、それ以外の時期には 5,000 ユーザーしかいません。この場合、柔軟なシステムは、需要が高いときにリソースを割り当て、需要が低いときにそれらを解放できます。
使用ごとに課金されるクラウドベースのシステムを使用する場合、弾力性は不可欠です。これにより、負荷が低い期間にアイドル状態のリソースに過大な支払いが発生しないことが保証されます。また、より多くのリソースを必要とするアプリケーションにリソースを割り当てるのにも役立ちます。
弾力性とスケーラビリティの違い (およびそれが適用される場合) を知ることは非常に重要です。それらに対処するには2つの異なるソリューションが必要だからです。
スケーラブルなアーキテクチャには、サーバーの追加や既存のマシンの仕様の改善など、「従来の」スケーリング方法が必要です。いずれの場合も、システムの負荷容量を永続的に増やします。
エラスティックアーキテクチャには、リソースのリアルタイム割り当てが必要ですが、これは特定のソリューションで実現できます。すべてのクラウド サービスがそれをサポートしているわけではありません。多くの場合、最初にサポートするものを構成して、弾力性を持たせる必要があります。
最後の比較として、弾力性のあるシステムはスケーラブルでなければなりませんが、スケーラブルなアーキテクチャは必ずしも弾力性があるとは限りません。
スケーラビリティテストは、さまざまなユーザー負荷でアプリケーションまたはシステムがどの程度うまく機能するかを測定する非機能ソフトウェア テストです。その目標は、システムが予測された負荷で壊れるかどうかを調べ、それを修正できるように洞察を明らかにすることです。
多くの場合、スケーラビリティ テストは、ユーザー、トランザクション、プロセス、およびその他のシステム負荷の追加による拡張の増加を見越して行われます。ウェブサイトやアプリが中断されずに実行されるようにするために、改善点を特定するのに役立ちます。
スケーラビリティテストは、負荷容量に基づいてアプリケーションのパフォーマンスを評価する負荷テストに似ています。ただし、両者には重要な違いがあります。
負荷テストとは、システムに一度に最大負荷をかけることで、システムの限界点を見つけることです。その主な関心事は、パフォーマンスの問題を特定することです。
一方、スケーラビリティ テストは段階的に行います。システムが特定の負荷レベルでそのように動作する理由を理解し、それを改善するための洞察を提供したいと考えています。主な関心事は、システムが目標数のユーザーまたはトランザクションにどのように対応できるかを調べることです。
スケーラビリティ テストには、上向きと下向きの2種類があります。
アップワードテストでは、アプリケーションが限界点に達するまで仮想ワークロードをアプリケーションに追加します。これは、システムが処理できる最大容量を決定するのに役立ちます。
ダウンワードテストはその逆です。最初は高いワークロードで開始し、最適な負荷レベルに達するまで徐々に減らします。多くの場合、下方テストは上方テストの後、またはアプリケーションが最初のスケーラビリティ テストに失敗した場合に実行されます。
このプロセスがビジネスの成功にとって非常に重要なのはなぜでしょうか? 定期的なスケーラビリティテストのビジネス上の利点のいくつかを見てみましょう。
ソフトウェアを起動したり、より多くのユーザーに対応するために拡張したりする前に、バグを早期に検出して修正するのに役立ちます。これにより、より洗練された製品が得られるだけでなく、コストの削減にも役立ちます。1-10-100 ルールによると、エラーを修正するための価格は、開発中は10 倍、ソフトウェアの起動後は最大で100倍になります。
スケーラビリティ テストは、予測される需要を満たすために必要な正確なコンピューティングリソースを決定するのにも役立ちます。これにより、新しいハードウェアやインフラストラクチャへの投資に対する過剰な支出を防ぐことができます。
最終的に、スケーラビリティテストは、最高のユーザーエクスペリエンスを提供することがすべてです。負荷が高すぎるシステムによるクラッシュ、無応答、速度低下は、顧客に悪影響を及ぼす可能性があります。その結果、顧客はあなたの製品を完全に放棄する可能性があります.
スケーラビリティテストは、システムをテストし、その応答性を確認するのに役立ちます。これにより、積極的にパフォーマンスのボトルネックを即座に特定できるため、ピーク シーズンの前に解決できます。
スケーラビリティ テストには、特に大規模なアプリケーションの場合、より多くの時間と費用がかかります。詳細なテストは完了するまでに長い時間がかかる可能性があり、アプリケーションの起動が遅れたり、予算を超えたりする可能性があります。これらの短所があるため、スケーラビリティをテストする前に確固たる理由があることをお勧めします。何十万もの同時ユーザーを獲得するエンタープライズ ソフトウェアは良い候補ですが、ユーザーが限定された単純なアプリはそうではないかもしれません。
スケーラビリティ テストは完全なソリューションではないことに注意してください。テスト環境は、運用環境を 100% ミラーリングすることはできません。事前にわからない、または完全に再現できない現実の状況が常に存在します。
いずれの場合も、これらの「未知の」負荷により、実際よりも優れたテスト結果が得られる可能性があります。これは、スコープが限定されているスケーラビリティ テストや、間違ったメトリックを測定している場合にも当てはまります。これらは、長期的にはより多くの害を引き起こす誤った結果をもたらす可能性があります。
スケーラビリティテストで評価できるさまざまな項目があります。何を選択するかは、アプリケーションとインフラストラクチャの性質によって異なります。一般的な指標には次のものがあります。
応答時間は、ユーザーがアクション (ボタンのクリックやフォームの送信など) を実行してから、アプリケーションから応答を受け取るまでの遅延です。
応答時間の最も基本的な尺度は、ユーザーがリンクをクリックしたり、ブラウザにURLを入力したりしてから、Web ページが読み込まれるまでの時間です。これは、ユーザーエクスペリエンスに大きな影響を与える応答性を測定するため、おそらくスケーラビリティ テストで最も重要な指標の1つです。応答時間が長いと、アプリケーションの動作が遅くなり、「バグがある」ように見えます。
応答時間が長くなる最も一般的な原因はサーバーの遅延であるため、通常、スケーラビリティテストではこれを調査します。具体的には、応答時間が短くなりすぎる前に、ネットワークが耐えられる最大ユーザー数を決定することが目標です。
一般に、ユーザー数が多いほど、応答時間は長くなります。サーバーは大量の同時ユーザー要求を処理するのに苦労しているため、これは理解できます。ユーザーが地理的にサーバーから離れた場所にいる場合も、応答時間の遅延が発生する可能性があります。
通常、ワークロードは複数のサーバー間で分散されるため、クラウドまたはハイブリッド環境では応答時間がわずかに異なります。このような場合、スケーラビリティテストでは、ロードバランサーの有効性を測定して、サーバーが過多のリクエストで過負荷にならないようにします。
このような分散アーキテクチャで各サーバーコンポーネントの応答時間を測定することも価値があります。そうすれば、アプリケーションの負荷に関係なく、全体的な応答時間を測定できます。
高い応答時間を改善する最善の方法は、コンテンツ配信ネットワーク (CDN) を使用するなど、ネットワークを最適化することです。これは、データを世界中に分散させることで機能し、ユーザーとサーバーの間の地理的な距離が大きいことによる遅延を軽減します。
不必要に長く複雑なコードも、応答時間を長くする可能性があります。数秒の遅延でさえ、何千人ものユーザーが乗算され、大幅な速度低下を引き起こす可能性があります。コードとスクリプトを最適化および縮小すると、サーバーの処理と応答時間が短縮されます。
スループットは、アプリケーションが設定された期間に処理できる要求またはプロセスの数を測定します。これは、アプリケーションの性質によって異なります。
たとえば、Web サイトでは、サーバーが 1時間に処理できる Web ページ要求の数としてスループットを参照する場合があります。一方、データベースは、1分間に処理できる
SQLクエリの数としてスループットを測定できます。
一般に、システムにかかるサーバーの負荷に関係なく、スループットは変化しません。例えば、1分間に10人の顧客にサービスを提供できるファーストフードレストランです。何千人もの顧客が外に並んでいても、安定した速度で「処理」できる必要があります。したがって、スケーラビリティ テストを行う際、開発者は多くの場合、アプリケーションがさまざまな負荷で満たす必要があるスループットの目標を定義します。
スケーラビリティテストは、アプリケーションの上限または最大スループット制限を見つけるためによく使用されます。ここでは、スループットが均等になり安定するまで、仮想ユーザーが着実に追加されます。しかし、低下し始めた場合は、より深刻な問題またはアプリケーションのボトルネックを示している可能性があります。
例を挙げます。スケーラビリティテストを行っていて、ある時点でスループットが劇的に低下したとします。さらに調査を進めると、ドロップ時にシステムのデータベースレイヤーでスローダウンが発生していたことが明らかになりました。このシナリオでは、データベースがスループットレベルを低下させるボトルネックです。
このように、不安定なスループットは、多くの場合、注意が必要な根本的な問題の兆候にすぎません。
メモリ使用量は、アプリケーションがタスクごとにユーザーごとに消費するRAMの量を測定し、ギガバイトやテラバイトなどのバイト単位で測定されます。これは、アプリケーションがシステム リソース (RAM) をどの程度効率的に使用しているかを測定するための、リソース使用率のメトリックです。
メモリ使用量は、アプリケーションの速度と応答性を判断できる重要な指標です。システムのメモリが不足すると、プログラム全体の速度が低下したり、クラッシュしたりする可能性があります。メモリ使用量がわずかに増加しただけでも、複数のユーザーで増加すると悪影響を与える可能性があります。
メモリ使用量の問題を修正するには、2つの側面があります。
一方では、メモリ使用量は主にベストプログラミングプラクティスに関するものです。開発者は、メモリの消費が最小限になるようにアプリケーションをコーディングする必要があります。たとえば、アプリケーションコードはデータベースへのSQLクエリを最適化して、RAMの使用率や冗長な呼び出しを最小限に抑える必要があります。
反対に、メモリ使用量はすべてハードウェアに関するものです。システムメモリは、限られた数の同時ユーザー要求またはトランザクションのみをサポートできます。スケーラビリティ テストは、この制限を見つけることを目的としています。このしきい値に達すると、システムをさらにスケーリングするには、RAMまたはデータベース ストレージを追加する必要があります。
CPU使用率は、アプリケーションが動作するために必要な処理能力を測定し、メガヘルツ (MHz) などのヘルツ単位で測定します。
CPU使用率は、メモリ使用率と同様のメトリックです。まず第一に、どちらもアプリケーションのシステムリソースの使用効率を評価するリソース使用率の指標です。また、CPU 使用率が高いとアプリケーションの速度が低下したりクラッシュしたりする可能性があるため、ユーザー エクスペリエンスにも直接影響します。最悪の場合、システムのCPUの寿命を縮める可能性があります。
不適切なプログラミング方法も、メモリと同様にCPUの過剰使用を引き起こします。たとえば、「デッド」コードやスレッドを使用すると、ソフトウェアが不要な処理能力を使用する可能性があります。
ただし、メモリと同様に、CPUは限られたリソースであり、一定量のタスクとユーザー要求しか処理できません。サーバーコンポーネントをアップグレードまたは追加すると、CPU 使用率が分散され、パフォーマンスが向上します。
ネットワーク使用量は、アプリケーションが使用する帯域幅を決定するメトリックであり、1秒あたりのバイト数 (Bps) で測定されます。
スケーラブルなアプリケーションでは、大量のユーザーリクエストがあっても、ネットワークの使用を最小限に抑える必要があります。これが過剰な場合、ネットワークの輻輳が発生し、応答時間が長くなり、ユーザーエクスペリエンスが低下する可能性があります。
多くの場合、ネットワークの使用を改善するには、プログラミングの実践が必要です。たとえば、圧縮アルゴリズムは、アプリケーションがネットワーク経由で送信するデータサイズを縮小し、帯域幅の使用を最小限に抑えることができます。
スケーラビリティテストは、ネットワーク使用量の劇的な急増を検出するために重要です。これにより、さらに調査して解決することができます。ただし、ネットワークの輻輳は、使用しているネットワークの種類など、制御できない変数によって引き起こされることもあります。これらを排除するには、さまざまなネットワーク条件でスケーラビリティ テストを実行することが不可欠です。たとえば、4G、5G、およびWi-Fiネットワークのテストシナリオが必要です。
スケーラビリティ テストには通常、次の4つの手順が含まれます。
リアルタイムコミュニケーションは、スケーラビリティが重要なアプリケーションの1つです。ただし、ビデオの遅延や通話の遅延をユーザーに経験させたくない場合は除きます。Agoraは、優れたユーザー エクスペリエンスを備えたシームレスなリアルタイムボイス チャットおよびビデオ チャット機能を提供するリーダーです。Agoraのハイパースケーラビリティにより、アプリケーションはトラフィックの突然のスパイクに耐え、ライブ ビデオ ストリーミング中に1人から数百万人の同時ユーザーにスムーズにスケーリングできます。
Agora のグローバル エッジ ネットワークを使用して、アプリケーションを拡張し、世界中のどこにいても任意の数のエンド ユーザーをサポートします。アプリケーションと対象ユーザーを増やすことは困難です。アプリケーションがシームレスに動作することを確認してください。