Upgrade to Pro — share decks privately, control downloads, hide ads and more …

20210629/AdTechnologyMeetupVol2

 20210629/AdTechnologyMeetupVol2

2021年6月29日に開催したAdTechnologyMeetup vol.2にて、当日投影したスライドです。
※尚、ご登壇いただきました中村様は、2021年8月末に合同会社DMM.comをご退職されています。

AdTechnology Meetup

September 16, 2021
Tweet

More Decks by AdTechnology Meetup

Other Decks in Programming

Transcript

  1. 1

  2. 19
 プロダクト開発において拘ったこと(DMM 中村) <3ヶ月でリリースしたアドサーバの開発 2/7>  DMMが以前利用していた3rd Party製アドサーバの問題点 • アドリクエストのレスポンス速度が遅い(100ms超)
 •

    正確な広告効果の測定ができていない
 ◦ 例えば、見みられていない広告もimpressionとしていた
 • 低いカスタマイズ性(データ活用等)
 ◦ できるが、イチイチ見積もりから開発作業が発生し、時間も料金もかかりコストが高い。海外製 ということもあり、レスポンスも良くない。
 • 運用手数料が高い

  3. 21
 プロダクト開発において拘ったこと(DMM 中村) <3ヶ月でリリースしたアドサーバの開発  4/7>  そもそも、初めてのことで社内で信用がないので、 各担当者への悪印象を持たれないよう以下に気をつけて計画(汗) • とにかく障害は起こさない •

    とにかくサービス(売上)への影響はゼロ • とにかくオペレーション担当の手間を増やさない • とにかくアドサーバの前担当者は リスペクトする(悪口言わない) • とにかくコストはかけない(時間も予算も)
  4. 22
 プロダクト開発において拘ったこと(DMM 中村) <3ヶ月でリリースしたアドサーバの開発  5/7>  拘った点 実行したことそれらの結果 最小のシステム 配信サーバと集計バッチのみ開発。入稿はSEメンテを想定し後回し 素早くリリース

    3ヶ月でローンチ 関係者の信頼を得て ・影響は最低限に抑えるため、First Viewではない特定の枠をターゲットとし、問題がある場合は即座 に前3rdParty製のタグに戻せる状態にする。 ・監視を優先度高くし、問題が発生した場合はすぐにリカバリできる状態を準備 継続して改善する リリース後、システムによる大きな障害が発生することはなく、安定的に稼働し、 対応枠を増やしていき、半年で完全にリプレイス完了 それらの点は評価され、現在では各事業部からの問い合わせも増え、利用増
  5. 28
 プロダクト開発において拘ったこと (LOB 長谷川) • Feature Development (機能開発) ◦ 広告配信に関わる機能全般の開発

    • UI/UX ◦ 管理画面のUI(+API)の改善と開発 • Data ◦ 在庫見積もり機能の開発 • SRE • QA • App SDK (iOS/Android) 現状のチーム構成
  6. 29
 プロダクト開発において拘ったこと (LOB 長谷川) • Ad • Batch • API

    • UI • Data • SRE • QA • App SDK (iOS/Android) 変更前のチーム構成
  7. 30
 プロダクト開発において拘ったこと (LOB 長谷川) • 2019/06 ◦ Adコンポーネントの開発スタート • 2019/07

    - 2019/08 ◦ DSP, SSP, DMPチームから移動開始 ◦ 移動してきたメンバーがBatch, APIなどそれぞれのコンポーネントの開発を開始 • 2019/09 - 2019/10 ◦ DSP, SSP, DMPチームからの移動が本格化 ◦ それぞれのコンポーネントに参加する形で自然とチームが形成されていった チーム構成変更までの流れ - 1
  8. 31
 プロダクト開発において拘ったこと (LOB 長谷川) • 2020/01 ◦ 長谷川がLOB側のマネージャーになる ◦ 1on1開始

    • 2020/02 - 2020/03 ◦ AdとBatchチームを統合 ◦ チーム構成の模索 • 2020/04 ◦ 全体のチーム構成を変更 チーム構成変更までの流れ - 2
  9. 32
 プロダクト開発において拘ったこと (LOB 長谷川) • 開発タスクを開発開始可能にするまでにボトルネックがあった ◦ プロダクトオーナーが全体の開発機能の要件定義を行う必要があった ◦ 機能説明から各コンポーネントの見積もり完了まで時間がかかっていた

    • メンバーからの声 ◦ 機能の一部のみ開発をしているため、全体像がわからない ◦ 今のコンポーネントだけではなく他のコンポーネントの開発もやってみたい なぜチーム構成を変更したのか
  10. 33
 プロダクト開発において拘ったこと (LOB 長谷川) • コンポーネントのしきりがなくなった ◦ 新しいことへ挑戦しやすい環境 ◦ リソースの柔軟な配置

    • feature ownerの導入 ◦ プロダクトオーナーの負担軽減 ◦ 複数の中・大規模の開発の並行稼働が可能に チーム構成を変更して得られたもの
  11. 34
 プロダクト開発において拘ったこと (LOB 長谷川) • 開発に参加していない機能について、理解の解像度が低くなる ◦ コードレビューやアラート対応などに影響がでてくる • 現状考えている対策

    ◦ QA開始前に、エンジニアでの確認期間を設ける ◦ 自分が担当した機能の他に、他のメンバーが開発した機能も動作確認を行う ◦ → 開発に参加していない機能の理解を深めてもらう 今後の課題
  12. 39
 プロダクト開発において拘ったこと(Supership 三宅) インストリームの種類2 CM再生位置 • Pre-Roll ◦ 動画本編再生開始前にCMを再生 •

    Mid-Roll ◦ 動画本編再生中にCMを再生 ▪ 指定位置でCM再生 • Post-Roll ◦ 動画本編終了時にCMを再生 VAST仕様書より
  13. 40
 プロダクト開発において拘ったこと(Supership 三宅) 動画Player側で負荷分散は行うが、DSPにとって重たいものは重たい • prefetch ◦ CM挿入の数分前に分散させて広告リクエストを送る • チャンク分散

    ◦ 配信動画そのものを数秒間のチャンクに分け、その間で分散させる • ストリーム分散 ◦ 配信動画そのものをいくつかのグループに分け、数十秒遅延で配信させる リニア配信 + Mid-Roll → 全視聴者が同じタイミングでCM入り → 同時視聴者数 = 瞬間リクエスト数 → 負荷がYABAI!
  14. 42
 プロダクト開発において拘ったこと(Supership 三宅) 果たした成果 • ブラッシュアップ中ではあるものの、数百万同時視聴に耐えうるDSP環境を構築することが できた • 個々の配信サーバー内で分散処理されていたものを中央集権化できた 今後力を入れるところ

    • オンプレ/クラウドのスムーズな案件切り替え ◦ Liveで余った予算を自動でVODに回すとか • クラウドコスト抑制 ◦ データ転送の最適化やスケールアウト/スケールインの高速化