Google Chromeの拡張機能であるStreakは、Google Workplaceと直接統合され、販売パイプライン、連絡先、アクションアイテムが表示されるCRMダッシュボードを構築できるツールです。2011年に登場したStreakは現在、Opendoor、Uber、Atlassian、Logitech、Rappi、Keller Williamsなど、業界をリードする企業をはじめ、世界中の6000社を超える企業で導入されています。
StreakはGmail上に展開され、受信トレイ内に埋もれている有益な情報を自動的に抽出して整理します。Streakの顧客ベースが急速に拡大するに従い、テラバイト規模の電子メールメタデータを整理してコラボレーションを強化できる、高度なシステムが必要になりました。いくつかの選択肢について検討した結果、Streakユーザーが電子メールとメタデータを簡単に共有できるようにし、またStreakの開発スピードを最高度に高められるのが、TiDBでした。
使用例
スレッドの統合
Streakは、電子メールに一意の識別子を適用し、続いて電子メールメタデータをインデックス登録していくことで、電子メールデータを整理します。この一意の識別子によって、受信トレイ内で同じヘッダーを持つ電子メールがまとめられ、複数のユーザーに対応する1つのスレッドのメッセージが作られます。それにより、ユーザーベース全体にわたる、約35 TB分の電子メールメタデータが、多数の小さなレコードとして編成されます。
権限モデル
電子メールには、パスワードのリセットや部外秘の社内メッセージなど、さまざまな機密情報が含まれている場合があります。電子メールの実際のデータではなく、メタデータがインデックス登録されるのはそのためです。さらに、その情報が確実に関係者だけに共有されるように、複雑な権限モデルが適用されます。
課題
- Streakは、フィルタリングされセグメント化された情報に、Gmailの受信トレイからすばやくアクセスできるようにする機能です。特に事業規模が拡大した場合には、大量のデータをリアルタイムに更新し計算する必要があります。そのため、高度な並行処理を維持しつつ、ユーザーが常に正確なデータを受け取れるように、データ分析をリアルタイムに実行できるデータベースが必要でした。
- Streakでは、ユーザーのGmail受信トレイ内の電子メールをすべてインデックス登録するため、大量のデータの保管が必要になります。しかし個々のレコードは均一に利用されるわけではありません。特に関連性が高いものがある一方で、有意でないデータが多量に存在することがあります。その場合は、必要なストレージとコンピューティングノードとの間で不一致が生じます。検討したデータベースソリューションの中には、ストレージとコンピューティングノードを一体としてスケーリングすることが求められるものもありました。
- Streakでは大量の電子メールメタデータが処理されるため、アクティビティが急増することも多くなります。データの急増やホットリージョンが生じる原因を把握しなければなりません。たとえば、広範に共有されるマスメール（GoogleからすべてのGmailユーザーに送信されるサービス更新）は、書き込みホットスポットの原因になり得ます。従来型のデータベースソリューションでは、この種のデータ急増にすばやく対応できる可観測性ツールが用意されていませんでした。
- およそ35 TBのデータを最小限の人数の開発チームで管理するため、Streakでは、すぐにセットアップできて管理も容易なデータベースソリューションが必要でした。過去に導入したソリューションでは、手動でインデックスを構築したり、カスタマイズによってバックアップソリューションを作成するなど、多くの手作業が発生するケースもありました。
- Streakの開発チームはデータベースインフラストラクチャに関する作業に対応できるとはいえ、それよりも効率的に時間を使うべきだと考えていました。この貴重なリソースを解放する意味でも、データベースソリューションによるカスタマーサポートが、セットアップや日常的なトラブルシューティングには不可欠であることを認識しました。しかし一口にカスタマーサポートと言ってもその知識の程度と利用しやすさには差があり、カスタマーサポートのレベルが低ければ技術的な導入は成功しないことも理解しました。
TiDBを選ぶ理由
Streakの開発チームは、新しいデータベースソリューションを探しているときに、Hacker NewsでJepsenによるTiDBのテスト結果に関する記事を目にしました。また、MySQLとの互換性があるプロジェクトについて、GitHub検索でTiDBが上位にランクされていることも知りました。
それがきっかけで、まずはいくつかのテーブルでTiDBを試してみようということになりました。数か月にわたって利用してみたところ、パフォーマンス改善とレイテンシの低減が見られ、開発チームの生産性が向上し、データベースインフラストラクチャのコストも最小になったのです。TiDBは、Hybrid Transactional and Analytical Processing（HTAP）ワークロードがサポートされた、オープンソースの分散型NewSQLデータベースでした。
強固な一貫性を持ったデータのリアルタイムビュー
Streakは、Gmailの複数の受信トレイから情報をリアルタイムに抽出して、ユーザーダッシュボードに整理して表示します。このデータはリアルタイムに更新して、複数のユーザーがいつでも利用できるようにする必要があります。開発チームは当初、OLAPデータベースのClickHouseを使用して、インデックス登録と分析的クエリを実行し、さらにMySQLからキーによって結果を引き出すことを試みました。しかしそれは、チームにとっては望ましくない手作業になってしまいました。結局、分析的クエリも実行できるハイブリッドなトランザクションシステム（HTAP）であるTiDBを使用することで、効率向上に成功しました。TiDBは分散データベースであるため、読み取りを複数のTiKVストアに拡散し、並行して計算を行うことが可能です。またSQLレイヤがストレージレイヤから分離されているため、分析のワークロードが重くなっても専用のTiDBサーバーインスタンスに隔離して処理できます。
Streakの使用例では、強固な一貫性も求められました。一貫性は、顧客のユーザーエクスペリエンスにとっても、開発チームの効率性にとっても鍵になる要素です。顧客が引き出すデータは、同じデータソースに対して同時に更新が行われても、正確性が保持されなければなりません。古いデータが誤ってトランザクションデータベースに書き込まれたりしてはならないのです。TiDBはACIDに完全に準拠しているため、強固な一貫性が保証されます。
ストレージとコンピューティングノードの分離
Streakの事例で特徴的なのは、ストレージレイヤとコンピューティングレイヤが同じペースでは拡大していないことです。それは電子メールメタデータのインデックスの規模が大きいためであり、レコードによっては必ずしも頻繁に使用されないか、まったく使用されないものもあります。Streakでは効率性とコスト上の理由から、これらのレコードを別個に管理する必要がありました。TiDBのアーキテクチャはコンピューティングとストレージが分離されるように設計されているため、そのような管理が可能です。TiDBがステートレスSQLコンピューティングレイヤとして機能し、TiKVが分散トランザクション型のキー値ストレージエンジンになっています。そのため、ビジネスニーズに合わせて、コンピューティングノード（TiDB）とストレージノード（TiKV）を別個にスケーリングできます。
TiDBアーキテクチャ
アクティビティの急増を把握する可観測性ツール
Streakでは電子メールメタデータのインデックス登録の過程で、データの急増や特定のインデックスのホットリージョン化が発生する場合があります。TiDBには一般的な低速のクエリログだけでなく、TiDBダッシュボード内にKey Visualizerツールが用意されています。Key VisualizerはTiDBの使用状況を分析し、トラフィックのホットスポットのトラブルシューティングを行って、特定の期間におけるTiDBクラスタのトラフィックを視覚的に示します。またKey Visualizerの核になっているヒートマップでは、時間の経過と測定値の変化がXY軸上に表されます。それぞれの色は、特定期間内におけるリージョン別の読み取り/書き込みトラフィックの変動を示します。TiDBダッシュボードには、包括的なモニタリングツールのセットと、分析とインタラクティブな視覚化が可能なオープンソースのWebアプリケーション、Grafanaも用意されています。
Key Visualizer – TiDBダッシュボード
Grafanaモニタリングツール – TiDBダッシュボード
セットアップが容易：MYSQLとの互換性とデータの一括移行
Streakにとって、TiDBへの移行は複雑なものではありませんでした。MySQLとの互換性が確保され、データの移行が容易になっていたからです。TiDBはMySQLプロトコルとの互換性があるため、既存のMySQLインスタンスから簡単に移行できます。
Streakチームは、大型のSQLダンプをTiDBクラスタに完全にインポートできる、オープンソースのTiDBエコシステムツールTiDB Lightningを使用して、データをTiDBに移行させました。個々のSQLステートメントを実行していく従来の方法よりも、少なくともインポート速度が3倍、1時間あたり約250 GBになっています。TiDB Lightningでは、複雑で時間がかかる一部の操作をスキップすることで、標準的なインポート速度の向上を実現しました。
TiDB Lightningのアーキテクチャ
