メインフレームの漸進的近代化のためのシームの発見

バッチ入力としてのシーム

最初に発見した外部境界線は、ファイル転送サービスでした。
プロバイダーは、半構造化形式のデータを含むファイルを2つのルートを介して転送できます。基盤となるファイル転送サービスと対話するファイルアップロード用のWebベースのGUI（グラフィカルユーザーインターフェース）、またはプログラムによるアクセスのためのサービスへのFTPベースのファイル転送です。

ファイル転送サービスは、プロバイダーとファイルごとに、メインフレーム上のどのデータセットを更新する必要があるかを決定します。これにより、バッチジョブスケジューラで構成されたデータセットトリガーを介して関連するパイプラインが実行されます。

各パイプラインをクラウド全体で再構築できると仮定すると（後で、より大きなパイプラインを扱いやすいチャンクに分割することに関してさらに詳しく説明します）、クラウド上に個々のパイプラインを構築し、メインフレームとデュアルランして、同じ出力が生成されていることを確認するというアプローチを採用しました。私たちのケースでは、ファイル転送サービスに追加の構成を適用することでこれを実現でき、メインフレームとクラウドの両方にアップロードをフォークしました。テスト環境で実行されているダミーデータを使用して、本番環境のようなファイル転送サービスを使用してこのアプローチをテストすることができました。

これにより、必要な期間、クラウドとメインフレームの両方で各パイプラインをデュアルランして、食い違いがないことを確認できます。最終的には、ファイル転送サービスに追加の構成を適用して、メインフレームデータセットへのさらなる更新を防止し、現状のパイプラインを非推奨にするというアプローチを採用することになります。パイプライン全体をエンドツーエンドで再構築しなかったため、この最後のステップを自分でテストすることはできませんでしたが、私たちの技術的なSMEは、メインフレームパイプラインを効果的に非推奨にするためにファイル転送サービスに必要な構成に精通していました。

APIアクセスとしてのシーム

さらに、外部に公開されているAPIゲートウェイの周りの境界線を特定し、顧客へのコンシューマサブシステムのエントリポイントを表すことで、外部向けAPIについても同様の戦略を採用しました。

デュアルランから得た知見に基づき、設計したアプローチは、HTTPS呼び出しのチェーンの上位、ユーザーにできるだけ近い場所にプロキシを配置することでした。私たちは、（現状のメインフレームとクラウド上に新しく構築されたAPIの両方）の呼び出しストリームを並列実行し、その結果を報告できるものを探していました。

事実上、アーティファクトの出力を広範囲かつ継続的に監視することで、早期に信頼性を高めるために、新しいプロダクトレイヤーにダークローンチを使用する計画でした。最初の年にはこのプロキシの構築を優先しませんでした。その価値を活用するには、製品レベルで大部分の機能を再構築する必要がありました。ただし、APIレイヤーで意味のある比較テストを実行できるようになるとすぐに構築する意図がありました。これは、ダークローンチの比較テストを調整するために重要な役割を果たすコンポーネントであるためです。さらに、分析により、プロダクトレイヤーによって生成される副作用に注意する必要があることが強調されました。私たちのケースでは、メインフレームは課金イベントなどの副作用を生成しました。その結果、重複を防ぎ、顧客が2回請求されないようにするために、メインフレームコードに侵入的な変更を加える必要がありました。

バッチ入力境界線と同様に、必要な限りこれらの要求を並列実行できます。しかし、最終的には、プロキシレイヤーでカナリアリリースを使用して、顧客ごとにクラウドに切り替えることで、メインフレームで実行されるワークロードを徐々に削減します。

粗粒度シーム：データインタラクションとしてのシーム

主な焦点は、プログラム全体にわたる広範なデータベースアクセスでした。ここでは、データベースに書き込んでいる、読み込んでいる、またはその両方を行っているプログラムを特定することから分析を開始しました。データベース自体を境界線として扱うことで、データベースをプログラム間の接続として依存しているフローを分離できました。

データベースリーダー

データベースリーダーに関しては、クラウド環境で新しいデータAPI開発を可能にするために、メインフレームとクラウドシステムの両方が同じデータにアクセスする必要がありました。最初の顧客セグメントの移行のために最初の候補として選択した製品によってアクセスされるデータベーステーブルを分析し、クライアントチームと協力してデータレプリケーションソリューションを提供しました。これにより、変更データキャプチャ（CDC）技術を使用してソースとターゲットを同期することで、テストデータベースからクラウドに必要なテーブルをレプリケートしました。CDCツールを利用することで、クラウド上のターゲットストア間で必要なデータサブセットをほぼリアルタイムでレプリケートすることができました。また、データのレプリケーションにより、クライアントはリレーショナルなものだけでなく、他のストアにもアクセスできるようになるため、データモデルを再設計する機会が得られました（たとえば、ドキュメントストア、イベント、キーバリュー、グラフが考慮されました）。アクセスパターン、クエリ複雑さ、スキーマの柔軟性などの基準に基づいて、データの各サブセットについて、どのテクノロジースタックにレプリケートするかを決定しました。最初の年には、DB2からKafkaとPostgresの両方にレプリケーションストリームを構築しました。

この時点で、データベースから読み取るプログラムを通じて実装された機能は、段階的に再構築され、後でクラウドに移行できる可能性があります。

データベースライター

データベースへの書き込みに関しては、主にメインフレーム上で実行されるバッチワークロードで構成されていました。それらを通過するデータとそこから出力されるデータを慎重に分析した結果、「製品ラインの抽出」を適用して、互いに独立して実行できる個別のドメインを特定することができました（同じフローの一部として実行されることは、変更できる実装の詳細でした）。

このような原子単位とそのそれぞれの境界を操作することで、他のワークストリームがこれらのパイプラインの一部をクラウド上で再構築し始め、メインフレームの結果と比較することができました。

移行アーキテクチャの構築に加えて、私たちのチームは、他のワークストリームがデータパイプラインと製品を設計するために使用するさまざまなサービスを提供する責任がありました。この具体的なケースでは、ファイル転送サービスにファイルをドロップすることでプログラムによって実行されるメインフレーム上のバッチジョブを構築し、それらのパイプラインがメインフレームで生成するジャーナルを抽出してフォーマットしました。これにより、同僚は自動比較テストを通じて作業に対する緊密なフィードバックループを持つことができました。結果が同じであることを確認した後、将来のアプローチとしては、他のチームが各サブパイプラインを1つずつ段階的に移行できるようにすることでした。

サブパイプラインによって生成されたアーティファクトは、さらなる処理（例：オンライントランザクション）のためにメインフレームで必要になる場合があります。したがって、これらのパイプラインが後で完了し、クラウド上に存在する場合、私たちが選択したアプローチは、「レガシーミミック」を使用してデータをメインフレームに複製することでした。これは、このデータに依存する機能がクラウドに移行されるまで行われます。これを実現するために、クラウドへのレプリケーションには同じCDCツールを使用することを検討していました。このシナリオでは、クラウドで処理されたレコードはストリーム上のイベントとして保存されます。メインフレームがこのストリームを直接消費することは、システムの回帰テストを構築およびテストする両方において複雑であり、レガシーコードに対するより侵襲的なアプローチを要求しました。このリスクを軽減するために、まるでそのデータがメインフレーム自体によって生成されたかのように、データをメインフレームが処理できる形式に変換する適応レイヤーを設計しました。これらの変換関数は、単純な場合は、選択したレプリケーションツールでサポートされる場合がありますが、私たちのケースでは、クラウドからの追加の要件に対応するために、レプリケーションツールとともにカスタムソフトウェアを構築する必要があると想定しました。これは、既存の処理をゼロから再構築することから生まれる機会を企業が活用して、それらを改善する（例：効率化）際に一般的に見られるシナリオです。

要約すると、クライアント側のSMEと緊密に協力することで、メインフレーム上のバッチワークロードの既存の実装に異議を唱え、データ境界が明確な代替の個別パイプラインを考案することができました。私たちが扱っていたパイプラインは、定義した境界のために同じレコードで重複していなかったことに注意してください。後のセクションでは、私たちが対処しなければならなかったより複雑なケースについて調べます。

粗粒度シーム：バッチパイプラインステップハンドオフ

おそらく、データベースだけが操作できる境界ではないでしょう。私たちのケースでは、出力データベースに永続化するだけでなく、ダウンストリームパイプラインにキュレーションされたデータをさらに処理するために提供するデータパイプラインがありました。

これらのシナリオでは、まずパイプライン間のハンドシェイクを特定しました。これらは通常、フラットファイル/VSAM（仮想記憶アクセス方式）ファイル、またはTSQ（一時記憶キュー）に永続化された状態から構成されます。以下は、パイプラインステップ間のこれらのハンドオフを示しています。

例として、アップストリームに格納されているキュレーションされたフラットファイルを読み取るダウンストリームパイプラインの移行設計を検討していました。メインフレーム上のこのダウンストリームパイプラインは、オンライントランザクションによってクエリされるVSAMファイルを生成しました。このイベント駆動型のパイプラインをクラウド上に構築することを計画していたため、CDCツールを利用してメインフレームからこのデータを取得し、クラウドデータパイプラインが消費するイベントストリームに変換することにしました。これまで報告してきたものと同様に、移行アーキテクチャでは、適応レイヤー（例：スキーマ変換）とCDCツールを使用して、クラウドで生成されたアーティファクトをメインフレームにコピーする必要がありました。

これまでに特定したこれらのハンドシェイクを活用することで、1つの例示的なパイプラインに対してこのインターセプションを構築およびテストし、ダウンストリーム処理を続行するために必要なデータでメインフレームにフィードバックするレガシーミミックを使用して、同じアプローチでクラウド上のアップストリーム/ダウンストリームパイプラインのさらなる移行を設計することができました。これらのハンドシェイクに隣接して、データを抽出およびフィードバックできるように、メインフレームに重要な変更を加えました。ただし、エッジで異なるジョブトリガーを使用することで、コアで同じバッチワークロードを再利用することにより、リスクを最小限に抑えていました。

細粒度シーム：データ特性

場合によっては、上記の内部境界の発見と移行戦略のアプローチでは不十分な場合があり、私たちのプロジェクトでも、移行しようとしていたワークロードの規模のために発生し、ビジネスにとってより高いリスクにつながりました。私たちのシナリオの1つでは、データロードパイプラインからデータを取得する個別モジュールである「IDキュレーション」に取り組んでいました。

顧客IDキュレーションは複雑な領域であり、私たちのケースではクライアントの差別化要因でした。したがって、彼らは、新しいシステムの結果が英国およびアイルランドの人口についてメインフレームよりも精度が低いことを許容できませんでした。モジュール全体をクラウドに正常に移行するには、数十のID検索ルールとその必要なデータベース操作を構築する必要があります。したがって、変更を小さく保ち、頻繁に配信できるようにしてリスクを低く抑えるために、これをさらに分割する必要がありました。

私たちは、SMEとエンジニアリングチームと緊密に協力して、データとルールの特性を特定し、それらを境界として使用して、このモジュールをクラウドに段階的に移行できるようにしました。分析の結果、これらのルールを「単純」と「複雑」の2つの異なるグループに分類しました。
単純なルールは、異なるデータセグメント（つまり、アップストリームの個別のパイプライン）に依存している場合、両方のシステムで実行できます。したがって、これらはIDモジュール空間をさらに分割する機会を表していました。これらは、ファイルの取り込み中にトリガーされた大部分（約70％）を占めていました。これらのルールは、既に存在するIDと新しいデータレコードとの間の関連付けを確立する役割を果たしていました。
一方、複雑なルールは、データレコードがIDの変更（作成、削除、または更新など）の必要性を示す場合にトリガーされました。これらのルールには慎重な処理が必要であり、段階的に移行することはできませんでした。これは、IDへの更新が複数のデータセグメントによってトリガーされる可能性があり、両方のシステムでこれらのルールを並行して操作すると、IDのずれとデータ品質の低下につながる可能性があるためです。これらには、ある時点で1つのシステムがIDを生成することが必要でした。そのため、ビッグバン移行アプローチを設計しました。

メインフレーム上のIDモジュールの元の理解では、データを取り込むパイプラインがDB2で変更をトリガーし、ID、データレコード、およびそれらの関連付けの最新ビューが生成されました。

さらに、個別のIDモジュールを特定し、SMEで発見したシステムのより深い理解を反映するようにこのモデルを改良しました。このモジュールは複数のデータパイプラインからデータを取得し、DB2に単純なルールと複雑なルールを適用しました。

ここで、データパイプラインについて前に書いたのと同じテクニックを適用できますが、IDについてはより粒度が高く段階的なアプローチが必要でした。
異なるデータセグメントで動作するという条件付きで、両方のシステムで実行できる単純なルールに取り組む計画を立てました。これは、IDデータを維持するシステムが1つしかないという制約があったためです。私たちは、バッチパイプラインステップハンドオフを使用し、イベントインターセプトを適用して、データを取り込み、フォークする（システムハンドオフ間でデータが失われないことを確認できるようになるまで一時的に）設計に取り組みました。これにより、取り込まれたファイルに対して分割統治のアプローチを採用し、クラウド上で並列ワークロードを実行して単純なルールを実行し、メインフレーム上のIDに変更を適用し、それを段階的に構築することができます。単純なバケットに分類されるルールが多くありました。したがって、まだ実装されていないルールをトリガーする必要がある場合に、メインフレームにフォールバックする機能がターゲットIDモジュールに必要でした。これは次のようになります。

クラウドIDモジュールの新しいビルドがリリースされると、フォールバックメカニズムを通じて適用される単純なバケットに属するルールが少なくなります。最終的には、その段階を通して観測されるのは複雑なものだけになります。前に述べたように、これらはIDのずれの影響を最小限に抑えるために、すべて一度にマイグレーションする必要がありました。私たちの計画は、クラウドデータベースレプリカに対して複雑なルールを段階的に構築し、広範な比較テストを通じて結果を検証することでした。

すべてのルールが構築されたら、このコードをリリースし、メインフレームへのフォールバック戦略を無効にします。これのリリース後、メインフレームのIDと関連付けデータは、クラウドIDモジュールによって管理される新しいプライマリストアのレプリカになります。したがって、メインフレームを機能させたままにするにはレプリケーションが必要です。

他のセクションで前述したように、私たちの設計ではレガシーミミックとアンチ腐敗レイヤーを採用し、メインフレームからクラウドモデルへのデータ、およびその逆の変換を行いました。このレイヤーは、システム全体にアダプターのシリーズで構成されており、データはイベント駆動型データパイプラインを使用してクラウドが消費するためにメインフレームからストリームとして流れ出し、既存のバッチジョブが処理できるようにメインフレームにフラットファイルとして戻されます。簡潔にするために、上記の図にはこれらのアダプターは示されていませんが、境界がどれだけ細かいかに関係なく、データがシステム間を流れるたびに実装されます。残念ながら、ここでの私たちの仕事は主に分析と設計であり、CDCツールとファイル転送サービスを使用して、必要な形式でメインフレームに出入りするデータを送信できることを確認するスパイクを実行する以外に、エンドツーエンドで仮定を検証する次のステップに進むことができませんでした。メインフレームの周りの必要な足場を構築し、要件を収集するために現状のパイプラインをリバースエンジニアリングするのに必要な時間は相当なものであり、プログラムの最初のフェーズのタイムフレームを超えていました。

細粒度シーム：ダウンストリーム処理ハンドオフ

ダウンストリームのバッチワークロードを供給するためのアップストリームパイプラインで採用されたアプローチと同様に、オンラインフローの移行にはレガシーミミックアダプターが使用されました。既存システムでは、顧客API呼び出しによって一連のプログラムがトリガーされ、課金や監査証跡などの副作用が発生し、メインフレーム上の適切なデータストア（主にジャーナル）に永続化されます。

オンラインフローをクラウドに段階的に移行するには、これらの副作用を新しいシステムで直接処理するか（これによりクラウドの範囲が拡大します）、またはメインフレームにアダプターを戻して、それらに関連する基盤となるプログラムフローを実行およびオーケストレーションするかを確保する必要がありました。当社では、CICS Webサービスを使用して後者を選択しました。構築したソリューションは機能要件についてテストされましたが、最初の段階では本番環境のようなメインフレームのテスト環境を用意することが困難だったため、クロスファンクショナルな要件（レイテンシやパフォーマンスなど）は検証できませんでした。次の図は、アダプターの実装に従って、移行された顧客のフローを示しています。

アダプターは一時的な足場として計画されていたことに注意することが重要です。クラウドがこれらの副作用を自分で処理できるようになった後は、継続性のために必要な限りデータをメインフレームに複製する計画だったため、アダプターには有効な目的はありませんでした。