- Kafkaはデータセンター時代の分散ログとして成功したが、パブリッククラウドでは AZ間のネットワークコスト とローカルディスク運用の負担が大きくなる
- WarpStreamはApache Kafkaプロトコル互換の ディスクレス・ストリーミングプラットフォーム で、S3のようなオブジェクトストレージ上でローカルディスクやブローカーのリバランシングなしに動作する
- 3つのアベイラビリティゾーンにまたがるKafkaクラスターでは、1GiBのストリーミングごとに最良の場合でも約 $0.053 のAZ間転送コストがかかり、これはS3に1GiBを1か月保存するコスト $0.021 より高い
- WarpStreamはステートレスなGoバイナリである Agent と独立したメタデータストアによって、ストレージとコンピュート、データとメタデータを分離し、データはユーザーのクラウドアカウント内のオブジェクトストレージに残す
- コストは大半のKafkaワークロードで 5〜10倍削減 できる可能性がある一方、現行実装ではProduceリクエストのP99が約400ms、プロデューサーからコンシューマーまでのエンドツーエンドP99が約1秒のレイテンシを受け入れる必要がある
クラウドで高コスト化したKafkaの基本構造
- Apache Kafkaは2011年にオープンソースとして公開されて以来、ストリーミングアーキテクチャの基盤インフラとして定着した
- 問題はKafkaそのものよりも、2011年のLinkedInのデータセンター向けに最適化された設計が 現代のクラウドワークロード にあまり合っていない点にある
- 特にコストと運用負担が大きく表れる
- クラウド経済性: Kafkaのレプリケーション方式はAZ間の帯域コストを大きくしうる
- 運用負担: 自前のKafkaクラスター運用には専任チームとカスタムツールが必要になる
- ローカルディスクにデータを保存する類似システムも、同じコスト・運用上の問題を抱えうる
Kafka-nomics: AZ間転送コスト
- 一般的な3AZのKafkaクラスターでは、生成されたデータはパーティションリーダーの配置のため 2/3 の確率でゾーンをまたいで書き込まれ、その後リーダーが別の2つのゾーンのフォロワーへデータをレプリケートする
- 1GiBがゾーン間転送されるときのコストは $0.022 と計算される
- 送信元ゾーンのegress $0.01
- 送信先ゾーンのingress $0.01
- 最良の場合でも1GiBあたりのストリーミングコストは
0.02 * 2/3 + 0.02 * 2 = $0.053 程度になる
- S3に1GiBを1か月保存するコストは $0.021 であり、Kafkaでプロデューサーからコンシューマーまでデータをコピーするコストがあれば、同じデータをS3に2か月以上保存できる
- スループットの大きいKafkaクラスターでは、ハードウェアよりも AZ間帯域料金 がコストを支配し、ワークロード費用の70〜90%を占めることもある
- スループットが低くても保存期間が長ければストレージ容量は増え、ローカルSSDで3重レプリケーションする方式は、ディスク使用率100%を仮定しても、S3のようなオブジェクトストレージよりGiBあたり約10〜20倍高くなりうる
開発者が背負うクラスター運用
- 開発者はビジネス課題を解決するためにKafkaを導入するが、その前にKafkaとZooKeeperまたはKRaft、リーダー選出、パーティション、コンシューマーグループ、リバランシング、ブローカーチューニング、クライアントチューニングを学ばなければならない
- Kafkaのデータプレーンであるブローカーと、合意ベースのコントロールプレーンであるコントローラー・ZooKeeperなどは、いずれも ローカルSSD 上で直接運用される
- 自前ホストのKafkaクラスターでは、ノード交換やクラスター拡張のような基本作業であっても、安全に実施するには専門チームとカスタムツールが必要になる
- Apache Kafka内蔵のパーティション再割り当てツールは、ブローカー廃止時に自動で再割り当て計画を作成できず、管理者がパーティションレプリカ移動計画を手作業で作らなければならない
- AWS MSKのようなホスティングサービスでも運用負担は完全にはなくならない
- MSKのクラスターリバランシング文書はApache Kafkaの文書へリンクしている
- その手順には、どのパーティションをどのブローカーへ移すかをJSONで手動編集する工程が含まれる
- Cruise Control は負担軽減に役立つが、別の概念学習、サービスのデプロイ・監視、運用上の鋭い落とし穴が追加される
- Cruise Control自体もApache KafkaとZooKeeperに依存するJVMアプリケーションである
オブジェクトストレージ上にストリーミングを載せるアプローチ
- Datadogが開発した Husky は、S3上で直接動作する観測データ向けカラム指向データベースであり、大部分はステートレスで自動スケールするデータレイクとして動作していた
- Husky構築後、Kafkaクラスターは比較対象として古い構造に見えるようになった
- DatadogのKafka帯域は2桁GiB/s、ブローカーストレージはPiB級NVMeで計測されるほどだった
- 大規模ストレージワークロードは、クラウド環境におけるオブジェクトストレージの 経済性・信頼性・拡張性・弾力性 と競うのが難しい
- SnowflakeやDatabricksのようなビッグデータ技術も、汎用オブジェクトストレージを中心にシステムを設計している
- Kafkaに似たシステムをS3上に直接構築できれば、2つの負担を同時に減らせる
- 最大の難所は、S3のような 高レイテンシなストレージ媒体 の上で、ローカルディスクなしにKafkaプロトコルの意味論を保ちつつ、低レイテンシのストリーミング基盤を作ることにある
WarpStreamアーキテクチャ
- WarpStreamはAWS S3、GCP GCS、Azure Blob Storageのような汎用オブジェクトストア上で直接動作する、Apache Kafkaプロトコル互換のストリーミングプラットフォームである
- AZ間帯域コストがなく、管理すべきローカルディスクもなく、ユーザーのVPC内で実行できる
- Kafkaブローカーの代わりに Agent を使う
- AgentはステートレスなGoバイナリである
- JVMを使わない
- Kafkaプロトコルを話す
- どのAgentでもトピックリーダー、コンシューマーグループのオフセットコミット、クラスターコーディネーターの役割を担える
- WarpStreamは2つの分離によってKafkaのステートフルな構造を置き換える
- ストレージとコンピュートを分離し、データをS3へオフロードする
- データとメタデータを分離し、メタデータをカスタムメタデータストアへオフロードする
- すべての保存をオブジェクトストレージへ委ねることで、負荷変動に応じてAgent数を増減しても データのリバランシング が不要になる
- 障害時も別のAgentで即座にリトライできるため、復旧が速い
- パーティションごとのデータ偏りによって一部のKafkaブローカー負荷が高くなるホットスポット問題も、大半が軽減される
- WarpStream Virtual Clusterのメタデータはカスタムのメタデータデータベースに保存される
- データのレプリケーション、耐久性、可用性はオブジェクトストレージバケットが担い、ユーザーのデータはクラウドアカウント内に残る
- クラウドアカウントの外へ出るのは、パーティション内のバッチ順序のような合意に必要な ワークロードメタデータ だけである
- 詳細な構造は WarpStreamアーキテクチャ文書 にまとめられている
コスト例とレイテンシのトレードオフ
- テスト環境の継続的ストリーミングワークロードでは、140MiB/sのデータを継続的に生成し、専用コンシューマー3台がそれを消費して、合計560MiB/sの連続データ転送を生み出している
- クラウドアカウント全体のAZ間ネットワークコストは、1日平均 $15 未満と測定された
- 同じワークロードをKafkaクラスターで実行すると、AZ間ネットワークコストだけで1日 $641 と計算される
- 計算式は
0.14GiB * $0.053/GiB * 60 * 60 * 24
- 同じワークロードでのS3 API操作コストは1日 $40 未満である
- Agentハードウェアは27 vCPU規模のVMだけで足りる
- 大半のKafkaワークロードの総保有コストは、WarpStreamで 5〜10倍 低くできる可能性がある
- 最大の欠点はレイテンシである
- ProduceリクエストのP99は現在約400ms
- データがS3へ耐久的に保存され、クラウドのコントロールプレーンにコミットされるまで確認応答しないためである
- プロデューサーからコンシューマーまでのエンドツーエンドP99レイテンシは約1秒である
- ワークロードがP99で約1秒のプロデューサー-コンシューマーレイテンシを許容できるなら、GiBあたりのストリーミングコストを5〜10倍下げ、運用負担をほぼなくせる
- インターフェースは独自プロトコルではなくKafkaであり、AWS S3、GCP GCS、Azure Blob Storageを使う環境で実行できる
開発者体験と使い方
- WarpStreamはKafkaの主要な問題のうち、まずクラウド経済性と運用負担に取り組んでいる
- Kafkaには開発者体験の問題もあり、パーティションは複雑なストリーム処理アプリケーションを書くには抽象度が低すぎると見なされている
- 今後は、ストリーム処理アプリケーションを従来のアプリケーション開発により近づける方法を扱う予定だとしている
- デモは30秒以内に実行できる
$ curl https://console.warpstream.com/install.sh | bash
$ warpstream demo
- WarpStreamはApache Kafkaの上にオブジェクトストレージベースの代替製品を販売する企業の製品紹介であり、本文中の数値や比較はその文脈で読む必要がある
1件のコメント
Hacker Newsの意見
「ほぼすべてのテック企業がKafkaを使っている」というのは間違っていると思う
互いに根拠を示したわけではないが、最近働いた6社のうち Kafka を使っていたところは0社で、その前の会社では導入を主導したものの、後に捨てた
LinkedInは99%の人にはない超大規模問題を解くためにKafkaを作ったのであり、技術者には不要な技術を使うという評判があるとはいえ、大半はKafkaの使用を避けることに成功していると思う
必要なのがそれだけなら、保持期間のない単純なメッセージブローカーのように簡単に使えるし、永続性を活用した特殊な処理が必要ならそちらへ進めばいい
基本形でも堅牢で広く使われているオープンソースツールに否定的な感情を持つなら、たいてい一部の特殊機能やユースケースが原因なのだと思う
むしろこうした表現は、このベンダーにとって印象が良くない。技術的な長所短所でKafkaを批判したり競争したりすることはできるが、市場での位置づけを歪めるのはあまり良くない
良いユースケースがあることは疑っていないが、これまではどんな状況にも無理やり押し込もうとする熱心なユーザーしか見ておらず、後味の悪さが残ったので、自分は「嫌いな側」に属している
「Accidental SRE」の部分には同意するが、Kafkaは堅実な技術であり、だからこそRedpandaのような「Kafkaより良いKafka」ツールもあふれている
最後は論点から外れているように思う。広く使われていないとしても、それが賛否の分かれる技術かどうかとは別の話だ。言及された1%のスケーリング問題を解く人たちにとっては、今でも好き嫌いの対象になり得る
「ランボルギーニは好き嫌いが分かれる」という言葉が、ほとんどの人はランボルギーニを持っていないから間違いだ、と言うのに似ている。筆者も明示的に「データ分野で」と範囲を限定していた
いくつか質問がある
そのためS3 PUTコストはトピック-パーティション数ではなく、稼働中のAgent数とフラッシュ間隔に比例する。データがS3とクラウド制御プレーンに耐久的に保存される前にProduceリクエストを承認することはない
信頼性とコストのどちらかを選ばなければならない、という状態であるべきではないと思う。WarpStreamは、3つのアベイラビリティゾーンで動かすレベルの信頼性と可用性を、1つのアベイラビリティゾーン分のコストで提供する
順序は、クラウド制御プレーンで実行されるカスタムメタデータデータベースが処理する
各アベイラビリティゾーンにKafkaクラスタを置き、後で統合するまでだけレプリケートする方式そのものに問題はない。ただし分散システムとアベイラビリティゾーンがあると、エンジニアたち、そしてビジネス要件はたいていマルチアベイラビリティゾーン構成を選ぶ。リージョンも同じだ
そのため大半のKafkaクラスタはマルチアベイラビリティゾーンだが、実際にはそうしなくてもよい場合が多く、その請求書がKafkaのせいにされる
Kafkaプロトコルは、Kafkaパーティション内の作業順序を実際には保持しない。プロデューサー-パーティションのペア内の作業順序を保持し、それも特定の方法で設定した場合に限られる
標準実装は、プロデューサーからブローカーがメッセージを受け取った順序を保持する方式だが、外部システムの観点では、正しく設定した場合に特定のキーと特定のプロデューサーのメッセージが受信順に保持される、という意味に近い
Cloud Metadata Storeが実質的にオフセットを割り振る役割をしているのか？
WarpStreamの共同創業者兼CTOのRyan Worlです。S3の上に直接構築したKafkaプロトコル互換のストリーミングシステムの開発者プレビューを発表できて、とてもうれしく思います。
実行すべきステートフルなディスク／ノードがなく、データのリバランシングもなく、ZooKeeperもなく、可用性ゾーン間の帯域幅コストもないため、5〜10倍安くなります。
WarpStreamについて質問があれば、共同創業者のrichieartoulと一緒にお答えします。
作らなかった理由の一つは、規模が重要でないなら、ユーザーは小型版Kafkaを欲しがるよりSQLiteを直接使えばいいのでは、という逆説を感じたからだった。
ただ、人々がKafkaプロトコルのセマンティクスを好んでいる場合や、すでにKafkaを使っていたものの想定していた規模ではなく、その複雑さを背負う必要がないと分かった場合もあり得る。幸運を祈る。
Cloudflare R2をサポートしているなら、マルチクラウドにも良さそう。
Kafkaがパーティションレベルで提供しているような順序保証も提供するの？
「5〜10倍安い」というのが主に可用性ゾーン間コストの削減によるものなら、AWS MSKもそれを提供していない？
一つだけ確かなことがある。クラウドプロバイダー上の個別VMでKafkaを「定石どおり」に動かすと、ばかげて高くつく。
KafkaとHadoopについて、複数の顧客と非常に単純な話をした記憶がある。ディスクがすでに完全な冗長システムとして提供されているのに、なぜVM／ディスクレベルでデータをもう一度複製するのか、という話だ。
ここではAzure Storageのことで、ローカル冗長、可用性ゾーン冗長、グローバル冗長ストレージを提供しており、その多くはマネージドディスクの実行に使えた。
だから、適切に設計されたHadoop／Kafkaのクラウドマネージドサービスは、プロバイダー組み込みの冗長性を活用するためにストレージアダプターを使う。一部のクラウドプロバイダーにKafka互換のイベントブローカーがある理由も同じだ。
WarpStreamの残りの部分は、ほとんどおまけのようなものだが、内部構造と可用性ゾーン間コストをどう避けているのかは気になる。
ちなみに私はMicrosoftで働いているが、ほぼ10年前に入社する前はHadoop／Spark／Kafkaクラスターを構築していた。
一部のRaft実装では、投票権はあるがクォーラムリーダーにはなれないノードを許容している。例えば、すべてのトラフィックが非対称VPNトンネルを通る支社は、リーダーに選出されるべきではないが、どの候補が見えているかは分かっている。
そのため、クラスター運用の基本コストはハードウェア3倍ではなく2.2倍に近く、小規模なソリューションや開発者サンドボックスでは大きな違いだった。シャード3個では負荷に対して微妙に足りないが5個では多すぎる場合、あるいは6個と7個の差でも重要になる。
問題は、地理的レプリケーションではこの記事の核心である二つの問題を解決できない点だ。クラウドの経済性という面では、Kafkaのレプリケーション戦略は設計上、膨大な可用性ゾーン間帯域幅コストを生み、運用負荷という面では、自前のKafkaクラスター運用には事実上、専任チームと精巧なカスタムツールが必要になる。
それでもクラウドでこの機能を取り戻す必要がある。特に、過去にも常にそうだったように、振り子が再びセルフホスティングへ揺れ始めたときにはなおさらだ。
EBSのようなソリューションにはコストが伴う。特に多くのIOPSが必要な場合は非常に高い。可用性ゾーン間トラフィックのコストは節約できても、ストレージに途方もない金額を払うことになる。
自分でレプリケーションすれば、ずっと安い接続ストレージを使える。
richieartoulへ、ブログ記事は少し盛りすぎだ。
Kafkaは、非常に大きなクラスターを運用するまでは、本質的に専門家の専任チームや数百万ドルを要求するものではない。
ただし、3つの可用性ゾーンにまたがるクラスターが、可用性ゾーン間転送コストでお金を吸い取るという点には完全に同意する。AWSがMSKを売るやり方もそれだ。可用性ゾーン間転送は「無料」だと言うが、実際にはすでに価格に含まれている。
面白そうだが、「Accidental SRE」を読んで二つ質問が浮かんだ。
ベアメタルはずっと前からあったが、自前のベアメタル管理が特に大きく簡単になったようには思えない。本当に簡単なら、こうしたものはエンドユーザーがもっと直接管理していたはずだ。
だとすると、このサービスはどう管理するのか？ クラウドプロバイダーなのか、ベアメタルなのか？
二人とも、通常は自分で管理するFoundationDBの経験が豊富だ。だからメタデータストアにも再びFoundationDBを選んだのか？ 選んだ、あるいは選ばなかったなら、その理由が気になる。
これにより、すべての顧客データは顧客のクラウドアカウントとS3バケット内に残り、私たちは見たり触れたりできません。顧客はWarpStream Agentを自分で実行する必要はありますが、管理しやすいステートレスなコンテナにすぎません。
メタデータストアとしてFoundationDBを検討しましたが、最終的には使いませんでした。無料ティアをコスト効率よく成立させるには、この特定のユースケースに合わせてメタデータストアをできるだけ効率的にする必要があり、そのためにはもう少しカスタムなものが必要でした。
それでもFoundationDBは素晴らしい技術です。私が使った複数の分散データベースの中で最高のものです。
「パーティションはいくつ使うべきか？ はっきりしないが、一度決めたら絶対に変えられないので、正しく選ばなければならない」というのは、単に間違っている。パーティション数は変更できる。
それに、繰り返し出てくる「Kafka の運用にはエンジニアチーム全体が必要だ」という主張もよく分からない。経験上、事実ではない。運用コストが高いのは確かだが、私たちのチームではエンジニアリング時間をそれほど必要としていない。
とても興味深い。自分も似たものを設計して、Zig で実装しようとしていた https://github.com/fremantle-industries/transit
Kafka の力のかなりの部分は API に由来しており、最終的にはクラスタ管理の複雑さは複数の実装を通じて抽象化されていく、という似た結論にたどり着いた。
S3 のキー空間の上に Kafka の永続性を実装できるなら、WarpStream のように S3 に直接永続化する方式から始め、その後、より高速なホットディスクとメモリの階層化メカニズムを重ねることで、エンドツーエンドのレイテンシを下げられると考えていた。
方向性は気に入っている。もっと深く話したければ、Twitter で連絡してもらってもよい https://twitter.com/rupurt
以前の職場で、この製品とおそらく非常によく似たものを作った。1日あたり二桁 TB の機械学習トラフィックがあり、リアルタイムの低レイテンシは不要だったため、すべて S3 に移したところ、約 90% のコスト削減になった。
JVM 上に作り、メタデータ維持のために依然として 6 ブローカーの Kafka クラスタを使っていた。もともとすべて Kafka にあったときは、おそらく 300 ブローカーだったはずだ。
Kafka のコンピュート／ストレージモデルは、レイテンシを許容できる極端なユースケースではうまくスケールせず、Apache Pulsar のモデルのほうが向いていた。ただし当時の Pulsar は、本番環境で使うには十分に安定していなかった。
コスト効率の鍵の一つは、データサイズが十分に大きく、経済的なファイルサイズに達するまで長く待つ必要がなかった点だ。毎秒 10MB 未満のパイプラインがこの方式で効率よく動くとは想像しにくい。
これは Pinterest の memq だったか、それとも別のものだったか？
記事タイトルは “Kafka is dead. Long live WarpStream.” であるべきだった。“long live” の部分は後継者を指す。
https://en.wikipedia.org/wiki/The_king_is_dead,_long_live_th...!