モバイルプッシュ用トークン保存のAWSパターンを考えてみる #アドカレ2015

どうも、ひめのです。 AWSモバイルアドベントカレンダー2015 18日目です。

私からは、プッシュ用トークンを保存する際のAWS側の構成について紹介します。

プッシュ用トークンとは

あらためて説明する必要もないかとは思いますが、モバイルアプリにプッシュ通知を行う場合には モバイルアプリを特定するためのトークンが必要になります。

iOSであれば、APNsから取得する、デバイストークン Androidであれば、GCMのプッシュトークンになります。 以下トークンと呼びます

このトークンは、常に同じ値になることが保証されているわけではないため アプリの起動時などに常に最新のトークンを取得し続けることが必要です。

たくさんのユーザを抱えているアプリの場合、起動時に必ずトークンを保存することが必要となり 負荷がかかることが想定されます。

そんなトークンの登録についてパターンを考えてみます。

Amazon DynamoDB を利用する

みなさんご存知の通り、Amazon DynamoDBは高速、安定したパフォーマンス、高いスケーラビリティを備えた完全マネージド型のクラウド NoSQL データベースサービスです。

• AWS再入門 Amazon DynamoDB 編

これを利用することで、負荷に耐えられる設計とする方法です。 ただし、DynamoDBの書き込みスループットは金額により異なりますし その前にあるEC2も相当数準備することになります。

SQSを利用する

次に、DynamoDBの書き込みスループットを押さえて対応する方法です。 プッシュ用トークンは即時反映など必ずしも必要であるものではないので 一度SQSをかませることで、DynamoDBへの書き込みを一定にする方法です。

• AWSでジョブWorkerを構成するベストプラクティス 〜 SQSの巻

AWS Mobile SDKを利用する

最後はモバイルから直接DynamoDBへ書き込みを行う方法です。 上記に上げたようなDynamoDBのフロントがボトルネックになることを防ぐことが出来ます。

ただし、iOS、Androidそれぞれ実装が必要になるため、各アプリ側で責任をもつ必要があります。

まとめ

他にもkinesis firehoseを利用するなど、方法はいろいろあるとは思いますが、クラスメソッドで直近検討をしていた方法を記載してみました。 もちろんどれが正しいということはありませんので、誰かの（社内で残しておきたかったのでw）参考になれば幸いです。