記事公開日:2024年2月9日
2023年12月6日から8日まで4年ぶりのフルオフラインイベントとしてベルサール六本木グランドコンファレンスセンターで開催された「db tech showcase 2023 Tokyo」で興味深いセッションがありましたので、ご紹介したいと思います。
セッションタイトルは「アーキテクチャ多様化時代にデータベースをTiDBにまとめるという選択」で、TiDBのユーザであるmenu株式会社の窪田 浩之氏、合同会社DMM.comの渡部 太緒氏、およびMicoworks株式会社の陳 瀚氏の3名に、PingCAP株式会社の日下 太智氏がモデレータとして参加したパネルディスカッション形式で開催されました。
モデレーターを務めた PingCAP株式会社 プロダクトマネージャー兼
シニアソリューションアーキテクト 日下 太智氏
まず、最初に登壇された方々からの自己紹介があり、その後、TiDBに移行した理由へと話が進んで行きました。
登壇した3社の自己紹介
日下氏：TiDBを各社にお使いいただいているわけですが、背景やどんな問題があるのかということや使い方等についていろいろお話を伺いたいと思っていますが、まずは自己紹介からお願いします。
窪田氏：menuというフードデリバリーアプリの開発をしているmenu株式会社の窪田と申します。menuというアプリでは、店舗、ユーザ、配達員の3者のマッチングをするいわゆるスリーマッチングモデルというモデルのアプリケーションで、この3者に対するスマートフォンアプリが存在します。このアプリケーションを実現するためのバックエンドのドメインというのはかなり複雑で、現在はそのリファクタリングとしてマイクロサービス化などを行っています。私はこのmenu株式会社で、バックエンドとインフラのエンジニアをやっております。基盤チームでインフラの構築、運用からAPIの開発まで行っています。
menu株式会社 開発本部 Professional 窪田 浩之氏
渡部氏：合同会社DMM.comの渡部と申します。DMM.comは、動画配信やオンラインゲーム事業、他にもアニメ製作やサッカークラブの経営など、さまざまな領域で挑戦をし続けている会社です。今年で設立26年目を迎え、現在では60以上の事業、26社のグループ会社、会員数は4,100万人を超えるところまで成長してきました。このような、DMM.comの数多くのサービス、そして会員が利用する共通機能をDMMプラットフォームとして提供しています。これらの共通機能は170人規模のエンジニアが所属するプラットフォーム事業本部で開発しています。私は、その部署で認証機能の開発と運用を担っています。本日は、進行中のオンプレにある認証APIのリプレイス、クラウド化についてお話します。
合同会社DMM.com プラットフォーム事業本部 エンジニア 渡部 太緒氏
陳氏：Micoworks株式会社は2017年10月30日に設立されたスタートアップ企業で、MicoCloudというマーケティングプラットフォームを提供しています。MicoCloudは、LINEを活用したコミュニケーションツールで、導入後の効果が期待できるLINE顧客管理ツールとしてナンバーワンの評価をいただいています。サービス内容は、LINEに登録いただいたカスタマーに、配信やコミュニケーションを行います。そのコミュニケーションの中から、カスタマーの顧客属性や行動履歴を収集して蓄積します。さらにその蓄積したデータをセグメンテーションして、配信や更なるコミュニケーションをとります。この繰り返しで、コミュニケーションを最適化し、反応率を拡大するというツールになっています。私は、SREとしてMicoCloudのサービス安定稼働に日々努めています。
Micoworks株式会社 プロダクト統括本部 SRE Senior Specialist 陳 瀚氏
旧来のアーキテクチャーと現在
日下氏：ここからは、元々抱えていた課題やなぜTiDBに移行するに至ったかというところをご紹介いただきたいと思います。
窪田氏：Menuが提供しているサービスは、コロナ禍で成長していく中で、かなりバックエンド側に技術的負債が増えていきました。バックエンドにモノリスな大きなAPIサーバがあり、その後ろにGoogleが提供するEnterprise版のCloud SQLがマスタースレーブの構成をとっていて、ほとんどすべてのデータを一括して格納しているような状態でした。この状態で、レプリケーションの遅延の問題やメンテナンス時のダウンタイムが問題視されていたので、マイクロサービス化するにあたって、データベースを見直すことになりました。
その中で、MySQL互換のTiDBが選択肢に上がって、現在移行を進めています。具体的には、モノリスのAPIサーバをマイクロサービスとして少し切り出しながら、マイクロサービスの後ろに置くDBをTiDBにして、Cloud SQLから少しずつTiDBに移行しているということです。
日下氏：モノリスアーキテクチャからマイクロサービス化を進めているということですが、具体的に困っていたことはどのようなところですか?
窪田氏：元々のCloud SQLでは、インスタンスとして大きいものが1つあり、論理的なDBがいくつか同居している状態でした。その1つのDBに書き込みが発生した時に、その他のDBに影響が起きてレプリケーション遅延が起こるという事故が起きていました。このような問題が、TiDBのNewSQLの方に移していくことで解決が見込めるのではないかということで、TiDBを選択しました。
特にTiDBにはリソースコントロールという各論理的なデータベースの使用するCPUリソースの上限を設定するような機能があり、それがマイクロサービス化する中で各データベースをひとつのTiDBクラスターにまとめる際にノイジーネイバー対策として有用ではないかとも考えています。
日下氏：ありがとうございます。リソースコントロールについて補足すると、TiDBクラスターのリソースの使用上限や優先順位などを定義したリソースグループと呼ぶものを、DBユーザーやセッション、ステートメントに割り当てることでワークロードの分離を論理的に実現するTiDBの機能となります。現時点では不要でも、将来的な課題になり得る部分の対策も見越して選択されたということですね。では、続いて渡部さんお願いします。
渡部氏：私たちはTiDBに移行中というステータスなのですが、その移行対象のシステムというのが、ログイン機能を提供している認証APIです。DMM会員はさまざまなデバイスからログインしてくるのですが、そのログインに関する情報をオンプレのMySQLに、セッション情報をCouchbaseに、ログイン履歴をCassandraに格納するという運用を行っていました。
この認証APIとDBについて、オンプレから脱却するというクラウド移行プロジェクトが現在進行中です。3つのDBをTiDB Cloudに移行することで、オンプレ脱却とDBの統合が達成される予定です。複数DBを運用することで発生しているさまざまな課題が解決することを期待しています。
日下氏：複数DB運用による具体的な課題についてもう少し教えていただけますか?
渡部氏：新しい認証機能は日々登場するため、それを継続的に実装しなければならないわけですが、3種類のDBを使い分けていることにより認知負荷が増大し、開発効率が下がってしまっています。また、エンジニアの採用面でも3種類のDBに習熟したエンジニアはそう多くはないので苦戦しています。
日下氏：なるほど、システム的な課題だけではなく、組織面でも課題があるということですね。最後に陳さんお願いします。
陳氏：弊社が提供しているMicoCloudというサービスでは、大量のデータを取得して、蓄積するのにDynamoDBを利用していました。その取得したデータをセグメンテーション化したり、配信したり、検索や分析をするのにRedShiftを使用していました。この2つのデータベースを使用することで複雑度が高くなってしまい、また、期待した性能も出なかったなどさまざまな問題が発生しました。
そこで、NewSQLのTiDBが登場します。TiDBには、HTAPというオンライントランザクションと、オンライン分析の異なるワークロードを同時に実行できるという機能があります。その機能を使用することで、データの検索や分析でバランスよくパフォーマンスが出せることを期待して、TiDBを検証したところ、検証結果が見事に私たちの目的と合致しましたので、TiDBに移行することにしました。
日下氏：MySQL互換という観点でAuroraからTiDBへ移行するという話は耳にすることもありますが、現状ではAuroraを残しつつDynamoDBとRedshiftをTiDB Cloudに移行されています。その背景を教えていただけますか?
陳氏：システム上で発生している問題を優先的に対処したということですね。Auroraに関しては、あまり問題がなかったので、そのままにしています。ただ、先ほども言った通り運用の観点では一本化できたほうが都合が良いので、実はAuroraもTiDBへ移行することを検討しています。
日下氏：なるほど。移行は初耳でした(笑)。
TiDB以外の製品の選択を検討しなかったのか
日下氏：ここまで三者三様でいろいろ背景もあったようですが、移行に際していろいろな選択肢があったと思います。なぜ、TiDBにしたか教えていただけますか?
窪田氏：menuに関しては、元々Cloud SQLを使用していたこともあるため、インフラの担当者と相談しながら、それぞれの良し悪しを確認しつつ、将来的なことも見越してTiDBに移行して問題ないと判断されたデータから順々に移行を行っている状況です。
日下氏：それぞれのユースケースで、1番適切なものをご選択しているということですね。次に渡部さんはいかがですか?
渡部氏：移行対象にMySQLがありましたので、第一にトランザクションや高機能なクエリが使えるDBである必要がありました。また、認証APIは障害が発生すると60以上のサービスに全てアクセスができなくなるミッションクリティカルな機能なので、高負荷に耐えられダウンタイムのない分散DBである必要がありました。それらの要件を満たす選択肢としてNewSQLが候補にあがったのですが、MySQL互換が一番の決め手となりTiDBを選択しました。MySQL互換により移行のコストが下げられることが大きな利点でした。さらに学習コストも要因の一つです。MySQLであれば使いこなせるエンジニアが多いため、中長期的な学習コストを考慮すると、MySQL互換がよりメリットとなります。そのように判断し、NewSQLの中でもTiDBに軍配が上がったという状況でした。
日下氏：ありがとうございます。特に御社の場合はいろいろなサービスを運営されている中で、プラットフォーム的な仕組みを構築していると、MySQL互換であることが重要な選択肢になってくるというようなことですね。最後に、Micoworksの陳さんはいかがですか?
陳氏：我々は、HTAPの機能があるということで、TiDBが最初に選択肢に挙がってきました。検証結果も期待値を満たしていましたので、そのまま移行したということです。
日下氏：元々、DynamoDBとRedshiftを使っていた領域で、TiDBに移行したことで却ってパフォーマンスが期待を下回るというような部分もあるのではないかと思うのですが、そのあたりはいかがですか?
陳氏：もちろん、部分的にパフォーマンスで問題があることもありますが、システム全体でパフォーマンスを見ています。例えば、DynamoDBでデータを蓄積するパフォーマンスにおいては、TiDBに置き換えることで下がっている部分がありましたが、検索や分析の部分での性能が大幅に改善できたので、全体として最適化ができたと思っています。また、元々複数のデータベースを使用していたので、だいぶ運用がなくなったということで、今まで複数DBのモニタリングやバックアップとリストとかも全部TiDBに移行することで改善されました。
日下氏：ありがとうございます、運用も踏まえたトータルコストという観点で選んでいただいてるということですね。
実際にTiDBへ移行したことのメリットとデメリット
日下氏：次に、TiDBの実際ということで、良いこと、良くないことを伺っていきたいと思います。
窪田氏：まずは、MySQL互換であるということは、非常にアプリケーション開発者としてはメリットが大きいと思います。あとは、NewSQLの特性でもありますが、ReadだけでなくWriteがしっかりスケールしてくれることです。ノードの追加もすごい簡単にできるということもメリットになっています。あとは、ObservabilityもTiDB Cloudでは、しっかりしている管理画面があるのですが、初めから揃っているっていうのは非常にいい点だと思います。 ただ一方で、今後改善していただけると嬉しい点をあげるとすれば、弊社のObservability系は基本的に、Datadogに全部集約しているのですが、Datadogに流したいデータが不足している部分があるので、今後対応していただければと思います。
渡部氏：私たちはまさにMySQLの移行が終わったというステータスで、これからCassandraを移行していく状態ですが、やはりMySQL互換っていうのがとても良いです。MySQLクライアントがそのまま使えて、既存のSQLもほとんどそのまま使えるということで、アプリケーションからはTiDBだと意識することなく使えるという点が使い勝手が良いと思います。
日下氏：今、MySQLからの移行は終わったというお話がありましたが、具体的にどのように移行をしたのか、どのツールを使用したのかなどを教えていただけますか?
渡部氏：サービスが担う責務上、DB切替時のダウンタイムが許容できませんでした。そのため、既存データをTiDBに移行した後、MySQLとTiDB双方にダブルWriteするフェーズを挟み、最後にアプリケーションの参照先をTiDBに切り替えるという流れで移行しました。移行の過程において、データの差分をチェック、修正する必要がありますが、そこはPingCAPが中心となって開発しているツールを使用しました。
アプリケーションエンジニアの視点では、接続先をMySQLからTiDBへ変えるだけで、既存のコードをそのままCopy&Pasteしても使えるという点が本当に扱いやすかったです。思ったよりも移行のコストを抑えられたなという実感があります。もし仮に、新しいエンジニアがチームに入ってきたとしても「これMySQLだから」と言っても通じるぐらい、利用者からすると本当に差を感じません。そこが良い点だなと思っています。
日下氏：利用されたツールについて会場のみなさまに補足すると、MySQLとTiDBのデータ差分をチェック、修正するツールとしてsync-diff-inspectorというものがあり、それをご利用いただきました。また、MySQLからTiDBに移行するためのDMというツールや、TiDBからMySQLにレプリケーションするTiCDC(TiDB CloudではChangefeed)と呼ばれる機能もあります。このChangefeedは、MySQL系のデータベースだけではなくCloud StorageやKafkaにも流すことができます。Micoworksさんもお使いいただいていますよね。
陳氏：はい、データプラットフォームとの連携で活用しています。そういったツールが充実している部分も良いところだと思います。
ほかにTiDBの良いところは、やっぱり、MySQL互換性があることですね。あとは、パフォーマンスが私たちの期待値を達成しているところです。改善をお願いしたい点としては、システムのObservabilityをNewRelicに統合しようとしていますが、まだ、TiDB Cloudからの統合できる項目が足りないので、改善してほしいと思っています。
日下氏：ありがとうございます。いただいたフィードバックをプロダクトに反映していきます。他に言い残したことはありませんか? 特に良くないことについて(笑)。
渡部氏：TiDBは良いプロダクトだと思いますが、話題に出たObservabilityの統合機能の観点含めTiDB Cloudはまだ成熟しきってない部分があると思っていて、いくつか要望をPingCAPに出しています。今まさに改善していただいているところでもあるので、今後さらに使いやすくなることを期待してます。
日下氏：日本のお客様のほとんどはTiDB Cloudをご利用いただいていることもあり、こういったお客様からのフィードバックは非常にありがたいです。MicoworksさんはTiDB Dedicatedだけでなく、TiDB Serverlessも使っていただいていますよね。その視点ではいかがですか?
陳氏：メインサービスであるMicocloudではTiDB Dedicatedを利用しており、その一部データをTiDB ServerelessにChangefeedを使ってレプリケーションし、社内用の分析データプラットフォームとして利用しています。TiDB Serverlessは真の従量課金で安く利用できているので助かっています。
そのServerlessに対して、ぜひ改善していただきたい点は、アクセスに関する部分です。TiDB Dedicatedでは、パブリックのアクセスに関してIPアドレスをホワイトリストで許可できたり、制限をかけられたりできますが、TiDB Serverlessではそれができません※1。同じ機能を入れていただければ、もっと活用の幅が広げられると思います。
日下氏：はい、承知しました。陳さんには、OLAPワークロードのための追加コンポーネントであるTiFlashもお使いいただいていますが、まだまだTiDBはNewSQLの側面で認知いただいてるところが強いと思うので、そのあたりも教えていただきたいと思います。TiFlashを使われているサービス上での機能や、TiFlashの使いどころはどのようなイメージしょうか。
陳氏：そうですね、我々のサービスでは、蓄積したデータで、そのユーザの最終セグメンテーションを運営して、そこから更にサービスを改善していく、お客さんに価値提供するのが非常に重要なのでセグメンテーションのパフォーマンスが非常に重要になります。DynamoDBとRedShift使った時に、検索でレスポンスが、50秒以上かかってたケースがありましたが、それをTiDBのリアルタイム分析機能であるTiFlashを検証した時、クエリーを最適化せずそのまま使用したにも関わらず1秒程度でレスポンスが返ってきたので、驚きました。オンライン分析と、オンライントランザクションをうまく分離できるというか両立できるTiFlashが非常にいいと思っています。
日下氏：なるほど。サービスの中で、ユーザさん自身のKPIとか軸を持って分析するための機能だとか、そういったところにマッチしそうな感じですね。
Micoworksさんみたいに、ユーザ自身に分析機能を含めたサービスをお使いいただいてるケースももちろんありますし、EC系の会社の場合、ECサイトの各店舗の情報を集計するようなところのパフォーマンス改善の観点で、TiFlashをお使いいただいてるケースもあります。NewSQLとしての機能をより強力に補完するイメージを持っていただくと理解がしやすいのかなというふうには思います。
一方で、先ほどMySQL互換ということで、コピペしたら行けたみたいな話もあったと思うのですが、TiDBのMySQL互換性というのは100パーセントではありません。お三方の中でアプリケーション開発エンジニアとして、もうちょっと頑張ってほしいなとか、もしくはエンジニアの方から受けたフィードバックみたいなのがあったらぜひご紹介いただきたいなと思うのですが、いかがですか?
窪田氏：TiDBのローカルの開発環境が実はすごい入れやすいという側面もあります。TiUPというツールにplaygroundというコンポーネントがありまして、コマンド1つで簡単にデータベースの起動ができます。MySQLを使っていると、MySQLを立ててphpMyAdmin入れてというようにいろいろと複数のツールを入れなければといけないのですが、TiUPコマンドを使うとローカルでオブザーバビリティのダッシュボード画面含めて一気に立つので、そのあたりはアプリケーション開発者や他のメンバーもすごく喜んでいました。
日下氏：そういった面も含めて、ローカル環境においても使い勝手がまあ良かったということですね。渡部さん、陳さん、いかがですか?
渡部氏：先ほどからMySQL互換の話ばかりしていますが、やっぱりMySQLクライアントをそのまま使えるというのは、すごく楽だと思っています。アプリケーションコードにほとんど変更を加えることなく、移行のタスクを進められてきましたし、いつも通りの接続方法でホストの情報を変えるだけでTiDBに接続できるので、本当にTiDBを意識せずに開発できるというところが良いなと思ってます。
日下氏：ありがとうございます。TiDBはゲーム系の会社からもよくお声がけをいただいておりまして、その中でPoCを進めていただいてたりもしています。その中で、多くのゲーム系のお客様も、エンドポイント変えたら普通に動いたという評価をいただいてたりもしますので、互換性は割とあると見ていただいて良いと思っております。
アーキテクチャを踏まえたデータベースの活用
日下氏：最後に、皆さまからアーキテクチャを踏まえたデータベースの活用について、ひと言ずついただければと思います。
窪田氏：TiDBは最初にお話したリソースコントロールであったりとか、Writeがスケールするであったりとか、そのマイクロサービスを構築する際に、その複数のマイクロサービスの複数のデータベースを1つのクラスターにまとめてしまっても、十分使えるような機能がいっぱいあるので、 アプリケーションの開発においても検討の1つとして入れても全然問題ないと思っています。
渡部氏：今回の我々のケースのように、リレーショナルデータベースとNoSQLのスケーラビリティ機能の両方が必要なときに、NewSQLという選択肢は「あり」だと思います。さらにその中でも、MySQL互換に注目してTiDBを選択するのは「あり」なのではないかと思います。また、NoSQLを利用していない場合でも、オンプレ環境のMySQLの移行先として、フルマネージドのTiDB Cloudは良い選択肢の1つではないでしょうか。
陳氏：HTAP機能のあるTiDBは、先ほどお話したように、オンライントランザクションとオンライン分析の異なるワークロードをバランスよく取り入れているので、いろんなアプリケーションでもうまく適用できるのではないかと思っています。
日下氏：ありがとうございます。会場のみなさまの中にもデータベース選定に関わる方が多くいらっしゃると思います。その際に機能面や性能面、可用性の観点などいろいろな軸で検討されると思いますが、TiDBにまとめることでそれら個別具体的な良い悪いだけではなく、運用、それこそ組織的な課題も含めた全体最適の観点というのも、本セッションを通じて伝われば幸いです。
また、TiDBはNewSQLということで「まだNewSQLは早いかな…」という視点もあるかもしれませんが、TiDB Serverlessという選択肢もありますので、サービスがスケールした際の”保険”というような位置付けとして捉えていただけると嬉しいです。
最近、注目されているNewSQLデータベースであるTiDBをどのように使用しているのか、また、なぜ導入することにしたのかということについて、ユーザーからの生の声を聴けたとても良い機会だったと思います。どのデータベースを使用するにしても、機能も重要ですが、検証をしっかりした上で導入を検討することがとても重要だということを改めて認識したセッションでした。
出典：Think IT – 「【事例から学ぶ】アーキテクチャ多様化時代にデータベースを「TiDBにまとめる」という選択」(2024年2月9日)
参考情報：
・DMM.comが認証基盤をオンプレミスからクラウドへ、 移行先のデータベースとしてNewSQLを評価した結果とは？
・DynamoDBとAmazon Redshiftなど複数のデータベースを、1つのNewSQL「TiDB」で統合に成功 (Micoworks社)
