Amazon Web Services ブログ

Autodesk が Amazon Aurora を使用してデータベースのスケーラビリティを向上させ、レプリケーションラグを削減した方法

Autodesk は 3D 設計、エンジニアリング、エンターテイメントソフトウェアのリーダーです。Autodesk は物を作る人のためのソフトウェアを作成しています。高性能の車を運転したり、超高層ビルを見上げたり、スマートフォンを使用したり、偉大な映画を見たりしたことがある人は、何百万人もの Autodesk ユーザーがソフトウェアで行っていることを体験したことがあると思われます。

Autodesk は Amazon RDS で稼働するマネージド MySQL データベースと Amazon EC2 でホストされるセルフマネージド MySQL データベースの両方からAmazon Auroraに移行しました。このブログ記事は、その経験をまとめ、次の点について取り上げます。

  • Autodesk の Amazon Aurora への移行決定に影響を与えた要因
  • 移行上の特定の利点
  • 移行と最適化に関して学んだベストプラクティスと教訓

まず、クラウドで生まれた Autodesk Access Control Management (ACM) アプリケーションの移行パスを確認します。始めに Amazon RDS for MySQL を選択し、スケーラビリティ、可用性、およびパフォーマンスを向上させるために Aurora に移行しました。ACM が移行を問題なく完了させたことで、Autodesk の他のいくつかのアプリケーションが Aurora に移行する意欲が高まりました。EC2 でホストされているセルフマネージド MySQL データベースを Amazon Aurora に移行する主要な例として、BIM 360 Field Classic について説明します。

ACM アプリケーションのアーキテクチャと MySQL の課題

次の図は、ACM の初期アーキテクチャの高度な図式を示しています。アプリケーション層は、高可用性を維持するために複数のアベイラビリティゾーンにわたる EC2 インスタンスで構成されています。トラフィックは Elastic Load Balancing サービスを使用して配信されます。さらに、EC2 Auto Scaling を使用して、アプリケーションへのスパイクの多いトラフィックを処理する EC2 インスタンスの数を調整します。

このアーキテクチャにより、Autodesk はアプリケーションの拡張と負荷の分散を行うことができましたが、すぐにボトルネックがデータベースに転移しました。アプリケーションは、単一の RDS MySQL データベースインスタンスに接続され、利用可能なスケーリングオプションを制限しています。アプローチの 1 つは、データベースインスタンスのサイズを増やすことでした。このアプローチは、プロビジョニング可能なデータベースインスタンスの最大サイズによって制約されました。ACM はすぐに利用可能な最大のインスタンスの容量制限を超えました。

次の選択肢は、プライマリインスタンスから読み込みをオフロードするための RDS Read Replica インスタンスを追加することによって、データベース容量を水平方向に拡大することでした。Autodesk は、すべての ACM ユーザーに一貫性のある体験をしてもらうために、レプリケーションの遅延を 1 秒未満に保ちたいと考えました。Read Replica に関連付けられたレプリケーションラグは、プライマリおよび読み取りレプリカインスタンスのワークロードプレッシャーに依存します。(ここで言うレプリケーションラグは、書き込み操作が Read Replica に表示されるまでの時間のことです)。

Autodesk は、複数の MySQL データベースにまたがってデータを分割することで ACM を再構築するのではなく、レプリケーションラグを最小限に抑えるために、データベースに向けられた負荷を制限するアプリケーションを絞る必要がありました。このアプローチは持続可能ではありませんでした。なぜなら、ACM の採用は課された制限によって大幅に制約されたからです。この影響により、Autodesk は Amazon Aurora などの代替案を検討することになりました。

Amazon Aurora による救助

Autodesk が Aurora を評価する上で優先したのは、次の点です。

  • パフォーマンスの向上
  • 読み取りスケーリングのための低遅延レプリケーション
  • MySQL との完全な互換性 (リフトアンドシフト移行)
  • 自動ストレージスケーリング

Aurora は、標準的な MySQL データベースのスループットを最大 5 倍まで向上させます。パフォーマンスが向上したことで、Autodesk がアプリケーションを変更せずに MySQL で導入されたスロットリング制限を取り除き、将来の成長のために十分な余裕を持てます。Aurora が提供する、分散型のフォールトトレラントな自己修復ストレージシステムは、最大 64 テラバイトまで自動的に拡張され、データベースストレージを手動でスケーリングする必要がありません。最大 15 個の低レイテンシーの Aurora Replicas は、可用性を向上させ、100 ミリ秒以下の典型的なレプリケーションの遅れを抑えて読み取りスケーリングを行うことができます。

Autodesk は Aurora Replicas を使用してプライマリインスタンスから読み込みをオフロードし、スケールを水平に読み込みました。さらに、高速クローニング、ポイントインタイムリカバリ、Amazon S3 への継続的バックアップ、および 3 つの Availability Zones にわたるレプリケーションにより、Aurora は Autodesk がオペレーショナルオーバーヘッドをさらに削減することを可能にしました。

次の図は、Aurora に移行した後の ACM アプリケーションのアーキテクチャを示しています。

このアーキテクチャでは、Aurora クラスターには 1 つのライターインスタンスと最大 4 つの Aurora Replicas が含まれています。Aurora Auto Scaling を有効にして、CPU 使用率に基づいて Aurora Replicas の数を自動的に調整しました。

データベースのパフォーマンスは、Aurora に移行した後の期待値を上回りました。Autodesk は、アプリケーションのスケーラビリティが 20 倍向上し、アプリケーションの応答時間が 2 倍改善され、Aurora は 7 倍のデータベース接続をサポートできることを確認しました。移行の特筆すべき点は、同様のサイズのデータ​​ベースインスタンスで CPU 使用率が 10 倍に低下し、ACM が拡張するにつれデータベースが成長するのに十分な余裕が残っていたことです。移行の前後に、MySQL と Amazon Aurora の比較チャートをいくつかキャプチャし、これらの改善点を強調しました。

Autodesk は、CPU 使用率がピーク時に MySQL で 100% だったのが、Amazon Aurora で 10% 未満となり、10 倍削減することができました。次の図は、移行前後の CPU 使用率を示しています。

MySQL

Aurola

次の図は、移行前後のアプリケーションの応答時間を示しています。

Autodesk は、応答時間を 2 倍向上させることができました。

MySQL

Aurola

移行プロセスと学んだ教訓について深く掘り下げてみましょう。

移行のベストプラクティスと学んだ教訓

Autodesk は Amazon Aurora への移行をサポートするためにAWS Professional Service を利用しました。以下は、AWS Well-Architected フレームワークの 5 つの柱によって分類されるすべての考慮事項とベストプラクティスをまとめたものです：

信頼性

  • テストと検証: パフォーマンスの向上と、将来のスケーラビリティを担保するため、1 台の Aurora ライターと 4 台の Aurora Replica を使用して通常のトラフィックの 5 倍のステージング環境で負荷テストを実施しました。テストの結果、持続的に負荷がかかっても CPU 使用率が 10% を下回っていることが確認されました。アプリケーションのレイテンシーも必要条件を超えるものでした。Aurola は、Aurola クラスターで最大 15 個の Aurora Replicas をサポートします。最大 4 つの Aurora Replicas しか使用していないため、Aurora Replicas を追加することにより、読み込みを拡大するのに十分な余裕があります。Aurola は最大 64 テラバイトの記憶容量を自動的に拡張できます。ACM データベースはおよそ 1 テラバイトと見積もられ、ストレージの拡張に十分な余裕があります。
  • マルチ AZ 配置： 可用性を向上させ、フェイルオーバーを高速化するために、異なる Availability Zone (AZ) に Aurora Replicas を作成しました。Aurora Replica には、2 つの目的があります。1 つ目はプライマリインスタンスのフェイルオーバーターゲットとして機能させること、そして 2 つ目はプライマリインスタンスと同じ記憶域を共有するため、レイテンシーの低い読み取りをオフロードすることです。プライマリインスタンスが使用できなくなった場合、Aurora Replicas が昇格されるオーダーを指定するために、Aurora Replicas ごとにフェイルオーバー優先順位を設定します。Aurora ストレージは 3 つの Availability Zones に 6 つのデータコピーを保持し、数百のストレージノードに分散されています。この機能は、万が一 AZ 全体の接続が失われたような場合でも、完全な読み書きが行えるようにするのに役立ちます。
  • 負荷の分散: リーダーエンドポイントに接続することで、Aurora は DB クラスター内のレプリカ間で接続の負荷を分散させることができます。このアプローチは、読み取りワークロードを分散させるのに役立ち、パフォーマンスの向上と各レプリカで使用可能なリソースのより公平な使用につながります。ACM データベースのワークロードは読み取りの負荷が高く、ワークロードの約 90% が読み取りで占められていました。4 つの Aurora Replicas を設定したことで、読み取りのワークロードをオフロードし、レプリカに分散することができました。同時に、Aurora Replicas を使いやすくするために、アプリケーションの接続プールサイズを増やしました。
  • 移行中の共存: 最初の移行中に、安全なロールバックのために Aurora と RDS の間でレプリケーションも設定しました。プロダクションの切り替えが完了してから 1 週間後、十分な自信を得てもはや代替環境は必要ないと判断し、その時点でレプリケーションを終了することにしました。MySQL binlog ベースのレプリケーションでは、パフォーマンス重視で書き込みパフォーマンスが低下する可能性があります。操作上の理由から必要でない限り、binlog をオフにすることをお勧めします。
  • 耐久性と災害対策 (DR): Aurora は 3 つの Availability Zones にまたがって 6 つのデータコピーを保持し、S3 のデータを継続的にバックアップします。DR については、リージョン間の読み取りレプリカ Aurora クラスターを別の AWS リージョンに追加し、ステージング環境での災害復旧訓練をシミュレートして、大規模な災害にあっても運用の準備ができるようにしました。

パフォーマンス効率

  • 適正なサイジング: パフォーマンス上の利点を得るための最適なコストについては、異なるインスタンスタイプの負荷テストを実行し、r3.8xlarge を選択しました。また、Aurora へ移行することで達成されたパフォーマンス向上の感覚を得るために、MySQL に対する負荷テストの結果をベンチマークしました。書き込みと読み取りの両方を行うためにプライマリインスタンスをオーバープロビジョニングする代わりに、主に書き込みを処理するプライマリインスタンスのサイズを調整しました。Aurora Replicas を追加して読み取りパフォーマンスをスケールアウトしました。
  • オプションの最適化: 通常は必要ではありませんが、利用可能な MySQL パラメータを使用してクエリの実行を最適化することができます。たとえば、繰り返しの読み取りでパフォーマンスを確保するために、クエリキャッシュサイズを増やしました。また、長時間実行されるクエリを監視し、トランザクションの長さを短縮しました。MySQL のパラメータの詳細については、MySQLリファレンスマニュアルをご覧ください。

優れた運用効率

  • パフォーマンスの最適化: 5 秒間隔で Aurora クラスターの監視を強化し、長時間実行されるクエリを探しました。さらに、週ごとのジョブのスケジューリングを行い、新しい統計情報を収集しました。これにより、トランザクションの処理時間を短縮し、長時間実行されるクエリを削減することができました。
  • 継続監視: Aurora クラスターの重要なメトリックとアプリケーションのメトリックの可視性を維持するために、Amazon CloudWatch 用のダッシュボードを作成しました。デフォルトでは、プライマリインスタンスと Aurora Replicas 間のレプリケーションラグ値を表す AuroraReplicaLag メトリックが毎分 CloudWatch に発行されます。毎秒この値を収集するカスタム CloudWatch メトリックを設定して、レプリケーションラグをより詳細に把握し続けられるようにしました。また、CPU 使用率、メモリ使用率、DML と DDL クエリの待ち時間とスループット、バッファキャッシュヒット率などの重要なメトリックのイベントサブスクリプションとアラームも作成しました。さらに、Amazon SNS を使用して、担当グループに自動的にイベント通知を行うように設定しました。
  • 構築の自動化: AWS CloudFormation テンプレートを使用して、Aurola クラスターをプロビジョニングし、Aurora Replicas を自動スケーリングしました。これにより、新しいスタックをプロビジョニングする時間が大幅に短縮されました。この自動化を基盤に、ゼロダウンタイムのアップグレードとリリース管理のためのブルー/グリーンアーキテクチャをデプロイしました。

セキュリティ

Amazon VPC サービスで Aurola クラスターをセットアップし、Aurola クラスターへのアクセスを隔離するようにセキュリティグループを設定しました。Aurora では暗号化を有効にしてデータを安全に保護しました。Aurora で暗号化を有効にすると、バックアップとスナップショットが自動的に暗号化されます。さらに、Aurora インスタンスとの Secure Socket Layer (SSL) 接続を使用するようにアプリケーションを設定しました。

コストの最適化

新しい環境でのアプリケーション負荷の不確実性のため、Aurola クラスターに 4 つの r3.8xlarge Aurora Replicas をオーバープロビジョニングすることにしました。移行が完了した後も、CloudWatch メトリックを使用してデータベースのパフォーマンスと使用率を監視し続けました。新しいシステムの安定性に十分な自信が持てたとき、収集したメトリックを使用して環境を適切なサイズにしました。その一環として、Aurora Replicas の使用率を最適化するために、CPU 使用率に基づいて Aurola を設定しました。今では、ワークロードに応じて、Aurola クラスターは 1 つのプライマリインスタンスで構成され、最大 4 つの Aurora Replicas インスタンスをスケールできます。

さて、次は何でしょう?

Autodesk ACM データベースの移行が完了し、移行後のパフォーマンスが大幅に向上したため、Autodesk は複数のアプリケーションにわたって Amazon Aurora を採用し始めました。BIM 360 Field チームが実施した移行作業は、セルフマネージド MySQL データベースを Amazon Aurora に移行した素晴らしい例です。

BIM 360 Field Classic

Autodesk は、ACM の移行が無事完了した後、AWS Professional Services を利用して別の移行を実施しました。ここでは、BIM 360 Field Classic アプリケーション用の Amazon EC2 でホストされているセルフマネージド 6 ノード MySQL のセットアップを Amazon Aurora に移行しました。MySQL のセットアップには、1 つのマスターライターと 5 つの読み取りレプリカがありました。BIM 360 Field 環境を評価したところ、以下の結果が得られました：

  1. AWS BIM 360 Field アプリケーションデータベースは、およそ 2 テラバイトのデータを保持します。
  2. 高可用性とフェイルオーバーは、アプリケーションとデータベースの間にあるミドルウェア層によって管理されます。
  3. フェイルオーバーアプリケーションは EC2 でホストされています。
  4. Aurora Replicas は、MySQL の binlog ベースのレプリケーションを介してマスターと接続され、10 秒以内にフェイルオーバーを達成するフェイルオーバーターゲットとしても機能します。
  5. アプリケーションは、各レプリカが設定されているポート番号に基づいて、5 つのノードすべてにクエリを手動でルーティングします。
  6. バックアップは日々行う Percona XtraBackup と MySQLDump スクリプトの実行によって設定します。EC2 インスタンスレベルのスナップショットも、インスタンスレベルの復旧用にスクリプト化されています。

この構成は BIM 360 Field Classic でも機能しましたが、Autodesk では EC2 インスタンスレベルのバックアップからデータベースのバックアップまで、幅広い領域を管理する必要がありました。その一環として、データベースの高可用性を確保し、フェイルオーバーアプリケーションの障害回復戦略を実装することが重要でした。また、Autodesk は、アプリケーションのコードを管理してクエリの負荷を分散し、論理的 binlog レプリケーションのデータ整合性を維持する必要がありました。これらの操作は実行可能ですが、規模が大きくなく、かなりのリソースと計画が必要です。これらの機能をすぐにサポートする Amazon Aurora に移行することにより、高可用性、フェイルオーバー、およびロードバランシングのメカニズムを自動化および簡素化しました。

Aurola への移行

Amazon Aurora Migration Handbook とは異なる移行方法を評価し、この移行にオープンソースツール Mydumper を使用して論理バックアップのアプローチを選択しました。r4.16xlarge インスタンスとの全体的なデータ転送プロセスを並列化することで、移行が高速化されます。

コストをさらに最適化し、いくつかの Autodesk アプリケーションの追加要件を満たすために、以下のことを行いました。

  1. Aurora Auto Scaling を有効にして、CPU 使用率に基づいて Aurora Replicas の数を自動的に調整すること。複数のレプリカを連続して実行する代わりに、必要なときにレプリカを追加することでコストを削減しています。
  2. すべての Aurora クラスターで、Aurora 用スナップショットツールをデプロイして、AWS リージョン間のスナップショットのコピーを自動化し、35 日以上 Aurora スナップショットを保持するようにしました。これは、目標復旧時間 (RPO) と復旧時間目標 (RTO) の両方で Autodesk の要件を満たすために行いました。スナップショットツールは、AWS Lambda や AWS Step 関数など、AWS エコシステム内のいくつかの AWS のサービスを使用して、AWS リージョンとアカウント間のスナップショットコピープロセスを自動化します。
  3. Amazon Aurora Audit イベントの CloudWatch Logs を有効にして、監査ログを CloudWatch ログに公開し、CloudWatch メトリックとアラームを作成して Aurora DB クラスターのアクティビティを継続的に監視しました。

結論

Amazon Aurora を使用することで、ACM と BIM 360 Field Classic の両方のアプリケーションのスケーラビリティを向上させ、アプリケーションのパフォーマンスを向上させ、管理オーバーヘッドを削減し、コストを最適化できました。

「ACM データベースはおよそ 1 テラバイトで、いくつかのテーブルの行数は 10 億行を超えています。ピーク時には 1 分間に 25,000〜30,000 件のリクエストを受け付けます」と、Autodesk のシニアエンジニアリングマネージャー、Krishna Kumar 氏は述べています。「アプリケーションを 100 倍拡張させる戦略を構築しています。Aurola は ACM のロードマップの重要な部分を占めており、Aurola によりこれらのスケーリングの課題を解決するための能力が備わると感じています」

ACM の Aurora への移行が成功したことで、複数の Autodesk チームが Aurora の高性能、スケーラビリティ、可用性を活用するための全体的な道筋が示されました。Autodesk では Aurora への移行戦略を正式化し、最新の例としては BIM 360 Field Classic など、いくつものアプリケーションスタックを移動させて Aurora の使用を開始するために積極的に取り組んでいます。

著者について

Piyush Patel は、AWS Professional Services のシニアビッグデータコンサルタントです。 彼は、AWS の使用時にお客様のソリューションの価値を向上させるため AWS のカスタマーと協力してビッグデータベースおよび解析プロジェクト関連の指導や技術支援を行っています。

 

 

 

 

Akm Raziul Islamは アマゾン ウェブ サービスのデータベースと解析を担当するコンサルタントです。 彼は、AWS の使用時にカスタマーのソリューションの価値を向上させるため AWS のカスタマーと協力して様々なデータベースおよび分析プロジェクト関連の指導や技術支援を行っています。
 

Chayan Biswas は、アマゾン ウェブ サービスのプロダクトマネージャーです。

 

 

 

 

altaltKrishna Kumar は、Autodesk の核となる基礎的なクラウドサービスの複数の分野を担当するシニアエンジニアリングマネージャーです。 彼は何年もの間、複数のテクノロジーとドメイン分野でチームを組み、統率してきました。信頼性の高い安定性とパフォーマンスを備えたスケーラビリティの高いアプリケーションの構築に情熱を注いでいます。