移行アーキテクチャ

レガシーシステムの置換を容易にするためにインストールされるソフトウェア要素。置換が完了したら削除する予定です。

2022年3月28日

レガシー置換を成功させるための核心は、レガシーを新しいソフトウェアで段階的に置き換えることです。これにより、早期にメリットを提供し、ビッグバンに伴うリスクを回避できます。置換の間、レガシーシステムと新しいシステムは同時に動作する必要があり、動作を古いものと新しいものの間で分割できます。さらに、この2つ間の分業は、レガシーが徐々に廃止されるにつれて定期的に変化します。

レガシーと新しいものとの間のこの相互作用を可能にするために、時間の経過とともに変化するこのコラボレーションをサポートする移行アーキテクチャを構築および進化させる必要があります。中間構成では、新しいシステムのターゲットアーキテクチャには不要な統合が必要になる場合があります。

または、より直接的に言うと、あなたは無駄になる作業に投資する必要があります。

仕組み

建物の改修を考えてみましょう。建築家が完成品のレンダリングを提供し、建設業者が開始の準備をしています。しかし、最初のステップは、建設現場に足場を設置することです。

足場自体を借り、それを建設するチームに支払うことは避けられない投資です。これは重要な作業を可能にするために必要であり、改修中のリスクを軽減して作業者の安全性を高めます。また、新しいオプションのロックを解除する可能性があります。屋根を交換中に煙突を修理したり、伸びすぎた木々を処理したりできます（比喩をさらに広げると）。作業が完了すると、別のチームが到着して足場を解体します。そして、あなたはそれが見えなくなることを喜んで受け入れます。

レガシー置換のコンテキストでは、この足場は、ターゲットアーキテクチャに向けた現在の進化ステップの構築を容易にする、または可能にするソフトウェアコンポーネントで構成されています。足場のように、これらのソフトウェアコンポーネントはターゲットアーキテクチャに到達すると不要になり、削除する必要があります。

大規模なレガシーモノリスを一度に置き換えるのはリスクが高いため、いくつかのステップで置き換えることで、ビジネスの安全性を向上させることができます。バリューストリームの抽出や製品ラインの抽出などのパターンを使用して、機能のサブセットまたはデータのサブセットによってこれを行うことができます。これらを行うには、モノリスを分割する必要があり、そのためには、モノリスに分離のためのシームを導入して、その各部分を分離する必要があります。モノリスにシームを導入するコンポーネントは、モノリスが置き換えられると必然的に消滅するため、移行アーキテクチャです。また、モノリスが既存の義務を果たすためにも必要ではありません。

モノリスの異なる部分がどのように相互に通信するかを確認し、通信パスにコンポーネントを配置することでシームを導入できます。コンポーネントは、トラフィックを他の要素に迂回または複製するように変更します。イベントインターセプションは、イベントを介した通信でこれを行います。抽象化による分岐は、APIでこれを行います。これらのシームを作成すると、レガシーミミックを導入して、レガシー通信フローに新しいコンポーネントを導入できます。

レガシー置換における最大の課題の1つは、レガシーシステムが直接アクセスすることが多いデータの処理です。可能であれば、リポジトリパターンを採用するなど、APIを導入することで直接データアクセスを置き換えることでシームを導入することをお勧めします。しかし、それができない場合は、システムの状態を複製する必要があります。レガシーミミックとイベントインターセプションは、このパスをたどる必要が生じた場合に両方とも役立ちます。

移行アーキテクチャとして一般的に使用されるパターン
使用	パターン
シームの作成	イベントインターセプションレガシーミミック抽象化による分岐リポジトリアンチ腐敗レイヤー
状態の複製：新しい ➔ 古い（「ライトを点灯させておく」）	レガシーミミック（サービス消費ミミック）
状態の複製：古い ➔ 新しい	レガシーミミック（サービス提供ミミック）イベントインターセプション

明確な宛先アーキテクチャを念頭に置いていても、そこに到達するための多くの経路があります。チームが取る可能性のあるさまざまなパスのそれぞれは、異なる移行アーキテクチャを配置することによって有効にされるか、または必要になります。この場合、各パスについて費用対効果分析を実行して、選択に影響を与えるかどうかを確認できる程度に詳細にする必要があります。

移行アーキテクチャを使用することの一部は、不要になったときにそれを削除することであることに注意してください。後で削除しやすくするアフォーダンスを追加するために、構築時にもう少し投資する価値があるかもしれません。同様に、適切に削除されていることを確認する必要があります。不要なコンポーネントは、たとえ未使用であっても、将来のチームがシステムを保守および進化させるための取り組みを複雑にする可能性があります。

使用場面

誰も苦労したくないと思っており、使い捨てるつもりで何かを構築することについて話すとき、その感情は自然に生じます。使い捨てのものは価値が低いと結論付けるのは簡単です。しかし、移行アーキテクチャはいくつかの方法で価値を提供し、この価値を構築コストと比較する必要があります。

最初の価値は、多くの場合、ビジネスに機能を提供する速度が向上することです。ここでは、壁を塗装するときにトリムの上にペインターズテープを使用するという便利な比喩があります。トリムにテープを貼らないと、トリムの近くで注意深くゆっくりとペイントする必要があります。事前にテープを貼り、後でテープを剥がすためのコストは、間違った場所にペイントするのを避けるために必要な速度（およびスキルの削減）によって相殺されます。

ソフトウェアにおけるこのトレードオフは、タイムトゥバリューの重要性によって拡大されます。ビジネスで、置換されているレガシーシステムからの既存のデータと新しいシステムからのデータを統合する新しいダッシュボードが必要な場合、新しいダッシュボードに、レガシーソースのデータをダッシュボードに必要な形式に読み取って変換するゲートウェイを構築することで、より迅速に実現できます。このゲートウェイは、レガシーシステムが削除されると破棄されますが、交換が行われるまでの期間に統合されたダッシュボードを持つことの価値は、それを作成するコストを十分に超える可能性があります。比較が近い場合は、レガシー交換が予想よりも長くなる可能性も考慮する必要があります。

移行アーキテクチャの2番目の価値は、レガシー置換のリスクをどのように軽減できるかです。顧客管理システムにイベントインターセプションを追加するには、構築するのに費用がかかりますが、構築すると、顧客の段階的な移行が可能になります（たとえば、製品ラインの抽出またはバリューストリームの抽出を使用）。顧客のサブセットを移行すると、移行中に深刻な問題が発生する可能性が減少し、問題が発生した場合の影響を軽減する傾向があります。さらに、本当に深刻な問題が発生した場合、イベントインターセプションを使用すると、以前の状態に簡単に戻すことができます。

原則として、チームはレガシー置換中に常に移行アーキテクチャを検討し、一時的なソフトウェアを構築することでこれらのメリットを実現できるさまざまな方法をブレインストーミングする必要があります。次に、チームは、タイムトゥバリューの向上とリスクの軽減によるメリットを、この短命なソフトウェアの構築コストと比較評価する必要があります。一時的なソフトウェアがそのコストをどれほど頻繁に回収するかを知って、多くの人が驚かれると思います。

例：アーキテクチャの進化

このセクションでは、概要記事で紹介したミドルウェア削除の例について詳しく説明し、移行アーキテクチャがシステムの安全な進化をどのように可能にしたかについて説明します。

レガシー構成

概要で説明したように、現状のアーキテクチャは、一部の統合ミドルウェアを介して、製品の価格設定とレガシーストアフロントへの公開を担当するメインのレガシーシステムで構成されていました。そのミドルウェアは、レガシーキューから公開された製品イベントを消費し、製品がストアフロントにどのように表示されるかの長期的なオーケストレーションを処理しました。製品が販売されると、レガシーストアフロントはミドルウェアを呼び出し、ミドルウェアは基盤となる共有レガシーデータベース内の製品ステータスを更新します。レガシーミドルウェアは、レガシーデータベース内の内部状態も格納しており、データウェアハウス経由で重要なレポートにフィードされていました。クリティカルアグリゲータを参照してください。

ターゲットアーキテクチャ

ターゲットアーキテクチャ内では、レガシーストアフロントは残りますが、その責任の一部は新しいストアフロントマネージャーコンポーネントに移動します。ストアフロントマネージャーは、製品が販売のためにそのチャネルにルーティングされるときに資産処分ルーターによって生成されたビジネスイベントを消費し、新しいAPIを使用して製品をストアフロントに公開します。ストアフロントマネージャーは、ストアフロント内での製品の表示方法を担当します。製品が販売されると、レガシーストアフロントは新しいAPIを使用してストアフロントマネージャーを呼び出し、ストアフロントマネージャーはダウンストリームの資産販売処理コンポーネントによって消費されるビジネスイベントを発行します。

最初の小さな実現ステップ

最初に追加される移行アーキテクチャは、イベントルーターコンポーネントでした。これは、イベントインターセプションパターンの例です。イベントルーターは、新しいコンポーネントを介して販売する製品をルーティングするために利用できる技術的なシームを作成しました。

Storefront Manager の導入

次のステップでは、新しいストアフロントマネージャーを追加しました。ここには、移行アーキテクチャも追加されました。これは、非常に異なる2つの目的を果たしました。具体的には、新しいコンポーネントをレガシーの懸念事項（データ構造やメッセージなど）から分離することと、レガシーの世界内で稼働を維持することです。分離（アンチ腐敗レイヤー）のため、イベントルーターによってルーティングされるレガシーメッセージを、ストアフロントマネージャーが消費し、ターゲットアーキテクチャ内で維持される新しいクリーンなビジネスイベント形式に変換するイベントトランスフォーマーを作成しました。ストアフロントマネージャーとレガシーストアフロントは、新しいAPIを介して連携するため、これも追加し、製品が販売されたときにレガシーストアフロントがその製品を公開したシステムに「コールバック」する内部イベントインターセプションも追加しました。稼働を維持するために、2つの移行アーキテクチャが必要でした。まず、製品が販売されたときに新しいビジネスイベントが公開されました。これらは、統合ミドルウェアを模倣し、レガシーデータベースを販売情報で更新する一時的なレガシーデータベースアダプターによって消費されました。次に、MIデータ模倣を作成しました。これは、イベントインターセプターとレガシー模倣の両方でした。新しいAPI内のイベントをインターセプトし、ビジネス上重要なレポートに必要な「状態」情報でレガシーデータベースを更新しました。

ビジネス成果 - レガシーミドルウェアの廃止

レガシーシステムは、どの資産を販売できるかを決定し、公開する製品を送信する責任を依然として負っていましたが、時間の経過とともに、新しいコンポーネントにルーティングされる製品の数が増加し（製品ラインの抽出を参照）、最終的にはレガシーミドルウェアに依存せずにトラフィックの100％が処理されるようになりました。この時点で、レガシーミドルウェアを廃止し、新しいストアフロントマネージャーと移行アーキテクチャコンポーネントを本番環境に残すことが可能になりました。

資産廃棄ルーターの導入

しばらくして、新しい資産廃棄ルーターコンポーネントが稼働しました。（この例はやや単純化されており、より大規模なレガシー置換プログラムの経験から描かれていることを覚えておいてください。）そのコンポーネントは、ストアフロントマネージャーが消費できる製品の新しいビジネスイベントを公開しました。他のコンポーネントがどの資産を廃棄するかを決定するようになったため、イベントルーターは不要になり、イベントトランスフォーマーも不要になりました。そのため、これらのコンポーネントは廃止することができました。レガシーミドルウェアが廃止されたため、ビジネス上重要なレポートは新しいコンポーネントのデータを使用するように変更されており（ソースへの復帰を参照）、MIデータ模倣コンポーネントも廃止することができました。

ターゲットアーキテクチャへの安全な到達

しばらくして、新しい資産販売処理コンポーネントがオンラインになり、レガシーシステムからの最後の責任を引き継ぎました（この例の範囲内）。その時点で、移行アーキテクチャの最後であるレガシーデータベースアダプターを削除することができました。ストアフロントマネージャーによって生成されたビジネスイベントは、資産販売処理コンポーネントによって消費されました。

重要な改訂

2022年3月28日：初版公開