移行後のコストの最適化

ワークロードを Azure に移行した後は、コストを最適化して、過剰な支出がないようにする必要があります。 この記事では、移行後のコストを最適化する方法と、最小限の業務中断で廃止されたアセットを使用停止にする方法に関するガイダンスを提供します。

コストのために移行されたワークロードを最適化する

ワークロードを移行し、不要なリソースを使用停止にした後は、稼働中のデータに基づいてワークロードを最適化することで、コストを節約できます。

評価中のパフォーマンスに基づいてワークロードのサイズを変更できますが、ワークロードが Azure で実行されている間は、追加のコスト削減が可能な場合があります。

コストを最適化するためのツール

Azure に移行すると、リソース コストを管理するための新しいツールが利用可能になります。 クラウド支出を管理するには、次の一覧を使用します。

ツール	説明	リソース
アセットのサイズ調整	サービス使用量メトリックを確認し、ワークロードの要件に合わせて適切にサイズ変更します。	Azure Advisor のコストに関する推奨事項
Azure Reserved Virtual Machine Instances	予約インスタンスを使用すると、頻繁に実行される Azure 内のリソースにコミットできます。 常にアクティブなワークロードのインスタンスを予約することを検討してください。	Azure リソースに対する予約を管理する 最大限の予約使用に備えた Azure 仮想マシン (VM) サイズ
Azure 節約プラン	Azure 節約プランを使用した場合、1 年間または 3 年間、コンピューティング サービスに対して 1 時間当たり固定金額を支払うようコミットすると、従量課金制価格と比較して最大 65% の割引が適用されます。	Azure の節約プランに関する推奨情報
コスト管理	Microsoft Cost Management を使用して、環境のコストを監視および管理できます。	Cost Management Advisor での予約の提案
財務業務に関するドキュメント	財務業務は、財務管理の原則とクラウド エンジニアリングおよび運用を組み合わせた作業分野であり、組織がクラウドの支出をより深く理解できるようにします。	財務業務とは

廃止された資産を使用停止する

移行されたワークロードを運用環境に昇格した後、ワークロードを実行したアセットは不要になり、サービス対象外と見なされます。 しかし、これらのアセットは引き続き電力やその他のリソースを消費し、コストを増加させます。 そのため、経費を削減するために、廃止されたアセットをシャットダウンして破棄することをお勧めします。

古いアセットや機器のシャットダウンし、破棄することは簡単に見えるかもしれませんが、予期しない問題が発生する可能性があります。 ここでは、ビジネスに問題を発生させることなく、古いリソースを安全にシャットダウンして破棄する方法に関するヒントをいくつか紹介します。

監視の継続

移行されたワークロードを運用環境に昇格させた後も、運用トラフィックが正しくルーティングされるように、廃止が予定されているアセットを引き続き監視する必要があります。

アセットはオフになっていても、ストレージ、ネットワーク、その他のインフラストラクチャ リソースを引き続き使用する場合があります。 それらが削除されない限り、オンに戻すと、予期しない問題が発生する可能性があります。

リソースの次のシグナルを監視します。

• コンピューティング: CPU や RAM などのリソース コンピューティングの使用量。
• ストレージ: ディスク入出力 (I/O) などのリソース ストレージの使用状況。
• ネットワーク: アプライアンスからの受信ネットワークと送信ネットワークを含むリソース ネットワークの使用状況。 たとえば、通信にファイアウォールとロード バランサーを使用するアセットを検査します。
• ログ: Windows とアプリケーションのログ
• その他のシグナル: アセットが以前の運用環境でホストされていたときに、アセットを監視するために使用したその他のシグナル。

一部の移行では、アセットがオフになりません。 複製されている場合がります。 ネットワーク アクティビティまたは新しいログを伴う、突然の急増や、一貫したインフラストラクチャ シグナルの中程度の使用率は、アセットがまだ使用中であることを示している場合があります。

テスト ウィンドウと依存関係の検証

最適な計画を使用した場合でも、運用ワークロードに、廃止されたと見なされるアセットへの依存関係が引き続き含まれている可能性があります。 このような場合は、廃止されたアセットを無効にすると、予期しないシステム障害が発生することがあります。 そのため、アセットの終了は、システム メンテナンス アクティビティと同じレベルの厳格さで処理する必要があります。

リソースの終了を促進するために、適切なテストおよび停止期間を策定します。 終了前にアセットを正常にテストするには、メンテナンス期間が必要です。 ビジネスの中断を引き起こさずにアセットをテストできる期間を選択します。

テストおよびメンテナンス期間の定義

• 影響度の低い時間: テスト期間による影響度の低い時間を特定します。 アプリケーションの使用時間が最も低い時間を選択します。
• テスト ケースの明確化: アプリケーションのユーザーによって実行された実際のアクティビティと一致するテスト期間で実行できる明確なテスト ケースを特定します。 これらのアクティビティはサーフェス レベルではなく、使用されるすべてのプロセスを計画する必要があります。 移行からのテスト ケースがある場合は、そのテスト ケースを再利用できます。 アプリケーションで頻繁に作業するユーザーや他のチーム メンバーがいる場合は、それらの人にテストを依頼するとよいでしょう。
• スケジュールと通信: 可能な限り、メンテナンス期間をスケジュールします。 最低 4 時間を目指す必要があります。
  • スケジュール: アプリケーション ユーザーが事前に計画できるように期間を計画します。 2 週間が妥当です。
  • 通知: 変更を事前に通知します。 このメンテナンス期間中に停止が発生する可能性があり、システムが応答しない可能性があることを想定します。 ユーザーは、この期間中にアプリケーションが使用可能ではないと想定できるようになります。

メンテナンス期間前

• テスト ケースの実行: テスト ケースを実行し、リソースの使用状況を監視します。
  • 新しい使用状況が見つかった場合は、メンテナンス期間の手順を進めないでください。 代わりに、さらに調査して、アセットがまだ使用されているかどうかを確認する必要があります。
  • 新しい使用状況が見つからない場合は、メンテナンス期間の手順に進むことができます。

メンテナンス期間中

• アセットを無効にする: 使用停止のフラグが設定されているアセットを無効にします。
  • まだアセットが有効な場合、オフにします。
  • すべてのロード バランサーからアセットを削除し、受信要求に応答できなくなったことを確認します。
• テストの実行: Azure で実行されるワークロードに対してテスト ケースを実行します。
  • テストは問題なく成功しました: この時点で、アセットは使用されていません。
    • ユーザーがアプリケーションの安定性を再び期待できることを認識できるように、変更期間の完了を伝えます。
    • テストが成功したら、次のセクションに進みます。
  • テストに失敗しました: この時点でアセットが使用されている可能性があります。追加のテストが必要です。
    • 使用停止のフラグが設定されているアセットを再度有効にし、失敗したテスト ケースを繰り返します。
    • テスト ケースが失敗し続ける場合は、関連のない問題が存在する可能性があります。 メンテナンス期間内でより多くのテストを行う必要があります。また、適切なレベルのサポートが得られるようにエスカレーションを行ってください。
    • テスト ケースが失敗しなくなった場合は、その問題が関連している可能性があります。 テストを完了した後は、アセットを有効のままにし、メンテナンス期間を完了してください。
    • 予定メンテナンス期間以外で問題を調査します。 移行されたワークロードに対する変更のために別のメンテナンス期間をスケジュールし、テスト用に追加のメンテナンス期間をスケジュールします。

保持期間とデータ検証

テスト期間が完了したら、使用停止のフラグが設定されているすべてのアセットをオフにして切断し、ワークロードを運用できるようにする必要があります。 使用停止の次のフェーズに進むことができますが、アセットをすぐに破棄しないでください。

保有期間を検討する

移行のレプリケーション プロセス中にデータが失われることは珍しいことではありません。 これは特に、定期的にはアクセスされない古いデータの場合に当てはまります。 データの一時的なバックアップとして機能するよう、インベントリから削除されたアセットをしばらく保持します。 廃止されたアセットを破棄する前に、保持とテストのために少なくとも 30 日を見ておく必要があります。

データ ガバナンス要件を検討する

組織のデータ ガバナンス チームには、30 日間の保有期間だけでなく、より多くの要件がある場合があります。

• 保有期間の義務を理解する: 情報を保持するための義務を理解し、特定の法的要件の検証チェックリストを構築するために必要なチームとチェックする必要があります。
  • 現時点では、動作するアセットがあることは重要ではありません。 その情報に関するデータを取得できる必要があります。 必要に応じて、データを復元するためにディスクまたはバックアップを保持します。
  • たとえば、物理データセンターに SQL データベース サーバーがある場合は、そのデータをバックアップし、復旧可能なリソースとして維持することができます。 その後、仮想マシンの使用を停止し、バックアップを廃止するための保持時間を設定できます。

次のステップ

廃止されたアセットのコミッションを使用停止すると、移行は完了します。 これにより、学習と改善のための振り返りを使用して、移行プロセスを改善する良い機会が生まれます。

振り返りの実施