Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
CyberAgent adtechstudioにおける ServiceMeshへのモチベーショ...
Search
Masaya Aoyama (@amsy810)
August 06, 2018
Technology
0
360
CyberAgent adtechstudioにおける ServiceMeshへのモチベーションと課題 / cloud native deep dive about istio at CyberAgent
Cloud Native Deep Dive #2
CyberAgent adtechstudioにおける ServiceMeshへのモチベーションと課題
Masaya Aoyama (@amsy810)
August 06, 2018
Tweet
Share
More Decks by Masaya Aoyama (@amsy810)
See All by Masaya Aoyama (@amsy810)
Keynote: Cloud Native Darwinism: Continuous Evolution of Platforms for Competitive Edge - KubeCon + CloudNativeCon Japan 2025 / kubecon-japan-2025-amsy810-keynote
masayaaoyama
0
33
KubeCon + CloudNativeCon EU 2025 Overview / k8sjp-70-kubecon-cncon-eu-2025-overview
masayaaoyama
0
120
KubeCon + CloudNativeCon NA 2024 Overviewat Kubernetes Meetup Tokyo #68 / amsy810_k8sjp68
masayaaoyama
0
460
Cloud Nativeを支える要素技術・プロダクト・プラクティスの歩み / infrastudy-returns-01-amsy810
masayaaoyama
4
770
KubeCon + CloudNativeCon EU 2024 Overview / k8sjp64-kubecon-overview
masayaaoyama
0
360
KubeCon + CloudNativeCon NA 2023 Sessions for Site Reliability Engineers / amsy810-srett08
masayaaoyama
2
790
KubeCon + CloudNativeCon NA 2023 Overview+Recap for Gateway API Cloud Native Community Japan Kickoff meetup / amsy810_cncj1
masayaaoyama
0
2k
Kubernetes as a Service の利用者を支える機能 - Platform Engineering Meetup #1 / pfem01-amsy810-k8s
masayaaoyama
1
2.6k
Kubernetes基盤を自律的に支えるController化の実装Tips / forkwell-202303-amsy810-k8s
masayaaoyama
7
3.8k
Other Decks in Technology
See All in Technology
2つのフロントエンドと状態管理
mixi_engineers
PRO
3
150
まずはマネコンでちゃちゃっと作ってから、それをCDKにしてみよか。
yamada_r
2
120
会社紹介資料 / Sansan Company Profile
sansan33
PRO
6
380k
Snowflake Intelligence × Document AIで“使いにくいデータ”を“使えるデータ”に
kevinrobot34
1
120
EncryptedSharedPreferences が deprecated になっちゃった!どうしよう! / Oh no! EncryptedSharedPreferences has been deprecated! What should I do?
yanzm
0
490
データ分析エージェント Socrates の育て方
na0
7
2.5k
サラリーマンの小遣いで作るtoCサービス - Cloudflare Workersでスケールする開発戦略
shinaps
2
470
新アイテムをどう使っていくか?みんなであーだこーだ言ってみよう / 20250911-rpi-jam-tokyo
akkiesoft
0
350
企業の生成AIガバナンスにおけるエージェントとセキュリティ
lycorptech_jp
PRO
2
200
エンジニアが主導できる組織づくり ー 製品と事業を進化させる体制へのシフト
ueokande
1
100
COVESA VSSによる車両データモデルの標準化とAWS IoT FleetWiseの活用
osawa
1
400
要件定義・デザインフェーズでもAIを活用して、コミュニケーションの密度を高める
kazukihayase
0
120
Featured
See All Featured
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
188
55k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
We Have a Design System, Now What?
morganepeng
53
7.8k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Six Lessons from altMBA
skipperchong
28
4k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
Designing Experiences People Love
moore
142
24k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.1k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
Practical Orchestrator
shlominoach
190
11k
Transcript
Masaya Aoyama CyberAgent adtech studio CyberAgent adtechstudioʹ͓͚Δ ServiceMeshͷϞνϕʔγϣϯͱ՝ @Cloud Native
Deep Dive #2 MasayaAoyama @amsy810
連載「今こそ始めよう!Kubernetes 入門」 @ThinkIT Japan Container Days v18.04 Keynote 登壇 Cloud Native
Meetup Tokyo Organizer (+ KubeCon日本人会 + JKD) CKA #138、CKAD #2 OpenStack / Kubernetes Contributor Masaya Aoyama (@amsy810) Infrastructure Engineer
2018年9⽉21⽇発売予定 https://bit.ly/k8s-amsy810 Kubernetesの各リソースについて体系的かつ網羅的に説明 Cloud Nativeな開発を促進させる周辺エコシステムについても紹介 ▪⽬次案 第1章 なぜKubernetesが必要なのか? 第2章 Kubernetes環境の選択肢
第3章 APIリソースとkubectl 第4章 Workloadsリソース 第5章 Discovery & LBリソース 第6章 Config & Storageリソース 第7章 ClusterリソースとMetadataリソース 第8章 リソース管理とオートスケーリング 第9章 ヘルスチェックとコンテナのライフサイクル 第10章 メンテナンスとノードの停⽌ 第11章 ⾼度で柔軟なスケジューリング 第12章 セキュリティ 第13章 マニフェストの汎⽤化を⾏うオープンソースソフトウェア 第14章 モニタリング 第15章 コンテナログの集約 第16章 CI/CD環境 第17章 マイクロサービスとServiceMesh 第18章 Kubernetesのアーキテクチャ 第19章 Kubernetesとこれから 付録
導入に向けたモチベーション 1.レイテンシのモニタリング 2.ロジックの Canary Release Circuit Brakeとかももちろんしたい
端末でWebページを開いたとき DSP Demand Side Platform SSP Supply Side Platform Yahooで検索をしようと
Yahooのページを開く 広告枠を埋めるよう SSPにリクエスト
SSPからDSPsに対してオークションを実施 DSP Demand Side Platform SSP Supply Side Platform この端末で
この広告枠買う?
ad-technology system DSP Demand Side Platform SSP Supply Side Platform
この端末で この広告枠買う? 男性でYahooをよく利用する人 Yahooだからアダルト広告はだめだな…健全なのがいい すごいコーラ好きな人みたい 広告主にサントミーがいるから100円で入札して 新商品のウルトラコーラを宣伝しよう…
ad-technology system DSP Demand Side Platform SSP Supply Side Platform
この端末で この広告枠買う? 100円で買う
ad-technology system DSP Demand Side Platform SSP Supply Side Platform
この端末で この広告枠買う? いつまでも全DSPを待っているとユーザビリティが低下する = オークションは 100ms で締め切り うーん・・・・ まだ?
ad-technology system DSP Demand Side Platform SSP Supply Side Platform
この端末で この広告枠買う? マイクロサービスアーキテクチャでは どのコンポーネントがボトルネックになっているか判別しづらい 広告主に関するサービス 予算に関するサービス SSPに関するサービス 広告枠に関するサービス 入札ロジックに関するサービス ユーザに関するサービス ※ イメージ
導入に向けたモチベーション 1.レイテンシのモニタリング 100msを超えたリクエストは棄却される = 売上0(サーバ代はかさむ) マイクロサービスアーキテクチャ内のボトルネック把握 2.ロジックの Canary Release 売上に大きく影響するロジック
= 売上マイナス数百万 徐々にロジックを導入できるように 可能ならPod数はそこまで増やしたくない(≠ BlueGreen Deploy)
ロジック変更前 DSP Demand Side Platform SSP Supply Side Platform この端末で
この広告枠買う? 男性でYahooをよく利用する人 Yahooだからアダルト広告はだめだな…健全なのがいい すごいコーラ好きな人みたい 広告主にサントミーがいるから100円で入札して 新商品のウルトラコーラを宣伝しよう…
ロジック変更後 DSP Demand Side Platform SSP Supply Side Platform この端末で
この広告枠買う? 男性! 男性はみんな筋トレ好きだからダンベル100%買う! 広告主にマッスル株式会社がいるから 10000円で入札してダンベルを宣伝しよう…
Canaryリリースの必要性 DSP Demand Side Platform SSP Supply Side Platform この端末で
この広告枠買う? 男性! 男性はみんな筋トレ好きだからダンベル100%買う! 広告主にマッスル株式会社がいるから 10000円で入札してダンベルを宣伝しよう… DSPは多売薄利 ロジックやシステムに問題があるとインパクトが大きい Canaryリリースが必要
導入に向けたモチベーション 1.レイテンシのモニタリング 100msを超えたリクエストは棄却される = 売上0(サーバ代はかさむ) マイクロサービスアーキテクチャ内のボトルネック把握 2.ロジックの Canary Release 売上に大きく影響するロジック
= 売上マイナス数百万 徐々にロジックを導入できるように 可能ならPod数はそこまで増やしたくない(≠ BlueGreen Deploy)
導入に向けた課題 1.マイクロサービス間のレイテンシをモニタリングするためにレイテンシが増える そもそもEnvoyプロキシが挟まるのでしょうがない StgなどではConduitでモニタリングのみ行い傾向調査? Istio Performance and Scalability WG が対応中
Throughput が + 142 %、Latency (p50) が - 59 % 2.CI/CDのつくりこみ Deploymentを複数作って Traffic Shiftingする場合 VirtualServiceとDestinationRuleの管理…Deployment削除…
Pilot Mixer Istio-Auth Envoy App a Envoy App b Envoy
App c Deployment a Deployment b Deployment c Data Plane Control Plane Istioの場合
導入に向けた課題 1.マイクロサービス間のレイテンシをモニタリングするためにレイテンシが増える そもそもEnvoyプロキシが挟まるのでしょうがない StgなどではConduitでモニタリングのみ行い傾向調査? Istio Performance and Scalability WG が対応中
Throughput が + 142 %、Latency (p50) が - 59 % 2.CI/CDのつくりこみ Deploymentを複数作って Traffic Shiftingする場合 VirtualServiceとDestinationRuleの管理…Deployment削除…
CI/CDの作り込み 新しいDeploymentを作成(replica=x) DestinationRuleを更新する(subsetを登録) Virtual ServiceでTraffic Shifting(Replica数も可能なら制御) Trafficの割合を徐々に制御 古いDeploymentを削除(or replica=0にする) ロールバック時の挙動どうする?
弊社はGitOps風、Spinnakerや別のツールを使っている場合は?