翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

テクノロジーの視点

テクノロジーは、大規模な移行を加速するための優れた基盤を提供します。例えば、Cloud Migration Factory ソリューションは、移行にend-to-end自動化を提供する方法に焦点を当てています。このセクションでは、スコープ、戦略、タイムラインに合わせて、必要なスケールと速度を達成するためにテクノロジーを使用するためのベストプラクティスをいくつか説明します。

包括的な原則は、可能な限り自動化の領域を確認することです。対象範囲内に何千ものサーバーがある場合、タスクを手動で実行すると、コストと時間のかかる作業になる可能性があります。

移行を実行するために、通常、次のようないくつかのツールが使用されます。

これらのツールは、評価から動員、実装まで、移行のさまざまな段階で使用されます。これらのツールの選択は、ビジネス目標とタイムラインによって決まります。

移行フェーズが計画されたら、次のステップは、移行チームが必要なツールを使用するスキルを持っていることを確認することです。チームにスキルや経験がない場合は、ターゲットを絞ったトレーニングを計画してスキルセットを強化します。可能であれば、チームが安全な環境で移行ツールの経験を積むことができるイベントを作成します。例えば、チームがツールを試すために移行できるサンドピットサーバーやラボサーバーはありますか? または、初期開発ワークロードを学習目的で使用することは可能ですか?

自動化、追跡、ツールの統合

移行検出を自動化して必要な時間を短縮する

ほとんどの大規模な移行プログラムは、移行の範囲 (移行対象) を理解し、戦略 (移行方法) を策定することによって開始されます。検出は、この重要な側面です。必要なメタデータポイントは、移行戦略決定ツリーを形成するためにキャプチャされます。ワークロードをペースで移行するには、必要な移行メタデータを特定して、移行ファクトリーなどの実装プロセスにインポートする必要があります。移行メタデータを抽出、変換、ロード (ETL) する完全に自動化されたメカニズムにより、検出プロセスにかかる時間と労力が大幅に削減されます。

あるお客様は、移行ファクトリー用に完全に自動化されたデータ取り込みプロセスを開発しました。すべての移行メタデータを含む移行ウェーブプランは、Microsoft SharePoint のスプレッドシートでホストされ、維持されました。ソースが変更されると、手動操作なしで移行ファクトリにデータをロードする AWS Lambda 関数が開始されました。この自動データ取り込みプロセスにより、お客様は手動作業を減らし、人為的ミスを最小限に抑え、スピードを加速できました。1,000 を超えるサーバーを に移行できました AWS。

反復タスクを自動化する

移行実装フェーズでは、多くの小規模なプロセスを頻繁に繰り返す必要があります。 AWS Application Migration Service (MGN) を使用する場合、例えば、移行の対象となる各サーバーに エージェントをインストールする必要があります。

特定のビジネス要件と技術要件に適した移行ファクトリーを構築することは、大規模な移行を成功させるために必要な効率と速度を実現する最も効果的な方法です。移行ファクトリーは、標準化されたデータセットを使用して移行を高速化する統合およびオーケストレーションフレームワークを提供します。すべてのタスクを特定したら、規範的なランブックとともに自動化できるすべての手動タスクを自動化する時間を取ります。

Cloud Migration Factory ソリューションがその一例です。Cloud Migration Factory は、組織に固有の側面を自動化できる移行自動化基盤を提供するように設計されています。たとえば、CMDB のフラグを更新して、オンプレミスサーバーを廃止できることを強調できます。このシナリオでは、移行ウェーブの最後にこのタスクを実行するオートメーションを作成できます。Cloud Migration Factory には、すべてのウェーブ、アプリケーション、サーバーメタデータを含む一元化されたメタデータストアがあります。自動化スクリプトは Cloud Migration Factory に接続して、そのウェーブ内のサーバーのリストを取得し、それに応じてアクションを実行できます。Cloud Migration Factory は をサポートしていますAWS Application Migration Service。

追跡とレポートを自動化して意思決定を迅速化する

自動移行レポートダッシュボードを構築して、プログラムの重要業績評価指標 (KPIs) を含むライブデータを追跡およびレポートすることをお勧めします。移行プロジェクトには、以下を含む組織全体のステークホルダーが参加します。

ロールを実行するには、これらのステークホルダーにライブデータが必要です。例えば、オンプレミスリソースと 間の共有接続への影響を理解するには、ネットワークチームが今後の移行ウェーブを把握している必要があります AWS。リーダーシップチームは、移行の完了度を把握したいと考えています。信頼できる自動ライブフィードにより、ミスコミュニケーションが防止され、意思決定の基盤が提供されます。

大規模なヘルスケアのお客様が、データセンターの閉鎖に向けて、期限が近づいています。規模と複雑さを考慮すると、当初はステークホルダー間の移行ステータスの追跡と伝達にかなりの時間が費やされていました。その後、移行チームは Amazon Quick Sight を使用してデータを視覚化する自動ダッシュボードを構築し、移行速度を向上させながら追跡と通信を大幅に簡素化しました。

移行を容易にするツールを調べる

特に組織内の誰も大規模な移行を管理したことがない場合、移行に適したツールを選択することは簡単ではありません。

移行をサポートする適切なツールを選択する時間を取ることをお勧めします。この調査にはライセンスコストが伴う場合がありますが、より広範なイニシアチブを検討するとコスト上のメリットが得られます。または、組織に埋め込まれたツールでも同様の結果が得られる場合があります。たとえば、エステート全体にアプリケーションパフォーマンスモニタリングツールが既にデプロイされているため、豊富な検出情報を提供できます。

テクノロジーのお客様は、最初は知識不足のため、移行中に自動検出ツールの実行に消極的でした。その結果、SI AWS パートナーは、サーバー名、オペレーティングシステムのバージョン、依存関係など、エステートを手動で検出するために、アプリケーションごとに 5～10 時間の会議を実行する必要がありました。検出ツールが使用されていた場合、検出作業は 1,000 時間以上短縮された可能性があると推定されました。

前提条件と移行後の検証

移行前段階でランディングゾーンを構築する

移行ウェーブ中に AWS ターゲット仮想プライベートクラウド (VPCs) とサブネットを構築するのではなく、事前にターゲット環境またはランディングゾーンを構築することをお勧めします。適切に設計されたランディングゾーンを構築することは、移行の前提条件です。ランディングゾーンには、モニタリング、ガバナンス、運用、セキュリティコントロールを含める必要があります。

移行前にランディングゾーンを構築して検証することで、新しい環境でワークロードを実行する際の不確実性を最小限に抑えることができます。ランディングゾーンを設定すると、ステークホルダーはアカウントまたは VPC レベルで管理される側面について心配することなく、ワークロードの移行に集中できます。

前提条件アクティビティの概要

ランディングゾーンに加えて、移行前に他の技術的前提条件、特にリードタイムが長いプロセスを調整することが重要です。たとえば、オンプレミスから にデータをレプリケートするために必要なファイアウォールの変更を行います AWS。技術的な前提条件を早期に伝えることは、必要なリソースの準備と割り当てに役立ちます。前提条件が満たされていないため、移行が停止することが一般的です。これは進行中の移行の波に影響を与えるだけでなく、問題が修正されている間、将来のすべての移行の日付をプッシュバックする可能性があります。

複数のデータセンターを退避することを目指し AWSて、 への一括移行を実行することを目的とした金融サービス会社。ただし、オンプレミスと の間で利用可能な帯域幅は、意図した速度では不十分 AWS でした。残念ながら、帯域幅を増やすには新しい接続が必要で、リードタイムは 3 か月でした。これは、移行速度が最初の 3 か月間制約されたことを意味します。

継続的な改善のために移行後のチェックを実装する

最後に、オペレーション統合、コスト最適化、ガバナンスとコンプライアンスチェックなどの移行後の検証を必ず実装してください。移行後の検証には、以前に移行されたワークロードを評価して、将来の波に適用すべき技術的教訓を明らかにすることが含まれます。

さらに、これはコスト管理オペレーションを実装する優れた機会です。たとえば、移行中に、パフォーマンステストの必要性を減らすために AWS 、インスタンスのサイズをオンプレミスの資産と一致させることにしました。データセンター閉鎖のクリティカルパスでテストが行われなくなったので、Amazon CloudWatch を使用してインスタンス使用率を評価し、より小さいサイズのインスタンスが適切かどうかを判断できます。

このフェーズの重要性を説明するために、ある大規模なテクノロジーの顧客が大規模な移行を実行していましたが、当初は移行後の検証が含まれていませんでした。100 を超えるサーバーを移行した後、 AWS Systems Manager エージェント (SSM Agent) が正しく設定されていないことがわかりました。以前に移行したすべてのサーバーを修正する必要があり、移行が停止しました。顧客は、インスタンスが最初の見積もりの 5 倍の大きさであることも特定したため、各移行ウェーブの最後にコストチェックポイントを実装しました。