Amazon Web Services ブログ

Autodesk のミッションクリティカルなデータベースを Microsoft SQL Server から Amazon Aurora MySQL に移行する



この記事は、Autodesk のソフトウェアアーキテクトである Tulika Shrivastava 氏が、AWS の Rama Thamman の協力の下で執筆したゲスト投稿です。Autodesk は自社を評して次のように述べています。「Autodesk は 3D 設計、エンジニアリング、エンターテイメントソフトウェアの分野で牽引する企業です。車を運転したり、超高層ビルを見上げたり、スマートフォンを使用したり、偉大な映画を見たりしたことがある人は、何百万もの Autodesk ユーザーがソフトウェアで行っていることを身をもって体験されているものと思われます」

Autodesk は、AWS のサービスの中でも特に、プライベートデータセンターから Amazon EC2 へワークロードを移行することで、数年前にクラウドのモダナイゼーションを開始しました。Autodesk は、柔軟性とスケーラビリティを得て予想される成長を後押しするために近代化する必要がありました。2019 年、当社はミッションクリティカルなシングルサインオン (SSO) アプリケーションを EC2 上のセルフマネージド SQL Server から完全マネージド型の Amazon Aurora MySQL に移行しました。このサービスでは、1 億 4200 万人を超えるユーザーからの認証リクエストを集め、1 分あたり 145,000 件を超える API リクエストに応答しています。認証と承認のために 300 を超える製品とサービスと統合されています。

この移行により、Autodesk SSO サービスの管理と復元力が合理化され、コストが最適化され、インフラストラクチャメンテナンスのオーバーヘッドが削減されました。初期コスト分析によると、当社は Amazon Aurora MySQL を使用することで、データベース全体のコストの約 40〜50% を毎月節約できるだろうことがわかりました。

この記事では、Autodesk がこのミッションクリティカルなデータベースを最小限のダウンタイムで移行した方法の概要を説明します。以下のセクションでは、移行前のアーキテクチャ、移行戦略、移行手順、パフォーマンスの比較について見ていきます。

移行前のアーキテクチャ

次の図は、Autodesk の以前の SQL Server アーキテクチャを示しています。データベースは、セルフマネージド EC2 インスタンスで実行されていました。この設定には、災害復旧のために、複数のアベイラビリティーゾーンと別のリージョンの 1 つのノードにかけて、Always On 機能がありました。

時間が経つにつれて、チームは既存の設定で以下の課題に直面し始めました。

  • 停止 – 過去の多くのインシデントは、複雑なセルフマネージドデータベースインフラストラクチャによるもので、RAID 10 設定の Amazon EBS ストレージを備えた EC2 インスタンスが関わっていました。これにより、Windows Server Failover Cluster (WSFC)、ストレージ、IOPS などのさまざまなレイヤーで問題が発生しました。さらにシリアスなのは、インシデントの根本原因の分析を行うことが困難になったことです。
  • バックアップ – バックアップの管理はオーバーヘッドであり、特にリージョン間のセットアップでそれが言えます。自動化されたスクリプトを使用していましたが、このプロセスには依然として手作業とモニタリングが必要でした。
  • パッチング – Autodesk には複数の環境 (テスト、ステージング、本番など) があるため、パッチの適用に管理者はかなりの時間を割くことを余儀なくされました。
  • スケーラビリティ – プライマリノードは読み取り専用のルーティングリクエストを処理し、接続するセカンダリノードを識別します。この機能により、接続は常に正常なセカンダリノードにルーティングされますが、スケーラビリティの観点からはプライマリノードがボトルネックになります。
  • レプリカの数 – SQL Server は最大 8 つのセカンダリレプリカがありますが、Aurora MySQL は 15 のレプリカを持つことができます。
  • コスト – 総所有コストは、Aurora へ移行することで達成できるコストの 2 倍でした。
  • 伸縮性 – インフラストラクチャのスケーリングは時間のかかるプロセスでした。

移行戦略

Autodesk は概念実証を実施することで計画を開始しました。これにより、アプリケーションの変更、データベースの変更、スクリプトの自動化、事前に作成できるサービスの特定が可能になりました。さらに重要なことは、Aurora への移行により、前述の制限を受けないことが分かったことです。

 

Autodesk は、必要な変更を実装した後、段階的なアプローチでさまざまな環境を移行する計画を立てました。これにより、戦略を微調整し、さまざまな環境で移行を実行するときに発生するダウンタイムを明確につかむことができました。目的は、最小限のダウンタイムで移行することでした。さまざまな環境で移行を迅速かつ一貫して実行する柔軟性を実現するために、当社は Terraform を使用したデータベース作成や DMS 設定などの要素を自動化しました。 自動化には AWS CloudFormation を使用することもできます。

 

次のセクションでは、重要な考慮事項について説明します。

スキーマの移行

AWS Schema Conversion Tool は、最小限の労力でスキーマを移行するための優れたツールです。この場合、カスタム要件のために、独自のスキーマ変換アプローチを使用する必要がありました。

スキーマ変換プロセスの一環として、データベースに最適な文字セットを選択しました。これにより、データベースのサイズが元のサイズのほぼ 3 分の 1 に削減されました。これは得られた大きな利点の 1 つでした。

ターゲットデータベースのスキーマを確定する前に、次のオプションを徹底的に評価する必要があります。

  • 文字セットと照合
  • データ型の選択
  • 日付/時刻パターン
  • マルチバイト文字ストレージ
  • 特殊文字ストレージ
  • インデックスのタイプ

これらの考慮事項は、データを正常に移行するだけでなく、特別なデータセットに関する移行後の問題を回避するのにも役立ちます。

キャパシティープランニング

キャパシティープランニングのために広範なテストを実施しました。ワークロードを繰り返し実行して、適切なインスタンスのサイズと容量を決定しました。そして Amazon CloudWatch、New Relic、MonYog などのさまざまなモニタリングツールの主要なメトリクスを比較しました。さらにスロークエリログを分析しました。また、既存の実稼働ワークロードと、トラフィックとデータの成長の将来予測についても検討しました。

アプリケーションの移行

データアクセスに NHibernate (ORM) を使用したため、アプリケーションの移行はシームレスに行えました。ORM はクエリの約 80% を生成したため、ORM 設定の変更を最小限に抑えて、アプリケーションに MySQL のクエリを生成させることができました。ORM からアプリケーションで生成されるクエリの数を把握して、残りのクエリを変換するために必要な労力を見積もることは良いアイデアです。

当社は、オンデマンドのデータベース接続切り替えをサポートし、読み取り/書き込みトラフィックを制御するための SSO アプリケーションの機能を開発しました。これは、さまざまな環境での移行の計画と実行を通じて継続的にデプロイする際に非常に役立ちました。また、データベースカットオーバー中のダウンタイムを最小限に抑えるのにも役立ちました。

当社は .NET の完全なフレームワークを使用していましたが、残念ながら、NHibernate を備えた .NET フルフレームワーク用の MySQL ドライバーは、Aurora MySQL フェイルオーバーをサポートしていません。つまり、本質的に、アプリケーションがそのような障害から自力で回復できません。MySQL 用の .NET ドライバーで Aurora MySQL フェイルオーバーのサポートが欠落しているため、回避策を作成して、カスタムソリューションを考え出しました。これにより、アプリケーションが障害なくトラフィックを提供し続けることができます。

データの移行

データの移行と検証は重要なステップです。AWS DMS を使用したため、移行プロセスを安全かつコスト効率よく実行できました。詳細については、「AWS Database Migration Service の使用開始」を参照してください。

移行手順

次の図は、さまざまな移行状態と手順の概要を示しています。これは、ロールフォワード移行の設計パターンです。これらの手順から、移行の進行状況に関する洞察が得られます。以下のセクションでは、各状態とそれが関係するものについて説明します。

可能な限り、事前にサービスとインフラストラクチャを作成しました。たとえば、移行に着手する前に、Aurora MySQL DB、SQL サービスロールバック DB、および DMS インスタンスの準備ができていました。

初期状態

これは、SQL Server でのサービスの初期状態を示しています。

ステップ 1

このステップでは、SQL Server から Aurora MySQL へのフルロード移行を開始しました。フルロード移行は、特定の時点のスナップショットコピーです。DMS はデータをソースからターゲットにコピーします。

 

データベース制約の包含の観点から最適なフルロードパフォーマンスを得るには、フルロードの前にプライマリキーのみを持つことが理想的です。フルロード後に、外部キーなどの他の制約を追加できます。DMS は複数のテーブルからデータを並列にロードするため、複雑な外部キー関係によりプロセスが遅くなる可能性があります。Aurora MySQL では、ライターノードのみを持つのが最適です。SQL Server ロールバックのセットアップでは、プライマリノードでロールバックデータベースを作成することが理想的です。特に大きなテーブルがある場合、単一ノードで実行するとインデックス作成が高速になります。

ステップ 2

Aurora MySQL への SQL Server のフルロードタスクが完了した後、SQL Server ロールバックデータベースへの Aurora MySQL のフルロードタスクを開始しました。タスクが完了すると、ソース、Aurora MySQL、および SQL Server ロールバックデータベース間でフルロードのデータが同期されました。

ステップ 3

このステップでは、Aurora MySQL と SQL Server の両方のロールバックデータベースにインデックスと外部キーを追加し、リーダーノードを Aurora MySQL に追加し、さらにロールバックデータベースを Always On データベースに追加しました。このステップでこれらを追加すると、フルロードのパフォーマンスが向上し、カットオーバー前にデータベースの高可用性が実現します。

フルロード中に検証を有効にすることもできますが、変更データキャプチャ (CDC) を使用する場合は、このステップで有効にする方が効率的です。DMS は、フルロードの一部として移行したデータを含む、データ全体のデータ検証を行います。DMS には、カスタム検証関数を定義できる特別な機能があります。この機能は、特殊文字と BLOB データ型を検証するために頻繁に使用しました。

QA プロセスの一環として、いくつかの重要なワークフローを検証しました。主要なワークフローが期待どおりに機能することを確認するために、フルロード後にラウンドのサンプルデータ検証を行いました。このサンプルデータ検証は、DMS 検証に加えて行いました。徹底的にテストした後、CDC がトリガーされ、ソースから Aurora MySQL へ、そして Aurora MySQL から SQL Server ロールバックデータベースへ、フルロード以降に蓄積された増分変更が伝播されました。

DMS は移行メトリクスを CloudWatch に送信します。詳細については、「AWS DMS タスクのモニタリング」を参照してください。

ステップ 4

CDC が進行中の間、CloudWatch の以下のメトリクスを他のメトリクスと密接にモニタリングしました

  • ValidationPendingOverallCount
  • CDCLatencySource
  • CDCLatencyTarget

検証保留全体カウントが低い値に達したとき、ソースとターゲット間の CDC レイテンシーが最小になったときに、データベースを切り替えました。それは多段階のプロセスでした。アプリケーションの書き込みトラフィックを停止し、保留中のレコードが完全に検証されるのを待って、アプリケーションのフラグを反転させて、Aurora MySQL を指すようにしました。

前述のメトリクスの最適な値を見つけられるかは、ユースケースと来たる変化の速度に左右されます。テストを複数回実行することでこれらの値を決定する必要があります。

次のグラフ例は、ValidationPendingOverallCount メトリクスを示しています。最初は保留中の行の数が多く、徐々に減少していることがわかります。

次のグラフ例は、CDCLatencySource メトリクスを示しています。これは、ソースデータベースからキャプチャされた最後のイベントと DMS インスタンスの現在のシステムタイムスタンプの間のギャップを秒単位で示しています。タスクスコーピングのためにソースから変更がキャプチャされなかった場合、DMS はこの値をゼロに設定します。

次のグラフ例は、CDCLatencyTarget メトリクスを示しています。これは、Aurora MySQL でコミットを待機している最初のイベントタイムスタンプと AWS DMS インスタンスの現在のタイムスタンプの間のギャップを秒単位で示しています。この値は、Aurora MySQL で処理されないトランザクションがある場合に発生します。それ以外の場合、すべてのトランザクションが適用されるなら、ターゲットのレイテンシーはソースのレイテンシーと同じです。ターゲットのレイテンシーは、ソースのレイテンシーよりも小さくしないでください。

ステップ 5

このステップでは、アプリケーションは Aurora MySQL を指しており、正常に機能しています。すべての機能が正常に動作することを確認するために、チームでアプリケーションをエンドツーエンドでテストしました。ロールバックセットアップを数日間実行してから停止しました。

最終状態

このステップでロールバックのセットアップを削除しました。次の図は、新しいアーキテクチャを示しています。

ロールバックステップ

このステップは、最悪のシナリオでのバックアッププランを立てることでした。データベースはミッションクリティカルなサービスの一部であるため、極めて悪いケースから回復するためのメカニズムを導入する必要がありました。

このデータベースを使用する必要が生じた場合、Aurora への書き込みトラフィックを停止し、保留中のレコードが検証されるのを待ってから、アプリケーションをロールバックデータベースに切り替えるように計画を立てました (SQL Server Always On)。このようにして、データを失うことなく古いセットアップに戻ることができました。

ロールバックのセットアップを検証するために十分なテストを実行することが重要です。テスト環境で本番規模のデータを使用してこれらのテストを実行し、アプリケーションが Aurora MySQL からロールバック DB を使用するように切り替えたときにデータの損失がないようにしました。

パフォーマンスの比較

読み取りクエリと書き込みクエリの両方について、移行前後の上位 10 件のクエリパフォーマンスを比較しました。

 

次のグラフは、上位 10 件の読み取りクエリのクエリパフォーマンスを示しています。Aurora のパフォーマンスが非常に優れていることがわかります。

次のグラフは、上位 10 の書き込みクエリのクエリパフォーマンスを示しています。Aurora MySQL は、書き込みクエリでも MSSQL よりも優れていました。実行時間は MSSQL よりもかなり短くなりました。

推奨事項

前のセクションで説明したアプローチに加えて、次の推奨事項を考えてみてください。

  • 多くのテスト実行を計画することで、データベースに適した移行戦略を考え出すことができます。万能の戦略はないため、独自の設定を考え出し、それに従って最適化します。
  • 複数回のパフォーマンステストを実施して、SQL クエリを微調整します。データベースが異なると動作もさまざまです。
  • 可能な限り最大限に移行プロセスを自動化します。Terraform を使用して自動化したため、テストの実行を複数回すばやく繰り返し、一貫した実行プロセスを思いつくことができました。
  • 考えられるすべてのアラートを設定し、十分なモニタリングを行って移行プロセスを分析します。
  • 予期しないエラーを処理するのに十分な時間を与えるには、少なくともスケジュールされたカットオーバーの 1 日前にデータベース切り替えポイント (移行ステップのステップ 4) に到達することが理想的です。

まとめ

異なるデータベース間の移行は必ずしも容易ではありませんが、AWS DMS と適切な計画を立てたことで、Autodesk は SQL Server から Aurora MySQL へのスムーズな移行を実現しました。当社は現在、運用効率を大幅に高め、コストとパフォーマンスが最適化されたインフラストラクチャを備えています。

Autodesk や他社が Amazon Aurora MySQL で経験した利点を踏まえて、変革を受け入れ、インフラストラクチャを近代化するための計画について何か考えていらっしゃいますか?

 

著者について

 

Tulika Shrivastava 氏は、Autodesk のソフトウェアアーキテクトです。彼女はシドニーに住んでおり、Autodesk のシングルサインオンサービスをリードしています。彼女は、特に AWS で、スケーラブルで可用性の高い製品とサービスを設計して構築する実務経験を積んでいます。

 

 

 

Rama Thamman は、AWS R&D およびイノベーションソリューションアーキテクチャチームの R&D マネージャーです。彼はお客様と協力して、AI/ML、ロボティクス、AR VR、IoT、衛星、およびブロックチェーンの分野で革新的なプロトタイプを構築しています。