見出し画像

AmazonSNSでPush通知する環境の構成について

NAVITIME_Tech

はじめに

こんにちは、バネ屋です。
ナビタイムジャパンで『トラックカーナビ』をメインにiOS/Androidの開発を行なっています。
『トラックカーナビ』に関してはこちらの記事もご覧ください。

今回は当社で一部のプロダクトが使用しているAmazon SNS(Simple Notification Service)を利用したPush通知の配信構成についてお話しさせていただきます。

なんでAmazon SNS?

以前はトークンファイルを手動で配信用サーバーに配置し、Jenkinsを用いて直接FCM(Firebase Cloud Messaging)やAPNs(Apple Push Notification service)を叩いてPush通知を送信するというような運用をしていました。
しかし、各種サービスのリソースをAWSに移行していくという全社的な動きがあり、配信に必要なトークンの管理等もAWSに移行していくとなっていたため、それであれば配信しやすいようにAWS内で完結してしまおうということでAmazon SNSを使用することになりました。

また、Amazon SNSの利用料金は最初の100万件までは無料でその後は0.50USD/100万件なので、費用を抑えて配信環境を整備できるのも理由の一つです。

構成について

AWS移行過渡期と移行後で構成を多少変更しています。過渡期はトークンを別で準備し、移行後はAmazon Athenaでトークンを準備するようになっています。
過渡期の構成については移行後に同じ構成でできることを意識して構成したため、配信部分のコードなどはほぼそのままにできています。

構成その1：トークンを別で準備

構成その2：トークンをAmazon Athenaで準備

構成理由

トークンの用意と配信を分けている理由に関してはヒューマンエラーの防止のためになります。いくらシステムを準備したとしても最終的には人が操作するため、誤操作による誤配信の可能性があり得ます。
そのため、トークン配置時に件数に間違いがないかを確認できるように配置後即配信しないようにしています。

また、配信に関してはAmazon SQS(Simple Queue Service)を間に挟んでいますが、これは配信速度を上げるために行なっています。
トークンとPushの内容をキューイングして配信処理を同時実行させることで配信速度を上げるようにしています。

構成と少し話はそれますが、配信実行時に一定の件数の配信ごとに遅延を入れるようにしています。これはPush通知が一斉にユーザーに届いて同時に開かれた結果、アクセス集中が起きて輻輳の可能性があるので負荷軽減の目的で遅延を入れています。

各箇所での挙動

トークン配置

トークン配置用のAWS Lambdaでは手法に差はあれどAmazon S3へのトークンファイル配置処理を行なっています。
配置の際にはトークンを2万件ごとに分割してから配置しています。これはAWS Lambdaに渡せるファイルサイズの上限が6MBだったこと、Amazon SQSのキューに詰められるメッセージの上限が2万件だったことが理由になります。

配信予定作成

分割して配置されたトークンを取得してPush配信用のペイロードと共にAmazon SQSにメッセージをキューイングしていきます。

Amazon SQSはFIFOキューを用いて必ず1回のみ実行されるようにしています。これは通知が重複して送られないようにするためです。
キューイングの際はグループIDを設定して、実際の送信処理が並列実行されるようにした上でバッチ処理によりまとめてメッセージを登録することで登録処理および配信速度を早めるようにしています。

構成やトークン配置のところで少し触れましたが、メッセージの上限は2万件のため、これを超える件数を詰めようとするとエラーになり、Push配信がされません。そのため、2万件登録後にキューが捌かれるのを待ち＋輻輳防止のために2万件毎に少し時間を空けるようにしています。

配信実行

Amazon SQSからのメッセージをもとに起動され、Push配信用のペイロードとトークンをAmazon SNSに渡して配信処理を実行します。トークンはそのままでは配信できないため、このタイミングでトークンをもとにエンドポイント(Amazon SNS用の配信識別子)の登録も行なっています。

終わりに

Amazon SNSを使った配信の方法についてはたくさん記事が出てくるのですが、構成についての話が少なかったため、今回は構成に絞って書かせていただきました。
Amazon SNSそのものの利点ではありませんが、すべてAWS内で構成したことで他の機能との連携で拡張・変更しやすくなったところはこの先運用していく上でのメリットと感じています。
Push配信の環境を作成しようとする方の助けになれば幸いです。

構成や実装はまだまだ改良の余地があると思っています。実際はもっとベストな構成があるとか、もう既にそのやり方は古いといったこともあると思います。
そういった情報をご存知な方がいらっしゃいましたらコメントしていただけたらと思います。

最後まで読んでいただきありがとうございました。