Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

エンジニア勉強会資料_⑤広告プロダクトとプラットフォームの開発

568 views

Published on

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

Published in: Engineering
  • Be the first to comment

エンジニア勉強会資料_⑤広告プロダクトとプラットフォームの開発

  1. 1. 広告プロダクトとプラットフォームの開発 Techplay 2018年 3月13日
  2. 2. 自己紹介 照沼 領 (てるぬま りょう) ❖ マーケティングプラットフォーム本部 開発部 所属 ❖ クラウドストック → 予測・最適化チーム → L2Mixer → プラットフォーム を担当 ❖ コミュ力問題がありつつも開発副部長も兼務 ❖ ここ最近の悩みはコミュ力
  3. 3. Techplay x Brainpad 話すこと
  4. 4. 話すこと 内部 背景/要因 マーケティング プラットフォーム システム開発 わかった事 必要な人 システムの事 外部 / 業界
  5. 5. Techplay x Brainpad 背景 / 要因
  6. 6. 業界環境 MarTech AdTech(display) http://cdn.chiefmartec.com/wp-content/uploads/2017/05/marketing_technology_landscape_2017_slide.jpg https://www.slideshare.net/tkawaja/luma-display-ad-tech-landscape-2010-1231
  7. 7. 成長中
  8. 8. 多種多様化 と 拡大傾向
  9. 9. AdとBrainpad Ad BP
  10. 10. Ad 入稿 (広告作成) 広告と接触 広告効果 施策 広告面
  11. 11. AdとBrainpad 入稿 (広告作成) 広告と接触 広告効果 施策 自動化 データレイク ETL 機械学習 予測・最適化 広告面
  12. 12. AdとBrainpad 入稿 (広告作成) 広告と接触 広告効果 施策 自動化 データレイク ETL 機械学習 予測・最適化 広告面 自動運用 シミュレーション レポート
  13. 13. データ と アナリティクス
  14. 14. プラットフォームとエコシステム プラットフォーム ● レイヤー構造化 / オープン化 / シェアリング .... エコシステム ● 共存共栄 / ビジネス・テクノロジーアーキテクチャ構成 ....
  15. 15. プラットフォーム 広告主 管理画面 広告面 API 広告代理店 ツール ベンダー
  16. 16. エコシステム 広告主 管理画面 広告面 API 広告代理店 ツール ベンダー 広告面 管理画面 広告面
  17. 17. モジュール化 と 構造形成
  18. 18. 背景と要因 まとめ 多種多様化 拡大傾向 データ アナリティクス モジュール化 構造形成 高速な製品 開発環境 スケーラブル 分析(ML) マイクロサービス プラットフォーム プラットフォーム要件
  19. 19. Techplay x Brainpad システムアーキテクチャ
  20. 20. プラットフォーム論理構成:簡易版 ※ 点線のものは開発中または予定のものになります Earned ML Engine Paid Owned 認証・認可 AdMincer(MediaHub) 新規開発 and more広告面 バックエンド サービス プロダクト
  21. 21. プラットフォーム論理構成:簡易版 AdMincer(MediaHub) 新規開発 バックエンド サービス プロダクト
  22. 22. Media AdMincer:現在のアーキテクチャ ※ 絶賛開発中のため、実際のものと異なることがあります AdMincer Products Cloud SQL BigQuery Cloud Storage account event message storage Compute Engine Batch media hub App Engine API App Engine Cron App Engine OpenID Connect web app Cloud Pub/Sub Cloud Pub/Sub messaging
  23. 23. AdMincer:開発中のアーキテクチャ Media ※ 絶賛開発中のため、実際のものと異なることがあります AdMincer Products Cloud SQL BigQuery Cloud Storage account event message storage Compute Engine Batch media hub App Engine API App Engine Cron App Engine OpenID Connect web app Cloud Pub/Sub Cloud Pub/Sub messaging Compute Engine Kubernetes Engine インフラ管理が製品付加価値ではない(意訳) ※ カリッカリにチューニングして容易にスケールできれば問題はない
  24. 24. プラットフォーム論理構成未来:簡易版 Admincer (MediaHub) 新規 開発 バックエンド サービス プロダクト ML Engine 〔オウンドメディア〕 〔ペイド・アーンドメディア〕
  25. 25. Techplay x Brainpad わかった事 と 必要な人
  26. 26. わかったこと 1. SoE SoR 的な解釈 2. 技術的スプロール 3. Circuit Breaker 4. スコープ 5. API Gateway 6. バージョンニング地獄 7. DeployPipeline 8. コンウェイの法則 よかった事 改善が必要な事 よくしていきたい事
  27. 27. SoE SoR的な解釈 レイヤー・モジュール化によりサービスレベルでの、SoE,SoRの比重が明確化 (SLA、OLA、SLO も考え易く) EarnedPaid Admincer(MediaHub) 広告面 バックエンド サービス プロダクトSoE SoR
  28. 28. 技術的スプロール 速さ vs 秩序 のバランシングをどうするか? AdMincer (MediaHub) Account OpenID Connect Compute Engine App Engine App Engine Kubernetes Engine
  29. 29. Circuit Breaker 凝集性の高さが、Circuit Breaker の役割をし投資した被害を軽減 システム全体の波及しない coheciveproduct Customer Market AdMincer AdMincer
  30. 30. スコープ モノシリック マイクロサービス Next Ready 環境 開発環境(ローカル) プロダクション Next Ready 環境 外部向け 開発環境(ローカル) プロダクション NextReady 環境 内部向け 連携サービス スコープが拡大する。 真面目にやろうとすると、配布し易さの制約が発生し、インフラの軽量化が必要に... 連携サービス ローカル開発 連携サービス 向け環境
  31. 31. API Gateway バックエンドサービス毎にAPIを作らず Single Entry Point App Engine API Cloud Pub/Sub Compute Engine 開発機能 ML Engine API Gateway Backend Service
  32. 32. Versioning Hell バージョン管理が大変 Admincer (MediaHub) BigQueryApp Engine VerUp VerUp VerUp VerUp 過去バージョン サポート バージョン管理 各種広告媒体API バージョン管理 VerUp VerUp VerUp VerUp
  33. 33. Deploy Pipeline master :NextReady 環境 指定文字 :部分リリース tag :プロダクション環境リリース 部分リリース Next Ready 環境 プロダクション master master へ commit tag の設定 commit に 固定文字列 指定
  34. 34. Deploy Pipeline Compute Engine GKE Container Engine App Engine インスタンスを用いるとサーバー管理の俗人化や人が入る余地ができ アンチパターンの温床になる 大変 簡単 設定・管理 保守 スケールアウト Manual Configurations Management
  35. 35. コンウェイの法則 "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." — M. Conway “組織の設計するシステムには ... その組織のコミュニケーション構造を そのまま反映した設計になるという制約がある” 引用:https://anagileway.wordpress.com/2016/05/25/inverse-conway-maneuver-and-devops-microservices-and-agile/
  36. 36. 現状 ● 1チームで開発 ● 法則を通りにならない 要因 ● これまでの知見を生かしたい ● そんなに人がいない Admincer 法則通りにならない App Engine API Cloud Pub/Sub Compute Engine 開発機能 ML Engine API Gateway Backend Service 1つのチーム
  37. 37. Techplay x Brainpad [まとめ] 考察
  38. 38. わかったことへの考察 ●SoE SoR 的な解釈 → 顧客、マーケットに訴求しやすい開発環境 ●技術的スプロール ●Circuit Breaker → 低リスク(小さい失敗可能)
  39. 39. わかったことへの考察 ● スコープ ● API Gateway → 複雑化を管理できる技術・設計の重要性が増加 ● バージョンニング地獄 ● DeployPipeline → 高度化・複雑化しても ビジネス・開発の速度を落とさない 品質を保てる技術・設計の重要性が増加
  40. 40. わかったことへの考察 ● コンウェイの法則 → 法則通りにアーキテクチャが一つのモノシリックならない か?を確認していきたい → 逆コンウェイの法則の視点で検討していきたい
  41. 41. 逆コンウェイの戦略 “The ‘Inverse Conway Maneuver‘ recommends evolving your team and organizational structure to promote your desired architecture. Ideallyyour technology architecture will display isomorphism with your business architecture.” – Technology Lader (ThoughtWorks) 拙訳:逆コーンウェイ戦略は、自分たちの望ましいアーキテクチャ設計を促進する ように、チームと組織側を機動的に進化させることを推奨する。理想的には「技術 的アーキテクチャ」が「ビジネスアーキテクチャ」の同形写像になるように。
  42. 42. わかったことへの考察 App Engine API Cloud Pub/Sub Compute Engine 開発機能 ML Engine API Gateway Backend Service 1チーム 1チーム 1チーム ● 戦略の原則に通りなら 3チーム程度必要 ● ML周りは専門的なエンジ ニアが必要となる ● 戦略の正当性の検証方法
  43. 43. 最後まで読んでいただき ありがとうございます

×