容量計画に関する考慮事項

基本的な容量計画は簡単な計算から始まりますが、プロセスを複雑にする要因があります。 単純な現在の使用量と予測される使用量に加えて、次の考慮事項も考慮する必要があります。

• サービスの制限とクォータ
• コストの制限事項
• コードと構成の非効率性
• 依存関係

このユニットでは、これらの考慮事項が容量計画に与える影響と、それぞれの対処方法について説明します。

サービスの制限とクォータ

クラウド コンピューティングは無制限のリソースと見なされる傾向があります。 従来のサーバー/データセンター モデルと比較すると、クラウドの容量は無限に見えます。 クラウドでは、まったく新しいレベルのスケールが提供されます。 ただし、他のすべての場合と同様に、いくつかの制限があります。 容量計画では、これらのサービスの制限に達するタイミングを理解する必要があります。

システムとそのアーキテクチャを確認するときは、使用しているクラウド サービスの制限を理解する必要があります。 たとえば、既定では、Azure では VM の可用性セットごとに最大 1000 台の VM とすることができます。 この制限は、開始したばかりの場合には、VM の数として十分すぎるように思えることがあります。 ただし、この制限に達すると、それ以上 VM をプロビジョニングできないため、停止が発生する可能性があります。

同様に、既定では、リージョンごとにサブスクリプションあたり 250 個のストレージ アカウントを使用できます (この制限はサポート要求を通じて増やすことができます)。 これらの制限はどちらも、増加できるソフト制限の例です。 ただし、一部のサービスには上限があり、次のリンクから確認できます。

Azureサブスクリプションとサービスの制限、クォータ、制限条件

これらの制限とクォータは、注意して監視する必要があります。 これを行う方法を見てみましょう。

Azure ポータル

サービス クォータと、それらの制限に関連する場所は、ナビゲーション ウィンドウの [ の [>] セクションで確認できます。 ネットワーク/コンピューティング、Azure リージョンなどのサービス カテゴリでフィルター処理できます。 制限に違反している場所が表示されます。

&Azure ポータルで見つかったサービス制限の情報を表示するさまざまなリソースとそのクォータの表のスクリーンショット

コードを使用する

この切り捨てられた例に示すように、Azure サービスに対して Usage - List エンドポイントを使用して、現在のリソース使用状況情報と、サブスクリプションのコンピューティング リソースの制限を取得できます。 最新の安定した API バージョンについては、Azure REST API リファレンスを確認してください。

GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/{location}/usages?api-version=2024-07-01
{ 
    "currentValue": 12,
    "id": "/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/westeurope/usages/virtualMachines",
    "limit": 25000, 
    "name": { 
        "localizedValue": "Virtual Machines",
        "value": "virtualMachines" 
    }, 
    "unit": "Count" 
}

現在使用されている仮想マシンの数は、25,000 の制限に対して 12 であることがわかります。 一部の制限はサポート 要求を通じて増やすことができるため、しきい値に近づく可能性がある場合は、事前に把握しておく必要があります。

コストの制限事項

スケーリングは、単に問題により多くのリソースを投入することだけではありません。 組織がクラウド環境のコストを理解することが重要であり、一般にリソースを追加するとコストが増えます。 このコストに注意し、財務チームと協力して、現在のクラウド支出と予想されるクラウド支出について確実に一致していることを確認してください。

最初にシステムを設計するときと、既に実行中のシステムの定期的なレビューを実行する場合の両方で、コストを予測する必要があります。 Azureには、次のツールが用意されています。

• Azure計算ツールを使用して環境のコストを計画します。
• Azure ポータルで、現在および予想される毎月の支出を確認します。
• Microsoft Cost Managementで予算を設定します。 このツールを使用すると、管理グループ、リソース グループ、サブスクリプションなど、さまざまなスコープでコストを調べることができます。

コードと構成の非効率性

場合によっては、より多くのリソースを指示することで問題が解決することがありますが、コストがかかります。 スケーリングがソリューションではない場合や、完全なソリューションではない場合があります。 場合によっては、スケーリングが必要と思われるものが、実際には不適切なコーディングや構成によって引き起こされる問題である可能性があります。

リソースをスケールアウトする前に、最初にバグを見つけることでコストと時間を節約できる可能性があります。 このアプローチの例を次に示します。

• 大規模なNoSQL データベースで 1 つのパーティションのみを使用するなど、ホット パーティションを含む不適切に設計されたデータベースがある場合は、スケーリングの量に関係なく低速になります。
• 非効率的なデータベース クエリがある場合は、データベースでより多くのリソースをスローする前にパフォーマンスを高めることができます。 一般的なクエリに基づいてデータベースに適切なインデックスを追加するだけで、コストが 100 倍低下することがあります。
• タイムアウトが正しく設定されていない場合、サーバーとデータベースの間の一貫性のないタイムアウトからの再試行により、データベース接続が飽和する可能性があります。 その場合は、データベースをスケーリングする前に設定を修正する必要があります。
• 開発者のコードが非効率的な場合、問題に対処するためのより効率的なコードを記述できますか? おそらく、コードは可能な限りメモリを解放しないので、必要でないときにより大きなメモリ VM を使用してきました。 このような修正により、大幅なコスト削減が可能になります。

依存関係

このモジュールで説明されているいくつかの問題に対処するために必要な変更は、多くの場合、アプリケーションの開発者に依存します。 ここで推奨されるソリューションとベストプラクティスの一部には、あなたと開発者とのコラボレーションが必要です。

これらの推奨事項の一部を自分で完全に実装できない場合があります。 ただし、クラウド システムとその機能と特性を理解していれば、システムとそのスケーラビリティと信頼性を向上させる変革の原動力になることができます。