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
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Honahuku
October 17, 2024
Technology
0
1.1k
エンジニアでも論文が読みたい!
PIXIV DEV MEETUP 2024 での発表資料です
https://conference.pixiv.co.jp/2024/dev-meetup
Honahuku
October 17, 2024
Tweet
Share
More Decks by Honahuku
See All by Honahuku
Kubernetes のスケーラビリティを左右するデータストアの話
honahuku
0
75
KubeCon + CloudNativeCon Japan 2025 に行ってきた! & containerd の新機能紹介
honahuku
0
180
「改訂版ブルーム・タキソノミー」を利用したソフトウェアドキュメンテーションの改善手法の提案
honahuku
0
700
Kubernetes のクラスタ内ネットワーク概要
honahuku
1
68
大規模コンピューティングを支える Kubernetes のネットワーク
honahuku
0
390
今から始める分散システム
honahuku
0
340
SecAd~Ad data drivin’ network security~
honahuku
0
220
Other Decks in Technology
See All in Technology
Databricks (と気合い)で頑張るAI Agent 運用
kameitomohiro
0
340
AWS Bedrock Guardrails / 機密情報の入力・出力をブロックする — Blocking Sensitive Information Input/Output
kazuhitonakayama
2
180
primeNumber DATA MANAGEMENT CAMP #2:
masatoshi0205
1
630
APMの世界から見るOpenTelemetryのTraceの世界 / OpenTelemetry in the Java
soudai
PRO
0
200
オンプレとGoogle Cloudを安全に繋ぐための、セキュア通信の勘所
waiwai2111
3
1k
パネルディスカッション資料 (at Tableau Now! - 2026-02-26)
yoshitakaarakawa
0
760
社内でAWS BuilderCards体験会を立ち上げ、得られた気づき / 20260225 Masaki Okuda
shift_evolve
PRO
1
150
ソフトウェアアーキテクトのための意思決定術: Create Decision Readiness—The Real Skill Behind Architectural Decision
snoozer05
PRO
27
7.6k
AIで 浮いた時間で 何をする? 2026春 #devsumi
konifar
16
3.4k
Snowflake Night #2 LT
taromatsui_cccmkhd
0
270
Introduction to Bill One Development Engineer
sansan33
PRO
0
380
AI活用を"目的"にしたら、データの本質が見えてきた - Snowflake Intelligence実験記 / chasing-ai-finding-data
pei0804
0
820
Featured
See All Featured
The innovator’s Mindset - Leading Through an Era of Exponential Change - McGill University 2025
jdejongh
PRO
1
110
Large-scale JavaScript Application Architecture
addyosmani
515
110k
Marketing Yourself as an Engineer | Alaka | Gurzu
gurzu
0
140
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.4k
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
1
1.9k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
1k
Tell your own story through comics
letsgokoyo
1
830
How to train your dragon (web standard)
notwaldorf
97
6.5k
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
63
53k
The Spectacular Lies of Maps
axbom
PRO
1
570
Code Review Best Practice
trishagee
74
20k
The Mindset for Success: Future Career Progression
greggifford
PRO
0
260
Transcript
エンジニアでも論文が 読みたい! Honahuku
アドプラットフォーム事業部/ アド・プロダクト部/ 広告なんでもチーム エンジニア Honahuku
今回話さないこと • 論文の読み方 • 具体的な研究のいろは・進め方
今回話すこと • エンジニアリングと研究の似ているところ • エンジニアリングに活かせるアカデミックなアプローチ • 私の活用事例
研究,やってますか 私は最近全然できてません
研究ってなんだよ • 事業会社でエンジニアをしながら研究をしている人は多 くないと思う • しかしエンジニアリングに研究の考え方が生きることが ある
エンジニアリングの手法 • 技術選定 ◦ 他社の事例や業界動向など複数の要素から意思決定 • 新環境の負荷試験 • ポストモーテム・プレモーテム •
課題解決
研究の手法 • 技術選定 ◦ 他社の事例や業界動向など複数の情報を収集 • 新環境の負荷試験 • ポストモーテム・プレモーテム •
課題解決 先行研究の調査 実験 結果考察 研究目的
研究のモチベーション • 研究とエンジニアリングは似ている点もあるが、異なる 点も多い • 仮に同じ目的があったとしても『研究』と『エンジニア リング』はアプローチが異なるはず
アカデミックなアプローチ • 論文というフォーマット ◦ 序章(背景)、手法、実験、考察、結論 ◦ 論文を読み、ディスカッションを重ね、検討し、より 良い案を提案する
アカデミックなアプローチ • 信頼度と情報ソース ◦ 単なる妄想は学問とは言えない ◦ 知識の積み上げ(先行研究)、情報ソースは重要
なぜ Honahuku は 論文を読むのか
自分の領域へ普段と違う 切り口から切り込むと嬉しい
何が嬉しいかというと 論文という別角度のデータソースから より理解を深めることが出来る
何が嬉しいかというと • why に切り込んだ背景知識を得られる • 関連する課題や手法へのインデックスを貼れる • 局所最適な手法に囚われすぎない
Honahuku のケース • 属人性が高くなんとなくで動いているインフラへの 問題意識 • プロダクトの可用性だけでなく可観測性と回復力を 高める取り組みを考えていた
論文紹介 • MS の SRE に関する論文 ◦ インシデント検知の問題点 ▪ モニターの不足によるインシデントの対応遅れ
▪ 不要なモニターによるオオカミ少年なアラート ◦ サービスに対する監視を分析し、改善手法の実証実験を 行った[ganatra2023] • [ganatra2023]: Detection is better than cure: A cloud incidents perspective, https://doi.org/10.1145/3611643.3613898
監視とインシデント対応 • モニターの不足はインシデント対応遅れや連鎖的な障害発 生に繋がる • 検出までの時間(Time to Detect)は シグナルやアラートが欠落していると最大 •
障害対応時間(Time to Mitigate)はモニター についてのドキュメントに欠落・誤りがある と伸びる
カスケード障害 • DBが停止するインシデントが発生したとする ◦ エンキューに時間がかかりジョブが詰まる ▪ DB停止に気づけてもキューのスタック検知のアラート が無ければ障害時間の増加がありえる ▪ システムの全容を把握している人や経験豊富な人は気
付ける可能性が高い
カスケード障害 • DBが停止するインシデントが発生したとする ◦ エンキューに時間がかかりジョブが詰まる ▪ DB停止に気づけてもキューのスタック検知のアラート が無ければ障害時間の増加がありえる ▪ システムの全容を把握している人や経験豊富な人は気
付ける可能性が高い そうでない人は?
モニターの見直し • モニターは過去の障害発生を元に追加されてきた ◦ 場当たり的なモニター追加は欠落や重複を招くのでは? • 賢いモニタリングフレームワークはモニター追加や重複削除 の提案をしてくれそう ▪ インシデントを学習(ML)させて提案に使う
Honahuku のケース • 属人性が高くなんとなくで動いているインフラへの 問題意識 • プロダクトの可用性だけでなく回復力と可観測性を 高める取り組みを考えていた
チームへの適用 • 同じように不要なモニターが無いか、見落としているメト リクスは無いかを洗い出し • 残った必要なモニターに対してアラートロジックとドキュ メントに誤りが無いかを確認することをPJに盛り込む
チームへの適用 • 同じように不要なモニターが無いか、見落としているメト リクスは無いかを洗い出し • 残った必要なモニターに対してアラートロジックとドキュ メントに誤りが無いかを確認することをPJに盛り込む 論文を元にした対応方針の検討
アカデミックなアプローチで より快適な エンジニアリングライフを!