こんにちは。プラットフォーム開発部 のthorです。以前の記事では、Strangler Fig Pattern（ストラングラーフィグパターン）を用いて、レガシーな翻訳基盤システムの一部分だけをリアーキテクチャする方法について説明しました。今回は、レガシーデータを持つサービスのリアーキテクチャに焦点を当て、その具体的なアプローチを紹介します。
ストラングラーフィグパターンとは？
ストラングラーフィグパターンは、既存のシステムを徐々に新しいシステムに置き換えていく手法です。既存の機能を新システムで実装しその機能を段階的に移行していくことで、リスクを最小限に抑えつつシステム全体をモダナイズできます。
前回の記事でのテキスト翻訳のリアーキテクチャ
前回の記事では、以下のような構成のレガシー翻訳システムの一部を新しいマイクロサービスに置き換える例を紹介しました。
上記のレガシーシステムの中で、テキスト翻訳のリクエストの一部を新しいマイクロサービスで処理するように変更しました。
用語集というレガシーデータの課題
次に用語集管理システムのリアーキテクチャを考えるにあたり、ストレージに保存された用語集データ(レガシーデータ)に関する課題を整理します。レガシーデータを持つサービスのリアーキテクチャにおいては、以下のような課題が存在します。
- データの整合性: 新旧システム間でデータの一貫性を保つ必要があります。
- データ移行の複雑さ: 大量のデータを安全に移行するための計画が必要です。
- 既存のデータフォーマット: レガシーシステムのデータフォーマットが新システムと異なる場合、変換が必要です。
用語集データは以下のような構成のシステムで管理されています。
ユーザから入力された用語集データは、用語集データベースと用語集ファイルストレージの両方に保存されます。用語集データベースには、用語のID、原文、訳文、作成日時、更新日時などのメタデータが保存され、用語集ファイルストレージには、テキスト翻訳システムで利用しやすいように前処理されたバイナリ形式の用語集ファイルが保存されます。
レガシー用語集管理システムでのデータベースのスキーマやファイルストレージのパス構成は、モダン用語集管理システムでは改善したいものになっています。そのため、用語集データベースと用語集ファイルストレージの両方を新しい構成に移行する必要があります。
用語集管理システムのリアーキテクチャのアプローチ
レガシーデータを含むシステムの移行のアプローチとして、以下の3つの方法が考えられます。
- データベースののみ移行してからアプリケーションを移行する
- アプリケーションを移行してからデータベースを移行する
- アプリケーションとデータベースを同時に移行する
1. データベースのみ移行してからアプリケーションを移行する
このアプローチでは、レガシー用語集管理サーバがまず用語集データベースと用語集ファイルストレージを新しいシステムに同期します。
用語集のデータの同期が完了したら、新しい用語集管理システムで用語集を利用できるようになり、テキスト翻訳システムでも新しい用語集管理システムを利用できるようになります。(注: ファイル翻訳システムの記述は省略しています)
このアプローチの場合、レガシー用語集管理システムが新しい用語集管理システムのフォーマットに合わせてデータを変換しながら同期する必要があります。弊社のシステムでは技術者の少ないScala言語で実装されたシステムを改修する必要があり、開発スピードが遅くなる課題があります。
2. アプリケーションを移行してからデータベースを移行する
このアプローチでは、まず新しい用語集管理システムを構築し、レガシー用語集管理システムと並行して稼働させます。新しい用語集管理システムは、レガシー用語集管理システムのデータベースとファイルストレージを読み取り専用で参照します。(注: ファイル翻訳システムの記述は省略しています)
その後、レガシー用語集管理システムのデータベースとファイルストレージを新しいフォーマットに変換しながら新しい用語集管理システムに移行し、モダン用語集管理システムが用語集の更新を行うように切り替えます。(レガシー用語集管理システムの用語集はファイル翻訳でのみ利用されます。)
このアプローチの場合、レガシー用語集管理システムの改修が不要であり、Scalaの技術者が不足している弊社の状況に適しています。ただし、モダン用語集管理システムがレガシーデータのフォーマットに依存するため、リアーキテクチャが完了するまでモダン用語集管理システムの設計が制約される可能性があります。
3. アプリケーションとデータベースを同時に移行する
このアプローチでは、レガシー用語集管理システムとモダン用語集管理システムの両方を同時に稼働させ、両方のシステムが用語集データの更新を行います。
両方のシステムで更新を開始した後で、それ以前にレガシー用語集管理システムで作成されたデータをモダン用語集管理システムに同期します。両方のシステムでデータが同期された後で、全てのテキスト翻訳リクエストをモダン用語集管理システムに切り替えます。
このアプローチの場合、Scala言語で書かれたレガシー用語集管理システムの改修は不要であり、モダン用語集管理システムの設計も制約される可能性がなくなります。ただし、両方のシステムでデータの一貫性を保つために、HTTPリバースプロキシが両方のシステムに対してデータの整合性を保つように更新する必要があります。
サーガ(Saga)パターンを用いたデータ同期の実装
弊社では、3つ目のアプローチを採用し、用語集管理システムのリアーキテクチャを進める予定です。両方のシステムでデータの一貫性を保つために、サーガパターンを用いてデータ同期を実装します。
サーガパターンとは
サーガパターンは、分散トランザクションを管理するためのパターンであり、一連のローカルトランザクションを定義し、それぞれのトランザクションが成功した場合に次のトランザクションを実行します。もしどれかのトランザクションが失敗した場合、補償トランザクションを実行してシステムの一貫性を保ちます。
サーガパターンの実装には、以下の2つの方法があります。
- コレオグラフィー(Choreography)ベースのサーガ
- オーケストレーション(Orchestration)ベースのサーガ
今回のリアーキテクチャでのサーガパターン
今回のリアーキテクチャではオーケストレーションベースのサーガを用いたデータ同期の実装例を採用予定です。オーケストレーションベースのサーガでは、サーガオーケストレーターが各サービスのトランザクションを管理します。このオーケストレーターは、今回はHTTPリバースプロキシの一部として実装され、用語集管理システムのデータの整合性を保つ役割を果たします。以下の図のようなシーケンスでデータ同期を実装します。
もし、モダン用語集管理システムでの用語集管理リクエストが失敗した場合、サーガオーケストレーターは以下の図のようにレガシー用語集管理システムに対して補償トランザクションを実行します。
補償トランザクションはUndo操作として実装されます。例えば、用語集の作成が失敗した場合、補償トランザクションはその用語集を削除する操作になります。Undo操作の実装にはコマンドパターンを用いることが一般的です。
今回の例では、逐次的にトランザクションを実行していますが、パフォーマンスの観点から並行してトランザクションを実行することも可能です。ただし、並行してトランザクションを実行する場合、補償トランザクションの設計がより複雑になる可能性があります。
まとめ
レガシーデータを持つサービスのリアーキテクチャには、データの整合性や移行の複雑さなどの課題があります。ストラングラーフィグパターンを用いることで、リスクを最小限に抑えつつシステム全体をモダナイズできます。さらに、サーガパターンを用いたデータ同期の実装により、分散トランザクションの管理が容易になります。
