雷のように降り注ぐ情報
── タイムラグのないプッシュ通知を目指して

2018.5.31

アプリの更新情報、おすすめ商品のお知らせなど、スマートフォンやブラウザにリアルタイムな情報を発信する「プッシュ通知サービス」。
ユーザーは最新情報をリアルタイムで受け取れ、発信側はアプリ利用頻度を高められるとして、アプリには欠かせない機能になっている。

そして今、超高速の通知で注目を集めているプッシュ通知エンジンがある。
1秒で3.5万デバイスへのプッシュ通知が可能という、かつてない速さを実現した「BoltzEngine」 （ボルツエンジン）だ。

超高速プッシュ通知 BoltzEngine

国内トップクラスの配信速度を誇り、オンプレミスにもクラウドにも対応する柔軟さが特長の BoltzEngine 。他社のプッシュ通知エンジンとは一線を画すそのスペックを手に入れるまでのストーリーに迫った。

アプリに欠かせないものになったプッシュ通知

プッシュ通知はここ数年で増えたという印象です

メッセージアプリが普及してきて情報のスピードが早くなったことで、リアルタイムな情報を得られるプッシュ通知の需要が高まったと思います。発信側としても、たくさんの情報に埋もれてしまうという問題を解決するきっかけになりました。

開発としてはいつ頃から取り組みはじめたのでしょうか

LINE が日本でサービスを開始したのが2011年で、社内で最初にプッシュ基盤を入れたのもちょうどその頃ですね。共同開発させていただいている、生放送番組のアプリへの実装からスタートしましたが、当初はなかなかうまくいきませんでした。

番組の情報や出演者情報など、生放送と連動した通知なのでタイムラグがあってはいけないんですけど、全デバイスに送りきるのに数分かかってしまって…。通知を全て送りきることができませんでした。

その当時使っていた PHP は同時に並列で動けないという弱点があって、どうしてもスピードが遅くなっていたんです。例えるなら、「高速道路で1車線しか確保できなくて渋滞してしまっている」という感じですね。

どのように弱点を解決したんですか？

とにかく、問題となっている PHP の代わりになるものを模索する日々でした。PHP が並列処理に弱いので並列が書きやすいものを探していて、その中で、チームのエンジニアが提案してくれた Go 言語なら、プッシュ通知と相性がいいのではということになりました。

当時は Ruby や C# などの選択肢があったんですが、一番書きやすそうだったのが Go 言語でした。使ってみると並列が得意というふれこみ通り本当に書きやすくて、これなら問題を解決できると思いました。

修正後のパフォーマンスはいかがでしたか

開発中に一時的なデッドロックは発生したんですが、修正後のスピードは圧倒的でした。 前のバージョンでは秒間3000しか出なかったのが、サーバー1台あたり秒間3万に。別の開発案件でプッシュ基盤を入れたときには、速度が速すぎて落とすスロットリング機能を入れたほど、当初とは比べ物にならないくらいパワーがある基盤に成長しました。

単体プロダクト立ち上げの経緯について教えてください

精度が高くなっていく中で、アプリの一部として使うだけではもったいないと思うようになりました。それで、プッシュ通知を使った企画を出してみたら評判がよくて、正式にキックオフすることになったんです。

これまで共同開発から生まれたプロダクトはあったんですか？

あるにはあったんですが、あまりいい結果にならなかったこともあり、今回のプロジェクトの立ち上げは慎重にしました。専任担当を作るのもリスキーなので、メンバーは全員が兼任で。基本的にはプロダクトオーナー、エンジニア、アートディレクターの3名で進めて、パワーをかけすぎないように気をつけました。

少人数でプロジェクトを進めることへの不安は？

兼任ということで他の案件の合間をぬってやっていくという点では、スケジュール調整などで開発がストップしてしまったり難しい面もありました。でも、限られた期間だからこそ集中して取り組めたところもあると思います。

また、チームとしては3名でしたが、デザインのオペレーションやテスト、営業や宣伝など色んな方に関わってもらっています。プロダクトの概要やコンセプトについては都度共有して、「なぜオンプレミスにこだわっているのか」など、目指していることを明確にしたうえで共有することで、同じ方向を向いて取り組んでもらえたと思います。

プロダクトとして勝負できる自信

プロダクトの立ち上げ時点である程度のパフォーマンスは完成していましたよね

そうですね。なのでエンジン本体の大きな変更はありませんでした。ただ、エンジン本体だけがあってもお客様にそのまま使ってもらうことは難しいということになって。それで、プッシュ通知の配信機能が実装された管理サイト「BoltzMessenger」（ボルツメッセンジャー）をつくりました。

インターフェースやコードなどはあえて標準的なつくりになっています。専門知識が深くない人でもマニュアルに沿って操作できるのはもちろん、それぞれの用途に合わせてカスタマイズしていただけるように。ここまでの規模のものを、そのままコード提供しているのはなかなかないと思いますよ。

立ち上げからリリースまでは順調に進みましたか？

2015年2月にプロジェクトを立ち上げて、同年5月にリリースしました。なので実質は3ヶ月くらいですかね。展示会に間に合わせるためにかなり急いで仕上げたんですけど、しばらくは泣かず飛ばすでした…。初めての導入は10月くらいに、列車の運行情報アプリで使っていただきました。

その際の導入では、構築もこちらでやらせていただいたので特に大きな問題はなかったんですが、別の案件で導入いただいた際に BoltzMessenger の速度面でパフォーマンスが落ちてしまって。ご迷惑をおかけしてしまいましたが、 Messenger の構造に大きな問題があったわけではなかったので、すぐにリカバリーすることができました。

その経験をもとに、お客様の方で実装していただく場合の問題点が分かったので、注意して見なければいけない部分が明確になりました。実際それ以降は特に大きなトラブルなく今まで来ているので、導入時に起こりうる問題は初期段階でクリアにできたと思います。

他社からも様々なプッシュエンジンがリリースされていますが、違いは何だと思いますか？

まずは何よりスピードですね。あとは、オンプレミス対応をしているところ。他のプッシュサービスでオンプレミス対応しているところはかなり少なくて、ほとんど ASP サービスなんですよ。ASP のようなクラウド型のサービスになると、組み込みのところで難しくなったりセキュリティポリシーで導入してもらえないというデメリットが出てきます。BoltzEngine はサーバー側にインストールしていただくので、導入段階でつまずかないのは大きな特長だと思います。

開発としてはASP化した方がスムーズなんでしょうか？

それはそうですね。実は、社内からは「 ASP 化しないのか？」という意見も多くあったんです。でも、ASP 化しても BoltzEngine ではその良さを活かしきれないと思いましたし、今の限られたメンバーではやりきれるパワーが足りないと感じていたので、このままオンプレミスでやりきった方がいいんじゃないかと。その結果、他社には負けないオンリーワンな部分になりました。

そうして妥協せずにやってきた中で性能面で信頼をしていただいて、防災系のアプリなどに導入いただけているのもモチベーションになっています。災害の通知など失敗できない領域で使っていただいているので、安定したパフォーマンスを発揮しつづけられるようにしたいです。

まだ先へ行ける、可能性にみちたエンジン

これまでを振り返って思うことはありますか

プッシュ通知のプロダクトは、前職のときにも企画を出したりしていたので、 BoltzEngine でやっと形にできたという達成感はあります。なにより、「超高速でオンプレミス」を目指してやってきて、その部分でお客様に選んでいただけているのが嬉しいです。自分たちがやってきたことは間違いじゃなかったなと。

プッシュ通知の今後と BoltzEngine が目指すもの

プッシュ通知自体は保証されない機能ではあるんですが、それでも情報を伝えられるチャンネルが増えるというのは、これから先も色んな可能性を持っていると思うんです。ウェブプッシュなども出てきたなかで、ユーザーによりよい形で情報を提供するサービスを考えていきたいですね。

もともと iOS と Android しか対応していなかったのが、ウェブプッシュとか Amazon の Kindle が増えてきて、これからもっと多様化していくと思います。現状で言うと、ASP サービスでウェブプッシュも Kindle も対応しているところはそんなにないと思うので、そこの部分をさらに強化してオンリーワンのサービスを提供し続けたいです。

また、プッシュ通知が分かりにくい仕組みになっていると感じる人が多いと思うので、身近に感じてもらえるような取り組みをしていきたいですし、今後も BoltzEngine という基盤を活用して、新しいプロダクトが生まれてくれることを期待しています。

プロダクトオーナー／ 伊藤 伸裕　Nobuhiro Ito

• Twitter
• facebook
• hatena_b