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
積み上げられた技術資産と向き合いながら、プロダクトの信頼性をどう守るか
Search
PLAID Tech
PRO
May 29, 2025
Technology
0
1.6k
積み上げられた技術資産と向き合いながら、プロダクトの信頼性をどう守るか
2025年5月29日開催
若手エンジニアが語るリアルな実例 ~「技術負債」との戦い方・「技術資産」活かし方
https://plaidtech.connpass.com/event/353065/
PLAID Tech
PRO
May 29, 2025
Tweet
Share
More Decks by PLAID Tech
See All by PLAID Tech
Rollupのビルド時間高速化によるプレビュー表示速度改善とバンドラとASTを駆使したプロダクト開発の難しさ
plaidtech
PRO
1
210
早くて強い「リアルタイム解析基盤」から広げるマルチドメイン&プロダクト開発
plaidtech
PRO
1
370
月間180PBのストリーム処理されたイベントデータを使用した, KARTEのリアルタイムインタラクションマネジメント
plaidtech
PRO
0
590
固有技術の掛け算で事業推進に繋げるプロダクト開発
plaidtech
PRO
0
120
マルチプロダクトSaaSにおけるフェーズの違いや個人の強みを活かした組織づくり
plaidtech
PRO
0
830
6年の歴史×ペタバイト級のデータ基盤のチームを一体化する開発スタイル
plaidtech
PRO
4
230
生成AIでユーザー分析を強くする
plaidtech
PRO
4
430
プレイドにおけるDatadog APMの活用方法
plaidtech
PRO
2
770
モノリス開発の名残から脱却、マルチプロダクト開発における多様な開発者のニーズに応える使い勝手と 堅牢性を追求した認可基盤刷新の過程と工夫
plaidtech
PRO
2
2.2k
Other Decks in Technology
See All in Technology
Uniadex__公開版_20250617-AIxIoTビジネス共創ラボ_ツナガルチカラ_.pdf
iotcomjpadmin
0
150
「Chatwork」の認証基盤の移行とログ活用によるプロダクト改善
kubell_hr
1
100
エンジニア向け技術スタック情報
kauche
0
110
AIエージェント最前線! Amazon Bedrock、Amazon Q、そしてMCPを使いこなそう
minorun365
PRO
11
4.2k
MySQL5.6から8.4へ 戦いの記録
kyoshidaxx
1
100
(非公式) AWS Summit Japan と 海浜幕張 の歩き方 2025年版
coosuke
PRO
1
340
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
4
1.4k
2年でここまで成長!AWSで育てたAI Slack botの軌跡
iwamot
PRO
2
470
OAuth/OpenID Connectで実現するMCPのセキュアなアクセス管理
kuralab
5
880
Agentic DevOps時代の生存戦略
kkamegawa
0
1.1k
Azure AI Foundryでマルチエージェントワークフロー
seosoft
0
150
標準技術と独自システムで作る「つらくない」SaaS アカウント管理 / Effortless SaaS Account Management with Standard Technologies & Custom Systems
yuyatakeyama
2
1.1k
Featured
See All Featured
Designing for Performance
lara
609
69k
Embracing the Ebb and Flow
colly
86
4.7k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
The World Runs on Bad Software
bkeepers
PRO
69
11k
VelocityConf: Rendering Performance Case Studies
addyosmani
330
24k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Facilitating Awesome Meetings
lara
54
6.4k
4 Signs Your Business is Dying
shpigford
184
22k
KATA
mclloyd
29
14k
How to Think Like a Performance Engineer
csswizardry
24
1.7k
Transcript
© PLAID, Inc. 2025.05.28 | 若手エンジニアが語るリアルな実例 ~「技術負債」との戦い方・「技術資産」活かし方 積み上げられた技術資産と向き合 いながら、プロダクトの信頼性を どう守るか 株式会社プレイド ⽚⼭拓海
© PLAID, Inc.
© PLAID, Inc. ⾃⼰紹介 ⽚⼭ 拓海 Takumi Katayama • 株式会社プレイド
• KARTE Blocks ソフトウェアエンジ ニア 2
© PLAID, Inc. ⽬次 1. KARTE Blocksの構成 2. 信頼性担保の必要性 3.
SLOの策定 4. 具体的に役⽴った点 5. まとめ © PLAID, Inc. 3
© PLAID, Inc. ⽬次 1. KARTE Blocksの構成 2. 信頼性担保の必要性 3.
SLOの策定 4. 具体的に役⽴った点 5. まとめ 4
© PLAID, Inc. KARTE Blocksの構成 5 • サイト改善における悩みは様々 ◦ 「継続してできない」「安⼼してできない」「⾃由にできない」
• KARTE Blocksは、「サイト改修‧更新の効率化」「テストによる仮説検証や パーソナライズ」「データによる課題発⾒」までをワンストップで実現 • サイト運営の複雑性を緩和‧解消し、安⼼‧⾃由に⾏えるようにするプロダク ト あなたのサイト改善 あっという間に。継続的に。
© PLAID, Inc. | Confidential こんなサイトがあったとしてBlocksのタグを埋め込んだ上で たとえば
© PLAID, Inc. | Confidential
© PLAID, Inc. | Confidential こんな感じの編集をすると たとえば
© PLAID, Inc. | Confidential
© PLAID, Inc. | Confidential
© PLAID, Inc. | Confidential
© PLAID, Inc. | Confidential 実際に変更が反映されて配信される! たとえば
© PLAID, Inc. | Confidential
© PLAID, Inc. KARTE Blocksの構成 14 管理画⾯ builder server builder.js
ユーザーのサイト ユーザーが配信設定をする 設定内容から3rd party script(builder.js) を⽣成してデプロイ builder.jsを配信 タグ⾃体に設定内容が埋め 込まれる ユーザーのサイトで読み込むこ とで実際にサイトを書き換え sync load
© PLAID, Inc. KARTE Blocksの構成 15 特徴 • 3rd party
scriptをクライアントに配布して書き換えを⾏う • 管理画⾯、3rd party scriptをbuildするserver、3rd party script⾃体の3つの構成 • 事業のコアは3rd party scriptにある、管理画⾯はそれを配布するための⼿段
© PLAID, Inc. ⽬次 1. KARTE Blocksの構成 2. 信頼性担保の必要性 3.
SLOの策定 4. 具体的に役⽴った点 5. まとめ 16
© PLAID, Inc. 信頼性担保の必要性 17 信頼性担保の必要 性 • 元々、SLO⾃体は⼀部のプロダクトやプラットフォームチームによって定 義されていた
• 最近ではプロダクトの成⻑や時間の経過により、事業の構造やあるべき 姿と合っていないコードも増えつつある • エンタープライズのクライアントも増えてきている中で、信頼性の向上は 必要
© PLAID, Inc. ⽬次 1. KARTE Blocksの構成 2. 信頼性担保の必要性 3.
SLOの策定 4. 具体的に役⽴った点 5. まとめ 18
© PLAID, Inc. SLOの策定 19 SLOの策定 • そもそものプレイドにおけるSLOの概要については下記スライドを参照 ◦ PLAID
マルチプロダクト環境下で SLO運⽤を浸透させるために 20230705 - Speaker Deck • その上で、KARTE Blocksで何に⽐重を置いてSLOの定義と運⽤をやって いるのか
© PLAID, Inc. KARTE Blocksの構成 20 管理画⾯ builder server builder.js
ユーザーのサイト ユーザーが配信設定をする 設定内容から3rd party script(builder.js) を⽣成してデプロイ builder.jsを配信 タグ⾃体に設定内容が埋め 込まれる ユーザーのサイトで読み込むこ とで実際にサイトを書き換え sync load さっきの図を引⽤
© PLAID, Inc. KARTE Blocksの構成 21 管理画⾯ builder server builder.js
ユーザーのサイト ユーザーが配信設定をする 設定内容から3rd party script(builder.js) を⽣成してデプロイ builder.jsを配信 タグ⾃体に設定内容が埋め 込まれる ユーザーのサイトで読み込 むことで実際にサイトを書 き換え sync load ⼤事なのはここ!
© PLAID, Inc. SLOの策定 22 KARTE BlocksにおけるSLO • SLOはCritical User
Journey(以下CUJ)を決めた結果の副産物 ◦ つまり、何がユーザーにとってクリティカルかを決める ◦ ⾃ずと何がクリティカルではないかが決まる ◦ CUJを守ることが信頼性向上につながる • ⼤事なのはbuilder.jsをデプロイする部分と、builder.jsが読み込まれる部分
© PLAID, Inc. SLOの策定 23 KARTE BlocksにおけるSLO • 管理画⾯は ◦
配信に関わる部分はクリティカル(配信設定) ◦ 配信に関わらない部分(運⽤に必要なラベル等の管理)はそもそもクリ ティカルではないものとして扱う
© PLAID, Inc. SLOの策定 24 大前提 • CUJを決めるには、抽象度⾼く何がクリティカルかを描いておく必要がある ◦ 今回だと配信ができないことが1番クリティカル
© PLAID, Inc. SLOの策定 25 大前提 • 次に、何がクリティカルではないかを同様に考える ◦ 妥協できる点を考える
◦ 今回だと配信に関わらない部分であれば管理画⾯はゆるくていい ▪ クリティカルではないというだけでもちろん落ちない努⼒はする • その上で、機能を洗い出し、必要に応じてPdMやbiz、エンジニアに相談して決め る
© PLAID, Inc. SLOの策定 26 CUJその1、builder.jsの配信 • 事業のコアとなるのは、builder.jsが正常に配信されること
© PLAID, Inc. SLOの策定 27 CUJその1、builder.jsの配信 • 計測⽅法 ◦ datadogとfastlyの連携を使って、正常にbuilder.jsが読み込まれている
かどうかを確認 ▪ status codeを使って判断 ▪ 割ってたらアラート鳴らす ◦ 実⾏部分に関しては、loggerは⼊れていない ▪ サイズ等の都合、⼊れたい気持ちはある ▪ エラーハンドリングを真⾯⽬にやる形で担保
© PLAID, Inc. SLOの策定 28 CUJその2、管理画面が正常に動作する • 管理画⾯で配信に関わる機能が使えること • 設定が保存できない等、配信に関わる機能が使えないとクライアントの
業務の遂⾏が困難になるため、ここはクリティカルとして扱う • 計測⽅法 ◦ datadogのlogsからmetricsを⽣成することができる ◦ server sideのlogのstatus codeを⾒て、5xxだったらbad eventsとし て扱う
© PLAID, Inc. SLOの策定 29 CUJその3、builder.jsのデプロイができる • 管理画⾯で保存したものをbuilder serverでデプロイする、そこが正常に動作 すること
• それ⽤のserverがいて、そこにリクエストを投げることでデプロイする仕組み
© PLAID, Inc. SLOの策定 30 CUJその3、builder.jsのデプロイができる • 計測⽅法 ◦ もし何らかの理由でbuilder.jsのデプロイが失敗しても3回まではretryす
る ◦ 3回⽬の失敗をトリガーにdatadogにmetricsを送信 ▪ それ⾃体がbad events ◦ 全ビルドをtotal events
© PLAID, Inc. SLOの策定 31 逆に、クリティカルとして扱わないもの • beta版の機能 ◦ e.g.
KARTEと連携することで動的書き換えのできるDynamic Block • 管理画⾯で配信に関わらない機能 ◦ e.g. 運⽤管理のためのラベル機能
© PLAID, Inc. SLOの策定 32 逆に、クリティカルとして扱わないもの • その他 ◦ 集計機能(配信ができていればrecover可能なので)
◦ クライアントに損失のないもの(たとえばhard limitの超過によるアラートが 出ない等) ◦ 代替機能があるもの(別の導線から案内可能) ◦ …etc
© PLAID, Inc. ⽬次 1. KARTE Blocksの構成 2. 信頼性担保の必要性 3.
SLOの策定 4. 具体的に役⽴った点 5. まとめ 33
© PLAID, Inc. SLOの策定 34 SLOの運用 • 四半期に⼀度、⾒直すタイミングを設けている ◦ 内容は新機能やbeta版のものが正式リリースされるときにどうするか
◦ 現状の数字を眺めてみて値の調整や指標の妥当性を確認、認識を揃える ◦ 今、KARTE Blocksでは⼤きなリリースを控えているため、次のタイミングで はそれによって守るべきところや捨てるべきところを考え直す(予定)
© PLAID, Inc. SLOの策定 35 SLOの運用 • 別途、weeklyでdatadogを眺めている ◦ builder.jsのサイズやCPU、memory等の変動を確認
◦ もし問題あるなら時間とって改善(ダッシュボードかもしれないしアプリケー ションコードかもしれない)
© PLAID, Inc. 実際に役⽴った点 36 インシデント対応 • 配信に関わる補助機能が使えないことによる不具合が発⽣ ◦ 代替機能が存在する不具合だったので、クリティカルではないもの
として判断でき、インシデントの重要度をコントロール ◦ リリースして再度アナウンス ◦ CUJが明確なので迅速に判断、対応できた ◦ 事後対応として、今回のケースをSLOのspecに補⾜事項として追加
© PLAID, Inc. 実際に役⽴った点 37 新規開発 • 現在、KARTE Blocksでは⼤きなリリースを控えている ◦
このような状況でも、安⼼して機能をリリースするには信頼性の担保が必要 ◦ クリティカルな要素を把握し、安⼼してリリースする ◦ リリース粒度に関わらず、攻めの開発を⾏うために守りの部分は⾮常に重要
© PLAID, Inc. ⽬次 1. KARTE Blocksの構成 2. 信頼性担保の必要性 3.
SLOの策定 4. 具体的に役⽴った点 5. まとめ © PLAID, Inc. 38
© PLAID, Inc. まとめ 39 まとめ • KARTE BlocksでのSLOの策定 ◦
⼤事なのはCUJ ◦ CUJを守ることが信頼性向上につながる • CUJが明確だと ◦ 障害対応もスムーズになる ◦ 新しい機能の追加や⼤きめの改修の際にも安⼼してリリースできる