Copyright ⓒ 2025 Nikkei Inc. All rights reserved. リアルタイム行動ログを付加価値に繋げる、 ファンアウトの試行錯誤 日本経済新聞社 プラットフォーム推進室 データインテリジェンスグループ 佐野 玄 1


Copyright ⓒ 2025 Nikkei Inc. All rights reserved. Copyright ⓒ 2025 Nikkei Inc. All rights reserved. 2
 自己紹介 佐野 玄 プラットフォーム推進室 データインテリジェンスグループ (DIG) 部長 兼 CDIO室 エンジニアリングマネージャー - 2020年 (再)入社 - 2016〜2019 マーケティングテクノロジスト - 2020〜 ストラテジスト→部長 - 95% ピープルマネージャー - 5% デベロッパー - キャリアの軸は マーケティング ✖ データ - マーケSaaSのカスタマーサクセスマネージャー - データSaaSのソリューションアーキテクト - 広告代理店でのコンサルタント - Atlas, Ingestly… - 最近、カメラ趣味の延長で登山を始めました

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. Copyright ⓒ 2025 Nikkei Inc. All rights reserved. 3
 今日お話しするのは… 集めたログから「もっと価値を創る」ために、ログの「供給先」を増やしました。 どんな用途にどんな方法をとったのか、どう考えどう実装したかを紹介します。 より良い方法があるよ、とお気付きの方からの助言をいただけると嬉しいです！

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. チャレンジ 4 インプリ アイディア チャレンジ まとめ インプリ アイディア まとめ

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. リアルタイムアナリティクス & CDP 作りました 5
 チャレンジ インプリ アイディア チャレンジ まとめ インプリ アイディア まとめ Fastly AWS Kinesis SQS Enrichment Endpoint Metadata Android iOS JS Google Cloud BigQuery PubSub Consumer Elasticsearch Consumer 日経の数十あるWebサービスやネイティブアプリのフロントエンド＆バックエンドでアクセス状況を計測します。 大容量データも軽々処理できるBigQueryと、スキーマレスでログの柔軟性を高められるElasticsearch、インメモリーで超高 速なSingleStoreを組み合わせて、一千人を超えるデータ利用者に分析・可視化を提供しています。 SingleStore Consumer （ログの処理部分だけ切り取り） BI&CDPは この後ろ

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. 色々なことが分かります 6
 チャレンジ インプリ アイディア チャレンジ まとめ インプリ アイディア まとめ ページビュー スクロール深度 クリック フォーム操作 記事本文の可視性 読了 動画・音声の再生 視聴時間 画面描画速度 (RUM） サービスの使われ方・記事の読まれ方など、パッシブな情報が「反応・反響」として お客様からフィードバックを得る貴重な経路になっています。（メディアサービスの特性）

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. もっとお客様にデータから価値を届けたい 分析と可視化だけでは十分ではありません。 せっかく頂いたデータですから、もっと直接データを提供価値に繋げたい！ 7
 チャレンジ インプリ アイディア チャレンジ まとめ インプリ アイディア まとめ 計測 処理 分析 可視化 パーソナライズ プロモーション ✓ 示唆を得て次の施策に繋げることはできてきた データを活かした機能をプロダクトに組み込みたい 閲読履歴機能、レコメンデーション、通知など もっと的確なコミュニケーションを実現したい マーケティングの4R

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. Consumer追加？ いまある部分 となると、データ供給先が増える 用途が増えると、ほぼデータの供給先も増えるということになります。 どこで分岐しましょう？ どんな打ち手が必要でしょう？ 8
 チャレンジ インプリ アイディア チャレンジ まとめ インプリ アイディア まとめ Kinesis Consumer Consumer BigQuery PubSub Consumer Enrichment Elasticsearch SingleStore Consumer MA？ Consumer レコメン？ MA？ レコメン？ ETL 定期バッチ処理？ 適しているシーンもあるけれど せっかくのリアルタイムデータだし…ちょっと違う

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. アイディア 9 インプリ アイディア チャレンジ まとめ インプリ チャレンジ まとめ

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. 前提 ● ログ ○ 1日平均1.6億件 ■ 1月の多い日で2億件 ■ 平日朝にスパイクがあり、多い時間帯と少ない時間帯で20倍以上の差がある ○ 1件当たり平均2KB ■ JSON形式 ■ コンピューティングコストよりストレージコストが安いと判断、Pre-JOIN拡張している ○ ニアリアルタイム ■ お客様の閲読から集計可能になるまで0.2秒程度 ● 環境 ○ AWSとGoogle Cloudのマルチクラウド ○ 主要な処理はAWSで行われている ○ DWHはBigQuery、その周辺にAirflowとTROCCOでデータ連携できる ○ ほとんどのコンポーネントはTerraformで管理している（例外もある） 10
 アイディア インプリ アイディア チャレンジ まとめ インプリ チャレンジ まとめ

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. シャード追加してConsumerも増やそう Consumerを増やす？ 真っ先に思いついたのがConsumerの追加でした。 Kinesisのシャードは Write:Readが1:2の比率なので、Producerが1つとするとConsumerは2つ使え、 同数のシャードを追加するごとに単純にConsumerは2つずつ増やせそう…（と思った） 11
 アイディア インプリ アイディア チャレンジ まとめ インプリ チャレンジ まとめ Kinesis Consumer Consumer Elasticsearch SingleStore Consumer MA？ Consumer レコメン？ ● Pros ○ Consumerの量産は簡単。Lambda作って、Kinesisとポ チッと繋ぐだけ。 ○ シャード追加で水平スケールできるとすれば、全件処理する 場合のLambdaの性能・負荷・コストは予測しやすい。 ○ Kinesis直だから速い。 ○ それぞれIteratorがあり再処理しやすい。 ● Cons ○ ログの一部しか必要としない処理でも、全件読み出してとり あえずLambdaが発火することになり、無駄なコストも？ ○ キャパがWrite 1 : Read 2 だからってConsumerを倍に できるわけではなかった（再処理などでスパイクする）

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. Consumer 1つに複数の役割を持たせる？ １つのConsumerの役割を増やす？ 次に考えたのが、1つのConsumerから処理を分岐する方法でした。 新設するConsumerは一つにしてKinesisの読み出しを最小限にしつつ、Consumer(Lambda)に一人二 役以上を担ってもらい連携先を広げていくこともできそう…（と思った） 12
 アイディア インプリ アイディア チャレンジ まとめ インプリ チャレンジ まとめ Kinesis Consumer Consumer Elasticsearch SingleStore MA？ Consumer レコメン？ ● Pros ○ Consumer (Lambda) の発火は最小限、1つのレコードが 1回処理されるだけなのでLambdaの費用は抑えられる。 ○ 必要なシャード追加も最小限なのでここもお得。 ● Cons ○ 連携先が増えるとLambdaの実行時間が延びコストになる。 ○ 連携先が増える度にLambdaの改修とデプロイが必要だ。 ○ 連携先の一つに障害が発生した場合に、どこからどこまで再 処理するかごちゃごちゃになる。（Iteratorが共通）

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. 必ずしも全件必要ということではない ConsumerはKinesisから全ログレコードを受け取りますが、連携先が必要としているログレコードはその 100%とは限りません。分析用途でデータを格納するBigQueryやElasticsearchには全件連携したいです が、レコメンデーションであれば記事の閲読履歴だけ、マーケティングオートメーションであればランディングや コンバージョンだけ連携したい、ということがあります。 13
 アイディア インプリ アイディア チャレンジ まとめ インプリ チャレンジ まとめ MA Consumer レコメン 記事の閲読履歴、読了基準を満たしたログ ログ全体の50%くらい コンバージョンポイント, etc… ログ全体の0.1%以下 Consumerにフィルター機能があると良い

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. インプリメンテーション 14 インプリ アイディア チャレンジ まとめ アイディア チャレンジ まとめ

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. 拡張ファンアウトでキャパ確保 分岐処理用Consumer追加 Consumerを追加 && 拡張ファンアウトを割り当て 連携先の拡張に対応するためのConsumerを1つ追加しました。（連携先の拡張は後述） Read TPはモニタリングしながらシャード数を調整し、最終的には既存の重要な処理を拡張ファンアウトコン シューマーに切り替えるなどして落ち着きました。 15
 インプリメンテーション インプリ アイディア チャレンジ まとめ アイディア チャレンジ まとめ Kinesis Consumer Consumer Elasticsearch SingleStore Consumer ？ 編集業務で必要なリアルタイム ダッシュボードのDBなので遅延し ないよう専用キャパを割り当て ここの連携は（相対的に）優先度が 低いので既存のキャパで動かす

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. Consumerがフィルタリング、SNS-Lambdaで後続処理 「EventTrigger」と名付けたConsumerを追加しました。このConsumerは発火の都度、DynamoDBを参 照してQueryDSLとTopic ARNのセットを取得、Queryに一致するレコードをSNSトピックに連携します。 SNSトピック毎にSubscriberのLambdaがあり、Lambdaが後続処理に繋いでいます。 16
 インプリメンテーション インプリ アイディア チャレンジ まとめ アイディア チャレンジ まとめ フィルターと分岐を司る “EventTrigger” Kinesis Consumer (Event Trigger) SNS Trigger Conditions SNS SNS API連携 API連携 API連携 フィルター条件（QueryDSL）と連携先SNS トピック等をDynamoDBテーブルに保存

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. フィルタリング用Query DSLをGUIで設定できるように マーケティングオートメーション（MA）の施策をリアルタイムデータに基づいて発火する機能も内製しましたが、 施策の度にQueryDSLを手書きしてDynamoDBを更新していると手間になる・事故の元になりそうです。 そこで、 “NGMA” と呼んでいる内製MAツールに条件指定用のGUIを搭載して設定を楽にしました。 17
 インプリメンテーション インプリ アイディア チャレンジ まとめ アイディア チャレンジ まとめ

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. 拡張ファンアウト 分岐処理用Consumerと SNS+Lambda群 レコメン専用Kinesis 全体像 18
 インプリメンテーション インプリ アイディア チャレンジ まとめ アイディア チャレンジ まとめ Kinesis Consumer Consumer Elasticsearch SingleStore Consumer Trigger Conditions SNS API連携 SNS API連携 Consumer Kinesis 電子版レコメンへ NGMA etc... SendGrid 編集に不可欠な リアルタイム分析 レコメンデーション等の プロダクトにおけるパーソナライズ プロモーション施策の発火 メールやA/Bテストなどサービス上 でのマーケティング施策発火

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. まとめ 19 インプリ アイディア チャレンジ まとめ インプリ アイディア チャレンジ

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. 採用しているサービスを比較 20
 まとめ インプリ アイディア チャレンジ まとめ インプリ アイディア チャレンジ データ保持期間 Kinesis 〜365日間 SQS 14日間 SNS 48時間 Cloud Pub/Sub 31日間 再処理のしやすさ ◎ Iterator指定 △ 再試行・DLQ △ 再試行・DLQ ◎ Iterator指定 ファンアウト ◎ 通常シャード、拡張シャード × 〇 ◎ メッセージサイズ 1MB 256KB 256KB 10MB ストリーム処理の根幹はSQSとKinesisで確実にデータを保持し、再処理耐性を高めています。 ファンアウトは Consumerの追加か、単一Consumerから分岐してSNS経由の連携としました。 メッセージサイズやレイテンシーは今回の用途では気にするような制約はありませんでした。

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. Key Takeaway 1. Consumer側の要件に応じてサービスを使い分ける a. 全件に近いボリュームを連携する場合はKinesis Consumerを増やす b. 一部を連携する先が複数あるならば、分岐用Consumerを1つ作る i. その後の連携はSNSまたはSQSを挟んで個別のSubscriberを用意しておく 2. KinesisにConsumerを追加する際のシャード数に注意 a. Write1:Read2だが再処理やスパイクではバランスが崩れる b. 重要なConsumerは拡張ファンアウトでキャパを確保する 3. 再処理の要否に応じた設計が必要 a. KinesisはIteratorの打ち直しで過去に遡って再処理できる。保持期間も365日まで延長可能 b. SNSやSQSは再試行の設定はできるが、連携先の障害などに対してはDLQを設けて保持する必要があり、データ保持期間の 短さにも注意が必要 4. それぞれのサービスの違いに注意する a. どれも似たことできるが微妙に異なるし、先々仕様が変わることもある b. 設計マージンになるのか無駄なコストになるのか…？ 21
 まとめ インプリ アイディア チャレンジ まとめ インプリ アイディア チャレンジ

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. データエンジニアの採用やってます！！ 22
 まとめ インプリ アイディア チャレンジ まとめ インプリ アイディア チャレンジ 一緒にデータ基盤の改良・運用をしたり、データ利活用を推進する仲間を募集しています！ データエンジニア - Google Cloud と AWS のマルチクラウド環境 - Go、Python、Rust、TypeScript、Node.js などを利用 - IaC(Terraform),オーケストレーション(Airflow, Dataform),CI/CD(GitHub Actions) - コーディングが得意な方も、インフラ管理が得意な方も、プロマネが得意な方もぜひ！

Copyright ⓒ 2025 Nikkei Inc. All rights reserved. Thank you! Any questions? 
 
 もっと良い方法、改善策あれば教えてください 🙇
 23