TiDB導入を検討したが見送った話
こんにちは!
株式会社ココナラのシステムプラットフォーム部でインフラ・SREチームに所属のぐっさんです。
少し前にTiDBをココナラに導入できないか、比較検討をしたのでその時のお話を紹介したいと思います。
はじめに
現在ココナラではデータベースは主にAmazon Aurora MySQLを利用しています。
Aurora MySQLはマネージドで非常に便利なサービスですが、定期的にアップデートを実施する必要があります。
アップデートの作業では万全を期すため、サイトメンテナンスを入れて作業を行っています。
メンテナンスに際しては、可能な限り短時間で作業を行うための工夫として Blue/Green Deploy を用いています。
更なるユーザー体験向上に向け、なるべくサイトメンテナンスは行わずアップデートが行えないかインフラの観点で検討することとなりました。
その対策の一つとして、最近話題の分散型NewSQLデータベースであるTiDBの導入を検討しました。
また、同時にAmazon RDS Proxyも検討対象として挙がり、比較検討の結果こちらを採択することとなったのですが、RDS Proxyについてはまたの機会にご紹介できたらと思います。
TiDBとは
検討の詳細に入る前に、TiDBについて生成AIに聞いてみました。
TiDBの概要
TiDBはPingCAP社が開発したオープンソースの分散型NewSQLデータベースです。
特にMySQLと高い互換性を持ちつつも、分散型アーキテクチャによって高い拡張性と可用性を実現しています。TiDBの主な特徴
水平スケーラビリティ（Horizontal Scalability）
- ノード（サーバー）を追加するだけで、データ容量やトランザクション処理能力を容易に拡張できます。
- クラウド環境での柔軟な運用に適しています。
高可用性（High Availability）
- データが複数ノード間で自動的に冗長化されており、障害時には自動的にフェイルオーバーや復旧が行われます。
- 計画外ダウンタイムを最小限に抑え、安定したサービス提供を可能にします。
MySQLとの高い互換性
- SQL構文やプロトコルがMySQLと高い互換性を持っているため、既存のMySQLベースのアプリケーションを大幅に変更することなく移行可能です。
リアルタイム分析（HTAP）
- トランザクション処理（OLTP）と分析処理（OLAP）を単一データベース上で行えるHTAP（Hybrid Transactional and Analytical Processing）をサポートしています。
- リアルタイムでの意思決定やデータ活用を可能にします。
これらの特性から、TiDBはスケーラブルなWebサービスや、リアルタイム分析が求められるアプリケーションに適したデータベースと言えます。
TiDB導入を検討した理由
Aurora MySQLは高性能かつ運用が簡単ですが、潜在的なものも含め以下のような課題がありました。
- 定期的なDBメンテナンスによるサイトのメンテナンス
- AZ障害が発生した際のサービス影響
- サービスのグロースに伴う、DBスケールアップのタイミングでメンテナンスの発生
これらの課題を解決しうるソリューションとしてTiDBは非常に魅力的でした。
特に特徴に上がっている 高可用性（High Availability） の強みが、課題解決に繋がるのではと期待していました。
また、現在利用しているのがAurora MySQLであることから、いくつかあるNewSQLデータベースの中からMySQL互換であるTiDBに絞って検討を行いました。
比較検討で行ったこと
今回の検討ではAmazon RDS Proxyを含めた評価を主に机上で実施しました。
とはいっても、闇雲に比較検討する訳にもいかないのでQCDの考えをベースに、ひとまず関連する比較ポイントの洗い出しを行いました。
実際に比較検討したときの表(抜粋)
実際に比較したポイントの例を幾つか紹介します。
Quality（品質）の観点
- 可用性: 障害発生時の影響や、メンテナンス作業時の影響
- ライフサイクル: メンテナンスのサイクルやサポート期間
- スケーラビリティ: スケールアップ、スケールアウトの限界や効果
Cost（コスト）
- メンテナンスコスト: メンテナンスの準備にかかる総工数含めたコスト
- インフラ費用: ランニングコスト
- 人件費: 主に学習コスト
Delivery（納期）
- 導入検証期間: 準備も含めた検証に係る期間の長さや難易度
- 移行期間: 移行開始してから移行完了に係る期間の長さや難易度
検証の結果と課題
TiDBは魅力的なメリットが多く、当初は積極的に導入を検討しました。
しかし、机上での検討を進める中で以下のような課題が明らかになりました。
- Aurora MySQLからTiDBへの移行に伴う互換性の検証コスト
- パフォーマンス周りの検証コスト
- アプリケーションコードの修正が発生する可能性
- インフラの変更と運用方法の再設計に必要な工数
リソースが限られている中で、これらの検証や移行作業に要する工数が導入に向けた一番の課題であることが見えてきました。
ここでTiDBについてもう少し踏み込んだ話をすると、TiDBはMySQL互換のデータベースですが以下で図示しているように設計思想やアーキテクチャが全く異なっています。
Aurora MySQLクラスター概略図
TiDBクラスター概略図
結果、TiDBは高いスケーラビリティと高可用性を実現しているのですが、既存のワークロードにどのような影響を及ぼすかについては、実際に動かして一つ一つ確かめる必要があります。
結論
TiDBはNewSQLデータベースとしては珍しいMySQL互換のデータベースであり、MySQLを利用している環境から移行を目指す場合に現実的な選択肢になるデータベースです。
ですが、MySQL互換といってもあくまでのクエリ周りの互換性に限られ、実態としては従来のRDBMSとは全く異なるアーキテクチャで動作しているため、事前の検証を入念に行う必要があります。
その結果、導入することで得られるメリットよりも導入にかかるコストが大きくなってしまうことから、タイミングとしては時期尚早と判断し、現時点でのTiDB導入は見送ることとなりました。
ただし、製品としては魅力的な部分も大きいので、今後のサービスの成長や要件の変化次第では再検討の余地は十分にあると考えています。
さいごに
こういった題材にしては比較的珍しい導入を見送ったケースの紹介となりましたが、新しい技術やサービスを検討する際には、そのメリットだけでなく、導入や移行に伴うコストやリスクも慎重に検討する必要があります。
特に比較的新しい技術に関してはその技術のナレッジが少ない傾向にあるため、「技術の特性が目的にマッチしているか」「動作周りに問題がないか」のように気をつけるべきポイントを洗い出した上でしっかり見極める必要があると考えています。
今回の経験が、他の方々がデータベース移行や新技術導入を検討する際の参考になれば幸いです。
ココナラでは絶賛エンジニアを募集しています。
少しでも興味を持たれた方がいましたら、ぜひ下記の採用ページをご覧ください。
採用情報はこちら。
カジュアル面談希望の方はこちら。
Discussion