次の方法で共有

移行前にワークロード アーキテクチャを設計する

  • [アーティクル]

この記事では、クラウド内のワークロードの移行対象の状態を設計するためのプロセスと考慮事項について説明します。 この記事では、イテレーション内でのワークロードのアーキテクチャの定義の一部であるアクティビティを確認します。

段階的な合理化 に関する記事では、一部のアーキテクチャの前提条件が、移行を含むビジネス変革の一部であることを示しています。 この記事では、一般的な前提条件について説明します。 また、回避できるいくつかの障害を指し示し、アーキテクチャの前提条件に挑戦することでビジネス価値を加速させる機会を特定します。 アーキテクチャを設計するためのこの増分モデルは、チームがより迅速に移動し、ビジネス成果を早期に得るのに役立ちます。

一般的な前提に基づく基本アーキテクチャ設計

移行作業では、次の前提条件が一般的です。

  • サービスとしてのインフラストラクチャ (IaaS) ワークロード想定します。 ワークロードの移行には、主に、IaaS 移行を介して物理データセンターからクラウド データセンターにサーバーを移動することが含まれます。 通常、このプロセスには最小限の再開発または再構成が必要です。 このアプローチは、"リフト アンド シフト" 移行と呼ばれています。
  • アーキテクチャの一貫性維持します。 移行中にコア アーキテクチャに変更を加えると、複雑さが大幅に増加します。 新しいプラットフォームで変更されたシステムをデバッグすると、分離が困難な多くの変数が導入されます。 ワークロードは移行中にわずかな変更のみを行う必要があり、変更は徹底的にテストする必要があります。
  • アセットのサイズを変更するを計画します。 すべてのリソースを完全に使用するオンプレミスの資産はほとんどないとします。 移行前または移行中は、実際の使用要件に最も合わせてアセットのサイズが変更されます。 Azure Migrate や Modernize などのツールでは、実際の使用に基づいてサイズ設定が提供されます。
  • ビジネス継続性とディザスター リカバリー（BCDR）の要件を記録します。 既にビジネスとネゴシエートされているワークロードに対して合意されたサービス レベル アグリーメント (SLA) がある場合は、Azure への移行後も引き続き SLA を使用します。 SLA がまだ設定されていない場合は、クラウドでワークロードを設計する前に SLA を定義して、適切に設計していることを確認します。
  • 移行のダウンタイムを計画します。 SLA 要件を満たしていない場合と同様に、ワークロードを運用環境に昇格したときに発生するダウンタイムは、ビジネスに悪影響を及ぼす可能性があります。 ダウンタイムを最小限に抑えながら移行する必要があるソリューションには、アーキテクチャの変更が必要な場合があります。 リリース計画を開始する前に、ダウンタイム要件の一般的な理解が確立されていることを前提としています。
  • ユーザーとアプリケーションのトラフィック パターンを定義します。 既存のソリューションは、既存のネットワーク ルーティング パターンとソリューションによって異なります。 現在のネットワーク使用状況をサポートするために必要なリソースを特定します。
  • ネットワークの競合を回避することを計画します。 データセンターを 1 つのクラウド プロバイダーに統合すると、ドメイン ネーム システム (DNS) またはその他のネットワーク構造で競合が発生する可能性があります。 移行中は、クラウドでホストされている運用システムの中断を回避するために、これらの競合を回避するように設計することが重要です。
  • ルーティング テーブルを計画します。 ネットワークまたはデータセンターを統合する場合は、プロジェクトにルーティング テーブルを変更するための計画が含まれていることを確認します。 データセンター間のルーティング要件を検討してください。

ランディング ゾーンの設計アーキテクチャ

クラウド導入フレームワークの 準備フェーズ では、組織は Azure ランディング ゾーン の導入の一環として、共有プラットフォーム サービスデプロイしました。 移行のランディング ゾーンの準備ができたら、移行されたワークロードを受け取るランディング ゾーンを準備しました。

この計画に基づいて、次の移行コンポーネントが配置されていると想定できます。

  • ハイブリッド接続は、Azure ネットワークをオンプレミス ネットワークに接続します。
  • Azure Firewall などのネットワーク セキュリティ アプライアンスは、ワークロード外のトラフィックの検査を処理します。
  • ログ要件、許可されたリージョン、許可されていないサービス、その他の制御などのガバナンス プラクティスを適用するための Azure ポリシーがアクティブです。
  • Azure Monitor では、共有ログ用の Azure Monitor ログ ワークスペースが設定されています。
  • ドメインに参加しているサーバーまたはその他の ID のニーズをサポートするための共有 ID リソースが確立されます。

これらの移行の要点が確立されていない場合、組織は準備完了フェーズを直ちに見直して、これらのニーズに対処する必要があります。 これらのコンポーネントがないと、移行に遅延と後退が発生し、成功が少なくなる可能性があります。

設計しているワークロードには、サブスクリプションが割り当てられています (理想的にはサブスクリプション サービス プロセス経由)。 サブスクリプションには、複数のワークロードが含まれる場合もあれば、ワークロード のリソース組織を組織がどのように完了したかに応じて、1 つのワークロードだけが含まれる場合があります。 多くのアプリケーション環境を持つワークロードを移行する場合、アプリケーション環境向けのガイダンスに基づき、複数のサブスクリプションを持つことも考えられます。

ワークロード ネットワーク アーキテクチャを設計する

アプリケーション固有のリソースを特定のサブスクリプションにデプロイし、ワークロード専用の仮想ネットワークを設計することを計画します。 詳細については、ネットワーク アーキテクチャ の設計に関するガイダンスを参照してください。 特に、仮想ネットワーク セグメント化することに重点を置く必要があります。

ネットワークには、ロード バランサーやその他のアプリケーション配信リソースなどのリソースが必要な場合があります。 N 層アーキテクチャ ガイド を使用して、Azure でこれらのリソースを計画できます。

ワークロードの依存関係を設計する

移行評価ツールを使用すると、Azure Migrate と Modernize で依存関係分析 などの依存関係分析を実行できます。 このツールは、サーバー間の相互依存関係を識別するのに役立ちます。

ワークロード自体のアーキテクチャの計画に加えて、ワークロード間の依存関係を考慮することが必要になる場合があります。 たとえば、一部のワークロードでは頻繁な通信が必要な場合があります。 その場合は、この要件を考慮して移行ウェーブと依存関係を計画すると、移行が成功するのに役立ちます。

Azure アーキテクチャ センターのガイダンス (スポーク間 ネットワークなど) を使用して、移行後に相互接続されたワークロードがどのように機能するかを設計できます。

コンフィデンシャル コンピューティングの導入に備える

主権要件を持つワークロードのサブセットによって、コンフィデンシャル コンピューティングが使用される可能性があります。 ソブリン ランディング ゾーンのデプロイの一環として、コンフィデンシャル コンピューティング用の管理グループが作成されます。

主権のコンテキストでは、コンフィデンシャル コンピューティングを使用するには、サポート サービスとして Azure Key Vault とカスタマー マネージド キーが必要です。 詳細については、Microsoft Cloud for Sovereignty でのカスタマー マネージド キーを使用した暗号化に関する説明を参照してください。

最初のクラウド見積もりを更新する

アーキテクチャの設計が完了したら、クラウドの見積もりを見直して、計画予算内に収まるようにします。 ロード バランサーやバックアップなどのサポート サービスを追加すると、コストが変わる可能性があります。 Azure Migrate や Modernize で ビジネス ケースなどのツールを使用して詳細なコスト管理演習を行うことができますが、アーキテクチャ設計を調整する際には、定期的に見積もりを見直す必要があります。

従来の IT 調達プロセスに慣れている場合、クラウド内のリソースを見積もることは異質に感じるかもしれません。 クラウド テクノロジを採用すると、取得は厳格で構造化された資本コスト モデルから、流動的な運用経費モデルに移行します。 多くの場合、クラウドへの移行の計画は、組織または IT チームがこの変更に初めて遭遇する場合です。

従来の資本支出モデルでは、IT チームは、さまざまなプログラムにわたって複数のワークロードに対する購買力を組み合わせようとします。 このアプローチでは、これらの各ソリューションをサポートできる共有 IT 資産のプールを一元化します。 運用経費クラウド モデルでは、コストは個々のワークロード、チーム、またはビジネス ユニットのサポート ニーズに直接起因します。 組織内の顧客と、組織がサポートするビジネス目標に対して、より直接的なコスト属性が組織に与えられます。 財務管理に対するこのより動的なアプローチは、多くの場合、FinOps と呼ばれます。 FinOps は Azure 固有の考慮事項ではありませんが、FinOps について理解を深めるのに役立ちます。 詳細については、「FinOps とは」を参照してください。.

移行用のワークロード アーキテクチャを設計する場合は、料金計算ツール を評価情報と共に使用して、ワークロード全体の価格を把握できます。

また、ワークロードが移行された後も、ワークロード コストを最適化するために引き続き作業する必要があります。 組織がコスト管理スキルを成熟させる方法の詳細については、「コスト管理規範のを改善する」を参照してください。

アーキテクチャを変更するタイミングを把握する

移行は、既存のアーキテクチャを維持し、クラウド プラットフォームに移行することに重点を置く傾向があります。 ただし、移行の場合でも、ワークロードの再設計が必要になる場合があります。 この一覧では、移行前にアーキテクチャを変更する必要がある場合の例を示します。

  • 技術的負債の支払い。 一部の老朽化したワークロードでは、多額の技術的負債が伴います。 技術的負債は、任意のクラウド プロバイダーでホスティング コストを増やすことで、長期的な課題につながる可能性があります。 技術的負債によってホスティング コストが不自然に増加する場合は、代替アーキテクチャを評価する必要があります。
  • 信頼性の向上。 標準の運用ベースラインは、クラウドでの信頼性と復旧の度合いを提供します。 ワークロード チームによっては、より高い SLA が必要になる場合があり、アーキテクチャの変更につながる可能性があります。
  • 高コストのワークロード。 移行中は、実際の使用量に合わせてすべての資産を最適化する必要があります。 一部のワークロードでは、特定のコストの問題に対処するためにアーキテクチャの変更が必要になる場合があります。
  • パフォーマンス要件。 ワークロードのパフォーマンスがビジネスに直接影響する場合は、追加のアーキテクチャの考慮事項が必要になる場合があります。
  • セキュリティで保護されたアプリケーション。 セキュリティ要件は一元的に実装される傾向があり、通常はポートフォリオ内のすべてのワークロードに適用されます。 ワークロードによっては、アーキテクチャの変更につながる可能性のある特定のセキュリティ要件が存在する場合があります。

これらの各基準は、移行の障害の可能性を示す指標として機能します。 ほとんどの場合、サーバーのサイズを適切に設定したり、新しいサーバーを追加したり、その他の変更を加えたりして、ワークロードを移行した後に条件に対処できます。 ただし、ワークロードを移行する前にこれらの条件のいずれかが必要な場合は、移行ウェーブからワークロードを削除し、個別に評価します。

Azure Well-Architected Framework と azure Well-Architected Review は、特定のワークロードの技術所有者との会話をガイドし、ワークロードをデプロイするための代替オプションを検討するのに役立ちます。

その後、ワークロードは、クラウド導入計画の再設計または最新化の取り組みとして分類されます。 ワークロードの再設計にかかる時間が長いため、これらの代替ワークロード導入パスは移行プロセスとは別のものとして検討してください。

アーキテクチャのチェックリスト

次のチェックリストを使用して、アーキテクチャに関する重要な考慮事項を確実に説明できます。

  • 可用性、ディザスター リカバリー、およびデータ復旧のためにアーキテクチャが SLA を満たしていることを確認します。
  • ネットワークのセグメント化プラクティスをネットワーク設計に適用したことを確認します。
  • 監視とログキャプチャを計画したことを確認します。
  • 仮想マシンのサイズが、必要な実際のコンピューティング時間に適していることを確認します。
  • 必要な実際のサイズとパフォーマンスに合わせてディスクのサイズが適切に設定されていることを確認します。
  • 必要に応じて、負荷分散サービスを計画したことを確認します。 サービスには、Azure Load Balancer、Azure Application Gateway、Azure Front Door、または Azure Traffic Manager のインスタンスが含まれる場合があります。
  • 必要に応じて、主権とコンフィデンシャル コンピューティングの要件を計画したことを確認します。

次の手順

移行ワークロード をデプロイする