More Related Content
Similar to エンジニア勉強会資料_③Rtoasterの11年 (20)
More from BrainPad Inc. (20)
エンジニア勉強会資料_③Rtoasterの11年
- 3. 自己紹介
篠原 聖(しのはら さとし)
❖ 2006年2月入社(ブレインパッド歴12年)
❖ マーケティングプラットフォーム本部 開発部 所属
❖ 第二世代Rtoaster(現行)より設計・開発・運用を担当
❖ 現在もコア部分の設計・開発や運用を担当しつつ開発部長も兼務
❖ ここ数年の悩みは薄くなってきた前髪
- 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リクエスト/秒
- 18. 2007-07 → 2010-08
ボトルネックの調査と解消
■ Webビーコン型を月間3億PVのサイトへ導入
○ 当時のASPで1,000万トラッキング程度だったので未体験の負荷
○ お客様データセンターに用意されたサーバーへインストール
○ サーバースペックは役割毎に指定されているため台数でカバー
○ 運用してみると実は月間5億PVだった
■ サーバー台数やデータ量増で潜在的な問題が顕在化
○ 多くのボトルネックはデータベース操作
■ リアルタイム性が求められない情報は非同期に複数クエリをまとめて更新
■ 機能拡張の過程で発生した不要な正規化を崩してテーブルを統合
○ ロングトランザクションでデータベース負荷増大
■ 管理画面による時間のかかるデータ操作をバックグラウンド処理へ移行
■ 大量データに対する更新は小さなレコード単位に分割して処理
- 20. 2012-06 → 2012-10
データベースの負荷軽減
■ サイト内分析などの用途でRtoasterが利用される機会が増てきた
○ スコア設定やユーザー属性の大量投入が増加
○ データ量が多いため項目削除などに時間がかかりDB負荷も高い
■ テーブルの正規化を崩して独自のデータ構造へ
○ 紐付くスコアやユーザー属性の数に関係なく1つのカラムに圧縮して格納
○ 利用する際にフィルタすることで全ユーザーに対する更新操作は行わない
○ サービスを稼働させながら新しいデータ構造へ徐々に移行
- 22. 運用で見えてきた問題点
● オンプレミス環境であることの問題点
○ 機器調達の初期コスト・調達までのリードタイム
■ 急に大規模なサイトへの導入が決まっても対応できない
■ セキュリティ対策を検討しても機器のコストが…
○ サーバー増による物理的な問題
■ ラックの空きスペースや電源容量の不足、空きラックが近くにない
■ ハードウェア障害の対応など運用コスト増加
● Rtoasterの設計上の問題点
○ データベースはスケールアップで対応してきたが限界が見えてきた
○ ScorerやRecommenderのスケールアウトが不完全でメモリが逼迫してきた
■ 各サーバーが全てのサイトのルール情報を保持
■ 結局スケールアップが必要?サーバー入れ替え?
これらの問題を解消するために設計変更とインフラのクラウド移行計画が始動
- 30. クラウド移行のまとめ
● クラウド環境で解決したこと
○ 機器調達が簡素化されインフラ増強までのリードタイムが短縮
■ 以前: 機器選定→ベンダー相見積→社内手続→発注→納品→機器設置→構築
○ ハードウェア障害対応や空きラック不足などの物理的な問題から解放された
○ 一部顧客から要求のあったDDoS対策やIPSの他、GSLBも手軽に導入できた
● Rtoasterの設計変更で解決したこと
○ ScorerやRecommender、データベースがクラスタ単位でスケールアウト可能に
○ サービス停止が伴うようなインフラ増強が不要になった
○ シングルテナント環境やパッケージ製品との互換性を保てた
● とは言え課題は残る
○ オンプレミス設計のままクラウドに持っていったのでコストメリットが少ない
○ バージョンアップや環境維持などのサービス運用負荷の改善は限定的