はじめに
マーケティングテクノロジー部の濱田翔馬です。
普段はアドサーバーやお知らせ通知機能などCRM系ツールの開発運用を行いつつ、テックリードとして部全体の技術支援をしています。
今回は「お知らせ通知機能」の配信基盤刷新が完了したことにともなって、運用負担改善・パフォーマンス改善をしたため対応内容をご紹介します。
リプレース事例として参考になれば幸いです。
お知らせ通知機能とは？
お知らせ通知機能とは、DMMページのヘッダー部分に存在する「ベルマーク機能」と「お知らせ通知ページ」をセットにしたサービスです。主に下記の機能を提供しています。
- ベルマーク機能：現在の未読通知件数を表示する機能（お知らせ通知ページへの遷移導線でもあります）
- お知らせ通知ページ：開催されているDMM各種キャンペーンを掲載するページ
DMM全体で開催されているキャンペーン情報を掲載するサービスとなっています。
私たちのチームでは、お知らせ通知の配信と通知入稿を行うシステムを開発しています。
旧お知らせ通知機能のアーキテクチャ
今回紹介するお知らせ通知機能のアーキテクチャは下記画像の構成となっています。
なお、現時点（2024年12月現在）ではお知らせ通知ページのデザイン刷新が完了しているため、本記事ではこれから旧お知らせ通知機能と呼称させていただきます。
デザイン刷新プロジェクトの詳細についてはこちらのInside記事をご覧ください。
旧お知らせ通知機能は、下記3つの基盤がAWS上にフルマネージドな構成で構築されています。
- お知らせ通知API（+ お知らせ通知ページ）
- お知らせ通知を配信するシステム。お知らせ通知ページで利用
- お知らせ通知管理API（+ 入稿管理ページ）
- 入稿担当者が利用する通知管理システム
- あなた宛通知作成バッチ
- 「あなた宛のお知らせ」通知を作成するシステム
配信基盤を刷新することになった背景について
旧お知らせ通知機能には、「あなた宛のお知らせ」と「運営からのお知らせ」の2種類のキャンペーンカテゴリが存在しました。前者はユーザーごとに異なるキャンペーンを、後者は全ユーザー向けのキャンペーンを配信するものです。
基盤刷新に至った背景は「あなた宛のお知らせ」の入稿フローにあります。
「あなた宛のお知らせ」は下記のステップで入稿する必要がありました。
- 通知内容が記載されたCSVファイル（100MB〜）をS3にアップロードする。
- Step Functionsを起動し、あなた宛通知作成バッチ（ECS Fargate）を実行する。
- バッチ処理のなかでCSVファイルのバリデーション&データ変換をしてRDSに登録する。
一度の入稿で10万件以上の通知を作成しているため、入稿が完了するまでに2〜4時間かかります。
また、繁忙期などトータルで3億件近い通知が入稿される場合もあり、RDSに登録した通知を定期的に削除していく必要もあります。大量のレコードを無停止で削除していくことになるため、開発者側もかなりの工数を割いて対応している状況でした。
近年、上記の運用負担がさらに増えたことを背景に、この度、運用フローの見直しと既存システムの抜本的な改善に取り掛かりました。最終的にはユーザー体験改善（お知らせ通知ページのデザイン刷新など）に繋げられるような仕組みであることも重視しました。
リアーキテクチャ後のシステム構成について
リアーキテクチャ後のシステム構成は下記の通りです。
マーケティングテクノロジー部では、近年様々な保有プロダクトをGoogle Cloudに移行する機会が増えてきました。そういった部内の動きもあり、Google Cloudで新規構築していくことを決定しています。後述しますが、BigQueryとの連携のしやすさも採用する決め手の一つでした。
採用した主なサービスは下記の通りです：
- Cloud Run
- Cloud Bigtable
- BigQuery
- Memorystore for Redis
- Cloud SQL
すべてのサービスを紹介していくには紙面が足りないため、いくつかピックアップして紹介させていただきます。
Cloud Run
ECS Fargateの移行先としてCloud Runを採用しました。これはもともと保有プロダクトで採用実績があった点や開発体験の良さなどが採用の後押しとなりました。
事前にパフォーマンスを計測し、高トラフィックな環境でも十分要件を満たすことが分かり採用に踏み切ることができました。
Cloud Bigtable
Cloud Bigtableは、Googleが保有するNoSQLデータベースです。AWSでは同種のサービスとしてDynamoDBが存在します。 数PBもの大容量データに対して低レイテンシー（公式では5ms）で処理できる点が魅力的です。
新基盤では大容量の配信データや時系列データを高速に処理していく必要があったため採用しています。 現在、500万件ちかいデータのread/writeに対しても十分なパフォーマンスを発揮しており、あらためて採用して良かったと思える素晴らしいサービスでした。
BigQuery
後述するセグメント取り込み基盤の構築で採用しました。
新基盤では、社内に蓄積された数TBの大容量データからセグメントを作成していく必要があります。BigQueryはJob単位で高負荷なワークロードを並列実行できるため、私たちのプロダクトと非常に相性が良かったです。
分析はもちろんのことオフラインバッチ処理においても活用の幅は広く、今後の機能拡張に対して様々な手段を提供してくれる点が魅力的なサービスでした。
改善した点について
リアーキテクチャによって様々な点を改善できました。そのうちのいくつかを紹介させていただきます。
入稿担当者のみで配信設定が完結
旧お知らせ通知機能では、入稿設定にミスがあった場合、開発者側で修正する必要がありました。 これは、「あなた宛のお知らせ」通知がユーザー単位で通知を作成するため、データの一括修正には複雑なマイグレーションを必要としたためです。
私たちは、セグメント配信方式を採用することでこの課題の解決を目指しました。
セグメント配信方式とは、ユーザーを特定の条件（セグメント）で絞り込み、対象ユーザーに対してのみ配信する方式を指します。 この配信方式によって対象ユーザー（誰に）と通知データ（何を）を完全に分離できるため、通知データの入稿ミスを修正しやすくなります。
上記の改善によって、入稿担当者は開発者に頼らずとも通知データの修正を自由に行えるようになりました。 結果的に開発者側の運用負担を低減させることにもつながり、運用者・開発者両者にとって効果の高い改善となりました。
入稿設定の簡略化
旧来の「あなた宛のお知らせ」通知では、大量の通知を一度の入稿で登録していく必要がありました。 入稿用のCSVファイルは時に1GBを超え、アップロード・バリデーション・登録までに2〜4時間を要するほどです。
今回構築したセグメント取り込み基盤では、数KBのセグメントファイルと取り込みスケジュールの設定で入稿が完了します。 この基盤によって全体的な入稿（通知配信が可能になるまでの設定）は10〜15分で完了するようになり、劇的な時間短縮を実現しました。
セグメント取り込みの流れは下記の通りです：
- 入稿担当者はセグメントファイルのアップロードと取り込みスケジュールを設定します。
- セグメント取り込み基盤は取り込みスケジュールを検知し、社内DWH（BigQuery）からセグメントを自動的に取得します。
- 取得したセグメントを配信可能なデータに変換し、Cloud Bigtableに登録していきます。
- 新お知らせ通知APIでは、Cloud Bigtableからセグメント情報を取得し、対象の配信情報をユーザーに返却します。
低レイテンシーな配信の実現
旧来のお知らせ通知APIはキャッシュレイヤーを保持しておらず、ユーザーのリクエストごとにRDBへ問い合わせしていました。 新基盤では多層キャッシュを保持する構成にし、低レイテンシーな配信を実現しています。
下記グラフは直近1週間の99.9%ileレイテンシーの推移を示しています。グラフのとおり15ms〜45msの低レイテンシーを維持できるようになりました。
現状、新基盤の月平均レイテンシーは28msとなっており、従来の平均レイテンシー200msと比較しておよそ1/7まで速度改善したと言えます。
私たちのチームでは長らくアドサーバーの開発をおこなっていたこともあり、レイテンシーはかなりシビアに捉えていました。チームの努力が実際の数値として現れていることを非常に喜ばしく思います。
実際に行ったレイテンシー改善の詳細はこちらの記事をご覧ください。
今後も引き続き速度改善を実施していき、低レイテンシーの維持に努めていきたいと考えています。
まとめ
リアーキテクチャによって抜本的な運用負担改善とパフォーマンス改善ができました。私たちのプロダクトを利用いただいている様々なユーザーさんに、より良いプロダクト提供ができ非常に嬉しく思います。
現在私たちのチームでは、保有しているCRMツール（アドサーバーやお知らせ通知機能など）を統合する一元管理プロダクトの開発が進行しています。今回構築した新基盤は、その基礎基盤として活用できるように設計しました。
これからも一層プロダクト開発に取り組んでいき、より良いプロダクトに磨き上げていきます！
最後に求人情報の紹介です。マーケティングテクノロジー部では共に働く仲間を募集しています。 ご興味ある方は、募集ページをご確認ください！
