事例公開日：2020年10月20日
中国にあるZTO Express社は、世界最大級の速達便会社であり、同業界をリードしています。2016年12月31日現在、中国で速達便サービスのほか、高付加価値ロジスティクスサービスを提供しており、その対象地域は同国の都市・地域の96%以上に及んでいます。中国の2019年11月11日「独身の日」のセールでは、セールスプロモーションを通じて2億件以上の注文を獲得しました。
当社のビジネスが急成長するにつれ、膨大な量のデータがデータベースに流れ込むようになりました。Oracle Exadataではデータストレージ要件に応えることはできませんでした。データベースをシャーディングした後、データ分析をリアルタイムで実行できなくなり、データベースのスケーリングもできなくなりました。Apache KuduとHBaseの2つの選択肢がありましたが、どちらもリアルタイムデータウェアハウスの構築には適していませんでした。当社が求めていたのは、水平方向の拡張性、厳密な整合性を保持した分散トランザクション、同時実行性の高い書き込み、分レベルの多次元クエリに対応できるデータベースでした。
TiDBは、オープンソースの分散型Hybrid Transactional/Analytical Processing（HTAP）データベースです。TiDBのおかげでIT効率が300%向上し、2020年第二四半期には1注文あたりコストを前年同期比で17.1%削減することができました。
この記事では、当社がOracle ExadataからTiDBに移行した理由を説明します。また、TiDBを活用してデータベースをスケーリングする方法やわずか数分でクエリに応答できる多次元分析を実現する方法について説明します。
分散型SQLデータベースであるTiDBを選択した理由
問題点
ビジネスが急拡大する中、当社は以下の問題を抱えていました。
- Exadataデータベースのデータ量が増加したため、Exadataのストレージ容量に深刻な問題が発生。Exadataのデータ保存期間がますます短くなる一方、アプリケーションチームはデータ保存期間の延長を求めていました。
- シャーディングでは、リアルタイムデータ分析の要件を満たすことができない。データ分析はストアドプロシージャに依存しており、システムの拡張性とメンテナンス性が不十分でした。
- ピーク時、スタンドアロンマシンのパフォーマンスボトルネックやシングルポイント障害が発生するリスクが高い。データはT+1モードでレプリケートされていました。データ分析をリアルタイムで行うことができませんでした。
- リアルタイムデータウェアハウスを構築するため、HBaseとKuduをテストしたが、Kuduは既存のテクノロジースタックと互換性がなく、HBaseの多次元クエリへの対応は非常に制限されている。
TiDBはデータベース要件のすべてをクリア
上記の問題に直面する中、以下の機能を備えたデータベースが必要でした。
- 水平方向のオンライン拡張性を備えている。データが「リージョン」別にスライスされており、HBaseのように分割したり移行したりできる。ホットスポットの自動スケジューリングをサポートしていることが望ましい。
- Oracleの従来のアプリケーションをサポートするため、厳密な整合性のある分散トランザクションとセカンダリインデックスに対応している。
- 同時実行性の高い書き込みとアップデートをサポートし、アプリケーションチームのニーズに基づいて結果をすばやく検索できる。
- Sparkを使って分レベルのデータ分析をすばやく実行できるように、テクノロジーエコロジーがSparkと緊密に統合されている。
- 大容量ワイドテーブルの構築や多次元クエリ分析をサポートしている。
TiDBはオープンソースのクラウドネイティブな分散型SQLデータベースであり、PingCAPとそのオープンソースコミュニティによって開発されました。MySQLとの互換性を持ち、水平方向の拡張性、厳密な整合性、優れた可用性を備えています。Online Transactional Processing（OLTP）ワークロードやOnline Analytical Processing（OLAP）ワークロード両方のためのワンストップソリューションです。TiDBのアーキテクチャの詳細については、こちらをご覧ください。
当社のデータベース要件をすべて満たしていたことから、TiDBを導入しました。
TiDBの活用方法
2019年、実稼働環境にTiDBをデプロイしました。現在の実稼働環境には100以上の物理ノードがあり、OLTPアプリケーションとOLAPアプリケーションの両方が実行されています。TiSparkはTiDBのOLAPソリューションであり、TiDBのストレージエンジンの上で動作します。TiSparkがオンライン分析クエリをサポートした結果、クエリ応答時間が数分以内になりました。私たちがワイドテーブルをリアルタイムの抽出、変換、格納（ETL）で構築したとき、TiSparkによってリアルタイムデータとオフラインデータが効率的に接続されました。
ExadataからTiDBへの移行
TiDBを導入する前の、ZTO Express社のコアシステムアーキテクチャは以下のようなものでした。
各データ転送ポイント内に、さまざまなデータソースと情報ソースがありました。上記アーキテクチャ図を以下に解説します。
- 左側にあるのが、複数のトピックスを持つメッセージ指向ミドルウェア。
- 右側にあるのが、アプリケーションコンシューマー。これがミドルウェアメッセージを消費し、それらをOracleに保存している。外部サービス機能を提供するため、APIとアプリケーションデータサービスがある。
このアーキテクチャで大量のデータの分析を行うには、Oracle上にストアドプロシージャをたくさん構築する必要がありました。しかし、データサイズが大きくなるにつれ、ストレージ問題やコンピューティング問題がますます深刻になってきました。残念ながら、Oracleハードウェアをアップグレードするだけではこの問題を解決することができませんでした。いずれにしてもこの選択肢はコストがかさみました。そのため、新しいソリューションを探すことにしました。
TiDBを導入した後のアーキテクチャを以下に示します。
アーキテクチャ図を以下に解説します。
- 左側にあるのが多数のメッセージ。Sparkはこれらのメッセージをリアルタイムでシステムに接続し、分散コンピューティングフレームワーク内にあるHiveディメンションテーブルのデータを使って、MERGEオペレーションとJOINオペレーションを実行する。同時にSparkは、オフラインT+1計算モードによって分析されたデータとHBaseに保存されているデータを使ってMERGEオペレーションを実行する。
- 最終的な計算結果はTiDBに保存される。TiDBのデータを日々Hiveにレプリケートし、データのバックアップをとる。
- TiSparkは、Apache SparkをTiDBの上のレイヤーまたはTiKVストレージレイヤーで実行し、複雑なOLAPクエリに応答するために構築された薄いレイヤー。当社はTiSparkを使用してTiDB上でデータ分析を行う。これはサマリーレイヤーと呼ばれている。サマリーレイヤーには、公開データとアプリケーションレイヤーデータが含まれている。このデータをOracle（軽量サマリーレイヤーと多次元サマリーレイヤーを含む）にも配置している。
- 当社は、APIインターフェースサービス、詳細なクエリ、一部のラベルなど、TiDBベースの専門的サービスも提供している。
このアーキテクチャでは、すべてのクリティカルノードが水平方向の拡張性をサポートしています。通常、単一のノードや単一のクリティカルパスにはプレッシャーはかかりません。
TiDBとTiSparkを組み合わせて使用し、リアルタイムウェブテーブルを作成
2017年、リアルタイムデータウェアハウスを構築する方法を探しました。Apache HBaseとKuduをテストしましたが、以下の理由からあまり適していないことがわかりました。
- KuduはクエリエンジンとしてImpalaを利用するが、当社はクエリエンジンとして主にPrestoを利用している。したがって、互換性の問題が発生するかもしれない。加えて、Kuduコミュニティがアクティブでない。
- HBaseではアプリケーションクエリの要件をすべて満たすことができない。
当社のロジスティクスプロセスでは、多くのメッセージが当社システムに接続されています。各小包の完全な輸送経路ルーティングとレイテンシーを予測し、転送中の各小包のデータをキャプチャする必要があります。大量のデータを低レイテンシーで処理する必要があるため、TiDBとTiSparkを組み合わせて使用し、リアルタイムワイドテーブルを構築することにしました。
70以上のフィールドを持つワイドテーブルを構築しました。このワイドテーブルでは、OLTPデータがリアルタイムでTiDBに書き込まれます。TiSparkは、OLAPクエリを分レベルのクエリ応答時間で処理します。
TiSparkを利用する前に、DataXとSqoopを試しましたが、これらによるETL処理はTiSparkによるものよりもはるかに低速でした。テストの結果、TiSparkならば、3億行のデータを約10分でHiveにレプリケートできることがわかりました。さらに、リアルタイムワイドテーブルのデータは10以上のKafkaトピックから取得されます。複数のメッセージがシステムに書き込まれた場合、メッセージの順序を保証することが難しくなります。TiSparkを使用することによって、オフラインデータをリアルタイム分析シナリオに組み入れることができます。
下図は、リアルタイムワイドテーブルの作成方法を示しています。
- Sparkがコンピューティングのために複数のメッセージをクラスタに接続し、Hiveディメンションテーブル内のデータを使ってJOINオペレーションを実行する。
- JOINオペレーションの後、私たちは詳細データをTiDBに格納し、次いでTiSparkを使ってTiDBのデータを計算し、それをHiveに格納する。Prestoクラスタを使用して分析用データを提供する。
- TiSparkを使用してオフラインデータの一部をTiDBにフラッシュバックし、T+1分析を行う。また、TiDBを使用して外部アプリケーションサポートサービスを提供する。
このアーキテクチャでは、すべてのクリティカルノードが水平方向の拡張性をサポートしています。通常、単一のノードや単一のクリティカルパスにはプレッシャーはかかりません。
TiDBのオペレーションとメンテナンス
TiDBはそのモニタリングメカニズムとして、PrometheusとGrafanaを組み合わせて使用します。このモニタリングのメトリクスならば、当社のニーズを満たすことができます。私たちはDataXを使用してデータをHiveにT+1モードでレプリケートし、データのバックアップをとります。ところが、クラスタがオンラインアプリケーションと開発者クエリの両方をサポートしているため、SQLクエリによってデータベースサーバーに過剰な負荷がかかってしまったことがありました。この問題を解決するため、以下の対策を講じています。
- 特殊なアカウントによってオンラインで実行されているスローSQLクエリをモニタリングする。システムが自動的に、これらのスロークエリを停止し、オペレーションスタッフ、メンテナンススタッフ、アプリケーションの担当者に通知します。
- ユーザーがSpark SQLステートメントを使用してTiDBからのデータを照会できるクエリ用プラットフォームを開発し、同時実行制御機能とセキュリティ管理機能を追加した。
- メトリクスをXiaomiモニタリングにも接続した。クリティカルアラートが発生した場合、モニタリングシステムが関連スタッフを呼び出します。
TiDBがもたらしたメリット
IT効率が300%向上
2019年、121億2000万件の注文を完了しました。前年比で42.2%増加しており、増加率でみると業界平均を16.9ポイント上回っています。2019年11月11日「独身の日」の大々的なセールでは、TiDBのサポートによって、ピーク時トラフィックが120,000クエリ/秒（QPS）を超えました。また、TiDBは何百億行ものインサートとアップデートをサポートしました。TiSparkは、分レベルのオンラインデータ分析をサポートしました。これにより、セール日にITサービスが着実に稼働することが保証されました。
また、TiDBをベースにした新しいデータベースインフラストラクチャを導入したことにより、以下のメリットを享受できるようになりました。
- アーキテクチャ全体が明確になり、メンテナンスが容易になった。システムの可用性が強化された。
- TiDBがOLTPワークロードに対して高いパフォーマンスを発揮できるようになった。パフォーマンスはOracleよりも若干低いかもしれませんが、これはTiDBが分散型データベースだからです。
- 水平方向のオンライン拡張性を実現できた。ストレージやコンピューティングレイヤーにあるノードを追加または削除すれば、いつでもスケールアウトしたり、スケールインしたりすることができます。スケーリングプロセスがアプリケーションオペレーションスタッフやメンテナンススタッフにとってトランスペアレントになりました。
- サポートされるデータ保存期間を15日間から45日間に延長させることができた。
- OLTPワークロードとOLAPワークロードが分離されたため、単一のノードに対するプレッシャーが解消された。
- 以前よりも多くのアプリケーションディメンションのデータ分析がTiDBによってサポートされた。
- ハードウェアコストを削減できた。
1注文あたりのコストを17.1%削減
現在、当社の実稼働環境には100以上のTiDB物理ノードと200以上のTiDBインスタンスがあります。これらのノードやインスタンスは、主に決済センター、注文センター、貨物運送状センター、メッセージセンター、積み替え関連のスマートアプリケーションをサポートしています。
TiDBから得られたメリットは以下のとおりです。
- データ主導でリファインした管理手段を引き続き有効に利用できる。2020年第二四半期の1注文あたりのコストを前年同期比で17.1%削減できた。
- Oracleと比較すると、TiDBの柔軟かつ効率的なオンデマンドデプロイメントプランによって、総所有コスト（TCO）を大幅に削減することができた。
問題とソリューション
TiDBを使用し始めた時、いくつかの問題に直面しました。PingCAPチームと協力してその一部を解決しました。
ホットスポットが書き込みパフォーマンスに影響を与える
一部の専門的なアプリケーションでは、特定の期間内に書き込みとアップデートが頻繁に行われます。現在の懸念材料はインデックスのホットスポットです。時間別に多くのアプリケーションを照会しているため、時間関連インデックスや複合インデックスを作成する必要があります。一定の時間内で書き込みやアップデートを継続的に行えば、インデックスのホットスポットが生じる可能性があります。このホットスポットによって、書き込みパフォーマンスが低下する可能性があります。
将来PingCAPチームがこの問題を最適化してくれるはずです。そして最終的には私たちの問題が緩和されることを願っています。
トラブルシューティングが困難な問題
一部のSQLステートメントに大量のコプロセッサー要求が含まれ、キーバリューストアインスタンスの負荷が100%になったとき、クラスタの書き込みパフォーマンスが低下しました。このような場合、長期間実行されているSQLステートメントを見つけるには、ログを閲覧するか、またはSHOW PROCESSLISTコマンドを実行し、トラブルシューティングを行う必要がありました。多数のTiDBサーバーが存在する場合は、トラブルシューティングに時間がかかります。この問題を解決するため、すべてのログをElastic Stack（以前の「ELK stack」）に接続しました。
この問題に対処するため、TiDB 4.0にTiDB Dashboardが導入されました。TiDB Dashboardはさまざまなウィジェットがビルトインされたグラフィカルインターフェースであり、これによりユーザーはクラスタを簡単に診断、モニタリング、管理することができます。TiDB Dashboardには、各クエリのSQLステートメント、その実行終了時刻、クエリのレイテンシー、最大メモリ使用量が表示されます。ユーザーは、クラスタ内にある各スロークエリに関する詳しい情報を1か所で確認することができます。
スロークエリのトラブルシューティングをより簡単に
また、PingCAPチームは、Timeline Tracing機能も開発しています。この機能はすべてのSQL文に対し、自動的に有効化されます。これが実装されれば、ユーザーは各SQL文の実行ライフタイムの各ステージにおける、SQL文の実行時間がわかります。この機能はTiDB 5.0から利用できるようになります。
メモリのフラグメンテーション
当社は多くのUPDATE文、INSERT文、DELETE文を実行しています。以前はTiDB 3.0.3を使用していました。システムの動作はしばらくの間安定していましたが、モニタリングメトリクスチャートにいくつかの問題が見つかりました。Raftstore CPUメトリクスのような一部のノードのメトリクスが断続的に欠落していく中、SQL継続時間メトリクスなどのクラスタパフォーマンス関連のモニタリングメトリクスは穏やかに上昇していきました。
最初、これはモニタリング自体に問題があると考えました。しかし、PingCAPのエンジニアの支援のおかげで、問題の原因はメモリのフラグメンテーションであることがわかりました。そこで、クラスタのローリング再起動を行ったところ、この問題は一時的に解決されました。TiDB 3.0.14では、この問題は修正済みです。当社はこのバージョンにアップグレードを済ませていますのでもう心配ありません。
次の行動
当社は多くのアプリケーションをTiDB 3.0.14で実行していますが、現在のところ動作は安定しています。2020年5月、TiDB 4.0 GAがリリースされました。TiDB 4.0の機能の多くが、当社の喫緊のニーズに合致しています。例えば大量のデータのバックアップ、大規模トランザクション、TiFlash（リアルタイムHTAP分析を実行するためのTiDB用の拡張分析エンジン）などが挙げられます。
現在、当社のOLTPアプリケーションとOLAPアプリケーションは、キーと値のノード上で完全には物理的に分離されていません。大量の分析クエリが存在し、それらが幅広い時間帯にわたっており、大量のデータを含んでいる場合、インデックスフィルタリングのパフォーマンスが低下します。その結果、テーブルのフルスキャンが発生します。この場合、TiSparkには相当なリソースが必要になり、キーと値のノードに大きなプレッシャーがかかります。ピーク時には、データ分析が書き込みパフォーマンスに悪影響を及ぼす場合があります。したがって、TiFlashに細心の注意を払っています。私たちの次の行動は、TiDB 4.0をテストし、リアルタイムのデータハウスを構築することです。
当社がTiDBをどのように活用しているのかもっと詳しく知りたい場合は、SlackのTiDBコミュニティにご参加ください。TiDBをクラウド環境で試したい場合は、HTAPに対応しているフルマネージドデータベースサービスのTiDB Cloudをご検討ください。こちらで2週間の無料トライアルを申し込むことができます。
