翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
移行フェーズ
大規模な移行は、準備段階と計画段階で定義、テストされた構成要素、プロセス、ツール、リソース、方法論で構成されます。以前のフェーズで学んだベストプラクティスと教訓を活用した後、自動化とアジャイルデリバリーを通じて、実装と運用のスケーリングのブループリントであるマイグレーションファクトリーを実装することができます。
移行ファクトリー
移行プロジェクトのスケールアウトフェーズでは、複数のチームが同時に作業することになります。中には、リホストやマイナーリプラットフォームのパターンで大量の移行をサポートするチームもあります。これらのチームは移行ファクトリーと呼ばれます。移行ファクトリーは、複数のスプリントチームが並行して作業することで、移行計画のスピードを向上させます。企業アプリケーションポートフォリオの 20～50% は、ファクトリーアプローチによって最適化できるパターンの繰り返しで構成されています。これはアジャイルデリバリーモデルであり、リリース管理計画を作成することが重要です。計画は、準備段階と計画段階で生成された現在のワークロードと情報に基づいて作成する必要があります。将来の移行の波と将来の移行チームのために、継続的に最適化されるべきです。各チームに 3 つのスプリントをサポートするアプリケーションのバックログを持つことをお勧めします。これにより、スケジュールに影響する問題が発生した場合に、アプリケーションの優先順位を変更することができます。
大規模で複雑なアプリケーションでは、多くの場合、リファクタリング/リアーキテクトのパターンに従います。これらは通常、アプリケーションの所有者が計画したリリースサイクルで実施します。ファクトリチームは自給自足で、5 ～ 6 つの部門横断的な役割を担っています。その中には、オペレーション、ビジネスアナリスト、オーナー、移行エンジニア、開発者、 DevOps の専門家が含まれます。移行ファクトリーチームが特に力を入れている例を次に示します:
-
リホスト移行チームは、重要な変更を必要としない、大量かつ複雑性の低いアプリケーションを移行します。これらのチームは移行自動化ツールを活用します。このアプローチはパッチとリリースの管理プロセスに組み込まれています。
-
リプラットフォーム移行チームは、プラットフォームの変更やアプリケーションアーキテクチャの反復可能な変更を必要とするアプリケーションを設計して移行します。
-
リファクタリング/リアーキテクト移行チームは、依存関係の多い複雑または中核となるビジネスアプリケーションを設計して移行します。ほとんどの場合、開発チームと技術運用チームがこのビジネス能力をサポートします。移行は、そのチームの計画におけるリリースサイクルまたは数回のリリースサイクルになります。これらが数多く飛び交う可能性があり、Cloud Business Office (CBO) は、移行が完了するまでのタイミング、リスク、および問題を追跡する責任があります。このチームがアプリケーションの移行プロセスを担当します。
考慮が必要な項目:
-
ポートフォリオ分析を実施して、すべてのアプリケーションに共通するパターンを把握することで、ファクトリーチームが効率的に実装できる反復可能な作業を構築できます。
-
AWS パートナーを使って、チームが通常のビジネス活動をサポートする際のリソース制約を支援します。 AWS および AWS パートナーコミュニティは、データベース、アプリケーション開発、移行ツールなどの特定のトピックに特化したリソースを提供できます。
ハウツーガイド
