容量計画に関する考慮事項
基本的な容量計画は、単純な計算から始まりますが、プロセスを複雑にする可能性のある要因があります。 わかりやすい現在の使用量と予測される使用量に加えて、以下のことを考慮に入れる必要もあります。
- サービスの制限とクォータ
- コストの制限
- コードや構成の非効率性
- 依存関係
このユニットでは、これらの考慮事項が容量計画にどのような影響を及ぼす可能性があるかと、それぞれの考慮事項に対処する方法を確認します。
サービスの制限とクォータ
クラウド コンピューティングは、無制限のリソースとして見られる傾向があります。 従来のサーバー/データセンター モデルと比較して、クラウドの容量は無限であるように思えます。 クラウドでは、確かにまったく新しいレベルのスケールが提供されます。 ただし、他のすべてのことと同様に、いくつかの制限があります。 容量計画では、それらのサービス制限にいつ達しようとしているかを理解する必要があります。
システムとそのアーキテクチャを調べるときに、使おうとしているクラウド サービスの制限を理解する必要があります。 たとえば、Azure では既定で、VM 可用性セットあたり最大 200 の VM を用意できます。 利用を開始しようとしているだけであれば、この制限の VM の数は十分すぎるように思えるかもしれません。 しかし、その制限に達すると、それ以上 VM をプロビジョニングできなくなり、その結果、停止が発生する可能性があります。
同様に、既定では各リージョンで、サブスクリプションごとに 250 のストレージ アカウントを用意できます。 これらの制限はどちらも、引き上げることができるソフト制限の例です。 しかし一部のサービスには最大値の制限があります。これについては、次のリンクを参照してください。
Azure サブスクリプションとサービスの制限、クォータ、および制約
これらの制限とクォータは、注意して監視する必要があります。 それを行う方法を見てみましょう。
Azure portal
サービスのクォータと、その制限に関連している場所については、ナビゲーション ウィンドウの [サブスクリプション] -> [設定] の下にある [使用量とクォータ] セクションで確認できます。 ネットワークやコンピューティングなどのサービス カテゴリと、Azure リージョンに関してフィルターを適用できます。 どこで制限にぶつかっているかが表示されます。
コードを使用する
この不完全な例に示すように、任意の Azure サービスの Usage - List エンドポイントを使用して、現在のリソース使用状況の情報と、サブスクリプションのコンピューティング リソースの制限も取得できます。
GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/{location}/usages?api-version=2023-03-01
{
"currentValue": 124,
"/subscriptions/{subscriptionId}/providers/Microsoft.Network/locations/westeurope/usages/VirtualNetworks",
"limit": 1000,
"name": {
"localizedValue": "Virtual Networks",
"value": "VirtualNetworks"
},
"unit": "Count"
}
上限の 1000 に対して、現在使用中の Azure Virtual Network (VNet) の数は 124 であることがわかります。 制限の引き上げにはサポート リクエストが必要なため、しきい値に近づく可能性があるタイミングについて前もって把握しておくようにします。
コストの制限
スケーリングは、問題に際してより多くのリソースを投じるだけのことではありません。 組織では、クラウド環境のコストについて理解し、より多くのリソースを追加することは、一般に、コストを増加させることと同じであると理解することが重要です。 このコストに注意して財務チームと一緒に検討し、現在のクラウド支出や予想されるクラウド支出について合意するようにします。
システムを最初に設計するときと、既に稼働中のシステムの定期的レビューを実施するときの両方で、コストを予測する必要があります。 Azure には、次のこと役立つツールが用意されています。
- Azure 計算ツールを使用して、環境のコストについて計画します。
- Azure portal で、現在の月々の支出と予測される月々の支出を調べます。
- Microsoft Cost Management で予算を設定します。 このツールを使用すると、管理グループ、リソース グループ、サブスクリプションなどのさまざまな範囲でコストを調べることができます。
コードや構成の非効率性
リソースを追加することで問題が解決することもありますが、それにはコストがかかります。 スケーリングが解決策ではない場合や、完全な解決策ではない場合があります。 場合によっては、スケーリングが必要と思われたことが、実際には不適切なコーディングや構成に起因する問題であることもあります。
リソースをスケールアウトする前にまずバグを見つけることで、コストと時間を節約できる可能性があります。 このアプローチの例を次にいくつか示します。
- 巨大な noSQL データベースでパーティションを 1 つだけ使用しているなど、ホット パーティションがあるデータベースを適切に設計していない場合は、どれだけスケーリングするかにかかわらず低速になります。
- 非効率的なデータベース クエリがある場合は、データベースにより多くのリソースを投じる前に、そのパフォーマンスを向上させてください。 よくあるクエリに基づいてデータベースに適切なインデックスを追加するだけで、コストが 100 分の 1 に下がることもあります。
- タイムアウトが正しく設定されていないと、サーバーとデータベースでタイムアウトが一貫しないことによる再試行が発生し、それが原因でデータベース接続が飽和状態になる可能性があります。 その場合は、データベースをスケーリングする前に設定を修正する必要があります。
- 開発者のコードが非効率的な場合、より効率的なコードを記述して問題に対処できますか。 可能であったのにコードでメモリが解放されないことがあります。そのため、必要ではないときにより多くのメモリを消費している VM を使用していたかもしれません。 そのようなことを修正すれば、コストを大幅に節約できる可能性があります。
依存関係
このモジュールで説明されているいくつかの問題に対処するために必要な変更は、多くの場合、アプリケーションの開発者に頼る必要があります。 ここで推奨されているソリューションやベスト プラクティスには、実現するためにユーザーと開発者の協力が必要なものがあります。
これらすべての推奨事項を自力で完全に実装することはできない場合もあります。 ただし、クラウド システムとその機能や特性を理解すれば、システムとそのスケーラビリティおよび信頼性を向上させる作業で変化を促進する立場に立つ助けとなります。