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

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

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

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

以下の前提条件は、すべての移行作業で一般的です。

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

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

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

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

• ハイブリッド接続は、Azure ネットワークをオンプレミス ネットワークに接続します。
• Azure Firewall などのネットワーク セキュリティ アプライアンスは、ワークロード外のトラフィックの検査を処理します。
• ログ要件、許可されたリージョン、許可されていないサービス、その他の制御などのガバナンス プラクティスを実施するための Azure Policy がアクティブです。
• 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 フレームワーク と Azure Well-Architected レビュー は、特定のワークロードの技術的な所有者とのやり取りについて案内し、ワークロードをデプロイする際の代替オプションを検討する場合に役立ちます。

その後、ワークロードは、クラウド導入計画の再設計作業または最新化作業として分類されます。 ワークロードを再設計するためにさらに時間が必要になるため、これらの代替ワークロードの導入パスは、移行プロセスとは別で考慮してください。

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

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

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

次のステップ

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