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

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

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

Pusna-RSの全体システム構成と機能概要

　以下がPusna-RSのシステム全体構成です（図4）。

図4

• インフラ：AWS
• 開発言語：Node.js v0.8系
• フレームワーク：Express 3系
• DB：Amazon DynamoDB
• 検索エンジン：Elasticsearch

　スケーラビリティの実現のためにAWS、配信スピードの向上のためにDynamoDBとNode.jsを最大限活用した作りとしています。また、実行環境の構築・管理についてはAWS Elastic Beanstalkを使用しています。各詳細は次回以降紹介していきますが、ここでは、機能概要を簡単に触れておきます。

図4【1】クライアントライブラリ

　前述した通りプッシュ通知にはデバイストークンが必要になるため、APNs・GCMから取得してPusna-RSへ送信する機能が一律必要となります。そのため、アプリ起動時にこれらの処理を行うモジュールをライブラリ化して、各アプリに提供しています。

　また、後述する条件を指定しての配信を行うために、最終ログイン日時や応募回数などアプリごとの固有情報も送信できるようにしています。

図4【2】登録機能

　クライアントライブラリから送信されたデバイス情報を受け取り、永続化を行います。

　クライアントライブラリはアプリ起動時に情報を送信してくるため、デバイス数の増加に伴いリクエスト数が増加します。そのため、最もスケーラビリティが求められる機能になります。

　永続化については後述しますが、DynamoDBとElasticsearchに格納を行っています。

図4【3】配信機能

　管理機能よりリクエストを受けて、実際の配信を行います。配信のパターンによりデバイス情報をDynamoDBまたはElasticsearchから抽出し、APNs・GCMに対して配信要求を送信します。配信パターンは以下の3種類があります。

1. デバイス指定配信
   • デバイスを指定してのプッシュ通知を行う
   • ビッグデータとの連携などで利用
2. 全件配信
   • 対象アプリの全デバイスに対してプッシュ通知を行う
   • 全ユーザーへのお知らせなどに利用
3. 条件指定配信
   • デバイスごとに保持する固有情報にて、条件を指定しての配信を行う
   • ユーザーセグメント別の配信などに利用

　上記の配信パターンのうち、デバイス指定配信・全件配信についてはDynamoDBから、条件指定配信についてはElasticsearchから抽出を行います（図5）。

図5

　配信機能の詳細については第3回記事で説明予定です。

図4【5】管理機能

　管理機能は以下の機能を保持しています。

• Pusna-RS利用ユーザーの管理
• アプリ情報の管理
• 配信要求の予約、即時実施
• 配信結果などの確認

　また、これらの機能について画面だけでなくAPIも用意しており、アプリ側のサーバーと連携しての配信も実施しています。

Pusna-RSにおけるモジュール間の接続

Amazon SQS（Simple Queue Service）

　システム構成図にも記載していますが、Pusna-RSでは全体的にモジュール間の接続にSQSを利用しています。SQSはAWSで提供される分散キューサービスで、信頼性・スケーラビリティに優れ低コストで使える特徴があります。

　例えば、登録機能ではAPI部分と永続化部分を分割してSQSでつなげています（図6）。

図6

　SQSを利用することで一つ一つの機能を単純化できるだけではなく、DynamoDB・Elasticsearchへの登録速度も一定に保つことができます。また、キューのたまり具合に応じたオートスケールも実現できるため、スケーラビリティの向上に大きな効果を出しています。

Amazon SNS

　SQSを利用することでスケーラビリティを確保していますが、さらにAmazon SNSと組み合わせることでシステムの拡張性も担保させています。

　Amazon SNSはAWSで提供されているプッシュメッセージングサービスです。Amazon SNSは複数のエンドポイントを持つことができ、一つの通知を複数のエンドポイントに送信することができます（図7）。

図7

　エンドポイントとしてSQSを持つこともできるため、Pusna-RSでは全てのSQSへのキュー登録をAmazon SNS経由で行っています。Amazon SNSは設定変更のみでエンドポイントを増やすこともできるため、拡張性を持たせることができます。

　実際にビッグデータ基盤と連携する際はこの機能を活用し、ビッグデータ基盤用のキューを作成することでアプリケーションの改修なしで連携を開始しました（図8）。

図8

Pusna-RSにおける永続化

　前述の通り、永続化はDynamoDBとElasticsearchを活用しています。DynamoDBはAWSより提供されている分散KVSです。

　高速に動作でき、スケーラビリティ・信頼性にも優れているため、Pusna-RSではマスターデータとして活用しています。しかし、DynamoDBは検索機能が弱いため、そこを補完する必要がありました。そのため、Elasticsearchを導入することにより検索機能を実現しています。

　ElasticsearchはApache Solrと同様にApache Luceneをコアにしたオープンソースの全文検索エンジンです。

次回はPusna-RSにおけるDynamoDBの使い方

　次回はPusna-RSにおけるDynamoDBの使い方について紹介する予定です。