2018年3月13日にブレインパッドが開催した「エンジニア向け勉強会」の講演資料です。

1. Rtoasterの11年
株式会社ブレインパッド
2018-03-13

2. 本日お話しすること
Rtoasterは当初Webアクセス解析ツールのRTmetricsと連携するサーバー設置型の製
品として2006年4月20日にリリースされました。
その後、Javascriptタグによるトラッキング機能の追加やマルチテナント対応を行い、
ASPとして2006年9月12日よりサービス運用を開始しました。
ASPの運用開始からこれまで、サービスの規模が拡大していく中で、製品の互換性を
維持しつつ、どのような対応を行ってきたかについてお話しします。

3. 自己紹介
篠原 聖（しのはら さとし）
❖ 2006年2月入社（ブレインパッド歴12年）
❖ マーケティングプラットフォーム本部 開発部 所属
❖ 第二世代Rtoaster（現行）より設計・開発・運用を担当
❖ 現在もコア部分の設計・開発や運用を担当しつつ開発部長も兼務
❖ ここ数年の悩みは薄くなってきた前髪

4. Agenda
➢Rtoasterの概要
➢Rtoaster ASP運用
➢オンプレミスの時代
➢クラウドへ移行
➢最後に

5. Rtoasterの概要

6. Recommender
Scorer
Rtoasterの仕組み
トラッキング
データ
レコメンド
リクエスト
ASPのTTFB
トラッキング： 8ms
レコメンド ： 18ms
※4箇所レコメンドの場合
ルールで利用
Rtoasterはリアルタイムにユーザーの行動をスコア化し、レコメンデーションを行う
サービスです。
スコア
ルール処理
スコア更新
レコメンド
ルール処理
コンテンツ
選択
レコメンド
表示

7. Rtoasterのシステム構成
RtoasterにはRTmetrics連携型とWebビーコン型の2つのシステム構成が存在します。
どちらの構成でも利用できる機能は基本的には同じです。
■ RTmetrics連携型（第2世代 2006-06-15〜）
✓ お客様環境へ導入するサーバー設置型の製品
✓ 別途Web解析ツールのRTmetricsが必要
■ Webビーコン型 （2006-09-12〜）
✓ ASPでの提供がメイン
✓ Javascriptタグでトラッキングを行う

8. RTmetrics連携型
✓ 効果測定はRTmetricsで行う
✓ RTmetricsのAPIからScorerが
ログをリアルタイムに取得
✓ タグはレコメンドのみ
RTmetricsが必要なので
導入ハードルが高い

9. Webビーコン型（ASP）
✓ 効果測定はRtoasterが行う
✓ Trackerがリクエストを受けてRMIでScorerに通知
✓ 全てのページにトラッキングタグの埋め込みが必要
✓ SOAP APIも利用可能

10. Rtoaster ASP運用

11. Rtoaster ASPの処理数
（共用環境＋専用環境※サーバー設置型は除く）
【2018年1月時点】
✓ 34億 PV/月
✓ 151億IMP/月
【2007年1月時点】
✓ 5万 PV/月
✓ 1,000IMP/月

12. Rtoaster ASPの処理数
（共用環境のみ）
550,000 PV/月
680,000 IMP/月
74,000,000 PV/月
272,000,000 IMP/月
383,000,000 PV/月
1,096,000,000 IMP/月
1,500,000,000 PV/月
2,340,000,000 IMP/月
1,650,000,000 PV/月
4,550,000,000 IMP/月
3,000,000,000 PV/月
9,000,000,000 IMP/月

13. Rtoaster ASPの処理数
（共用環境のみ）
550,000 PV/月
680,000 IMP/月
74,000,000 PV/月
272,000,000 IMP/月
383,000,000 PV/月
1,096,000,000 IMP/月
1,500,000,000 PV/月
2,340,000,000 IMP/月
1,650,000,000 PV/月
4,550,000,000 IMP/月
3,000,000,000 PV/月
9,000,000,000 IMP/月ピーク時
5,200リクエスト/秒

14. Rtoaster ASPの環境
クラウド期オンプレミス期
2015-04

15. オンプレミスの時代

16. サービス規模拡大にどう対応するか
オンプレミスの時代のRtoasterでは2つのアプローチで対応を行ってきました。
⇨ インフラ増強
○ Tracker / RecommenderやScorerはスケールアウト
○ ネットワーク機器やデータベースはスケールアップ
⇨ ソフトウェア改修
○ チューニングを行うことによるパフォーマンス改善
○ 例えば、設計の見直しなどによるテーブル操作やデータ量の削減など
○ システム構成が変更できない環境に対する互換性が必要

17. 2006-09
サービス開始
オンプレミスの時代
2007-05
サーバー増強
2007-12
インターネット回線増速
サーバー増強
2008-10
サーバー増強
2009-01
ネットワーク機器入替
サーバー増強
2009-06
サーバーラック追加
ネットワーク再構築
2010-04
サーバー増強
2008-07 → 2010-08
ボトルネックの調査と解消

18. 2007-07 → 2010-08
ボトルネックの調査と解消
■ Webビーコン型を月間3億PVのサイトへ導入
○ 当時のASPで1,000万トラッキング程度だったので未体験の負荷
○ お客様データセンターに用意されたサーバーへインストール
○ サーバースペックは役割毎に指定されているため台数でカバー
○ 運用してみると実は月間5億PVだった
■ サーバー台数やデータ量増で潜在的な問題が顕在化
○ 多くのボトルネックはデータベース操作
■ リアルタイム性が求められない情報は非同期に複数クエリをまとめて更新
■ 機能拡張の過程で発生した不要な正規化を崩してテーブルを統合
○ ロングトランザクションでデータベース負荷増大
■ 管理画面による時間のかかるデータ操作をバックグラウンド処理へ移行
■ 大量データに対する更新は小さなレコード単位に分割して処理

19. 2006-09
サービス開始
オンプレミスの時代
2007-05
サーバー増強
2007-12
インターネット回線増速
サーバー増強
2008-10
サーバー増強
2009-01
ネットワーク機器入替
サーバー増強
2009-06
サーバーラック追加
ネットワーク再構築
2010-04
サーバー増強
2008-07 → 2010-08
ボトルネックの調査と解消
2010-09
ロードバランサー導入
サーバー増強
2010-11
サーバー増強
2012-02
インターネット回線増速
2011-04
サーバー増強
2011-11
ファイアウォール入れ替え
ロードバランサー入れ替え
2011-12
サーバー増強
データベースにioDrive導入2012-01
サーバー増強
2012-03
サーバー増強
2012-05
サーバー増強
2012-06 → 2012-10
データベースの負荷軽減

20. 2012-06 → 2012-10
データベースの負荷軽減
■ サイト内分析などの用途でRtoasterが利用される機会が増てきた
○ スコア設定やユーザー属性の大量投入が増加
○ データ量が多いため項目削除などに時間がかかりDB負荷も高い
■ テーブルの正規化を崩して独自のデータ構造へ
○ 紐付くスコアやユーザー属性の数に関係なく1つのカラムに圧縮して格納
○ 利用する際にフィルタすることで全ユーザーに対する更新操作は行わない
○ サービスを稼働させながら新しいデータ構造へ徐々に移行

21. 2006-09
サービス開始
オンプレミスの時代
2007-05
サーバー増強
2007-12
インターネット回線増速
サーバー増強
2008-10
サーバー増強
2009-01
ネットワーク機器入替
サーバー増強
2009-06
サーバーラック追加
ネットワーク再構築
2010-04
サーバー増強
2008-07 → 2010-08
ボトルネックの調査と解消
2010-09
ロードバランサー導入
サーバー増強
2010-11
サーバー増強
2012-02
インターネット回線増速
2011-04
サーバー増強
2011-11
ファイアウォール入れ替え
ロードバランサー入れ替え
2011-12
サーバー増強
データベースにioDrive導入2012-01
サーバー増強
2012-03
サーバー増強
2012-05
サーバー増強
2012-06 → 2012-10
データベースの負荷軽減2012-11
サーバー増強
2013-01
サーバー増強

22. 運用で見えてきた問題点
● オンプレミス環境であることの問題点
○ 機器調達の初期コスト・調達までのリードタイム
■ 急に大規模なサイトへの導入が決まっても対応できない
■ セキュリティ対策を検討しても機器のコストが…
○ サーバー増による物理的な問題
■ ラックの空きスペースや電源容量の不足、空きラックが近くにない
■ ハードウェア障害の対応など運用コスト増加
● Rtoasterの設計上の問題点
○ データベースはスケールアップで対応してきたが限界が見えてきた
○ ScorerやRecommenderのスケールアウトが不完全でメモリが逼迫してきた
■ 各サーバーが全てのサイトのルール情報を保持
■ 結局スケールアップが必要？サーバー入れ替え？
これらの問題を解消するために設計変更とインフラのクラウド移行計画が始動

23. クラウドへ移行

24. クラウド移行の検討
2014年7月よりベンダー選定と移行プラン、内部実装変更の検討を開始
● 検討事項は盛り沢山
○ これまで蓄積してきたデータや外部連携データフォーマットの互換性は？
○ シングルテナント環境やパッケージ製品とソースは分かれない？
○ タグの使い方やレコメンドの表示速度は変わらない？
○ 移行後に問題があった場合はすぐに切り戻せるの？
○ 移行にかかる期間と完了までに発生する費用は？
○ 環境切り替えの際のサービス停止時間は？
○ などなど…
検討の結果オンプレミス構成から大きく設計を変えずに移行することに…
見積の結果平行運用
期間は3ヶ月以内
サービス停止時間は
4時間程度
環境を平行運用して
DNS切り替えで対応

25. クラウド移行のための改修
Scorerと
Recommenderを統合
RMI通信を圧縮など
クラスタ単位で
水平分割
RecommenderはEngineへ移動
リクエストを受けるとクラスタを
振り分けてEngineで処理

26. クラウドへ移行
クラウド期オンプレミス期
平行稼働期間
2015-01 → 2015-
03

27. クラウドへ移行
旧（オンプレミス）環境と新（クラウド）環境をWANで接続
データベースのみ水平分割に対応したプログラム
をリリース
サイト規模によってクラスタを分けて旧環境のユ
ーザーを更新する際に新環境へ移行
クラスタ毎にアクセスがない旧環境のユーザーを
新環境へ移行するバッチを稼働
rsyncなどで必要な情報は定期的に同期を実施
環境切替時にサービスを停止して残りのデータ移行
DNSの変更により
環境切り替え・切
り戻し

28. クラウドへ移行
旧（オンプレミス）環境と新（クラウド）環境をWANで接続
データベースのみ水平分割に対応したプログラム
をリリース
サイト規模によってクラスタを分けて旧環境のユ
ーザーを更新する際に新環境へ移行
クラスタ毎にアクセスがない旧環境のユーザーを
新環境へ移行するバッチを稼働
rsyncなどで必要な情報は定期的に同期を実施
環境切替時にサービスを停止して残りのデータ移行
DNSの変更により
環境切り替え・切
り戻し
問題は発生しつつも無事（？）にクラウド環境へ移行が完了

29. 2015-04
クラウド上でサー
ビス開始
2015-06
GSLB導入
(静的コンテンツのみ)
2015-08
クラスタ追加
クラウド移行後
2016-03
Akamai DSD導入
2016-05
クラスタ追加
2016-08
Endpoint冗長化
(西日本リージョン)
2016-08
クラスタ追加
2016-10
クラスタ追加
2017-10
クラスタ追加
2018-01
Akamai GTM/DSA導入

30. クラウド移行のまとめ
● クラウド環境で解決したこと
○ 機器調達が簡素化されインフラ増強までのリードタイムが短縮
■ 以前： 機器選定→ベンダー相見積→社内手続→発注→納品→機器設置→構築
○ ハードウェア障害対応や空きラック不足などの物理的な問題から解放された
○ 一部顧客から要求のあったDDoS対策やIPSの他、GSLBも手軽に導入できた
● Rtoasterの設計変更で解決したこと
○ ScorerやRecommender、データベースがクラスタ単位でスケールアウト可能に
○ サービス停止が伴うようなインフラ増強が不要になった
○ シングルテナント環境やパッケージ製品との互換性を保てた
● とは言え課題は残る
○ オンプレミス設計のままクラウドに持っていったのでコストメリットが少ない
○ バージョンアップや環境維持などのサービス運用負荷の改善は限定的

31. 最後に

32. Rtoasterの今後について
Rtoaster v5がリリースされたことを契機に
次の12年を見据えた設計見直しの
検討を開始しました
次世代のRtoaster開発者WANTED！

33. Copyright © 2018 BrainPad, Inc.
ご清聴ありがとうございました