分散型SQLの導入を加速：Plaid社が1年で41のサービスをAmazon Auroraから移行した方法

※このブログは2024年11月22日に公開された英語ブログ「Accelerating Distributed SQL Adoption: How Plaid Migrated 41 Services from Amazon Aurora in One Year」の拙訳です。

Plaid社は、アプリケーションがユーザーの銀行口座と接続できるデータ転送ネットワークを構築する金融サービス企業です。HTAP Summit 2024では、Plaid社の経験豊富なソフトウェアエンジニアであるZander Hill氏と、エンジニアリングマネージャーのAndrew Chen氏が、Amazon Auroraから分散型SQLデータベースへの意欲的な移行プロジェクトについて詳しく語りました。

このブログでは、彼らの基調講演からの主なポイントを振り返ります。Plaid社が移行を決断した理由、直面した課題、そして分散型SQLを採用したことで得られたメリットについて探ります。

変革の必要性：Plaid社が直面したデータベースのスケーリング課題

Plaid社は膨大な量の機密データを扱っており、堅牢でスケーラブルかつ高可用性を備えたデータベースインフラが必要不可欠です。当初、同社はAmazon Auroraを利用しており、データ集約型のワークロードを支えるために800台以上のデータベースサーバーを管理していました。しかし、インフラ全体で1秒あたり50万件を超えるクエリ (QPS) を処理する規模に成長するにつれて、システムには限界が見え始めました。

Hill氏は、300以上のMySQLクラスタを管理することが次第に負担となり、特にアップグレードやスケーリング作業を行う際に課題が顕著になったと説明しました。Plaid社のチームは、データベースのパフォーマンスを維持するために多大なエンジニアリングリソースを割かなければならず、特にAmazon Auroraが書き込みスループットやスケーラビリティの限界に近づく中で、その負担はさらに増大しました。また、2～10テラバイト (TB) に及ぶ大規模なテーブルでオンラインスキーマ変更ができないことが開発を遅らせ、エンジニアリングの生産性に影響を与えていました。

HTAP Summit 2024の基調講演に登壇したPlaid社の経験豊富なソフトウェアエンジニア、Zander Hill氏

Plaid社が直面した主な課題は以下の通りです：

• データベースのスケーラビリティの限界：Amazon Auroraでは書き込み操作を効率的にスケールできず、パフォーマンスのボトルネックが発生していました。
• 高いメンテナンス負担：データベースのメンテナンスに多大な時間を要し、アップグレードには最大6カ月ものエンジニアリング作業が必要でした。
• 開発速度の低下：スキーマ変更に時間がかかり、機能リリースの遅延を招き、顧客満足度にも影響を与えていました。

適切なAmazon Auroraの代替案の模索

Plaid社が分散SQLへの移行を決断したのは、以下の3つの主要な目標を達成するためでした：大規模な信頼性の向上、開発者の生産性向上、そしてメンテナンス負担の軽減です。Google Spannerなどの有力な代替案を評価した結果、Plaid社はTiDBを選択しました。この高度な分散SQLデータベースは、MySQL互換性、水平スケーラビリティ、およびパフォーマンスを損なうことなく分散トランザクションをサポートする能力を備えています。

Chen氏によると、TiDBの分散SQLアーキテクチャはスムーズな水平スケーリングを可能にします。これにより、Plaid社はシステムを停止することなく、予測不能な需要の急増にも対応できるようになりました。また、TiDBはオンラインスキーマ変更をサポートしており、これにより開発者はパフォーマンスに影響を与えることなく大規模なテーブルを変更することが可能です。これらの機能はPlaid社が抱えていた重大な課題を解決し、明確な改善の道を提供しました。

HTAP Summit 2024の基調講演に登壇したPlaid社のエンジニアリング・マネージャー、Andrew Chen氏

Plaid社がTiDBを選んだ主な理由は以下の通りです：

• ゼロダウンタイムでのスケーリング：TiDBは中断のないスケーリングと自動フェイルオーバーを提供し、Plaid社のミッションクリティカルなワークロードに欠かせない機能を実現しました。
• MySQL互換性：TiDBは、既存システムとのスムーズな統合を可能にし、大規模なコードの書き換えを必要としませんでした。
• 分散トランザクション：TiDBは分散環境で一貫性があり信頼性の高いパフォーマンスを提供しました。

Plaid社のAmazon Aurora代替への移行

Plaid社は、Amazon AuroraからTiDBへの移行を2023年初頭に開始し、2025年半ばまでに完全移行を完了する予定です。移行リスクを最小限に抑えるため、非クリティカルなサービスから始め、高スループットを必要とするアプリケーションへ段階的に移行するアプローチを採用しました。

移行における主なステップは以下の通りです：

1. 互換性問題の特定：移行前に、主キー、外部キー、オートインクリメントIDなどの一般的な互換性の問題を修正することに注力しました。
2. データ同期：TiDB LightningやTiCDCといったツールを活用し、Amazon AuroraとTiDB間でデータを同期させ、移行中の一貫性を確保しました。
3. 検証とテスト：ブルーグリーンレッドデプロイメント戦略を用い、TiDBへの完全移行前にパフォーマンスや正確性を検証しました。

Plaid社は、トラフィックをAmazon AuroraからTiDBにスムーズに切り替えるため、機能フラグを利用してダウンタイムを最小限に抑えました。このプロセスにより、顧客に一切のサービス中断を感じさせることなく移行を進めることができました。移行におけるいくつかの課題がありました。

• クエリのパフォーマンス問題：Amazon Aurora向けに最適化された一部のクエリは、TiDBで効率的に動作するよう調整が必要でした。
• ツールとエコシステムの課題：バイナリ主キーやタイムスタンプ列に関連するオープンソースツールの問題に直面し、これを解決するためにTiDBのサポートチームと密接に協力しました。

Plaid社の成果 データベースのスケーラビリティと効率の向上

Plaid社はTiDBを採用して以来、システム性能と運用効率において目覚ましい改善が見られました。スケーリングや構成変更などのメンテナンス作業をサービスを停止することなく実行できるようになったため、稼働時間の向上とレイテンシの短縮につながっています。

主な利点は以下の通りです。

• メンテナンス作業の軽減：TiDBへの移行により運用負荷が軽減され、エンジニアリングリソースを技術革新に集中させることができました。
• 稼働率の向上：メンテナンス作業が中断を伴わなくなり、ほとんどのアップグレードでダウンタイムがゼロになりました。
• コスト削減：複数のMySQLクラスタの管理コストを削減することで、システムの信頼性を向上させながらコスト効率を実現しました。

Hill氏とChen氏は、TiDBのマルチテナント機能によって、Plaid社がリソース使用率を最適化できたことも共有しました。これにより、ワークロードが効果的に分離され、ノイジー・ネイバーがパフォーマンスに影響を与えるのを防ぐことができました。

まとめ：Amazon Auroraに代わる選択肢で、将来を見据えた拡張を

Plaid社のTiDB導入事例は、最新のSaaSアプリケーションのスケーリングにおいて、分散SQLデータベースを採用することによる変革の力を示しています。Amazon Auroraの制約から脱却し、TiDBの分散SQLアーキテクチャを採用することで、Plaid社はスケーラビリティの課題を克服し、開発者の生産性を向上させ、運用上の複雑さを軽減することができました。

TiDBはPlaid社のデータシステムの近代化を可能にし、高い可用性とパフォーマンスを維持しながら、同社の急速な成長をサポートできる体制を整えました。同様の課題に直面している組織にとって、TiDBはスケーラビリティ、信頼性、コスト効率のバランスの取れた理想的なAmazon Auroraの代替手段となります。Plaid社が残りのワークロードの移行を続ける中で、他の企業が分散SQLを使用してデータインフラストラクチャを将来にわたって活用する方法を示す強力な例となっています。

組織内での分散SQL採用を加速するためのさらなる戦略にご興味がありますか？イベントの基調講演全体をご視聴いただくための登録はこちらから。新しい発見が得られます。お楽しみください！