Upgrade to Pro — share decks privately, control downloads, hide ads and more …

積み上げられた技術資産と向き合いながら、プロダクトの信頼性をどう守るか

 積み上げられた技術資産と向き合いながら、プロダクトの信頼性をどう守るか

2025年5月29日開催
若手エンジニアが語るリアルな実例 ~「技術負債」との戦い方・「技術資産」活かし方
https://plaidtech.connpass.com/event/353065/

Avatar for PLAID Tech

PLAID Tech

May 29, 2025
Tweet

More Decks by PLAID Tech

Other Decks in Technology

Transcript

  1. © PLAID, Inc. ⽬次 1. KARTE Blocksの構成 2. 信頼性担保の必要性 3.

    SLOの策定 4. 具体的に役⽴った点 5. まとめ © PLAID, Inc. 3
  2. © PLAID, Inc. ⽬次 1. KARTE Blocksの構成 2. 信頼性担保の必要性 3.

    SLOの策定 4. 具体的に役⽴った点 5. まとめ 4
  3. © PLAID, Inc. KARTE Blocksの構成 5 • サイト改善における悩みは様々 ◦ 「継続してできない」「安⼼してできない」「⾃由にできない」

    • KARTE Blocksは、「サイト改修‧更新の効率化」「テストによる仮説検証や パーソナライズ」「データによる課題発⾒」までをワンストップで実現 • サイト運営の複雑性を緩和‧解消し、安⼼‧⾃由に⾏えるようにするプロダク ト あなたのサイト改善 あっという間に。継続的に。
  4. © PLAID, Inc. KARTE Blocksの構成 14 管理画⾯ builder server builder.js

    ユーザーのサイト ユーザーが配信設定をする 設定内容から3rd party script(builder.js) を⽣成してデプロイ builder.jsを配信 タグ⾃体に設定内容が埋め 込まれる ユーザーのサイトで読み込むこ とで実際にサイトを書き換え sync load
  5. © PLAID, Inc. KARTE Blocksの構成 15 特徴 • 3rd party

    scriptをクライアントに配布して書き換えを⾏う • 管理画⾯、3rd party scriptをbuildするserver、3rd party script⾃体の3つの構成 • 事業のコアは3rd party scriptにある、管理画⾯はそれを配布するための⼿段
  6. © PLAID, Inc. ⽬次 1. KARTE Blocksの構成 2. 信頼性担保の必要性 3.

    SLOの策定 4. 具体的に役⽴った点 5. まとめ 16
  7. © PLAID, Inc. 信頼性担保の必要性 17 信頼性担保の必要 性 • 元々、SLO⾃体は⼀部のプロダクトやプラットフォームチームによって定 義されていた

    • 最近ではプロダクトの成⻑や時間の経過により、事業の構造やあるべき 姿と合っていないコードも増えつつある • エンタープライズのクライアントも増えてきている中で、信頼性の向上は 必要
  8. © PLAID, Inc. ⽬次 1. KARTE Blocksの構成 2. 信頼性担保の必要性 3.

    SLOの策定 4. 具体的に役⽴った点 5. まとめ 18
  9. © PLAID, Inc. SLOの策定 19 SLOの策定 • そもそものプレイドにおけるSLOの概要については下記スライドを参照 ◦ PLAID

    マルチプロダクト環境下で SLO運⽤を浸透させるために 20230705 - Speaker Deck • その上で、KARTE Blocksで何に⽐重を置いてSLOの定義と運⽤をやって いるのか
  10. © PLAID, Inc. KARTE Blocksの構成 20 管理画⾯ builder server builder.js

    ユーザーのサイト ユーザーが配信設定をする 設定内容から3rd party script(builder.js) を⽣成してデプロイ builder.jsを配信 タグ⾃体に設定内容が埋め 込まれる ユーザーのサイトで読み込むこ とで実際にサイトを書き換え sync load さっきの図を引⽤
  11. © PLAID, Inc. KARTE Blocksの構成 21 管理画⾯ builder server builder.js

    ユーザーのサイト ユーザーが配信設定をする 設定内容から3rd party script(builder.js) を⽣成してデプロイ builder.jsを配信 タグ⾃体に設定内容が埋め 込まれる ユーザーのサイトで読み込 むことで実際にサイトを書 き換え sync load ⼤事なのはここ!
  12. © PLAID, Inc. SLOの策定 22 KARTE BlocksにおけるSLO • SLOはCritical User

    Journey(以下CUJ)を決めた結果の副産物 ◦ つまり、何がユーザーにとってクリティカルかを決める ◦ ⾃ずと何がクリティカルではないかが決まる ◦ CUJを守ることが信頼性向上につながる • ⼤事なのはbuilder.jsをデプロイする部分と、builder.jsが読み込まれる部分
  13. © PLAID, Inc. SLOの策定 23 KARTE BlocksにおけるSLO • 管理画⾯は ◦

    配信に関わる部分はクリティカル(配信設定) ◦ 配信に関わらない部分(運⽤に必要なラベル等の管理)はそもそもクリ ティカルではないものとして扱う
  14. © PLAID, Inc. SLOの策定 25 大前提 • 次に、何がクリティカルではないかを同様に考える ◦ 妥協できる点を考える

    ◦ 今回だと配信に関わらない部分であれば管理画⾯はゆるくていい ▪ クリティカルではないというだけでもちろん落ちない努⼒はする • その上で、機能を洗い出し、必要に応じてPdMやbiz、エンジニアに相談して決め る
  15. © PLAID, Inc. SLOの策定 27 CUJその1、builder.jsの配信 • 計測⽅法 ◦ datadogとfastlyの連携を使って、正常にbuilder.jsが読み込まれている

    かどうかを確認 ▪ status codeを使って判断 ▪ 割ってたらアラート鳴らす ◦ 実⾏部分に関しては、loggerは⼊れていない ▪ サイズ等の都合、⼊れたい気持ちはある ▪ エラーハンドリングを真⾯⽬にやる形で担保
  16. © PLAID, Inc. SLOの策定 28 CUJその2、管理画面が正常に動作する • 管理画⾯で配信に関わる機能が使えること • 設定が保存できない等、配信に関わる機能が使えないとクライアントの

    業務の遂⾏が困難になるため、ここはクリティカルとして扱う • 計測⽅法 ◦ datadogのlogsからmetricsを⽣成することができる ◦ server sideのlogのstatus codeを⾒て、5xxだったらbad eventsとし て扱う
  17. © PLAID, Inc. SLOの策定 30 CUJその3、builder.jsのデプロイができる • 計測⽅法 ◦ もし何らかの理由でbuilder.jsのデプロイが失敗しても3回まではretryす

    る ◦ 3回⽬の失敗をトリガーにdatadogにmetricsを送信 ▪ それ⾃体がbad events ◦ 全ビルドをtotal events
  18. © PLAID, Inc. SLOの策定 31 逆に、クリティカルとして扱わないもの • beta版の機能 ◦ e.g.

    KARTEと連携することで動的書き換えのできるDynamic Block • 管理画⾯で配信に関わらない機能 ◦ e.g. 運⽤管理のためのラベル機能
  19. © PLAID, Inc. SLOの策定 32 逆に、クリティカルとして扱わないもの • その他 ◦ 集計機能(配信ができていればrecover可能なので)

    ◦ クライアントに損失のないもの(たとえばhard limitの超過によるアラートが 出ない等) ◦ 代替機能があるもの(別の導線から案内可能) ◦ …etc
  20. © PLAID, Inc. ⽬次 1. KARTE Blocksの構成 2. 信頼性担保の必要性 3.

    SLOの策定 4. 具体的に役⽴った点 5. まとめ 33
  21. © PLAID, Inc. SLOの策定 34 SLOの運用 • 四半期に⼀度、⾒直すタイミングを設けている ◦ 内容は新機能やbeta版のものが正式リリースされるときにどうするか

    ◦ 現状の数字を眺めてみて値の調整や指標の妥当性を確認、認識を揃える ◦ 今、KARTE Blocksでは⼤きなリリースを控えているため、次のタイミングで はそれによって守るべきところや捨てるべきところを考え直す(予定)
  22. © PLAID, Inc. SLOの策定 35 SLOの運用 • 別途、weeklyでdatadogを眺めている ◦ builder.jsのサイズやCPU、memory等の変動を確認

    ◦ もし問題あるなら時間とって改善(ダッシュボードかもしれないしアプリケー ションコードかもしれない)
  23. © PLAID, Inc. 実際に役⽴った点 36 インシデント対応 • 配信に関わる補助機能が使えないことによる不具合が発⽣ ◦ 代替機能が存在する不具合だったので、クリティカルではないもの

    として判断でき、インシデントの重要度をコントロール ◦ リリースして再度アナウンス ◦ CUJが明確なので迅速に判断、対応できた ◦ 事後対応として、今回のケースをSLOのspecに補⾜事項として追加
  24. © PLAID, Inc. 実際に役⽴った点 37 新規開発 • 現在、KARTE Blocksでは⼤きなリリースを控えている ◦

    このような状況でも、安⼼して機能をリリースするには信頼性の担保が必要 ◦ クリティカルな要素を把握し、安⼼してリリースする ◦ リリース粒度に関わらず、攻めの開発を⾏うために守りの部分は⾮常に重要
  25. © PLAID, Inc. ⽬次 1. KARTE Blocksの構成 2. 信頼性担保の必要性 3.

    SLOの策定 4. 具体的に役⽴った点 5. まとめ © PLAID, Inc. 38
  26. © PLAID, Inc. まとめ  39 まとめ • KARTE BlocksでのSLOの策定 ◦

    ⼤事なのはCUJ ◦ CUJを守ることが信頼性向上につながる • CUJが明確だと ◦ 障害対応もスムーズになる ◦ 新しい機能の追加や⼤きめの改修の際にも安⼼してリリースできる