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
Honahuku
October 17, 2024
Technology
0
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
54
KubeCon + CloudNativeCon Japan 2025 に行ってきた! & containerd の新機能紹介
honahuku
0
160
「改訂版ブルーム・タキソノミー」を利用したソフトウェアドキュメンテーションの改善手法の提案
honahuku
0
560
Kubernetes のクラスタ内ネットワーク概要
honahuku
1
52
大規模コンピューティングを支える Kubernetes のネットワーク
honahuku
0
270
今から始める分散システム
honahuku
0
320
SecAd~Ad data drivin’ network security~
honahuku
0
200
Other Decks in Technology
See All in Technology
Bill One 開発エンジニア 紹介資料
sansan33
PRO
4
14k
AIとともに歩んでいくデザイナーの役割の変化
lycorptech_jp
PRO
0
840
「最速」で Gemini CLI を使いこなそう! 〜Cloud Shell/Cloud Run の活用〜 / The Fastest Way to Master the Gemini CLI — with Cloud Shell and Cloud Run
aoto
PRO
1
170
事業開発におけるDify活用事例
kentarofujii
5
1.4k
AIエージェント入門 〜基礎からMCP・A2Aまで〜
shukob
1
170
オブザーバビリティと育てた ID管理・認証認可基盤の歩み / The Journey of an ID Management, Authentication, and Authorization Platform Nurtured with Observability
kaminashi
1
290
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
20k
Databricks AI/BI Genie の「値ディクショナリー」をAmazonの奥地(S3)まで見に行く
kameitomohiro
1
400
SCONE - 動画配信の帯域を最適化する新プロトコル
kazuho
1
320
SQLAlchemy の select(User).where(User.id =="123") を理解してみる/sqlalchemy deep dive
3l4l5
3
320
あなたの知らない Linuxカーネル脆弱性の世界
recruitengineers
PRO
3
150
Zephyr(RTOS)にEdge AIを組み込んでみた話
iotengineer22
1
320
Featured
See All Featured
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
36
6.1k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Designing Experiences People Love
moore
142
24k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
Mobile First: as difficult as doing things right
swwweet
225
10k
Facilitating Awesome Meetings
lara
57
6.6k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Build The Right Thing And Hit Your Dates
maggiecrowley
38
2.9k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.6k
Building Adaptive Systems
keathley
44
2.8k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.7k
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に盛り込む 論文を元にした対応方針の検討
アカデミックなアプローチで より快適な エンジニアリングライフを!