Amazon Web Services ブログ

レガシーなモノリシックアプリを AWS でモダナイズする10ステップ

この記事は、”Ten steps to modernizing legacy monoliths in the AWS Cloud”を翻訳したものです。

モダナイゼーションの課題

レガシーなモノリシックアプリケーションをモダナイズするプロセスは複雑であり、しばしば成功するまでに数年かかり、その過程で組織はさまざまな障害に直面します。主な課題の 1 つは、変更の影響を受けるビジネスプロセスが移行中および移行後もシームレスにに運用され続けることを確認することです。組織は、大がかりなビッグバン形式のリリースを行うか、小さなサイクルでリリースを行い中断を最小限に抑えるかを決める必要があります。後者の場合、モノリシックなアプリケーションをどのように小さな部分に分割するかを明らかにすることが大きな課題となります。

モダナイゼーションを開始する前に見過ごされがちですが、重要なステップは、目的を明確に特定し、動機を理解し、成功の指標を設定することです。モダナイゼーションが必要な理由として、しばしば古いハードウェアやソフトウェアの保守の困難さ、サポートコストの増加、サポート契約期限切れに伴う既存のシステムの廃止の必要性が挙げられます。しかし、古い技術だけではシステムの更新の理由にはなりません。成功したモダナイゼーション戦略は、コストの削減、効率の向上、既存の投資の最大活用といったビジネス目標を優先させます。最終的には、レガシーシステムをアジャイル、スケーラブル、柔軟な環境に変革し、実質的なビジネス上のメリットをもたらすことを目指しています。

マイグレーションパス

クラウドへのアプリケーションの移行には、7 つの戦略である「7 R」があります。リタイア、リテイン、リホスト、リロケート、リパーチェス、リプラットフォーム、リファクタリング/リアーキテクトです。リファクタリングは、クラウド移行時にアプリケーションをモダナイズし、アーキテクチャをクラウドベースの機能を利用するように変換することで、アジリティ、パフォーマンス、スケーラビリティを強化します。迅速な開発、スケーラビリティ、コスト削減の要求に応えるために選択されます。典型的なシナリオには、レガシーシステムの制限の克服、モノリシックなアプリケーションの高速デリバリーの課題への対処、保守が困難なレガシーソフトウェアの管理、テスト容易性とセキュリティの向上が含まれます。

この記事では、Volkswagen AG と AWS での経験に基づいて、レガシーモノリシックなアプリケーションのリファクタリング手順を 10 ステップで説明しています (図 1)。ビジネスプロセスやビジネス機能に基づいてモノリシックなアプリケーションを 分割し、その後 ストラングラー・フィグ・パターンを適用することを推奨しています。このパターンでは、新しいサービスでレガシーシステムの機能を徐々に置き換えていきます。目標は、レガシーシステムとモダナイズされたシステムを共存させながら、スムーズな移行を実現することです。完全な置き換えが完了するまでその状態が続きます。

図 1 – リファクタリングのための10ステップのプロセスフロー

ステップ 1 – 目標と成功のためのKPIの概要を示す
組織全体の戦略的目標に沿うように、モダナイズの取り組みの企業目標と技術目標を理解し概要を示します。そして、コスト削減、柔軟性向上、オペレーション効率の向上、サイクル時間の短縮、生産性の向上などの具体的なビジネス目標に基づく第一動機を理解しながら、主要な原動力を特定します。

成功の KPI
モダナイゼーションの成功を測るために、顧客ニーズとの整合性を確保し、オペレーショナル・エクセレンスを推進するため、ビジネス面と技術面の両方で主要業績評価指標 (KPI) を設定します。ゴール、質問、指標 (GQM) フレームワークを使用して、目的と関連する指標を特定します。指標は主に 2 つのグループに分類できます。

1. プロダクトメトリクスは、新機能がビジネス運営に与える影響など、お客様への価値提供に焦点を当てています。
2. 運用メトリクスは、リードタイム、サイクルタイム、デプロイ頻度、サービス復旧時間、変更失敗率など、ソフトウェア開発プロセスの改善に焦点を当てています。

ステップ 2 – ビジネスプロセスとケーパビリティをマッピング
バリューストリーム (リーン原則) および企業資産管理 (EAM) プロセスを把握することで、識別されたビジネスプロセスの効率化と確立された目標が合致することを保証できます。ビジネスプロセス分析 (BPA) では、内部のワークフローを検証して最適なプロセスを導きます。プロセスフロー図を作成すれば、複雑なプロセスを単純化し、相互作用を明確にし、ユーザ関連のワークフローの分析と改善を支援できます。これらの図は、ステークホルダー向けの明確な概要を提供し、事業を自動化して効率と生産性を高める改善案を着想するきっかけにもなります。

モダナイゼーションは、従来のシステムから移行するだけでなく、新しい環境でそれらを再構築することを目指しています。現在と将来の業務機能を特定し、scaled agile framework (SAFe) の戦略的テーマを統合します。「現状」の徹底的な分析をターゲットのビジョンと合わせて行うと、新しい機能を導入するためのギャップが明らかになります。プロセスや機能が実際の価値の流れとは無関係な歴史的、政治的、または技術的な理由で存在することがよくあります。このステップでは、柔軟性に欠けるレガシーシステムによって発生した手動プロセスとシステムのギャップに対処します。例えば、定期的なスプレッドシート計算は新しいシステムに統合し、別々の管理と電話やメールでの対応を、イベントトリガーによる通知で自動化できます。

ステップ 3 – ビジネスケーパビリティと将来のサービスをマッピングする
このステップでは、以前に特定されたビジネスケーパビリティを、ビジネス要件と技術的ソリューションを関連付けた詳細なケーパビリティ – サービスマップを作成することで、将来のサービスにマッピングします。アプリケーションは、特定のユースケース向けにカスタマイズされたモノリシックなものから始まることが多いですが、内部構造が貧弱、保守コストが高い、新しい開発者のオンボーディングでサポートコストが増大するなどの理由から、モダンな環境での制限に直面することが多くあります。高い結合度と低い凝集度により、新機能の追加が大幅に遅れる可能性があります。原因は、メジャーアップデートのためのチーム間の広範な調整が必要となるためです。

これらの課題に対処するために、マイクロサービスのアーキテクチャが採用され、継続的インテグレーションおよびデプロイ (CI/CD) の実践を通じて開発の高速化とスケーリングの容易化が図られます。この段階では、新しいマイクロサービスとターゲットの API が特定され、定義されます。新しいマイクロサービスは明確な境界線と特定の機能を持つように設計され、独立して開発、デプロイ、スケーリングができるようになります。

ステップ 4 – モノリシックアプリケーションの分割とプロダクトチームの編成
レガシーのモノリシックアプリケーションを分割するには、特定されたサービスを論理的に分類して一貫したユニットを構築し、それらの運用範囲を設定する必要があります。これらのユニットは、独立したアプリケーションとして、または広範なプロダクトの一部として、あるいは複数のアプリケーションにまたがって動作する可能性があります。分割は次の手順で行えます。(1) ドメイン駆動設計の中心的なパターンであるバウンデッドコンテキストによりプロダクトを特定し分離する。(2) 依存関係とデータフローを特定する。(3) ストラングラーパターンを使って移行パスと優先順位を決める。

このステップの目的は、サービスを各システムに合わせて効率化および統合を最適化し、組織の戦略的方向性と変化への対応力を支える明確なドメインモデルを作成することです。さらに、このステップではドメイン駆動設計の原理に従って、新規または既存の境界づけられたコンテキストを中心としたプロダクトチームを編成します。ビジネス ユーザーの配置を考慮し、プロセス オーナーを特定し、自律したプロダクトチームを設立します。これらのチームを特定のドメインまたはコンテキストに合わせることで、集中した開発、スムーズなデリバリ、より良いプロダクト管理が可能になります。

ステップ 5 – データフローを特定し、統合層を確立する
データフロー図を使用して、上流と下流の内部および外部データフローをマッピングし、真のデータ所有者を特定します。なぜなら、時間の経過とともにレガシーシステムが下流システムの主要なデータソースになる傾向があるためです。これにより、データをオリジナルソースから新しいアプリケーションに直接ルーティングできるようになり、レガシーシステムへの依存度が低減します。あらゆるデータ責任を新しく作成したアプリケーションに移譲し、これらがデプロイされ稼働した後の下流データフローに対処してください。データフローをレガシーシステムから外れた経路に振り分けることで、完全に移行するまでレガシーシステムと新しいアプリケーション間で必要なデータ同期を最小限に抑えることができます。さらに、モダナイズ後にレポートおよび分析機能がどのように適応するかを評価し、分散型レポートか集中型レポートを選択し、新しいデータソースを決定する必要があります。

効果的な統合層を構築するには、現在の通信プロトコルを評価し、アプリケーション間のデータフローを促進するための今後の変更点を特定する必要があります。統合層では、次の 3 つの主要なデータフローに対処する必要があります。(1) 従来のアプリと新しいアプリとの間のデータ同期(2) 新しく作成されたアプリに割り当てられたアップストリームとダウンストリームのデータ責任(3) 新しいシステム内部のデータフロー

ステップ 6 – 共有およびプラットフォーム全体のサービスを特定して構造化する
機能を特定してサービスに対応付けると、一部のサービスが共通で共有できることがわかります。これらのサービスを共有サービスまたは基盤プラットフォームサービスとして分類します。共有サービスは、認証やアクセス制御のための認証・承認サービス、アラートや更新の通知システム、ロギングなど、複数のアプリケーションにまたがる横断的な関心事に対応します。プラットフォーム サービスは、全体のプラットフォームをまたいでイベント駆動型のアーキテクチャを構築できるようにする統合サービスなどの基本的なコンポーネントです。共有サービスまたはプラットフォームサービスとしてこの戦略的な分類を行うことで、冗長な機能を排除し、効率的で一貫したアプリケーション環境を促進できます。これらのサービスは、標準化と再利用を通じて、さまざまなアプリケーションをサポートするスケーラブルで一貫したフレームワークを提供します。

ステップ 7 – 非機能要件を文書化する
レイテンシ、スループット、データ残存などの重要な非機能的側面を詳述します。これらの要素を理解することは、デプロイ戦略を決定し、モダナイズされたアプリケーションがパフォーマンス基準を満たし、規制やコンプライアンス基準を順守し、組織の運用目標と合致することを確実にする上で不可欠です。このステップでは、リソースの最適化、セキュリティ対策の強化、スケーラビリティと信頼性の確保を行います。これらの要件を明確に定義することで、チームは明確な期待値を設定し、効果的な計画とテストを可能にし、シームレスなユーザーエクスペリエンスと堅牢な運用継続性を実現するソリューションを提供できます。

ステップ 8 – 技術選定と達成したい状態を定義する
データベース、バックエンドサービス、フロントエンドコンポーネントなど、アプリケーションに適した技術スタックを決定します。バックエンドサービスにはコンテナ化を取り入れ、ポータビリティとスケーラビリティを高めます。これは組織のプラットフォームの選択と、チームの専門性に沿ったものです。技術選定には、モジュール性と業界標準の遵守など、原則に沿った決定を行います。アプリケーションおよびデータ アーキテクチャ、ターゲットのデータモデル、統合ポイント、データフロー、API エンドポイントの定義、サービスの相互作用について詳細なターゲット状態の設計を作成してください。目標は、システムの理想的な最終状態を捉えた首尾一貫したブループリントを作成し、ベストプラクティスに沿うこと、長期的なビジョンをサポートし、変化するビジネスニーズに迅速に適応しながら、将来の開発を最適化することです。

ステップ 9 – MVP の開発
最小機能製品 (MVP) の最初のアプリケーションのデプロイを計画します。複雑さが低く、依存関係が少なく、初期の分離において高いビジネス価値があるものに焦点を当てます。これにより、ビジネス価値の迅速なデモンストレーションが可能になり、必要な実装プロセスが設定されます。ユーザーの参加スピードや地理的な影響など、即時的な恩恵を最大化する要因に基づいて MVP を優先順位付けします。リスクの低い管理可能なプロジェクトから始めることで、初期の成功が容易になり、信頼が構築され、スケーラブルなモダナイゼーションの基盤が確立されます。

この方法に従えば、プロダクトチームは予め定められた成功基準に沿って MVP アプリケーションを立ち上げます。成功した場合は、チームメンバーが新しいグループを形成して他のアプリケーションを開発し、分割してシーディングする戦略を用いて段階的にモダナイズを拡大します。

ステップ 10 – ロールアウト戦略とデータ移行計画を作成する
順調な移行と、アプリケーションの成功裏な立ち上げのためには、ロールアウト、データ移行、切り替えの綿密な計画が不可欠です。特定のユーザーグループにカナリアリリースを利用するなどし、ビジネスチームとダウンタイムの調整を行うことで、リスクを最小限に抑えます。ミッションクリティカルなアプリケーションでは、一時的にキューを活用し、新システムが運用可能になるまで受信リクエストを管理し、リダイレクトします。新しい MVP をそれまでのシステムと併用し、新システムが完全に引き継ぐまでデータの整合性とトランザクションのセキュリティを確保します。両システム間でデータの一貫性を保ち、アクションがトランザクションとして安全であることを確認します。移行専用のコードを後から削除できるよう設計します。

移行前に、データ量とデータ移行のパフォーマンスを考慮したデータ移行およびデータ同期の計画を立ててください。AWS は、AWS Data Migration Service (AWS DMS) がオンプレミスから AWS へのデータベース移行、AWS DataSync がオンプレミスと AWS ストレージサービス間のデータ移行の自動化と高速化、AWS Transfer Family が企業間の継続的なファイル転送の AWS ストレージサービスへの安全なスケーリングを実現する包括的なデータ転送サービスを提供しています。これらのサービスは、オンプレミスシステムとクラウドストレージの統合を合理化し、オンラインおよびオフラインのデータ移行を容易にします。

レガシーシステムから堅牢な DevOps アプローチに徐々に移行し、リリース後に問題が発生した場合の ロールバックに備えることで、運用上の要件を満たします。変更管理プロセスを改善して、より俊敏な 開発とリリースを実現し、市場投入時間を短縮します。
レガシーシステムと新しい MVP を並行して実行しながら、モダナイズしたアプリケーションが目的を果たした時点で、レガシー機能の廃止を計画、スケジュールします。

Volkswagen AG におけるレガシーモダナイゼーションの事例

この Volkswagen AG (VW) における IT 変革の例では、レガシーモノリスアプリケーションをアップグレードし、新機能とクロスプロセス機能を追加しながら、モダンな AWS クラウドインフラストラクチャへの移行中のビジネスリスクを削減するために、チームが特定のパターンとステップを利用した様子が示されています (図 2)。

Figure 2 – Volkswagen refactor example図 2 – Volkswagen 移行プロセス 例

ビジネスプロセスの概要を説明した後、レガシーシステムはプロセス単位で分割され、新しいシステムの機能について最終決定を行う専任のビジネスオーナーが配置されました。レガシーシステムの知識の低下と古い文書化のため、新製品の機能を定義するために、ビジネスオーナーと複数のステークホルダー面談を行う必要がありました。
VW チームは、目標、ビジネス影響、依存関係、相乗効果、実装するモジュールの全体的な複雑さに基づいて MVP の優先順位を決定しました。モダナイズが必要な従属システムについて、ロールアウト計画が検討され、ブランドごとに実施されました。一部のブランドがレガシーシステムを引き続き使用していたため、モダナイズされたシステムからレガシーシステムへのデータ同期が必要でした。共通の統合レイヤーを確立することが重要なステップで、これによりソース、モダナイズ、ダウンストリームのシステム間の新しいデータ交換と、レガシーシステムへのデータ同期が可能になりました。

教訓

複雑なモノリシックシステムをモダナイズするプロジェクトでは、同様の課題が何度も発生しています。

  • これらのシステムは多くの場合、共通のデータベースを持っていました。通常、システムのすべてのモジュールで共有される、中央のリレーショナルデータベースが備わっていました。
  • データフローは年々要件に基づいて成長し、システム全体の見直しは稀にしか行われませんでした。
  • 新しい要件では、システムに新しい機能が追加され、旧式の機能を削除することなく、複雑さがさらに増し続けました。
  • 個々のモジュールは密接に結合されており、当初の役割分担の明確な分離とモジュール間の境界が多くの場所でぼやけてしまいました。

これらの点の総体は以下のようになります。

  • システムを拡張するには多大な費用がかかりました。
  • 実装された機能に関する知識が失われていきました。
  • 新しいユースケースは遅れがちだったり、多大な費用がかかりました。

多くの場合、システムの刷新は、一から作り直したり、一度に全面的に入れ替えたりすることはできませんでした。課題は、置き換え対象のシステムが新システムと長期間並行して稼働する必要があったことです。つまり、両方のシステムでデータを常に同期させ、トランザクションを安全に実行する必要がありました。

こうした場合に更新を成功させるには、次のことが重要でした。

  • 組織とステークホルダーのビジョンを理解する。
  • 業務プロセス、価値の流れ、該当ドメイン内の情報の流れを把握する。
  • ビジネスおよび技術的な目標をサポートするために、対象システムに必要な機能を導き出す。
  • 移行戦略を立案する。

まとめ

レガシーモノリスアプリケーションのモダナイズは、慎重な計画、実行、モニタリングを要する戦略的な旅路です。このブログの 10 の手順に従うことで、組織はレガシーのモダナイズの複雑さに対処し、進化する要求に応えることができます。主要な要素には、ビジネス目標との整合性、クラウド機能の利用、シームレスなデータ移行、主要な指標に対する継続的なパフォーマンス測定が含まれます。成功した変革の報酬は非常に大きく、成長と革新の新しい機会と並んで、ビジネス上の利点がもたらされます。レガシーアプリケーションのモダナイズに関するガイダンスを受け、AWS がどのようにモダナイズの旅路を支援できるかを知るには、AWS の自動車向業界向けページを訪問するか、 AWS チーム までお問い合わせください。

翻訳はソリューションアーキテクトの小森谷が担当しました。原文はこちら