イオンスマートテクノロジーが期待するTiDBとは
2020年10月に設立されたイオンスマートテクノロジーは、イオングループのデジタルシフト戦略を担う企業だ。「お客様の買い物体験の向上と、店舗DXを進める会社と位置づけられています」と言うのは、イオンスマートテクノロジー株式会社 CTO室 SREチームリーダーでDevRelの担当も兼任する香西俊幸氏だ。
イオングループの代表的なアプリケーションに「iAEON」がある。膨大な顧客IDと購買データを集約し、イオングループが提供する決済機能やポイントプログラム機能がまとめられたアプリケーションだ。iAEONは提供開始から3年ほどで500万人以上の会員があり、独自のコード決済サービス「AEON Pay」は836万人が利用している。
香西氏は自社の取り組みを紹介する前に、今回のテーマでもあるTiDBとPingCAPを紹介した。TiDBは複数コンポーネントからなる分散データシステムで、HTAP（Hybrid Transactional and Analytical Processing）を実現するMySQL互換のNewSQLデータベースだ。拡張性の高さに大きな強みがある。
TiDBを開発、提供しているのがPingCAP社だ。元InnoDB開発者のサニー・ベインズ氏を始めとし国内外のデータベースのスペシャリストが集まっており、日本法人のPingCAP JapanにTiDB主要コンポーネントの1つTiKVのコアデベロッパーが在籍しているのもユニークな点だと説明する。
NewSQLは、SQLデータベースとNoSQLデータベースの両方の特性を持ち、「シンプルに言えば、RDBMSとNoSQLのいいところを利用したもの」と香西氏。NewSQLはPostgreSQL互換のものが多い中、MySQL互換なのもTiDBのユニークな点だと言う。
TiDBは、大きく4つのコンポーネントで構成される。MySQLプロトコルの接続エンドポイントを外部公開するステートレスSQLレイヤのTiDB。ここにデータは保存されず、コンピューティングとSQL分析・処理のみを行う。実際のデータは、TiKVノードやTiFlashノードに送信され保存される。TiDBは、Golang製のOSSだ。
TiKVは、分散トランザクション型のKey-Valueストアで、データの永続化にRocksDBが使われている。CNCFによってホストされるRust製のOSSで、Graduatedステータスとなっている。TiFlashは、データを列ごとに保存し分析処理を高速化しHTAPを実現する。これはC++製のOSSで、オプションのコンポーネントとなる。TiDBクラスター全体の頭脳となるコンポーネントが、プレイスメント・ドライバーでメタデータ管理を行う。また管理UIも提供されている。
TiDBには無限のスケーラビリティがあり、さまざまな優位性がある。「唯一合わないユースケースとしては、複数コンポーネントから構成されるのでネットワーク遅延の加算によるレイテンシがあるため、数ミリセックのレスポンスが求められる要件のシステムには向かないでしょう」と香西氏は言う。
HTAPとはOLTPとOLAPのワークロードを同じアーキテクチャで処理でき、ワークロードが互いに干渉しないものだ。従来はOLTPのデータベースからETL処理をはさみOLAPのデータベースにデータを入れる構成が多かったが、HTAPのTiDBならETLなしで1つの仕組みにより実現できる。
PingCAPが提供する、TiDBを用いたDBaaSがTiDB Cloudだ。2024年2月現在、AWSとGoogle Cloudから提供されている。「イオンスマートテクノロジーではAzureをメインに使っているので、Azure版を心待ちにしています」と香西氏。
TiDB Cloudでは、ServerlessとDedicatedのサービスが選べる。ServerlessはAWSのみで、Dedicatedはリソース課金、Serverlessはクエリ課金となっている。プライベートの接続方式は、DedicatedではVPC Peeringが可能だが、ServerlessはPrivate Linkのみとなる。またServerlessでは、スケールアップ、スケールアウトは自動で行えるがいくつかの機能制限もある。
TiDBでデータベース運用における課題を解決したい
イオンスマートテクノロジーがTiDBを導入する背景としては、データベース運用におけるいくつかの課題があったからだ。スケーラビリティやシャーディングによる運用コストと複雑性の増加、メンテナンスビリティの問題とメンテナンス時の運用負荷の増加、MySQL 8への対応がせまっていることなどが具体的な課題として挙げられる。
これら課題に対し、「TiDBのことを知れば知るほど、TiDBしか勝たんのでは、との気持ちにさせられました」と香西氏。そのため、2024年2月7日にはTiDB Cloudの導入を視野に、PingCAPと共同検証を開始するプレス発表もしている。3月からは、さまざまな検証を実施し、本格的な導入を進めることとなる。
イオンスマートテクノロジーでは、マイクロサービスアーキテクチャを採用しており、それによる課題もある。通常、マイクロサービスに期待するのは、開発スコープを小さくし開発スピードを上げる、開発スコープを分離しコストを適切に管理する、サービス分離による障害の影響範囲を極小化するなどがある。
イオンスマートテクノロジーは、3年目の新しい企業だ。設立当初にサービスを新規構築する際、上記のようなメリットを考慮し、これからの時代はマイクロサービス開発が主流となりKubernetesだとの方針が打ち出される。そのため最初からKubernetesとマイクロサービスでの開発となった。
ところで、香西氏が尊敬する米国のソフトウェア技術者のマーティン・ファウラー氏も言うように、「成功したマイクロサービスのストーリーのほとんどは、大きくなりすぎたモノリスを分割するところから始まっている。そして、マイクロサービスシステムとしてゼロから構築されたシステムは、ほとんどのケースで深刻なトラブルに見舞われている」との話がある。この言葉の通り、ゼロからマイクロサービスに取り組んでいるイオンスマートテクノロジーでは、さまざまなトラブルに遭遇しており「アンチパターンを踏み抜いています」と言う。
マイクロサービスがかなり難しいアーキテクチャであることに直面しており、導入後にさまざまな課題が出ているのが現状だ。たとえば、ドメイン境界設定に起因するサービス分割の失敗がある。これは、マイクロサービス間に依存関係を持たせることなく分割するのが難しく、適切に切り分けるには深いドメイン知識が必要になるためだ。結果的にマイクロサービス間の依存度に応じたインターフェイスの増加、多発する循環参照なども発生し、デプロイの複雑度が上昇してしまう。そのため、もともとシンプルなものを求めていたのに、逆にマイクロサービスの導入で複雑化してしまっている。
また、マイクロサービス間のトランザクション管理も難易度が高い。これはいわゆる分散トランザクションであり、「分散トランザクションは、単純に設計や実装の難易度がかなり高いと思います」とも言う。いくつか推奨されるパターンはあるが、パターンに従って実装しても、上手く分散トランザクションが実現できるとは限らないのだ。
TiDBに集約し運用負荷を削減してアーキテクチャの選択肢を増やす
これらマイクロサービスの技術的な課題は、システムアーキテクチャの実装の課題でもある。そのため、TiDBで直接解決するのは難しい。しかし「データベースをTiDBに集約すれば、アーキテクチャの実装の選択肢を増やせる」と香西氏は言う。たとえばマイクロサービスで良くあるのが、データベースで同じテーブルを見たい、データベースを共有したなどだ。TiDBでは、それらはかなりやりやすくなるはずだ。
一方、マイクロサービスとリンクしない組織設計は、組織論の課題だ。これは適切なサービス分割ともリンクするので、セットで考える必要がある。適切なサービス分割が難しい中、組織も追従させるのは大変だ。結果的に組織構造はそのままで、マイクロサービス化されることは良くある。イオンスマートテクノロジーも、組織設計がないままマイクロサービスが始まり、DevとOpsが分離したまま運用されている。このように組織課題があるため運用負荷が増大しており、それを運用体制でカバーする状況が続いている。
運用体制でカバーしている部分に対し、「TiDB Cloudならメンテナンスによる運用負荷の改善がかなり見込めるのではと考えています」と香西氏。スケールアップやバージョンアップ、DDLの実行やシャーディングの管理など、現状ではサービスを完全に停止した状態でメンテナンスを行うこともあるが、TiDB Cloudならばメンテナンス時間を入れずにオンラインで実施できると期待する。
自動シャーディング、バージョンアップも、TiDBの分散システムの特性を生かし裏で自動処理される。シャーディングのホットスポットが発生する問題も、自動で調整してくれる。イオンスマートテクノロジーでは、シャーディングを多用しているので、その管理から解放される効果は大きいと期待している。
またTiDBでは、単一のエンドポイントをアプリケーションが見ることでデータベースのシェアリングができる。そのためのアプリケーション側の改修も不要なのは大きなメリットだ。講演の最後に「TiDB Cloudが提供する無停止で実現される無限のスケーラビリティ、安定稼働によりもたらされる運用負荷の削減に、非常に大きな期待しています」と、香西氏は言うのだった。
