使用の最適化のための設計
 リソースと操作の使用を最大化します。 それらを、ソリューションのネゴシエートされた機能要件と機能以外の要件に適用します。 |
|---|
サービスやオファリングは、さまざまな機能と価格レベルを提供します。 一連の機能を購入した後、それらが十分に活用されない状況は避けてください。 そのレベルへの投資を最大化する方法を見つけてください。 同様に、課金モデルを継続的に評価して、現在の運用ワークロードに基づいて、その使用状況により適したモデルを見つけてください。
サンプル シナリオ
Contoso University は現在、大学の教職員が各学年のコースを作成したり更新したりできるだけでなく、これらのコースの学生によって使用される主な登録ポータルである市販の (COTS) ソリューションをホストしています。 このソリューションは、サービスとしてのソフトウェア (SaaS) 教育管理システムとカスタム統合されており、最終的には数年以内にこのシステムにすべての機能を移行することを希望しています。 その間に、このカスタム統合コンポーネントでコストを最適化したいと考えています。
COTS オファリングのテクノロジ ソリューションは一般に、Azure Database for MySQL であるそのデータベースを除き、ブラック ボックスのように扱われます。 このカスタム統合は、Azure App Service の Standard サービス プラン上でファンアウトされて実行される Azure Durable Function です。 この App Service は、以前は大学の Web サイトをホストしていましたが、それは現在なくなっています。 この Durable Function は、MySQL データベースから SaaS の API への夜間同期を実行する、専用の Azure Storage アカウントによってサポートされる Python アプリケーションです。
実用的である場合は従量課金ベースの価格を使用する
従量課金ベースの価格を提供するサービスが存在する可能性があります。つまり、そのサービスの使用率に対してのみ課金されるため、必要なくなったらサービスをシャットダウンしてコストが発生しないようにできます。 散発的にのみ利用されるワークロード コンポーネントがある場合、これは 24 時間 365 日実行されるコンポーネントに対する支払いと比べて、浪費されるコストを最小限に抑えるのに役立ちます。
従量課金ベースの価格を使用すると、正確に使用した分に対してのみ支払います。 このオプションは、ワークロード コンピューティングがフルタイムで利用されると想定されていない場合に適した選択です。
"Contoso の課題"
- 同期ジョブは通常、毎晩、特定の時刻に約 1 時間実行されます。 そのパフォーマンスは、これまで満足なものでした。 誤動作はまれであり、一時的な障害は現在の構成で適切に処理されます。
- 同期ジョブに必要なコンピューティングは 1 日あたり約 1 時間しか利用されないのに、使用率に関係なく 24 時間分支払うことになるため、ワークロード チームは現在の設計の代わりの方法に関心があります。
- チームは、毎晩同期が実行された後にサービスをシャットダウンするスクリプトを記述し、翌日にそれを再デプロイすることを検討しましたが、この解決策によって大きなリスクと複雑さがもたらされます。
"アプローチの適用と結果"
- チームはジョブ履歴を分析し、この関数の最も長い実行がわずか 2 時間未満であったことを見つけました。 専用プランのコストを最悪のシナリオでの Azure Functions 従量課金プランのコストと比較し、従量課金プランの方が安価であると結論付けました。
- チームは、パフォーマンスが十分であることを確認するパフォーマンス テストを実行し、実行時間がわずかに増加したことに気付きましたが、それはまだ許容される制限内にあります。
- 従量課金プランでは、ジョブが実行されている場合にのみコストが発生するため、ワークロードの全体的なコストはこれを使用して削減されます。
高可用性設計を最適化する
既にリソースに対して支払っている場合は、復旧計画の一部として、アクティブ/パッシブ モデルよりアクティブ/アクティブまたはアクティブのみのデプロイを優先します。
設計が、既定でアクティブ/パッシブ モデルを使用するように設定されている場合は、そうでなければ使用される可能性があるアイドル状態のリソースが生成されるかもしれません。 アクティブ/アクティブに変換すると、負荷平準化とスケール バーストの要件を過剰な支出なしに満たすことができる可能性があります。 アクティブのみのモデルで復旧目標を満たすことができる場合は、これらのリソースのコストを完全に削除できます。
"Contoso の課題"
- COTS アプリケーションでは、プライマリ サーバーと同じ可用性ゾーンにスタンバイ サーバーを提供する、同一ゾーン高可用性のために構成された Azure Database for MySQL フレキシブル サーバーを使用します。 そこでは、自動バックアップも有効になっています。
- ワークロードの RPO は 12 時間と比較的長く、RTO は授業日の間の 3 時間です。
- 以前の復旧テストに基づいて、チームは、スタンバイ サーバーへの自動フェールオーバーによって RPO と RTO の目標を満たせることがわかっています。 また、バックアップからのデータベースの復旧もテストしており、このシナリオの目標を満たすことができます。
"アプローチの適用と結果"
- ワークロード チームは、サービスのコストと比較した高可用性設計の利点を 1 つのインスタンスの場合の 2 倍と再評価しました。
- チームは、新しいインスタンスの構築とバックアップからのデータベースの復旧をテストし、引き続き復旧目標に準拠していることに満足しているため、スタンバイ インスタンスを削除することを決定しました。
- チームは、新しい復旧戦略が反映されるように DR 計画を更新し、新しい構成によってコスト削減を実現しました。
クラウド環境を未使用のリソースやデータがないように維持する
デプロイを未使用のリソースやデータがないかどうか定期的かつ厳格に確認し、それらの使用を停止します。 時間の経過と共に、以前には何らかの目的のために必要だったが、使用されなくなったリソースやデータがクラウド環境内に長くとどまり、コストが不必要に発生する場合があります。 コスト効率を最適化するのに役立つように、環境をクリーンに維持するように注意してください。
未使用のリソースをシャットダウンし、必要なくなったデータを削除すると、無駄が減って資金が解放されるため、それらを他の領域に投資できます。
"Contoso の課題"
- この大学は、以前の構成に戻さなければならなくなる可能性があることを恐れ、従来からソリューションの使用停止に対して控えめなアプローチを取ってきました。 この注意深さのために、場合によっては忘れ去られている破棄されたサービスが、何か月も 1 つ以上の環境で実行されている状況が発生しています。
- このようなサービスがないかどうか環境を確認するための正式なプロセスは存在しないため、通常、破棄されたサービスが検出された場合は偶然です。
"アプローチの適用と結果"
- チームは、Durable Function の App Service から従量課金ホスティングへの移行の一部として、App Service の使用停止をバックログに追加しました。 次のスプリントの一部として、彼らはすべての環境にわたって App Service のデプロイをシャットダウンします。
- 破棄されたリソースを事前に検出するのに役立つように、チームは、未使用のリソースを通知するための Azure Advisor のアラートを設定しました。
- チームは、破棄されたリソースを識別するためにチームが運用前環境の毎月の完全な確認と、運用環境の四半期ごとの完全な確認を行う必要がある新しいポリシーを実装しました。 見つかった破棄されたリソースはすべて、使用停止にするためにバックログに追加されます。