翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 大規模な移行のベストプラクティス
組織の機能を管理する要因によっては、大規模な移行が困難になる可能性があります。このセクションでは、労力の初期段階で対処し、プロジェクト全体で追跡することで、大規模な移行を簡素化できるいくつかの主要な要因について説明します。
大規模な移行に関する以下のベストプラクティスは、他のお客様から取得したデータに基づいています。ベストプラクティスは 3 つのカテゴリに分かれています。
+ People
+ テクノロジー
+ プロセス
# 人々の視点
このセクションでは、人的視点の以下の主要領域に焦点を当てます。
+ エグゼクティブサポート – 意思決定を行う権限のあるシングルスレッドリーダーを特定する
+ チームコラボレーションと所有権 – さまざまなチーム間のコラボレーション
+ トレーニング – さまざまなツールに関するチームのプロアクティブトレーニング
## エグゼクティブサポート
**Contents**
+ [シングルスレッドリーダーを特定する](#leader)
+ [上級リーダーシップチームの調整](#align-leadership)
### シングルスレッドリーダーを特定する
大規模な移行を開始するときは、プロジェクトと説明責任に 100% 専念しているシングルスレッドのテクニカルリーダーを特定することが重要です。このリーダーは、一貫した優先順位を維持することで、意思決定を行い、サイロ化を回避し、ワークストリームを合理化することができます。
大規模な移行のグローバル顧客は、プログラムの開始時に毎週 1 台のサーバーから、2 か月目の開始時に毎週 80 台を超えるサーバーにスケールできました。シングルスレッドリーダーとしての CIO の完全なサポートは、移行されるサーバーの急速なスケールアップにとって重要でした。CIO は、移行チームと毎週の移行カットオーバーコールに参加して、問題のリアルタイムのエスカレーションと解決を確保し、移行速度を加速しました。
### 上級リーダーシップチームの調整
移行の成功基準に関して、さまざまなチーム間で調整を行うことが重要です。移行の計画と実装は小規模な専有チームによって達成できますが、戦略を定義し、周辺機器のアクティビティを実行する際に課題が発生します。これらの潜在的な障害には、次のような IT 組織のさまざまな分野からのアクションやエスカレーションが必要になる場合があります。
+ ビジネス
+ アプリケーション
+ ネットワーク
+ セキュリティ
+ インフラストラクチャ
+ サードパーティーベンダー
アプリケーション所有者、リーダーシップ、調整、シングルスレッドリーダーへの明確なエスカレーションからの直接的なアクションが重要になります。
## チームコラボレーションと所有権
**Contents**
+ [部門横断的なクラウド対応チームを作成する](#cross-function)
+ [コア移行チーム外のチームや個人の要件を事前に定義する](#define-reqs)
+ [ワークロードの移行時にライセンスの問題がないことを検証する](#licensing)
### 部門横断的なクラウド対応チームを作成する
**Contents**
大規模な移行プロジェクトの重要な最初のステップは、組織がクラウドで作業できるようにすることです。これを実現するには、[Cloud Enablement Engine](https://d1.awsstatic.com/whitepapers/cloud-enablement-engine-practical-guide.pdf) (CEE) を構築することをお勧めします。CEE は、移行のための組織の運用準備に重点を置いた、権限と説明責任を持つチームです AWS。CEE は、インフラストラクチャ、アプリケーション、運用、セキュリティからの代表者を含む部門横断的なチームである必要があります。チームには以下の責任があります。
+ ポリシーの開発
+ 組織のクラウド運用モデルを確立するツール、プロセス、アーキテクチャの定義と実装
+ ステークホルダーが表すすべての領域でステークホルダーの連携を継続的に促進する
あるヘルスケアの顧客が CEE から始めませんでした。ただし、最初のパイロット移行により、ギャップが特定されました。最終移行カットオーバー日まで、厳しい期限が設定され、チームは*移行の戦場*を実装しました。移行の戦場では、インフラストラクチャ、セキュリティ、アプリケーション、ビジネスの関係者が問題の解決を支援できます。
### コア移行チーム外のチームや個人の要件を事前に定義する
コアプログラム外のチームや個人を特定し、移行計画段階での関与を定義します。後の段階で移行の勢いを促進するには、アプリケーションチームの関与に特に注意してください。アプリケーションに関する知識、問題を診断する能力、カットオーバーにサインオフする要件が必要です。
移行はコアチームが主導しますが、アプリケーションチームはカットオーバー中の移行計画とテストの検証に関与している可能性があります。お客様は多くの場合、アプリケーション移行ではなくインフラストラクチャプロジェクトとしてクラウド移行にアプローチします。これにより、移行中に問題が発生する可能性があります。
移行戦略を選択するときは、アプリケーションチームに必要な関与を検討することをお勧めします。例えば、リホスト戦略では、リプラットフォーム戦略やリファクタリング戦略と比較して、アプリケーションとチームの関与が少なくて済みます。リプラットフォーム戦略やリファクタリング戦略では、より多くのアプリケーション環境が変更されています。アプリケーション所有者の可用性が制限されている場合は、リファクタリング、再配置、再購入戦略ではなく、リホストまたはリプラットフォームの使用を検討してください。
### ワークロードの移行時にライセンスの問題がないことを検証する
企業の既製の製品をクラウドに移行すると、ライセンスが変更される可能性があります。ライセンス契約は、オンプレミスの資産に焦点を当てている場合があります。たとえば、ライセンスは CPU によって、または特定の MAC アドレスにリンクされている場合があります。または、ライセンス契約には、パブリッククラウド環境でホストする権利が含まれていない場合があります。ただし、ベンダーとライセンスを再交渉すると、リードタイムが長くなり、移行が難しくなる可能性があります。
移行の範囲が定義されたら、すぐに調達チームまたはベンダー管理チームと協力することをお勧めします。ライセンスは、ターゲットアーキテクチャと移行パターンにも影響する可能性があります。
## トレーニング
**Contents**
+ [新しいツールとプロセスについてチームをトレーニングする](#tools-training)
### 新しいツールとプロセスについてチームをトレーニングする
移行戦略が定義されたら、移行とターゲット運用モデルに必要なトレーニングを理解するために時間を費やしてください。移行中は、組織にとって AWS Database Migration Service初めてのツールなどを使用する可能性があります。チームを積極的にトレーニングすることで、移行フェーズで発生する遅延を軽減できます。
実践的な方法でツールを試す機会を提供するアクティブな知識移転方法を探すことをお勧めします。例えば、 AWS プロフェッショナルサービスは、大規模な移行を担当する 3 つのシステムインテグレーター (SI) AWS パートナー向けに、いくつかの Cloud Migration Factory トレーニングセッションを提供しました。これにより、チームは移行フェーズに移行する際に基本的な知識を持つことができました。また、各 SI AWS パートナーチーム内でファーストラインエスカレーションとして機能する可能性のある対象分野のエキスパート (SMEs) を特定するのにも役立ちました。
# テクノロジーの視点
テクノロジーは、大規模な移行を加速するための優れた基盤を提供します。例えば、Cloud Migration Factory ソリューションは、移行にend-to-end自動化を提供する方法に焦点を当てています。このセクションでは、スコープ、戦略、タイムラインに合わせて、必要なスケールと速度を達成するためにテクノロジーを使用するためのベストプラクティスをいくつか説明します。
包括的な原則は、可能な限り自動化の領域を確認することです。対象範囲内に何千ものサーバーがある場合、タスクを手動で実行すると、コストと時間のかかる作業になる可能性があります。
移行を実行するために、通常、次のようないくつかのツールが使用されます。
+ 発見
+ 移行の実装
+ 設定管理データベース (CMDB)
+ インベントリスプレッドシート
+ プロジェクト管理
これらのツールは、評価から動員、実装まで、移行のさまざまな段階で使用されます。これらのツールの選択は、ビジネス目標とタイムラインによって決まります。
移行フェーズが計画されたら、次のステップは、移行チームが必要なツールを使用するスキルを持っていることを確認することです。チームにスキルや経験がない場合は、ターゲットを絞ったトレーニングを計画してスキルセットを強化します。可能であれば、チームが安全な環境で移行ツールの経験を積むことができるイベントを作成します。例えば、チームがツールを試すために移行できるサンドピットサーバーやラボサーバーはありますか? または、初期開発ワークロードを学習目的で使用することは可能ですか?
## 自動化、追跡、ツールの統合
**Contents**
+ [移行検出を自動化して必要な時間を短縮する](#discovery)
+ [反復タスクを自動化する](#repeating)
+ [追跡とレポートを自動化して意思決定を迅速化する](#decision)
+ [移行を容易にするツールを調べる](#tooling)
### 移行検出を自動化して必要な時間を短縮する
ほとんどの大規模な移行プログラムは、移行の範囲 (移行対象) を理解し、戦略 (移行方法) を策定することによって開始されます。検出は、この重要な側面です。必要なメタデータポイントは、移行戦略決定ツリーを形成するためにキャプチャされます。ワークロードをペースで移行するには、必要な移行メタデータを特定して、移行ファクトリーなどの実装プロセスにインポートする必要があります。移行メタデータを抽出、変換、ロード (ETL) する完全に自動化されたメカニズムにより、検出プロセスにかかる時間と労力が大幅に削減されます。
あるお客様は、移行ファクトリー用に完全に自動化されたデータ取り込みプロセスを開発しました。すべての移行メタデータを含む移行ウェーブプランは、Microsoft SharePoint のスプレッドシートでホストされ、維持されました。ソースが変更されると、手動操作なしで移行ファクトリにデータをロードする AWS Lambda 関数が開始されました。この自動データ取り込みプロセスにより、お客様は手動作業を減らし、人為的ミスを最小限に抑え、スピードを加速できました。1,000 を超えるサーバーを に移行できました AWS。
### 反復タスクを自動化する
移行実装フェーズでは、多くの小規模なプロセスを頻繁に繰り返す必要があります。 AWS Application Migration Service (MGN) を使用する場合、例えば、移行の対象となる各サーバーに エージェントをインストールする必要があります。
特定のビジネス要件と技術要件に適した移行ファクトリーを構築することは、大規模な移行を成功させるために必要な効率と速度を実現する最も効果的な方法です。移行ファクトリーは、標準化されたデータセットを使用して移行を高速化する統合およびオーケストレーションフレームワークを提供します。すべてのタスクを特定したら、規範的なランブックとともに自動化できるすべての手動タスクを自動化する時間を取ります。
[Cloud Migration Factory](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-factory-cloudendure/welcome.html) ソリューションがその一例です。Cloud Migration Factory は、組織に固有の側面を自動化できる移行自動化基盤を提供するように設計されています。たとえば、CMDB のフラグを更新して、オンプレミスサーバーを廃止できることを強調できます。このシナリオでは、移行ウェーブの最後にこのタスクを実行するオートメーションを作成できます。Cloud Migration Factory には、すべてのウェーブ、アプリケーション、サーバーメタデータを含む一元化されたメタデータストアがあります。自動化スクリプトは Cloud Migration Factory に接続して、そのウェーブ内のサーバーのリストを取得し、それに応じてアクションを実行できます。Cloud Migration Factory は をサポートしています[AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html)。
### 追跡とレポートを自動化して意思決定を迅速化する
自動移行レポートダッシュボードを構築して、プログラムの重要業績評価指標 (KPIs) を含むライブデータを追跡およびレポートすることをお勧めします。移行プロジェクトには、以下を含む組織全体のステークホルダーが参加します。
+ アプリケーションチーム
+ テスター
+ チームの廃止
+ アーキテクト
+ インフラストラクチャチーム
+ リーダーシップ
ロールを実行するには、これらのステークホルダーにライブデータが必要です。例えば、オンプレミスリソースと 間の共有接続への影響を理解するには、ネットワークチームが今後の移行ウェーブを把握している必要があります AWS。リーダーシップチームは、移行の完了度を把握したいと考えています。信頼できる自動ライブフィードにより、ミスコミュニケーションが防止され、意思決定の基盤が提供されます。
大規模なヘルスケアのお客様が、データセンターの閉鎖に向けて、期限が近づいています。規模と複雑さを考慮すると、当初はステークホルダー間の移行ステータスの追跡と伝達にかなりの時間が費やされていました。その後、移行チームは [Amazon Quick Sight ](https://docs.aws.amazon.com/quicksuite/latest/userguide/quick-bi.html)を使用してデータを視覚化する自動ダッシュボードを構築し、移行速度を向上させながら追跡と通信を大幅に簡素化しました。
### 移行を容易にするツールを調べる
特に組織内の誰も大規模な移行を管理したことがない場合、移行に適したツールを選択することは簡単ではありません。
移行をサポートする適切なツールを選択する時間を取ることをお勧めします。この調査にはライセンスコストが伴う場合がありますが、より広範なイニシアチブを検討するとコスト上のメリットが得られます。または、組織に埋め込まれたツールでも同様の結果が得られる場合があります。たとえば、エステート全体にアプリケーションパフォーマンスモニタリングツールが既にデプロイされているため、豊富な検出情報を提供できます。
テクノロジーのお客様は、最初は知識不足のため、移行中に自動検出ツールの実行に消極的でした。その結果、SI AWS パートナーは、サーバー名、オペレーティングシステムのバージョン、依存関係など、エステートを手動で検出するために、アプリケーションごとに 5～10 時間の会議を実行する必要がありました。検出ツールが使用されていた場合、検出作業は 1,000 時間以上短縮された可能性があると推定されました。
## 前提条件と移行後の検証
**Contents**
+ [移行前段階でランディングゾーンを構築する](#landing-zone)
+ [前提条件アクティビティの概要](#outline)
+ [継続的な改善のために移行後のチェックを実装する](#post-checks)
### 移行前段階でランディングゾーンを構築する
移行ウェーブ中に AWS ターゲット仮想プライベートクラウド (VPCs) とサブネットを構築するのではなく、事前にターゲット環境またはランディングゾーンを構築することをお勧めします。適切に設計されたランディングゾーンを構築することは、移行の前提条件です。ランディングゾーンには、モニタリング、ガバナンス、運用、セキュリティコントロールを含める必要があります。
移行前にランディングゾーンを構築して検証することで、新しい環境でワークロードを実行する際の不確実性を最小限に抑えることができます。ランディングゾーンを設定すると、ステークホルダーはアカウントまたは VPC レベルで管理される側面について心配することなく、ワークロードの移行に集中できます。
### 前提条件アクティビティの概要
ランディングゾーンに加えて、移行前に他の技術的前提条件、特にリードタイムが長いプロセスを調整することが重要です。たとえば、オンプレミスから にデータをレプリケートするために必要なファイアウォールの変更を行います AWS。技術的な前提条件を早期に伝えることは、必要なリソースの準備と割り当てに役立ちます。前提条件が満たされていないため、移行が停止することが一般的です。これは進行中の移行の波に影響を与えるだけでなく、問題が修正されている間、将来のすべての移行の日付をプッシュバックする可能性があります。
複数のデータセンターを退避することを目指し AWSて、 への一括移行を実行することを目的とした金融サービス会社。ただし、オンプレミスと の間で利用可能な帯域幅は、意図した速度では不十分 AWS でした。残念ながら、帯域幅を増やすには新しい接続が必要で、リードタイムは 3 か月でした。これは、移行速度が最初の 3 か月間制約されたことを意味します。
### 継続的な改善のために移行後のチェックを実装する
最後に、オペレーション統合、コスト最適化、ガバナンスとコンプライアンスチェックなどの移行後の検証を必ず実装してください。移行後の検証には、以前に移行されたワークロードを評価して、将来の波に適用すべき技術的教訓を明らかにすることが含まれます。
さらに、これはコスト管理オペレーションを実装する優れた機会です。たとえば、移行中に、パフォーマンステストの必要性を減らすために AWS 、インスタンスのサイズをオンプレミスの資産と一致させることにしました。データセンター閉鎖のクリティカルパスでテストが行われなくなったので、Amazon CloudWatch を使用してインスタンス使用率を評価し、より小さいサイズのインスタンスが適切かどうかを判断できます。
このフェーズの重要性を説明するために、ある大規模なテクノロジーの顧客が大規模な移行を実行していましたが、当初は移行後の検証が含まれていませんでした。100 を超えるサーバーを移行した後、 AWS Systems Manager エージェント (SSM Agent) が正しく設定されていないことがわかりました。以前に移行したすべてのサーバーを修正する必要があり、移行が停止しました。顧客は、インスタンスが最初の見積もりの 5 倍の大きさであることも特定したため、各移行ウェーブの最後にコストチェックポイントを実装しました。
# プロセスの視点
プロセスは一貫性をもたらしますが、各プロジェクトが一意であるため、進化し、変更の影響を受けやすくなります。プロセスを繰り返し実行すると、障害発生時、学習時、導入時、反復時に大きなメリットをもたらす可能性のある改善のギャップと余地を特定できます。これらの変更は、プロジェクトとビジネスが将来活用できる新しいアイデアやイノベーションにつながる可能性があり、品質とチームの自信をもたらす成長の促進要因となります。
移行プロセスは、以前にリンクされていない可能性のあるテクノロジーや境界を越えるため、複雑になる可能性があります。この視点は、大規模な移行の特定の要件に関するプロセスとガイダンスを提供します。
## 大規模な移行の準備
以下のセクションでは、移行ジャーニーを明確な方向性で開始し、成功に不可欠なステークホルダーからの賛同を得るために必要な基本原則の概要を説明します。
**Contents**
+ [ビジネスドライバーを定義し、タイムライン、範囲、戦略を伝える](#bus-drivers)
+ [ブロッカーの削除に役立つ明確なエスカレーションパスを定義する](#escalation)
+ [不要な変更を最小限に抑える](#change)
+ [end-to-endプロセスを早期に文書化する](#end-to-end)
+ [標準の移行パターンとアーティファクトを文書化する](#artifacts)
+ [移行メタデータとステータスの信頼できる単一のソースを確立する](#metadata)
### ビジネスドライバーを定義し、タイムライン、範囲、戦略を伝える
大規模な移行に近づくと AWS、サーバーを移行する方法が多数あることがすぐにわかります。例えば、次の操作を実行できます。
+ を使用してワークロードをリホストします[AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html)。
+ アプリケーションをコンテナ化し、[Amazon Elastic Container Service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) (Amazon ECS) または [Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) (Amazon EKS) マネージドコンテナプラットフォームでホストします。
+ ワークロードを完全なサーバーレスアプリケーションに再設計します。
正しい移行パスを決定するには、ビジネスドライバーから逆算することが重要です。最終的な目標がビジネスの俊敏性の向上である場合は、2 番目の 2 つのパターンを優先できます。これには、より多くのレベルの変換が含まれます。年末までにデータセンターを退避することを目標とする場合は、リホストの速度によってワークロードをリホストすることを選択できます。
大規模な移行には、通常、次のような幅広い利害関係者が関係します。
+ アプリ所有者
+ ネットワークチーム
+ データベース管理者
+ エグゼクティブスポンサー
移行のビジネス推進要因を特定し、移行プログラムのメンバーがアクセスできるプロジェクト憲章など、そのリストをドキュメントに含めることが重要です。さらに、目標とするビジネス成果に密接に一致する主要業績評価指標 (KPIs) を作成します。
たとえば、ある顧客が、データセンターを退避するという目標ビジネス成果を達成するために、12 か月以内に 2,000 台のサーバーを移行したいと考えています。ただし、セキュリティチームはこの目標に向けて調整されていませんでした。その結果、データセンターの閉鎖日を逃したが、アプリケーションをさらにモダナイズするか、最初にリホストしてタイムリーなデータセンターの閉鎖を可能にし、アプリケーションをモダナイズするかについて、数か月にわたる技術的な議論が行われました AWS。
### ブロッカーの削除に役立つ明確なエスカレーションパスを定義する
大規模なクラウド移行プログラムには、通常、幅広い利害関係者が参加します。結局のところ、数十年にわたってオンプレミスでホストされているアプリケーションが変更される可能性があります。各利害関係者が競合する優先順位を持つことが一般的です。
すべての優先順位が価値をもたらす可能性がありますが、プログラムは予算の量が制限され、目標成果が定義されます。さまざまなステークホルダーを管理し、目標とするビジネス成果に焦点を当てるのは難しい場合があります。この課題は、移行の対象となる数百または数千のアプリケーションに乗算すると複雑になります。さらに、ステークホルダーは、他の優先事項を持つさまざまなリーダーシップチームに報告する可能性があります。これを念頭に置いて、目標とするビジネス成果を明確に文書化するとともに、明確なエスカレーションマトリックスを定義してブロッカーを排除することが重要です。これにより、かなりの時間を節約し、さまざまなチームを共通の目標に合わせることができます。
この例の 1 つは、12 か月以内にプライマリデータセンターを退避することを目標とする金融サービス会社です。明確なマンデートやエスカレーションパスがなかったため、時間と予算の制約に関係なく、ステークホルダーが希望する移行パスを作成しました。CIO へのエスカレーション後、明確な義務が設定され、必要な決定をリクエストするためのメカニズムが提供されました。
### 不要な変更を最小限に抑える
変化は良好ですが、変化が多いほどリスクが高くなります。大規模な移行のビジネスケースが承認されると、特定の日付までにデータセンターを退避するなど、このイニシアチブを推進する目標とするビジネス成果が生じる可能性が高くなります。技術者が AWS サービスを最大限に活用するためにすべてを書き換えることは一般的ですが、これはビジネス目標ではないかもしれません。
ある顧客は、会社のウェブスケールインフラストラクチャ全体を 2 年間移行することに重点を置いていました AWS。アプリケーションチームがアプリケーションを書き換えて数か月を費やすことを防ぐためのメカニズムとして、2 週間のルールを作成しました。2 週間のルールを使用することで、顧客は何百ものアプリケーションを複数年にわたって移動する必要があったとき、一貫した頻度で長期的な移行を維持できました。詳細については、ブログ記事[「The Two-week Rule: Refactor Your Applications for the Cloud in 10 Days](https://aws.amazon.com/blogs/enterprise-strategy/the-two-week-rule-refactor-your-applications-for-the-cloud-in-10-days/)」を参照してください。
ビジネス成果と一致しない変更は最小限に抑えることをお勧めします。代わりに、将来のプロジェクトでこれらの追加変更を管理するメカニズムを構築します。
### end-to-endプロセスを早期に文書化する
大規模な移行プログラムの初期段階で、移行プロセス全体と所有権の割り当てを文書化します。このドキュメントは、移行の実行方法とその役割と責任についてすべての利害関係者を教育するために重要です。このドキュメントは、問題が発生する可能性のある場所を理解し、移行を進めるにつれてプロセスの更新と反復を提供するのに役立ちます。
移行プロジェクトの開発中に、既存のプロセスを理解し、統合ポイントと依存関係が明確に文書化されていることを確認します。変更リクエスト、サービスリクエスト、ベンダーサポート、ネットワークとファイアウォールのサポートなど、外部プロセス所有者とのエンゲージメントが必要な場所を含めます。プロセスを理解したら、責任、説明責任、相談、情報 (RACI) マトリックスに所有権を文書化して、さまざまなアクティビティを追跡することをお勧めします。プロセスを確定するには、移行の各ステップに関連するタイムラインを特定してカウントダウン計画を作成します。カウントダウンプランは通常、ワークロード移行のカットオーバー日時から逆算して機能します。
このドキュメントアプローチは、1 年未満で AWS 正常に に移行し、4 つのデータセンターを終了した多国籍のホームアプライアンス企業にとってうまく機能しました。6 つの異なる組織チームと複数のサードパーティーが関係していたため、管理オーバーヘッドが発生し、意思決定がback-and-forthし、実装が遅れました。 AWS プロフェッショナルサービスチームは、顧客とそのサードパーティーと協力して、移行アクティビティの主要なプロセスを特定し、それぞれの所有者に文書化しました。結果として得られた RACI マトリックスは、関係するすべてのチームによって共有され、合意されました。RACI マトリックスとエスカレーションマトリックスを使用して、お客様は遅延の原因となっていたブロック要因と問題を軽減しました。その後、データセンターをスケジュールどおりに終了できました。
RACI とエスカレーションマトリックスを使用する別の例では、保険会社は 4 か月以内にデータセンターを出ることができました。お客様は責任共有モデルを理解して実装し、詳細な RACI マトリックスに従って、移行中の各プロセスとアクティビティの進行状況を追跡しました。その結果、実装の最初の 12 週間で 350 を超えるサーバーを移行できました。
### 標準の移行パターンとアーティファクトを文書化する
これは、実装用の Cookie カッターを作成することを前提としています。再利用可能なリファレンス、ドキュメント、ランブック、パターンがスケーリングの鍵です。これらのジャーナルには、将来の移行プロジェクトが再利用して回避できる経験、学習、落とし穴、問題、ソリューションが記されており、移行を大幅に加速します。パターンとアーティファクトは、プロセスを改善し、将来のプロジェクトを導くのに役立つ投資でもあります。
たとえば、ある顧客が、3 つの異なる SI AWS パートナーによってアプリケーションが移行される 1 年間の移行を実行していました。初期段階では、各 AWS パートナーは独自の標準、ランブック、アーティファクトを使用していました。これにより、同じ情報がさまざまな方法で顧客チームに提示される可能性があるため、顧客チームに多くのストレスがかかりました。このような初期の苦労の後、顧客は移行で使用するすべてのドキュメントとアーティファクトの一元的な所有権を確立し、推奨される変更を送信するプロセスを確立しました。これらのアセットには以下が含まれます。
+ 標準の移行プロセスとチェックリスト
+ ネットワーク図のスタイルと形式の標準
+ ビジネス重要度に基づくアプリケーションアーキテクチャおよびセキュリティ標準
さらに、これらのドキュメントと標準への変更は毎週すべてのチームに送信され、各パートナーは変更の受信と準拠を確認する必要がありました。これにより、移行プロジェクトのコミュニケーションと一貫性が大幅に向上し、別のビジネスユニットで別の大規模な移行作業が開始されると、そのチームは既存のプロセスとドキュメントを採用でき、成功が大幅に加速しました。
### 移行メタデータとステータスの信頼できる単一のソースを確立する
大規模な移行を計画する場合、さまざまなチームを連携させ、データ駆動型の意思決定を可能にするには、信頼できる情報源を確立することが重要です。このジャーニーを開始すると、設定管理データベース (CMDB)、アプリケーションパフォーマンスモニタリングツール、インベントリリストなど、使用できる多数のデータソースが見つかる場合があります。
または、データソースが少なく、必要なデータをキャプチャするメカニズムを作成する必要があります。例えば、検出ツールを使用して技術情報を明らかにし、IT リーダーを調査してビジネス情報を取得する必要がある場合があります。
移行に使用できる 1 つのデータセットにさまざまなデータソースを集約することが重要です。その後、単一の信頼できるソースを使用して、実装中の移行を追跡できます。たとえば、移行されたサーバーを追跡できます。
提供されたデータセットを使用した移行の計画に重点を置いて、 AWS すべてのワークロードを に移行したいと考えている金融サービスの顧客。このデータセットにはビジネス重要度や依存関係情報などの重要なギャップがあったため、プログラムは検出演習を開始しました。
別の例では、同じ業界の企業が、サーバーインフラストラクチャインベントリout-of-date理解に基づいて移行ウェーブの実装に移行しました。データが正しくなかったため、すぐに移行数が減少し始めました。この場合、アプリケーション所有者は理解されなかったため、テスターを間に合うように見つけることができませんでした。さらに、データはアプリケーションチームが完了した廃止と一致していないため、サーバーはビジネス目的で使用されずに実行されていました。
## 大規模な移行の実行
ビジネス成果を確立し、ステークホルダーに戦略を伝えたら、大規模な移行の範囲を持続可能な移行イベントや波に取り込む方法の計画に進むことができます。次の例は、ウェーブプランを作成するための主要なガイダンスを提供します。
**Contents**
+ [安定したフローを確保するために、移行ウェーブを事前に計画する](#plan-waves)
+ [ウェーブ実装とウェーブ計画を個別のプロセスとチームとして維持する](#separate)
+ [大きな成果を得るために小規模から始める](#start-small)
+ [カットオーバーウィンドウの数を最小限に抑える](#cutover-numbers)
+ [フェイルファスト、エクスペリエンスの適用、反復](#iterate)
+ [遡及情報を忘れないでください。](#retrospective)
### 安定したフローを確保するために、移行ウェーブを事前に計画する
移行の計画は、プログラムの最も重要なフェーズの 1 つです。「計画に失敗した場合、失敗する予定」と書かれています。移行ウェーブを事前に計画しておくと、チームが移行状況に対してより積極的になるにつれて、プロジェクトが迅速に流れるようになります。これにより、プロジェクトのスケーリングが容易になり、プロジェクトの需要が増加し、複雑になるにつれて意思決定と予測が向上します。前もって計画することで、チームが変化に適応する能力も向上します。
例えば、ある大規模な金融サービスの顧客がデータセンターの出口プログラムに取り組んでいました。当初、お客様は移行ウェーブを順番に計画し、1 つのウェーブを完了してから次のウェーブの計画を開始します。このアプローチにより、準備時間が短縮されました。利害関係者がアプリケーションが移行されていることを知らされても AWS、移行を開始する前にいくつかのステップを実行する必要がありました。これにより、プログラムに大幅な遅延が発生しました。顧客がこれを認識した後、移行ウェーブが数か月前に計画された、包括的で未来に焦点を当てた移行計画ストリームを実装しました。これにより、アプリケーションチームは、 AWS パートナーへの通知、ライセンス分析などの移行前アクティビティを実行するのに十分な通知が提供されました。その後、プログラムの重要なパスからこれらのタスクを削除できます。
### ウェーブ実装とウェーブ計画を個別のプロセスとチームとして維持する
ウェーブプランニングチームとウェーブ実装チームが別々の場合、2 つのプロセスは並行して機能します。通信と調整では、十分なサーバーやアプリケーションが期待速度を達成する準備ができていないため、移行が遅くなるのを回避できます。例えば、移行チームは毎週 30 台の サーバーを移行する必要があるかもしれませんが、現在のウェーブでは 10 台の サーバーしか準備ができていません。この課題は、多くの場合、以下が原因で発生します。
+ 移行実装チームはウェーブプランニングに関与しておらず、ウェーブプランニングフェーズで収集されたデータも完了していません。移行実装チームは、ウェーブを開始する前により多くのサーバーデータを収集する必要があります。
+ 移行実装は、ウェーブ計画の直後に開始される予定であり、間にバッファはありません。
事前にウェーブを計画し、準備とウェーブ実装の開始の間にバッファを作成することが重要です。また、ウェーブプランニングチームと移行チームが連携して適切なデータを収集し、再作業を避けることも重要です。
### 大きな成果を得るために小規模から始める
小規模から始めて、その後のウェーブごとに移行速度を上げることを計画します。初期ウェーブは、10 台未満の単一の小さなアプリケーションである必要があります 。後続のウェーブにアプリケーションとサーバーを追加し、移行速度を最大限に向上させます。複雑性やリスクの低いアプリケーションを優先し、スケジュールに従って速度を上げることで、チームは連携して作業し、プロセスを学習する時間を確保できます。さらに、チームはウェーブごとにプロセスの改善を特定して実装できるため、後のウェーブの速度を大幅に向上させることができます。
あるお客様は、年間 1,300 台を超える サーバーを移行していました。パイロット移行といくつかの小さなウェーブから始めることで、移行チームは後の移行を改善する複数の方法を特定できました。例えば、以前に新しいデータセンターネットワークセグメントを特定しました。プロセスの早い段階でファイアウォールチームと協力して、移行ツールとの通信を可能にするファイアウォールルールを設定しました。これにより、将来の波での不要な遅延を防ぐことができます。さらに、チームは、各ウェーブで検出プロセスとカットオーバープロセスをさらに自動化するスクリプトを開発することができました。小規模から始めることで、チームは初期のプロセス改善に集中し、自信が大幅に高まりました。
### カットオーバーウィンドウの数を最小限に抑える
大規模な移行には、スケールを推進するための統制のとれたアプローチが必要です。一部の領域で柔軟性が高すぎることは、大規模な移行にはアンチパターンです。毎週のカットオーバーウィンドウの数を制限することで、カットオーバーアクティビティに費やされる時間が高くなります。
たとえば、カットオーバーウィンドウの柔軟性が高すぎる場合、それぞれ 5 台のサーバーで 20 回の カットオーバーが発生する可能性があります。代わりに、それぞれ 50 台の サーバーで 2 つのカットオーバーを行うことができます。各カットオーバーの時間と労力は似ているため、カットオーバーが少なくて大きいほど、スケジューリングの運用上の負担が軽減され、不要な遅延が制限されます。
ある大規模なテクノロジー企業が、契約の有効期限が切れる前にいくつかのリースデータセンターから移行しようとしていました。有効期限が切れると、費用がかかり、短期的な更新期間が発生します。移行の前半では、アプリケーションチームは、カットオーバーのわずか数日前に何らかの理由で移行をオプトアウトするなど、過去 1 分間の移行スケジュールを指示することができました。これにより、プロジェクトの初期段階で多数の遅延が発生しました。多くの場合、顧客は過去 1 分間に他のアプリケーションチームと交渉して入力する必要がありました。顧客は最終的に計画の規律を高めましたが、この初期のミスは移行チームに継続的なストレスをもたらしました。スケジュール全体の遅延により、一部のアプリケーションがデータセンターから間に合わなくなりました。
### フェイルファスト、エクスペリエンスの適用、反復
すべての移行には、最初は落とし穴があります。早期失敗は、チームが学習し、ボトルネックを理解し、学んだ教訓をより大きな波に適用するのに役立ちます。移行の最初の数波は、次の理由で遅くなることが予想されます。
+ チームメンバーはお互いとプロセスに適応しています。
+ 大規模な移行には、通常、さまざまなツールや人が関係します。
+ end-to-endのプロセスの統合、テスト、失敗、学習、継続的な改善には時間がかかります。
問題は一般的であり、最初の数回のウェーブ中に予期されます。一部のチームは新しいことを試して失敗することを好まない可能性があるため、これを理解し、組織全体に伝えることが重要です。失敗すると、チームが失望し、将来の移行の妨げになる可能性があります。最初の問題がジョブの一部であることを全員が理解し、全員が失敗するように促すことが、移行を成功させるための鍵となります。
ある会社では、24～36 か月で 10,000 台を超える サーバーを移行する予定です。この目標を達成するには、1 か月あたり約 300 台の サーバーを移行する必要がありました。ただし、1 日目から 300 台の サーバーを移行したわけではありません。最初の 2 つの波はウェーブを学習することでした。これにより、チームは物事がどのように機能し、誰が何を行う権限を持っているかを理解できます。また、CMDB や CyberArk との統合など、プロセスを改善する統合も特定しました。学習ウェーブを使用して失敗、改善、失敗し直し、プロセスと自動化を改善しました。6 か月後、毎週 120 を超える サーバーを移行できました。
### 遡及情報を忘れないでください。
これはアジャイルプロセスの重要な部分です。チームがコミュニケーション、調整、学習、同意、前進する場所です。最も基本的なレベルでの遡及は、振り返って何が起こったのかを議論し、何がうまくいき、何を改善する必要があるのかを判断することです。その後、それらの議論に基づいて改善を構築できます。遡及的思考は、教訓を学ぶという考え方に形式やプロセスを巻き付けます。大規模な移行を成功させるには、プロセス、ツール、チームが常に進化し、改善する必要があるため、遡及性は重要です。遡及的分析はその中で重要な役割を果たします。
従来の教訓学習セッションはプログラムの最後まで行われないため、多くの場合、これらの教訓は次の移行ウェーブの開始時にレビューされません。大規模な移行では、学んだ教訓を次のウェーブに適用し、ウェーブ計画プロセスの重要な部分とする必要があります。
ある顧客については、カットオーバーから学んだ教訓について議論し、文書化するために、毎週の遡及調査が行われました。これらのセッションでは、プロセスの観点や自動化から合理化の範囲がある領域を発見しました。これにより、カットオーバー中のサードパーティーツールの検証や Amazon CloudWatch エージェントのインストールなど、手動タスクを最小限に抑えるために、特定のアクティビティ、所有者、自動化スクリプトを含むカウントダウンスケジュールが実装されました。
別の大規模なテクノロジー企業では、以前の移行ウェーブの問題を特定するために、チームと定期的な遡及調査を実施しました。これにより、プロセス、スクリプト、自動化が改善され、プログラム全体で平均移行時間が 40% 短縮されました。
## その他の考慮事項
多くの分野を大規模な移行プログラムに組み込む必要があります。以下のセクションでは、考慮すべき他の項目について説明します。
**Contents**
+ [移動中にクリーンアップする](#clean-up)
+ [追加の変換のために複数のフェーズを実装する](#phases)
### 移動中にクリーンアップする
コストが予想の 10 倍で、移行に使用されるリソースがシャットダウンされてクリーンアップされるまでプロジェクトが完了していない場合、移行は成功とは見なされません。このクリーンアップは、移行後のアクティビティの一部である必要があります。これにより、未使用のリソースやサービスが環境内に残ってコストが増加することがなくなります。移行後のクリーンアップは、環境を公開する脅威や脆弱性を防ぐためにも優れたセキュリティプラクティスです。
への移行の主な成果 AWS クラウド は、コスト削減とセキュリティの 2 つです。未使用のリソースを残すと、クラウドへの移行というビジネス目的が損なわれる可能性があります。クリーンアップされていない最も一般的なリソースは次のとおりです。
+ テストデータ
+ データベースをテストする
+ ファイアウォールルール、セキュリティグループ、ネットワークアクセスコントロールリスト (ネットワーク ACL) IP アドレスを含むアカウントのテスト
+ テスト用にプロビジョニングされたポート
+ Amazon Elastic Block Store (Amazon EBS) ボリューム
+ スナップショット
+ レプリケーション (オンプレミスから へのデータレプリケーションの停止など AWS)
+ スペースを消費するファイル (移行に使用される一時データベースバックアップなど)
+ 移行ツールをホストするインスタンス
不正なクリーンアッププラクティスの一例では、SI AWS パートナーは移行が成功した後にレプリケーションエージェントを削除しませんでした。 AWS 監査では、すでに移行されていたレプリケーションサーバーと EBS ボリュームのコストは毎月 20,000 USD (USD) であることがわかりました。この問題を軽減するために、 AWS Professional Services は、古いサーバーがまだレプリケートされているときに SI AWS パートナーに通知する自動監査プロセスを作成しました。その後、SI AWS パートナーは未使用の古いインスタンスに対してアクションを実行できます。
今後の移行では、移行後のハイパーケア期間として 48 時間を定義し、プラットフォームのスムーズな導入を保証するプロセスを採用しました。次に、お客様のインフラストラクチャチームがオンプレミスサーバーに対する廃止リクエストを送信しました。廃止リクエストが承認されると、それぞれのウェーブのサーバーがアプリケーション移行サービスコンソールから削除されることが通知されました。
### 追加の変換のために複数のフェーズを実装する
大規模な移行を実行するときは、データセンターの閉鎖やインフラストラクチャの変革など、中心的な目標に集中し続けることが重要です。小規模な移行では、スコープのクリープの影響は最小限に抑えられます。ただし、数日の追加作業に数千のサーバーを掛けると、プログラムにかなりの時間がかかる可能性があります。さらに、追加の変更により、サポートチームのドキュメント、プロセス、トレーニングの更新が必要になる場合もあります。
潜在的なスコープクリープを克服するには、移行に複数フェーズのアプローチを実装できます。例えば、データセンターを退避することが目標である場合、フェーズ 1 にはワークロードをできるだけ AWS 速くリホストすることのみが含まれる場合があります。ワークロードがリホストされると、フェーズ 2 はターゲットのビジネス成果を危険にさらすことなく、変革的なアクティビティを実装できます。
たとえば、ある顧客が 12 か月以内にデータセンターを出る予定でした。ただし、移行には、新しいアプリケーションパフォーマンスモニタリングツールのロールアウトやオペレーティングシステムのアップグレードなど、他の変換アクティビティが含まれていました。1,000 台を超える サーバーが移行対象であったため、これらのアクティビティにより移行が大幅に遅れました。さらに、このアプローチでは、新しいツールの使用に関するトレーニングが必要でした。顧客は後で、リホストに重点を置いた複数フェーズのアプローチを実装することを決定しました。これにより、移行速度が向上し、データセンターの閉鎖日を満たさないリスクが軽減されました。