AWS Schema Conversion Tool によるTrimble社のデータベース移行を成功させた秘訣とは’s データベース移行の成功

Trimble 社の フィールドサービス管理部門 (FSM) でインフラストラクチャ運用部のディレクターである Todd Hofert 氏による寄稿。

状況
最近、 Trimble 社のフィールドサービス管理部門のインフラストラクチャ運用グループは、非公開でホストされている SaaS サービスをアマゾン ウェブ サービス (AWS) に移行する積極的な取り組みに着手しました。同部門は、ハードウェアのリフレッシュ、継続的なコスト削減の必要性、 AWS 上の同社の次世代プラットフォームと従来の商品を調和させたいという必要性に直面しました。これに対応して、 Trimble 社のインフラストラクチャチームは、データウェアハウスソリューションから始まる包括的な移行計画を策定しました。

コスト削減、可用性、スケーラビリティは、 AWS イニシアチブへの主な推進力でした。Trimble 社は、Oracle からオープンソースデータベースプラットフォームに移行することで、現在のライセンスコストを最適化することに決めました。また Trimble 社は、 Amazon RDS を使用してデータベースを動作させることで、信頼性を保証し、運用サポートの間接費を削減することにも力を入れました。

データベースの選択
Trimble 社の運用とデータベース開発チームは、 AWS チームを招き入れて、 Oracle から離れたデータベースプラットフォームへの移行に関する難易度を調べました。この評価の中心となったのは、 AWS Schema Conversion Tool (AWS SCT) 評価レポートでした。

Trimble 社のチームは AWS SCT を使用して、ソースである Oracle データベースと Amazon Relational Database Service (Amazon RDS) のオープンソースデータベースエンジンの中で代替となるターゲットとの「ギャップ」を調べたのです。Trimble には、既存の ETL ツール (Informatica) とレポートを作成する製品 (Microstrategy) を使用できること、という2番目の基準もありました。私たちは、プロジェクトが計画通りに進み、ビジネスの期待に沿えるためにはこのアプローチが必要であることを確信しました。一方でスコープクリープを回避する必要があります。

いずれのデータベースでも Trimble 社が既存のフロントエンドソリューションを使い続けることが可能でした。しかし、 AWS SCT の評価では、 PostgreSQL の RDS は Oracle ソースデータとのギャップが少なく、ターゲットデータベースとして選択するようになっています。Schema Conversion Tool 評価レポートでは、現在のデータベースプラットフォームと PostgreSQL 用 RDS との間の機能的なギャップに対応するために、どういう点で努力が求められたかについて明確なイメージが示されていました。それに応じてリソース提供の計画をしることができました。

評価レポートは、 Trimble 社に RFP に対する入札を促すための基盤とフレームワークを提供し、第三者が大部分の移行作業を行えるようにしました。この基盤により、 Trimble は他の移行作業に集中することができました。その結果、 Trimble は Amazon の提携企業である OpenSCG と有益なパートナーシップを結び、データベース移行活動を推進しました。Trimble は、 OpenSCG のサポートサービスとトレーニングプログラムを通じて、この関係を今も維持しています。

Schema Conversion Tool 評価レポートは、この移行への努力の範囲を理解するための成功への鍵となりました。もともと特に夢中になって取り組んできた人がいない、大部分が手作業だと考えていた仕事でしたが、簡単明瞭にプロセス化されました。この評価は、予定していた日程を数か月間、短縮しました。

移行
Trimble 社は 4 社ほど有望なベンダーから入札を求めました。入札額を確認した後、他のベンダーからの回答と比較し、Trimble 社は専門性と造詣の深さを理由に、 OpenSCG と契約をしました。Trimble は特定されている機能に関するギャップを解消するという過酷な仕事を OpenSCG に課しました。OpenSCG は PostgreSQL データベーススキーマを作成して、ソースデータベースからターゲットデータベースにデータを移行するための移行スクリプトを書いていました。Trimble スタッフはこれらの取り組みをサポートし、フロントエンドアプリケーションの構成と検証に関係するすべてのタスクを担当しました。

プロジェクトは2つのサブプロジェクトに分割されました。最初に、チームは北米のホスト型移行に焦点を当てて、その後ヨーロッパのホスト型移行を行いました。北米データベースのサイズは 6.5 TB で、月あたりの平均成長率は約 22 GB でした。ヨーロッパのデータベースは 4.6 TB で、月あたりの平均成長率は 33 GB です。

チームは既存の非公開にホストされている災害復旧サイトのデータベースのレプリカセットを移行のソースデータベースとして使用しました。彼らは、 PostgreSQL データベース VM と同時に、データ移行 VM を配備しました。これらの VM は、 OpenSCG が提供するスキーマとスクリプトを使用して生産データベースをターゲットである PostgreSQL データベースに移行しました。移行が正常に完了したら、 AWS snowball を使用して、エクスポートされた PostgreSQL データベースを AWS に送信しました。AWSでは、エクスポートされたデータベースが PostgreSQL インスタンスのターゲット RDS にインポートされました。このプロセスはそれぞれ地図上の場所で 2 回行われました。最初の反復でテストデータがシードされ、 2 度目は検証後に生産データセットを作成しました。

切り替え
既存のETLプロセスは、非公開でホストされたデータウェアハウスのライブソリューションと、 PostgreSQL ソリューション向けの試作品の RDS との間で同期を維持しました。QA 、機能テストと性能テストを徹底した期間、データ整合性の検証により、いくつかの問題が特定されました。チームは当初予定されていた公開予定日より前にそれらをうまく解決しました。最も重大な課題は、 ETL プロセスの性能面と、一部のレポートの性能に関する問題でした。

実施したチームのデューデリジェンスは、人の目につきにくい切り替えとなりました。この切り替えは、 ETL の実行とレポートの実行の間で論理的にスケジュールされたので、エンドユーザーはまったく気付きませんでした。

結果
Trimble FSM はそれ以来、従来のデータウェアハウススタックを完全に廃止しました。Trimble はコロケーションプロバイダーからの完全な撤退を完了しつつあります。

このデータウェアハウスへの移行は、ホスティングされたすべてのソリューションを AWS に移行するためのより大きなプロジェクトの最初の 3 つの段階を示していました。Trimble は現在までに、 2 つの生産データウェアハウススタック、それぞれの開発環境、および北米およびヨーロッパの従来の生産アプリケーションスタックの移行を完了しました。Trimble は現在、年末に完了予定のアプリケーション開発環境の移行の最終段階にあります。

見積もりが示すところによれば、これらのプロジェクトにより、Trimble 社の直接的なインフラストラクチャのコストは、非公開でホストされるインフラストラクチャの 4 分の 1 以下に減るはずです。追加の AWS サービスを利用する将来の取り組みの計画が進行中です。Trimble 社はこれらにより、運用にかかる間接費をさらに節約することを期待しています。

まとめ
このプロジェクトの主な取り組みは次のとおりです。

利用可能なすべてのリソースを用いて、プロジェクトロードマップを定義するための完全なデューデリジェンスを実施します。Trimble は、 AWS Schema Conversion Tool とその AWS アカウントチームのアドバイスを利用しました。これらは重要な成功要因であることが判明しました。

プロジェクトを補完するための外部のリソースや専門家のアドバイスを検討することをためらってはいけません。社内チームを完全にするため外部のベンダーと協力してプロジェクトにかかる時間を数か月短縮しました。

最初に理想的な仕上がり像を思い描き、必要に応じて実現可能なものに引き返して取り組んでください。多くの人が Oracle からのプラットフォーム移行が、途方もないことで達成できそうにない目標であると感じていました。結局のところ、その心配は根拠がないことが分かりました。