PingCAPが国内最大級のNewSQLデータベースカンファレンス「TiDB User Day」を開催、事例を中心にTiDBの運用ノウハウを幅広く紹介

2023年7月7日、PingCAP主催の国内最大級となるNewSQLデータベースカンファレンス「TiDB User Day」がハイブリッドで開催されました。

このカンファレンスでは、まずPingCAP米国本社より共同創業者兼CTOのEd Huang氏とMySQLのInnoDB元開発者でHeatWaveの開発リードを担っていたシニアアーキテクトのSunny Bains氏が来日し、「TiDBとMySQLと未来」というタイトルでTiDBの最新情報について講演後、LINEやSBペイメントサービスなど6社から事例を紹介するという形で進められました。最後は「ゲーム業界のデータベースを覗いてみよう」というパネルディスカッションで終了しました。

事例紹介1：SBペイメントサービス

6社から事例の発表があったわけですが、事例の中にはいわゆるネット企業だけではなく、金融系のサービスで使用されている事例があり、エンタープライズでの活用の始まりを予感させるものでした。特にSBペイメントサービスでは、決済システムでの検証事例でした。

SBペイメントサービスでは、ECサイト向けにさまざまな決済手段を提供しており、加盟店に決済APIや画面によるサービスを提供しています。現在、EC市場では取引件数が日々増加し、障害やメンテナンス時のダウンタイムによる影響が顕著になってきています。また、既存サービスではさまざまな機能を提供するためのクエリが巨大化、複雑化してきており、そのチューニングやレビューといったDBAとのQAが増え、開発のリードタイムが増加してきました。そこで、開発者・運用者が求めるデータベースの要件を検討した結果、以下のようになりました。

いくつかのソリューションを比較検討した結果、これらを満たすものはTiDBしかないということで、TiDBの検証を始めました。検証は構築から運用までの一連の作業を行うことにしました。また、検証の観点については既存のデータベースと同じ使い勝手を求めつつ、さらに上記の要件を満たすかを確認したいということで、以下の4点を重点的に検証しました。

• 既存アプリとの互換性
• クエリレスポンスタイムの変化
• アップデート時の影響
• 障害時の影響

まず「既存アプリとの互換性」については、既にAWS Auroraで稼働しているアプリケーションを対象としました。結果として既存のコードを一切変更せず、向き先変更だけでTiDB環境で問題無く稼動させることができました。

「性能」については、検証の結果Auroraに比べてクエリの実行時間が数ms程遅くなっていました。ただし、リアルタイム処理であるという仕様上、この程度の遅延であれば無視しても問題ない増加量であるという結論となっています。

「アップデート時の影響」については、Auroraで検証した際データベースに対するConnection resetにより数件のリクエストエラーが発生し、またレスポンスタイムについてはDBインスタンス再起動時に最大15秒程度のクエリ遅延が数十件発生していました。

TiDBにおいてはリクエストエラーは確認できず、レスポンスタイムについてはAuroraと同様に遅延は認められましたが、最大でも1.5秒の遅延が数十件と突出した遅延にはなりませんでした。

最後に「障害時の影響」については、TiDB及びTiKVでそれぞれノード障害を発生させて検証を行いました。こちらもリクエストエラーは見受けられず、またリクエストにおいての遅延もありませんでした。

このように、ユースケースを想定した事前検証は重要で、今後のサービス利用に向けて大きな手応えを感じたといえるのではないかと思います。

事例紹介2：さくらインターネット

次に、検証ではなく現実にアプリを構築し、運用してきたさくらインターネットから「在宅ワーク時代における宅急便を活用したDXサービスの設計と仕組み：さくらインターネットとヤマト運輸によるSlackアプリ」というタイトルで講演がありました。

ここ数年のコロナの影響で在宅ワークが一般的になってきましたが、そこで問題となるのが荷物を社員間で送付する必要が発生した際に、社員間の住所を聞いてはいけないルールのある中でいかに実現するかです。この課題を解決するために、さくらインターネットでは社内外で使えるようなサービスを開発しました。

具体的には、下図のように①「荷物を送りたい⼈が受け取る⼈を指定する」、②「受け取る⼈は住所を⼊れる」、最後に③「荷物をコンビニ(2023年10月現在ではファミリーマートとセブンイレブン)に持ち込むかヤマト運輸に引き渡す、またはPUDOステーションに投⼊する」ことで、荷物を住所がわからない人に無事に荷物を届けることができます。これを社内の情報基盤であるSlack経由で実現することがポイントです。

技術的には、Slackの「3秒ルール」というEventに対して3秒以内に応答しなければいけないという制約がありました。これはSlack自体の考え方によるもので、レスポンスに時間がかかるとユーザ体験が悪くなるので、それを避けるためのものでした。そのためには、このアプリでは非同期処理が必須になります。

そこで、このアプリを開発するために使用してPythonのフレームワークであるDjangoとPythonベースの分散タスクキューツールであるCeleryを使い実現することにし、実行中のブローカーにはRedisを使用しました。しかし、契約情報やSlackの認証情報などの永続化されたデータはTiDBに格納する方式にし、さくらインターネットのクラウドのエンハンスドDB(TiDB)サービスを活用することにしました。

非同期処理では、HTTPリクエストに応答した後に追加で処理を⾏う場合は、Celeryを活用することで「伝票情報のヤマト運輸システムへの登録」や「SlackのDM送信」を実行しました。また、非同期タスクを定期実行する「Celery Beat Scheduler」を活用することで、下記のような処理をスケジュール実行しています。

• 荷物追跡情報の取得更新
• 請求⾦額の更新
• 有効期限切れの伝票の削除

次に、エンハンスドDBの構築・運用についての説明がありました。方針としてはTiDBをシンプルに構築して利用するということで、構築に当たっては「Terraform + Ansible + TiUP」によるIaC(Infrastructure as Code)の手法を活用しました。

基本的にはTerraformを活用してインフラ構築と設定を行うわけですが、Ansibleを活用し、Linuxユーザの設定やTiDB以外のパッケージ等のインストールや設定しなければならない項目を設定しました。TiDBクラスターのセットアップはTiUPを活用しています。TiUPはTiDB 4.0で導入されたクラスターの運用および保守ツールで、Go言語で書かれたクラスター管理コンポーネント「TiUPクラスター」を提供しています。

TiUPクラスターを使用すると、TiDBクラスターのデプロイ、開始、停止、破棄、スケーリング、アップグレードなどの日常的なデータベース操作を簡単に実行し、TiDBクラスターのパラメーターを管理できます。要するに、TiUPを活用することでTiDBクラスターの管理が容易になるということです。TiDBの監視という視点では、TiUPを使用してTiDBクラスターをデプロイすると、TiUPはPrometheus、Grafana、Alertmanagerなどのモニタリングサーバーもデプロイするので、慣れている監視ツールを選ぶことができます。このようにTiUPを活用することで、TiDBクラスターの運用・監視がとても容易に実現できます。

＊　＊　＊　＊　＊

SBペイメントサービスでの事例では、TiDBのエンタープライズ領域への適用に向けての実環境に近い検証環境での検証が進んでいることが紹介されました。この事例では、検証結果も問題なく本番に適用できるレベルであることを示しており、近い将来でのエンタープライズ領域での活用を期待させるものでした。なお、この検証結果を受け、2023年10月からは無事に本番環境での稼働が開始されています。

また、さくらインターネットの事例は、クラウド上にアプリを構築し、実稼働している環境での運用・監視についての紹介でした。こちらはツール(TiUP)の提供もあり、それほど手間をかけることなく運用・監視ができるということで、今後活用を検討しているユーザへの導入に向けてのモチベーションを上げることができる内容でした。このように、TiDBそのものの機能拡張も重要ですが、構築や運用に向けてのツールの整備もTiDB活用を広げるための大きな要因であることは間違いありません。

今回紹介できなかった4社の事例とパネルディスカッションの内容については、冒頭で紹介した本イベントのWebサイトでアーカイブ動画が公開されていますので、興味のある方は、ぜひそちらをご覧ください。