Web アプリを手動でスケーリングする
手動でスケール アウトし、再びスケール インすることで、予想されるトラフィックの増加と減少に対応できます。 スケール アウトすると、Web アプリのインスタンス数が増加するために可用性が高まるという、さらなるメリットが得られます。 1 つのインスタンスが失敗しても、Web アプリが使用できなくなることはありません。
ホテル予約システムでは、予想される繁忙期の前にスケール アウトすることができます。 繁忙期が終わって予約要求の数が減少すると、再びスケール インすることができます。
このユニットでは、Web アプリを手動でスケール アウトする方法と再びスケール インする方法を学習します。
App Service プランとスケーラビリティ
通常、Azure で実行されている Web アプリでは、Azure App Service を使用してホスティング環境が提供されます。 App Service では、Web アプリの複数のインスタンスを実行するように準備できます。 これらのインスタンス間で受信要求が負荷分散されます。 各インスタンスは、仮想マシンで実行されます。
App Service プランでは、各インスタンスで使用できるリソースが定義されます。 App Service プランでは、オペレーティング システム (Windows または Linux)、ハードウェア (メモリ、CPU 処理能力、ディスクの記憶域など)、および自動バックアップや復元などのサービスの可用性が指定されます。
Azure により、明確に定義された一連の App Service プランのレベルが提供されています。 このリストは、これらの各レベルを容量およびコストの昇順にまとめたものです。
- Free レベルでは、1 GB のディスク領域、最大 10 個のアプリのサポート、および共有インスタンスが 1 つのみ提供され、可用性の SLA は提供されません。 各アプリには、1 日あたり 60 分のコンピューティング クォータが備えられています。 Free サービス プランは、運用デプロイよりも、アプリの開発とテストに適しています。
- Shared レベルでは、より多くのアプリ (最大 100) のサポートが提供され、単一の共有インスタンスで実行されます。 アプリには、1 日あたり 240 分のコンピューティング クォータが備えられています。 可用性 SLA はありません。
- Basic レベルでは、無制限の数のアプリがサポートされ、より多くのディスク領域が提供されます。 アプリは、3 つの専用インスタンスにスケール アウトできます。 このレベルでは、99.95% の可用性の SLA が提供されます。 このレベルは 3 つのレベルから成り、レベルに応じて異なる量のコンピューティング パワー、メモリ、ディスク記憶域が提供されます。
- Standard レベルでは、無制限の数のアプリもサポートされています。 このレベルでは、10 個の専用インスタンスにスケーリングでき、99.95% の可用性の SLA が提供されます。 Basic レベルと同様に、このレベルは 3 つのレベルから成り、レベルに応じてパワーの異なるコンピューティング、メモリ、ディスクのオプション セットが提供されます。
- Premium レベルでは、最大 20 個の専用インスタンス、99.95% の可用性 SLA、複数のレベルのハードウェアが提供されます。
- Isolated レベルは、専用の Azure 仮想ネットワークで実行され、ネットワークとコンピューティングの分離が提供されます。 このレベルでは、100 個のインスタンスにスケール アウトでき、99.95% の可用性の SLA が提供されます。
Note
レベルによっては、一部のオペレーティング システムで利用できないものもあります。 たとえば、現在 Linux では Shared レベルを利用できません。
Web アプリを監視およびスケーリングする
Web アプリを作成する際には、新しい App Service プランを作成するか、または既存のプランを使用することができます。 既存のプランを選択した場合、同じプランを使用する他のすべての Web アプリは、ご利用の Web アプリとリソースを共有します。 これらはすべてまとめてスケーリングされるので、スケーリング要件が同じである必要があります。 アプリの要件がそれぞれ異なる場合は、アプリごとに独立した App Service プランを使用します。
スケール アウトするには、選択したレベルで可能な上限まで、App Service プランにさらにインスタンスを追加します。 Free レベルを使用していない場合は、インスタンスごとに時間単位で課金されます。 このタスクは、Azure portal で実行できます。
効率的なスケーリングのために重要となるのは、いつ、どの程度スケーリングを行うかです。 App Service に使用可能なメトリックを使用して、Web アプリのパフォーマンスを監視します。 このタスクを実行する最も簡単な方法は、Azure portal を使用することです。
CPU 使用率、メモリ占有率、ディスク キューの長さなど、リソースの使用量が着実に増加している場合は、これらのメトリックが臨界点に達する前にスケール アウトを検討する必要があります。 また、要求の平均応答時間、失敗した要求の数なども監視する必要もあります。 これらの数値が両方とも大きい場合は、実行中のシステムが容量の上限に近づいているか、上限を超えている可能性があります。 今すぐスケール アウトする必要があると考えられます。
これらのメトリックにより、システムの負荷が軽く十分な空き容量があると示されている場合は、コストを削減するために再びスケール インした方がよいでしょう。
どちらの場合にも、Web アプリの統計情報を継続的に監視する必要があります。 システムが安定するまで待ちます。 メトリックにより、アプリがまだパワー不足または過度であることが示される場合は、必要に応じてインスタンスを追加または削除します。