前方互換性・後方互換性とは何なのか？ 〜Schema Registry における例〜
Schema evolution において前方互換性・後方互換性を意識することは重要ですが、どっちがどっちか混乱することがあるのでメモとして残しておきます。 一般的な説明 Wikipedia の互換性の説明がとても簡潔に表現されていると思うので引用します。 前方互換性（英語: Forward compatibility） 新しいシステム向けのデータなどが古いシステムでも使用できること1。 後方互換性（英語: Backward compatibility） 古いシステム向けのデータなどが新しいシステムでも全て使用できること2。 前方互換性の例として、よく白黒テレビがカラーテレビ放送を受信して白黒で表示できることが挙げられますが、ポイントとしては、前方互換性を考慮して白黒テレビが作られているわけではなく、前方互換性を考慮してカラーテレビ放送規格 (NTSC) が定められていることです。初めて「
Kafka Streams の State Store が tombstone によって遅くなってしまったので RocksDB のパラメータを調整してみた話 - Repro Tech Blog
Platform Team の Repro Core という Unit に所属している村上と申します。 Repro Core の役割の 1 つとして、共通基盤となる Kafka Streams アプリケーションの運用があります。 この共通基盤は Repro の大量トラフィックを捌いている基盤になるため、日々の運用の中で様々な課題に直面します。 今回はそのような課題の中から、tombstone によって State Store のパフォーマンスが低下し、その解決策として RocksDB のパラメータを調整した話をします。 前半部分では tombstone によって State Store のパフォーマンスが低下した件を説明します。後半は RocksDB の compaction の挙動確認とそのパラメータ調整について説明します。 ちなみに、私が所属している Repro Core については、
Kafka is dead, long live Kafka
TL;DRWarpStream is an Apache Kafka® protocol compatible data streaming platform built directly on top of S3. It's delivered as a single, stateless Go binary so there are no local disks to manage, no brokers to rebalance, and no ZooKeeper to operate. WarpStream is 5-10x cheaper than Kafka in the cloud because data streams directly to and from S3 instead of using inter-zone networking, which can be
Kafka Brokerのcompaction動作の詳細とチューニング方法について - Repro Tech Blog
Reproでチーフアーキテクトとして働いているid:joker1007です。 今回、Kafka Brokerのcompaction動作について調査しチューニングすることでパフォーマンス改善の成果が得られたため、そのノウハウをブログにまとめておきました。 かなりマニアックな内容なので、需要は多くないと思いますが、私が調査した限りでは日本語で同じ様な内容のブログ記事はほとんど存在しなかったため、Kafkaを自前で運用している人にとっては役に立つ内容かもしれません。 compactionとは (参考: https://kafka.apache.org/documentation/#compaction) Kafkaの基本的なデータ削除ポリシーは一定時間が経過したら過去のデータをそのまま削除するdeleteというポリシーを使う。 これは、log.retention.hoursという設定でコントロー
Stateful Kafka Streams アプリケーションで consumer が増減すると意図しない偏りが発生する理由 〜 StreamsPartitionAssignor はいかにタスクを割り当てるのか 〜
Stateful Kafka Streams アプリケーション、つまり state store を使った Kafka Streams アプリケーションでは consumer が増減するとタスクの割当が極端に偏ることがあります。その理由について、WordCount の例を使って解説し、運用上の注意点についてまとめます。 なお、Kafka Streams のバージョンは 2.7.2 です。 サンプルアプリケーション WordCount は次のように入力値を単語に分割し、単語ごとに処理した回数を数えるシンプルなアプリケーションです。 KStream<String, String> source = builder.stream("streams-plaintext-input"); source.flatMapValues(value -> Arrays.asList(value.toLower
Taking our Ruby & Kafka stack to the next level
Migrating from ruby-kafka to rdkafka-rubyMar 02, 2022 | Dennis Bielinski At Doximity, we have an internally-built gem called dox-messaging that all our applications use to interface with the Kafka backend. It has been a wrapper for ruby-kafka. Its purpose is to provide a more user-friendly API to interact with Kafka while also enforcing best practices and providing sane defaults for configurations
Kafka入門 第1回 「そもそもKafkaとはなにか」 - joker1007’s diary
これは社内向けに書いた、Kafkaってそもそも何やねん、ということをメンバーに解説するための記事を一部編集して公開できる様にしたものです。 第2回以降では、Kafkaを利用したアプリケーション開発のノウハウについて解説していく予定です。そちらも社内の事情を除いた形で公開していくつもりです。 そもそもKafkaとは Kafkaはイベントストリーミングプラットフォームと呼ばれるミドルウェアです。 元々はストリームバッファと呼ばれてたと思います。 公式のドキュメントには以下の様に書かれています。 Kafka combines three key capabilities so you can implement your use cases for event streaming end-to-end with a single battle-tested solution: To publis
Kafka Streamsを本番運用する時に検討しておくべきconfigの設定値について - joker1007’s diary
Kafka Streamsをそれなりのデータ規模で運用していくとデフォルトの設定値では動作に困るケースがしばしば出てきます。 その中でも気にしておいた方がいい設定値について紹介していきます。 acceptable.recovery.lag これはあるタスクにおいてStateStoreとchangelogトピックのlagのどこまでを追い付いていると許容するかどうかを設定します。 デフォルト値は10000なんですが、KTableとかで外部からデータが放り込まれていてそれが結構なデータ量だと10000とか一瞬で越えてしまって、一瞬プロセスを再起動しただけでも追い付いていない、みたいな扱いになってrebalanceが即座に走ってしまう挙動になりました。 実際にデータが入ってくるペースを考慮した値に設定しておかないと、プロセスを再起動した際に余計なrebalanceやレストアが走って無駄な停止時間が
大規模Kafkaクラスターで起きた「SYN flood」 再現性のない問題をどのように原因究明したか
2021年11月10日と11日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2021」がオンラインで開催されました。そこで岡田遥来氏が、LINEで最もよく使われるミドルウェアの1つ「Kafka」クラスターのリクエスト遅延を、どのように解決したかについて紹介しました。まずは起きた現象と、その原因究明について。 分散ストリーミングミドルウェア「Apache Kafka」 岡田遥来氏：ではセッションを始めます。よろしくお願いいたします。 こんにちは。岡田遥来と申します。LINEでシニアソフトウェアエンジニアをやっていて、全社的に利用されるApache Kafkaプラットフォームの開発・運用を担当しています。 ご存じの方も多いかもしれませんが、Apache Kafkaは分散ストリーミングミドルウェアで、LINEでは最もよく使われるミドル
rdkafka-ruby で Local: Broker transport failure (transport) が起きる場合の対処方法
rdkafka-ruby を使っていると “Local: Broker transport failure (transport)” というエラーに遭遇することがあります。様々な条件で発生するかもしれませんが、自分が遭遇したのは次の条件を全て満たす時です。 metadata.broker.list (bootstrap.servers) に指定されている broker のうち 1 台以上の調子が悪い 高負荷状態であるとか、broker が起動していないとか producer を生成してからすぐに produce を実行する produce を実行する際に partition_key が指定されている なお、rdkafka-ruby のバージョンは 0.10.0、librdkafka のバージョンは 1.5.0 を前提としています。 エラーが起きる場合の対処方法 次のどれかの選択肢を取ること
Kafkaに接続するJavaアプリケーションをGravitonインスタンスへ移行してパフォーマンスを改善する - joker1007’s diary
社内向けのドキュメントと兼用したので、前提とかメンバー向けの解説が含まれているので、前後のパフォーマンスの変化だけを見たい人は、下の方のグラフ画像までスクロールしてください。 gravitonインスタンスを活用するモチベーション ワークロードによる相性はあるが、特にマルチスレッド性能で既存のインスタンスより性能向上が見られる上にコストが安いため、うまくフィットすれば性能改善とコスト削減の双方でメリットがある。 また、周辺ハードウェアもアップデートされているため、エフェメラルストレージ付きのインスタンスのストレージサイズが増えているなどのメリットもある。 特に現時点ではr6gdインスタンスが利用したかった。 gravitonインスタンスを利用するためarm64アーキテクチャへの対応 gravitonインスタンスはarm64 (aarch64) アーキテクチャのCPUのため、既存のx86_64
Apache Kafka が生まれた理由
今データを使って何かした方がいいと考えているお客様は多いのではないかと思います。Red Hat の金融セミナーでもこの手のお話があり、マネーソーの登壇者が以下の話をしていました。 義務化されるものがある一方で、オープンバンキングを実装するための様々なアプローチがあるのですが、一貫したテーマが一つあることに気付きました。〜略〜 今や誰もが同じデータへアクセスすることが可能で勘定系システムの中にある貴重なデータに基づいて活動できるのは私だけではありません。ではどうしたら差別化できるでしょうか。〜略〜 その答えとは次のようなものです。 データを使っていますぐ何かした方がよい。〜略〜 データに基づく活動が次の未開拓領域です。 ETL を使っていたときの LinkedIn の課題前提 : アクテビティデータActivity data is one of the newer ingredients i
GitHub - redpanda-data/redpanda: Redpanda is a streaming data platform for developers. Kafka API compatible. 10x faster. No ZooKeeper. No JVM!
Redpanda is a streaming data platform for developers. Kafka® API-compatible. ZooKeeper® free. JVM free. We built it from the ground up to eliminate complexity common to Apache Kafka, improve performance by up to 10x, and make the storage architecture safer, and more resilient. The simpler devex lets you focus on your code (instead of fighting Kafka) and develop new use cases that were never before
Amazon Web Services
Home AWS Summits AWS Summits AWS Summit ANZ AWS Summit ASEAN AWS Summit India AWS Summit Korea AWS Summit Japan Events/Webinars Events/Webinars AWS Innovate - AI/ML Edition AWS Innovate - Data Edition AWS Innovate - Modern Apps Edition AWSome Day Online Conference AWS Builders Online Series Hot Topics Hot Topics AI and Machine Learning Migration and Modernization Data and Analytics Modern Applicat
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kafka vs Redpanda Performance - Do the claims add up? — Jack Vanlightly
Redpanda vs. Kafka: A performance comparison (2022 update)
GitHub - maxwellpeterson/kafka-worker: Kafka 0.8.0 broker implementation on top of Cloudflare Workers
GitHub - msfidelis/kafka-stress: CLI Tool to Stress Apache Kafka Clusters
PowerPoint Presentation
LinkedIn、システムの複雑性低減のためにLambdaアーキテクチャを廃止
