はてなブックマーク

前提 DuckDB が使える環境 Docker Compose が使える環境 まとめ DuckDB から直接 PostgreSQL にアクセスできる PostgreSQL の読み込みも書き込みもできる バッチ処理を PostgreSQL のリードレプリカからデータを読み込んで、DuckDB で集計して PostgreSQL に書き込むと言うのができる DuckDB とは こちらをどうぞ。 DuckDB雑紹介(1.1対応版)@DuckDB座談会 - Speaker Deck PostgreSQL Extension 名前で誤解しやすいのですが DuckDB の PostgreSQL Extension であって、PostgreSQL の Extension ではないので注意してください。 DuckDB のPostgreSQL Extension は PostgreSQL のデータを直接操作で

時雨堂の自社サービスのアピールが含まれます 概要 これは自社サービスの管理者用ダッシュボードのログ解析機能として DuckDB-Wasm を採用したので雑に紹介します。 DuckDB とは こちらをどうぞ。 DuckDB雑紹介(1.1対応版)@DuckDB座談会 - Speaker Deck まとめ DuckDB-Wasm を利用する事でクライアントリソースが利用できるようになった Parquet ファイルを OPFS に保存できるようになり、オフラインで利用できるようになった 自分が求めるレベルでの可視化は全て DuckDB/DuckDB-Wasm で十分だとわかった ダッシュボードの実装 自社が提供している 自社パッケージ製品を検証できるサービス の管理者用ダッシュボード(以降ダッシュボード)で DuckDB-Wasm を利用してログ解析をブラウザ上で実現しています。 Fluent B

概要 なぜ 自社 で DuckDB を採用したのかを、雑に書いていきます。 変更履歴 2025年03月12日: DuckDB の開発体制と Zstandard で圧縮されたファイルの読み込みについて追記 2025年02月13日: 今後やりたい事 v2 を追記 まとめ DuckDB / DuckDB-Wasm を利用する事で中小規模のサービスであれば、ログ解析や統計情報の可視化を低コストで提供することができる DuckDB を go-duckdb 経由で利用する事で、HTTP リクエスト単位での DuckDB を利用できる DuckDB-Wasm と OPFS を利用する事で、クライアント側での統計情報のため込みができるようになる 解決したい課題 解決したい課題は基本的にサービスの運用費を抑えるということです。中小規模のサービスでは運用費が大きな課題になります。 自社パッケージ向けのログ解析ツー

前提 DuckDB が使える環境 Docker Compose が使える環境 まとめ DuckDB から S3 互換オブジェクトストレージを利用する際、MinIO を使う事で、ローカルに気軽に S3 互換オブジェクトストレージ環境を用意できる。 DuckDB とは こちらをどうぞ。 DuckDB雑紹介(1.1対応版)@DuckDB座談会 - Speaker Deck MinIO とは MinIO はオープンソースの S3 互換オブジェクトストレージです。 DuckDB は S3 API 機能を持っており、S3 互換オブジェクトストレージとの相性がとても良いです。 ローカルで試したい時などに Docker Compose で MinIO を用意して利用すると、とても便利です。 Docker Compose ローカルということでセキュリティは一切考慮していません MinIO のイメージを pu

まとめ 圧縮された複数の JSON Lines を読み込める S3 から直接読み込める 好きなタイミングで Parquet で出力 DuckDB とは こちらをどうぞ。 DuckDB雑紹介(1.1対応版)@DuckDB座談会 - Speaker Deck 圧縮済みのログを読み込む 解析対象のログファイルって spam-20240501.jsonl.gz や egg-20240601.jsonl.zst みたいに圧縮されていたりします。 特に日付単位で分かれてたりすることは多いです。そこから目的のログを探し出すのは、基本はスクリプトを書くことが多いと思います。 DuckDB を使えば色々解決します。

前提 ミドルウェアのログ可視化 ログサイズは全体で 1 TB 未満 ログは jsonl で出力される まとめ 非同期での可視化 オフラインでの可視化 低コスト DuckDB とは こちらをどうぞ。 DuckDB雑紹介(1.1対応版)@DuckDB座談会 - Speaker Deck サンプル とりあえず動くのが見たい人用です。ソースコードも公開してます。 DuckDB-Wasm + Parquet + S3-compatible object storage + OPFS S3 から Parquet ファイルを fetch して DuckDB-Wasm への登録 OPFS へ Parquet ファイルの保存 OPFS から Parquet ファイルの読み込み DuckDB-Wasm へ登録 SAMPLE 1 の出力 SAMPLE 1 での検索 SAMPLE 1 での Parquet ファイ

長くパッケージソフトウェアとしてのミドルウェアを開発してきて、ミドルウェアとウェブフックの組み合わせがとても良いと感じているので、雑にまとめていこうと思います。 まとめ ミドルウェアとウェブフックの組み合わせはお勧め。 戦略 ミドルウェアに永続化情報を持たせない ミドルウェアから直接データベースを引く仕組みを持たせない ミドルウェアにプラグインの仕組みを持たせない データベースを直接引く仕組みを持たせない 自分がミドルウェアを開発したときは、ミドルウェアがデータベースを引く仕組みを持っているというのが一般的でした。 ただこれ、どのデータベースに対応するのかという問題がでてきます。 PostgreSQL や MySQL や Oracle や SQL Server などなど、対応するデータベースが多いと、ミドルウェアの開発者は大変です。 RDB だけでなく LDAP や Redis といったデ

2024 年 12 月 25 日追記 sqlc と sqlc-gen-typescript は積極的なメンテナンスがされていないため、採用するときは注意してください。 まとめ sqlc-gen-typescript かなり良い 自分が TypeScript でウェブアプリを利用するなら間違いなく sqlc を選択する SQL は共通言語という点で本当に偉大 sqlc とは sqlc とは Go で書かれた SQL を元にコードを生成するツール。 なぜ sqlc ? 結局、それぞれの ORM 固有の技術を覚えるくらいなら SQL を覚えた方が早い 拡張に ORM が対応していようがいまいが関係ない SQL パーサーが libpg_query という実際の PostgreSQL サーバーソースを使用している wasilibs/go-pgquery を利用しているので信頼できる Wasm 化され

pytest で E2E テストが本当に便利です。 実際どう使っているかを紹介しておきます。 なぜ Python でテストなのか 自分が Python に慣れている 自分にとって pytest を超えるテストランナーが今のところない SpaceX がテストを Python で書いてて、じゃぁ Python でいいかとなった https://old.reddit.com/r/spacex/comments/gxb7j1/we_are_the_spacex_software_team_ask_us_anything/ft0bz35/ We use C & C++ for flight software, HTML, JavaScript & CSS for displays and python for testing. Rye のおかげで Python の環境構築が苦にならなくなった htt

これは一部時雨堂製品の宣伝記事になっています 前提 著者は OBS に関してはまったくの初心者 WebRTC に関しては商用の WebRTC SFU を 1 から開発、販売している会社を経営している WHIP については WebRTC のシグナリング規格 WHIP と WHEP について をどうぞ まとめ OBS の WHIP の方向性は良い それ以外の WHIP 実装は正直いまいち クローズドソースの WHIP 実装が増えるの良くない流れだとおもう OBS WHIP とは 凄く簡単に言うと OBS から WebRTC で直接配信できるようになる仕組み。 こんな感じの遅延でブラウザなどへの配信が可能になる。 OBS WHIP の現状 OBS 30.0.0 で WebRTC/WHIP が利用可能になった。 WHIP 対応機能 WHIP エンドポイント URL の設定 H.264 による配信機

10Gbps Unmetered Dedicated Servers | DataPacket.com を自社サービスに採用して 1 年以上過ぎたので振り返ってみます。 追記: 2024年08月23日 DataPacket から Akamai Connected Cloud へ切り替えました 自社製品が Raft ベースの分散システムになり、軽量なサーバーを大量に上げる事でスケールアウトが可能になっためです DataPacket 自体は利用中に障害は一切なく、サポート対応も素晴らしかったです 前提 著者は選定と調達を担当しています 著者は運用や構築に関して素人であり、実際の運用や構築は行っていません オープンになっていない価格については一切書きません 自社製品は Raft ベースのクラスター機能を持っています まとめ (2024年03月03日 版) DataPacket の利用で不満は今のとこ

これは一部時雨堂製品の宣伝記事になっています 自社製品で WHIP に対応し、 WHEP にも対応していっいるので、雑に書いておこうと思います。 プロトコルの細かい説明などはしていないので、各自 ChatGPT に聞いたりして調べてください。 まだドラフト段階のプロトコルなので、今後仕様が変わっていきますので要注意です。 定期的にアップデートしていきます。 WHIP / WHEP とは WHIP / WHEP とは簡単に言うと WebRTC でのシグナリングの規格です。 なぜそんな規格が必要なのか?、実は WebRTC ではシグナリングの規格は存在しません。 自由です。なので各種サービスで独自のシグナリングを実装しています。 なぜシグナリングの規格がないと困るのか、WHIP の言い出しっぺ方から聞く機会があり、OBS への対応が目的という話でした。 OBS はもともと MS が提供していた

ちまちまアップデートしていきます 前提 時雨堂 が実際に利用している機能を中心に紹介しています OTP 26.2.1 ベースに書いています この資料が以下の書籍を読んだ人にとって、最近の Erlang/OTP の動向をキャッチアップする手助けになればと思います。 プログラミング Erlang https://shop.ohmsha.co.jp/shopdetail/000000001784/ すごい Erlang ゆかいに学ぼう! https://www.ohmsha.co.jp/book/9784274069123/ https://tatsu-zine.com/books/sugoi-erlang-ja また、Erlang/OTP を利用した製品がより多く生まれるといいなというお気持ちもこっそりあります。 書籍の Erlang/OTP のバージョンについて プログラミング Erlang

まとめ Erlang/OTP の分散機能利用時のサーバー間通信はデフォルトでは暗号化されていない Erlang/OTP が提供する分散機能の暗号化は TLS を利用する Tailscale で P2P VPN をサーバー間で張って Erlang/OTP の分散機能オススメ Erlang 分散機能 時雨堂で開発しているミドルウェアソフトウェアは Erlang/OTP (以下 Erlang) を利用しています。 Erlang は分散機能が入っています。分散機能を簡単に説明すると、他のサーバーにある Erlang とやりとりができる仕組みです。 このときにサーバ間を利用する際に、暗号化が必要になりますが、Erlang が標準で提供為てる機能はサーバー間通信を TLS にする方法がありますが、Erlang に TLS 処理させるのは CPU も食べるしお勧めはできません。 Erlang -- Us

現在は 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 拡張機能 を利

PostgreSQL (TimescaleDB) で SKIP LOCKED という機能がある事を知ったため、自分用のメモ。 目的 最大処理時間が数十時間かかる可能性があるワーカーの管理に、MQ 的な仕組みを使いたいと考え、できるだけ楽に使える仕組みを検討することにした。 クラウドのサービスは利用しない AWS / GCP / Azure といったサービスを普段から利用していない Go で利用できること 普段の負荷は 1 時間 10 リクエストもない 負荷対策での利用ではない MQ をもし使う場合は RabbitMQ だが、今回はオーバーキル Erlang VM で、ソースも一通り読んだことあるので、何かあってもなんとかなる 一つの処理が数十時間かかることもあり、ジョブにはキャンセルをできるようにしたい 処理が終わるまでは Ack を返さない仕組みが必要 Redis の検討 MQ を除くと

mTLS を利用することで、クライアント・サーバー間で強固な認証の仕組みを簡単に導入することができます。 今回は Go で書いたバッチ処理の結果を Cloudflare Workers 経由でデータベースに保存した歳に、 Go から Cloudflare Workers へのアクセス制御に Cloudflare mTLS を採用したので、まとめておきました。 個人的に mTLS (Clouddflare mTLS) を流行らせたいという思いもあります。 Go のコード package main import ( "crypto/tls" "crypto/x509" "io" "log" "net/http" "net/url" "os" "time" ) const ( // mTLS を有効にして保護している URL // クライアント証明書が無い状態でアクセスするとエラーコード 102

2021 年に Google が Lyra という低ビットレート音声コーデックを公開しました。 今までの音声コーデックとは異なり機械学習を利用した音声コーデックです。 残念ながら 2021 年の Lyra は速度や音質は実戦投入は難しいという感じでしたが、 2022 年に Lyra V2 として速度、音質が最適化されたバージョンが公開されました。 Lyra は機械学習を利用したコーデックで、 TensorFlow Lite を利用しています。このコーデックと機械学習の組み合わせは今後のデファクトスタンダードになっていくと考えています。 Lyra の簡単なまとめ ビットレートは 3.2 kbps / 6 kbps / 9.2 kbps で利用可能 Opus の場合音声通話用のビットレートは 24 ~ 32 kbps あたりを利用 Opus 自体は 7.1 ch とかにも対応しているので 51

利用しているサービスに何か障害が起きたとき真っ先に見に行くのがステータスページですが、ステータスページ作るのはめんどくさいです。 そこで自社で利用しているステータスページサービスを簡単に紹介したいと思います。 OnlineOrNot - Free Status Pages and Uptime Monitoring - OnlineOrNot 仕組みとしては定期的に指定された URL をチェックしにいくというシンプルなものです。 ちなみに、時雨堂のサービスのステータスページは以下になります。 どんな感じかのイメージをつかんでもらえるといいかなと。 Shiguredo Inc. Status プラン 5 URL までは無料で使えます。カスタムドメインや URL を増やしたい場合は有料です。 さらにこれ Team プランだとプライベートステータスページも提供してくれるようです。 Plans &

追記: 2024年07月20日 Testcontainers を使いましょう。 概要 dockertest は go でテストを書く際に docker 経由で指定したコンテナを起動してくれてテストが終わったらコンテナを削除してくれる便利ライブラリです。 モチベーション 時雨堂では TimescaleDB という PostgreSQL に TSDB 拡張を追加した少し変わった RDBMS を利用しています。 TimescaleDB 専用の関数があったりするため、モックなどを使わずにテストを書くのが現実的です。 dockertest ory/dockertest: Write better integration tests! Dockertest helps you boot up ephermal docker images for your Go tests with minimal wo

時雨堂では自社サービスを提供する際には OSS 開発元の商用製品を利用するようにしています。 のサービスを使っている話を聞かないので、せっかくなのでこんなのもあるよということで紹介していきます。 Ubuntu Pro 時雨堂では OS は Ubuntu LTS に統一しています。 そんな中でベアメタルサーバーで利用している Ubuntu では Ubuntu Pro の INFRA-ONLY を契約して利用しています。 ベアメタル(物理サーバー)なので 1 サーバーあたり年 225ドル かかります。 主な目的は Kernel Livepatch service to avoid reboots です。 セキュリティパッチを当てる際に可能な限り再起動をしなくてよくしてくれます。 コンテナ時代に再起動とか何言ってんだと言われるかもしれませんが、 ベアメタル利用がメインのサービスを運用しているので重

Cloudflare で mTLS を利用するのがあまりにも簡単だったので書いておきます。 mTLS について 一般的に TLS を利用する場合は「クライアントがサーバーから送られてきた証明書を検証する」という仕組みを利用し、 信頼できる機関が発行した証明書を利用しているかどうかや証明書のドメインが一致しているかどうかなどを確認します。 mTLS (mutual TLS) というのは TLS 利用時に「クライアントから送られた証明書をサーバが検証する」という仕組みです。 つまりサーバーがクライアントがわから送られてくる証明書を確認するというフェーズが挟み込まれます。 この証明書自体は何を使ってもよく、オレオレ証明書でもかまいません。 クライアント側に証明書を設定するという仕組みです。VPN とかを利用したりする方は経験があるかもしれません。 mTLS はめんどくさい クライアント側に証明書

定期的に更新していく https://github.com/voluntas/webapp-template TimescaleDB 利用版 https://github.com/voluntas/webapp-sqlite-template SQLite 利用版 方針 自分が良いなと思った技術を使う 難しいことはしない SQL を頑張る バックエンドは Go と sqlc 開発者は最大でも 3 人を想定 運用コストを減らす 負荷は秒 1000 リクエストを処理できれば十分 Remix ありき Cloudflare Workers ありき Cloudflare Zero Trust ありき マルチクラウドは Cloudflare Load Balancing ありき できるかぎり OSS 開発元の SaaS を利用 監視なども含める 宣伝 自社 SaaS が実際に利用している技術は Zen

定期的にアップデートしていきます 自分の立ち位置 商用 WebRTC SFU のプロトコルスタック実装経験あり QUIC プロトコルタック実装経験あり WebTransport への理解 WebTransport over HTTP/3 の知識はあり WebTransport over HTTP/2 の知識はあり WebRTC 的な利用をする場合の結論 WebTrasnport を WebRTC 的な利用をする視点からの結論です。 WebTransport は WebRTC のような MediaChannel / DataChannel からみたら圧倒的に仕組みが足りてないので、 WebTransport の上にそれらの仕組みを作り込める必要があります。 実際 Media over QUIC のメーリングリストでは RTP over QUIC という話がでているくらいです。 結局メディア専