Pulsarとはどんな技術なのか。その概要とヤフーによる導入事例など、イベントで語られた内容を紹介します。
Yahoo! Inc.が開発したOSS「Pulsar」とは？
今回のMeetUpは新しくオープンしたばかりの新社屋、東京ガーデンテラス紀尾井町17階のコワーキングスペース「LODGE」で開催！
LODGEの広さは1330平方メートル。このような人数を集めてプレゼンテーションができる場所はもちろん、ミーティングスペースなど、情報交換や新たな協業を生み出していけるような仕組みがさまざま用意されています。
司会進行を務めたのは、福田奏。
同技術を紹介するのに先立ち、システム統括本部 プラットフォーム開発部長の服部典弘があいさつを行いました。
「Pulsarとの出会いは2015年11月11日。Yahoo! Inc.に行ったときに、すごいメッセージングキューシステムを見て、衝撃を受けました。しかも、OSSとして公開をするということで興奮を覚えました。ぼくらも公開を手伝うために開発にかかわり、ようやく9月にOSSとして公開し、このようなイベントを開催できるようになりました。ヤフーでは、これからもOSSに貢献していきたい。そしてPulsarはヤフーが公開にかかわったOSSとして、伸びていってもらいたいと願っています」
今回はPulsar開発のアーキテクト、Yahoo! Inc.のMatteo Merli（マテオ・マルリ）がPulsarの概要を紹介。
そして、ヤフーの社内向けメッセージングシステムのリードエンジニア北條正和が通訳を務めました。
Yahoo! Inc.が開発した「Pulsar」はホステッド型、高信頼性・高パフォーマンス・スケーラビリティに富んだPub/Subメッセージプラットフォーム。
特徴は1つのインスタンスを複数のサービス（テナント）が共有する形となっていること。障害が起きたときの対応が簡単だったり、マシンを新しく追加した際のセットアップが一部自動でできたりなど、簡単に利用できることを意識して作られています。
Yahoo! Inc.では2年ぐらい使われており、1日当たりに生成されるメッセージ数は1000億以上。トピック数は140万と巨大ですが、今までにデータロスはなく、パブリッシュレイテンシーは平均5ms以下を実現しています。
またPulsarは80以上のアプリケーションで利用されています。AWSのようにWeb上で簡単な操作をするだけで、すぐに利用できるように設計。現状は8つのデータセンターでPulsarのクラスターが稼働しているのです。
主なユースケースは3つ。
●システム間/アプリケーション間のインテグレーション
システム間で状態の遷移など、お互いに通知しあうところに使われている。
●永続性のあるキュー
ストリーム・プロセッシング、バッファリング、フィードインジェスチョン、タスクディスパッチャなどに使われる。
●巨大なデータストアのメッセージバス
Pulsar自体がプラットフォームとして提供されているが、Pulsarを利用して作られたプラットフォームもあり、遠隔地のデータセンターへのリプリケーションに使われている。
Pulsarが提供する主な機能と開発の背景
Pulsarが提供する主な機能は、以下の3つです。
1.REST/Java/コマンドラインAPI
初期設定やメトリックスを取得する機能がREST-APIやコマンドラインツールとして提供されている
2.マルチテナンシー
Pulsarは1つのインスタンスを複数のサービスで利用できる。どのサービスかを特定するために、認証/認可機能を提供。
それぞれのサービスで使われているトピック、サブスクリプション管理の機能を持つ。不要なメッセージを消す機能などを提供する。
3.メッセージリテンションとリプライ
メッセージを受け取り処理した後で、同じ処理をやり直したいというときに、リテンション機能を使って、例えば3時間前のメッセージから送り直すことができる。
なぜPulsarを開発したのかをひと言で言うと、Yahoo! Inc.の自分たちの要求「マルチテナント」「大量のトピックスを扱える」「低レイテンシーと耐久性の両方を満たす」「ジオレプリケーション（遠隔地に同じデータを複製・格納し、可用性を担保する仕組み）」を満たすソフトウエアがなかったから。
またオープンソースの分散メッセージングシステムというと「Apache Kafka」が思いつきますが、Kafkaでは以下の理由により採用ができなかった。KafkaのストレージモデルがYahoo! Inc.の要求と合わなかったことです。
Kafkaのストレージモデルはトピックごとにパーティションを持つファイルシステムを基本としていたこと。私たちは100万のトピックを扱うため、ファイルシステムという形式では難しいと判断したのです。
そのほかにも、巨大なバックログの管理する能力、運用の容易性も求めていました。例えばKafkaの場合、クライアントがApache Zookeeperにアクセスする必要がありますが、Pulsarはそれを必要としません。
Zookeeperにはいろんなデータが入っているため、クライアントからアクセスするようにすると面倒になるからです。そのほかにも、コンシューマの方でどこまでメッセージを受け取ったというポジションの保存をしたくなかったのです。
さらに、障害からの回復を行う際に、Kafkaでは古いサーバーから新しいサーバーにデータをコピーするという作業が必要になりますが、それをしたくはありませんでした。
Pulsarのメッセージモデルは図の通り。
Pulsarでは1つのトピックを複数のコンシューマでsubscribeできますが、サブスクリプションのタイプはExclusiveとSharedの2つ。サブスクリプションAは1つのサブスクリプションには1つのコンシューマしかつながらず、メッセージの順序も保たれる。一方のサブスクリプションBは、複数のコンシューマにつながりますが、メッセージの順序は保証されません。
サブスクリプションAとBは同時に存在できます。また実際にPulsarを使うときのJavaのコードは図の通り。指定されているURLはBrokerの位置を示しています。
左はプロデューサー側のプログラム。Pulsarクライアントを生成して、どのBrokerを使うか指定。その次にプロデューサーを生成します。
生成したプロデューサーは、ずっと使うことができます。最後の2行はメッセージの送信プログラム。メッセージは同期でも非同期で送信可能となっています。
右はコンシューマ側のプログラム。最初のPulsarクライアントを生成する部分は、プロデューサー側と同じ。次のCliant.subscribeでコンシューマを生成する。
ここではトピック名にサブスクリプション名をプラスして付けている。複数のサブスクリプションを生成して、混ぜ合わせて使うことが可能。表示のコードは同期ですが、非同期のAPIも持っています。
クライアントライブラリで提供されている主な機能は以下の通り。
- 同期・非同期のオペレーション
- パーティショントピック：1つのトピックを複数のパーティションに分割して扱う機能
- 複数のメッセージをまとめて送信する機能
- 圧縮
- エンド・ツー・エンドチェックサム：ネット上でメッセージが化けてしまったときに、それを検知する機能
- TLSによる暗号化
- 複数のメッセージに対するACKをまとめて送る機能
- クライアントサイドの統計情報：レイテンシーが高くなっているところなどを調べることができる
図のようなアーキテクチャとなります。
Pulsarでは、クライアントはBrokerとのみ通信を行います。Broker は状態を持っておらず、メッセージはBookieで保存。PulsarのメッセージのストレージはBookKeeperを使用します。
1つのクラスターの中に複数のBookKeeperのインスタンスがあり、その中に各トピックのデータが分散されて保存されているのです。
BrokerとBookieの2層構造にしているのは、独立して数を増やしていけるというメリットがあるから。配付部分がボトルネックとなっているのであれば、Brokerを増やす。メッセージを保存するというところがボトルネックとなっているのであれば、Bookieを増やすことでボトルネックを解消できます。
もう一つのメリットは、壊れてしまったり、過負荷になってしまった場合に、単純に1つ増やすことでトピックの担当しているBrokerをスイッチすることができること。このように2層構造にすることで、Pulsarは難しいことを気にすることなく、簡単に規模を拡大できます。
Brokerの内部は以下の図の通り。1台のBrokerで1秒間に5000～6000メッセージを扱うことができます。Bookieも同様で、1秒間に数千という単位でメッセージを扱うことが可能です。このような高速性を実現しているのは、図のようなアーキテクチャを採用しているからです。
Pulsarのログ部分にBookKeeperを採用した理由は、シーケンシャルなデータに対して効率の良いストレージだったこと。入出力がBookie間で分散されること。書き込み、読み込みが独立していること。求める永続性と速度に応じてパラメータを調整可能なことです。
Pulsarのパフォーマンスはグラフの通り。これは1つのトピックに対して1つのプロデューサーでパブリッシュしたときのレイテンシーをグラフ化したもの。
メッセージサイズが小さければ、より多くのメッセージを少ないレイテンシーで送ることができます。
2ヶ月前にPulsarのソースコードを公開し、GitHubに挙げているので、ぜひチェックしてみてください。質問も受け付けています。
ヤフーがPulsarの採用を決めたわけ
続いては、北條による、「ヤフーでのPulsar導入事例」のセッション。ヤフーではお客さま向けに約100のサービスを提供しています。これらのサービスを支えるシステムはフルスクラッチではなく、共通で使う機能（ストレージやデータベースなど）は複数のサービスから利用できる形で用意しています。
各サービスはそれらの機能と各サービス独自のロジックで組み合わせて開発します。このような形で機能を提供するため、マルチテナント機能を持つPulsarがマッチというわけです。
マルチテナントのメリットは、サーバーなどの数が少なくできるなど、設備コストを削減できること。また1インスタンスで複数のサービスに対してメッセージングサービスが提供できるので、ちょっとしたチューニングが違うという理由で、個別にインスタンスを立てるが必要なく、運用コストも低減できること。
また、個別のサービスで運用をしているとナレッジが分散してしまいますが、メッセージングの専門家を1ヶ所に集めてMaaSとして提供するので、ナレッジの集約もできます。そしてメッセージングの難しいところを考えずに、サービス開発に集中できることもメリットです。
マルチテナントを実現する上で重要になるのが認証認可です。マルチテナントは1つのトピックに対して複数のサービスがアクセスできるので、不要なメッセージを間違えて違うトピックに流してしまったり、他のサービスには公開したくないデータが他のサービスから見えてしまったりということが起こりえます。それをコントロールするため、Pulsarは認証顔機能を搭載しています。
ヤフーでPulsarを使い始めたのはごく最近。利用しているサービスもまだまだ少ないため、社内の少人数で開発を行っているあるシステムでは、システム間のメッセージングにPulsarを採用しました。
採用の理由は、第一にメッセージング機能の開発に時間を割きたくなかったこと（コストを最小限にしたい）。第二にすぐに使いたかった。これらがMaaSの提供する価値とマッチした。
今後の予定としては、Pulsarを社内で本格リリースします。そして実際のサービスで活用してもらい、フィードバックを得たいと考えています。さらに、それをOSSのコミュニティーへとフィードバックし、OSSコミュニティーへ貢献していきたいと思います。
今後もヤフーとしてOSSに貢献し、注力していくつもりです。実はMeetupイベントもその1つの試み。次回のMeetupではどんな技術が公開されるのか、ぜひご期待ください！
講演後は質問が飛び交う楽しい懇親会に
Pulsarについての講演終了後は、そのまま会場で懇親会を開催。登壇者以外にもヤフー社員が加わり、 Pulsarに関する質問や活発な意見交換が行われました。
ヤフーでは、定期的にこうしたヤフー社員と交流の場を持つイベントを開催しています。ぜひご興味を持った方はお気軽にご参加ください。お待ちしております！
