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

1. 広告プロダクトとプラットフォームの開発
Techplay
2018年 3月13日

2. 自己紹介
照沼 領 (てるぬま りょう)
❖ マーケティングプラットフォーム本部 開発部 所属
❖ クラウドストック → 予測・最適化チーム → L2Mixer → プラットフォーム を担当
❖ コミュ力問題がありつつも開発副部長も兼務
❖ ここ最近の悩みはコミュ力

3. Techplay x Brainpad
話すこと

4. 話すこと
内部
背景/要因
マーケティング
プラットフォーム
システム開発 わかった事
必要な人
システムの事
外部 / 業界

5. Techplay x Brainpad
背景 / 要因

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. 成長中

8. 多種多様化
と
拡大傾向

9. AdとBrainpad
Ad BP

10. Ad
入稿
（広告作成）
広告と接触 広告効果
施策
広告面

11. AdとBrainpad
入稿
（広告作成）
広告と接触 広告効果
施策
自動化
データレイク
ETL
機械学習
予測・最適化
広告面

12. AdとBrainpad
入稿
（広告作成）
広告と接触 広告効果
施策
自動化
データレイク
ETL
機械学習
予測・最適化
広告面
自動運用 シミュレーション
レポート

13. データ
と
アナリティクス

14. プラットフォームとエコシステム
プラットフォーム
● レイヤー構造化 ／ オープン化 ／ シェアリング ....
エコシステム
● 共存共栄 ／ ビジネス・テクノロジーアーキテクチャ構成 ....

15. プラットフォーム
広告主
管理画面
広告面
API
広告代理店
ツール
ベンダー

16. エコシステム
広告主
管理画面
広告面
API
広告代理店 ツール
ベンダー
広告面
管理画面
広告面

17. モジュール化
と
構造形成

18. 背景と要因 まとめ
多種多様化
拡大傾向
データ
アナリティクス
モジュール化
構造形成
高速な製品
開発環境
スケーラブル
分析（ML）
マイクロサービス
プラットフォーム
プラットフォーム要件

19. Techplay x Brainpad
システムアーキテクチャ

20. プラットフォーム論理構成：簡易版
※ 点線のものは開発中または予定のものになります
Earned
ML Engine
Paid Owned
認証・認可
AdMincer(MediaHub)
新規開発
and more広告面
バックエンド
サービス
プロダクト

21. プラットフォーム論理構成：簡易版
AdMincer(MediaHub)
新規開発
バックエンド
サービス
プロダクト

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. 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. プラットフォーム論理構成未来：簡易版
Admincer (MediaHub)
新規
開発
バックエンド
サービス
プロダクト
ML Engine
〔オウンドメディア〕 〔ペイド・アーンドメディア〕

25. Techplay x Brainpad
わかった事 と 必要な人

26. わかったこと
1. SoE SoR 的な解釈
2. 技術的スプロール
3. Circuit Breaker
4. スコープ
5. API Gateway
6. バージョンニング地獄
7. DeployPipeline
8. コンウェイの法則
よかった事
改善が必要な事
よくしていきたい事

27. SoE SoR的な解釈
レイヤー・モジュール化によりサービスレベルでの、SoE,SoRの比重が明確化
（SLA、OLA、SLO も考え易く）
EarnedPaid
Admincer(MediaHub)
広告面
バックエンド
サービス
プロダクトSoE
SoR

28. 技術的スプロール
速さ vs 秩序 のバランシングをどうするか？
AdMincer
(MediaHub)
Account
OpenID Connect
Compute Engine
App Engine
App Engine
Kubernetes
Engine

29. Circuit Breaker
凝集性の高さが、Circuit Breaker の役割をし投資した被害を軽減
システム全体の波及しない
coheciveproduct Customer
Market
AdMincer
AdMincer

30. スコープ
モノシリック マイクロサービス
Next Ready 環境
開発環境（ローカル）
プロダクション
Next Ready 環境
外部向け
開発環境（ローカル）
プロダクション
NextReady 環境
内部向け
連携サービス
スコープが拡大する。
真面目にやろうとすると、配布し易さの制約が発生し、インフラの軽量化が必要に...
連携サービス
ローカル開発
連携サービス
向け環境

31. API Gateway
バックエンドサービス毎にAPIを作らず Single Entry Point
App Engine
API
Cloud
Pub/Sub
Compute
Engine
開発機能
ML Engine
API Gateway Backend Service

32. Versioning Hell
バージョン管理が大変
Admincer
(MediaHub)
BigQueryApp Engine
VerUp
VerUp
VerUp
VerUp
過去バージョン
サポート
バージョン管理
各種広告媒体API
バージョン管理
VerUp
VerUp
VerUp
VerUp

33. Deploy Pipeline
master ：NextReady 環境
指定文字 ：部分リリース
tag ：プロダクション環境リリース
部分リリース
Next Ready 環境
プロダクション
master
master へ
commit
tag の設定
commit
に 固定文字列 指定

34. Deploy Pipeline
Compute
Engine
GKE
Container Engine
App Engine
インスタンスを用いるとサーバー管理の俗人化や人が入る余地ができ
アンチパターンの温床になる
大変 簡単
設定・管理
保守
スケールアウト
Manual Configurations Management

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. 現状
● 1チームで開発
● 法則を通りにならない
要因
● これまでの知見を生かしたい
● そんなに人がいない
Admincer
法則通りにならない
App Engine
API
Cloud
Pub/Sub
Compute
Engine
開発機能
ML Engine
API Gateway Backend Service
1つのチーム

37. Techplay x Brainpad
[まとめ] 考察

38. わかったことへの考察
●SoE SoR 的な解釈
→ 顧客、マーケットに訴求しやすい開発環境
●技術的スプロール
●Circuit Breaker
→ 低リスク（小さい失敗可能）

39. わかったことへの考察
● スコープ
● API Gateway
→ 複雑化を管理できる技術・設計の重要性が増加
● バージョンニング地獄
● DeployPipeline
→ 高度化・複雑化しても
ビジネス・開発の速度を落とさない
品質を保てる技術・設計の重要性が増加

40. わかったことへの考察
● コンウェイの法則
→ 法則通りにアーキテクチャが一つのモノシリックならない
か？を確認していきたい
→ 逆コンウェイの法則の視点で検討していきたい

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. わかったことへの考察
App Engine
API
Cloud
Pub/Sub
Compute
Engine
開発機能
ML Engine
API Gateway Backend Service
1チーム
1チーム
1チーム
● 戦略の原則に通りなら
３チーム程度必要
● ML周りは専門的なエンジ
ニアが必要となる
● 戦略の正当性の検証方法

43. 最後まで読んでいただき
ありがとうございます