前置き
アーキテクチャは静的な完成形ではなく、ビジネスや技術という「環境」に応じて変化し続けるものです。
なので、一度分離されたインフラ基盤を、再び統合するという意思決定は十分にあり得ます。
なぜインフラの再統合が起きるのか
物理的なインフラ分離は、耐障害性や自律性において理想的ですが、もちろんデメリットもあります。
環境の変化によって、そのデメリットがメリットを上回った場合に、システムの再統合が検討されます。
この再統合も適応度関数として用意すべきではないでしょうか？
1. コスト最適化 💰
複数のインフラ基盤（例: 複数のKubernetesクラスター）を個別に維持・管理するのは、単一の大きな基盤を運用するよりも金銭的・人的コストが高くなります。
衰退期のように、ビジネスがコスト削減フェーズに入った場合、インフラの統合による効率化は有力な選択肢です。
2. 運用の簡素化と標準化
組織の成熟度が変化し、中央集権的なプラットフォームチームが強力な内製プラットフォーム（IDP）を構築した場合など、分離されたインフラで各チームが自由な運用をするよりも、
標準化された単一の基盤に乗った方が全体の生産性が高まると判断されることがあります。
上記の記事が関連しているので、参考までに。
3. 技術の進化 🚀
かつては物理的な分離でしか実現できなかったレベルの論理的な分離（テナンシー） が、
単一のインフラ基盤上で可能になる技術が登場した場合です。
例えば、Kubernetesの仮想クラスター（vCluster）のような技術を使えば、単一の物理クラスター上で、まるで別のクラスターのように分離された環境を各チームに提供できます。
重要なのは「可逆性」
ここでの本質は、やはりアーキテクチャに可逆性があるかどうかです。
非同期アーキテクチャの強み
サービス間が非同期で疎結合に設計されていれば、それらが物理的に同じクラスターで動くか、別のクラスターで動くかは、アプリケーションコードの変更なしに、インフラ構成のレベルで選択できるようになります。
サービスメッシュの役割
サービスメッシュは、サービスがどのインフラ上にあっても、一貫したポリシーを適用できます。これにより、インフラの物理的なトポロジーの変更が、アプリケーションやガバナンス層に与える影響を最小限に抑えることができます。
ここまでのまとめ
アーキテクチャの理想形は、常に一つではありません。
コスト、耐障害性、チームの自律性、開発速度といった、多数のトレードオフの中の
スイートスポットです。
ビジネスや技術の環境変化によって、このスイートスポットは移動します。
アーキテクトは、その変化を捉え、インフラを分離する方向にも、統合する方向にも、柔軟にシステムを進化させていくことが求められます。
システムの統合
サービスメッシュなどもない異なる部署ごとに運用された複数のシステムの構成するオペレーションを繋いでビジネスモデルを再編するとき、時にはそのシステムを部分的に融合する可能性もあります。
この時もすべてを一気に融合するのはアンチパターンですので、段階的に統合が必要です。
その際の心構えを以下で触れていきます。
システムを部分的に融合する可能性
ビジネスモデルの再編を行う際には、部分的なシステムの融合（統合）は、むしろ積極的に検討すべき選択肢です。
長年、異なる部署で個別に運用されてきたシステムには、以下のような問題が潜んでいることが多いためです。
データ・機能の重複
複数のシステムに、同じ顧客マスタや商品マスタなど、重複したデータや機能が存在する。
データのサイロ化
本来一元管理されるべきデータが分散し、全社的なデータ活用を妨げている。
非効率なプロセス
組織のサイロが、システム間の非効率な手作業や多重入力といったプロセスを生み出している。
ビジネスモデルを再編する絶好の機会に、これらの技術的負債を解消し、より効率的で堅牢なシステム基盤を構築するために、部分的な機能統合は不可欠と言えます。
段階的な統合の重要性
大規模なシステム統合における唯一の現実的かつ成功率の高いアプローチと言えます。
「すべてを一気に融合する」というビッグバンアプローチは、以下のような理由で典型的なアンチパターンです。
高すぎるリスク
長期間にわたる開発の後、一斉にリリースするため、問題が発覚した際の手戻りが甚大になります。
価値提供の遅延
プロジェクトが完了するまで、ビジネスは一切の価値を享受できません。
可逆性のなさ
一度進めてしまうと、後戻りが非常に困難です。
そこで、以下の段階的なアプローチが正攻法です。
①. 論理アーキテクチャの定義
まず、ビジネスの理想的な流れを反映した「あるべき姿」としての論理アーキテクチャを定義します。これは全体の北極星となります。
②. 乖離分析と優先度付け
次に、現行の物理アーキテクチャが、その「あるべき姿」とどれだけ乖離しているかを分析します。そして、ビジネスインパクトや技術的リスクの観点から、最も価値の高い部分から着手するように優先度を付けます。
③. 段階的な統合
優先度に従い、少しずつ現行システムの一部を新しいアーキテクチャに移行・統合していきます。この際、ストラングラー・フィグ・パターンのような手法が有効です。
統合の順序（インフラ vs アプリ）
原則として、インフラ基盤の融合を先行させるのが一般的かつ安全な進め方です。
理由
共通の土台作り
まず、統合されたアプリケーションが稼働するための、標準化された新しいインフラ基盤（例：共通のKubernetesクラスター、VPC、CI/CDパイプライン）を構築します。
この共通の土台があることで、その後のアプリケーション移行・統合がスムーズに進みます。
リスクの分離
「インフラの構築・移行」という課題と、「アプリケーションの改修・データ移行」という課題を分離できます。
これらを同時に進めようとすると、問題が発生した際に原因の切り分けが非常に困難になります。
一般的な進め方
①. 新しい共通インフラ基盤を構築する。
②. 既存のアプリケーションを、まずは最小限の変更（Lift & Shift） で新しい基盤に移行させ、安定稼働させる。
この際の変更の単位は単一責務を意識してください。
③. 共通基盤の上で、改めてアプリケーションの本格的なリファクタリングや機能統合を開始する。
この進め方により、巨大で複雑なプロジェクトを、管理可能でリスクの低いステップに分割して、着実に進めることができます。
古いインフラ基盤の破棄
古いインフラ基盤をすぐには破棄しないのは、安全なシステム移行における鉄則です。
最大の理由は可逆性を確保するためです
なぜ古いインフラを維持するのか
1. 可逆性（ロールバック計画）の確保
どれだけ入念にテストをしても、新しいインフラに移行した直後に、予期せぬ重大な問題（パフォーマンスの劣化、隠れたバグ、データの不整合など）が発生するリスクはゼロではありません。
そこで、古いインフラを稼働状態で維持しておくことで、問題が発生した際に、DNSの切り替えなどによって迅速にトラフィックを安定稼働していた元の環境に引き戻すことができます。これが最も確実な安全策となります。
2. 段階的なトラフィック移行の実現
古いインフラを維持することは、より安全な移行パターンであるカナリアリリースや
ブルーグリーンデプロイメントの実施を可能にします。
ブルーグリーンデプロイメント
新旧両方の環境を並行稼働させ、問題がないことを確認した上で、ルーターでトラフィックを一度に新しい環境に切り替えます。問題があれば、即座に元に戻せます。
カナリアリリース
まず、ごく一部のユーザー（例: 1%）のトラフィックだけを新しい環境に向け、影響を慎重に観察します。問題がなければ、徐々にトラフィックの割合を増やしていきます。
いつ破棄するのか？
古いインフラを破棄するのは、新しいインフラが本番トラフィックの負荷の下で、一定期間（数日〜数週間）安定稼働したことを確認し、「新しい環境は信頼できる」という確信が得られた後です。
アーキテクチャの意思決定において、特に大規模な移行を伴う場合、常に
「もしこの判断が間違っていたら、どうやって元に戻すか？」という可逆性
を確保しておくことが極めて重要です。
非同期から同期に戻す
ビジネスモデルの再編など、アーキテクチャの前提が根本から変わる際には、一度非同期にしたものを、あえて同期に戻すという意思決定もあり得ます。
なぜ非同期から同期に戻すのか？
非同期・疎結合は多くのメリットがありますが、ビジネス要件によっては同期・密結合の方が望ましいケースも存在します。
強い一貫性が求められるようになった
分離されていた当時は結果整合性で問題なかった業務が、ビジネスモデルの変更により、
アトミックなトランザクションとして即時完了する必要が出てきた場合。
（例：在庫引当と決済が、絶対に同時に成功または失敗しなければならなくなった）
パフォーマンス
ユーザー体験上、複数の非同期プロセスが完了するのを待つよりも、単一の同期リクエストで完結させた方が、全体的な応答時間が短くなる場合。
複雑性の削減
2つのサービスがあまりにも頻繁に（非同期で）通信し合う関係になってしまった場合、それらを1つのサービスに統合した方が、システム全体の理解しやすさや運用負荷が下がる場合。
安全な統合ステップ（データとロジックの順序）
アプリケーションを安全に統合するには、データを先に、ロジックを後に扱うのが原則です。
ステップ1：データ層の同期と「信頼できる唯一の情報源」の確立
目的
2つのサービスが、最終的に同じデータを参照するようにする。
方法
①. まず、統合後の新しいデータベーススキーマを設計します。
②. 次に、サービスAとサービスBのデータベース間で、データ同期の仕組み（バッチ処理やリアルタイムレプリケーション）を構築します。
③. 一定期間、両方のデータベースを同期させ、データの整合性を確保します。
この時点で、どちらか一方を 「信頼できる唯一の情報源」 として定めます。
ステップ2：統一された参照API（Facade）の構築
目的
書き込み処理に影響を与えずに、データの読み取り部分から統合を進める。
方法
①. 新しい統合サービスに、ステップ1で確立した「信頼できる情報源」からデータを読み取るだけの参照系APIを構築します。
②. 既存のサービスA, Bを呼び出していたクライアントのうち、データの参照のみを行っている部分を、この新しいAPIに切り替えていきます。
ステップ3：ビジネスロジック（トランザクション）の段階的な移行
目的
最もリスクの高い書き込み処理を、少しずつ新しいサービスに移行する。
方法
①. 新しい統合サービスに、同期的なトランザクション処理を行うビジネスロジックを実装します。
②. プロキシやAPIゲートウェイを使い、特定の種類の書き込みリクエスト（例：「新規注文の作成」のみ）を、古いサービスではなく新しい統合サービスにルーティングします。
③. 動作が安定していることを確認しながら、徐々にルーティングするリクエストの種類を増やしていきます。（例：「注文の更新」「注文のキャンセル」も新しいサービスへ）
ステップ4：旧システムの廃止
全てのリクエストが新しい統合サービスに向けられるようになったことを確認した後、
古いサービスとそのデータベース、そしてそれらを繋いでいた非同期メッセージングの仕組みを安全に廃止します。
統合時のメカニズムのまとめ
つまり、まとめると、
統合させていく場合には、分離していく工程をまるで巻き戻すような順
で段階的に行っていけばいいということです。
なぜ「巻き戻し」になるのか
大規模なアーキテクチャ変更におけるリスクを最小限に抑えるための安全策は、分離・統合のどちらの方向でも、本質的に同じだからです。
その中心にあるのが、やはり ストラングラー・フィグ・パターン の考え方です。
以下に、分離と統合の工程を並べて比較します。
まとめ
このように、データの流れの向きや対象が異なるだけで、
①. まずデータの一貫性を確保
②. リスクの低い参照系から移行
③. 最後にリスクの高い更新系を移行する
という、安全性を最優先したステップは全く同じです。