- 著者: @voluntas
- S3 と書いたら S3 互換オブジェクトストレージを含みます
- どうして DuckDB を使い始めたのか
- 自社製品関連の統計情報を解析したい
- BigQuery はサービスないので採用しなかった
- TSDB を利用する事にした
- InfluxDB と比較して Postgres も利用できる TimescaleDB を利用した
- sqlc を使いたかった
- TimescaleDB は日本リージョンにマネージドがある
- コスト面では特に優位性はない
- 別に早くない、ため込む場所としては便利
- 継続的集計機能もあるが、使い方が難しい
- InfluxDB と比較して Postgres も利用できる TimescaleDB を利用した
- ClickHouse を検討
- データベースは運用したくない
- クラウドサービスは一度導入すると変更が厳し
- コスト面で優位性がない
- 統計情報自体が価値を生むサービスではない
- 統計情報はあくまでおまけ
- 最初は自社の CLI ツールに組み込む予定で DuckDB を検討していた
- 自社製品のログ解析ツールとして、ログを一時的に読み込ませる場所として SQLite を検討していた
- SQLite に JSONL ログを追加する
- DuckDB は解析が楽そう、さらに JSONL の tar.gz がそのまま読める
- さらに複数ファイルも同時に読み込める！
- 自社製品のログ解析ツールとして、ログを一時的に読み込ませる場所として SQLite を検討していた
- DuckDB が想像以上に S3 とちゃんと連携できていることを知る
- S3 -> DuckDB -> S3 ができる
- Postgres -> DUckDB -> Postgres ができる
- これはすごい、さらに S3 では
*が利用できる
- 自社製品はクライアントから 15-60 秒間隔で、JSON で統計情報が送られてくる
- JSONL としてログに出力する仕組みがある
- 統計情報なので、一定間隔の情報が必要不可欠
- リアルタイムでの解析はほぼ求められていない
- もし求められたら、それこそ duckdb サーバー立てておいて、シングルスレッドでもいい
- 単一障害点で問題無い
- リアルタイムに問題を解析したから、問題を解決できることはない
- 利用後に後で解析したいが多い
- 5 分くらいの遅延は問題無い
- 既に Postgres を利用したジョブキューモドキの仕組みがある
- S3 へのログの保存は Fluent Bit を利用
- Plugin S3 を利用する
- Rewrite Tag 機能を使うことで S3 のパスをかなり自由にいじれる
- DuckDB は顧客向けの解析
- 集計結果を Parquet にして S3 に保存
- 顧客は Parquet ファイルをダウンロードして集計
- 社内向けは DuckDB は採用せず、VictoriaLogs を利用する
- https://victoriametrics.com/products/victorialogs/
- https://docs.victoriametrics.com/victorialogs/index.html
- 社内向けの利用は Grafana との連携が必須なため
- Fluent Bit を利用して S3 に JSONL ログを gzip 圧縮で保存
- Fluent Bit の Rewrite Tag を利用する事で JSONL ログの中身毎に S3 のパスを変えられる
- これを利用する事で全探索を避ける
- Fluent Bit の Rewrite Tag を利用する事で JSONL ログの中身毎に S3 のパスを変えられる
- 顧客の利用が終わったら自社製品はウェブフックを飛ばすのでそのウェブフックをトリガーに解析をする
- Postgres に解析のジョブキューを突っ込む
- この時、解析のジョブキューは
SKIP LOCKEDを利用している
- この時、解析のジョブキューは
- ジョブワーカーは systemd/Timer を利用して 1 分毎にジョブを確認しにいく
- Postgres に解析のジョブキューを突っ込む
- ジョブワーカーで顧客が利用した ID で S3 の統計情報を集計して Parquet ファイルを生成する
- Parquet だけじゃなくて TimescaleDB に保存してもよい
- Parquet ファイルは公開用の S3 バケットを用意する
- S3 のポリシーを利用して古くなったログは気軽に捨てられる
- データベースを利用すると削除は大変
- 非同期可視化
- そもそも必要なときにしかダッシュボードの可視化は見られない
- であれば必要なときにリクエストしたタイミングで可視化情報を作ればいいのでは？
- ログは S3 にため込んでおいて、そのログを解析して Parquet ファイルを作る
- Parquet ファイルを S3 署名付き URL で https:// でアクセスできるようにして DuckDB-Wasm で読み込ませる
- DuckDB-Wasm がサイズ的にちょっと重いのが気にはなってる
- Parquet は 1 テーブルなので、毎回それを読み込む
- キャッシュも使える
- 変更されるデータではないので、キャッシュは長めに持たせる
- 事前に解析用の SQL を用意しておくか、解析結果を表示させるだけかは悩ましい
- 解析結果の表示だけなら JSON データを作っておいて、それを https:// でアクセスさせるだけでもいい
- Parquet ファイル自体はサイズは小さめで提供する
- Parquet ファイルはざっくり集計に抑えて、実際の集計は DuckDB-Wasm でやる
- duckbox 形式 (DuckDB の生成するファイル) を ATTACH する事で複数テーブルにも対応できる
- duckbox を S3 において DuckDB で解析して貰う
- ブラウザから取得できる統計情報を DuckDB-Wasm に保存する
- ローカルでの解析する仕組みを SQL で提供する
- OPFS に対応しないと永続化ができないので難しい
- これは解決したいなと考えている
- ミドルウェアソフトウェアのログを Parquet ファイルとして提供する
- ClickHouse クラウドは月 500 ドル程度かかる
- S3 は Akamai Connected Cloud の Object Storage を利用する
- ストレージ費用は 1 TB で月 20 ドル
- 転送量は 1 TB 無料枠があり、 1 TB で月 5 ドル
- ジョブワーカーはメモリが必要であれば Linode の High Memory プランを利用
- 月 60 ドルで 24 GB のメモリが利用できる
- https://www.linode.com/pricing/#compute-high-memory
- そもそも 1 解析でも 1 GB のメモリが必要になることはほぼ無い
- 解析結果を何日保存するかによるが、 1 ヶ月で 2.5 TB でも月 50 ドル程度で済む
- SQL が得意ではない自分にはとても良い
- MotherDuck もこの方向性で製品を作っている
- Text to SQL こそ SQL のテストを書くべきだと思っている
- Python DuckDB API + Testcontainers で書けないか
- DuckDB の SQL を書くのに sqlc を使いたい
- ただ動的にスキーマーが決定するため、難しい
- 課題が多いのでもう少し使い込んでから様子見