メッセージキュー「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


PulsarYahoo! 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 Kubernetes5. Kafkaとの⽐較6. Yahoo! JAPANの取り組み


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


メッセージキュー（MQ）とは？

送信側システム

受信側システム

12345

メッセージキュー

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




受信側システム1




1対1の通信なら問題ないが、1対多や多対多になると複雑で⼤変


Pub-Subメッセージングをすれば…









トピック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

サービスAConsumer B⽤MQProducer

サービスBConsumer

C⽤MQProducer

サービスCConsumer Producer

サービスDConsumerD⽤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

ProducerProducerProducerProducerProducerProducer

ConsumerConsumerConsumerConsumerConsumer

スケールアウト


特徴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

Producer12345

Consumer

Consumer

Consumer

25

3

41

subscription(Shared)

▪ 1つのサブスクリプションに複数のConsumerが接続可能▪ メッセージは各Consumerにラウンドロビンで配信される▪ 複数のシステムで処理を分担させたい場合に有⽤

トピック


サブスクリプションタイプ3 - Failover

Producer12345

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


PulsarClient client = PulsarClient.create("pulsar://broker.usw.example.com:6650");

// トピックとサブスクリプションを指定して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


PulsarClient client = PulsarClient.create("pulsar://broker.usw.example.com:6650");

// 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

Bookie1

LocalZooKeeper

Bookie2

Bookie3

Pulsar クラスタ

GlobalZooKeeper


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-blog-alog-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にあります▪ ⽇本語ドキュメントもあります▪ 質問やフィードバックはメーリングリストへ：› [email protected]› [email protected]


Pulsarの近況 - 最近マージされた機能

▪ Kafka client Java API wrapper› KafkaProducer / KafkaConsumerのインターフェイスでPulsarを利⽤するためのラッパー

▪ End-to-Endでの暗号化› メッセージをproduce時に暗号化 / consume時に復号する機能を追加

▪ non-persistentなトピック› メッセージを永続化しないことでより⾼速なproduce / consumeを可能にするトピック

▪ produce時の重複排除› メッセージをproduceする際にBroker側で重複を排除する

Technology

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