現在は TimescaleDB から Akamai Connected Cloud の Managed Database (PostgreSQL) への移行を進めています。

移行理由

Managed Service for TimescaleDB の費用が高い
サポート対応があまり良いとは言えない
サービス全体を Akamai Connected Cloud へ移行したため、統一したい
TimescaleDB は期待した性能はでなかった
PostgreSQL 拡張は扱いづらかった
TSDB の集計が PostgreSQL で行うとリソースを食べ過ぎる

Akamai Connected Cloud の Managed Database (PostgreSQL) と Object Storage という組み合わせへ移行します。
集計処理は DuckDB の PostgreSQL 拡張機能を利用します。DuckDB から直接 PostgreSQL へアクセスする仕組みです。

TimescaleDB を自社サービスに採用して 1 年以上過ぎたので振り返ってみます。

前提

著者は SQL に関して TimescaleDB を採用を決めたタイミングから勉強した初心者です
Managed Service for TimescaleDB を採用しています

まとめ

TimescaleDB の利用で不満は今のところない
sqlc との組み合わせは最高
開発会社が提供するマネージドサービスは最高

なぜ TimescaleDB を採用したのか

統計情報のため込みと集計

自社製品であるミドルウェアパッケージソフトウェアのクラウド版を提供するにあたり、何よりも重視したのは統計情報の提供です。それもサーバーの統計情報ではなく接続単位での接続情報を顧客に提供することです。

自社製品はリアルタイムに音声や映像を配信する製品ということもあり、一定間隔での統計情報の収集が重要になります。ネットワークが不安定になったタイミングの統計データが残っていないようでは意味がありません。

大量の統計データをため込み、バッチ処理をしたいと考えていました。最初はお手伝い先でもがっつり使っている BigQuery を検討していましたが、主要クラウドサービスは可能な限り使いたくない事と、そもそも RDB に入ってる情報と統計情報を組み合わせて出力したいと考えていたため、接続単位の統計情報も同じデータベースに保存したいと考えていました。

そこで、見つけたのが PostgreSQL の拡張として TSDB を提供している、TimescaleDB です。

PostgreSQL としての機能は全て使えて、かつ統計情報をため込む部分だけ TSDB 化でき、さらに RDB 部分と TSDB で JOIN が使えて、集計用の専用関数がある、文句ありませんでした。

sqlc との相性

もともとデータベースと通信をするバックエンドサーバは Go で開発しており、sqlc という SQL をコンパイルして Go のコードを出力するツールを採用していました。そのため、RDB は sqlc の対応が充実している PostgreSQL 一択でした。

sqlc は TimescaleDB 独自の関数を完全に無視してくれるのも、とても助かりました。ORM などを採用すると TimescaleDB のような独自拡張が含まれている RDB とは相性が悪い気がします。

ログ保存もできる

自社のミドルウェアが吐き出すログファイルの保存も考えていました。最初は S3 互換オブジェクトストレージに保存することを検討していたのですが、取り出したり集計したりするのがめんどくさいということがあり、色々検討したところ、Fluent Bit の PostgreSQL 機能を利用することで、実現したいことが可能なことがわかりました。

自社のミドルウェアが吐き出すログファイルはほとんどが JSON 形式です。そのため TimescaleDB 側に JSONB カラムを用意する Fluent Bit の PostgreSQL 機能ととても相性が良いことがわかりました。

さらに TimescaleDB には Compression と Data Retention という二つの機能があります。

Compression はその名の通り、圧縮です。一定期間経ったデータを圧縮することでディスクストレージの容量を減らすことができます。一定期間は自由に指定することができます。

Data Retention は一定期間経ったデータを自動的に破棄してくれる仕組みです。何も考えることなくログを入れても容量を圧迫する事がありません。

以下は実際に利用している TimescaleDB を利用したログファイルの設定です。

ALTER TABLE auth_webhook_log SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'tag'
);

SELECT add_compression_policy('auth_webhook_log', INTERVAL '3 days');
SELECT add_retention_policy('auth_webhook_log', INTERVAL '90 day');

認証ウェブフックのログデータを Fluent Bit の PostgreSQL 経由で TimescaleDB に送り、3 日経過したら圧縮、90 日経過したら破棄しています。

これはあくまでログの保存であり、認証ウェブフックの値は別に保存していますので、破棄しても問題ありません。

さらに PostgreSQL は JSON を処理するクエリーがあるのも重要です。ここでは説明は省略しますが、思った以上にやりたい放題できます。 JSON関数と演算子

事前に sqlc でクエリーを作っておけば Go から気軽に呼び出せるのも良いです。

TimescaleDB の導入

クラウドサービスを採用

まず導入するに当たって自前運用をするべきかを検討しましたが、どう頑張ってもリスクが高すぎるということで、Timescale 社が提供しているクラウドサービスを利用することにしました。

Timescale 社が提供しているクラウドサービスは二つあります。

Timescale Cloud というサーバーレスモデルで、スケールも気軽にできるバージョン。ただしこれは日本リージョンがありません。そのため採用は見送りました。

Managed Service for TimescaleDB というマネージドモデルです。これは AWS / GCP / Azure を利用して Timescale 社で TimescaleDB をマネージドで提供してくれるサービスです。自社では GCP の Tokyo リージョンを採用しました。

実際クラウドサービスを採用して良かった点を箇条書きで上げておきます。

1 年以上運用して 1 度も障害は起きていない
TimescaleDB のアップデートがダウンタイム 0 で行える
スペックアップグレードがダウンタイム 0 で行える
Prometheus エンドポイントが用意されてる
PgBouncer が用意されている
メンテナンス時間を自分たちで自由に指定できる
- といってもダウンタイムはない
ログ、クエリー統計がウェブから確認できる
自動でバックアップしてくれて、リストアが簡単
mTLS が利用でき、かつ IP 縛りもできる

デメリットは今のところ特に感じていません。価格も控えめだと思います。

sqlc と組み合わせてどうだったか

最高でした。実際自社クラウドサービスの課金用の利用情報の集計などに TimescaleDB 固有の time_bucket 関数を使っていますが、性能面での不満はありません。

sqlc と TimescaleDB の組み合わせは大変良い選択だと感じています。

監視

監視は Managed Service for TimescaleDB が提供している Prometheus エンドポイントだけでは足りないと考え、PostgreSQL Server Exporter を別途立てています。

蛇足ですが自社では Prometheus ではなく VictoriaMetrics という Prometheus 互換の監視ツールを採用しています。これは TSDB 内蔵でデータ圧縮効果がとても高く、シングルノードで安定して動くというのが強みです。

Grafana

社内向け可視化ツールとしては Grafana を採用しています。Grafana のデータソースに PostgreSQL を指定することができ、かつ TimescaleDB 専用のフィールド設定もあります。

Timescale Documentation | Set up TimescaleDB and Grafana

SQL でログの可視化が気軽にできるのは便利です。

Continuous aggregates

Continuous aggregates にはまだ、手を出せていません。それよりもやることが山ほどあるからです。ただ、継続的かつ増分的に更新していける仕組みはとても魅力的なので、落ち着いたら使っていこうと思っています。

Timescale Documentation | Continuous aggregates

導入前にさくらインターネットさんから直接事例を紹介して頂いた

実は日本の企業ではさくらインターネットさんが TimescaleDB を早い段階から実際に利用していて、 Timescale 社の採用事例にも掲載されています。

Explore Timescale Success Stories: SAKURA Internet | Timescale

ありがたいことに、知り合いのさくらインターネットの中の方が、実際に TimescaleDB を導入した人と繋いで頂き、導入した経緯、性能などを共有いただく事ができました。

実際に利用されている状況を伺ったところ、性能は自分たちが利用する範囲では充分な性能を出せていました。むしろ TSDB はそんなにも性能が出るのかと驚きました。

dockertest

TimescaleDB を導入するにあたり重視したのは E2E テストです。実際に TimescaleDB を Docker 経由で動かし、そこに対して sqlc を利用してテストを書きたいと考えていました。

この辺りは別の記事として書いてあるので興味あるかたはどうぞ。

dockertest のススメ

ライセンス

TimescaleDB は二つのエデイションが提供されています。

Apache License 2.0 ディション
- 利用制約が一切ない代わりに、いろいろ機能がありません
コミュニティエディション
- 全ての機能がある代わりに TimescaleDB をサービスとして提供することができません
- Timescale 社が提供しているマネージドサービス以外ではコミュニティエディションは利用できません
  - もし TimescaleDB に対応していたとしても Apache License 2.0 エディションです
- マネージドサービスやるんじゃねぇライセンスです

TimescaleDB Community Editionは、ご自身のオンプレミスやクラウドインフラにインストールし、無料で運用することができます。TimescaleDB Community Editionは、自社でサービスを管理する場合、完全に無料で利用できます。

自前で立てて使う場合は何も困ることはありません。ただ自分で立てるより絶対マネージドサービス使った方がいいです。

Timescale Documentation | Compare TimescaleDB editions

お試しする

docker で試すのが一番楽です。

Timescale Documentation | Install TimescaleDB from Docker container

$ docker run -d --name timescaledb -p 127.0.0.1:5432:5432 -e POSTGRES_PASSWORD=password timescale/timescaledb-ha:pg14-latest

雑感

TimescaleDB は RDB を利用しながら TSDB が使いたいサービスには最適な選択肢だと思います。また sqlc との相性もとても良く、開発が本当に楽です。

自社ではバッチ処理なども全部 sqlc を利用していますが、事前に sqlc でテストを書いて確認できるのも良いです。

TimescaleDB は大変お勧めです、是非使ってみてください。

自社のクラウドサービスの構成は公開してるのでもし良ければどうぞ。

時雨堂クラウドサービスを支える技術

Discussion