Pinterest、OpenTSDBから独自の時系列データベースに切り替え

2014年以降、Pinterestのエンジニアリングチームは、メトリクスのストアおよびクエリのためのエンジンとしてOpenTSDBを使ってきた。しかし、メトリクスデータ量の増大による様々なパフォーマンス問題のため、彼らは独自の時系列データベースを開発することにした。それはGokuと呼ばれ、C++で書かれており、OpenTSDBに準拠したAPIを備えている。

Pinterestの開発チームは、Statsboardというシステムを使っている。これはGraphite、Ganglia、OpenTSDBからのメトリクスをYAMLによる宣言的な設定で統合するダッシュボードだ。2012年初め、PinterestのモニタリングにはGangliaが使われており、システムメトリクスだけを収集し、アプリケーションメトリクスを収集していなかった。その後、アプリケーションメトリクスのためにstatsdを使ったGraphiteが開発され、続いてクラスタ化したGraphiteがデプロイされた。2014年にはOpenTSDBがデプロイされた。カスタムのメトリクスエージェントを使って、処理パイプライン経由でデータをKafkaクラスタにプッシュし、それをOpenTSDBとGraphiteにプッシュした。数年前の時点で、OpenTSDBのスループットは150万ポイント/秒だったという。PinterestチームはJavaのGC問題と、OpenTSDBがバックエンドストアとして使っているHBaseの頻繁なクラッシュに直面した。Pinterestには、多数のサービスのために巨大なHBaseデプロイメントがあったのだ。

彼らの自社製時系列データベースエンジンであるGokuは、OpenTSDBの特定の領域を改善しようとしている。これには、HBaseスキャンの代わりに転置インデックスを使用すること、データポイントの圧縮改善、クラスタ化したクエリ集約、高速なシリアライゼーション形式といったものが含まれる。GokuはFacebook Gorillaインメモリストレージエンジンを使って最近のデータを格納し、NFS上の永続ストレージを備えている。PinterestはEC2にホストされているが、彼らがAWS EFSを使っているのか、自前のソリューションを使っているのかは、記事からはわからない。著者によると、再起動時にはディスクからメモリにデータを読み戻すという。

Gokuのクエリモデルは、OpenTSDBと同等だ。シャード間でクエリを展開・集約するため、チームは独自のクエリ集約レイヤーを書いた。Gokuは2レベルのシャーディング戦略を用いている。これはメトリクス名のあとにタグキー-バリューのペアを続けることに基づいている。クエリはGoku proxyによって処理され、個々のGokuシャードに送られる。シャードは転置インデックスを使ってリクエストされた時系列のidを得てデータを取得し、個々のアグリゲーター（ダウンサンプリング、集計など）を実行し、それをproxyに送り返す。proxyは2周目の集約後、それをクライアントに送り返す。Gokuによるもうひとつの改善は、OpenTSDBのJSON形式の代わりに、Apache Thriftのバイナリデータ型を使うことだ。

Gokuは、Pinterestにおけるデータセットサイズだけでなく、遅延やリソース要件も低下させた。GokuはC++で書かれており、OpenTSDB APIに完全に準拠している。Javaで書かれたYuviという別のPinterestプロジェクトはGokuと多くの類似点がある。この他、Vivint、Uber、Improbable、Criteoといった時系列メトリクス収集/クエリシステムが作られ、あるいはカスタマイズされている。