Dow Jones でビジネスクリティカルなデータベースの移行 とモダナイズを一括して行い効率性とコストメリットを 実現した方法

マーケットデータのプラットフォームアーキテクチャについて

Dow Jones では、ピーク時に、マーケットデータプラットフォーム経由で毎秒 3,000 件を超えるリクエストを処理しています。データの種類は、取引所からの公式の終値から、リアルタイムの現在値データ、会社情報、マッピングデータまで多岐にわたります。Dow Jones のマーケットデータプラットフォームは、このマーケットデータを取り込み、正規化し、Dow Jones 全体で可視化します。ビジネスにとっての戦略的価値を考えると、プラットフォームはきわめて信頼性に優れ、スケーラブルかつ高速であるとともに、ダウンタイムから保護しつつ、数ミリ秒以内にリアルタイムのマーケットデータを消費者に提供する必要があります。

プラットフォームをモダナイズする前のシステムは、4 つの主要グループに分かれた 200 のオンプレミスサーバーで、44 を超えるアプリケーションが別々に実行されるという構成でした。

プラットフォームの中核的なデータストレージレイヤーは、Microsoft SQL Server 2008 R2 上に構築されオンプレミスで稼働する、2 TB のリレーショナルデータベース管理システムでした。このデータベースは、マーケットデータに関連するあらゆる情報の中央リポジトリとして、アプリケーションシステムのすべてのデータの格納に使用されていました。例えば、各証券取引所の上場銘柄情報に直接マッピングされた各企業に関するデータも、ここに格納されていました。このサーバーデータベースには、1970 年代にさかのぼる株価すべての履歴データを含めて、取引の処理に必要となる、マーケットデータに関するオペレーションデータも保存されていました。

マーケットデータの管理と消費者への提供に使用される一部のアプリケーションは、SQL Server データベースを中心としたものでした。AWS への移行により、そのようなシステムを使用停止とすることができました。使用停止となったのは以下のようなシステムです。

• DJ Symbology System: 米国の企業、カナダの企業、およびグローバル企業に向けたリアルタイム相場または遅延相場情報に「銘柄コード」(ダウジョーンズティッカーシンボルなど) の実際のマッピングを提供していました。
• Real-time Feed Processor グループのアプリケーション: 市場が開き、株式取引が行われているときに、最新データを維持する役割を果たしていました。これらのアプリケーションは複数のソースに接続され、データを取り込み、それをマーケットデータプラットフォームに統合していました。
• Intraday Systems: 市場の状態を維持する役目を負っていました。最終的には、クライアント向け API を移行しました。クライアント向け XML ファイルと印刷物を生成するためのレポートシステムの他、グラフ作成システムおよびメインのマーケットデータ APIです。

これらの各アプリケーションはそれぞれ、アラートの管理、インデックスの計算、価格の提供、クエリエンジンの更新など、マーケットデータアーキテクチャのさまざまな部分に対応していました。

アーキテクチャの観点では、オンプレミスのマーケットデータ用 SQL Server データベースは、米国内の 2 つの異なるデータセンターに分散された 15 もの個別のデータベースサーバーインスタンスで構成されていました。Dow Jones では、可用性の向上と障害時のデータ保護を目的として、SQL Server データベースミラーリングを使用していました。2 つの異なるデータセンターにまたがって 4 つのプライマリがミラーリングされ、その他のサーバーインスタンスは 2 つのディストリビューターインスタンスと 9 つのサブスクライバーインスタンスに分割されていました。プライマリプリンシパルサーバーインスタンスは、単一のデータセンターのすべてのクライアントにデータベースを提供していました。一方、プライマリミラーインスタンスは、プライマリサーバーに障害が発生した場合に備えるウォームスタンバイサーバーとして設定されました。各データセンター内のディストリビューターインスタンスは、ローカルサブスクライバーノードへの同期レプリケーションを処理していました。書き込みはすべてプライマリデータセンター内のプリンシパルサーバーによって処理され、読み取りは両方のデータセンターに分散された 9 つのサブスクライバーインスタンスによって処理されていました。

Dow Jones の移行とモダナイゼーションの概要

Dow Jones チームでは、本稼働までの時間を短縮するために、リフトアンドシフトのクラウド移行戦略を使用して、マーケットデータアプリケーションのコアコンポーネントを AWS に移行しました。この戦略によって Dow Jones は、アプリケーション全体を再設計することなく、コード変更を最小限にして移行を加速できました。このアプローチは暫定的なものです。リフトアンドシフトによる AWS への移行が終われば、クラウドネイティブのアプローチに移り、モダナイズを行う予定でした。AWS クラウドサービスと最適化は、システムのアップグレードと再構築が容易になるという大きなメリットをもたらしました。

このプロセスでのライセンスコストに対処するために、同社は MS SQL Server 上にある既存 (オンプレミス) の 2 TB のデータベースをクラウドネイティブデータベースにアップグレードしました。これにより、このタイプの AWS データベースで提供される信頼性、スケーラビリティ、管理性、コスト最適化を最大限に活用できるようになりました。結果として、マーケットデータは Amazon Aurora を使用して再構築されました。Amazon Aurora は、クラウド向けに構築された MySQL 互換のリレーショナルデータベースで、ハイエンドの商用データベースのパフォーマンスおよび可用性と、オープンソースデータベースのシンプルさおよび費用対効果を兼ね備えています。

Dow Jones のソフトウェアエンジニアリングマネージャーである Luke Sawatsky 氏は、「オンプレミスの SQL Server データベースから Amazon Aurora MySQL への移行は、いくつかの重要な段階を伴うものの、簡単なプロセスでした」と述べています。

第 1 段階: データベーススキーマの変換

AWS Schema Conversion Tool を使用した自動的なスキーマ変換

Dow Jones では、2 TB のデータベースを MS SQL Server からターゲットの Amazon Aurora MySQL データベースに移行する前に、ターゲットスキーマを作成する必要がありました。このプロセスを支援するために、同社は AWS Schema Conversion Tool (AWS SCT) を使用して、既存のデータベーススキーマを MS SQL Server から Amazon Aurora MySQL に変換しました。

また、Dow Jones ではこのプロセスの一環として、AWS SCT によるデータベース移行評価レポートを生成しました。このレポートは、AWS Schema Conversion Tool を使用してプロジェクトのうちどの程度を完了でき、変換を完了するためには他に何を行う必要があるかを評価するものでした。このレポートは、すべてのスキーマ変換タスクを要約し、ターゲットの Aurora MySQL の DB インスタンスに変換できなかったスキーマのアクション項目を詳細に示すことができる、きわめて価値の高いツールでした。

この分析の結果、Dow Jones の場合は、移行ターゲットとして MySQL 互換の Amazon Aurora を使用すれば、データベースストレージオブジェクト (スキーマ、テーブル、インデックス、タイプ、テーブルタイプなど) の 99.8% と、データベースコードオブジェクト (トリガー、ビュー、プロシージャ、関数など) の52% が、自動的に変換または最小限の変更で変換できることがわかりました。さらに、Dow Jones のデータベーススキーマ全体の 97% を Amazon Aurora (MySQL 互換) に自動変換できる可能性がありました。

スキーマの手動変換

ほとんどの移行作業は自動化できましたが、手動操作が必要になる箇所もいくつかありました。このレポートでは、1 つのデータベースストレージオブジェクトと 38 のデータベースコードオブジェクトに、手動操作で「significant action」(重大なアクション) を要するというフラグが付けられました。

例えば、データベースコードオブジェクトに関する重大な問題の 1 つは、Dow Jones でのグローバルカーソルの使用に関連していました。

Aurora MySQL Cursors フレームワークは SQL Server よりも単純で、基本的なタイプのサーバーのみが提供されます。Dow Jones のコードが高度なカーソル機能に依存するものであれば、全体的な再作成が必要になった可能性もありますが、この問題については、一時テーブルを使用して対処できました。

Dow Jones が遭遇した 2 つ目の問題は、SQL Server の関数に関連するものでした。この関数は、ネストされた SQL 文を使用して、レコードのツリーとその親レコードを取得するものでした。この再帰処理は MySQL で再現できなかったため、この SQL ステートメントを C# で記述し直す必要がありました。

Dow Jones では変換の問題ごとに、AWS SCT でオブジェクトをターゲットの Aurora MySQL データベースに正常に変換できるように、ソースの SQL Server データベース上のオブジェクトを適宜変更しました。SCT を使用すると、各反復の後のタイミングで評価レポートを再確認できました。

この段階では、変更したコードが期待どおりに実行されたことを検証するために、いくつかの小さな POC が並行して実行されました。Dow Jones では、変換の問題がなくなるまでこのプロセスを続けました。Dow Jones による計算では、ストアドプロシージャのコードの書き換えに要したエンジニア数は、合計で月に 1 人でした。さらに、あるコードの問題を修正すると他の問題が同時に修正されることが多く、全体の時間を短縮できることもわかりました。すべての変換を完了して、スキーマの変更を Aurora MySQL データベースに適用すると、次の段階であるデータ移行の準備が整いました。

第 2 段階: AWS Database Migration Service によるデータの移行

Dow Jones では、AWS Database Migration Service (AWS DMS) を使用することで、データを迅速かつ安全に、オンプレミスの SQL サーバーから Amazon Aurora MySQL に継続的に移行できました。移行中もソースデータベースの稼働状態がフルに維持されるため、データベースに依存するマーケットデータアプリケーションのダウンタイムを最小限に抑えることができました。データベース移行タスクを設定する際に、Dow Jones では「既存のデータを移行し、継続的な変更をレプリケートする」オプションを選択しました。これは、大量のデータがロードされた後でも、AWS DMS で変更をキャプチャして適用するためのオプションです。AWS DMS は、完全なデータ移行の複雑さを処理し、24 時間以内にプロセスを正常に完了しました。最後のステップとして、AWS DMS のレプリケーションタスクが「CDC のみ」に更新されました。これは、最後の切り替えまで両方のデータベースの同期状態を確保するオプションです。

第 3 段階: 内部テストフェーズと AWS Well-Architected Review

Dow Jones は、移行の次の段階で、マーケットデータプラットフォームが本稼働に対応していることを確認するために、長期にわたる内部テストを開始しました。この期間に、Dow Jones は AWS の専門家と協力して、プラットフォームの AWS Well-Architected Review (WAR) を実施しました。この重要なステップにより、オペレーショナルエクセレンス、セキュリティ、信頼性、およびパフォーマンス効率を確保するためのベストプラクティスを Dow Jones で使用していることが確認されました。Dow Jones では、確実に成功を手にするためのビジネス上の戦略として、コストを最適化するのではなく、容量をオーバープロビジョニングするという決定を下しました。コストの最適化は、移行後の取り組みの一環として予定に組み込まれました。

マーケットデータの WAR は、現在の AWS アーキテクチャについて、技術面で重要な数件の問題を明らかにするために有益でした。これらは、直ちに対応し、改善する必要があるものでした。さらに、マーケットデータチームは、以下のベストプラクティスのレコメンデーションを詳細に盛り込んで、実行可能な計画を策定できました。

• 障害発生時にデータベースを保護できるように、Aurora グローバルクラスターのリードレプリカとライターノードに、同一のデータベースインスタンスタイプ/サイズのプロビジョニングを行う。
• プライマリリージョンとバックアップリージョンの間でインスタンス数のバランスを取る。
• アプリケーションに適切な DNS TTL (1 秒) を設定する。
• 需要に応じて水平方向にスケーリングする。
• 定義したしきい値をクラスターが下回らないように、オートメーションを実装する。
• オートメーション/自動スケーリングを使用して、ピーク時のオーバープロビジョニングと、オフピーク時の数量やインスタンスクラスのダウンサイジングを行う。
• 稼働開始日より前に、Aurora データベースの「大規模」な負荷テストと耐障害性テストをフルに実行する。

最終的な成果: Dow Jones では、オンプレミスのレガシー SQL Server データベースを、スケーラブルで回復力のあるクラウドネイティブデータベースアーキテクチャに移行するモダナイズに成功しました。このクラウドネイティブデータベースは、バージニア州 (us-east-1) に 1 つのライターノードと 5 つのリーダーノードを置き、オハイオ州 (us-east-2) に 6 つのリーダーノードを置く Amazon Aurora グローバルクラスターを使用するものです。

第 4 段階: Aurora MySQL データベースの本稼働環境へのカットオーバー

Dow Jones では、移行プロセスのこの段階で、マーケットデータ用に以下の 2 つの並列データベース環境を稼働させました。

1. AWS でテストモードで動作するクラウドネイティブの Aurora MySQL データベース
2. 本稼働用データをクライアントに提供するオンプレミスの MS SQL Server

次に、Dow Jones では、すべてのクライアントにエンドポイントの変更を要求することなく、Aurora MySQL にカットオーバーするための作業に取り組みました。この課題に対応するために、マーケットデータチームは NGINX と呼ばれるプロキシサービスを使用して、クライアントデータリクエストをオンプレミスから AWS にリダイレクトしました。これにより、Dow Jones のクライアントに、中断することなくサービスを提供できる状態を確保しました。8 時間以内に、プロキシのインストールと DNS エントリの更新が行われ、マーケットデータクライアントが AWS の Aurora MySQL データベースに正常に接続されました。さらに 2 週間後、オンプレミスの MS SQL Server データベースが正式にシャットダウンされ、すべての本稼働トラフィックが AWS の Aurora MySQL データベースに到達するようになりました。これで、Aurora MySQL へのカットオーバーが完了しました。

第 5 段階: 移行後のデータベースの最適化

Dow Jones における移行作業は、AWS への移行で終わりではなく、移行後の段階がありました。Dow Jones ではこの段階で、AWS インフラストラクチャ全体でのコストの最適化とサイズの適正化に取り組みました。Amazon CloudWatch メトリクスと CloudHealth 管理ソフトウェアを使用してデータを分析したところ、マーケットデータワークロードの現在のパフォーマンスと使用要件に基づくと、Aurora MySQL に使用していたデータベースインスタンスのタイプ/サイズが大幅にオーバープロビジョニングされていることがすぐにわかりました。Dow Jones では、この分析の結果、Aurora MySQL データベースのインスタンスタイプ/サイズが現在の容量要件にさらに適合するようにサイズを調整し、コストの削減を進めるためにリージョンごとに 2 つのリーダーノードを排除する措置を講じました。再デプロイ後、Dow Jones は大幅に支出を削減できました。

まとめ

Dow Jones は、自社のミッションクリティカルなマーケットデータプラットフォームの安全性、優れたパフォーマンス、回復力、効率性を維持する必要がありました。オンプレミスの Microsoft SQL Server から Amazon Aurora に移行してモダナイズすることで、コストメリットが明らかになっただけでなく、クラウドネイティブツールによるメリットもありました。Amazon Aurora の自動ストレージプロビジョニングやレプリカなどの機能により、Dow Jones でのデータの保守および複製が容易になりました。

AWS では、クラウドを貴社で最大限に活用した場合のメリットをわかりやすく把握できるようお手伝いします。AWS は数百万のお客様からご信頼いただき、最も重要なアプリケーションをクラウドに移行しモダナイズするためにご利用いただいています。ぜひ、このコミュニティにご参加ください。Windows Server または SQL Server のモダナイズの詳細については、「Windows on AWS」をご覧ください。 今すぐ移行を開始するには、お問い合わせください。