Orbがデジタル通貨決済システムの基盤にNewSQLのTiDBを採用。ETLをなくし、トランザクション処理とデータ分析を統合可能に［PR］
今回は「Orbがデジタル通貨決済システムの基盤にNewSQLのTiDBを採用。ETLをなくし、トランザクション処理とデータ分析を統合可能に［PR］」についてご紹介します。
関連ワード （内部、本番環境、都内等） についても参考にしながら、ぜひ本記事について議論していってくださいね。
本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。
株式会社Orbは企業や自治体が独自のデジタル通貨システムを構築するときに有用なAPI型ミドルウェア「Orb DLT」の開発と提供をしている企業です。2019年にリリースした「Orb DLT」は、デジタル地域通貨の基盤として累計で82の自治体が採用しています。
Orb DLTは決済周辺のトランザクション管理に特化した分散台帳技術であり、Orb DLTを導入することでデジタル通貨決済システム基盤の開発やメンテナンスで工数削減が期待できます。
Orbは、それまでデータベース基盤に採用していたNoSQLデータベースのCassandraとリレーショナルデータベースのMySQLを、スケーラブルなSQLデータベースであるNewSQLのTiDBに統合し移行することに成功しました。
これにより、分散台帳技術の基盤にもTiDBのスケーラビリティが対応でき、また同社が抱えていたETLの課題を解決できることが示されたのです。
同社が抱えていた課題とはどのようなもので、その解決策としてなぜTiDBが採用されたのか。今年（2024年）7月に都内で行われた「TiDB User Day 2024」のセッション「デジタル通貨に特化した 独自分散台帳技術Orb DLTの高度化」で、同社CTO 岸本吉勝氏が紹介しています。
そのセッションの内容をダイジェストで紹介しましょう。
MySQLのバージョンアップが困難で新DBを模索へ
Orb DLTのアーキテクチャでは、リクエストはAPI Serverの「Nexus」とLogic Serverの「Core」を通じて最終的にData Handle Serverの「Appollo」に渡されます。
このApolloはCassandraを用いて構築されており、Cassandraからは4つのソフトウェアコンポーネントからなるETLを通じてMySQLへ決済履歴などのレポートデータを格納しています。
そしてこのMySQLをバージョン5からバージョン8へ移行しようとしたところ、JSON関連の問題で移行は困難だということが分かりました。
また以前から4つのソフトウェアコンポーネントからなるETLの障害点の多さも課題となっていました。
そこで、この機会に新たなデータベースの採用を模索し、着目したのがTiDBです。
TiDBはMySQL互換であるためMySQLを代替できるだけでなく、Cassandraが処理していた部分までカバーできそうだということで、検討と検証が始まりました。
Orb DLTの4つの条件を満たすこと
Orb DLTに採用する際にTiDBが満たすべき要件として、トランザクションを安全かつ高並列に実行可能であること、非中央管理型であること、可用性、分散性能の向上および維持も外せません。
調査の結果、TiDBであればData Handle ServerのApolloが担っていたトランザクション処理にも強みを活かすことができて、非中央管理型もNewSQLとしてのTiDBが備える強整合性およびオンラインでのスケールアウト、スケールイン可能なスケーラビリティで担保できそうです。
可用性についても同様で、TiDB CloudにはマルチAZや分散アーキテクチャによる耐障害性があり、サービスに影響を与えることなくTiDBのバージョンアップやスケールアップやスケールアウトを実施できると期待できます。
岸本氏はTiDBのこれらの機能を念頭に「TiDBに移行しても、Orb DLTとして必要な要件を満たすことができると判断しました」と言います。
データ移行における懸念点
続いて、CassandraとMySQLからTiDBへの移行について。
あるお客様の総レコード数は約6億。しかもJSON形式で保存しているカラムも多くあり、CassandraのあるJSON形式のカラムは2MB超となっています。これらのデータ移行ができるかどうかが懸念の1つでした。
またサービスの性質上、移行にかかるサービス停止時間も長く取ることができません。移行時のサービスへの影響も懸念点でした。
具体的なデータ移行は次のように実行しました。
新規に追加されるデータあるいは更新されるデータに関しては、デュアルライト方式で同期します。つまり既存のCassandraとMySQLに書き込むと同時に、データ変換を行いつつTiDBへの書き込みも行います。
すでにMySQLとCassandraに格納されているデータに関しては、本番環境とは別の環境にスナップショットを作成し、独自に開発したマイグレーションスクリプトでデータ変換を行いつつTiDBに書き込みます。
データ移行後には、正しくデータが同期できているかを確認するスクリプトを実行し、データの整合性も担保します。
データ移行後、3時間でTiDBへ切り替えが完了
このような移行作業において、いくつかの課題も浮上しました。
まず、マイグレーションスクリプトを用いてTiDBに2000QPS（秒間2000クエリ）でデータを追加しようとしたところ、TiDB内部でデータを保存するコンポーネントであるTiKVに性能劣化が見られました。
原因を調べてみると、前述のCassandraのあるカラムに保存された2MB超のデータの格納処理に時間がかかっていました。そこで処理速度を500QPSに落とすことで動作が安定しました。
もう1つの課題は、将来的なディスクスペースが枯渇する可能性でした。
TiKVは1ノード当たりのディスクスペースは4TBまでが推奨とされています。今後TiDBに格納するデータが増えた場合、追加ノードが必要になってしまいます（注：2024年11月時点において、TiDB Cloudでは32 vCPU、128 GiBの高性能なTiKVノードでは4TBを超える6144 GiBのディスクが利用可能です）。
そこでマイグレーションスクリプトでデータ変換だけでなく冗長なデータの整理や削減も実行するようにしました。
6億レコードのデータ移行にかかった期間は、設計から移行開始までが2カ月。データ移行を開始してから完了してTiDBへの切り替えが可能となるまで10日でした。
10日の内訳は、マイグレーションスクリプトの実行によるデータ移行が6日、データの整合性チェックのスクリプト実行が4日です。これ以後、CassandraとMySQL、そしてTiDBはずっとデータ同期している状態でした。
そしてTiDBへの切り替え作業は余裕を持って3時間でした。
ETLを排除しTiDBの一本化に成功
TiDBへの移行は、期待通りのことも、期待通りではなかったこともありました。
期待通りだったのは当初の課題が解決できたことです。つまりTiDBに一本化してETLを排除できたので、ETLで発生していた遅延もなくなりました。
オンラインでのスケールアップやスケールアウト、TiDBノーコード開発ツールバージョンアップについても、サービスに影響なく実施できました。
実際に5月には本番環境でTiDBのバージョンアップを実施したところ、ノーエラーでバージョンアップが完了しました。スケールアップやスケールアウトについてもノーエラーで実施できました。
性能劣化の原因分析とTiDB導入のアドバイス
期待通りではなかったのはいくつかの性能に関してです。
想定通りの性能は出せましたが、サーバのリソースが逼迫する状況になるとTiDB全体で性能劣化が起きることが分かりました。
これは想定していたより顕著でした。
リリース後にやや重いSELECTクエリがアクセス集中でスパイクしたことでCPUとメモリが逼迫した時には、読み込み性能だけではなく書き込み性能にも影響が出るという現象が起きました。
具体的には、200ミリ秒程度のレイテンシだった処理が、CPUが頭打ち状態になると一気に20秒ほどのレイテンシにまで落ちるくらいのイメージです。
また、オンライン分析処理のすべてでTiDBのOLAP用オプションであるTiFlashを全部使うことにして、いざ試してみたら性能が劣化することも発生しました。
これはなぜかというと軽いクエリではTiFlashの性能が発揮できず、軽いクエリは（TiFlashではなくTiDB標準のストレージエンジンである）TiKVのほうが性能を発揮できるためでした。
あるクエリに対してTiFlashを使うかどうかはTiDBのオプティマイザが判断するのですが、必要に応じてSELECT文にヒントを付けることで、明示的にTiKVを選択できるようになりました。
クエリの自由度が求められるサービスではリリースしてしばらくはサーバどれくらいの負荷がかかるか読みにくいため、リリース直後だけでもTiFlashを設置することで、重たいクエリが走った場合でもTiFlashが処理してくれることで保険になるのではないか、と岸本氏はTiDB導入時のアドバイスを語り、セッションを終えました。
≫ TiDB User Day | 国内最大級のNewSQLデータベースイベント | PingCAP株式会社
（本記事はPingCAP Japan提供のタイアップ記事です）