この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。
リモートPush通知は、外部から情報を通知(Push)することで、起動していないアプリを強制的に起動させる唯一の手段です。 アプリケーションの実装に捕らわれがちですが、実はとても大事なサーバサイドのPush通知機能について説明します。
Push通知とは？
今さら説明する必要はないとは思います。ユーザ通知はアプリケーションが起動（フォアグラウンド）でない状態でもアプリケーションやWebサイトに情報をおくることができる唯一の手段です。
SNSのメッセージ、ECショップからのセールのお知らせ、鉄道会社の運行情報通知など様々な分野で応用されています。
Push通知は、見た目上、数行の文章と絵文字しか送ることができません。地味で単純な機能なため簡単なのだろう、と思われる方もおおいと思います。しかし、いざ実装してみると機能の面はもちろん、パフォーマンス、セキュリティなど考慮することが多々あります。
Push通知を構成する要素は、おもに、クライアント（アプリやブラウザ）、OSやブラウザ提供の配信サーバ(APNsやFCM)、そして、その中間に位置するアプリサーバから構成されます。アプリサーバはProvider サーバとも呼ばれます。
本記事はアプリサーバの役割について解説します。
アプリサーバの主な機能
- クライアントから通知された宛先の管理
- クライアントの属性による宛先の絞り込み
- Push通知の作成
- Push通知の配信
- 開封イベントなど行動分析の管理
宛先の管理
スマホアプリやブラウザからPush通知を使います！と宣言すると、OSやブラウザはPush通知の宛先を取得します。電子メールにおけるメールアドレスと似た機能ですが、これらの宛先は、スマホアプリごとやブラウザのWebサイト(ドメイン＋パス)ごとに一意に割り当てられます。複数のスマホで同じアカウントを使い回していたとしても、別々の宛先が割り当てられる点が、メールアドレスと異なります。
これらの宛先は、iOSではデバイストークン、AndroidではレジストレーションID、WebPush(PushAPI)ではendpointと呼ばれています。
Push通知の配信時はこの宛先を指定して送信します。
クライアントに通知を配信するためには、宛先を外部のサーバで管理する必要があります。
通常、WebAPIを用いてアプリサーバ上のDBやファイルに保存しておくのが一般的です。
そのため、管理するだけでも
・データベース
・WebAPIのプログラム
・Webサーバ（SSL対応）
が必要になります。
なお、宛先は配信サーバの都合で変わることもありますので、クライアントごとに一意の識別子を割り当て、その識別子と宛先を対応づけて管理します。
属性による宛先の絞りこみ
登録しているクライアント全員に送りたい場合は、宛先を管理するだけで問題ありませんが、
まったく関心のない情報をクライアントに送ってもクライアントの利用者は迷惑です。
さらに、邪魔だと思って通知をOFFにされてしまう場合もあるでしょう。
効果的なPush通知には、特定のクライアントに送るための宛先絞り込みが必要です。
宛先絞り込みの機能もアプリサーバが行う役割の一つです。
宛先絞り込みの機能を実現するためには、利用者のユーザIDや性別などの属性情報を宛先とマッピングさせておく必要があります。
通常、クライアントから識別子や宛先とともに属性情報を付与してWebAPIを経由してアプリサーバに送ります。
アプリサーバは、クライアントから送られてきた識別子・宛先と属性情報の関連を保持しておきます。
様々な検索条件に対応するために、複雑なプログラムの実装が必要になることがあります。
また、クライアント数は利用状況によっては数十〜数千万に達することもあり、宛先の絞り込みの処理のパフォーマンスが求められます。最適なデータベースの選定やチューニングが必要となります。
なお、外部CRMを利用している場合は、ユーザIDなどを属性としてもたせ、外部のCRMなどで検索した結果を渡すことも可能です。
複雑な絞り込みの実装をCRMにまかせることはできますが、その場合は、CRMとの連携部分の実装が必要となります。
Push通知の作成
Push通知の宛先や本文、オプションなどを指定して作成します。
実際に配信するときはもちろん、あらかじめ文言を用意しておき日時を指定して後で送ったり、定期的に送るという要望も多いかと思います。
その際は、作成したPush通知をデータベースに保持しておく必要があります。この管理もアプリサーバで行います。
文章はもちろん、絵文字も入力可能のため、Webブラウザ上で作成できるようにしておくと便利です。
次回へ続く
