大規模システム移行と分離戦略の事例

baeba · 2025-05-13T10:00:11+09:00

Key Takeaways 既存システムを全面的に置き換えることなく、段階的な分離によって移行を推進した。 CDCベースのリアルタイムデータシステムで、メインフレームへの直接アクセスを置き換えた。 RESTの代わりにGraphQLを採用し、多数のBFFレイヤーを削減して柔軟性と保守性を確保した。ドメイン中心のチーム構造（Team Topologies）により、チームの責任とオーナーシップを明確にした。段階的なデプロイと自動化を通じて、リスクなくシステムを移行し、安定して価値を提供した。導入事例: 障害発生中でも生き残った半分のシステムメインフレーム障害が発生したが、クラウドベースのストリーミングアーキテクチャのおかげで新しいUIは正常に動作した。既存システムがダウンしても、新システムは顧客体験を維持し、レジリエンスを証明した。中核戦略: 多層分離（Decoupling）ドメイン駆動設計（DDD）: メインフレーム中心のモデルをビジネスに適した形へ再構成 Team Topologies: 機能中心のチーム編成へ移行イベント駆動アーキテクチャ: 非同期方式でシステム間の結合度を緩和 Change Data Capture（CDC）: リアルタイムのデータ変化を検知し、レガシーと新システムを接続以前の構造: Unified Web Portal 1.0 さまざまなメインフレームデータをETLで統合してSQL DBとSaaSに提供していたが、リアルタイム性の不足、データ品質の低下、メインフレーム直接呼び出しなどの問題が発生した。問題点 ETLによるデータ遅延柔軟性に欠けるメインフレームとの同期接続無数のBFF APIの生成組織構造に起因するボトルネックとリリース遅延トラフィック急増時にメインフレーム過負荷でサービス全体に障害が発生新たな目標設定技術的目標: メインフレームとWebの分離、BFFの廃止、チーム自律性の確保ビジネス目標: コールセンター問い合わせの削減、ライセンスコストの削減、顧客満足度の向上新しいアーキテクチャ概要メインフレームは依然としてシステムオブレコード CDC → Kafka → ドメインDB（CosmosDB） GraphQL + REST API → BFF → UI イベント駆動構造とメッセージブローカーですべてのコンポーネントを接続 Step 1: Change Data Capture リアルタイムデータストリーミングでシステムオブリファレンスを構築メインフレーム → Kafka → 変換 → ドメインDB → APIとして提供メインフレームのスキーマに依存しない柔軟なデータ構造を確保 Step 2: Domain-Driven Design + GraphQL DDDでドメインモデルを定義（Entity, Command, Event）各ドメインをGraphQLノードとして構成し、schema stitchingによってsupergraphを生成必要なデータだけを取得する最適なクエリ構造をサポート組織構造の変化: Team Topologies 機能中心のストリームアラインドチームへ再編複雑な領域（例: メインフレーム統合）は専任チームが管理技術支援のためのEnablementチームを運営イベント駆動の拡張: 内部ドメインイベント + Sagaパターン Outboxパターンでドメイン変更時にイベントを発行 Parallel Sagaでメインフレーム処理とCDCを同期ステートマシンベースのワークフローを構成し、複雑なフローにも対応課題イベント駆動構造の導入に対する組織内の認識変化が必要非同期構造に伴いオブザーバビリティの確保が必須メインフレームのバッチ処理 → CDCパイプラインの過負荷を誘発 GraphQL schema管理の複雑さとfederated approach導入の検討認証・ロギングなどの共通関心事は別パッケージと自動化で管理リリース戦略: リリーストレイン + Feature Flag 各チームは独立してデプロイし、デプロイリポジトリで統合 Kustomizeで環境別デプロイパイプラインを構成機能フラグで機能/セキュリティリリースを分離し、trunk-based開発を維持ハイブリッドアーキテクチャの適用 UWP 1.0とUWP 2.0を共存させながら段階的な移行を実施エッジルーティングでユーザーリクエストを新システムへ順次切り替え結論: 進化可能なプラットフォームの構築フロントエンドとメインフレームを完全に分離チーム中心の構造でスピードと安定性を確保顧客満足度と運用コストを改善将来的なメインフレーム置き換えまで可能にする柔軟な基盤を確保

(infoq.com)

9 ポイント投稿者 baeba 2025-05-13 | 1件のコメント | WhatsAppで共有

Key Takeaways

既存システムを全面的に置き換えることなく、段階的な分離によって移行を推進した。
CDCベースのリアルタイムデータシステムで、メインフレームへの直接アクセスを置き換えた。
RESTの代わりにGraphQLを採用し、多数のBFFレイヤーを削減して柔軟性と保守性を確保した。
ドメイン中心のチーム構造（Team Topologies）により、チームの責任とオーナーシップを明確にした。
段階的なデプロイと自動化を通じて、リスクなくシステムを移行し、安定して価値を提供した。

導入事例: 障害発生中でも生き残った半分のシステム

メインフレーム障害が発生したが、クラウドベースのストリーミングアーキテクチャのおかげで新しいUIは正常に動作した。
既存システムがダウンしても、新システムは顧客体験を維持し、レジリエンスを証明した。

中核戦略: 多層分離（Decoupling）

ドメイン駆動設計（DDD）: メインフレーム中心のモデルをビジネスに適した形へ再構成
Team Topologies: 機能中心のチーム編成へ移行
イベント駆動アーキテクチャ: 非同期方式でシステム間の結合度を緩和
Change Data Capture（CDC）: リアルタイムのデータ変化を検知し、レガシーと新システムを接続

以前の構造: Unified Web Portal 1.0

さまざまなメインフレームデータをETLで統合してSQL DBとSaaSに提供していたが、
リアルタイム性の不足、データ品質の低下、メインフレーム直接呼び出しなどの問題が発生した。

問題点

ETLによるデータ遅延
柔軟性に欠けるメインフレームとの同期接続
無数のBFF APIの生成
組織構造に起因するボトルネックとリリース遅延
トラフィック急増時にメインフレーム過負荷でサービス全体に障害が発生

新たな目標設定

技術的目標: メインフレームとWebの分離、BFFの廃止、チーム自律性の確保
ビジネス目標: コールセンター問い合わせの削減、ライセンスコストの削減、顧客満足度の向上

新しいアーキテクチャ概要

メインフレームは依然としてシステムオブレコード
CDC → Kafka → ドメインDB（CosmosDB）
GraphQL + REST API → BFF → UI
イベント駆動構造とメッセージブローカーですべてのコンポーネントを接続

Step 1: Change Data Capture

リアルタイムデータストリーミングでシステムオブリファレンスを構築
メインフレーム → Kafka → 変換 → ドメインDB → APIとして提供
メインフレームのスキーマに依存しない柔軟なデータ構造を確保

Step 2: Domain-Driven Design + GraphQL

DDDでドメインモデルを定義（Entity, Command, Event）
各ドメインをGraphQLノードとして構成し、schema stitchingによってsupergraphを生成
必要なデータだけを取得する最適なクエリ構造をサポート

組織構造の変化: Team Topologies

機能中心のストリームアラインドチームへ再編
複雑な領域（例: メインフレーム統合）は専任チームが管理
技術支援のためのEnablementチームを運営

イベント駆動の拡張: 内部ドメインイベント + Sagaパターン

Outboxパターンでドメイン変更時にイベントを発行
Parallel Sagaでメインフレーム処理とCDCを同期
ステートマシンベースのワークフローを構成し、複雑なフローにも対応

課題

イベント駆動構造の導入に対する組織内の認識変化が必要
非同期構造に伴いオブザーバビリティの確保が必須
メインフレームのバッチ処理 → CDCパイプラインの過負荷を誘発
GraphQL schema管理の複雑さとfederated approach導入の検討
認証・ロギングなどの共通関心事は別パッケージと自動化で管理

リリース戦略: リリーストレイン + Feature Flag

各チームは独立してデプロイし、デプロイリポジトリで統合
Kustomizeで環境別デプロイパイプラインを構成
機能フラグで機能/セキュリティリリースを分離し、trunk-based開発を維持

ハイブリッドアーキテクチャの適用

UWP 1.0とUWP 2.0を共存させながら段階的な移行を実施
エッジルーティングでユーザーリクエストを新システムへ順次切り替え

結論: 進化可能なプラットフォームの構築

フロントエンドとメインフレームを完全に分離
チーム中心の構造でスピードと安定性を確保
顧客満足度と運用コストを改善
将来的なメインフレーム置き換えまで可能にする柔軟な基盤を確保

1件のコメント

mhj5730 2025-05-13

段階的な改善と段階的なマイクロサービスの切り出しがとても重要ですが……こういう文章を見ると、そのプロジェクトを率いるPMが本当に重要で、すごい存在なんだなと感じます。これだけ多くのことを管理するなんて、すごすぎます。