Mobike - 最大級のドックレス自転車シェアリングプラットフォームを飛躍的にスケールアップ

事例公開日：2018年6月12日

 

Mobikeは世界初かつ世界最大のドックレス自転車シェアリングプロバイダーです。900万台以上のスマート自転車を運用しながら、世界200都市の2億人以上のユーザーにサービスを提供しています。Mobikeは低価格かつ便利な、都市圏での短距離移動手段であり、スマートロックシステムとモバイルアプリを組み込んだ特許取得済の自転車設計によって実現されています。毎日3,000万以上のライドをユーザーに提供しています。

Mobikeアプリを支えるシステムが、GPSデバイスとIoTコネクテッドデバイスが搭載された自転車から、日々30 TB以上のデータを収集しています。データ量と同時実行処理がこれまでにない速さで増加すれば、バックシステム、特にデータベースには非常に大きなプレッシャーがかかってきます。しかし、TiDBのおかげで、水平方向に柔軟にスケールアウトできるソリューションを活用できるだけでなく、「フレッシュ」データからインサイトを得て、意思決定をリアルタイムに行うこともできます。TiDBは分散型ハイブリッドトランザクション分析処理（HTAP）データベースであり、PingCAPチームによって開発されました。また、活気のあるTiDBのオープンソースコミュニティのおかげで、ベンダーロックインを避けながら世界中でデプロイし運用することができます。当社は現在、インフラストラクチャを心配することなく、急成長するビジネスと急増するデータに容易に対応できるようになりました。

2017年初期以降、実稼働環境でTiDBを使用しています。現在は100近くのノードを持つ複数のクラスタにTiDBをデプロイし、さまざまなアプリケーションシナリオで数十テラバイトのデータを処理しています。この記事では、当社がMySQLソリューションやそのシャーディングソリューションではなく、TiDBを選択した理由を詳しく説明します。その中で、TiDBによって問題が解決された経緯にも触れていきます。

 

TiDBを選択した理由

TiDBを選択する前、MySQLソリューションとそのシャーディングソリューションを詳しく評価しました。急成長しているスタートアップ企業である当社は、ごく短期間でスケーリングする必要がありましたが、MySQLシャーディングソリューションは以下の理由から適していないことがわかりました。

 

  • スタンドアロンMySQLの場合、頻繫にデータをアーカイブする必要がありました。データサイズがスタンドアロンMySQLの容量を上回った場合、ミドルウェアソリューションを使用してデータベースとテーブルをシャーディングしなければなりません。この作業を管理するのは困難です。
  • シャーディングに関するこれまでの経験を踏まえると、大量のデータはしばしばデータベースのハングアップを引き起こします。なぜならば、データ定義言語（DDL）オペレーションを実行するため、テーブル構造を頻繁にアップデートする必要があるからです。こうした状況はアプリケーションのユーザービリティに悪影響を及ぼし、さらにはデータの不整合を引き起こす可能性があります。また、当社は、サービス量の爆発的急増やサービス要件の変化にもかかわらず、アプリケーションロジックをより簡単にアップグレードしたいと考えています。しかしシャーディングではこれを実現できません。
  • シャーディングソリューションを選択したとしたら、いざデータベースをシャーディングする際に、進行中の業務を停止させ、アプリケーションコードをリファクタリングし、次いでデータを移行しなければなりません。さらに面倒なことに、シャード間でのデータの分散方法はシャーディングキーによって制御されているため、シャーディングキーを注意深く手動で指定しなければなりません。そして既存のシャーディングキーを変更すると、深刻な問題を引き起こす可能性があります。言うまでもなくシャーディングはシャード間の分散トランザクションをサポートしておらず、トランザクションの厳密な整合性も保証されていません。

新しいソリューションは、以下の要件を備えている必要があります。

 

  • オンラインDDL：新しいサービスが次々と開発されるため、常にDDLの変更が生じます。データベースのダウンタイムがなく、新しいカラムやインデックスを追加できるようにする必要があります。
  • 柔軟な拡張性：オンデマンドマーケティングキャンペーンの際は、データが急増したりトラフィックが一時的に急増したりします。ピーク時に容量を増やし、キャンペーン終了後に容量を減らすことによって、こうした状況に対応する必要があります。
  • オペレーションチームからの頻繁な相関クエリや一時的クエリに対する要求に対応する必要があります。

幸いなことに、TiDBはこれらの要件を十二分に満たしています。

 

TiDBの概要

TiDBのコア機能は以下のとおりです。

 

  • MySQLプロトコルとの互換性
  • 水平方向の拡張性
  • 複数のデータセンター間での分散ACIDトランザクション
  • 厳密な整合性の保証
  • 自動フェールオーバーと高可用性

TiDBプロジェクト内にはいくつかのコンポーネントがあります。

 

  1. TiDBクラスタは複数のステートレスTiDBインスタンスからなり、ステートレスSQLレイヤーとして機能します。ユーザーのSQLクエリを処理し、ストレージレイヤーのデータにアクセスし、検索結果を返します。
  2. TiKVクラスタは複数のTiKVインスタンスからなり、分散型キーバリュートランザクションストレージとして機能します。データはここに常駐しています。データはその出所に関係なく、最終的にTiKVに保存されます。レプリケーションにRaftプロトコルを使用することによって、データの整合性とディザスタリカバリを確保します。
  3. TiSparkはTiKVの真上に配置され、我々のデータサイエンティストがリアルタイムでのデータ分析と既存のHadoopシステムのオフラインデータ分析の両方をサポートしています。

また、TiDBエコシステムには、その他のエンタープライズレベルのツールが豊富にあります。これらには、デプロイメントを迅速に行うためのAnsibleスクリプト、MySQLからの移行をシームレスに行うためのSyncer、ヘテロジニアスなデータを移行するためのWormhole、バイナリログファイルを収集するツールであるTiDB Binlogが含まれています。

 

実稼働中の4つのアプリケーション

ケース1：ロックとロック解除の成功率

スマート自転車のロックとロック解除の成功率は、Mobikeの主要メトリクスの1つです。なぜならばロック/ロック解除が失敗すると、ユーザーエクスペリエンスの質が低下し、さらにはユーザー離れにつながるからです。スムーズなエクスペリエンスを提供するには、地域、アプリケーションのバージョン、拠点、ユーザー、自転車に基づき、ロック/ロック解除の成功率に関するインサイトをコンスタントに得ることによって、問題が生じた自転車を特定しています。ユーザーが自転車をロック/ロック解除するたびに、自転車に関する膨大なログ情報が生成されています（通常ラッシュアワー時）。こうしたデータの量は、毎年何百億行にも達すると思われます。

当社は、上記の要件をすべて満たすTiDBをデプロイし、ロック/ロック解除の成功率を高めるシステムを直接サポートしています。下図は、TiDBがどのように当社システムに統合されているのかを示しています。

 

TiDBにおいては、ロック/ロック解除の成功率が低下したことをシステムが検知すると、数分以内にアラートが管理者に送信されます。失敗した1つのライドと関連するユーザーや自転車をデータベースからすばやく見つけることができます。これにより、障害が生じた自転車を迅速に特定することができます。

 

ケース2：リアルタイムデータ分析

データ量が飛躍的に増加し続ける中、便利で正確なリアルタイムデータ分析を行うことによって、他の自転車シェアリングプラットフォームに対する競争力を維持する必要があります。TiDBを導入する前は、当社には数十のMySQLクラスタがありました。その一部はシャーディングされたデータベースであり、残りはスタンドアロンインスタンスでした。しかし、MySQLは、大量の複雑なデータセットに対するクエリを処理する目的で設計されていません。このため、リアルタイム分析はいっそう困難なものになりました。

この課題に対応するため、まず、データをHiveに同期させることを試みました。以下の2つの方法を考えつきました。しかし、どちらの方法にも大きな欠点がありました。

 

  1. 毎日データ全量の同期を行う。この方法では、オンラインデータベースに高いプレッシャーがかかるほか、時間の経過とともに大量のHiveリソースを消費します。
  2. 毎日増分同期を行う。HDFSがupdateオペレーションをサポートしていないため、日々の差分を前日のデータにマージする必要があることを考慮すると、このアプローチは複雑でした。この方法の利点は、データサイズが大きい場合に、増分同期の方が完全同期よりも高速であり、スペースが少なくて済むことです。短所は、増分同期ではHadoopのコンピューティングリソースの多くを占有し、その結果、システムの安定性に影響が出ることです。

一方、TiDBの場合は、MySQLエコシステム向け専用に開発されたツールを使って、複数のMySQLインスタンスからリアルタイムのデータ同期を実行できます。当社は前述したSyncerを利用し、TiDBクラスタをさまざまなMySQLインスタンスやシャーディングされたMySQLクラスタと同期させることができました。TiDBはupdateオペレーションをサポートしているため、Hiveに伴うような問題は発生しません。TiDB/TiKV上でApache Sparkを実行するために構築された薄いレイヤーであるTiSparkを組み合わせれば、データがTiDBにインポートされた直後に、Sparkによって複雑なOLAPクエリを実行することができます。

下図は、TiDBとTiSparkを使用した、当社のリアルタイムデータ分析システムの実装を示しています。このシステムによって、あらゆる種類の分析タスクをいつでも簡単に実行できます。Hadoopではこのようなシステムを構築することは不可能でしょう。

 

現在、TiDBクラスタには、数TBのデータを持つ数十のノードがあります。TiDBの高可用性アーキテクチャのおかげで、システムの動作は安定しています。また、x86サーバーを追加するだけで、データセットの増加スピードにかかわらず、リアルタイムデータ分析機能を確保しながら、水平方向に拡張することができます。

 

ケース3：Mobike StoreのOLTP

Mobike Storeは、ユーザーがMobikeコインを使って商品を購入できるオンラインショッピングプラットフォームです。Mobikeコインとは、革新的なロイヤルティリワードプログラムであり、ライダーの間で広く好評を得ています。ユーザーは乗車履歴、利用頻度、特定の行動に基づき、いろいろな方法でMobikeコインを集めることができます。

ユーザーベースが急速に拡大したため、Mobike Storeからのデータが急増しました。年内にはかるく何千億行に達すると思われます。Mobike Storeのシステムを支えるため、以下の要件を満たすデータベースが必要でした。

 

  • あらゆるシナリオにおいて、常時オンラインかつ利用可能で、稼働が安定している
  • すべてのデータを恒久的に保存できる
  • ピーク時や特別な販売促進キャンペーン中に、高水準の同時実行処理に対応できる
  • コアビジネスが成長および進展していく過程で、サービスの中断がない

社内テストの結果を見ると、Mobike Storeのインフラストラクチャニーズに合った最適なソリューションは、TiDBであることがわかります。1つのテーブルのデータ量が5000万行を超えると、TiDBはMySQLと比較して相当な優位性を示します。ネイティブな水平方向の拡張性によって、当社の容量を柔軟に拡大させることができます。また、オンラインDDLもサポートしているため、Mobike Storeのようなサービスを繰り返し提供することが容易になります。アプリケーションが変更されたとしても、サービスを中断する必要がありません。

TiDBをデプロイして以来、Mobike StoreでのOLTPのデータサイズは何百億行にも達しましたが、PingCAP社のチームによるタイムリーで専門的なサポートのおかげでオペレーションはスムーズに実行されています。

 

ケース4：ログ収集データベース

Mobikeは、リアルタイムの意思決定のためのリアルタイムインサイトを実現するため、パーキング履歴や自転車が正常にロック解除された時の通知など、あらゆる種類のデータソースからのログを保存し分析しています。このようにログデータ量が大きいため、データベースの拡張性やデータベース間の分析容量を重視しています。

TiDBを導入する前、当社は以下の問題を抱えていました。

 

  • 新しいサービスを開発するときはいつでも、データの量、増加量、同時実行性に関する要件に基づき、事前にMySQLシャーディングソリューションを個別に計画および設計しなければなりませんでした。
  • 当社のサービスはすべて相互接続されているため、さまざまなサービスをサポートしている、独立したデータベースのデータを集計するのが困難でした。
  • 他の複雑なリアルタイムデータ分析の要件を満たすため、面倒で時間のかかるETLを実行することによって、最初にデータをビッグデータプラットフォームに移行させる必要がありました。

TiDBを導入したことによって、これらの問題に容易に対処できるようになりました。

 

  • TiKVノードを追加するだけで、新しいサービスやアプリケーションからのデータに対応できます。システムの同時実行性に関する問題はもう発生しません。なぜならばクラスタを水平方向に拡張させ、分散度をさらに高めることができるからです。
  • これらの相互接続されたサービスを当社のTiDBクラスタに配置することによって、特定のタイプのデータや特定の期間のデータに簡単にアクセスし、分析を行うことができます。
  • TiSparkを活用することによって、TiDBクラスタ内のデータに対し、複雑な分析クエリを直接実行できます。この方法ならば、ETLを行う必要なく、1つのデータベースソリューションのみによって、リアルタイムデータ分析を簡単に実現できます。

 

 

問題点および最適化

TiDBは素晴らしい製品ですが、当社の複雑なユースケースに適合する形で使用するには、いくつかの問題と課題がありました。幸いなことに、PingCAP社の技術サポート・開発チームが常に支援してくれました。このセクションでは、当社が直面した（そしてその後克服した）主な課題と、それらに対して実施した最適化について説明します。

記事『TiDB Internal (I) – Data Storage』で説明されているとおり、TiKVは本質的に、順序付けられた巨大なキーと値のマップです。データはリージョンごとに分散されて保存されています。各リージョンには、連続した範囲のデータが含まれています。1つのリージョンにいくつかのテーブルからのデータが含まれている場合、または1台のマシン上に複数のホットリージョンが共存している場合は、リソースボトルネックが発生するため、リソース分離の問題が生じます。

この問題は、TiDBの設計において綿密に検討されました。その後、HotRegionBalanceが、TiKVクラスタを管理する別個のコンポーネントであるPlacement Driver（PD）に組み込まれたことで、この問題は回避されました。しかし、1つのクラスタ内に複数のデータベースがある場合、または1つのデータベース内に複数のテーブルがある場合は、依然としてリソースボトルネックが生じる可能性が高まります。これはPDのスケジューリングポリシーが以下の前提に基づいているからです。

 

  • 各リージョンのリソース消費が同等であること
  • 各リージョン間に相関関係がないこと
  • リージョンがストア間で可能な限り均等に分散されていること

この問題を解決するため、PingCAPチームと協力し、以下の最適化を達成しました。

 

最適化1：テーブルベースでの分割

TiKVのコプロセッサのテーブルベースでの分割最適化を行う目的は、各リージョンに1つのテーブルからのデータのみが含まれるようにし、小さなテーブルでリソースボトルネックが発生する確率を下げることです。これで、新しいテーブルデータが1つのリージョンに挿入されると、TiKVがそのtableIDを現在のリージョンのキー範囲に基づいて計算します。挿入されたキーがキー範囲外の場合は、このリージョンは事前に分割されます。

 

最適化2：テーブルレベルのリソース分離

TableIDとNameSpace間のマッピング関係に加え、NameSpaceとTiKV Store間のマッピング関係もPDのテーブルディレクトリに追加しました。マッピング関係はセキュリティを確保するため、etcdに書き込まれ、永続化されています。これで、新しいデータが挿入された時はいつでも、TiDBレイヤーからTableIDを取得し、次いでPDによってターゲットリージョンのTiKVアドレスを見つけることによって、新しいデータが他のTiKVノードに配置されるのを防止できるようになりました。さらに、PingCAPチームと協力してNameSpaceスケジューラを構築し、構造化されていないリージョンをそれを配置すべきTiKVサーバーに再スケジュールすることによって、テーブルレベルでのデータ干渉を確実に防止できるようにしました。

 

最適化3：管理ツール

NameSpaceを管理するため、特別の管理ツールを開発しました。幸いなことにTiDBは十分な柔軟性を備えていたため、この最適化を実現するためには、関連するAPIを呼び出し、TiDBのオリジナルインターフェースを介してテーブル名ごとにTableIDを取得するだけで足りました。Table NameとTable ID間の関係を管理および検証するため、PDコマンドライン管理ツールであるpd-ctlのコマンドディレクトリにHTTPインターフェースを追加しました。

 

結論

当社がTiDBを実稼働環境にデプロイしてから1年が経過しました。その間、ユーザー数は10倍近くに増加し、日々のライディングデータは数十倍に増加しました。TiDBのオンライン拡張性のおかげで、インフラストラクチャをスムーズにスケーリングすることができました。その結果、Mobikeアプリケーションの開発と最適化に注力し、MySQLのシャーディングルールに気をもむことなく、素晴らしいエクスペリエンスをユーザーに提供できるようになりました。こうした状況は、当社のような急成長しているスタートアップ企業にとって非常に有益であり、競合他社に一歩先んじることができます。

TiDBの主なメリットは以下のとおりです。

 

  • 柔軟な拡張性。TiDBの拡張性はNoSQLデータベースのそれに匹敵します。データサイズやアクセストラフィックが増加している場合、水平方向にスケーリングすることによって、レスポンスレイテンシーを安定的に維持しながら、システムサービスサポートの機能を改善することができます。
  • ユーザービリティ。TiDBはMySQLプロトコルとの互換性があることから、シャーディングを回避できる簡単なドロップインソリューションと言えます。ユーザーフレンドリーなインターフェースを備えているため、当社の技術者は各オペレーションやバックエンド管理を簡単に行うことができます。
  • エンタープライズグレードのサポート。何か問題が発生した場合は、PingCAP社に連絡すれば、サポート担当者がすばやく対応して問題を解決してくれます。

PingCAP社のチームとの緊密な連携とTiDBのオープンソースコミュニティとのインタラクションからも、大きなメリットとフィードバックを受けており、コードのメンテナンスコストも大幅に削減されました。

今後は、PingCAP社と引き続き密接に協力することによって、開発中の管理ツールを強化し、TiDBをインフラストラクチャの深部にまで実装するとともに、Mobike内でより広範に活用していく予定です。別のケーススタディ：The Hybrid Database Capturing Perishable Insights at Yiguo（生鮮食品のインサイトをキャプチャするハイブリッドデータベース、Yiguo社の事例）

関連ユーザケース