プッシュ通知の基礎知識＆秒間1万を超えるプッシュ通知基盤のアーキテクチャと仕組みとは：大規模プッシュ通知基盤大解剖（1）（1/2 ページ）

大規模プッシュ通知基盤について、「Pusna-RS」の実装事例を基にアーキテクチャや運用を解説する連載。初回は、プッシュ通知の概要に加え、AWSやNode.js、DynamoDB、Elasticsearch、Amazon SNS/SQS、Rendrなどで構成される全体的なアーキテクチャや仕組みについて紹介します。

[宮川典久，リクルートテクノロジーズ]

連載目次

プッシュ通知とは？ なぜ開発者はアプリにプッシュ通知機能を搭載するのか

　スマートデバイスにおける「プッシュ通知」はアプリにとって欠かせない機能の一つであり、メールマガジンと同様に重要な集客ツールです（図1）。スマートフォンをお使いの方でしたら、一度はプッシュ通知を受け取ったことがあるのではないでしょうか。

図1

　プッシュ通知はユーザーがスマートデバイスを起動していなくても通知を送ることができる仕組みであり、以下の特徴があります。

• 開くと直接アプリを起動するためアクションにつながりやすい
• アプリをインストールしているユーザーのみに届くため開封率が高い

　上記のような特徴から、プッシュ通知は以下の用途で使うことが多くなります。

• リアルタイムな情報配信
  直接アプリ起動につながるため、ニュースなどリアルタイム性の高い情報の配信に向く
• ユーザーのアクティブ率向上
  開封率が高いため、定期的にアプリを起動させるきっかけを作ることができる
• 休眠ユーザーの再起
  しばらく使っていないユーザーに対して送ることで、アクティブ化させることにつなげられる

　このような特徴と用途を持つプッシュ通知ですが、そもそも、その仕組みやインフラはどうなっているのでしょうか。

　本連載では全4回で、大規模プッシュ通知基盤の実装事例を基にアーキテクチャや運用を解説していきます。事例となるのは、リクルートテクノロジーズで開発・運用を行っている「Pusna-RS（パスナ・アールエス）」です。第1回の今回はプッシュ通知の概要とPusna-RSの全体的なアーキテクチャ構成について紹介します。

Pusna-RS

なぜプッシュ通知基盤を内製したのか

　リクルートテクノロジーズは、IT・ネットマーケティング技術の開発・提供を通してリクルートグループのサービスを支える機能会社です。リクルートテクノロジーズではテクノロジーをソリューションという単位にまとめてグループ内に提供しており、今回アーキテクチャを紹介するプッシュ通知基盤の「Pusna-RS」もその一つです。

　Pusna-RSはプッシュ通知の基盤であり、2014年1月より運用しています。プッシュ通知を行う外部サービスは複数ありますが、リクルートグループ内のビッグデータ基盤との連携や、セキュリティルールへの対応、個別の機能要件といったものを実現するために外部サービスを使わず内製するという判断をしました。今後リクルートグループ全体で使っていくこととなるため、スケーラビリティとスピードにこだわったアーキテクチャを採用しています。

　リクルートテクノロジーズではPusna-RSの前もPusnaというプッシュ通知基盤でプッシュ通知の運用を行っていました。しかし、アプリの重要性が増していくことに伴い急激なアプリ数・デバイス数の増加があり、配信スピードやスケーラビリティの問題が出てきました。

　Pusnaでは秒間数百程度の配信しか行えなかったため、数百万デバイス以上を持っているようなアプリの配信を指定時間内で送り切ることができず、日を分割して配信せざるを得ない状況でした。また、前述のようなアクティブ率向上や休眠ユーザー再起といった新たなニーズが増えてきたこともあり再構築に至りました。下記は再構築の目的です。

• デバイス数増加への対応
  • 急激なデバイス数増加に耐えられるスケーラビリティの実現
  • 「リアルタイムな情報配信」を行える配信スピードの実現
• 新たなニーズへの対応
  • 「ユーザーのアクティブ率向上」「休眠ユーザーの再起」の施策を行うためのビッグデータの活用

　特に、配信スピードは可能な限りのチューニングを行っており、秒間1万を超える高速配信を実現しています。

　Pusna-RSのアーキテクチャに入る前に、まずは基本的なプッシュ通知を行うために、どのような実装が必要かを説明します。

基本的なプッシュ通知の実装方法

　プッシュ通知はiOSデバイスに対してはアップルの「APNs（Apple Push Notification Service）」、Androidデバイスに対してはグーグルの「GCM（Google Cloud Messaging）」を利用して実現します。

　細かな違いはあるもののAPNs・GCM共に基本的な考え方は同じで、プッシュ通知を実現するためには以下の2つの機能を保つ必要があります。

• デバイス情報の登録機能
• プッシュ通知の配信機能

デバイス情報の登録機能

　プッシュ通知はAPNs・GCMに対して「対象アプリ」と「対象デバイス」を指定してメッセージを送る必要があります。「アプリ」についてはAPNs・GCMからアプリごとに認証キーが発行されるため、それを保持しておけばよいのですが、問題は「デバイス」です。

　デバイスを指定するためにはデバイストークン（GCMの場合は登録IDに当たりますがデバイストークンに用語を統一）という情報を必要とします。デバイストークンはデバイス内でアプリからAPNs・GCMに通信をしないと取得できません。

　プッシュ通知を行うためにはデバイス情報を自分たちで管理する必要があるため、アプリ内でデバイストークンを取得した後に自分たちのサーバーに送信して格納しておく必要があります（図2）。

図2

　また、デバイストークンはAPNs・GCM側で定期的にリフレッシュされてしまいます。そのため、確実にプッシュ通知を行うためにはアプリ起動時に毎回デバイストークンをサーバーに送信し、常に最新化を行っていく必要があります。

プッシュ通知の配信機能

　プッシュ通知を配信するには、APNs・GCMに対して基本的には「認証キー」「デバイストークン」「メッセージ」を送る必要があります。これによりデバイストークンとひも付いた実端末に配信が行われます（図3）。

図3