I’m an integration specialist at Solita Oy, an IT service management company, and a Boomi implementation partner. Our team was given the task of migrating master data from one Boomi Data Hub cloud to another Boomi Data Hub cloud location. Migrating data is often a complex task, and every platform and tool provides its own challenges. Data Hub has its own quirks that are good to know when performing migrations.
During the migration process we encountered a number of these challenges and found solutions. Now we want to share our lessons learned and best practices so others might benefit.
Boomi Data Hub（データハブ）とは？なぜ重要なのか
Boomi Data Hub（データハブ）は、 Boomi Enterprise Platformに含まれる幅広い用途に対応できるマスターデータ管理ソリューション（Master Data Management：企業内に分散する基幹データを統合・管理し、正確性と一貫性を保つための仕組み） です。企業が保有するマスターデータを、迅速かつ直感的に管理・監視・設定できる点が特長となります。
さらに、Boomi Enterprise Platformに含まれるBoomi Integration（複数の業務システムやクラウドサービスをつなぎ、データのやり取りを自動化する連携基盤） と組み合わせることで、周辺システム間のデータを一元的に維持できる環境を実現できます。これにより、企業全体でデータの整合性を保ちながら、業務をスムーズに進められるようになります。
背景
私たちのチームは、2つのリポジトリ（Repository：マスターデータを種類ごとに整理して保管・管理するための単位）と数千件におよぶ ゴールデンレコード（Golden Record：複数のシステムに分散する同一データを統合し、最も信頼できる正しい情報として管理されたマスターデータ） を含む Boomi Data Hub環境を運用していました。
We approached Boomi for the possibility of migrating the data in the background but unfortunately there weren’t any ready-made solutions available. There are ways for backing up and restoring data within a singular cloud environment, but migrating from one cloud to another, even within the Boomi Enterprise Platform environment, was a new challenge.
The MDM implementation style in use in our case followed the coexistence model, where multiple databases and systems containing master data must coexist. This caused additional complexity due to the distributed fashion of governance and importance of maintaining which systems have contributed to the golden records data.
As no ready-made solutions were available, we decided to find our own way and solution to the issue. During this process we discovered multiple things that don’t work, and some things that do work.
Data Hub（データハブ）移行前に検討すべきポイント
連携プロセスの準備
We found that transferring a Data Hub production environment was not feasible in a single go, as any errors during the migration might cause issues within production.
Instead, we chose to set up the new Data Hub repository in the new cloud and change our integrations in a way that all incoming data could be sent to either or both of the Data Hub environments.
We could control the flow of data from integrations to Data Hub through environment-extendable properties. This would give us fine control on the data flow without unnecessary deployments. The idea was to guide all incoming data towards Data Hub to be written in both Data Hubs, the old and the new, at the same time. Any data read from Data Hub would be coming from one Data Hub or the other, but this could also be controlled via the environment extensions.
What this setup enabled was that we could perform the migration handover smoothly by monitoring both the old and new Data Hubs for some time while comparing the data status periodically. This identified any errors in migration, allowed us to fix data issues, and when the time came, switch the Data Hub repositories with minimal impact on production usage.
We of course rehearsed the process multiple times with test environments before and during the migration of actual production data. Test data could only reveal part of the issues that actual complex production data with rich history would introduce to the process, so we had to return back to the test environments to ensure new solutions to revealed errors would work.
移行プロセスに適したツールの選定
リポジトリの構成や移行の目的によっては、「データの取得」「アップサート（Upsert：既存データの更新と新規データの登録を同時に行う処理）」「アップサート状況の監視」「データ状態の比較」など、多くのリクエストを実行する必要があります。さらに、データの変換、保存、比較、エンリッチメント（Enrichment：外部情報の付加によるデータ価値の向上）といった処理も求められます。
Data Hub からのデータ取得は REST API（Representational State Transfer API：Webの標準的な通信方式を用いてシステム間でデータをやり取りするためのインターフェース） を通じて行う必要がありました。これは、Data Hub コネクタではレコード履歴やメタデータ（Metadata：データの属性や状態などを示す補足情報）、高度なクエリなど、必要な情報を十分に取得できなかったためです。その結果、HTTP Client コネクタを利用することになりましたが、このコネクタは ステートレス（Stateless：通信のたびに状態情報を保持せず、毎回認証などの処理が必要となる方式） であるため、リクエストごとに認証を行う必要がありました。
もしデータの最新状態のみが重要で、履歴や周辺システムとの関連情報が不要であれば、移行ははるかに簡単になります。その場合は、データベースを .csv 形式で一括出力して変換し、新しいData Hubにアップロードするだけで済みます。
The REST API allows only the fetching of 200 golden records at a time. To fetch more golden records, the query needs to be repeated with an offset token provided with the previous reply. This prevents the API from choking under too large loads, but at the same time forces users to make repeated queries in order to get multiple records.
さらに、私たちはゴールデンレコードの履歴も移行対象としたため、各レコードごとに個別の取得処理が必要でした。加えて、各レコードのソースリンク状態を確認するためのメタデータ取得が必要となる場合もあり、リクエスト数は急速に増加しました。
BoomiのHTTP Clientコネクタのようなステートレス接続を使用した場合、単純なデータ取得だけでも実行時間が長くなり、現実的な作業スケジュールの維持が難しくなります。実際、ステートレス接続ではデータ取得と履歴取得に 1 時間以上を要しましたが、ステートフル接続（Stateful：通信中の状態情報を保持し、再認証などの処理を削減できる方式） を導入することで、約15分まで短縮できました。
さらに、ステートフル接続の導入、非同期処理（Asynchronous Processing：処理の完了を待たずに並行して作業を進める方式）、および幅優先のデータアップロード（Breadth-first Upload：複数データを段階的に広く処理していくアップロード方式）などの改善により、移行全体の実行時間は約1週間からわずか 3 時間へと大幅に短縮されました。
実行時間が 1 日以上に及ぶ場合、システム負荷の変動による影響を受けやすくなります。例えば、バッチ処理の実行順序が送信順と一致しない、処理完了待ちの間に接続がタイムアウトする、といった問題が発生します。また、データ破損への対応のために移行プロセスを複数回実行する必要もありました。
We chose to utilize custom Python scripts to perform the data fetching and insertions. We are sure that even better options for tooling would have been available, but with the time limits and our team’s familiarity with Python, it ended up as our choice.
So, before you start your migration process, research your options for the tool to use.
セキュリティへの配慮
どのようなツールを選択する場合でも、実際のゴールデンレコードや API キーなどの機密情報を、移行作業に使用する端末や環境に残したままにしないよう注意が必要です。こうしたデータを放置すると、セキュリティリスクを生むだけでなく、自社が意図せず機密情報を保管している状態となり、特定の法規制の対象になる可能性もあります。
特に人事関連データ（HR data）は、個人情報や機微性の高い情報を多く含む傾向があります。そのため、GDPR（General Data Protection Regulation：EU における個人データ保護規制） や、日本の 個人情報保護法（Act on the Protection of Personal Information：企業が個人情報を適切に取得・利用・管理するための国内法規） など、適用される法令の担当部門と連携し、適切なデータ管理体制を確保することが重要です。
データ移行プロジェクトでは、技術面の対応だけでなく、法令遵守の観点からもセキュリティを十分に考慮することが求められます。
データのクレンジングを実施する
移行は、さまざまなクエリや検証を通じてデータの状態を見直す絶好の機会です。移行前にデータ品質を一定の基準まで高めておくことで、移行プロセスを大幅に簡素化できるだけでなく、移行対象となるデータ量の削減にもつながります。
適切なマッチングルール（Matching Rules：複数のデータが同一かどうかを判定するための条件）やデータガバナンス（Data Governance：データの品質・管理責任・運用ルールを組織的に統制する取り組み）を整備していれば、本来は重複データが発生することは少ないはずです。しかし、実務上は例外的に重複が発生するケースもあります。
重複データを含んだまま移行を進めると、移行途中でレコードが 隔離状態（Quarantine：不整合やルール違反が検知されたデータを一時的に本流から分離する管理状態） に置かれる可能性があります。こうした状況への備えがない場合、移行プロセスが突然停止したり、データが破損したり、特定のレコードの移行をやり直す必要が生じることがあります。結果として、手作業による修正対応が大幅に増加し、移行プロジェクト全体の負担が大きくなるおそれがあります。
移行計画を立てる
Proper preparation won’t stop all the errors or prevent all the surprises, but it will minimize them.
Proper research into tool options saves you a lot of time during the process.
Reserve enough time for the project. Depending on MDM solutions used and tool options, you might have to create your own tools or spend time on automating parts of the process like data comparisons.
Plan the switch from the old MDM solution to the new one. Overlap between the old and new solutions might give you the possibility to verify the success of data migration and configurations. Running data to both old and new MDMs gives you the option to compare how the MDMs react to data and that they keep data synchronous.
Prepare for rollbacks. With Boomi Data Hub you should contact your Boomi representative to discuss rollback possibilities. You also need to take into account any rollback possibilities in surrounding systems. A data error in an MDM solution is quick to spread to surrounding systems.
Your old system connections might look a bit different after the migration. How should manually modified golden records look like in the new MDM? With Boomi Data Hub, you cannot use the “MDM” source that is shown on manually edited records. You have to either modify the source contributing to these manual changes to reflect one of your systems or come up with an extra source that will take responsibility for these changes.
Are you going to migrate also archived data? Getting end-dated records changes the process a bit, as the chance of duplicates increases. A record might have had multiple instances in the past and trying to migrate these might cause you to end up with duplicate errors in the migration process.
In the second blog of this series, I cover MDM configuration.
Boomi Data Hub は、企業内に存在するさまざまなデータサイロ（Data Silo：部門やシステムごとに分断され、共有されにくいデータの状態）の中心に位置する、クラウドネイティブ型のマスターデータ管理ソリューション です。既存の MDM 環境も含めたデータ基盤全体をつなぎ、導入しやすく、拡張性・柔軟性・セキュリティに優れた「サービスとしてのマスターデータ管理ハブ」を実現します。
詳細については関連情報をご確認いただくか、 Boomi 担当者までお問い合わせください。