急速な成長を目指す企業は、ウェブサイトやアプリなどのデジタル資産が利用者の活動急増に対応できるよう準備する必要があります。
アプリに必要な計算能力は、インストールされたサーバ(複数の場合は「サーバファーム」と総称)によって提供されます。しかし、一台のサーバで処理できる負荷には限りがあります。アプリの必要な処理能力が利用可能な資源を上回る場合、手動でサーバやシステムの規模を調整する手間を省くため、オートスケーリングが活用されます。
クラウドプラットフォームの機能の一つであるオートスケーリングは、アプリやワークロードへのトラフィック変動に応じて、展開中のサーバインスタンスの数を動的に増減させる仕組みです。
トラフィックの急増や急減が検出されると、クラウドは自動でインスタンス群に処理能力を追加または削減します。
そのため、新たなインスタンスを瞬時に追加することで、既存サーバが過負荷でダウンするリスクを軽減できます。
トラフィックが落ち着き、必要な計算資源が少なくなると、クラウドのオートスケーラーはインスタンスを停止して解放するように設定されています。
オートスケーリングはエネルギー消費を抑えることを狙いとしており、非常に重要です。サーバ負荷が低いときは、省電力モードにして電力を節約します。
この仕組みは負荷が変動するアプリに特に有用で、サーバの利用効率と可用性を向上させます。システム管理者が設定した制約の中で、計算マトリックス内のノードを自動的に組み合わせたり解除したりし、負荷を最適化します。
各クラウドサービスプロバイダーの料金体系は実際に消費されたサーバ時間に基づいているため、長期的にはコスト削減につながります。
オートスケーリングは、トラフィックに応じてクラウドサービスを即時に拡張する手法です。AWS、Azure、GCPなどがこの技術を提供しています。
需要の増減に合わせてインスタンスを繰り返し追加・削除することで、低コストかつ一定のパフォーマンスを実現します。動的で予測困難な負荷下でも、アプリの一貫性を保ちます。
サーバの数を自動調整することで、トラフィックの急増に対し即時に人力対応する手間を省き、各サーバの設定、監視、廃止作業が含まれます。
DDoS攻撃による急激な増加の検知は難しい場合もありますが、適切なオートスケーリングの指標と制御機能により、システムは迅速に対応できます。データベースはアプリのニーズに合わせ、容量を動的に増減、起動、停止します。
オートスケーリングを理解する前に、二つの戦略があることを知っておく必要があります。
横方向のスケーリングでは、特定のワークロードを処理するノード(またはKubernetesポッド)の数を増減させます。既存ノードの停止や変更が不要なため、新たな容量追加に適しています。この方法は縦方向のスケーリングよりも迅速ですが、全てのアプリやワークロードに適用できるわけではありません。
縦方向のスケーリングでは、既存ノードが利用可能なメモリや処理能力を増減させます。例えば、16GBのRAMと4仮想CPUを搭載したサーバが2台ある場合、縦方向のスケーリングで各台の能力を増強できます。特定の状況、例えばワークロードがない状態で構築されたリレーショナルデータベースでは、縦方向の拡張が唯一の方法となることもあります。
ただし、横方向の拡張に比べ、縦方向の拡張は自動化が難しいという側面があります。
オートスケーリングには、サーバが呼び出される方式により主に三種類あります。
サーバ負荷が比較的一定の場合に適用され、予測または先手のオートスケーリングプランにより、トラフィックが多い時に自動で追加サーバが起動されます。この形式では人工知能(AI)を活用し、トラフィック増加を「予測」して追加のサーバ資源を前もって「計画」します。
スケジュール型は、需要がピークとなる時刻に応じてあらかじめサーバを増設する点が予測型と異なります。自律的な予測型と比べ、人的な計画が必要となります。
管理者が設定した基準に達すると、自動で追加サーバが起動される仕組みです。例えば、主要サーバが1分間80%の負荷で稼働している場合に追加サーバが起動するよう設定されるなど、重要な性能指標に基づいてトリガーされます。
要するに、このオートスケーリングはシステムに流れ込むトラフィック量に応じて反応します。
スタティックに設定されたインスタンスと比べ、自動でスケールしない場合と比べると、オートスケーリング技術やサービスには多くの利点があります。その主なものは以下の通りです。
オートスケーリングがなければ、企業やクラウド利用者はトラフィックの変動や急増に対応するため、常に余分な資源を確保する必要がありました。必要な時に資源を増強し、負荷が下がると縮小することで、クラウド利用のコストを削減できます。
必要な資源を手動で追加する方法もありますが、この方法は拡張性や効率に欠けます。ポリシーに基づいて自動で動作するため、手動より効率的にスケール調整が可能です。
クラウド管理者は、ポリシーを設定することで、求める性能水準を定め、それを維持させることができます。
アプリの論理エラー、ハードウェアの不調、サービス内部の問題などさまざまな要因が障害を引き起こす可能性があります。オートスケーリングが有効な場合、ワークロードの健康状態と性能が常に監視され、需要に合わせて資源が自動的に交換・拡張されます。
資源を大量に消費するワークロードや、設計されたインスタンスの処理能力を超えるトラフィックが発生すると、クラウドサービスが利用不能になる恐れがあります。オートスケーリングにより、需要が急増してもサービスを継続できます。
オートスケーリングの一般的な活用例は以下の通りです。
オンラインショッピングの多くは営業時間内に行われるため、フロントエンドや注文システムは昼間に自動で拡張し、夕方に縮小するよう設計できます。また、APIセキュリティは、休暇や需要が増加する時期の準備をサポートします.
メディア企業が新たなコンテンツを発表すると、需要が予想以上に急増することがあります。このようなバイラルコンテンツには、必要な時に資源と帯域を提供できる点が役立ちます。
以前は、多くの顧客を獲得しようとする小規模企業にとって、コスト削減と急速な拡大の両立が大きな課題でした。Kubernetesのオートスケーリングは、スタートアップが低コストを維持しつつ、需要増加によるアプリサーバの故障リスクを低減する手助けをしています。
ロードバランサはアプリのオートスケーリングと連携して動作します。オートスケーリングとロードバランシングの両方が、サーバの健康状態の監視、トラフィック制御、サーバの追加や削除などのバックエンド作業を最小限に抑えます。オートスケール機能付きのロードバランサは広く利用されています。
これにより、アプリの可用性、パフォーマンス、レスポンスが向上します。アプリ要件に合わせ、オートスケーリングのポリシーを設定し、ロードバランサに各インスタンス間のトラフィック分配を指示することが可能です。
エラスティックロードバランサは、各ノードの健康状態を確認し、トラフィックを分散、リクエストをターゲットグループへ割り当てます。エラスティックLBは、トラフィックの流れを一時停止させ、データリクエストを再振り分けすることで、一つのインスタンスへの過負荷を防ぎます。
エラスティックLBを用いたオートスケーリングは、ロードバランサとオートスケーリンググループを連携し、全リクエストを均等に振り分けます。これにより、エンドポイントの数を監視する手間が省かれ、オートスケーリングとロードバランシングの違いが明確になります。
エンジニアが直面するオートスケーリングの問題点は以下の通りです。
オートスケーリングを実現するには、アプリのフロントエンド、バックエンド、データベース層、ロードバランサなど全てのインフラが自動的に連動する必要があります。
エンジニアはアプリをモノリシックではなくマイクロサービスとして構築し、横方向の拡張を可能にすべきです。また、アプリはステートレスでなければならず、ユーザリクエストが特定ノードに依存しない設計とする必要があります。NoSQLやリードオンリーデータベースは、リレーショナルデータベースよりも横方向のスケーリングに適しています。
最良の場合でも、ノードの起動に数分を要し、その間ユーザに遅延が発生することがあります。
エンジニアは正しい性能基準を見極める必要がありますが、これを正確に特定できるとは限りません。不正確な基準に基づくオートスケーリングは、ユーザ体験の低下を招く恐れがあります。
各クラウドサービスプロバイダーは、独自の方法やソフトウェアでサーバのオートスケーリングを実現しています。いくつかの例を見てみましょう。
Google Compute EngineはManaged Instance Groups (MIGs)を用いてオートスケールします。利用者はMIGを定義し、CPU使用率などの性能指標でグループ化、適切な上限を調整し、ワンクリックでオートスケーリングを有効にできます。
Amazon Web Services (AWS) には、AWSとEC2という二つのオートスケーリングサービスがあり、Launch templatesにより、Amazon EC2はインスタンス(例:VPCサブネット)の起動をサポートします。EC2利用者はインスタンス数を手動または自動で設定できます。
Microsoft Azureのオートスケーリングは、Azureクラウド利用者向けに資源を自動で調整し、VM、モバイル、ウェブサイトの展開をサポートします。
最新情報を購読