メッセージキュー「Pulsar」の紹介 @OSC_20171007

メッセージキュー「Pulsar」のご紹介
〜ヤフーの導⼊事例を交えて〜
ヤフー株式会社システム統括本部
志賀優毅
2017/10/07

Copyright (C) 2017 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 2
⾃⼰紹介
志賀優毅 (GitHub: yush1ga)
経歴：
▪ 2016/04 ヤフー株式会社新卒⼊社
▪ 2016/10~ メッセージキュー「Pulsar」の開発
▪ 2017/06~ 「Pulsar」のCommitter
登壇歴：
▪ 2017/05 GitHub Patchwork
▪ 2017/07 OSC 2017 Hokkaido

Pulsar
Yahoo! Inc. で開発された新しいPub-Subメッセージングシステム
（メッセージキュー）
▪ 2014秋 Yahoo! Inc. が開発を開始
▪ 2015春 Yahoo! Inc. で利⽤開始
▪ 2016/04 Yahoo! JAPANが開発に参加
▪ 2016/09 OSSとして公開
▪ 2017/01 Yahoo! JAPANで利⽤開始
▪ 2017/06 Apache Incubator Projectへ移管

Copyright (C) 2017 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止
アジェンダ
4
アジェンダ
1. メッセージキューについて
2. Pulsar導⼊の背景
3. インターフェースとアーキテクチャ
4. Pulsar on Kubernetes
5. Kafkaとの⽐較
6. Yahoo! JAPANの取り組み

メッセージキューについて

メッセージキュー（MQ）とは？
送信側
システム
受信側
システム
1
2345
メッセージキュー
6
システム間のメッセージのやり取りに使⽤されるソフトウェアの総称
▪ メッセージ … 他のシステムへの通知情報、処理して欲しいデータ、ログなど
▪ キュー … 先に⼊れたものから順に出てくるデータ構造
› メッセージの送信 = キューの最後尾にメッセージを追加する
› メッセージの受信＝キューの先頭からメッセージを取り出す
※ 送受信は⾮同期
MQにメッセージを
送信すると…
送った通りの順番で
相⼿に届く！

メッセージキューを使わなかったら…
送信側
システム
受信側
システム
12
45
3
6
9 8 7 早くメッセージを
受け取って！
ちょっと今は無理…
フロントエンド
サーバ
バックエンド
サーバ
エンドユーザ

メッセージキューを使えば…
送信側
システム
受信側
システム
134
2
相⼿の状態は知らないけど
とりあえずキューに追加！
今は無理だけど⼿が
空いたら受け取るよ
フロントエンド
サーバ
バックエンド
サーバ
エンドユーザ

Pub-Subメッセージングとは？
トピックと呼ばれる宛先に対してメッセージの送受信が⾏われる⽅式
▪ メッセージの送信側＝ Producer / Publisher / 出版者
▪ メッセージの受信側＝ Consumer / Subscriber / 購読者
トピックProducer
Consumer 1
Consumer 2
Consumer 3あるトピックに対して
メッセージを送信すると… メッセージキュー
そのトピックを購読している
相⼿にメッセージが届く！

Pub-Subメッセージングをしなかったら…
送信側
システム1
送信側
システム2
送信側
システム3
送信側
システム4
受信側
システム1
受信側
システム2
受信側
システム3
受信側
システム4
1対1の通信なら問題ないが、1対多や多対多になると複雑で⼤変

Pub-Subメッセージングをすれば…
送信側
システム1
送信側
システム2
送信側
システム3
送信側
システム4
受信側
システム1
受信側
システム2
受信側
システム3
受信側
システム4
トピック1
トピック2
トピック3
送信側も受信側もお互いを意識する必要がない → シンプルかつスケーラブルに

代表的なメッセージキュー
▪ Kafka
› 2011年にLinkedInから公開
› ⼤量のデータを⾼速に処理する事を⽬指し設計
› ストリームデータの処理によく使⽤される
▪ RabbitMQ
› 2007年にRabbit Technologiesから公開
› 通信プロトコルにAMQPを採⽤
› どちらかと⾔えばパフォーマンスよりも信頼性を重視
▪ ActiveMQ
› 2004年から使⽤されている歴史あるプロダクト
› 様々なプロトコルをサポートし、多数の⾔語から利⽤可能なのが強み

Pulsar導⼊の背景

全社プラットフォームとしてのMQを提供したい
■背景：
▪ ヤフーには100程度のサービスがあり、それぞれに開発/運⽤チームが存在
▪ バックエンドの処理（システム連携、データ解析 etc.）にMQを利⽤したい
しかし各チームそれぞれがMQを持つことになると
▪ 設備・運⽤コストが増え、本来やりたかったサービス開発に集中できない
▪ ナレッジが社内で分散する
→ サービス横断で利⽤可能な、全社プラットフォームとしてのMQを提供したい
■求められる要件：
1. ⾼いパフォーマンス / スケーラビリティ
2. 複数のサービスが同居できる
3. 複数のデータセンター間でのレプリケーション

要件1 – ⾼いパフォーマンス / スケーラビリティ
▪ ヤフーでは100程度のサービスを提供しており、それぞれの利⽤者数も膨⼤
▪ 例えばトップページ（PC）の1⽇あたりの利⽤者数は…
› PV（Webページの参照回数）：2億以上
› UB（ユニークなWebブラウザ数）：3千万以上
▪ それを⽀えるMQも⼤量のメッセージを⾼速に処理できる事が求められる
▪ 利⽤者数増⼤の可能性もあるためスケーラブルである事も必須

要件2 - 複数のサービスが同居できる
A⽤MQProducer
サービスA
Consumer B⽤MQProducer
サービスB
Consumer
C⽤MQProducer
サービスC
Consumer Producer
サービスD
ConsumerD⽤MQ
サービスごとに専⽤のMQを⽤意するのはコストが⼤きい
1つのMQに複数のサービスが同居できる（=マルチテナント）ことが求められる
ProducerサービスA Consumer
Producer Consumer
Producer Consumer
Producer Consumer
トピックA
トピックB
トピックC
トピックD
サービスB
サービスC
サービスD

要件3 – 複数のデータセンター間でのレプリケーション
データセンターA
Consumer
▪ ヤフーは地理的に離れた複数のデータセンターでサービスを展開
▪ 全てのデータセンターで同じメッセージを受けて同じ処理を実⾏したい場合：
› 全てのデータセンターにメッセージをPublish？ → ⾮効率的、⼿間がかかる
› 特定のデータセンターのMQに全てのConsumerが接続？ → レイテンシ⼤
→ MQ内で（データセンターをまたいで）レプリケーションして欲しい
Producer Consumer
Consumer
MQ
データセンターB
Consumer
Producer Consumer
Consumer
MQ
データセンターC
Consumer
Consumer
Consumer
ネットワークをまたぐこと
によりレイテンシが増加
各DCでPublishするのは
⾮効率
全DCでPublishするのは
⾮効率的

Pulsarは前述の要件を全て満たす
1. ⾼いパフォーマンス / スケーラビリティ
2. 複数のサービスが同居できる
3. 複数のデータセンター間でのレプリケーション

特徴1 – ⾼速 / スケーラブル
Producer
⼤量のメッセージを⾼速に送受信可能
▪ Yahoo! Inc. での実績
› トピック数：140万
› メッセージ数：1,000億 [msg/day]
› メッセージの送信に要する時間（平均）：5 [ms]
▪ サーバの台数を増やせばその分だけキャパシティを増やせる → スケーラブル
Consumer
Pulsar
Consumer
Pulsar
Producer
Producer
Producer
Producer
Producer
Producer
Consumer
Consumer
Consumer
Consumer
Consumer
スケール
アウト

特徴2 - マルチテナント
ProducerサービスA Consumer
Producer Consumer
Producer Consumer
Producer Consumer
トピックA
トピックB
トピックC
トピックD
サービスB
サービスC
サービスD
他のサービスのトピックへの
アクセスは認証・認可機構で
ブロック
複数のサービスが1つのPulsarインスタンスを共⽤可能
▪ ヤフーでは全社で共有するインスタンスを専⽤のチームが提供・運⽤
▪ 各サービスはサービス開発に集中できる各サービスが利⽤可能な
リソースを個別に設定可能

特徴3 – ジオレプリケーション
Producer トピック
あるデータセンターのトピックに送信したメッセージを他のDCに複製・配信可能
▪ Producerは⾃分と同じデータセンターのPulsarにメッセージを送ればいい
▪ Consumerは⾃分と同じデータセンターのPulsarからメッセージを受け取れる
Pulsar クラスタ A
Consumer
Consumer
Consumer
データセンターA
トピック Consumer
Consumer
Consumer
データセンターB
ジオレプリケーション
Pulsar クラスタ B

利⽤事例 - コンテンツ⼊稿プラットフォーム
▪ ヤフーには外部のコンテンツプロバイダから様々なファイルが⼊稿される
▪ ⼊稿サーバへのファイル転送を検知したら⼊稿ログをPulsarに流す
▪ トピックを購読している各サービスがファイルを取得して処理する
Producer
Consumer
トピック
サービスA
Pulsar
コンテンツの⼊稿ログ
をPulsarに流す
ファイルを取得
Consumer
サービスB
Consumer
サービスC
⼊稿サーバ
コンテンツ
プロバイダ
天気情報、地図情報、
ニュース、etc.
ログサーバ

利⽤事例 - Yahoo!メールのBEシステム
▪ メールの検索インデックスの⽣成/修正といった時間のかかるジョブを⾮同期に
処理するために利⽤
▪ ProducerはPulsarにジョブをキューイング
▪ ConsumerはPulsarからジョブを取り出して順番に処理
Producer
Consumer
Producer
トピック
ジョブを処理する
ハンドラ
メールBEサーバ
メールBEサーバ
Pulsar
リクエスト
ジョブを登録
忙しい時やジョブが
失敗した時は再登録
ジョブを
取り出して処理

インターフェース

Pulsarのインターフェース
▪ クライアントライブラリはJava, C++, Pythonを提供
▪ 他の⾔語からもWebSocket APIを利⽤可能
▪ Producer/Consumerは次のようなトピックURIを指定してPulsarに接続
▪ さらにConsumerはサブスクリプションの名前を指定する必要がある
▪ ⽤途に応じて3種類のサブスクリプションモード（メッセージの配信⽅式）を選択可能
persistent://property/cluster/namespace/destination
サービス名など
データセンターなど
⽤途など
⽤途の詳細などメッセージを永続化

サブスクリプションとは？
Producer
Consumer
Consumer
1
2345
Consumerがトピックの購読を開始した時に作成される購読の管理単位
▪ メッセージのキューはサブスクリプションごとに⽤意される
▪ Consumerとの接続が切れても削除されず、再接続までの間メッセージを溜め続ける
subscription-B
subscription-A
123
45
subscription-Aのキュー
subscription-Bのキュー
トピック

サブスクリプションタイプ1 - Exclusive
Producer
Consumer
Consumer
Consumer
12345
12345
▪ 1つのサブスクリプションには1つのConsumerだけが接続可能
▪ 既にConsumerが存在するサブスクリプションに接続を試みるとエラーになる
subscription-A
(Exclusive)
subscription-B
(Exclusive)
12345
トピック

サブスクリプションタイプ2 - Shared
Producer
12345
Consumer
Consumer
Consumer
25
3
4
1
subscription
(Shared)
▪ 1つのサブスクリプションに複数のConsumerが接続可能
▪ メッセージは各Consumerにラウンドロビンで配信される
▪ 複数のシステムで処理を分担させたい場合に有⽤
トピック

サブスクリプションタイプ3 - Failover
Producer
12345
Consumer
Consumer
Consumer
345
▪ 複数のConsumerが接続可能だが、メッセージを受け取るのはその内1つだけ
▪ そのConsumerがダウンすると別のConsumerがメッセージを受け取るようになる
▪ システムの障害に備えたい場合に有⽤
subscription
(Failover)
トピック
2
1
1と2の受け取り後にダウン

// PulsarのURIを指定してクライアントを作成
PulsarClient client = PulsarClient.create(
"pulsar://broker.usw.example.com:6650");
// トピックを指定してProducerを作成
Producer producer = client.createProducer(
"persistent://my-property/us-west/my-namespace/my-topic");
// メッセージを送信
producer.send("my-message".getBytes());
Javaのサンプルコード - Producer

// トピックとサブスクリプションを指定してConsumerを作成
Consumer consumer = client.subscribe(
"persistent://my-property/us-west/my-namespace/my-topic",
"my-subscription-name");
// メッセージを受信して画面に表示
Message msg = consumer.receive();
System.out.println(new String(msg.getData()));
// メッセージに対するACKを返信（キューからメッセージを削除）
consumer.acknowledge(msg);
Javaのサンプルコード - Consumer

// Consumerの設定にサブスクリプションタイプを追加
ConsumerConfiguration conf = new ConsumerConfiguration();
conf.setSubscriptionType(SubscriptionType.Shared);
Consumer consumer = client.subscribe(
"persistent://my-property/us-west/my-namespace/my-topic",
"my-subscription-name", conf);
Javaのサンプルコード - サブスクリプションタイプの指定

アーキテクチャ

システム構成図 Broker
‣ クライアントとのメッセージのやり取
りを担当
‣ 状態を持たないため増設が容易
Bookie
‣ BookKeeperのストレージノード
‣ トピックに送信されたメッセージやそ
れに関連するデータを保存
ZooKeeper
‣ トピックの管理に必要なメタ情報を保
存
‣ Local ZKはクラスタ内に閉じた情報を
担当
‣ Global ZKは全てのクラスタで共有すべ
き情報を担当
Producer Consumer
Broker 1 Broker 2 Broker 3
Bookie
1
Local
ZooKeeper
Bookie
2
Bookie
3
Pulsar クラスタ
Global
ZooKeeper

BookKeeperとは？
▪ オープンソースの分散型ログストレージサービス
▪ データを複製し複数のノード（Bookie）に分散して保存 → 強い耐障害性
▪ ノード数を増やせば容量と速度の向上が可能 → スケーラブル
A
Bookie2 Bookie3
D
C
A
B
D
B
C
Bookie1
データの複製数は⾃由に変更可能

BookKeeperのアーキテクチャ
▪ 先⾏書き込みログ
› ストレージに対する「操作」を先に書き込む
› ストレージへの反映は後からバックグラウンドで
› 途中で電源が落ちても「操作」を再開可能
› 容量より速度を重視したいので⾼速なSSDを使⽤
▪ 永続化ストレージ
› 連続するデータをまとめてキャッシュに読み込んでおく
› ⼀般にメッセージキューは連続するデータを扱うため効率がよい
› 速度より容量を重視したいので⼤容量なHDDを使⽤
速度と永続性の両⽴を実現
先⾏書き込みログ
（SSD）
永続化ストレージ
（HDD）
Bookie
書き込み
キャッシュ
先⾏読み込み
キャッシュ
Write
Read

Pulsar on Kubernetes

Kubernetesとは
▪ Dockerのオーケストレーションツール
▪ Dockerとは
› コンテナ型仮想化技術
コンテナ
App
ホストOS
ハードウェア
コンテナ
App

Dockerの問題点の例
コンテナ
App
コンテナ
App
Private IP
ホスト1
コンテナ
App
コンテナ
App
😇❓
ホスト2
Private IP

Kubernetesを使うと
コンテナ
App
コンテナ
App
Cluster IP
Kubernetesクラスタ (複数台のホストから構成)
コンテナ
App
コンテナ
App
Cluster IPCluster IP
あたかも1台の実⾏環境であるかのように利⽤可能

Pulsar on Kubernetes
▪ Pulsarは
› Google Container Engine (GKE)
› AWS
› 独⾃
のKubernetesクラスタに簡単にデプロイ可能
▪ GKEでのデプロイ⼿順を紹介
▪ 詳細な⼿順はこちら
https://pulsar.incubator.apache.org/docs/latest/deployment/Kubernetes

Google Cloud Platformの準備
▪ 事前準備として以下が必要
› cloud.google.comにサインアップできるGoogle Cloud Platformアカウント
› 既存のCloud Platformプロジェクト
› Google Cloud SDK (特にgcloudとkubectlツール)
無料トライアルアカウントでも可

Google Cloud Platformの準備

新しいKubernetesクラスタの作成
$ gcloud container clusters create
pulsar-gke-cluster # クラスタ名
--zone=us-central1-a # リージョンとゾーン
--machine-type=n1-standard-4 # マシンの種類
--num-nodes=2 # ノード数
--local-ssd-count=2 # ローカルSSDの数
※無料トライアルアカウント⽤に
ドキュメントよりスペックを下げています

Kubernetesダッシュボードの表⽰
$ gcloud container clusters get-credentials
pulsar-gke-cluster --zone=us-central1-a --
project=<project-id>
$ kubectl proxy
上記のコマンド⼊⼒後
http://localhost:8001/uiにブラウザからアクセス可

Pulsarのデプロイ – ZooKeeperのデプロイ
# yaml定義のあるディレクトリに移動
$ cd /path/to/incubator-pulsar/kubernetes
/google-container-engine
# デプロイ
$ kubectl apply -f zookeeper.yaml
# クラスタメタデータの初期化
$ kubectl exec -it zk-0 -- bin/pulsar
initialize-cluster-metadata --cluster us-central
--zookeeper zookeeper --global-zookeeper
zookeeper --web-service-url http://broker
.default.svc.cluster.local:8080/ --broker-
service-url pulsar://broker.default.
svc.cluster.local:6650/

Pulsarのデプロイ – 残りのコンポーネントのデプロイ
# bookie, broker, 監視ツールのデプロイ
$ kubectl apply -f bookie.yaml
$ kubectl apply -f broker.yaml
$ kubectl apply -f monitoring.yaml
以上でデプロイは完了

デプロイ完了後のKubernetesダッシュボード

Grafana

Pulsarダッシュボード

▪ 以下のコマンドから管理ツールを実⾏するためのコンソールにアクセス可能
▪ コンソールからパフォーマンステストも実⾏可能
51
管理ツール
$ kubectl exec pulsar-admin -it -- bash
$ bin/pulsar-perf produce persistent://prop/us-
central/ns/my-topic --rate 150000
# 実行結果
2017-09-28 05:35:30,398 - INFO -
[main:PerformanceProducer@341] - Throughput
produced: 149979.1 msg/s --- 1171.7 Mbit/s --
- Latency: mean: 46.952 ms (後略)

▪ 以下のコマンドから管理ツールを実⾏するためのコンソールにアクセス可能
▪ コンソールからパフォーマンステストも実⾏可能
52
管理ツール
$ kubectl exec pulsar-admin -it -- bash
$ bin/pulsar-perf produce persistent://prop/us-
central/ns/my-topic --rate 150000
# 実行結果
2017-09-28 05:35:30,398 - INFO -
[main:PerformanceProducer@341] - Throughput
produced: 149979.1 msg/s --- 1171.7 Mbit/s --
- Latency: mean: 46.952 ms (後略)
毎秒15万メッセージ！レイテンシ50ms！

Kafkaとの⽐較

Kafkaとは
▪ スケーラブルな分散Pub-Subメッセージングシステム
▪ 2011年にLinkedInから公開
▪ ⼤量のデータを⾼速処理する事を⽬指し設計
▪ ストリームデータの処理によく使⽤される
Pulsarと被る部分が多い
Pulsarのアドバンテージとは？

マルチテナントの実現しやすさ
Pulsar ◯トピックが階層化されているため、ネームスペース単位で設定変更が
可能で、設定変更作業を利⽤者側に委任しやすい
Kafka △トピックは階層化されておらず、トピックごとに設定が必要
Pulsarはマルチテナントを実現しやすいよう設計されている

トピック構造の違い
log-stream-for-log-a
job-queue-for-job-a
job-queue-for-job-b
service-a
job-
queue
job-a
log-
stream
job-b
log-a
log-b
Property
log-stream-for-log-b
Namespace Destination
Kafka
Pulsar
ACL
ACL
ACL
ACL
ACL
ACL
ACL
トピックごとに
設定が必要
ネームスペースの
設定を継承

Brokerの負荷分散
Pulsar ◯負荷に応じて⾃動的にBrokerが担当するトピックが移動
◯Brokerを増設した際、トピックの再割り当ては不要
Kafka △Brokerが担当するパーティションは固定
△Brokerを増設した際、パーティションの再割り当てが必要
PulsarはBrokerにデータを保持しないため、負荷分散が⾃動的に⾏われる

Yahoo! JAPANの取り組み

Yahoo! JAPANのPulsarに対する取り組み
▪ C++クライアントライブラリのOSS化
▪ Athenz⽤認証プラグインのOSS化
(※Athenzはロールベースの認証認可システムを実現するOSS)
▪ Spark Streamingのカスタムレシーバ作成
▪ ワイルドカードを⽤いた認可機能の追加
▪ ドキュメントの⽇本語化
▪ その他細かいバグ修正や機能追加

まとめ

まとめ
61
まとめ
▪ Pulsar
› 分散Pub-Subメッセージングシステム
› ⾼速、スケーラブル、マルチテナント、ジオレプリケーション
› 特に⼤規模なサービスでの利⽤に向く
▪ コード・ドキュメントはhttps://pulsar.incubator.apache.orgにあります
▪ ⽇本語ドキュメントもあります
▪ 質問やフィードバックはメーリングリストへ：
› users@pulsar.incubator.apache.org
› dev@pulsar.incubator.apache.org

Pulsarの近況 - 最近マージされた機能
▪ Kafka client Java API wrapper
› KafkaProducer / KafkaConsumerのインターフェイスでPulsarを利⽤するためのラッパー
▪ End-to-Endでの暗号化
› メッセージをproduce時に暗号化 / consume時に復号する機能を追加
▪ non-persistentなトピック
› メッセージを永続化しないことでより⾼速なproduce / consumeを可能にするトピック
▪ produce時の重複排除
› メッセージをproduceする際にBroker側で重複を排除する

メッセージキュー「Pulsar」の紹介 @OSC_20171007

メッセージキュー「Pulsar」の紹介 @OSC_20171007

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (11)

Similaire à メッセージキュー「Pulsar」の紹介 @OSC_20171007

Similaire à メッセージキュー「Pulsar」の紹介 @OSC_20171007 (20)

Dernier

Dernier (9)

メッセージキュー「Pulsar」の紹介 @OSC_20171007