使用の最適化のための設計

ツールと操作を最大限に活用します。 ソリューションの機能要件と非機能要件の両方を満たしていることを確認します。

さまざまなサービスには、さまざまな機能と価格ポイントが付属しています。 プランを選択した後は、それらの機能を無駄にしないでください。 それらを完全に使用し、あなたのお金の価値を得る方法を見つけます。 また、課金モデルにも注目してください。 実際にサービスを使用する方法に合ったより優れた課金モデルがあるかどうかを確認することをお勧めします。

シナリオの例

Contoso University は、教員がコースを管理し、学生を登録できるようにする商用の既製 (COTS) システムをホストしています。 これは、数年後に完全に切り替える予定のクラウドベースの教育管理システムに接続されています。 ここでは、カスタム統合パーツのコストを最適化したいと考えています。

COTS オファリングのテクノロジ ソリューションは、通常、Azure Database for MySQL 上で実行されるデータベースを除き、ブラック ボックスのように扱われます。 カスタム統合は、大学の Web サイトをホストするために使用された Standard Azure App Service プランでファンアウトされて実行される Azure 永続的な関数ですが、それ以降は実行されません。 Durable 関数は、Azure Storage を使用する Python アプリです。 MySQL データベースからクラウドベースの API に毎晩データが同期されます。

リソースの完全な値を使用する

必要なものだけを購入し、支払っているすべてのものを使用します。

一部のリソース SKU には、パフォーマンス、セキュリティ、または信頼性のための組み込みの機能が付属しています。 支払いを行っている場合は、必ず使用してください。 また、これらの機能が不要な場合は、コストを節約するために、よりシンプルな SKU を選択します。

"Contoso の課題"

• Durable 関数は、もともとパブリック Web サイト用にサイズ設定された Standard App Service プランで実行されますが、その Web サイトは廃止されました。

• チームは SKU を再評価したことがないため、使用していない機能と容量に対してまだ料金が発生しています。

• 統合ワークロードに実際に必要な機能が不明です。

"アプローチの適用と結果"

• チームは、現在の App Service プランを確認し、統合に同じレベルのスケーラビリティやパフォーマンスは必要ありません。下位レベルの構成でサポートできることを結論付けます。

• この関数は、永続的な関数を引き続きサポートするが、コストははるかに少ない下位レベルのプランに移行します。

• また、MySQL SKU を確認し、現在のワークロードに対して権限が付与されていることを確認します。

• これらの変更は、パフォーマンスや信頼性に影響を与えずにコストを削減するのに役立ちます。

高可用性設計を最適化する

既にリソースの料金を支払っている場合は、復旧計画の一部としてアクティブ/パッシブ モデルよりもアクティブ/アクティブまたはアクティブのみのデプロイに優先順位を付けます。

設計が、既定でアクティブ/パッシブ モデルを使用するように設定されている場合は、そうでなければ使用される可能性があるアイドル状態のリソースが生成されるかもしれません。 アクティブ/アクティブに変換すると、負荷平準化とスケール バーストの要件を過剰な支出なしに満たすことができる可能性があります。 アクティブのみのモデルで復旧目標を満たすことができる場合は、これらのリソースのコストを完全に削除できます。

"Contoso の課題"

• COTS アプリケーションでは、プライマリ サーバーと同じ可用性ゾーンにスタンバイ サーバーを提供する、同一ゾーン高可用性のために構成された Azure Database for MySQL フレキシブル サーバーを使用します。 そこでは、自動バックアップも有効になっています。

• ワークロードの目標復旧ポイント (RPO) は 12 時間で比較的長く、目標復旧時間 (RTO) は学校の日中に 3 時間です。

• 以前の復旧テストに基づいて、チームは、スタンバイ サーバーへの自動フェールオーバーによって RPO と RTO の目標を満たせることがわかっています。 また、バックアップからのデータベースの復旧もテストしており、このシナリオの目標を満たすことができます。

"アプローチの適用と結果"

• ワークロード チームは、高可用性設計の利点と、1 つのインスタンスの 2 倍のサービスコストを再評価します。

• チームは、新しいインスタンスの構築とバックアップからのデータベースの復旧をテストします。回復ターゲットにまだ準拠していることは満足しているため、スタンバイ インスタンスを削除することにしました。

• チームは、新しい復旧戦略を反映するようにディザスター リカバリー計画を更新し、新しい構成によるコスト削減を実現します。

需要に合わせてスマートにスケーリングする

実際に必要なものに基づいて容量を調整します。

ピーク時の使用量を常にプロビジョニングする代わりに、需要が増加したときにスケールアップし、低下したときにスケールダウンします。 この方法では、コストが実際の使用量に合わせて維持されます。

"Contoso の課題"

• 統合関数は毎晩実行されますが、App Service プランは常にアクティブなままです。

• 1 日の大半がアイドル状態のコンピューティング リソースに対して料金が支払われます。

• サービスが使用されていないときにスケールダウンまたは一時停止するためのオプションについては調べていません。

"アプローチの適用と結果"

• チームは、時間外にスケールダウンするように App Service プランを構成します。

• 関数を Azure Container Apps または Azure Functions 従量課金プランに移動する方法について説明します。これはゼロにスケーリングできます。

• また、使用状況を監視し、必要に応じてスケーリング ルールを調整するためのアラートも設定します。

• これらの変更は、コストを実際の使用量に合わせ、無駄を減らすのに役立ちます。