Slide 1
Slide 1 text
なんとなく使っていたSentryに
向き合い始めた話
2023/8/30
1
髙野 将 a.k.a @masaru_b_cl
Slide 2
Slide 2 text
2
⾃⼰紹介
髙野 将 a.k.a @masaru_b_cl
産業⽀援グループ
⼩売流通ソリューション部
Devチームマネージャー
Slide 3
Slide 3 text
prismatixとは︖
Slide 4
Slide 4 text
4
prismatixとは︖
l EC / CRM 特化型 PaaS
l クラスメソッドのB2B⾃社プロダクト
l エンゲージメントコマース
l 伴⾛型コンサルティング
https://prismatix.jp/
Slide 5
Slide 5 text
5
EC / CRM システムの課題
l パッケージの限界
l 複雑なシステム連携
l 帯に短し襷に⻑し
Slide 6
Slide 6 text
6
EC / CRM システムの課題
l パッケージの限界
→ ヘッドレスコマース
l 複雑なシステム連携
→ 700を超える汎⽤API
l 帯に短し襷に⻑し
→ マイクロサービス
Slide 7
Slide 7 text
7
プロダクトの特徴
シングルテナントで環境を構築・提供
l 顧客と⽤途ごとに独⽴した環境を提供
l 本番⽤ / ステージング⽤ / 開発⽤ / 性能試験⽤ など
l 必要なマイクロサービスだけ構築
l 認証のみ / 認証と会員基盤 / 認証とEC基盤 など
l フロントシステム側でAPIを組み合わせて機能を実現
l 専任のソリューションアーキテクトが導⼊⽀援
Slide 8
Slide 8 text
8
チーム体制
いわゆる機能別組織
l Devチーム︓開発担当
l アプリの機能追加・改善
l Kibanチーム︓運⽤担当
l アプリ実⾏環境構築・設定変更・維持管理
l CSチーム︓顧客担当
l 導⼊⽀援、顧客サポート窓⼝、要望や問題などの課題解決
Slide 9
Slide 9 text
9
Agenda
l Sentry導⼊〜これまで
l 今取り組んでいること
l チームに起きた変化
Slide 10
Slide 10 text
Sentry導⼊〜これまで
Slide 11
Slide 11 text
11
Sentry導⼊
「モダンな運⽤」をしたかった運⽤担当が主導
l 開発担当の積極的な巻き込みはなかった
l アプリに⼿を⼊れずに導⼊する⽅法を選択
l エラーログを元にSentryに連携する仕組みを構築
AWS Cloud 1
Amazon ECS
マイクロサービス
コンテナ
Amazon CloudWach Logs
AWS Lambda
Put lerror ogs
Subscribe error log
Capture message
AWS Cloud 2
AWS Cloud n
Slide 12
Slide 12 text
12
導⼊してどうなった︖
あまり活⽤されず……
Slide 13
Slide 13 text
13
導⼊してどうなった︖
あまり活⽤されず……
l 開発側には「⾒たければ権限付与します」という共有だけ
l 誰もが気軽に⾒れる状態ではなかった
l 活⽤⽅法および処理フローを決めていなかった
l Sentry Issueを⾒て気づいた運⽤担当が
そのことを開発担当に知らせたりはしていた
l 開発担当が積極的にアプリ修正につなげるような感じではない
Slide 14
Slide 14 text
導⼊から1年後
Slide 15
Slide 15 text
16
導⼊から1年後
エラーを処理するプロセスを決めた
Slide 16
Slide 16 text
18
エラーを処理するプロセスを決めた
エラーごとに対応マニュアルを作って処理する
1. 運⽤担当︓マニュアルを開発担当に作成依頼
2. 開発担当︓マニュアルを作成して運⽤担当に処理依頼
3. 運⽤担当︓作成されたマニュアルを参照して処理
Slide 17
Slide 17 text
それからしばらくして何が起きたか︖
Slide 18
Slide 18 text
20
それからしばらくして何が起きたか︖
エラー処理の⼿間が増え続け
運⽤負荷が増⼤した
Slide 19
Slide 19 text
21
直接的な要因
顧客の増加に伴って
エラーもマニュアルも増え続けたため
Slide 20
Slide 20 text
22
根本原因
エラー処理の⽬的がうまく共有されていなかった
l 開発担当︓
マニュアルは作るが処理は運⽤にお任せ
l ⽇々どれだけエラーが発⽣しているかを知らない
l エラー処理にどれだけ⼿間がかかっているかを知らない
l 運⽤担当︓
マニュアルで処理はするがアプリのことは開発にお任せ
l なぜそのエラーが発⽣するかを知らない
l どうやったらエラーが発⽣しなくなるかを知らない
分断がある
Slide 21
Slide 21 text
いま 取り組んでいる こと
Slide 22
Slide 22 text
24
いま取り組んでいること
エラー処理を開発担当の責務にする
Slide 23
Slide 23 text
25
エラー処理を開発担当の責務にする
エラー処理を 楽にしたい という動機を⽣む
l ⾃分たちが処理することで ⾯倒事 に気付けるようになる
l ⾯倒に感じれば 改善したい という気持ちが⽣まれる
Slide 24
Slide 24 text
26
実際何をやっているか 〜 その１
開発担当がエラーの仕分けと処理をする
l マニュアルを探して対応要否の判定、対応依頼を実施
l データ補正など権限が必要なものは運⽤担当に依頼
l エラー処理の 課題 を⾒つけ出して対処する
l 対応不要なエラーを発⽣させないようアプリを修正する
l 対処がしやすいエラーメッセージに修正する
l マニュアルを⾒つけやすくわかりやすくする
Slide 25
Slide 25 text
27
実際何をやっているか 〜 その２
Sentry連携の仕組み⾒直し
l 処理しやすいように Lambda を改善
l ⾊々なエラーが単⼀の Issue にまとまってしまっていた
l 例外名から fingerprint を⽣み出していたため
l 扱いたい単位で⼀つの Issue にする
l マイクロサービスや内部例外の違いを考慮する
l 対処不要ならIgnoreしやすくなる
l Ignore してできた余裕を アプリ改善 に向ける
Slide 26
Slide 26 text
28
チームに起きた変化
Slide 27
Slide 27 text
29
チームに起きた変化
エラーを意識したふるまいが
少しずつ⾒えてきた
Slide 28
Slide 28 text
30
チームに起きた変化
エラーを意識したふるまいが少しずつ⾒えてきた
l 「エラーを減らせるタスクを先にやったほうがいい」
みたいな意⾒が⾃発的に出てきた
l 「このサービスのエラーなんかいつもより多くない︖」
みたいな発⾔が出てきた
l 他のメンバーが作ったマニュアルについても
改善点を相談するようになった
Slide 29
Slide 29 text
最後に
Slide 30
Slide 30 text
32
最後に
エラーはプロダクト開発にとっての 学び
l 想定外 を 想定内 にするための元ネタ
l 考慮していなかった使われ⽅
l 思ってもいなかったアクセス量
l あると思っていなかった外部システムの挙動
l 運⽤/開発担当だからと思わず ⼀緒に取り組もう
l 組織としてのパフォーマンスアップにつながる
Slide 31
Slide 31 text
No content