1 ポイント 投稿者 GN⁺ 2025-01-11 | 1件のコメント | WhatsAppで共有
  • QuickwitチームはDatadogに合流して新製品開発に注力し、コミュニティが継続できるようQuickwitの新バージョンをApache License 2.0で公開する予定
  • 出発点はElasticsearchのスケーリング限界と高い運用コストであり、Quickwitは10倍以上コスト効率が高く、マルチペタバイトまでスケールする検索エンジンを目指した
  • BinanceはQuickwitで100PBのログサービスを構築し、1日あたり1.6PBをインデックス化。Mezmoも数千の顧客とペタバイト規模のログを本番環境で処理している
  • オープンソースへの関心と売上の増加、Series Aの検討が続いた一方で、Tokyo・Paris・New Yorkに分散したチーム構造がスケール時の負担を大きくし、買収機会を検討した
  • Quickwitとtantivyには主要アップデートが予定されており、新しいQuickwitバージョンには分散取り込み、cardinality集計、性能・メモリ改善などが含まれる予定

Datadogへの合流とオープンソースの継続

  • QuickwitチームはDatadogに合流し、Datadogとともに新製品を作ることに注力する予定
  • コミュニティがQuickwitを引き続き発展させられるよう、新バージョンを近くApache License 2.0で公開する予定
  • Quickwitとtantivyの双方に主要アップデートが予定されている
    • 新しいQuickwitバージョンには、コミュニティが要望してきた分散取り込みが含まれる
    • cardinality集計、性能およびメモリ改善、その他の追加機能も入る予定

Quickwitが解決しようとした問題

  • Quickwitは、Paul、Adrien、Françoisという3人のエンジニアによる長年の協業構想から始まった
  • 2020年、Paulの個人プロジェクトだったtantivyがきっかけとなった
    • tantivyはLuceneの有力な代替としてすでに知られていた
  • チームが狙った中核的な課題は、Elasticsearchのスケーラビリティと運用コストだった
    • Elasticsearchが効果的にスケールしない
    • コストが高くなりすぎる
    • 運用の複雑さが増す
  • 目標は、運用者が安心して管理でき、マルチペタバイト規模までスケールし、少なくとも10倍コスト効率の高い検索エンジンを作ることだった

分散チームと初期のオープンソース開発

  • 開発は、AdrienがSan Francisco、PaulがTokyo、FrançoisがParisにいる分散チーム体制で始まった
  • 異なるタイムゾーンを活用し、follow-the-sun型の開発サイクルを作った
  • Rustの選択は、初期の開発速度と安定性に大きく影響した
    • Common Crawlデータセットで作った最初のデモがHNのフロントページに載った
    • ほとんどバグはなく、Pythonの"'NoneType' object has no attribute"エラー1件が例外として言及された
  • 最初のバージョンは2021年7月13日にリリースされた
  • オープンソースは戦略的な選択であると同時に、エンジニアとして自然な選択でもあった
  • HNでの露出は初期ユーザーとの対話につながったが、対話が増えるほど不足している機能が明らかになり、多くの実装が必要になった

大規模ユースケースとRustエコシステムへの貢献

  • MezmoとBinanceのエンジニアリングチームとの出会いは、Quickwitが実際の大規模製品へ発展する転換点となった
  • BinanceはQuickwitで100PBのログサービスを構築した
    • 1日あたり1.6PBをインデックス化している
  • MezmoはQuickwitを本番環境に投入し、数千の顧客とペタバイト規模のログを処理している
    • 同じユーザー体験を提供しながら、インフラコストと複雑さを大幅に削減した
  • これらのパートナーシップは、Quickwitがコスト効率の高いマルチペタバイト検索エンジンとして地位を築くことに貢献した
  • チームはQuickwitの開発過程で、Rustエコシステムの複数のライブラリにも貢献した
    • tantivy: Quickwitの基盤である全文検索エンジンライブラリ
    • chitchat: CassandraとDynamoDBに着想を得た、障害検知を含むクラスタメンバーシッププロトコル
    • Bitpacking: bitpackingによる整数圧縮向けSIMDアルゴリズム
    • Whichlang: Rust向けの高速で軽量な言語検出ライブラリ
    • Mrecordlog: マルチテナンシー向けに設計された効率的なwrite-ahead log

Datadogを選んだ経緯

  • 2024年夏、Quickwitはオープンソースへの関心拡大、売上の急増、VCからの積極的な関心を経験した
  • 会社は新たな章を開き、Series Aラウンドを進める時期だと判断した
  • しかし、Tokyo、Paris、New Yorkに分散したチーム構造はすでに大きな負担であり、スケールはこの難しさをさらに増す可能性があった
  • Quickwitは最終的に新たな居場所を探すことにし、買収機会を検討した
  • Datadogは候補の中で明確に際立っていた
    • Datadogのユーザー体験提供能力
    • Quickwitのペタバイト規模検索エンジン
    • 顧客環境にデプロイされる強力なソリューションを作る機会がかみ合った
  • 大企業に加わることへの当初の懐疑は、Datadogチームとの対話を経て消えた
  • Datadogチームとの対話の中で、知的能力、謙虚さ、真正性のある文化が確認された

コミュニティと顧客

  • Quickwitチームは、従業員、投資家、コントリビューター、友人、支援者に感謝を述べている
  • 顧客としてMezmo、Formal、Radiant Security、MatterLabs、Fly.ioなどが言及されている
  • コミュニティは、Quickwitの歩みの一部として共にいてくれた対象として感謝を受けている

1件のコメント

 
GN⁺ 2025-01-11
Hacker Newsの意見
  • Quickwitの共同創業者として、Datadogによる買収がHNのトップページに載ったのを見ると、本当に一周したような気分になる
    Quickwitの歩みは最初からHNと結び付いていて、その過程はHNのトップページに載った投稿にそのまま記録されている: “Searching the web for under $1000/month” https://news.ycombinator.com/item?id=27074481, “A Rust optimization story” https://news.ycombinator.com/item?id=28955461, “Decentralized cluster membership in Rust” https://news.ycombinator.com/item?id=31190586, “Filtering a vector with SIMD instructions (AVX-2 and AVX-512)” https://news.ycombinator.com/item?id=32674040, “Efficient indexing with Quickwit Rust actor framework” https://news.ycombinator.com/item?id=35785421, “A compressed indexable bitset” https://news.ycombinator.com/item?id=36519467, “Show HN: Quickwit – OSS Alternative to Elasticsearch, Splunk, Datadog” https://news.ycombinator.com/item?id=38902042, “Quickwit 0.8: Indexing and Search at Petabyte Scale” https://news.ycombinator.com/item?id=39756367, “Tantivy – full-text search engine library inspired by Apache Lucene” https://news.ycombinator.com/item?id=40492834, “Binance built a 100PB log service with Quickwit” https://news.ycombinator.com/item?id=40935701, “Datadog acquires Quickwit” https://news.ycombinator.com/item?id=42648043
    こうしたトップページ掲載はすべてマイルストーンであり、コミュニティに価値あるものを還元したいという思いで、エンジニアリング記事に本気で取り組んできた。HNは可視性、前向きなフィードバック、批判的なコメント、直接連絡してきたリードまで提供してくれ、Quickwitの成功に重要な役割を果たしたと確信している

    • リンクを載せ忘れているようだけど、とにかくTantivyは素晴らしい
      pg_search https://www.paradedb.com/blog/introducing_search が好きで、これは別の会社が作ったものだがTantivyの上に構築されているように見え、そこがオープンソースの大きな利点だと思う。ただ、今回の買収後に開発が止まるのではないかと心配している。Tantivyを公開開発し続けることが、Datadogの収益にどう役立つのか気になる
    • おめでとう。チームがTantivyを作ったこと自体が、オープンソースへの大きな貢献だ
      Apache Luceneベースの製品(Solr、Elastic)に愛着を持てなかった立場からすると、Tantivyがオープンソースとして登場したのは本当にうれしかった。BM25スコアリング、きちんとしたアジア言語対応、速度、メモリ使用量などが素晴らしい
      https://github.com/quickwit-oss/tantivy
      Datadogは賢い選択をしたと思う。Tantivy自体が永久にApache 2ライセンスのままで、オープンソースコミュニティと持続可能な形で共存できるなら十分だ。商業的成功を享受する資格がある
  • Quickwitは今年初めのPR #5529でエンタープライズライセンスを追加しようとしていたようだが、今回の発表ではむしろコミュニティが継続できるようにApache License 2.0へ再ライセンスするとしている
    「私たちはDatadogと新製品を作ることに集中し、オープンソースコミュニティが続けられるよう、Quickwitとtantivyの大規模アップデートを近く出し、Apache License 2.0で再ライセンスする」という内容だ
    結果的に、より自由なライセンスのQuickwitを得ることになるが、行間を読むと開発は実質的に縮小するように見える。使ってみた限りでは安定しているので大きな不満はないが、今後さらに何をもたらしてくれるのか期待していた

    • おそらくチームが毎日フルタイムで直接開発していた体制は止まると思う。Datadog内で、似ているがクローズドな形のサービスとして統合開発することになった可能性が高い
      それでも現在の製品をOSI互換ライセンスで公開し、コミュニティが引き継げるようにしたいようで、この程度なら悪くない妥協だ。もっとひどい形にもなり得た
      Datadogもオープンソースとまったく無関係な会社ではない。オブザーバビリティパイプラインツールを汎用的に公開したVectorは、かなり堅実な製品だ: https://vector.dev/
  • 最近、複数のモダンなデータベースが買収されていて、少し残念。大きな革新をもたらす潜在力があった
    https://www.warpstream.com/, https://www.orioledb.com/, https://quickwit.io/

    • Supabase の社員として言うと、OrioleDB は今後も完全なオープンソースで、寛容なライセンスのまま維持される
      Supabase は、OrioleDB チームがホスティングよりもストレージエンジンに集中し、多くのユーザーフィードバックやバグ報告を受け取れるよう、初期の配布チャネルを提供している。共通の目標は、OrioleDB を Supabase だけでなくどこでも使われる Postgres のデフォルトストレージエンジン候補へと発展させること
    • 買収が必ずしも革新の終わりを意味するわけではない。時には、何年もかけて作り上げた革新を、はるかに大きなユーザー層へ広げられるようにしてくれる
      3社の創業者全員に会ったことがあり、全員が自分たちの仕事を世に出すことに本気だと確信している。ちなみに ParadeDB は独立しており、当面売却の予定もない
  • Datadog がノード、CPU、コンテナ、RAM(KB)、インデックス化された Unicode 文字単位で課金する方法を見つけ出すまでのカウントダウンが始まった

    • すでにそうしている。たとえばコンテナは Pro プランでホストあたり5個まで含まれるが、私の趣味プロジェクトでさえそれより多く、その後は1個ごとに追加料金を払う
      料金モデルがかなり複雑で、時間が経つと、これらの優れた機能が本当にその高額な価格に見合う価値があるのか疑問に思い始める
    • すでにそうしていないか?ログは取り込み GB ベースで、モニタリングはノード単位で課金している
  • Mezmo が Quickwit を本番環境に入れて数千の顧客とペタバイト規模のログを処理し、インフラコストと複雑さを大幅に削減したと言っているのに、その直後に Quickwit が競合に売られたのは、あまりいい気分ではないだろう

    • オープンソースに還元するときに引き受けるべきリスクだ
      ほかのみんなにとって良い点は、Datadog が台無しにした場合、フォーク需要がかなりありそうだというシグナルになっていること
    • それを自分たちでやったのなら、それがオープンソースの本質だし、Quickwit と契約があったのなら、こういう状況を扱う条項がないはずはないと思う
  • 関連記事: Binance built a 100PB log service with Quickwit(6か月前、228ポイント、コメント195件) https://news.ycombinator.com/item?id=40935701
    Show HN: Quickwit – OSS Alternative to Elasticsearch, Splunk, Datadog(1年前、145ポイント、コメント51件) https://news.ycombinator.com/item?id=38902042

    • 素早く動けない大手レガシーベンダーを脅かす成功製品を作り、早期に買収目的の採用をされることを目標にすべきだな
  • 「今年の夏から雰囲気が変わった。オープンソースの牽引力が強まり、売上が急増し、VC がより積極的に接触してきた。会社の新しい章を開き、Series A を調達する時だった」と言っているが、修辞的に言えば、なぜその時だったのか?
    現実的な答えはまさにそこにある。VC は、優れた技術を持つ急成長企業というだけでは満足しない。ポートフォリオ価値を引き上げて表示できるアップラウンドか、市場が高額な Series A を受け入れるほど熱くないならエグジットを押し進めるのだ

    • それは後続投資を探す時ではなく、シード投資を受ける時点ですでに下す決定だ
      収益性のある成長企業を作りたいなら、VC 資金はその道ではない
    • 創業者が協力しないと実際どうなるのか気になる。VC が力ずくでより悪い条件の売却を強制できるのか?丁寧な依頼と強圧の境界がどこにあり、実際のレバレッジが誰にあるのかよく分からない
    • 私たちのシードラウンドは 100% SAFE だったので、VC が私たちに何かを強制する権利はなかった
      ブログ文中の表現は少し誤解を招くかもしれない。François が言った VC は、すでに Quickwit に投資していた VC というより、会社の状況を知って、将来の Series A に参加したいと連絡してきていた別の VC たちを指していた可能性が高い
      全体として、私たちが「分岐点」にいると感じただけで、誰も腕をねじ上げたりはしていない
    • 創業者がシードを受け、いまプロダクトマーケットフィットを見つけて再現可能な売上が出始めたのなら、拡大のために Series A を調達するのは自然ではないか?
  • Datadog が本当に嫌いだ。うちの会社では、やってはいけない販売やマーケティングのやり方を指す悪口のように Datadog の名前を使っている
    2015〜2018年ごろの営業手法で完全にうんざりした。終わりのない電話とメールが来て、決定打は Lambda が初めて発表されたときの AWS re:Invent の Lambda 発表だった。早く Lambda を試したくてチーム全員で聞きに行ったのに、実際は Barr の「lambda up and running」ブログを初歩的に盗用した内容をスタンドアップコメディのように包装した Datadog 社員の発表で、発表者は自分が Datadog 社員であることを繰り返し強調していた。酒を飲ませて気分よくさせ、Datadog がかっこいいと感じさせようとするようなものだった
    真面目に聞くが、その後、会社は見直せるほど変わったのか?

    • それが実際の製品と何の関係があるのか?
    • Datadog と一緒になった後には、いくつかの結果があり得る
      昔のマネージャーが言っていたように、損益計算書には「良い人」という項目はなく、誰かがコストを払わなければならない。だから暗い道筋を思い浮かべて不安になりやすい
      しかしあり得る結果の一つは、Grafana エコシステムに対抗する有効なオープンソース競合が生まれることで、これだけでも残りのエコシステムが再ライセンスしないよう守ることができる。創業者たちが金と権力闘争なしに持続可能な道を見つける、Win-Win になる可能性もある。前向きに見たいし、時間だけが示してくれるだろう
    • 私は逆の経験をした。営業チームは私たちの時間をかなり尊重してくれた
    • 同意する。うちのドメインを一度把握した途端、全エンジニアが「Re: meeting next week」みたいなメール爆撃を受けた
    • うちにはそういう酒を飲ませる営業提案は一度も来なかったけど
  • つい最近 Elastic から Quickwit に移ったばかりなのに、ため息が出る。オープンソースで、オブジェクトストレージベースの別のログデータベースでおすすめはある?

    • Grafana Labs の Loki がよい: https://grafana.com/oss/loki/
      3年ほど前は製品がかなり速いペースで変わっていて、ドキュメントのかなりの部分が git 上にあったので、マイナーバージョンアップ時に少し面倒だったが、今はずっと成熟していると思う
    • SigNoz を一度試してみることを勧める
      ClickHouse の上に作られていて、高速でスケーラブル
      https://github.com/SigNoz/signoz
      ちなみに私は SigNoz のメンテナー
    • VictoriaLogs を見てみるとよい: https://docs.victoriametrics.com/victorialogs/
      小さな単一実行ファイルで、デフォルト設定だけですぐ実行でき、すべてのデータを単一ディレクトリに保存する。オブジェクトストレージ対応はまもなく追加される予定
  • Datadog がこの技術で何を作るのか気になる。数か月前まで、この会社は自分たちを Datadog のオープンソース競合だと紹介していたように思う

    • press release を見ると、規制上の理由で純粋な SaaS を使えない顧客に セルフホスティングモデル を提供しようとしているような示唆がある
      金融、保険、ヘルスケアのような規制産業は、データレジデンシー、プライバシー、規制要件を満たしながら、システム全体の可視性も維持しなければならない。ログを顧客環境や特定の地域に留める必要がある場合、シームレスなオブザーバビリティとインサイトの獲得が難しくなり、Datadog は Quickwit によって、複数のログツールを追加せずにこの要件を満たそうとしているように見える
    • エンタープライズ顧客により大きな請求書を送るためだ
    • むしろ、この技術でこれ以上何かを作らせないために買収したのかもしれない。既存のエンタープライズ契約更新を脅かすから
    • 自社の を守ろうという意図はかなり明らか。Datadog がここに投資し続けるとは思えない。かなり直接的な競合だったから
      以前買収したオープンソースの Vector はどうなったのか? あの人たちはまだ雇われているのか?
    • 既存インフラをこれで置き換えてコストを下げようとしているのかもしれないと思う