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
64
積み上げられた技術資産と向き合いながら、プロダクトの信頼性をどう守るか
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
200
早くて強い「リアルタイム解析基盤」から広げるマルチドメイン&プロダクト開発
plaidtech
PRO
1
360
月間180PBのストリーム処理されたイベントデータを使用した, KARTEのリアルタイムインタラクションマネジメント
plaidtech
PRO
0
550
固有技術の掛け算で事業推進に繋げるプロダクト開発
plaidtech
PRO
0
110
マルチプロダクトSaaSにおけるフェーズの違いや個人の強みを活かした組織づくり
plaidtech
PRO
0
650
6年の歴史×ペタバイト級のデータ基盤のチームを一体化する開発スタイル
plaidtech
PRO
4
220
生成AIでユーザー分析を強くする
plaidtech
PRO
4
420
プレイドにおけるDatadog APMの活用方法
plaidtech
PRO
2
750
モノリス開発の名残から脱却、マルチプロダクト開発における多様な開発者のニーズに応える使い勝手と 堅牢性を追求した認可基盤刷新の過程と工夫
plaidtech
PRO
2
2.1k
Other Decks in Technology
See All in Technology
会社員しながら本を書いてきた知見の共有
sat
PRO
3
660
Project Referencesを活用した実行環境ごとのtsconfig最適化
itatchi3
1
240
Introduction to Bill One Development Engineer
sansan33
PRO
0
230
AIに実況させる / AI Streamer
motemen
3
1.3k
MCP で繋ぐ Figma とデザインシステム〜LLM を使った UI 実装のリアル〜
kimuson
1
1k
テストを実施する前に考えるべきテストの話 / Thinking About Testing Before You Test
nihonbuson
PRO
12
1.9k
ソフトウェアテストのAI活用_ver1.10
fumisuke
0
180
会社紹介資料 / Sansan Company Profile
sansan33
PRO
6
360k
Type Challengesに新しい問題を追加して Type ChallengesのMaintainerになった話
ysknsid25
3
650
名刺メーカーDevグループ 紹介資料
sansan33
PRO
0
730
“新卒らしさ”を脱ぎ捨てて 〜1年を経て学んだこと〜
rebase_engineering
0
110
君だけのオリジナル async / await を作ろう / TSKaigi 2025
susisu
17
13k
Featured
See All Featured
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Building a Modern Day E-commerce SEO Strategy
aleyda
40
7.3k
Site-Speed That Sticks
csswizardry
6
580
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
180
53k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
It's Worth the Effort
3n
184
28k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
The Straight Up "How To Draw Better" Workshop
denniskardys
233
140k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
25
2.8k
Side Projects
sachag
453
42k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
BBQ
matthewcrist
88
9.6k
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が明確だと ◦ 障害対応もスムーズになる ◦ 新しい機能の追加や⼤きめの改修の際にも安⼼してリリースできる