• X
  • Facebook
  • RSS
トップ > タイアップ広告 > Yahoo! JAPANの新しいメッセージングシステムと、それをOSSで開発するエンジニアの素顔

Yahoo! JAPANの新しいメッセージングシステムと、それをOSSで開発するエンジニアの素顔

タイアップ広告 Web・IT Sponsored


国内有数のWebサイトであるYahoo! JAPANでは、その膨大なトラフィックを支える大規模なインフラチームを擁しています。大量なだけではなく、多様なサービスが生み出すさまざまなデータを処理したいという要求から、オープンソースとして公開されたばかりのメッセージングシステム「Pulsar」が生まれました。長年親しんだ六本木から移転したばかりのYahoo! JAPAN新オフィスで、同社のプラットフォーム開発エンジニアの考え方や働き方を、はてなエンジニアとの座談会形式でお聞きしました。

座談会出席者は、ヤフー株式会社 システム統括本部 プラットフォーム開発本部の北條正和さん、坂本雅宏さん、栗原望さん（上写真、中央より右へ）、はてなの坪内佑樹（システムプラットフォーム部 Webオペレーションエンジニア）と脇坂朝人（Mackerelチーム Webアプリケーションエンジニア）（同じく上写真、左より）。構成はITジャーナリストの星暁雄。記事の最後にプレゼントのお知らせもあります！

（※この記事は、ヤフー株式会社の提供によるPR記事です）

──皆さんの自己紹介をお願いします。

北條　前回、（米Yahoo! Inc.発OSSである）ATS（Apache Traffic Server）の座談会にも出席しましたが、現在はチームが変わって、メッセージングシステムの開発や社内向け展開を手掛けています。

坂本　Yahoo! JAPANに入社して4年目で、社内プラットフォームエンジニアです。同じくメッセージングシステムを手がけています。

栗原　Yahoo! JAPANに入社して5年目で、2人と同様に社内プラットフォームエンジニアで、メッセージングシステムの開発をしています。

ヤフー株式会社の栗原さん、坂本さん、北條さん（左から）

坪内　はてなに入社して3年目です。Webオペレーションエンジニアをしています。Mackerelの立ち上げに参加しました。

脇坂　はてなのWebアプリケーションエンジニアで、Mackerelの開発をやっています。先日まで比較的インフラに近い運用の仕事も別プロジェクトで行っていました。

株式会社はてなの脇坂（id:astj）と坪内（id:y_uuki）（左から）

■ Yahoo! Inc.発の大規模対応メッセージングシステムPulsarとは

──今回は、2016年9月に公開されたOSS（オープンソースソフトウェア）である Pulsar （GitHub）にYahoo! JAPANから関わったエンジニアの皆さんに集まっていただいています。そもそもPulsarとは何か、というところから教えていただけますか？

北條　メッセージングシステムです。メッセージングシステムにはKafka、ActiveMQなどいくつか存在していますが、Yahoo! Inc.のニーズに合ったものが見つからず、新たに開発したのがPulsarです。

──ニーズに合ったものが見つからなかったとは？

北條　例えば、Kafkaは設計上、膨大な数のトピック（メッセージをグルーピングする単位）を扱うことが難しいんです。使う人によって規模感が異なりますが、Yahoo! Inc.はいろいろなサービスを提供しているので、メッセージングシステムを個別にセットアップしていると膨大な手間になる。トピックの数が膨大でも扱える仕組みが欲しかったんですね。

坪内　まさに多数のサービスを支える基盤技術ならではのニーズですね。実際の規模はどれくらいなんでしょうか。

北條　そうですね。どれぐらいの規模かというと、Yahoo! Inc.では現在140万トピックをPulsarでさばいています。もちろん性能としてはもっと上の数字でもいけます。

──基本的な質問ですが、メッセージングシステムはどんな使い方をするものなのでしょう？

栗原　メッセージングシステムは利用範囲が広いので、何にでも使えます。例えば、ログ収集や膨大な数のユーザーを抱えるサービスで「この品物が出品された」という通知を送る用途にも使えます（注：Yahoo! Inc.のメール、ファイナンス、スポーツなどのサービスではすでにPulsarを利用中）。

坪内　はてなのMackerel（SaaS型サーバー監視サービス）にも何らかのメッセージのサービスを入れようと考えています。例えば、エージェントから得た情報の送り先として、時系列DBにもHadoopにも送りたいといった形で経路が複数ある場合があります。そこで、いったんメッセージングシステムに放り込めばいいようにしたい。Pulsarはそういう用途ですよね。

脇坂　Pulsarは、それまで使われていたメッセージングシステムを置き換える形だったのですか？ そこにはどんな課題があったのでしょうか？

北條　以前は、Kafkaや、社内利用だけで外部にはオープンにしていないメッセージングシステムを使っていました。どういうメッセージングシステムがいいのかは、時代とともに基準も変わってきます。今はPaaSやオートスケールがあるので、昔のようにホスト名を指定して送るようなやり方が難しいんです。

──Pulsarはクラウドの時代のメッセージングシステムという性格が？

北條　まあそうです。

──Pulsarのメリットの部分をもう少し教えてください。

北條　それまでのメッセージングシステムでは、デュラビリティ（耐久性、データが失われない性質）と低レイテンシ（遅延）がトレードオフの関係にあったのですが、Pulsarでは両方実現しているところが特徴といえます。だから、どちらを重視する使い方でも対応できます。

Pulsarのアーキテクチャ

Pulsarのアーキテクチャ

Yahoo! Inc.のエンジニアによれば「特にこだわりがないなら、迷ってないでこれ（Pulsar）を使えばいいよ」と。何にでも使えるメッセージングシステムを用意したから、後はサービス開発に集中してね、という立場です。

■ OSSにするため、3人で米Yahoo! Inc.に飛んだ

──なぜOSSにしたのですか？

北條　Yahoo! Inc.で作っているメッセージングシステムを見て、Yahoo! JAPANでも使ってみようということになり、触ってみたら「いいじゃん」と好感触だったので、開発にジョインしました。

同時期に「OSSにしよう」という話が持ち上がって。我々も「OSSにしましょう」とプッシュしました。僕らはメッセージングシステムでお金儲けをしているわけではないので、基盤技術であれば、みんなで作った方が業界によりよいものを提供できる。必要なものは、共通化できる要素があるんです。

脇坂　すんなりいきましたか？

北條　いいえ。もともと使われていた社内向けメッセージングシステムには、現在はまだオープンにしていない技術も含まれていて、そこを置き換える必要がありました。ここにいる3人で、オープンにするコンポーネントの開発作業をしました。そのために米国出張したんですよ。

脇坂　プラグインのような形になっていればいいですが、密結合だと大変ですね。

北條　はい、実際に密結合だったので、まずコンポーネントを分離できる形に持っていくのを第一ステップにしました。その後、どれに置き換えようかと考え、スケジュールも決まっていたので、それに合わせる形で作りました。

脇坂　それは、Yahoo! JAPANのユースケースに合わせた形でしょうか？

北條　ではないです（笑）。OSSとして見たときに、例えばKafkaと比べてこの機能がないので追いつけるようにしよう、OSSとしての価値を高めるようにしよう、という形で開発しました。具体的には、任意の認証機構を組み入れるよう、認証部分をプラグイン化するなどの取り組みをしてきました。

──苦労はありましたか？

栗原　個人的にはメッセージングシステムに触るのは初めてで、概念やコードの理解の段階で苦しみました。Javaによる開発経験もそれほどなかったですし。さらにOSSへ向けた開発は社内でもあまり例がなく。加えて出張に行ってこい、英語でディスカッションしてこいで、てんやわんやでした（笑）。

北條　僕は6週間向こう（Yahoo! Inc.）にいました。ここにいる2人は顔合わせの意味で1週間だけ出張して、後は日本に戻って共同作業を続けました。

──日本と米国に分かれて開発したわけですが、時差の問題などはどう乗り越えたのですか？

坂本　チケット管理システムに、「今日やったこと」と「相談したいこと」を書いて、向こうに任せるとか。

栗原　シフト制みたいになっていました。

北條　最初はうまく回らなかった。どうにかしなければいけないということで、日米で業務時間が重なる部分がちょっとだけあるので、ビデオ会議をするなど、工夫しました。

脇坂　はてなでもリモートの開発やミーティングはありますが、メンバーは皆国内なので時差のある開発の話は新鮮ですね。

──OSSに取り組む上で、気持ちに変化はありましたか？

栗原　これまで社内向けの開発では社外の開発者への意識は特になかったのですが、Yahoo! JAPANでも技術を外に出していこうという流れが出てきて、その矢先にこの話があったので、違和感なく気持ちがシフトしていきました。最新のものに触れたいという気持ちがあったので、そこはうれしかったですね。

OSSに取り組めたのは、自分にとって光栄なことでした。コードが世の中に出るということで、身が引き締まるような緊張感もありました。「変なコードは書けないな」とか。社外の人とのやりとりも発生するので、それは今までになかったことでした。

脇坂　公開に至るまでクローズなチームで開発していたと思うんですが、GitHubでイシューが来てレビューする、パッチを当てるとなったとき、それをチームで見る体制はどうしていますか？

栗原　そういう（OSSとしてのプロジェクト管理に当てる）時間は週にこれぐらい取りましょうという話をしています。Pulsarを社内に広める活動もやっていて、それと並行して社外セミナーをやったり、OSSとしてのPulsarを広めていくという活動も両立させていきたいと思っています。

北條　オープンソースにしても、ユーザーやメンテナーが増えなければ「ソースを外に出しただけ」になっちゃいます。外からご指摘をいただいた部分もあるので、やった方がいいものは、そうしていきます。

坪内　OSS化ということは、汎用化の側面もあったと思いますが。

栗原　プラットフォームの部署なので、汎用化の側面は今までもありました。それが社外向けに広がったイメージです。

脇坂　これは逆説的な話ですが、OSSは汎用的なものにしないといけないので、社内事情と独立して開発しやすい面がありますね。

坪内　オープンな技術しか使えない。その分、社内専用の技術に比べると、新しく入社してきた人が知っている可能性があるということですね。

──北條さんはATSに続いてPulsarに取り組んだわけですが、ひょっとしてYahoo! JAPANではOSS要員を育てるような取り組みが？

北條　そういう思惑はあるかもしれませんね。「OSSってどういうものだっけ？」が誰も分からない状況だと難しいところがあります。ライセンスもきっちり理解していないといけないし。ATSもそうですが、社内に閉じた技術を間違えて公開しないように注意する必要もあります。

■ 「クライアントの言語はどうですか？」

坪内　クライアントライブラリはどんな言語がありますか？

栗原　今はJavaです。社内ではC++ライブラリも使っています。

坂本　それと、試験段階ですがWebSocketのプロトコルも利用できます。

脇坂　はてなのMackerelで今行っているメッセージングシステムの導入では、ScalaやGoなどからの利用を検討しています。AWS（Amazon Web Services）のKinesisもクライアントライブラリで対応するプログラミング言語は豊富です。言語はある程度あるとうれしいと思っています。

北條　私たちとしては、他の言語バインディングを増やす予定は現状ではなくて。というのは、それぞれの言語向けにクライアントを作るのが難しいんです。アプリケーション側をシンプルにしたいので。

クライアントライブラリではサーバーが落ちたときに新しいサーバーに再接続するなどエラーハンドリングの処理をしていますが、それをアプリケーション上では見せたくない。そうした挙動の部分まで含めて言語バインディングを作っていくのは手間がかかります。もちろん、OSSとして他の開発者が作ってくれるのはウェルカムです。

脇坂　社内ニーズはJavaとC++でカバーできるんですか？

北條　まあまあカバーできます。他の言語が好きな人はもちろんいますが。

坪内　WebSocketから使う場合も、エラー処理などはしてくれるんですか？

北條　してくれます。

脇坂　Yahoo! JAPANの中でも、新しくサービスを構築するのでそこにPulsarを使いましょう、という話もあれば、他のメッセージングシステムを使っていてそれをPulsarに置き換える話もあると思います。そうした移行のエピソードはありますか？

栗原　まさに移行を進めている段階です。古い技術、似た技術、それをPulsarに移行してください、と社内向けに声を掛けている途中です。正直言って、けっこう大変です。

脇坂　Pub/Subの性質上、いろいろな所からSub（受信）されてPub（配信）のメリットも出てくるわけですし。

北條　Pubする人とSubする人が同じだったら移行も楽なんですけどね。

■ ストレージ層があってメッセージを長期間蓄積──Pulsarのアーキテクチャに迫る

坪内　メッセージを扱う場合、複数のシステムをうまくつなぎたいとか、ログを解析したいとか、長期間保存したいとか、そういった高度な要求が出てくる場合があります。メッセージを送る側が、こうしたさまざまな要求にちゃんと対応するのは大変です。毎回、到達チェックをしなければいけないとか。そういう諸々の要求を、Pub/Sub型メッセージングシステムに投げ込めばやってくれるのは、助かります。

北條　それがメッセージングシステムの役割の一つです。メッセージを送りたいとき、送り先が落ちているかもしれない。でも、いちいち待っていられない。メッセージングシステムを使うことで、送る側の処理の負担を軽くできます。

別のユースケースとして、受け取る側がいったんメッセージを受け取ったんだけど、「もう一回流してくれない？」と要求する例があります。例えばメッセージを受け取って処理するときにバグがあったとか。1日前にさかのぼって処理したい場合、元の送り主に依頼しても、もう残っていない。Pulsarの場合、設定可能なある一定期間のメッセージを蓄えてくれます。

脇坂　基本的な特性として、対応するSub（受信側）からACK（確認応答）を受け取ると、Pub（配信側）はいらないから捨ててしまう動作になると思うんですけど、再送とは違う次元で、後から送るメッセージをストレージに持っている形でしょうか。

北條　そうです。再送と、後からメッセージを送る部分は別のレイヤです。ACKのカーソル管理はしています。ACKが返ってこなかったら再送する、という処理は当然やっています。メッセージを受け取る人が複数いる場合、みんなが一緒とは限りません。受け取ると、昔のところから読み直さないといけない。

坪内　Pulsarのアーキテクチャについてですが、readとwriteで読むディスクが異なるようにできるということですが、デュラビリティとレイテンシの両立の工夫と関係があるのでしょうか？

栗原　例えばKafkaだとストレージの層はありませんが、Pulsarでは新たに設けていて、仲介するBrokerと呼ぶコンポーネントと、メッセージをためておくBookKeeperというコンポーネントを分けています。この部分が、PulsarとKafkaのアーキテクチャを比較したときに顕著に違う部分です。BookKeeperは別のオープンソースソフトウェアで、分散のログシステムというか。

Apache BookKeeper

そこで、readとwriteのディスクを物理的に分けて速くすることが、Pulsarの性能に寄与しているとは思います。

坪内　BookKeeperって、ライトアヘッドログ（Write Ahead Log、ログ先行書き込み）というか、レプリケーションログみたいな感じですよね。書く側はそっちに書いて、読む側はその先で読めばいい、みたいな感じですか？

栗原　ライトアヘッドのジャーナリングの部分、トランザクションを書く部分だけディスクが別に分かれているみたいな。そこだけSSDみたいな速めのものを用意しておくと。そっちは完全に他のreadの処理と切り離すことができるので、特に読み込みがだーっとたくさん発生したときにも書き込みはすいすいできます。それでうまくレイテンシを抑えることを達成していると。

北條　もっと厳密な話をすれば、キューがスムーズに流れているときはBrokerのオンメモリ（にあるデータ）だけで済んじゃっているんですよ。永続性を実現するためにストレージに書き込んではいますけど、それはジャーナリングログに書いているだけで、裏側では非同期にフラッシュ（ディスクへの書き込み）されている。なので、そこは書き込み性能に影響しません。読み込むとき、メモリになければ（ストレージから）読んでくるわけですけど、書き込む部分と読み込む部分は分かれているので、どれだけ書き込まれ続けても読むのは独立にできる。

坪内　なるほど。Cassandraなどで採用されているLSM-treeなんかもそれに近い作りですよね。ただし、書き込むディスクと読み込むディスクを分ける機構はPulsar独自のものかもしれません。アーキテクチャが面白いという切り口で興味を持つ人もいるかもと思いました。

脇坂　我々は、時系列DBのキューなどを使うとき「このコンポーネントはオンメモリにデータを持っているから、落ちると（データを）ロストする」といったヤバいものに印をつけているんですけど、PulsarのBrokerはオンメモリでデータを持つわけですね。Pulsarではクラスタの一部がクラッシュしてBrokerのメモリの中身が飛んだ場合、ストレージからデータを持ってきて何とかなる作りなんですか？

北條　そうです。

坪内　そのためのライトアヘッドログですよね。

──本日はどうもありがとうございました。

座談会は、さまざまなミーティングスペースがあるワンフロアの一角のオープンな円卓で行った。窓からは永田町や赤坂一帯が一望できる。

世の中にも貢献したいプラットフォームエンジニア募集

Yahoo! JAPANの大規模インフラを新しいテクノロジーで進化させるプラットフォームエンジニアを募集しています。

中途採用情報 - 採用情報 - ヤフー株式会社

社外の人でも利用できる「コワーキングスペース」に併設されたカウンターキッチン「LODGE Kitchen（ロッジ・キッチン）」。調理器具から調味料まで備え、イベントなどで実際に食事を提供できる。

■ Dellの28型4Kディスプレイ「S2817Q」を1名様にプレゼント！

記事をお読みの方の中から抽選で1名様に、Dellの28型4Kディスプレイ「S2817Q」をプレゼントいたします。応募方法は、下記の応募要項をご覧ください。

＜プレゼント応募要項＞
応募期間
2016年12月12日（月）から2016年12月25日（日）24時まで
賞品と当選人数
Dell ディスプレイ モニター S2817Qを1名様
応募方法
Twitter連携した上で、この記事をはてなブックマークに追加してください
※プライベートモードでのご利用は対象外です
当選発表
厳正なる抽選の後、本記事で、当選者様を発表させていただきます
賞品発送
当選発表後、はてなよりメールをお送りし、送付先情報（送付先住所、受取人氏名、電話番号）をお聞きします
※プレゼントの発送は日本国内に限らせていただきます

※当キャンペーンはDellの提供・協賛によるものではありません。

■ 2017年1月5日追記：プレゼント当選者発表！

厳正な抽選の結果、当選された方を発表します。おめでとうございます！

Dell ディスプレイ モニター S2817Q ×1名様

当選者の方には、のちほど送付先情報を確認するメールをお送りいたします。

  • ※期日までにご返信をいただけなかった場合は、再度抽選を実施し、繰り上げ当選者へ当選権をお渡しします。
  • ※繰り上げ当選が発生した場合、発表は、はてなからの当選連絡をもって代えさせていただきます。ご了承ください。

[PR]企画・制作：はてな
取材・構成：星 暁雄
写真：小高 雅也

文: 星暁雄