Pinterestは、レシピ、家庭生活、スタイルなどのアイディアを発見できる、アメリカのビジュアルディスカバリーエンジンです。2021年3月現在、月間のアクティブユーザー数は全世界で4億7800万人以上にのぼります。
ここ数年、当社はHBaseエコシステムを使用してクリティカルなオンラインアプリケーションを提供していました。ところがこのインフラストラクチャは複雑でした。機能にも制限があり、メンテナンスコストやインフラストラクチャコストも多くかかりました。このため、分散トランザクションとSQLとの互換性をサポートした、新しいストレージソリューションを探していました。
YugaByteDB、CockroachDB、オープンソースのスケールアウト型データベースであるTiDBを比較した結果、TiDBを選択しました。安定性やパフォーマンスに関する当社の要件を満たしていたからです。TiDBを利用すれば、システムの複雑さを低減し、インフラストラクチャコストを削減し、より厳密な整合性を実現することができます。
Pinterestのオンラインストレージの変遷
- 2012年、Pinterestのテクノロジースタックに、シャーディングされたMySQLを導入しました。これを使用して、ピン、ボード、ユーザーを含むコアデータモデルを保存しました。
- 2013年、Pinterestの最初のNoSQLデータベースシステムとしてHBaseを導入しました。その後、HBaseは幅広く活用され、当社のクリティカルなサービスの多くを処理しています。当社は、HBaseをベースにしてカラム型データストア、グラフサービスその他多くのアプリケーションを構築しました。
- 2015年、高パフォーマンスのC++ベースストレージエンジンとしてRocksDBを導入しました。これにより、key-value (KV) storeと機械学習を処理するアプリケーションが強化されました。
- 2017年、さらなる機能（例えば分散トランザクション）をNoSQLデータベースに追加してほしい、という要望をユーザーから受けました。NoSQLユーザーはセカンダリインデックス作成機能を要望していました。ユーザーの要望を満たすため、ミドルレイヤーシステムを多数構築しました。
- 2021年、SQLとNoSQL間のスイートスポットを必要とするユースケースが再び多く発生しています。ユーザーはNoSQLのような拡張性を求める一方、SQLライクな機能も求めています。そこで、当社の次世代ストレージサービスのテクノロジーとして、分散型SQLデータベースが有望な選択肢ではないか、と考えるようになりました。
Pinterestのオンラインストレージの変遷
HBaseの導入
HBaseの利用方法
2013年、PinterestにHBaseを導入しました。今日、当社は約50のクラスタを持ち、10PB以上のデータをホストし、1秒あたり1億以上のクエリを集計し、100種類以上のクリティカルなユースケースを処理しています。HBaseはその導入以来、Pinterestのインフラストラクチャの根幹になっています。今日でも、当社のクリティカルなオンラインパスとして機能しています。
HBaseを使用して、またはHBase上に、以下のコンポーネントを構築しました。
- HBaseとMemcacheを利用したグラフサービス
- HBaseとMemcache上に構築されたワイドカラム型データストア
- HBaseとApache Omidをベースとした、ミドルウェアレイヤーとしての分散トランザクションデータベース
- インデックス付けされたデータストア。HBaseアプリケーションとMuse（インハウスの検索エンジン）のほぼリアルタイムのインデックス作成を実現
下図は、HBaseエコシステムのアーキテクチャの概観を示したものです。
PinterestのHBaseエコシステム
このエコシステムを以下に説明します。
- 中心にあるのがHBaseです。
- HBaseの上にグラフデータベース、カラム型データストア、トランザクションマネージャー、セカンダリインデックス作成機能があります。
- 図の右側には、変更データキャプチャ（CDC）パイプラインがあります。ここにカスタマイズ済みのHBaseレプリケーションプロキシが構築されています。このプロキシは、HBaseからみたらログを右側に渡している、今度はそれをKafkaにストリーミングします。次いで、ダウンストリームの消費システムであるArgusがそのログを消費します。通知は、他のサービスにフィードバックしています。
HBaseの問題
HBaseは長年にわたって、当社の役に立ってくれました。しかし、以下のようないくつかの課題が生じました。
-
メンテナンスコストが高い
この8年間、使用していたHBaseのバージョンが古かったこともあり、長期にわたる技術的負債に悩まされてきました。HBaseは複雑なシステムであり、参入障壁も高く、その結果、HBaseを稼働させるのに多くの労力が必要でした。これが主要な問題点の1つでした。 -
機能の制限
HBaseは高性能ですが、そのインターフェースは単純です。ユーザーは最初、HBaseの単純なKVインターフェースを気に入りましたが、整合性の強化など、さらに充実した機能を求めるようになりました。これらの要請をすべて満足させることのできるミドルレイヤーシステムを、NoSQLデータストア上に構築するのは困難です。 -
複雑さ
ユーザーの要求を満たし続ける必要があったため、これらのいわば「レゴブロック」を時間をかけて積み上げ、SQLライクな機能をNoSQLデータストアでサポートしてきました。言うまでもなく、HBase自体には、ZooKeeperやHadoop分散ファイルシステム（HDFS）のようなさまざまなコンポーネントや付随サービスがありました。 -
インフラストラクチャコストが高い
高可用性を実現するためにプライマリスタンバイクラスタのペアを利用していたことから、インフラストラクチャコストが高額でした。また、1つのデータセットに6つのレプリカを使っていました。
HBaseシステムの主な問題点（対ユーザー）
ユーザーに対しても、既存のHBaseシステムには問題がありました。
Zenの問題点
Zenは、グラフデータモデルを提供するインハウスのグラフサービスです。基本的に、ユーザーはノードやエッジのデータモデルを使用してCRUDオペレーションを実行することができます。ユーザーはユニークなインデックス、ユニークでないインデックス、エッジクエリインデックス、ローカルインデックスなど、カスタマイズされたインデックスを定義することができます。
Zenには以下の2つの大きな問題点がありました。
-
データの不整合
HBaseは複数のテーブルをまたがったトランザクションや複数の行にまたがったトランザクションに対応していなかったため、不整合なデータが原因で多くの問題が生じました。ユーザーは混乱しました。彼らはデータの整合性を確保するためにさらにコーディングを行わなければなりませんでした。 -
クエリサポートの制限
HBaseの機能は限られていたため、結合のような複雑なクエリを実行するのが困難でした。
Ixiaの問題点
Ixiaはインハウスのインデックスデータストアです。これはHBaseとMuse（インハウスのインデックスエンジン）上に構築されています。当社はCDCを使用して非同期インデックス作成を行っています。信頼できる唯一のデータソースは、HBaseに書き込まれます。検索エンジンに各インデックスを非同期的に構築しています。
Ixiaの主な問題点は以下のとおりです。
- インデックス障害やインデックスの不整合が発生するときがある。不整合に関する問題をデバッグするため、フラストレーションが溜まったユーザーと共に多くの時間を費やしました。
- システムが複雑なため、問題診断に時間がかかる場合がある。
このため、この状況にスムーズに対処できる新しいストレージソリューションを探していました。
新しいストレージの探求
現在、当社のストレージソリューションには理想との乖離があり、以下の要素が欠落しています。
- 分散トランザクションのような機能。この機能があれば、必要に応じて厳密な整合性や優れたパフォーマンスを実現できます。このことは、オンラインアプリケーションにとって非常に重要です。
- SQLとの互換性。これにより、表現力豊かなクエリを実行し、シームレスなエクスペリエンスをユーザーに提供できます。
念頭にあったのは、Google Spannerのようなものでした。そこで、オープンソースの分散型SQLシステムを探求することになりました。
分散型SQLの探求
インハウスシステム、オープンソーステクノロジー、クラウドソリューションなど15種類のテクノロジーの評価を行いました。
オペレーション上の負荷、移行コスト、プログラミング言語、コミュニティサポート、コスト効率など、さまざまな要素について検討しました。その中でもオープンソースの分散型SQLシステムに注目しました。調査の最終段階で、YugaByteDB、CockroachDB、TiDBの3種類の候補に絞られました。そしてTiDBを選択しました。安定性とパフォーマンスに関する当社の要件を最もよく満たしていたからです。
TiDBとは？
TiDBは、ハイブリッドトランザクション分析処理（HTAP）ワークロードに対応したオープンソースの分散型SQLデータベースです。MySQLとの互換性を持ち、水平方向の拡張性、厳密な整合性、優れた可用性を備えています。TiDBのアーキテクチャの詳細については、こちらをご覧ください。
TiDBを使用した評価
Pinterestの実稼働トラフィックを使用してダークトラフィックの評価を行いました。ターゲットシステムとしてIxiaを使用しました。これはほぼリアルタイムでインデックスを作成するシステムであり、下図に示すとおり、HBase上にあります。
ダークトラフィックの評価
上図の説明
- 左側にあるのがIxiaのアーキテクチャです。ご覧のとおり非常に複雑です。HBaseとCDCパイプラインがあります。IxiaとThriftサーバーがあります。また、Memcacheと検索エンジンが使用されています。
- 右側にあるのがTiDB上に構築されたダークトラフィックアプリケーションです。
TiDBのアーキテクチャはIxiaよりもずっとシンプルです。
TiDBがもたらしたメリットは以下のとおりです。
- システムの複雑性の低下、整合性の向上。これはTiDBが分散トランザクションに対応しているためです。
- インフラストラクチャコストの軽減。これはコンポーネント数が減少したためです。
- 同等のパフォーマンス（場合によってはさらに優れたパフォーマンスも）— 同一タイプのクエリの場合です。
この結果は、当社のユースケースのうちの1つに過ぎません。他のユースケースについても評価を行いましたが、総じてTiDBのパフォーマンスと信頼性は満足のいくものでした。
TiDBの課題と機会
コラボレーションを継続する中で、新しいチャレンジについて、また、Pinterestのような会社にとってTiDBをさらに有益かつ強力にできる方法や場面について検討しています。例をいくつか挙げます。
- TiDBは、コミュニティで高い人気を博しており、今なお進化し続けています。当社は、TiDBがこれから製品としてさらに成熟し、機能を増やしていくことを期待しています。
- また、クォーラムが失われた場合に、オンラインリカバリが実行される機能を期待しています。
- Pinterestは米国外にも事業を展開する予定です。当社にとってのもう1つの重大な関心事はマルチリージョンデプロイメントです。
- また、数百テラバイト規模の大規模データを高速で取り込める優れたソリューションを期待しています。
- HBaseに非常に大きなエコシステムがあるため、HBaseからTiDBにダウンタイムゼロで移行できる方法をいまだ模索中です。
TiDBをどのように活用しているのかもっと詳しくお知りになりたい場合、または何か質問がある場合は、SlackのTiDBコミュニティにご参加ください。TiDBに興味が湧きましたら、こちらから使い始めることができます。
この記事は、Lianghong XuがPingCAP DevCon 2021で行った講演を基に作成されたものです。
本件に関するお問合わせ先
PingCAP株式会社 広報部
Mail：pingcapjp@pingcap.com