この記事はフアード・ハムディ（Fouad Hamdi）が執筆したブログの翻訳版です。
300 万人以上のユーザーが利用し、メインフレーム上で動作する 12,000 以上のプログラムを抱える 30 年来のシステムをモダナイゼーションするには、どのような方法が考えられるでしょうか？
今回は、VMware Tanzu Labs がビジネス クリティカルなシステムをメインフレーム インフラからマイクロサービス アーキテクチャに移行するアプローチについて、実例をもとに掘り下げます。安全かつ迅速に、大きすぎるプログラム（モノリス）からドメインを絞りこむために取ったアプローチと考察について解説します。
メインフレームのモダナイゼーションに向けた目標設定
あるお客様企業にとって、メインフレームのモダナイゼーションは難易度の高い取り組みであり、全体的な目標は次のようなものでした。
- 年間数百万ユーロに相当するインフラコストを削減する
- 社内で COBOL に詳しい人員が減ってきているため、新世代の開発者たちにビジネスの知識を習得させる
- 新しい機能を本番稼動させるまでに数か月かかるため、開発ライフサイクルを改善する
- コードとアーキテクチャを簡素化する
ビジネス ドメインの把握
このようなモダナイゼーションで最初に直面する課題の 1 つは、このようなモノリス、特にモダナイゼーションする既存のシステムが非常に巨大な場合、どのように細かく分解していけばよいのか、ということです。
この疑問に答えるため、私たちはイベント ストーミング ワークショップ（VMware のSWIFT による開発手法のツールの1つ）を実施し、このお客様のシステムについて詳しく調べました。イベント ストーミングは、サイロ化した社内環境の垣根を取り払い、人々が話し合って互いを理解することを促すのに最適なツールであるという大きなメリットを持ちます。大規模システムについて理解を深める際には、イベント ストーミングの活用を強くお勧めします。
ビジネス エキスパート、開発者、運用担当者、アーキテクトが一堂に会し、全員が協力してプロセスを明らかにすることで、メインフレームのビジネス プロセス内で発生する重要なイベントをすべて把握することができました。この取り組みにより、システムを視覚的に表し、ドメイン駆動設計（DDD）で「境界づけられたコンテキスト」と呼ばれるものを特定することができます。一般的に、境界づけられたコンテキストは、それ自体がアプリケーションまたはサービス化する候補となります。
イベント ストーミング ワークショップの参加者は、まずシステムの問題点と改善箇所を特定し、次に境界づけられたコンテキストに優先順位をつけて、最初にモダナイゼーションを進める領域をドット投票（丸型シールやペンなどを使って投票をする方法）で選びました。
初期のアーキテクチャ
メインフレームで処理しているビジネス プロセスを少し詳しく把握した上で、アーキテクチャのあるべき姿について展望を持ち、既存システム内でどうすればスムーズに統合できるかも検討する必要がありました。
実際、以下のような理由により、段階的に書き換える方が、ビッグバン型の切り替えを行うよりも安全だと考えることはよくあります。
- 書き換え終了を待たずに、既存システムの新機能を開発することができる。
- 既存の機能を １ つひとつ書き換え、より早く本番環境で提供することができる。
- 問題を早期に発見し、失敗した場合の開発コストを削減することができる。
しかし、このアプローチをとる場合、既存システムと新システムをいかに共存させるかが課題となります。
こちらは、私たちが調整に取り組んだ既存のシステム アーキテクチャの全体像です。
これは典型的な多階層アーキテクチャであり、各階層は技術指向で、専門のチームによって管理されています。エンド ユーザーは、クロスドメイン型の機能を大量に提供する 1 つの大きなフロントエンド アプリケーションとやり取りします。このアプリケーションは、Java 2 Platform, Enterprise Edition（J2EE）のバックエンドと通信し、エンタープライズ サービス バス（Oracle ESB）を通じてメインフレームに処理を委ねます。したがって、バックエンドはファサードとして機能し、ビジネス ロジックは一切含まれません。
エンド ユーザーの認証には Lightweight Directory Access Protocol （LDAP）が使用されますが、バックエンドからバスへの経路も設定されます。具体的には、バックエンド アプリケーションは ESB と通信するために EJB/T3 プロトコルで Weblogic RMI を使用しています（EJB は実行するコマンドに関する情報を含む XML データを転送するパイプとしてのみ使用されます）。このコマンドは、次にバスによって COBOL トランザクションに変換されます。
ここで、使用されたフォーマットを示す XML の一部を紹介します（実際のフォーマットはもう少し複雑でした）。
<Payload> <Transaction> <!-- ... --> <Domain>D01</Domain> <Name>T01<Name> <!-- ... --> </Transaction> <Transaction-Data> <!-- the data of the transaction were placed here --> </Transaction-Data> </Payload>
バスはメインフレームを呼び出し、COBOL の結果をバックエンドが使用するための XML に変換します。メインフレームは、IBM Db2 と DL/I という 2 つの異なるデータベースに依存しています。DL/I は階層型データベースですが、今回の取り組みでは IBM Db2 のみを対象としていました。
制約事項
以下のような制約事項が、今回の取り組みにおける意思決定に影響を与えました。
- ビジネス部門が、この移行プロジェクトに直接関与することはできなかった（一般的には直接の関与が望ましいものの、今回は不可能だった）。
- 既存のビジネス ルールでは、ドメインのエキスパートが時代遅れと考えるようなものであっても、そのまま移行しなければならない。
- 新システムを統合するために COBOL のコードを修正することはできない。
このような制約があったため、メインフレームと新システムの共存をサポートする実装パターンの選択は限られていました。
過去の経緯
この企業では過去 10 年間、メインフレームをモダナイゼーションする試みが幾度か行われ、ある程度はうまくいっていました（アプリケーションの全面書き換えや COBOL からの自動変換など）。ただし、コストがかかりすぎたり、コードの品質が落ちたりしたため、満足のいく結果とはいえないものでした。
そこで同社が VMware に期待したのは、効率的なアプローチでモダナイゼーションを行い、エクストリーム プログラミング（XP）によって、同社のモノリスを段階的に縮小していくことでした。
プロジェクト契約
イベント ストーミングから数か月後、VMware はこのお客様とのメインフレームのモダナイゼーションに関する契約を開始しました。作業開始に先立ち、お客様側と VMware の双方の人員でチームを構成しました。
チーム編成
コンウェイの法則にあるように、アーキテクチャは組織と密接に関係しています。アーキテクチャや技術面に注目するだけでなく、このことを考慮に入れておくことはとても重要です。
VMware では、ソフトウェアを迅速かつ安全に提供する上で、業務ごとにサイロ化された従来の組織はコミュニケーション構造に問題があると考えています。そのため、クライアントと仕事をする際、常にバランスのとれたチームの構築を提唱しています。つまり、各ビジネス領域の業務フローを担当する、典型的なストリーム アラインド チームです。
お客様のプロジェクト チームに参加する VMware のコラボレータは、イネーブリング チームの役割を果たします。短いプロジェクト期間中に、VMware の手法を共有してストリーム調整型チームにガイダンスを提供します。目指すのは、プロジェクト期間終了後にお客様のチームが自立を実現し、私たちがいなくても業務が継続できるようにすることです。
お客様側からは、製品マネージャ、ビジネス アナリスト、COBOL エキスパート、オペレーション エンジニア、ソフトウェア エンジニアの 6 名に加わっていただきました。彼らにはプロジェクトを通じて、VMware の手法や業務の進め方を学んでいただきました。
プラットフォーム
アプリケーションをデプロイするためのプラットフォームを利用するのも有効なアプローチです。たとえば PaaS は、開発者を本番さながらの開発環境から解放し、インフラの課題や障害対応のチケット システムに追われることなく、コーディングに集中できるようにする上で非常に効果的です。
幸い、この企業は VMware Tanzu Application Service を利用されていたため、マイクロサービスのデプロイと本番環境への移行を自動化し、時間を大幅に短縮できました。
プロジェクト開始
プロジェクトの最初のワークショップは、「インセプション」と呼ばれるものです。チーム メンバーとステークホルダーに会い、今後数週間の目標や潜在的なリスクを定義します。ワークショップの最後には、モダナイゼーションを開始するための検討事項として、いくつかのユーザー ストーリーを集めました。
ここでは、インセプションで確認された主な目標を紹介します。
- COBOL トランザクションの廃止
- サブドメインに特化したマイクロサービスとデータベースの導入
- 現行システムと新システムが共存可能なパターンを把握
- リーン、エクストリーム プログラミング（XP）の手法をチームに指導
- 本番稼働までの工程の改善
アーキテクチャに対するアプローチ
これまでにない新しいものを作るとき、VMware では通常、Tracer Bullets の原則（書籍『The Pragmatic Programmer』内での定義）に従います。つまり、できるだけ早い段階でアプリケーションを構築／デプロイすることで、自分たちの想定を検証したり、無効にしたりするのです。これにより、必要に応じて別の方向への方針転換もできます。このようなアプローチにより、アーキテクチャの変更を簡単かつ低コストに行えるだけでなく、構築しているアーキテクチャが、事前に特定した課題を本当に解決しているのだという確信が得られます。
試行錯誤 その 1：新旧システムのデカップリング
モノリスを縮小していくため、API ゲートウェイ コンポーネントを導入して分離を開始しました。このゲートウェイの役割は、レガシー環境と新しいシステムを接続し、異なるサブドメインと相互作用する、今後の Web アプリケーションのエントリ ポイントとして機能させることでした。
エンタープライズ アーキテクトとの検証の結果、私たちのアイデアは次のようなものとなりました。
ここで考えていたのは、ドメインのトランザクションをゲートウェイにリダイレクトし、ゲートウェイが再びバスを呼び出してメインフレームをコールバックするように ESB を構成し、この最初のフェーズでは単にパススルーとして動作させることです。この Strangler Fig パターンの具体的な応用例により、何も移行することなく安全に本番稼動させ、しかも既存のシステムを壊すことなく、新しいシステムを段階的に構築できました。
なぜこのとき、サブドメイン マイクロサービスを構築する代わりにゲートウェイを導入し、バスが（次の図のように）トランザクションをそこにリダイレクトするようにしたのか、疑問に思われるかもしれません。
これは、ある状況では完全に有効なアイデアですが、今回は（少なくとも）次の 2 つの理由から、ゲートウェイを利用する選択肢が選ばれました。
- 新システムに対応したアプリケーションを用意し、ゲートウェイを新しい環境へのインターフェイスとする計画があった。
- メインフレームのモダナイゼーションは ESB から脱却する機会でもあるため、今回はゲートウェイを導入するという手法をとった。
プロジェクト チームは、ゲートウェイにどの技術を採用するか確信が持てなかったため、Spring Cloud Gateway と自作の Golang ゲートウェイのスパイクの評価を行いました（スパイクとは、問題を解決するために可能な解決方法を特定するために実験を行う開発手法のことです）。
ゲートウェイによってバスでサポートされていたトラフィックを適切に処理できるようにしたかったため、ここでは主にパフォーマンスに焦点を当てました。さらに、新しいコンポーネントによって生じる遅延が、ユーザー エクスペリエンスに影響を与えるかどうかも評価したいと考えました。
実験と計測の結果、2 つのソリューションのパフォーマンスは極めて似通っていることがわかりました。しかしプロジェクト チームは、（新しい技術を習得する必要がある）自作の Golang よりも、エンタープライズ サポートのある Java ソリューションの方が安心できると考え、Spring Cloud Gateway の採用を決定しました。
バス チームがトラフィックをゲートウェイにリダイレクトすることについて質問したところ、ESB 内で適切な改修を行えるようになるまで、少なくとも 6 か月はかかるという回答でした。もちろん、それほど待つことはできないため、戦略を変更して別の方法を考える必要がありました。
試行錯誤 その 2：バスのバイパス処理
ESB の改修は待てないため、バスに期待する役割である「EJB コールを REST コールに変換する」コンポーネントを新たに導入することにしました。
LDAP は、すべてのバックエンド アプリケーションのトラフィックをこの新しいコンポーネントに再ルーティングするように再設定されました。
一方で、作業中のサブドメイン用のマイクロサービスも作成しました。
このフェーズでは、マイクロサービスは 1 つの読み取り専用トランザクションを取り込みました（そして、まだそれに対して何もしないようにしました）。ここでの目的はただ 1 つ、これらの新しいコンポーネントをブートストラップ処理し、一緒に統合することでした。
このようなアーキテクチャに関する試行錯誤のすべてが、ここで効果を発揮しはじめました。バックエンドのアプリケーションのトラフィックを捉え、必要に応じて旧システムにリダイレクトし、必要な機能を書き換えることができる新システムを構築したのです。
そして、エンドユーザーから見れば何も変わっていない状態で、すべて本番に移行できました。
試行錯誤 その 3：メインフレームのデータの読み込み
次に、選択したトランザクションのビジネス ルールを読み取り専用に書き換えることで、まだ新しいデータベースを導入する必要がないようにしました。ビジネス ルール上必要な時に、Db2 からデータを取り出すだけでした。このフェーズの目的は、異なる環境の新システムから、Db2 環境にアクセスできるかどうかを確認することでした。
試行錯誤 その 4：新しいデータの書き込み
このステップでは、データの書き込みを担当する別のトランザクションを取り込みました。この時点で初めて、今回のマイクロサービスにデータベースを導入しました。
メインフレームに実装されたビジネス ルールを理解するのは非常に困難だったため、並列運用パターンを適用することを選択し、Sam Newman 氏の著書『Monolith to Microservices』で定義されている Comparator モジュールを記述しました。このパターンでは、旧システムと新システムのどちらかを呼び出すのではなく、両方を呼び出して結果を比較し、両者が同等であることを検証しました。この時点では、旧システムだけが信頼できる情報源であると考えられていました。
この方法によって、データの所有権を新システムに移す前に、ルールが正しく実装されているかどうかを検証できました。
この時点で、アーキテクチャは以下のようになっていました。
Comparator モジュールは、まずサブドメインのマイクロサービスに組み込まれ、必要であれば後で別のアプリケーションに移行できるという選択肢を残しておきました。
結果
各コンポーネントはテストに基づく開発、ペアリング、継続的インテグレーションなどのエクストリーム プログラミング（XP）の手法に従って完全に実装され、VMware はお客様のすべての環境にデプロイするためのパイプライン構成も記述しました。
9 週間を経た時点で、プロジェクト チームは自分たちで移行を継続することに自信を持ち、VMware の手法を自社の状況に適用できると実感していました。非常に困難な環境に対しても、段階的なアプローチを用いることで、自信を深めることができたのです。
このプロジェクトから私たちが学んだことは、他の誰かが異なる状況で行ったことをコピー＆ペーストするのではなく、状況を考慮することの重要性です。
つまり、メインフレーム アプリケーションのモダナイゼーションは複雑なため、たゆみない努力が必要です。以下に、今回のアプローチをあらためて示します。
- モダナイゼーション作業にビジネス部門を巻き込むことで、使われていない機能の書き換えを回避
- わずか数週間でコード書き換えを開始
- 本番稼働までのリードタイムを 1〜3 か月からわずか 30 分に短縮
- お客様側から 6 名に参加していただき、社内で以下を実施できるようにした
- 効率的なエクストリーム プログラミング（XP）による継続的なモダナイゼーション
- 新システムを旧システムと共存させ、サービスを中断させることなく展開
- エンド ユーザーに影響を与えることなく、段階的にアーキテクチャを提供し、進化させる
執筆者について
エクストリーム プログラミング（XP）手法に基づくアプリケーションの設計／構築を得意とするソフトウェアエンジニア。
