Schema Registryを使ったKafkaにおけるAvro Schemaの管理について - シンガポール在住Data Engineerの覚書
最近、仕事でSchema Registryの導入を進めているので、調べたことなどを記しておきたいと思います。 Schema Registryとは www.confluent.io Schema Registry stores a versioned history of all schemas and allows the evolution of schemas according to the configured compatibility settings. It also provides a plugin to clients that handles schema storage and retrieval for messages that are sent in Avro format. Schema Registry とは、ここに書いている通り、スキーマのバージョン管理
巨大企業のサーバー構成や内部ツールを覗く - 発明のための再発明
はじめに この記事は設計・アーキテクチャ Advent Calendar 2018の１日目の記事です。 大きなサービスを支えるのは一筋縄では行かず、考えることは多くあります。しかし、ありがたいことに巨大な企業の中にも自社のサーバー構成やそれを支えるツールを公開している企業があります。 この記事では、彼らの叡智に触れるため、有名企業の事例を取り上げ要約をします。 各事例には元記事へのリンクを書いているので、興味があればリンク先も覗いてみてください。 ※新しいものばかりではないので、古くなっていたり既に別の方法に移行している可能性があることに注意してください。 LINE: 25k/secのスパイクをさばくアーキテクチャ 元記事: 25K request/secをさばいた「LINEのお年玉」のアーキテクチャの裏側 最初に紹介するのは、LINEが2018年に実施した、「LINEのお年玉」というイベ
Apache Kafkaの性能検証(5): システム全体のレイテンシについて - Qiita
初版: 2018/11/16 著者: 伊藤 雅博, 株式会社日立製作所 はじめに この投稿ではオープンソースカンファレンス2017.Enterpriseで発表した「めざせ！Kafkaマスター ～Apache Kafkaで最高の性能を出すには～」の検証時に調査した内容を紹介します（全8回の予定）。本投稿の内容は2017年6月にリリースされたKafka 0.11.0 時点のものです。 最終回となる今回は、システム全体のレイテンシについて紹介します。前回まではデータ処理のスループットに着目してチューニングを行ってきました。一般的に、スループットが増加するとレイテンシも増加しますが、これまでの検証で行ったチューニングではレイテンシを考慮していませんでした。そこで今回はレイテンシの測定結果について紹介します。 過去の投稿： 1. Apache Kafkaの概要とアーキテクチャ 2. Apache K
Apache Kafkaの性能検証(4): Producerの再チューニングおよびConsumerのチューニング結果 - Qiita
初版: 2018/11/9 著者: 伊藤 雅博, 株式会社日立製作所 はじめに この投稿ではオープンソースカンファレンス2017.Enterpriseで発表した「めざせ！Kafkaマスター ～Apache Kafkaで最高の性能を出すには～」の検証時に調査した内容を紹介します（全8回の予定）。本投稿の内容は2017年6月にリリースされたKafka 0.11.0 時点のものです。 第7回目となる今回は、Producerの再チューニング結果とConsumerのチューニング結果を紹介します。第6回の投稿ではBrokerのチューニングを行いましたが、最終的にはスループットが大幅に低下してしまいました。そこで今回は、Brokerのチューニングをした状態で改めてProducerのチューニングを行ってみます。その後Consumerのチューニングを行い、Producerの送信からConsumerの受信まで
Apache Kafkaの性能検証(3): Brokerのチューニング結果 - Qiita
初版: 2018/11/1 著者: 伊藤 雅博, 株式会社日立製作所 はじめに この投稿ではオープンソースカンファレンス2017.Enterpriseで発表した「めざせ！Kafkaマスター ～Apache Kafkaで最高の性能を出すには～」の検証時に調査した内容を紹介します（全8回の予定）。本投稿の内容は2017年6月にリリースされたKafka 0.11.0 時点のものです。 第6回目となる今回はBrokerのチューニング結果を紹介します。第5回の投稿では、Producer-Broker間の通信スループットを最適化しました。この最適化をした状態で、今回はBrokerのLogフラッシュ性能と、Broker間のレプリケーション性能をそれぞれチューニングして、スループットを最適化していきます。 投稿一覧： 1. Apache Kafkaの概要とアーキテクチャ 2. Apache KafkaのP
Apache Kafkaの性能検証(2): Producerのチューニング結果 - Qiita
初版: 2018/10/26 著者: 伊藤 雅博, 株式会社日立製作所 はじめに この投稿ではオープンソースカンファレンス2017.Enterpriseで発表した「めざせ！Kafkaマスター ～Apache Kafkaで最高の性能を出すには～」の検証時に調査した内容を紹介します（全8回の予定）。本投稿の内容は2017年6月にリリースされたKafka 0.11.0 時点のものです。 第5回目となる今回は、Producer-Broker間の送信スループットをチューニングした際の性能測定結果を紹介します。 投稿一覧： 1. Apache Kafkaの概要とアーキテクチャ 2. Apache KafkaのProducer/Broker/Consumerのしくみと設定一覧 3. Apache Kafkaの推奨構成と性能の見積もり方法 4. Apache Kafkaの性能検証(1): 検証環境とパラメ
Apache Kafkaの性能検証(1): 検証環境とパラメータチューニングの内容 - Qiita
初版: 2018/10/19 著者: 伊藤 雅博, 株式会社日立製作所 はじめに この投稿ではオープンソースカンファレンス2017.Enterpriseで発表した「めざせ！Kafkaマスター ～Apache Kafkaで最高の性能を出すには～」の検証時に調査した内容を紹介します（全8回の予定）。本投稿の内容は2017年6月にリリースされたKafka 0.11.0 時点のものです。 第4回目となる今回からは、実際にKafkaの性能検証を行った際の測定結果を紹介していきます。今回はまず、検証環境のシステム構成と検証方法について紹介します。 投稿一覧： 1. Apache Kafkaの概要とアーキテクチャ 2. Apache KafkaのProducer/Broker/Consumerのしくみと設定一覧 3. Apache Kafkaの推奨構成と性能の見積もり方法 4. Apache Kafka
Apache Kafkaの推奨構成と性能の見積もり方法 - Qiita
初版: 2018/10/12 著者: 伊藤 雅博, 株式会社日立製作所 はじめに この投稿ではオープンソースカンファレンス2017.Enterpriseで発表した「めざせ！Kafkaマスター ～Apache Kafkaで最高の性能を出すには～」の検証時に調査した内容を紹介します（全8回の予定）。本投稿の内容は2017年6月にリリースされたKafka 0.11.0 時点のものです。 第3回目となる今回は、Kafkaの推奨システム構成とネットワーク・ディスク性能の見積もり方法について紹介します。 投稿一覧： 1. Apache Kafkaの概要とアーキテクチャ 2. Apache KafkaのProducer/Broker/Consumerのしくみと設定一覧 3. Apache Kafkaの推奨構成と性能の見積もり方法 (本投稿) 4. Apache Kafkaの性能検証(1): 検証環境とパ
Apache Kafkaの概要とアーキテクチャ - Qiita
初版: 2018/9/28 著者: 伊藤 雅博, 株式会社日立製作所 はじめに この投稿ではオープンソースカンファレンス2017.Enterpriseで発表した「めざせ！Kafkaマスター ～Apache Kafkaで最高の性能を出すには～」の検証時に調査した内容を紹介します（全8回の予定）。本投稿の内容は2017年6月にリリースされたKafka 0.11.0 時点のものです。 第1回目となる今回は、Apache Kafkaの概要とアーキテクチャについて紹介します。 投稿一覧： 1. Apache Kafkaの概要とアーキテクチャ (本投稿) 2. Apache KafkaのProducer/Broker/Consumerのしくみと設定一覧 3. Apache Kafkaの推奨構成と性能の見積もり方法 4. Apache Kafkaの性能検証(1): 検証環境とパラメータチューニングの内容
AWS での Apache Kafka の実行のためのベストプラクティス | Amazon Web Services
Amazon Web Services ブログ AWS での Apache Kafka の実行のためのベストプラクティス この記事は Intuit とのパートナーシップに基づいて書かれ、AWS で Apache Kafka クラスタを実行するための学習、ベストプラクティス、推奨事項を共有するものです。Intuit の Vaishak Suresh と同氏の同僚の方々の貢献とサポートに感謝いたします。 Intuit の概要: Intuitは、AWS のエンタープライズ顧客のリーダーであり、ビジネスと財務管理ソリューションのクリエーターです。Intuit の AWS とのパートナーシップに関する詳細については、以前のブログ記事 Real-time Stream Processing Using Apache Spark Streaming and Apache Kafka on AWSを参照し
Kafka・Storm・ZooKeeperの認証と認可について #kafkajp
Apache Kafka Meetup Japan #3 https://kafka-apache-jp.connpass.com/event/58619/ 発表資料
1台のサーバーでZooKeeperアンサンブル、Kafkaクラスターを構成 - Qiita
概要 1台のサーバー上でZooKeeperアンサンブルとKafkaクラスターを構成したときのメモです。 ZooKeeperはKafkaに同梱のものを使用しました。 構成図は以下になります。 サーバーの環境情報は以下の通りです。 CentOS V7.4 OpenJDK V1.8 Kafka V1.1.0 構成手順 ZooKeeperの設定ファイルの作成 今回ZooKeeperは3インスタンスでアンサンブルを構成するため、以下の3つのプロパティーファイルを用意します。 ZooKeeper#1用プロパティーファイル tickTime=2000 initLimit=5 syncLimit=2 dataDir=/var/lib/zookeeper1 clientPort=2181 server.1=localhost:2888:3888 server.2=localhost:2889:3889 se
Apache Kafkaとストリーム処理/Reactive Streams
2018-05-26に行われた「JJUG CCC 2018 Spring」で発表した時の資料です。
MicroAdのデータ基盤 - MicroAd Developers Blog
こんにちは。インフラエンジニアの@kanga333です。 最近マイクロアドではデータ基盤を刷新しました。 今回はデータ基盤の刷新に至る背景と新基盤での設計ポイントについてざっくり書いていきたいと思います。 刷新に至る背景 マイクロアドを長年支えてきた既存データ基盤は長年の改修の結果、色々な課題を抱えていました。 データの転送がNFS, Fluentd, Kafkaなど機能毎に色々な方法で行われており、共通基盤的な部分にもかかわらず共通化ができていませんでした。 Hadoopクラスタはサービス毎に立ち上がっていました。クラスタのバージョンは更新できておらず、運用コストが膨らんでいました。 クラスタが分散しているので、データサイエンティストが新しい環境にデータを集める際に、どこににデータがあるのか各担当者にヒアリングする必要がありました。 そして、そこに第一回の記事でも触れているようにDWHの
これからはじめるKafkaリンク集 | 外道父の匠
お久！2017年前半頃から少しずつ触り始めたKafkaですが、運用に至るまでに必要な基本情報をまとめてみました。年明けのブログ欲衰退を吹き飛ばすにはリンク集に限ります。メモをブログ用に置換するだけなのだ！ Kafkaで何をやるかによっては全然足りないでしょうが、まぁ静かなブームっぽいので、触ろうとする人たちはたいてい自分でなんとかするマニアばっかりでしょう。自分も、やるべきことは大体やったけど、シリーズ化するかは未定ですたい。 Official Apache Kafka Documentation Apache Kafka 日本語訳 Index – Apache Kafka – Apache Software Foundation FAQ – Apache Kafka – Apache Software Foundation Book Kafka: The Definitive Guide
今のデータが知りたい！に応えるPythonでのリアルタイム処理基盤の構築をざっと振り返る - Qiita
本記事はNTTコム公式アドベントカレンダーの25日（最終日）の記事です。 まさか最終日の記事担当とは恐縮です1。 著者は、技術開発部に所属し、社内外の各種データ分析、異常検知技術の研究開発を行っています。最近の研究成果は、AAAIのカンファレンスIAAI2018で採択されました。 はじめに 分析結果をいちはやくチーム内、各種サービス部に提供するために、OSSを駆使した分析基盤をチームで構築しています。分析結果をレポーティングするにあたり、データの集計や分析処理が必要になります。閲覧者により、レポーティング間隔（分析結果の更新頻度）の要求もさまざまです。例えば、 定期的なメール配信、データの最新化、機械学習のモデルの更新（1日に1回のバッチ処理） １日に何度かデータにアクセスして、データの状況を確認する（◯分間 / ◯時間でのバッチ処理） 常に今のデータをモニタリングしたい（ニアリアルタイム
Apache Kafkaを使ったアプリ設計で反省している件を正直ベースで話す
Apache Kafka: Producer, Broker and Consumer2017年は生まれて始めてApache Kafkaを本格的に業務利用（PoCではなく本番運用）した年でした。Apache Kafka的なメッセージングミドルウェアそのもののは、社内的な事情でよく使っていたのでその使い勝手に対して困惑はほとんど無かったですし、ミドルウェアとして非常に安定しているため、Kafkaクラスタそのものでの不具合らしい不具合が発生したことは一度もありませんでした。 しかし、Kafkaのトピック設計などに関してのベストプラクティスは事例ベースでもあまり見かけたことがなく、チームメンバーと悩むことも多かったです。このストーリーでは、主にKafkaを利用したアプリ設計で考えたことや失敗したことを振り返りつつ共有します。なお、パーティション数や各種バッファサイズなどのチューニング要素は今回取
tcpdumpからKafkaのリトライ可能エラーを追う - n-agetsumaの日記
Kafkaのメッセージロストの原因の1つに、プロデューサの設定のretries(デフォルト0:リトライしない)の未設定がある。 Kafkaクライアントの送信リトライ プロデューサからメッセージ送信時のエラーには、retires設定によりKafkaのクライアントライブラリ内で自動リトライ可能なエラーと、リトライせずにProducer.sendメソッドの呼び出し元に例外を投げるエラーがある。自動リトライ可能なエラーで発生する例外は、org.apache.kafka.common.errors.RetriableExceptionの継承クラスである。代表的なものを以下に示す。 retiresによりリトライするエラー NotLeaderForPartitionException リーダーパーティションではないブローカーにメッセージが送られた場合のエラー応答。ブローカー障害によるフェールオーバ中にメ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
kafka-1.0-exactly-once
https://www.ospn.jp/osc2017.enterprise/pdf/OSC2017.enterprise_Hitachi_Kafka.pdf