前へ

次へ

演習 - デジタル資産を評価する

完了

この演習では、Tailwind Traders が Azure のネイティブ ツールを使用してデジタル資産を評価した際の方法について説明します。 このステップバイステップ ガイドには、ハンズオン演習として再作成できる参照が含まれています。 より速く体験したい場合は、各演習をスキップし、Tailwind Traders のデジタル資産の結果を利用してください。

デジタル資産を把握する

クラウドを利用すると、テクノロジ ポートフォリオの革新的な新機能を最大限に活用できます。 全体的な戦略には、単にクラウドに移行する必要があるワークロードと、少し最新化する必要のあるワークロードが混在している場合があります。 ワークロードによっては、クラウドネイティブ アプローチを使用するより積極的な戦略や大掛かりな再構築の方が適している場合もあります。 最先端の新しいアプリケーションやイノベーションであっても、何らかの既存テクノロジに依存しています。 これらのそれぞれについて、最初のステップは、現在自分が担当している資産 (アプリケーション、データ、VM) を明確に理解することから始まります。 これらの資産をまとめて、"デジタル資産" と呼びます。

Tailwind Trader の出発点

組織がデジタル資産の表面的な知識しか持っていないことは珍しくありません。 長年の技術的成長、買収、スタッフの変化、ビジネスの優先順位の変更といった理由により、技術的資産のコレクションが膨大であいまいなものになることがあります。 Tailwind Traders 社も例外ではありません。

Tailwind Traders のデジタル資産

会社のデジタル資産についてわかっていることを次に示します。

• 3 つのデータセンター:
  • 1 つは組織によって所有されています。
  • 2 つは、複数年契約でリースされています。
• 仮想化には整合性がありません:
  • 複数のハイパーバイザー ベンダーにより、コストとプロセスが複雑になっています。
• オペレーティング システムは標準化されていません:
  • Windows Server 2008 R2、Windows Server 2012、Windows Server 2016、Windows Server 2019 が混在しています。
  • 複数の Linux オペレーティング システム とバージョンが環境全体に展開されています。
  • ほとんどの Linux インスタンスはアプライアンス ベースのものであるか、または開発チームからの LAMP スタック展開により生じたものです。
• 運用管理には整合性がありません:
  • 修正プログラムの適用には一貫性がありません。
  • 基本的なデータセンターの拡散により、データセンターのリソース消費は計画された目標を 25% 超えています。
  • バックアップ アプライアンスが記憶域容量を超えました。 優先順位の低いワークロードのバックアップは、ローカル バックアップのみです。
  • アクティブな監視と最適化は、ミッション クリティカルなワークロードに限定されます。
  • 運用チームには負荷がかかりすぎており、人手が不足しています。
  • チームの ServiceNow の専門家は 3 年前、ベンダーが構成管理データベース (CMDB) の構成を完了した直後に退職しました。 それ以降、資産の新しい検出やマッピングは行われていません。
• IT 部門はコスト センターであると見なされています:
  • ビジネスでは IT の役割が軽視されています。
  • リースされたデータセンターの高いコストは正当化することが困難です。
  • IT 部門は、数年にわたって予算やスタッフを削減した後も、業務部門からコスト削減の圧力をかけられ続けています。
• 小売イノベーション チームは、高い価値をもたらすイノベーションのソースと見なされています:
  • 各イノベーションはリリースされると IT チームに移行され、継続的なコスト負担になっています。
• データセンター全体のワークロードは、次の要素で構成されます。
  • 小売イノベーション: 小売環境の境界を押し広げ、店舗内、オンライン、顧客のモバイル エクスペリエンス全体に広がる新しいイノベーション。
  • スマート店舗:環境制御、ドア、照明、対話型陳列棚、店内ディスプレイと広告、500 以上の販売時点情報管理システム。
  • 本社: 本社では、900 人を超える従業員が働いています。 多数の分野にわたるプロセスをサポートする、最高品質のソリューションを網羅するテクノロジ システムが使用されています。 これには、不動産、物流、サプライ チェーン、価格設定、人事、従業員のスケジュールと進捗管理、給与などが含まれます。
  • エンドユーザー ワークステーション: ほとんどがデスクトップベースで、モバイル、BYOD (Bring Your Own Device)、店内キオスク、仮想デスクトップ ソリューションを選択する従業員の割合が増加しています。
  • 集中オペレーション: IT チームは、すべての IT および小売イノベーション資産の継続的な技術運用を提供しています。

わかっていないこと

Tailwind Traders の課題は、表面上の情報以外は非常にあいまいであるという点です。 情報サイロの状態が何年も続き、テクノロジ ソリューション間でプラットフォームが共有されていないため、多くの知識ギャップが発生しています。 次のような重要な質問に、チームはまだ答えることができません:

• サーバー: 組織全体にハイパーバイザーがいくつあるか? サーバーまたは VM がいくつあるか? 各サーバーまたは VM にどのようなリソース (コア、メモリ、ストレージ) が割り当てられているか? オペレーティング システムにパッチが適用されているか、準拠しているか、ターゲット クラウド プラットフォームと互換性があるか?
• アプリケーション: サーバーや VM でいくつのアプリケーションがホストされているか? それらのアプリケーションでは、割り当て資産が実際に使用されているか? それらのアプリケーションは、自己完結型か、それとも資産のコレクションに依存しているか? それらのアプリケーションへの運用トラフィックはあるか? 各アプリケーションの重要度はどうなっているか?
• "データ:" データ資産全体にどのようなデータが存在しているか? データはどのように使用されているか? トランザクション アプリケーションはサポートされているか? より高度な分析にデータは使用されているか? データは環境内でどのようにステージングおよび移動されるか? データは環境内のさまざまなポイントで変換されているか? データは秘密度に基づいて分類されているか? ガバナンス、管理、マスター化が行われているか?
• ビジネスへの影響: さまざまなワークロードのビジネス価値はどのようなものか? ビジネス所有者が定義されているか? 運用サポートに対するコミットメントはあるか? これらのワークロードを廃止する計画はあるか? これらのワークロードに、ガバナンス、コンプライアンス、またはセキュリティ上の制約があるか?

デジタル資産を評価する

次のプロセスは、あいまいさを解消するのに役立ち、既存のデータに基づいて包括的な移行計画の策定を支援します。

まず、現在のオンプレミスのインフラストラクチャ、アプリケーション、および依存関係を特定します。 これは、Azure への移行対象のワークロードの特定と、最適化されたコスト予測の収集に役立ちます。 Azure Migrate のサーバー評価ツールを使用して、使用中のワークロード、ワークロード間の依存関係、ワークロードの最適化を明らかにします。

Note

導入計画の策定においてはさまざまな役割があります。 このセクションの残りの部分では、デジタル資産に関するデータを収集するための技術的な手順について説明します。 プロジェクト管理またはプロジェクト計画の役割が中心の場合は、最後までスキップして、サンプルのデータ出力により Tailwind Traders 環境からの情報を使用して計画がどのように作成されるかを確認してください。

開始する前に

• 次のエージェントベースの依存関係分析のサポートとデプロイの要件を確認します。

  • VMware VM
  • 物理サーバー
  • Hyper-V VM

• 以下を実行します。

  • Azure Migrate プロジェクトがあること。 ない場合は、今すぐ作成します。
  • サーバー評価ツールをプロジェクトに追加したことを確認します。
  • エージェントレスのアプライアンスを使用してオンプレミスのマシン、アプリケーション、データを検出するように Azure Migrate アプライアンスを設定します。 アプライアンスでは、オンプレミスのマシンが検出され、メタデータとパフォーマンス データがサーバー評価ツールに送信されます。 次に対してアプライアンスを設定します。
    • VMware VM
    • Hyper-V VM
    • 物理サーバー

• 次に、Azure Migrate の検出および評価のツールを使用して、オンプレミスの VMware VM、Hyper-V VM、他のパブリック クラウドや物理サーバーでホストされている VM を、Azure への移行のために検出して評価します。 検出および評価のツールにより、Azure Migrate アプライアンスからデータがプルされます。これは、次の手順を完了するのに役立ちます。

  • Azure 対応性: オンプレミスのコンピューターで Azure に移行する準備ができているかどうかを評価します。
  • Azure のサイズ設定:移行後の Azure VM のサイズまたは Azure VMware ノードの数を推定します
  • Azure コストの見積もり: Azure でオンプレミス サーバーを実行する場合のコストを見積もります。
  • 依存関係の分析: 相互に依存するサーバーを Azure に移動できるように、サーバー間の依存関係と最適化戦略を特定します。

使用中のワークロード

Azure Migrate は、軽量の Azure Migrate アプライアンスを使用して、オンプレミスの VMware VM、Hyper-V VM、その他の仮想マシン、および物理サーバーのエージェントレス検出を実行します。 継続的な検出によって、マシンの構成情報とパフォーマンス メタデータ、およびアプリケーション データが収集されます。 このアプライアンスによってオンプレミスのマシンから収集されるものは次のとおりです。

• マシン、ディスク、NIC メタデータ

• インストールされているアプリケーション、ロール、機能

• CPU とメモリの使用率、ディスク IOPS、スループットなどのパフォーマンス データ

データの収集後、アプリケーション インベントリの一覧をエクスポートして、マシン上で実行されているアプリケーションと SQL Server インスタンスを確認できます。 Azure Migrate のデータベース評価ツールを使用すると、SQL Server の準備状態を把握できます。

サーバー評価ツールで検出されたデータと共に CMDB データを使用して、サーバーとデータベース資産のビューを作成できます。 これは、事業単位、アプリケーション所有者、地域でのサーバー分散状況を把握するのに役立ちます。 次に、移行で優先するワークロードを決定できます。

ワークロード間の依存関係

サーバーの検出後、依存関係を分析して、サーバー間の依存関係を視覚化して特定し、相互依存のサーバーを Azure に移行するための最適化戦略を把握できます。 この視覚化は、特定のマシンが使用されているかどうかや、それらを移行せずに使用を停止できるかどうかを判断するのに役立ちます。 依存関係を分析することは、移行し忘れたものがないことを確認し、移行時の予期しない停止を回避するのに役立ちます。 アプリケーション インベントリと依存関係の分析を実行したら、信頼度の高いサーバー グループを作成して、それらの評価を開始できます。

最適化とサイズ設定

Azure では、時間の経過と共にクラウドの容量を変更するという柔軟性が提供されます。また、移行により、サーバーに割り当てられている CPU およびメモリ リソースを最適化する機会が提供されます。 特定したサーバーについての評価を作成すると、ワークロードのパフォーマンス履歴を把握するのに役立ちます。 これは、Azure VM SKU の適切なサイズ設定と、Azure でのディスクに関する推奨事項を理解するために不可欠です。

対応性と適合性の分析

評価レポートをエクスポートし、こちらのカテゴリでフィルター処理すると、Azure 対応性を把握できます。

• Azure 用の準備が完了:マシンをそのまま、一切の変更なく Azure に移行できます。
• 条件付きで Azure 用の準備が完了:マシンは Azure に移行できますが、評価で提供されている修復ガイダンスに従う軽微な変更を必要とします。
• Azure 用の準備が未完了:マシンをそのまま Azure に移行することはできません。 移行前に、修復ガイダンスに従って問題を修正する必要があります。
• 準備状態が不明:メタデータが不十分なため、Azure Migrate はマシンの準備状態を判断できません。

データベース評価を使用すると、SQL Server データ資産の Azure SQL Database または Azure SQL Managed Instance への移行についての準備状態を評価できます。 この評価は、各 SQL Server インスタンスの移行準備状態のパーセンテージを表示します。 さらに、インスタンスごとに、Azure 内の推奨ターゲット、移行の潜在的な阻害要因、破壊的変更の数、Azure SQL Database または Azure SQL Database VM 用の準備状態、互換性レベルを確認できます。 移行の阻害要因による影響と、それらの修正に関する推奨事項を得ることができます。

サイズ設定に関する推奨事項

マシンが Azure 用の準備が完了とマークされると、サーバー評価ツールは、Azure VM SKU とマシン用のディスクの種類を決定するサイズ設定に関する推奨事項を作成します。 サイズ設定に関する推奨事項は、パフォーマンス履歴に基づいてか (移行時にリソースを最適化するため)、パフォーマンス履歴を使用せずオンプレミスのマシン設定に基づいて取得できます。 データベース評価で、データベース SKU、価格レベル、およびコンピューティング レベルに関する推奨事項を確認できます。

コンピューティング コストを取得する

Azure Migrate の評価でのパフォーマンスベースのサイズ設定オプションは、VM の適切なサイズ設定に役立つので、これを Azure でのワークロードの最適化のためのベスト プラクティスとして使用するべきです。 適切なサイズ設定に加えて、Azure のコスト節約に役立つその他のオプションがいくつかあります。

• 予約インスタンス: 予約インスタンスを使用すると、従量課金制の価格と比較して、コストを大幅に削減できます。
• Azure ハイブリッド特典:Azure ハイブリッド特典を使用すると、アクティブなソフトウェア アシュアランスを含むオンプレミスの Windows Server ライセンス、または Linux サブスクリプションを Azure に持ち込むことができます。 これは、予約インスタンス オプションと組み合わせることができます。
• マイクロソフト エンタープライズ契約: Azure Enterprise Agreement (EA) を利用すると、Azure のサブスクリプションおよびサービスを節約できます。
• プラン: 複数の Azure プランがあります。 たとえば、開発テスト用の従量課金制プランまたは Enterprise Dev/Test は開発/テスト VM 向けの低料金を提供しています。
• VM のアップタイム: 1 か月あたりの Azure VM 実行日数と 1 日あたりの時間を確認できます。 使用していないときにマシンをシャットダウンすると、コストを削減できます。
• ターゲット リージョン: さまざまなリージョンで評価を作成して、特定のリージョンへの移行でコスト効率がより高くなる可能性があるかどうかを見極めることができます。

データの視覚化

ポータルで、サーバー評価レポート (Azure 対応性の情報と月単位のコストの分布を含みます) を表示できます。 また、評価をエクスポートし、視覚エフェクトを追加して移行計画を充実させることもできます。 プロパティのさまざまな組み合わせで評価を作成し、自分のビジネスに最適なプロパティのセットを選択できます。

ギャップと阻害要因を評価する

移行するアプリケーションとワークロードを決定したら、それらについてダウンタイムの制約を確認し、ご利用のアプリケーションと基になるインフラストラクチャとの間の運用上の依存関係を探します。 この分析により、目標復旧時間 (RTO) を満たす移行を計画し、データ損失を最小限に抑えることができます。 移行する前に、移行を妨げるおそれのある互換性の問題やサポートされていない機能を確認し、その影響を軽減することをお勧めします。 サーバー評価レポートとデータベース評価ツールは、このプロセスで特に役立ちます。

ワークロードの優先度を付ける

インベントリに関する情報を収集したら、最初に移行するアプリケーションとワークロードを特定できます。 フルスケールの移行を開始する前にすべての誤りを取り除くことができるように、体系的かつ制御可能な方法でアプリを移行するための "適用と学習" によるアプローチを確立します。

移行順序を優先度付けするには、複雑さ、移行時間、ビジネスの緊急度、運用に関する考慮事項、コンプライアンス、セキュリティ要件、アプリケーションの知識などの要素を検討します。

以下に、推奨事項をいくつか示します。

• すぐに成果の出るものを優先する: 評価レポートを使用して、Azure への移行に完全に対応していて、最小限の労力で移行できるサーバーやデータベースなど、すぐに成果の出るものを特定します。 この優先順位付けを行うためのいくつかの方法を次の表にまとめます。

  State	操作
  Azure 対応の VM	評価レポートをエクスポートし、状態が [Azure に対応] であるすべてのマシンをフィルター処理します。 これは、Azure Migrate: 移行とモダン化ツールを使用して Azure に移動するマシンの最初のグループとなる可能性があります。
  サポート終了のオペレーティング システム	評価レポートをエクスポートし、Windows Server 2008 R2 または Windows Server 2008 を実行しているすべてのマシンにフィルターを適用します。 これらのオペレーティング システムはサポートが終了しています。これらを Azure に移行した場合に限り、3 年間のセキュリティ更新プログラムが無料で提供されます。
  SQL Server の移行	データベース評価の推奨事項を使用して、Azure SQL Database 用の準備が完了しているデータベースを移行します。 Azure SQL Database VM に対応しているデータベースを移行します。
  サポートが終了するソフトウェア	アプリケーション インベントリをエクスポートし、サポートが終了しようとしているソフトウェアや拡張機能がないかフィルター処理を行います。 移行のために、これらのアプリケーションに優先度を付けます。
  過少にプロビジョニングされているマシン	評価レポートをエクスポートし、CPU 使用率 とメモリ使用率 (パーセンテージで測定) が低いマシンをフィルター処理します。 適切なサイズの Azure VM に移行し、使用率の低いリソースのコストを節約します。
  過剰にプロビジョニングされているマシン	評価レポートをエクスポートし、CPU 使用率 とメモリ使用率が高いマシンをフィルター処理します。 容量の制約を解決し、容量が逼迫したマシンを Azure に移行することで、これらのマシンの中断を防ぎ、パフォーマンスを向上させます。 Azure では、要求を満たすために自動スケール機能を使用してください。 評価レポートを分析して、ストレージの制約を調査します。 ディスクの IOPS とスループット、推奨されるディスクの種類を分析します。

• 小規模から始めて拡大する: 移行戦略に対する信頼を築くために、リスクや複雑さが最小限であるアプリケーションとワークロードの移行から始めます。 Azure Migrate による評価の推奨事項と CMDB リポジトリを分析し、パイロット移行の候補となる可能性がある開発テスト用ワークロードを探して移行します。 運用環境のワークロードの移行を開始するときに、パイロット移行からのフィードバックと知識を役立てることができます。

• 準拠: Azure では、業界で最大級のコンプライアンス ポートフォリオを維持しており、その内容は広範かつ詳細にわたります。 コンプライアンス要件を使って移行の優先順位を付けて、アプリケーションとワークロードが対象の国、地域、業界に固有の標準と法に準拠するようにします。 これは、ビジネスに不可欠なプロセスを処理する組織、機密情報を保持する組織、または規制の厳しい業界に属する組織に特に当てはまります。 このようなタイプの組織では、標準や規制が多く、頻繁に変更される可能性があり、後れを取らずについていくことが困難な場合があります。

移行計画を仕上げる

移行計画を仕上げる前に、次のようなその他の潜在的な阻害要因を検討し、緩和するようにしてください。

• ネットワークの要件: ネットワーク帯域幅および待機時間の制約を評価します。これらは、予期しない遅延や、移行レプリケーションの速度低下の原因となるおそれがあります。
• テスト/移行後の調整:移行アプリケーションのパフォーマンスおよびユーザー受け入れテストを実行したり、移行後にアプリケーションの構成や調整を行うための時間的余裕を確保します。 たとえば、データベース接続文字列を更新したり、Web サーバーを構成したり、カットオーバーやクリーンアップを実行したりする必要が生じる場合があります。
• アクセス許可: 推奨される Azure のアクセス許可と、移行に必要なサーバーおよびデータベースのアクセス ロールとアクセス許可を確認します。
• トレーニング: デジタル変革に向けて組織を準備します。 組織改革を成功させるには、しっかりしたトレーニング基盤が重要です。 Microsoft Learn の無料トレーニング (Azure の基礎、ソリューション アーキテクチャ、セキュリティに関するコースなど) をご確認ください。 チームに Microsoft 資格証明を調べるよう促します。
• 実装のサポート: 必要に応じて、実装のサポートを受けます。 クラウドに移行する多くの組織が、外部からサポートを受けています。 個別支援を受けながら迅速かつ自信を持って Azure に移行するには、Azure Expert マネージド サービス プロバイダーまたは FastTrack for Azure のご利用をご検討ください。

移行したいアプリケーション、アプリケーションとデータベースの可用性、ダウンタイム制約、移行マイルストーンに関する詳細情報を含む、効果的なクラウド移行計画を作成します。 計画では、データのコピーにかかる時間を考慮し、移行後のテストやカットオーバーの作業に必要な現実的な時間を含めます。

移行後のテスト計画には、機能、統合、セキュリティ、パフォーマンスに関するテストとユース ケースなどが含まれている必要があります。 こうすることで、移行されたアプリケーションが想定どおりに動作し、すべてのデータベース オブジェクトとデータのリレーションシップがクラウドに正常に転送されます。

移行のロードマップを作成します。 メンテナンス期間を宣言してアプリケーションとデータベースを最小限のダウンタイムで移行し、移行時における運用およびビジネスへの潜在的な影響を抑えます。

テスト移行

本格的な移行を開始する前に、Azure Migrate でテスト移行を実行することをお勧めします。 テスト移行は、所要時間の見積もりと、移行計画の微調整に役立ちます。 これにより、完全な移行の前に潜在的な問題を検出して修正できます。

演習の出力

Tailwind Trader では、全部で 3,500 の VM、1,200 のアプリケーション、300 のデータベースがデジタル資産全体で特定されました。 そのうち、80% を超えるものがリースされたデータセンターでホストされており、24 か月以内にクラウド ソリューションに移行される必要があります。

このデータを収集するために使用された移行ツールを使用すると、特定されたすべての資産を移行することができます。 ただし、そのような移行を行うと、組織の変更管理能力に大きな負荷がかかる可能性があります。 特に、チームが移行プロセスとクラウド ツールを初めて使用する場合は、1,200 のアプリケーションの十分なテスト、および 300 のデータベースの検証は、組織にとって負担になる可能性があります。

成功の可能性を高めるには、後に続く一連の移行のウェーブを計画します。 2 週間のスプリントで、運用環境への移行、テスト、リリースを行う、優先順位が高いワークロードの小さなセットを特定します。 その後、すべてのワークロードが移行されるまで、移行のウェーブを続けます。 時間が経つと、チームが各スプリントで移行できるワークロードの数が安定して増加し、移行の波のサイズが大きくなります。

第一波において、Tailwind Traders 社は、ビジネスへの影響が小さく技術的な複雑さが限られていることから、以下の領域でそれぞれのワークロードを特定しました。

• 小売イノベーション:
  • モバイル クーポン。小規模な Web サイトと、3 台のサーバーで実行されている 1 つの独立したデータベースで構成されるアプリケーション。
• スマート店舗:
  • ビデオ シェルフ。少数のパイロット ストア内の追跡された一連のディスプレイにビデオをプッシュダウンする動画配信システム。 このシステムでは、20 台のサーバーを使用して動画の管理と配信が行われます。
  • リモート ストア POS。組織の MPLS に接続して高速トランザクションを行うことができないリモートの場所で使用される POS システムのインスタンス。 このシステムには、15 台のサーバーが使用されます。
• 本社:
  • 従業員スケジュール アプリケーション。従業員のスケジュールを管理および表示するためのシンプルなアプリケーションです。 このシステムで使用されるのは 2 台のサーバーだけですが、お客様コンテンツについては中央の ERP および HR システムに接続する必要があります。
• エンドユーザー ワークステーション:
  • 仮想デスクトップには、最大 500 のデスクトップをサポートするために 30 台のサーバー ソリューションが必要です。 現在のビジネス需要は、それが利用可能になれば、需要が 3 倍に増えることを示唆しています。
• 一元運用:
  • 現在のバックアップ ソリューションの制限は、テクノロジ運用に多大なリスクをもたらしています。 将来的に組織の運用を保証するため、新しいソリューションが必要です。

これはデジタル資産全体のごくわずかなサブセットですが、移行、テスト、運用環境へのデプロイが可能な、測定可能で実用的なワークロードのセットが作成されます。 この最初のイテレーションでは、チームのスキルを高め、大規模な移行作業に対応できるようにします。

次のユニットでは、このデータを移行とイノベーションの作業をガイドするためのアクションにつながる計画に変換します。

続行