![[DL輪読会]GANSynth: Adversarial Neural Audio Synthesis](https://cdn.slidesharecdn.com/ss_thumbnails/20180315gansynthmizuta-190315003922-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Similar to エンジニア勉强会资料冲③搁迟辞补蝉迟别谤の11年 (20)
More from BrainPad Inc. (20)
エンジニア勉强会资料冲③搁迟辞补蝉迟别谤の11年
- 3. 自己紹介 篠原 聖（しのはら さとし） ? 2006年2月入社（ブレインパッド歴12年） ? マーケティングプラットフォーム本部 開発部 所属 ? 第二世代Rtoaster（現行）より設計?開発?運用を担当 ? 現在もコア部分の設計?開発や運用を担当しつつ開発部長も兼務 ? ここ数年の悩みは薄くなってきた前髪
- 5. 搁迟辞补蝉迟别谤の概要
- 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リクエスト/秒
- 15. オンプレミスの时代
- 16. サービス規模拡大にどう対応するか オンプレミスの时代のRtoasterでは2つのアプローチで対応を行ってきました。 ? インフラ増強 ○ Tracker / RecommenderやScorerはスケールアウト ○ ネットワーク機器やデータベースはスケールアップ ? ソフトウェア改修 ○ チューニングを行うことによるパフォーマンス改善 ○ 例えば、設計の見直しなどによるテーブル操作やデータ量の削減など ○ システム構成が変更できない環境に対する互換性が必要
- 18. 2007-07 → 2010-08 ボトルネックの調査と解消 ■ Webビーコン型を月間3億PVのサイトへ導入 ○ 当時のASPで1,000万トラッキング程度だったので未体験の負荷 ○ お客様データセンターに用意されたサーバーへインストール ○ サーバースペックは役割毎に指定されているため台数でカバー ○ 運用してみると実は月間5億PVだった ■ サーバー台数やデータ量増で潜在的な問題が顕在化 ○ 多くのボトルネックはデータベース操作 ■ リアルタイム性が求められない情報は非同期に複数クエリをまとめて更新 ■ 機能拡張の過程で発生した不要な正規化を崩してテーブルを統合 ○ ロングトランザクションでデータベース負荷増大 ■ 管理画面による時間のかかるデータ操作をバックグラウンド処理へ移行 ■ 大量データに対する更新は小さなレコード単位に分割して処理
- 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切り替えで対応
- 30. クラウド移行のまとめ ● クラウド環境で解決したこと ○ 機器調達が簡素化されインフラ増強までのリードタイムが短縮 ■ 以前： 機器選定→ベンダー相見積→社内手続→発注→納品→機器設置→構築 ○ ハードウェア障害対応や空きラック不足などの物理的な問題から解放された ○ 一部顧客から要求のあったDDoS対策やIPSの他、GSLBも手軽に導入できた ● Rtoasterの設計変更で解決したこと ○ ScorerやRecommender、データベースがクラスタ単位でスケールアウト可能に ○ サービス停止が伴うようなインフラ増強が不要になった ○ シングルテナント環境やパッケージ製品との互換性を保てた ● とは言え課題は残る ○ オンプレミス設計のままクラウドに持っていったのでコストメリットが少ない ○ バージョンアップや環境維持などのサービス運用負荷の改善は限定的
- 31. 最后に
- 33. Copyright ? 2018 BrainPad, Inc. ご清聴ありがとうございました