はじめに

初めまして、サーバーサイドエンジニアの徳丸です。

弊社では、20年以上昔に設計されたJavaによるモノリスなコードから、Go言語を使用しメンテナンス性の高いマイクロサービス群へと置き換えを行っています。

このプロジェクトの１つとして、プッシュ通知の配信機能をモノリスからマイクロサービスへ移行しました。結果として、約１億通/月※の大量配信を実現可能な配信基盤を構築できましたので、その際に実施したことを紹介したいと思います。

※弊社内で実施した負荷試験と実運用での成果を元に算出した理論値です

モノリス時代の課題

主に以下のような課題がありました。

大量配信などで負荷が高くなった際に、プッシュ配信とは関係のない機能の処理スピード低下やOOM（Out Of Memory）のリスクがあった
お客様の使用状況に応じたパフォーマンスチューニングが大変（配信頻度/タイミングなど）

AIMSTARは、お客様から連携された大量データを分析することがコアな部分ですので、その周辺機能である配信が原因でアプリケーション全体のパフォーマンスや可用性に悪影響が生じることは避けたいです。

また、お客様に導入いただく際に実施していた配信頻度などのチューニングも、AIMSTARを利用する趣旨から外れる作業であるため無くしたい、といった課題がありました。

マイクロサービスの構成

最終的には上図のような構成になりました。各要素の役割は以下の通りです。

Webプロセス

AIMSTARの配信シナリオから、配信対象者リストや配信開始日時などの配信予約情報を受けるプロセスです。

Producerプロセス

定期的に配信予約の状況をチェックし、配信開始時間を迎えた配信予約情報を配信予約キューに連携するプロセスです。

配信状況や連携先の配信サービスの特性に応じて、配信予約キューに連携する配信予約情報の流量のコントロールもします。

また、重複配信（配信対象者に対して同じメッセージを重複して送信してしまうこと）を排除するためのケアもこのプロセスで行います。

配信予約キュー

配信予約情報を保持するキューです。SQS（Simple Queue Service）というAWSのサービスを利用しています。

配信予約キューに配信予約情報が追加されたことをトリガーにLambdaが起動し、配信を実行するConsumerプロセスを起動します。

Consumerプロセス

配信処理を実行するプロセスです。FargateというAWSのサービスを利用していて、配信予約キューに配信予約情報が追加されたことをトリガに、Lambdaがそれに対応する１つのFargateタスクを起動する仕組みにしています。

可用性の観点から、敢えて配信処理を１つのスレッドで実行するようにしています（マルチスレッドを許容するとOOMのリスクが高まるため）。そのため、並列実行数 = 起動中のFargateタスク数となります。並列実行数の調整は、Producerプロセスが一度のタイミングで配信予約キューに追加できる配信予約情報の数の上限を変更することで行います。