運行情報配信システムの構成見直しで困ったことと解決方法
こんにちは、ツチノコです。
ナビタイムジャパンで社内APIの開発を担当しています。
当社では以前、運行情報配信システムをオンプレ環境からAWSに移行しました。本記事では、運行情報配信システムの移行にあたり困ったこと、および解決方法について記載したいと思います。
運行情報配信システムとは？
『NAVITIME』や『乗換NAVITIME』では、列車の遅延情報など、運行情報に変化があった場合に対象となるユーザーにプッシュ配信をしています。
対象ユーザーの抽出やプッシュ配信処理をしているのが運行情報配信システムです。
なぜ構成を見直したのか？
きっかけは、各種サービスが利用しているサーバーや静的ファイルなどのリソースをAWSに移行していくという全社的な動きです。
AWSに移行するにあたり、コードの煩雑さや証明書更新の手動運用など、運用にも課題があったことから、構成の見直しを実施しました。
AWS上でプッシュ配信を実現するにあたり、Amazon Simple Notification Service (SNS) を利用することで、証明書更新などの運用がしやすくなると考えました。
構成検討時に困ったこと
配信対象の管理方法
運行情報配信システムでAmazon SNSを利用するにあたり、SNSトピックを利用した配信方法を考えました。SNSトピックを利用すると、複数の受信者をグループとして管理でき、グループを対象としてメッセージを配信できます。
路線、曜日、時間帯など、配信条件ごとにSNSトピックを作成し、運行情報を配信する際には状況に合ったSNSトピックに対してメッセージを発行する、といった形を考えていました。
しかし、配信条件の組み合わせを元に作成するSNSトピックの数を試算したところ、作成できる上限を超えてしまうことが判明しました。
SNSトピックには、デフォルトでは1アカウントあたり100,000トピックの利用上限があります。
参考: よくある質問 - Amazon SNS | AWS クォータと制限
AWSのサポートに問い合わせれば制限の引き上げも可能とのことですが、膨大な数のSNSトピックを管理し切れない懸念もあったため、トピックの利用は断念しました。
検討の結果、配信プログラムで送信対象の判断をした後、エンドポイントに対して直接メッセージを配信する形にしました。
配信遅延
送信テストを実施したところ、送信対象のユーザーが多くなるにつれて、プッシュの配信遅延が発生してしまうことがわかりました。運行情報というリアルタイムに知りたい情報に関する配信遅延は致命的です。
配信遅延の原因について調査したところ、エンドポイント作成処理で時間がかかっていることが分かりました。
配信対象を抽出した後、送信対象のプッシュトークン情報を元にエンドポイントを作成していましたが、そのタイミングで処理が詰まっている状態でした。
対処方法として、エンドポイント作成処理を切り出し、定期的に非同期に実行するようにしました。
作成されたエンドポイントは Amazon Relational Database Service (RDS) 上で管理しており、プッシュトークン情報に紐づくエンドポイントが無い場合に新規作成されるようにしています。
また、他に並列で実行できる運行情報の抽出処理についても、同様に非同期で実行することで、配信遅延を発生しづらくしています。
最終的な構成
最終的には以下の構成となりました。
運行情報更新処理、SNSエンドポイント生成処理、運行情報プッシュ配信処理を別々のバッチに分けて非同期で実行することで、配信遅延を減らしています。
また、バッチ処理側で送信対象ユーザーを抽出して、エンドポイントに直接プッシュ通知を配信することで、多数のSNSトピックを管理せずに済みました。
最後までお読みいただき、ありがとうございました。