Slide 1

Slide 1 text

エンジニアでも論文が 読みたい! Honahuku

Slide 2

Slide 2 text

アドプラットフォーム事業部/ アド・プロダクト部/ 広告なんでもチーム エンジニア Honahuku

Slide 3

Slide 3 text

今回話さないこと ● 論文の読み方 ● 具体的な研究のいろは・進め方

Slide 4

Slide 4 text

今回話すこと ● エンジニアリングと研究の似ているところ ● エンジニアリングに活かせるアカデミックなアプローチ ● 私の活用事例

Slide 5

Slide 5 text

研究,やってますか 
 私は最近全然できてません


Slide 6

Slide 6 text

研究ってなんだよ ● 事業会社でエンジニアをしながら研究をしている人は多 くないと思う ● しかしエンジニアリングに研究の考え方が生きることが ある

Slide 7

Slide 7 text

エンジニアリングの手法 ● 技術選定 ○ 他社の事例や業界動向など複数の要素から意思決定 ● 新環境の負荷試験 ● ポストモーテム・プレモーテム ● 課題解決

Slide 8

Slide 8 text

研究の手法 ● 技術選定 ○ 他社の事例や業界動向など複数の情報を収集 ● 新環境の負荷試験 ● ポストモーテム・プレモーテム ● 課題解決 先行研究の調査 実験 結果考察 研究目的

Slide 9

Slide 9 text

研究のモチベーション ● 研究とエンジニアリングは似ている点もあるが、異なる 点も多い ● 仮に同じ目的があったとしても『研究』と『エンジニア リング』はアプローチが異なるはず

Slide 10

Slide 10 text

アカデミックなアプローチ ● 論文というフォーマット ○ 序章(背景)、手法、実験、考察、結論 ○ 論文を読み、ディスカッションを重ね、検討し、より 良い案を提案する

Slide 11

Slide 11 text

アカデミックなアプローチ ● 信頼度と情報ソース ○ 単なる妄想は学問とは言えない ○ 知識の積み上げ(先行研究)、情報ソースは重要

Slide 12

Slide 12 text

なぜ Honahuku は 論文を読むのか

Slide 13

Slide 13 text

自分の領域へ普段と違う 切り口から切り込むと嬉しい

Slide 14

Slide 14 text

何が嬉しいかというと 論文という別角度のデータソースから より理解を深めることが出来る

Slide 15

Slide 15 text

何が嬉しいかというと ● why に切り込んだ背景知識を得られる ● 関連する課題や手法へのインデックスを貼れる ● 局所最適な手法に囚われすぎない

Slide 16

Slide 16 text

Honahuku のケース ● 属人性が高くなんとなくで動いているインフラへの 問題意識 ● プロダクトの可用性だけでなく可観測性と回復力を 高める取り組みを考えていた

Slide 17

Slide 17 text

論文紹介 ● MS の SRE に関する論文 ○ インシデント検知の問題点 ■ モニターの不足によるインシデントの対応遅れ ■ 不要なモニターによるオオカミ少年なアラート ○ サービスに対する監視を分析し、改善手法の実証実験を 行った[ganatra2023] ● [ganatra2023]: Detection is better than cure: A cloud incidents perspective, https://doi.org/10.1145/3611643.3613898

Slide 18

Slide 18 text

監視とインシデント対応 ● モニターの不足はインシデント対応遅れや連鎖的な障害発 生に繋がる ● 検出までの時間(Time to Detect)は シグナルやアラートが欠落していると最大 ● 障害対応時間(Time to Mitigate)はモニター についてのドキュメントに欠落・誤りがある と伸びる

Slide 19

Slide 19 text

カスケード障害 ● DBが停止するインシデントが発生したとする ○ エンキューに時間がかかりジョブが詰まる ■ DB停止に気づけてもキューのスタック検知のアラート が無ければ障害時間の増加がありえる ■ システムの全容を把握している人や経験豊富な人は気 付ける可能性が高い

Slide 20

Slide 20 text

カスケード障害 ● DBが停止するインシデントが発生したとする ○ エンキューに時間がかかりジョブが詰まる ■ DB停止に気づけてもキューのスタック検知のアラート が無ければ障害時間の増加がありえる ■ システムの全容を把握している人や経験豊富な人は気 付ける可能性が高い そうでない人は?

Slide 21

Slide 21 text

モニターの見直し ● モニターは過去の障害発生を元に追加されてきた ○ 場当たり的なモニター追加は欠落や重複を招くのでは? ● 賢いモニタリングフレームワークはモニター追加や重複削除 の提案をしてくれそう ■ インシデントを学習(ML)させて提案に使う

Slide 22

Slide 22 text

Honahuku のケース ● 属人性が高くなんとなくで動いているインフラへの 問題意識 ● プロダクトの可用性だけでなく回復力と可観測性を 高める取り組みを考えていた

Slide 23

Slide 23 text

チームへの適用 ● 同じように不要なモニターが無いか、見落としているメト リクスは無いかを洗い出し ● 残った必要なモニターに対してアラートロジックとドキュ メントに誤りが無いかを確認することをPJに盛り込む

Slide 24

Slide 24 text

チームへの適用 ● 同じように不要なモニターが無いか、見落としているメト リクスは無いかを洗い出し ● 残った必要なモニターに対してアラートロジックとドキュ メントに誤りが無いかを確認することをPJに盛り込む 論文を元にした対応方針の検討

Slide 25

Slide 25 text

アカデミックなアプローチで より快適な エンジニアリングライフを!