Share
Embed
Slide 1
Slide 1 text
© PLAID, Inc. 2025.05.28 ｜ 若手エンジニアが語るリアルな実例 ~「技術負債」との戦い方・「技術資産」活かし方
積み上げられた技術資産と向き合
いながら、プロダクトの信頼性を
どう守るか
株式会社プレイド ⽚⼭拓海
© PLAID, Inc.
Slide 2
Slide 2 text
© PLAID, Inc.
⾃⼰紹介
⽚⼭ 拓海
Takumi Katayama
• 株式会社プレイド
• KARTE Blocks ソフトウェアエンジ
ニア
2
Slide 3
Slide 3 text
© PLAID, Inc.
⽬次
1. KARTE Blocksの構成
2. 信頼性担保の必要性
3. SLOの策定
4. 具体的に役⽴った点
5. まとめ
© PLAID, Inc. 3
Slide 4
Slide 4 text
© PLAID, Inc.
⽬次
1. KARTE Blocksの構成
2. 信頼性担保の必要性
3. SLOの策定
4. 具体的に役⽴った点
5. まとめ
4
Slide 5
Slide 5 text
© PLAID, Inc.
KARTE Blocksの構成
5
● サイト改善における悩みは様々
○ 「継続してできない」「安⼼してできない」「⾃由にできない」
● KARTE Blocksは、「サイト改修‧更新の効率化」「テストによる仮説検証や
パーソナライズ」「データによる課題発⾒」までをワンストップで実現
● サイト運営の複雑性を緩和‧解消し、安⼼‧⾃由に⾏えるようにするプロダク
ト
あなたのサイト改善
あっという間に。継続的に。
Slide 6
Slide 6 text
© PLAID, Inc. | Confidential
こんなサイトがあったとしてBlocksのタグを埋め込んだ上で
たとえば
Slide 7
Slide 7 text
© PLAID, Inc. | Confidential
Slide 8
Slide 8 text
© PLAID, Inc. | Confidential
こんな感じの編集をすると
たとえば
Slide 9
Slide 9 text
© PLAID, Inc. | Confidential
Slide 10
Slide 10 text
© PLAID, Inc. | Confidential
Slide 11
Slide 11 text
© PLAID, Inc. | Confidential
Slide 12
Slide 12 text
© PLAID, Inc. | Confidential
実際に変更が反映されて配信される！
たとえば
Slide 13
Slide 13 text
© PLAID, Inc. | Confidential
Slide 14
Slide 14 text
© PLAID, Inc.
KARTE Blocksの構成
14
管理画⾯ builder server builder.js
ユーザーのサイト
ユーザーが配信設定をする
設定内容から3rd party
script(builder.js)
を⽣成してデプロイ
builder.jsを配信
タグ⾃体に設定内容が埋め
込まれる
ユーザーのサイトで読み込むこ
とで実際にサイトを書き換え
sync load
Slide 15
Slide 15 text
© PLAID, Inc.
KARTE Blocksの構成
15
特徴
● 3rd party scriptをクライアントに配布して書き換えを⾏う
● 管理画⾯、3rd party scriptをbuildするserver、3rd party script⾃体の3つの構成
● 事業のコアは3rd party scriptにある、管理画⾯はそれを配布するための⼿段
Slide 16
Slide 16 text
© PLAID, Inc.
⽬次
1. KARTE Blocksの構成
2. 信頼性担保の必要性
3. SLOの策定
4. 具体的に役⽴った点
5. まとめ
16
Slide 17
Slide 17 text
© PLAID, Inc.
信頼性担保の必要性
17
信頼性担保の必要
性
● 元々、SLO⾃体は⼀部のプロダクトやプラットフォームチームによって定
義されていた
● 最近ではプロダクトの成⻑や時間の経過により、事業の構造やあるべき
姿と合っていないコードも増えつつある
● エンタープライズのクライアントも増えてきている中で、信頼性の向上は
必要
Slide 18
Slide 18 text
© PLAID, Inc.
⽬次
1. KARTE Blocksの構成
2. 信頼性担保の必要性
3. SLOの策定
4. 具体的に役⽴った点
5. まとめ
18
Slide 19
Slide 19 text
© PLAID, Inc.
SLOの策定
19
SLOの策定
● そもそものプレイドにおけるSLOの概要については下記スライドを参照
○ PLAID マルチプロダクト環境下で SLO運⽤を浸透させるために
20230705 - Speaker Deck
● その上で、KARTE Blocksで何に⽐重を置いてSLOの定義と運⽤をやって
いるのか
Slide 20
Slide 20 text
© PLAID, Inc.
KARTE Blocksの構成
20
管理画⾯ builder server builder.js
ユーザーのサイト
ユーザーが配信設定をする
設定内容から3rd party
script(builder.js)
を⽣成してデプロイ
builder.jsを配信
タグ⾃体に設定内容が埋め
込まれる
ユーザーのサイトで読み込むこ
とで実際にサイトを書き換え
sync load
さっきの図を引⽤
Slide 21
Slide 21 text
© PLAID, Inc.
KARTE Blocksの構成
21
管理画⾯ builder server builder.js
ユーザーのサイト
ユーザーが配信設定をする
設定内容から3rd party
script(builder.js)
を⽣成してデプロイ
builder.jsを配信
タグ⾃体に設定内容が埋め
込まれる
ユーザーのサイトで読み込
むことで実際にサイトを書
き換え
sync load
⼤事なのはここ！
Slide 22
Slide 22 text
© PLAID, Inc.
SLOの策定
22
KARTE BlocksにおけるSLO
● SLOはCritical User Journey（以下CUJ）を決めた結果の副産物
○ つまり、何がユーザーにとってクリティカルかを決める
○ ⾃ずと何がクリティカルではないかが決まる
○ CUJを守ることが信頼性向上につながる
● ⼤事なのはbuilder.jsをデプロイする部分と、builder.jsが読み込まれる部分
Slide 23
Slide 23 text
© PLAID, Inc.
SLOの策定
23
KARTE BlocksにおけるSLO
● 管理画⾯は
○ 配信に関わる部分はクリティカル（配信設定）
○ 配信に関わらない部分（運⽤に必要なラベル等の管理）はそもそもクリ
ティカルではないものとして扱う
Slide 24
Slide 24 text
© PLAID, Inc.
SLOの策定
24
大前提
● CUJを決めるには、抽象度⾼く何がクリティカルかを描いておく必要がある
○ 今回だと配信ができないことが1番クリティカル
Slide 25
Slide 25 text
© PLAID, Inc.
SLOの策定
25
大前提
● 次に、何がクリティカルではないかを同様に考える
○ 妥協できる点を考える
○ 今回だと配信に関わらない部分であれば管理画⾯はゆるくていい
■ クリティカルではないというだけでもちろん落ちない努⼒はする
● その上で、機能を洗い出し、必要に応じてPdMやbiz、エンジニアに相談して決め
る
Slide 26
Slide 26 text
© PLAID, Inc.
SLOの策定
26
CUJその1、builder.jsの配信
● 事業のコアとなるのは、builder.jsが正常に配信されること
Slide 27
Slide 27 text
© PLAID, Inc.
SLOの策定
27
CUJその1、builder.jsの配信
● 計測⽅法
○ datadogとfastlyの連携を使って、正常にbuilder.jsが読み込まれている
かどうかを確認
■ status codeを使って判断
■ 割ってたらアラート鳴らす
○ 実⾏部分に関しては、loggerは⼊れていない
■ サイズ等の都合、⼊れたい気持ちはある
■ エラーハンドリングを真⾯⽬にやる形で担保
Slide 28
Slide 28 text
© PLAID, Inc.
SLOの策定
28
CUJその2、管理画面が正常に動作する
● 管理画⾯で配信に関わる機能が使えること
● 設定が保存できない等、配信に関わる機能が使えないとクライアントの
業務の遂⾏が困難になるため、ここはクリティカルとして扱う
● 計測⽅法
○ datadogのlogsからmetricsを⽣成することができる
○ server sideのlogのstatus codeを⾒て、5xxだったらbad eventsとし
て扱う
Slide 29
Slide 29 text
© PLAID, Inc.
SLOの策定
29
CUJその3、builder.jsのデプロイができる
● 管理画⾯で保存したものをbuilder serverでデプロイする、そこが正常に動作
すること
● それ⽤のserverがいて、そこにリクエストを投げることでデプロイする仕組み
Slide 30
Slide 30 text
© PLAID, Inc.
SLOの策定
30
CUJその3、builder.jsのデプロイができる
● 計測⽅法
○ もし何らかの理由でbuilder.jsのデプロイが失敗しても3回まではretryす
る
○ 3回⽬の失敗をトリガーにdatadogにmetricsを送信
■ それ⾃体がbad events
○ 全ビルドをtotal events
Slide 31
Slide 31 text
© PLAID, Inc.
SLOの策定
31
逆に、クリティカルとして扱わないもの
● beta版の機能
○ e.g. KARTEと連携することで動的書き換えのできるDynamic Block
● 管理画⾯で配信に関わらない機能
○ e.g. 運⽤管理のためのラベル機能
Slide 32
Slide 32 text
© PLAID, Inc.
SLOの策定
32
逆に、クリティカルとして扱わないもの
● その他
○ 集計機能（配信ができていればrecover可能なので）
○ クライアントに損失のないもの（たとえばhard limitの超過によるアラートが
出ない等）
○ 代替機能があるもの（別の導線から案内可能）
○ …etc
Slide 33
Slide 33 text
© PLAID, Inc.
⽬次
1. KARTE Blocksの構成
2. 信頼性担保の必要性
3. SLOの策定
4. 具体的に役⽴った点
5. まとめ
33
Slide 34
Slide 34 text
© PLAID, Inc.
SLOの策定
34
SLOの運用
● 四半期に⼀度、⾒直すタイミングを設けている
○ 内容は新機能やbeta版のものが正式リリースされるときにどうするか
○ 現状の数字を眺めてみて値の調整や指標の妥当性を確認、認識を揃える
○ 今、KARTE Blocksでは⼤きなリリースを控えているため、次のタイミングで
はそれによって守るべきところや捨てるべきところを考え直す（予定）
Slide 35
Slide 35 text
© PLAID, Inc.
SLOの策定
35
SLOの運用
● 別途、weeklyでdatadogを眺めている
○ builder.jsのサイズやCPU、memory等の変動を確認
○ もし問題あるなら時間とって改善（ダッシュボードかもしれないしアプリケー
ションコードかもしれない）
Slide 36
Slide 36 text
© PLAID, Inc.
実際に役⽴った点
36
インシデント対応
● 配信に関わる補助機能が使えないことによる不具合が発⽣
○ 代替機能が存在する不具合だったので、クリティカルではないもの
として判断でき、インシデントの重要度をコントロール
○ リリースして再度アナウンス
○ CUJが明確なので迅速に判断、対応できた
○ 事後対応として、今回のケースをSLOのspecに補⾜事項として追加
Slide 37
Slide 37 text
© PLAID, Inc.
実際に役⽴った点
37
新規開発
● 現在、KARTE Blocksでは⼤きなリリースを控えている
○ このような状況でも、安⼼して機能をリリースするには信頼性の担保が必要
○ クリティカルな要素を把握し、安⼼してリリースする
○ リリース粒度に関わらず、攻めの開発を⾏うために守りの部分は⾮常に重要
Slide 38
Slide 38 text
© PLAID, Inc.
⽬次
1. KARTE Blocksの構成
2. 信頼性担保の必要性
3. SLOの策定
4. 具体的に役⽴った点
5. まとめ
© PLAID, Inc. 38
Slide 39
Slide 39 text
© PLAID, Inc.
まとめ
39
まとめ
● KARTE BlocksでのSLOの策定
○ ⼤事なのはCUJ
○ CUJを守ることが信頼性向上につながる
● CUJが明確だと
○ 障害対応もスムーズになる
○ 新しい機能の追加や⼤きめの改修の際にも安⼼してリリースできる