「はいチーズ！フォト」における通知基盤のサーバレスアーキテクチャ

千株式会社は「みんな、笑顔になぁれ」をスローガンに掲げ、保育業界の課題をITで解決し子どもたちの心と身体を強く育むことを目指す会社です。弊社は複数のサービスを運営していますが、今回はその中でも幼保業界を中心とした写真販売サービスである「はいチーズ！フォト」における通知基盤について説明します。

サーバレスのインフラアーキテクチャについて

「はいチーズ！フォト」の成長に伴い、EC2上で動いている従来のメール通知バッチが抱えていたリアルタイム処理におけるスケーラビリティの限界が顕在化していました。
特に、ユーザー数の増加に比例して通知の抽出から送信までの時間が増大し、パフォーマンスのボトルネックとなっていた点は大きな課題でした。このパフォーマンス問題は、ユーザーへのタイムリーな情報提供を阻害し、サービス体験の低下に直結するリスクがあったため、将来的な通知チャネルの多様化にも対応するべく、通知プロセスのアーキテクチャを全面的にリプレイスしました。

本アーキテクチャにおいては抽出と送信プロセスの完全な分離をすることで各プロセスが独立してスケール可能となり、システム全体の柔軟性と耐障害性が向上しました。
具体的には、以下のアーキテクチャを採用しています。

1. 抽出基盤

   • 通知対象ユーザーのデータ抽出後、その結果をParquetファイルとしてS3に集約する設計としました。Parquetの採用は、カラムナ構造と圧縮効率の高さから、大量データI/Oにおけるパフォーマンス向上を期待してのものです。
   • これにより、後続の送信基盤はデータソースへの直接的な依存なく、S3から高速かつ効率的にデータを読み込むことが可能となっています。

2. 送信基盤

   • S3に格納されたParquetファイルを起点として、各通知チャネルに最適化された送信タスクを並列実行します。
   • LINEの通知側はStepFunctions(Lambda)、ブラウザのPush通知側はECSでそれぞれ送信のタスクを実行することで高速で大量の通知の配信を実現しています。
   • Lambdaはzipではなくコンテナイメージでデプロイする方式を採用しているので、パフォーマンス次第で迅速にECS環境に移行することができるようにしています。

今後の展望や取り組み予定について

現状、LINE通知はAWS Step FunctionsとAWS Lambdaを組み合わせて実装されているため、今後もユーザーが増加し続けると、Lambdaの実行時間上限（15分）に到達するリスクが高まります。
この課題に対処するために、以下のいずれかの方法での改善を計画しています。

1. 対象分割によるLambda実行の最適化

   • 既存のLambdaベースの実装を活かしつつ、通知対象ユーザーをより細かく分割し、それぞれのLambda関数で並行処理することで、個々のLambdaの実行時間を上限内に収めるアプローチです。

2. ECSへの移行

   • ブラウザのPush通知と同様に、Amazon ECS上でLINE通知処理を実行するアプローチです。
   • Lambdaの実行時間制限から解放され、より長時間の処理や、よりリソースを必要とする処理に対応可能となります。

また、新規の通知チャネルへの対応を優先してきたため、現在EC2上で稼働しているメール通知バッチの新しい通知基盤への移行が完了していません。このメール通知バッチも、将来的なスケーラビリティと運用効率の観点から、新たな通知基盤のアーキテクチャに統合することが不可欠なため、今後移行を進めていく予定です。

◆執筆：千株式会社　ものづくり部　高倉 輝