テクノロジーの視点

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

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

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

• 発見

• 移行の実装

• 設定管理データベース (CMDB)

• インベントリスプレッドシート

• プロジェクト管理

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

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

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

このセクションの内容:

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

• 反復タスクを自動化する

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

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

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

ほとんどの大規模な移行プログラムは、移行の範囲 (移行対象) を理解し、戦略 (移行方法) を開発することで開始されます。検出は、この重要な側面です。必要なメタデータポイントは、移行戦略決定ツリーを形成するためにキャプチャされます。ワークロードをペースで移行するには、必要な移行メタデータを特定して、移行ファクトリーなどの実装プロセスにインポートする必要があります。移行メタデータを抽出、変換、ロード (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 QuickSight を使用して、データを視覚化する自動ダッシュボードを構築しました。これにより、移行速度を向上させながら追跡と通信を大幅に簡素化できます。

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

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

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

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

前提条件と移行後の検証

このセクションの内容:

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

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

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

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

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

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

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

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

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

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

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

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

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