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
2.3k
積み上げられた技術資産と向き合いながら、プロダクトの信頼性をどう守るか
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
データ民主化を加速する仕組み作り -BigQuery Sharing の活用-
plaidtech
PRO
0
120
サーバーサイドのビルド時間87倍高速化
plaidtech
PRO
0
780
大量配信システムにおけるSLOの実践:「見えない」信頼性をSLOで可視化
plaidtech
PRO
0
790
AI時代の開発生産性を加速させるアーキテクチャ設計
plaidtech
PRO
3
790
Rollupのビルド時間高速化によるプレビュー表示速度改善とバンドラとASTを駆使したプロダクト開発の難しさ
plaidtech
PRO
1
290
早くて強い「リアルタイム解析基盤」から広げるマルチドメイン&プロダクト開発
plaidtech
PRO
1
450
月間180PBのストリーム処理されたイベントデータを使用した, KARTEのリアルタイムインタラクションマネジメント
plaidtech
PRO
0
780
固有技術の掛け算で事業推進に繋げるプロダクト開発
plaidtech
PRO
0
150
マルチプロダクトSaaSにおけるフェーズの違いや個人の強みを活かした組織づくり
plaidtech
PRO
0
940
Other Decks in Technology
See All in Technology
更高效率低成本的 Observability 2.0 時代即將來臨 (Observability 2.0 Why you need know) - DevOpsDays Taiwan 2025
shazi7804
0
320
2025 IEEE MSST: NFS: Genesis
pugs
0
130
"複雑なデータ処理 × 静的サイト" を両立させる、楽をするRails運用 / A low-effort Rails workflow that combines “Complex Data Processing × Static Sites”
hogelog
1
920
How AI agents are changing the way we should build APIs
fabpot
1
360
Railsアプリケーション開発者のためのブックガイド
takahashim
5
2k
20250920_ServerlessDays
takuyay0ne
9
2.8k
Streamlit は社内ツールだけじゃない!PoC の速さで実現する'商用品質'の分析 SaaS アーキテクチャ
kdash
0
450
Rust In Python
lycorptech_jp
PRO
3
320
あなたのWebサービスはAIに自動テストしてもらえる?アクセシビリティツリーで読み解く、AIの『視点』
yusukeiwaki
1
470
ブラウザのAPIで色々なデバイスをあれこれ扱ってみた話(主にWeb HID API) / IoTLT @JLCPCB オープンハードカンファレンス
you
PRO
0
120
PacketProxyで探るGemini CLIのコンテキストエンジニアリング 〜AIエージェントを信頼できる相棒に〜
kakira9618
0
620
金融サービスの成長を支える “本人確認フロー” の改善と取り巻く環境の変化 / iOSDC Japan 2025
nakamuuu
1
110
Featured
See All Featured
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.1k
Facilitating Awesome Meetings
lara
56
6.5k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Designing for Performance
lara
610
69k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
The Power of CSS Pseudo Elements
geoffreycrofte
78
6k
RailsConf 2023
tenderlove
30
1.2k
What's in a price? How to price your products and services
michaelherold
246
12k
Building Adaptive Systems
keathley
43
2.8k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
45
2.5k
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が明確だと ◦ 障害対応もスムーズになる ◦ 新しい機能の追加や⼤きめの改修の際にも安⼼してリリースできる