クラウドの弾力性は、実際のワークロードの需要に合わせてリアルタイムでインフラストラクチャを調整します。手動介入と事前の容量計画を必要とする従来の IT インフラストラクチャとは異なり、エラスティック クラウド コンピューティングではリソースを自動的にスケール アップまたはスケール ダウンするため、トラフィックの急増時にはパフォーマンスを維持し、利用が少ない期間には無駄を回避できます。
クラウド コンピューティングの弾力性を理解するには、もはやインフラストラクチャを固定資産とする必要がなくなったことを認識することから始まります。
クラウド弾力性とは、リアルタイムの需要に基づいてコンピューティング リソースを自動的に調整するインフラストラクチャの機能です。トラフィックが増加すると、システムは追加のリソースをプロビジョニングします。需要が減少すると、スケール ダウンします。これは手動による介入なしで実行され、コストを制御しながらアプリケーションの応答性を維持します。
このメカニズムは、動的なリソース割り当てに依存します。クラウド プロバイダーは、ワークロード パターンを継続的に監視し、容量を追加または削除するタイミングを瞬時に決定し、必要に応じて拡張と縮小を行う柔軟なインフラストラクチャを実現します。
弾力性は、次の 2 つの方向で動作します:
垂直方向のスケーリング (スケール アップ/スケール ダウン): たとえば、仮想マシンの CPU やメモリを追加するなど、既存のリソースに処理能力を追加します。
水平方向のスケーリング (スケール アウト/スケール イン): たとえば、トラフィックを処理するために追加のサーバーをスピンアップするなど、インスタンス全体を追加または削除します。
従来のオンプレミス インフラストラクチャでは、この応答性は実現できません。物理サーバーには、調達、インストール、および構成が必要です。これらのプロセスには数週間から数か月かかることもあります。容量を追加した時点で、需要の急増が終わっているかもしれません。一方、クラウドの弾力性は、インフラストラクチャをソフトウェアとして扱います。これは、必要なときにすぐに使用でき、不要なときにはすぐに解放できます。
スケーラビリティと弾力性は、同じ意味で使用されることがよくありますが、それぞれクラウド インフラストラクチャの異なる側面に対処します。スケーラビリティは容量に関することです (リソースを追加して増加したワークロードを処理するシステムの能力)。弾力性とは、自動化と速度に関することです (これらの調整がどれだけ迅速かつ自動的に行われるか)。
スケーラビリティは、インフラストラクチャが成長できる可能性と考えてください。より多くのユーザー、トランザクション、またはデータに対応できるように拡張できるシステムを使用して、将来のニーズに向けた容量を構築していきます。このような拡張は、計画されたアップグレード、スケジュールされたリソースの追加、または予想される需要に基づく手動調整によって行われるでしょう。
エラスティック コンピューティングは、これをさらに先に進め、需要が発生したときに対応します。ピーク時の容量を計画し、それらのリソースを継続的に維持するのではなく、エラスティック システムはリアルタイムで調整します。それぞれの動作の違いは次のとおりです:
スケーラビリティの特性:
弾力性の特性:
クラウド環境では、これらの概念は相互に補完し合います。ビジネスの成長に合わせてアーキテクチャを成長させるにはスケーラビリティが必要であり、その成長を効率的かつコスト効率に優れたものにするには弾力性が必要です。
弾力性は、継続的な監視と自動化された判断に依存します。クラウド プラットフォームは、CPU 使用率、メモリ消費量、クラウド ストレージ容量、ネットワーク トラフィック、アプリケーション応答時間などのリソース使用状況メトリックを追跡します。これらのメトリックは、監視ツールに送られ、現在のパフォーマンスを定義済みのしきい値と比較します。
ワークフローは一貫したパターンに従います。監視システムは、数秒または数分ごとにインフラストラクチャからパフォーマンス データを収集します。メトリックが構成したしきい値を超えると、システムによってスケーリング アクションがトリガーされます。たとえば、CPU 使用率が 80% に達した状態が一定期間続くと、プラットフォームは追加のリソースをプロビジョニングします。使用率が 30% を下回ると、スケール ダウンされます。
これは、プロビジョニング プロセスを管理するオーケストレーション レイヤーを介して実行されます:
スケール アップ イベント中: システムは新しいコンピューティング インスタンスを起動し、ロード バランサーにアタッチし、トラフィックを追加された容量にルーティングします。アプリケーションは、数分以内に新しいリソースで要求の受信を開始します。
スケール ダウン イベント中: プラットフォームは使用率が低いリソースから接続をドレインし、不要なインスタンスを終了し、ワークロードを少数のマシンに統合します。
需要が通常の状態に戻ると、システムはベースライン容量に戻ります。小売アプリケーションは、通常の営業時間中には 5 台のサーバーで実行され、フラッシュ セール中は 20 台にスケーリングし、トラフィックが低下すると 5 台に戻る場合があります。
エラスティック システムの有効性は、構成によって大きく左右されます。しきい値を保守的に設定しすぎると、アイドル状態のリソースに余計な支出が発生し、厳しく設定しすぎると予期しない急増時にパフォーマンスが低下するリスクがあります。ポリシーは、スケーリングを行うタイミングだけでなく、どれだけの速さと量で実行するかを定義します。
クラウド コンピューティングの弾力性のビジネス ケースは、コスト、パフォーマンス、機敏性という 3 つの主要な要素に分類されます。
エラスティック インフラストラクチャを使用すると、実際に使用した時間分だけリソースの料金が発生するため、ピーク容量分を 24 時間支払い続けるという従来のモデルは排除されます。たとえば、月曜日から金曜日まで実行される開発環境は、週末に自動的にシャットダウンできます。午前 9 時から午後 5 時までがピークのトラフィックを記録するアプリケーションでも、夜間に容量が余ることはありません。
弾力性により、トラフィックが急増しても、アプリケーションの応答時間が遅くなったり使用できなくなったりすることなく、応答時間が維持されます。ユーザーは、通常の火曜日の朝に Web サイトにアクセスしても、ブラック フライデーの繁忙期に訪れても、同じエクスペリエンスを得られます。
IT チームがダッシュボードを監視し、リソースを手動で調整する代わりに、計画外の中断時を含め、インフラストラクチャが需要の変動を自動的に処理します。システムを復元する必要がある場合、エラスティック インフラストラクチャはリソースを迅速にプロビジョニングすることで ディザスター リカバリー戦略をサポートし、手動による介入を必要とせずにダウンタイムを短縮します。エンジニアは、日常的な容量管理に費やす時間を減らし、ビジネスを前進させるプロジェクトにより多くの時間を費やせます。
弾力性によって、市場機会や顧客のニーズに対応できるインフラストラクチャを実現できます。たとえば、マーケティング キャンペーンによって予期しないトラフィックが発生した場合、エラスティック インフラストラクチャは潜在的な顧客を逃すことなく受け入れられるようにスケーリングします。新しいサービスを迅速に導入したい場合も、長い調達サイクルを経ずに開始できます。
弾力性の利点は、組織全体で実感できます:
小売プラットフォームでは、年間を通じてトラフィックが大きく変動します。事業者によっては、ほとんどの月は安定したトラフィックを処理する一方、ブラック フライデー、サイバー マンデー、または年次セールの期間中に需要が何倍にも増加することがあります。エラスティック インフラストラクチャは、ハイブリッド環境のクラウド バーストなどのメカニズムを通じて、これらの時期的なピークのみスケール アップし、年間を通じてピーク容量を維持するコストを回避できます。
人気のあるシリーズの新しいエピソードを配信したり、ライブ イベントが始まると、何百万人もの視聴者が一斉に集まります。クラウドの弾力性により、日常的な視聴レベルに対して過剰なプロビジョニングを行うことなく、これらの急増期にもスムーズな再生体験を維持できます。
月末のレポート作成、四半期ごとの決算、年次の税務準備により、コンピューティング要件が予測可能な形で急増します。取引プラットフォームでは、市場の動きに合わせてボリュームが変動します。エラスティック システムは、これらの変動を自動的に処理し、処理ウィンドウ中にはスケール アップし、落ち着いている期間にはスケール ダウンします。
ビジネス生産性ツールは、勤務時間中に使用量が多く、夜間にはほとんど使用されません。これらのアプリケーションは、24 時間フル容量を維持するのではなく、タイム ゾーンごとにオフピーク時間帯にスケール ダウンできます。
エンジニアリング チームは、アクティブな開発スプリント中には多くのリソースを必要としますが、計画段階や休暇中ははるかに少ないリソースで済みます。エラスティック インフラストラクチャを使用すると、これらの環境は開発者が実際に必要な時期にのみ存在できるため、非運用ワークロードのコストを大幅に削減できます。
リモート従業員やハイブリッド従業員によるデスクトップの需要は、予測可能でありながら大きく変動します。従業員がそれぞれのタイム ゾーンのコア営業時間帯にログインすると、仮想デスクトップ インフラストラクチャ (VDI) 環境は、パフォーマンスを維持するために迅速にスケーリングする必要があります。その後、夜間にはスケール ダウンできるため、24 時間体制でフル容量を維持するコストを回避できます。
新しいテクノロジやアプローチが組織のインフラストラクチャの管理方法を再構築する中で、クラウドの弾力性は進化し続けています。いくつかの新しい傾向は、エラスティック システムがさらにインテリジェントで分散される未来を示しています。
現在のエラスティック システムは、需要が発生してから反応します。次世代のものは、トラフィック パターンが発生する前にそれを予測します。機械学習 (ML) モデルは、履歴データを分析して、スケーリング イベントが必要になるタイミングを予測し、反応的ではなくあらかじめリソースをプロビジョニングできます。これにより、需要の急増とリソースが使用可能になるまでのわずかなラグが短縮され、パフォーマンスがさらにスムーズになります。
サーバーレス アーキテクチャは、弾力性を論理的に突き詰めた形です。サーバーレス プラットフォームでは、仮想マシンやコンテナーをスケーリングする代わりに、個々の機能をスケーリングします。インフラストラクチャについてまったく考慮せずにコードを記述できます。プラットフォームはすべてのリソース割り当てを自動的に処理し、ゼロから数千の同時実行まで、そしてまたゼロまでスケーリングできます。このモデルは、エラスティック コンピューティングの究極形です。つまり、インフラストラクチャに関わる懸念事項からの完全な抽象化を意味します。
組織は、複数のクラウド プロバイダーとオンプレミス インフラストラクチャにワークロードを分散するようになっています。将来のエラスティック システムは、パブリック クラウド環境、プライベート インフラストラクチャ、オンプレミス システム全体でリソースを調整し、容量が最もコスト効率の高い場所または地理的に適切な場所にワークロードをスケーリングします。これにより、単一プロバイダーでは提供できない柔軟性が実現できます。
コンピューティングがエッジ インフラストラクチャを通じてユーザーに近づくにつれて、弾力性は分散アーキテクチャ全体で機能する必要があります。アプリケーションは、一元化されたデータ センターだけでなく、世界中のあらゆる場所にまたがってスケーリングし、コスト効率を維持しながら待機時間を短縮するためにユーザーの近くにリソースを動的に割り当てられるようになります。
これらの傾向は共通の方向性を示しています。弾力性をより自動化し、よりインテリジェントにし、アプリケーションの実行方法にシームレスに統合するということです。この機能は、構成しなければいけない機能から、意識しなくてもよい基盤的なインフラストラクチャの動作へと成熟していくでしょう。
Azure mobile app を入手する 
