S2 の導入発表

 (s2.dev)
1 ポイント 投稿者 GN⁺ 2024-12-22 | 1件のコメント | WhatsAppで共有
  • S2 は、耐久性のあるリアルタイムストリームを オブジェクトストレージのようにシンプルに 扱うことを目指すサーバーレス Stream Store のプレビューであり、ログとストリームをクラウドストレージの基本要素へと引き上げようとしている
  • レコードはストリームの tail に append され、複数の writer が同時に書き込んでも S2 が 耐久的な順序付け を担い、過去の読み取りとリアルタイム tailing の両方をサポートする
  • S2 の basin は、バケットのようにストリームの名前空間として機能し、ストリーム数や保持期間の制限なしに、ユーザーごとのストリームのようなモデリングを可能にする
  • ストレージクラスは Standard と Express から始まり、それぞれ p99 500ms 未満 と 50ms 未満 のレイテンシを目標に、レイテンシとコストの選択肢を分けている
  • 現在は gRPC API、Rust SDK、CLI を提供しており、REST API、Kafka プロトコル互換性、multi-region basins、5ms 未満のレイテンシ を次の段階に据えている

S2 が提案するストリームストレージモデル

  • S2 は、クラウド時代のストリーミングデータ向け サーバーレス Stream Store を志向している
  • 中核となるアイデアは、ログまたは stream もオブジェクトのようにクラウドストレージの基本要素になり得るということだ
  • オブジェクトストレージは、名前付きオブジェクトに対する PUT / GET / DELETE と blob・byte range に焦点を当てており、静止データに適している
  • S2 のストリームストレージは、名前付き Stream に対して APPEND / READ / TRIM を提供し、レコードとシーケンス番号を基本単位とする
  • 書き込みはストリームの tail に append され、複数の writer が同時に記録しても、S2 がすべてのレコードを 順序付け し、耐久性を保証する
  • 読み取りは数秒前から数年分まで開始でき、S3 blob では難しい リアルタイム tailing も可能だ
  • basin は、bucket が object の名前空間として機能するのと同様に、stream の名前空間として機能する
    • basin と stream は数の制限なく利用できる
    • データ保持期間にも制限がない
    • ユーザーごとのストリームのモデリングも可能で、Kafka のようにクラスタ制限やインフラのチューニングを扱う必要がない
  • stream tail を強い整合性で確認する動作と、書き込み時の 同時実行制御 もサポートする
    • fencing token を使う悲観的方式が可能
    • 想定シーケンス番号を提供する楽観的方式が可能
    • この設計は、MemoryDB や Neon のようなデータベースが活用する耐久性のオフロードと、コンピュート・ストレージ分離を狙っている

パフォーマンス、価格、現在の提供機能とロードマップ

  • S2 は、オブジェクトストレージの拡張性と耐久性を基盤として、マルチテナントサービス形態の サーバーレス API を提供する
  • 耐久性は妥協しない要素としつつ、レイテンシとコストの選択はストリームごとの storage class で調整する
    • Standard: AWS S3 Standard ベースで、すべてのパブリッククラウドプロバイダーに対応製品があるため、成長に合わせてすべてのクラウドリージョンで提供できると見ている
    • Express: AWS S3 Express One Zone バケット 3 つの quorum ベースで、Azure には regional counterpart があり、GCP でも可能性があると見ている
  • パフォーマンス目標と初期制限は次のとおり
    • Standard は end-to-end の p99 レイテンシ 500ms 未満 を提供
    • Express では 50ms 未満 のレイテンシが期待できる
    • すべての write は acknowledgement 前に、regional durability を持つ形で S3 に安全に保存される
    • スループットはストリームあたり 毎秒数百 MB レベルをサポートする
    • 直近に書き込まれたデータの読み取りは、インメモリキャッシュによりオーバーヘッドが小さい
    • 遅延した reader には object storage から直接提供され、cap はない
    • 初期段階では、write をストリームあたり 125 MiBps、直近の write に対する read をストリームあたり 500 MiBps に制限する
  • プレビュー期間中は無料で提供され、intended pricing を公開して、クラウドストリーミングシステムの一般的な水準よりも有意に安価な価格を目標としている
  • instance や cluster unit のような 固定費用 はない
  • 現在提供されている開発者インターフェースは次のとおり
  • システムは実証済みのクラウドインフラ上にあり、Rust コードベースは deterministic simulation testing を経ている
    • まだ若いシステムのため、問題がある可能性はある
    • general availability と、本番環境で信頼できる SLA に向けて成熟を進めている
  • 今後のロードマップは 3 つの軸に整理されている
    • Kafka protocol compatibility: オープンソースのレイヤーとして提供し、key-based compaction のような一部機能は S2 に直接統合する予定
    • Multi-region basins: より多くのクラウドリージョンへ拡張した後、リージョンやクラウドをまたぐ basin の可能性を見ている
    • Under 5 millisecond latencies: storage class の構造的な柔軟性により、Express と比べてさらに 10 倍の改善が可能だと見ている
  • Kafka や Kinesis の「low-level」API を主に使う場合、S2 はストリーム数の制限なし、10〜100 倍高い ordered throughput、同時実行制御といった要求を直接狙っている

関連記事

1件のコメント

 
GN⁺ 2024-12-22
Hacker News の意見

  • 法律家ではないが、製品名を S2 にして、紹介文で AWS S3 を改善する技術だと言うのは、Amazon から 商標/著作権クレームを招く可能性が高そうに見える
    同じ分野なので、消費者の混同も明らかに起こり得る。商標登録の有無は当然調べたのだろうが: https://tsdr.uspto.gov/#caseNumber=98324800&caseSearchType=U...

    • 面白い事実: スペイン語では S2 と EC2 がどちらも「ese dos」となり、まったく同じに聞こえる
      すでに EC2 と S3 も耳で聞くと区別しづらいのに、そこへもう一つ追加されるわけだ
    • 公平に言えば、S3 を改善することを目標に作ったのなら S4 と呼ぶのが正しそうだ
    • 少なくとも Cloudflare の R2 には名前についての論拠がある
      IBM 対 HAL、つまり『2001年宇宙の旅』式の命名だ
    • 悪い商標弁護士に相談したのか、そもそも相談しなかったのかは分からないが、費用はそれほど高くなかったはずだ
      最近商標出願の手続きを始めてみたが、ドメイン登録事業者のウェブサイト基準では s4.dev のようなドメインを買う費用と同じくらいだった。ローンチ後にリブランディングするのは、ローンチ前に変えるよりずっと苦痛だ
    • Amazon が単に同じものを作って S3 Streams と呼び、S2 は気にしない可能性もある
      もしかすると買収提案をするかもしれないし、訴訟にまで至る可能性は非常に低そうだ

  • アイデアは本当に良く、API も美しく、自分のプロジェクトで使いたいが、このスタートアップが現在の形で長く持ちこたえるという確信はまったくない
    成功すれば AWS がより良く安い内部版を作るだろうし、逆に市場で traction を得られない可能性も大きい。AWS に密接に結び付いた「クラウドの基本構成要素」API ではなく、Papertrail のようなダッシュボード付きのエンドユーザー向け製品として出てきた方が、はるかに筋が通っていたはずだ。ここに Digital Ocean Spaces のような S3 互換バックエンドを直接持ち込めるようにすれば、優れた長続きするクラウド中立の製品になる

    • 創業者の立場では、マルチクラウドを計画していて、今は AWS から始めているということだ
      内部アーキテクチャは AWS に縛られておらず、他のクラウドシステム向けに実装可能なインターフェース構造になっている
    • これ全体がすでに AWS 上で動いているなら、かなり皮肉だろう
      既存のオープンソースソフトウェアをサービスとして包み、AWS 製品より安いとマーケティングしながら、実際には AWS 上で動いているスタートアップは後を絶たない
    • Aptible(https://aptible.com)にもずっと同じ反論が出ていたが、10年以上たった今でも非常に成功した PaaS として残っている
    • クラウドインフラ分野をやるなら、AWS は価格では叩きに来るだろうが、開発者体験/ユーザー体験では絶対により良くできない
      だから Beezus のせいで止まる必要はないと思う
    • AWS はすでに似たことをしている: https://news.ycombinator.com/item?id=42211280
      “Amazon S3 now supports the ability to append data to an object” が30日前に発表されており、Azure も append blob でかなり前から同じ機能を持っていた。まだ S2 より素朴で record の概念はないが、クラウドプロバイダーがこれをネイティブに提供する段階まではごく小さい。record の概念まで入れると実質的に メッセージキューに近くなるが、その競争領域も同じく大きく、ログ保存ソリューションの側も似たようなものだ

  • 理解を助けてほしい。AWS 上に構築すると AWS はインターネット送信に GB あたり $0.09 を取るのに、ここではインターネット送信を GB あたり $0.05 で課金するということなのか?
    AWS の送信費用を補助しているように聞こえる。それとも公開されていない送信単価を使えるのだろうか?

    • 創業者の立場では、プレビュー期間中は課金しない
      意味のある規模になれば解決する予定で、ここには確かにいくつかの前提が入っている
    • 定価基準でも 150TB 以降は GB あたり $0.05 で、大容量ではそれよりさらに安い
    • ほとんどのユーザーが AWS 内にいて、1〜2セントの転送料だけ払えばよい、という方に賭けているようだ
    • 十分な規模があるところは、データ転送に小売価格を払わない
    • 今は GB あたり $0.08 に変えたようだ
      そうすると 50TB で最大月 $300 の損失で、それ以降は利益が出るようになる

  • これは基本的に WarpStream だが、すぐに Kafka 互換へ行かず、より低レベルの API を提供する形なのか?
    長期的に採用されるなら、ストリーミングのための S3 レベルの基本 API は本当に価値がありそうだ

    • 創業者の立場では、ある程度正しい要約だ
      ただし WarpStream とはアーキテクチャ上のアプローチも異なり、そのためはるかに低いレイテンシを提供できる。システムにはディスクもない

  • この人たちは今後キャリアを通じて「実は私たちは S3 ではありません」と説明することを、意識的に選んだわけだ

    • 創業者の立場では、名前の50%は違うと言える
    • こういう 文字+数字のストレージサービス は今いくつあるのか? S3、B2、R2、S2...
    • あるいはこれもある: https://github.com/google/s2geometry
    • それでも、形容しがたい戦争犯罪を犯した準軍事組織ではないと説明するよりはましに見える
      それは笑い事ではない
    • 法廷や弁護士の前でもそう説明しなければならないのでは? 法律家ではないが、これは Amazon に「S3」商標を意図的に利用し、混同を生んで自社ブランドを育てようとした、と主張するよう招いているように見える
      個人的にはその主張は正しく、本文でもかなり透けて見えていると思う

  • 良さそうだけど、Java SDKはないのかな？
    個人的に働いてきた会社では、Kafka の生成/消費の 90% は Spring か標準クライアントに深く依存していた。これだと軽い概念実証すら事実上できなくなる

    • S2 チームとしては、今後 Java/Kotlin SDK と Python SDK がリストに入っている
      現在は Rust SDK と CLI がある（https://s2.dev/docs/quickstart）。コアサービスも Rust で書かれているので、Rust がよい出発点のように感じられた

  • これは気に入った。次に誰かにこの上に作ってほしいのは、ストリーム「イベント」を特定時点でクエリ可能な表現として適用する部分
    基本的には Datomic っぽいものを作るためのもう半分。特定のデータベースというより、具体的なインメモリのクエリ可能データを作るためのパターンやフレームワークの方がよさそう。ローカルの Sqlite に適用する、MySQL binlog を基にローカルのクエリインスタンスへ適用して特定時点まで巻き戻せるようにする、アプリケーション別の apply/undo イベントをローカル状態に適用する、といったようにさまざまな方法が考えられる

  • およそ 10 年前に Gazette を始めた [0]
    Gazette は Kafka と WarpStream/S2 の間にあるアーキテクチャ上の中間地点にある。S3 をバックエンドにした無限のバイト指向ログストリームを提供するが、ブローカーは初期レプリケーション/耐久性の保証と append/read レイテンシの低減のためにローカルのスクラッチディスクを使う。そのため p99 は 500ms 超ではなく 5ms 未満で、設定可能な目標サイズ/圧縮/レイテンシ上限といった便利機能とともに、すべてのファイルが S3 に到達することを保証する。過去データを読むクライアントは S3 から直接コンテンツを取得し、その後ごく最近の append の live tailing に切り替わる
    Gazette は以前のスタートアップの社内ツールとして始まり、今の会社を作る際に raw service として提供する案 [1] をごく短期間検討したが、Gazette を内部実装の詳細として使う総合的なデータ移動プラットフォーム [2] へと方向転換した。この種のサービスの市場ポジショニングは極端に狭い。対象顧客がすでに使っているものと API 互換にして試すコストをゼロにするか（WarpStream はこれをうまくやった）、アプリケーションスタックのさらに上位へ行き、顧客が実際に解こうとしている問題をより直接的に解決する必要がある
    [0]: https://gazette.readthedocs.io/en/latest/
    [1]: https://news.ycombinator.com/item?id=21464300
    [2]: https://estuary.dev

    • S2 創業者としては、Estuary の成功を祝福する
      この市場が存在しない、あるいは非常に小さいと言った人は初めてではない。ただ、あなたも HN で検証を求めていたときには、何かがあると思っていたはず。S2 の上に Kafka 互換性のようなものをもっと多く提供することもできるが、核となる基本構成要素が重要だ。個人的にも欲しかったし、さまざまな文脈で作り直され、本来の性質を失ったシステムの形で非効率に再利用されているのを見てきたので、その確信だけでも創業者になるには十分だった。助言の背景は理解しており、今後の困難も分かっている。助言に感謝する

  • 非常に有用なサービスモデルだが、すべての書き込みが確認応答前に S3 に永続化されるなら、価値提案が分かりにくい
    書き手が record の束をより大きな blob として書く前にバッチ化し、バックグラウンドプロセスが compaction を行うことはできるだろうが、それでもオブジェクトストレージベースのストリーミングサービスではないのか？ AWS は RDS から Aurora へ行ったように、概してプロトコル互換サービスを実装する意欲があることを示してきたし、Kafka の再実装でも同じことができそうに見える

    • S2 チームとしては、本質的にはその方式で合っている
      書き込みを確認応答する前にオブジェクトストレージへ書く chunk をマルチテナント設計にし、異なるストリームの record を一緒に入れるようにすれば、頻繁に書き込みつつも S3 standard と express PUT それぞれについて価格/性能上理想的な blob サイズを狙える

  • 技術は本当に素晴らしそう。ただ、ソース公開ではないのが残念
    少数意見かもしれないが、コア技術が FSL のようなライセンスで公開され、完全にサポートされたセルフホスティングが可能なら、商用サービスを十分検討する。そうでなければ Kafka のようなものと比べてロックインを正当化しにくい

    • 創業者としては、S2 API の代替実装が出てくることを歓迎する
      自分たちでオープンソース公開するインメモリエミュレーターも検討中。API 自体はそれほど複雑ではない。Kafka API を維持しつつ、S2 のストレージクラス、非常に多くの topic/partition、partition あたりの高いスループットといった機能を得たいなら、セルフホスト可能なオープンソースの Kafka 互換レイヤーを計画中。クライアント側暗号化のような機能も入れて、より安心できるようにする予定