トップ > SRE > エンジニアのためのSRE論文への招待 - SRE NEXT 2023

エンジニアのためのSRE論文への招待 - SRE NEXT 2023

SRE 論文

この記事では、2023年9月29日に開催されたSRE NEXT 2023 IN TOKYOでの講演の概要に加えて、講演では触れられなかった部分の補足と、発表を終えての後記、最後にSRE NEXT全体の感想を書きました。

SRE NEXT 2020の基調講演に招いていただいたところから始まり、昨年のSRE NEXT 2022の公募セッションでも発表し、今回で3回目の発表になりました。今回の講演は、SRE NEXTの「NEXT」と価値観の一つである「Diversity」を踏まえて、自身のエンジニアと研究者の両方の経験を活かして、SREを深く実践する上で、技術論文を探して読むアプローチを提示するものです。昨今の国内のSREコミュニティでは組織的実践に主な関心が移っている状況と対比させて、コンピュータサイエンスに基づく技術的挑戦の可能性を示唆する意欲的な講演を目指したつもりです。

この講演での主要な論点は、エンジニアコミュニティでたびたび共有されている既に普及したあるいは普及中の技術の論文（既普及技術論文、著者による独自用語）を読む話ではありません。普及していないアイディアが提案されている技術論文（未普及技術論文、著者による独自用語）と、技術的挑戦に関心のある優れた実装力と適用力をもつエンジニアをマッチングさせることです。すでに普及した技術の「理解」ではなく、未普及技術の「開発」のための論文へのアプローチの可能性をこの講演で提案しています。

エンジニアが論文を読む動機

この講演では、エンジニアが論文を読む動機こそが最も伝えたいメッセージであるため、講演では触れられなかった話も含めて改めて述べておきます。

最近10年ほどで、SREの周辺技術は海外を中心にマネージドサービスやOSSとして展開されてきました。メガクラウド事業者による高度なインフラ技術のサービス展開、CNCF、Hashicorpなどの団体・企業による高度なインフラ技術のOSS展開、運用技術（Observability、インシデント管理など）のSaaS展開などです。その結果、それ以前は夢のように語っていた技術の一部を現実的な努力の範囲で使用できるようになってきました。

エンジニアリングは技術に閉じるものではなく、開発組織の成熟により向上させられるため、開発組織にいかにSREのプラクティスを導入していくかが、直近数年でコミュニティでの主要な議論になりました。このようなムーブメントは、英語圏の資料で度々みられるようになってきた”Sciotechnology”と呼ばれる概念で説明できるものです。このようにSREが社会技術としての成熟しつつあることは喜ばしいことです。

しかし、社会技術の「社会」と「技術」の両面が成熟していく中で、日本国内では、SREに携わるエンジニアが自ら技術を開発する挑戦機会は良くも悪くも以前より減少していると長年感じています。特に、自分のように国内のパブリッククラウド事業者に所属する者としては、技術を自ら開発していくことは会社の課題でもあります。会社の課題でなかったとしても、エンジニア個人として技術を開発していきたい欲求をもつ人にとっては個人の課題とも言えるかもしれません。

このような背景から、自分は以前から論文や研究というものに関心を寄せていました。ブログ記事「インフラエンジニア向けシステム系論文」を公開したのは９年前のことです。インフラエンジニアが取り扱う、OS、データベース、ネットワークなどの要素技術に関する論文を紹介する記事です。当時のエンジニアコミュニティで一定の反響がありました。

同時期に、若手インフラエンジニア現状確認会と呼ばれたイベントがあり、そこでも論文を読んでいきたいと話をしていたのを覚えています。当時若手として今後のキャリアを考えるなかで、例えば、データベースを作るような研究開発に近いキャリアもあるんじゃない？といった話をした気がします。振り返ってみると、要素技術を作るキャリアは難しかったものの、SREという社会技術（Sociotechnology）の範疇で研究開発というキャリアを今は歩んでいます。今回の講演では、その当時の自分が聞きたかった話をしていたのかもしれません。

そこから9年経過し、論文を読むことに興味を持っている、あるいは読んでいるエンジニアは少なくないことを観測しています（エンジニアが論文を読んでいる一例 engineers-reading-papers.md）。少なくとも工学系の論文は最終的には実務家がその論文に書かれた知を活かすことを想定して書かれているはずなので、エンジニアが論文を読むことは不自然なことではありません。

エンジニア仲間への事前のヒアリングによると、エンジニアは既に普及している新技術の歴史やなぜその技術が登場しているのか、内部の動作機序などを知りたいと考え、論文に興味をもったとのことでした。@rrreeeyyyくんの5年前のIOT研究会の招待講演 Web サービスの信頼性と運用の自動化について では、エンジニアリングを「ちゃんとやる」ことの一環として、論文を読むことの意義が述べられていました。ここで例として挙げられている論文は、大手クラウドベンダーや有名なOSSの要素技術を提案する論文です。

講演内ではこの類の論文を既普及技術論文と呼びました。既普及技術論文と比べて、圧倒的に論文の数が多いのは、未普及技術論文です。自分が研究者として普段読んでいる論文のほとんどはこの未普及技術論文です。未普及技術論文の中にもおもしろい論文が多数眠っており、これらの論文にはもっと可能性があるのではないかと考えています。しかし、これらの論文の著者はおそらくなかなか社会実装する時間がとれなかったり、あるいは使いやすい形で技術を提供するノウハウがなかったりすることもあるはずです。

そこで、アイディアはなかなか思いつくのが難しいが自分で技術を作ってみたいエンジニアと、社会実装されない未普及技術論文をマッチングさせたいと考えました*1。ソフトウェアエンジニアは必ずしも情報科学系の大学・大学院で学んでいるわけではなく、むしろ国内の情報系学科・研究科の入学定員数を考慮すると少数派でしょう。また、大学院で研究した経験があっても、その経験をエンジニアとしての活動に繋げて考えることは多くはないのではないでしょうか。

ただし、マッチングさせるのはよいとして、SREが興味をもつ未普及技術論文はどうやって探すのか、論文を見つけたとして情報系の論文に馴染みのないエンジニアが論文をどうやって読むのかを伝える導線のようなものが必要だと考えました。そこで、この講演では、エンジニアがアイディアを探すための、SRE分野の未普及技術論文に着目した、論文の探し方と読み方を紹介しました。

具体的な探し方や読み方については、後述のスライド資料、参考文献や国際会議リストを参照してください。研究目的での探し方と読み方と比べて基本の方針や使うツールに大きな差があるわけではないため、特に情報科学系の大学院で研究経験のある方はSRE固有の探し方のみを拾っていただければ十分な内容になっています。

学術論文について

スライドでは学術論文がどのようなものかを示すピクチャをMatt Might, The illustrated guide to Ph.D.のイラストを借りて説明しています。論文とは人類の未知領域を開拓し、既知領域をわずかでも押し広げた証としての文書だと考えています。人類の未知領域だと大げさに思えるのであれば、工学では未解決領域といった呼び方のほうが馴染みやすいかもしれません。実際の問題に例えれば、トレーシングのサンプリングによる情報量の欠損とストレージへ負荷増大のトレードオフの解決法は未解決領域といってよいでしょう。これは@egmcさんと懇親会で実際に話をしていた問題です。

このようにエンジニア同士で普段会話されている未解決の問題に対して、論文では解決のアイディアが提示されていることがあります。もちろん、そのアイディアはエンジニア目線でみれば実績が全く無かったり、限定的な状況でしか有効でないこともありますが、これはすごく大きなことです。未解決領域を進むことは解決済みの領域に敷かれた高速道路を進んでいくこととはわけが違い、暗闇のなかを手探りでゆっくり進んで安全な道筋に灯火を置いていくようなものだからです。未解決領域に近づくほど光が少なくなっていくため、高速道路から徐々に獣道のようになっていきますが、光があるのとないのとでは全く違います。この光を手がかりにして、どうすればよくわからないような問題に自分でアプローチできる可能性があるのが未普及技術論文の良さだと考えています。

未普及技術論文を実装・適用するときの困難

講演中にはほとんど述べられませんでしたが、光があるとはいえ暗闇に近い道のりは険しいものです。あるかないかわからない論文を探す負荷、自分が知らないことが書いてある論文を読む負荷、詳細のわからない手法の再現実装をする負荷、論文に書かれているような結果が再現しない再現性問題など高い不確実性の壁が待ち受けているかもしれません。だからこそ少ない光でも自分のもつ問題や興味に沿う道を発見する目を鍛える必要があり、それが論文の探し方や読み方の習得に繋がっていくと考えています。

また、この文脈では、未普及技術論文のアイディアを完全に再現する必要は必ずしもありません。アイディアの一部のみを再現したり、あるいはより自分の問題に沿った別のアイディアに派生させたほうが都合がよいこともあるでしょう。

スライド資料

当日使用したスライドと講演動画を以下に公開しています。当日は、20分発表の都合上、ググればわかることは該当スライドの右上にスキップ帯をかけていましたが、公開版では帯を外しています。

今後、プロポーザルを投稿される方への参考のために、プロポーザル文書を以下に公開しています。

SRE NEXT 2023 Proposal

紹介したSRE関連の国際会議

yuuki/sre-related-conferences-list.mdにSRE関連の国際会議を30+個ほど列挙しています。この中でも、Fieldの欄にSoftware Engineering/Cloud Computing/Reliabilityのいずれかを含む会議がSREらしいトピックを扱う論文が特に多いと経験的に感じています。とはいえ、SREを中心に据えた国際会議はないので、1会議1開催あたり1,2個興味のある論文を発見できればよい程度の期待値をもって探すとよいと思います。

講演中にはさらっと紹介しましたが、このリストを作るにもそれなりの年月がかかっています。既存のコンピュータサイエンス分野ならすでに誰かがリストを作ってくれたりしていますが、SREの括りでは自分が作るしかなかったからです。

査読なしのオープンジャーナルにarXivがあります。特にAI分野の論文はまずarXivに投稿されることが非常に多いです。SRE関連はAIOpsを除きAI分野と比べてarXivに投稿されている論文は少なく、査読を通過しているかどうかは品質に一定の保証を与えるため、arXivの論文は読まなくてもよいように思います。後日どこかの会議や論文誌に採録されてから読んでも遅くはないでしょう。

紹介したツール

  1. Google Scholar / Google Scholar Alert
  2. Connected Papers
  3. Paperpile
  4. Readable
  5. Obsidian

SRE論文の例

Googleの可用性指標

  1. Hauer, et al., “Meaningful Availability”, NSDI 2020.

プロダクションのインシデントの分析

  1. Wu, et al., An Empirical Study on Change-induced Incidents of Online Service Systems, ICSE 2023.
  2. Ghoso, et al., How to Fight Production Incidents? An Empirical Study on a Large-scale Cloud Service, SoCC 2022.

分散トレースのサンプリング問題を解決するMLモデル

  1. Huang, et al., Sieve: Attention-based Sampling of End-to-End Trace Data in Distributed Microservice Systems, ICWS, 2021.
  2. Las-Casas, et al., Sifter: Scalable Sampling for Distributed Traces, without Feature Engineering, SoCC, 2019.

eBPF由来のメトリクスをコンテナの配置戦略や性能解析に使用

  1. Neves, et al., Black-box Inter-application Traffic Monitoring for Adaptive Container Placement, SAC, 2020.
  2. Amaral, et al., MicroLens: A Performance Analysis Framework for Microservices Using Hidden Metrics With BPF, CLOUD, 2022.

メトリクスから合成されたSLOを用いた動的スケーリングフレームワーク

  1. Nastic, et al., SLOC: Service Level Objectives for Next Generation Cloud Computing, IEEE Internet Computing 24(3).
  2. Pusztai, et al., SLO Script: A Novel Language for Implementing Complex Cloud-Native Elasticity-Driven SLOs, ICWS, 2021.
  3. Pusztai, et al., A Novel Middleware for Efficiently Implementing Complex Cloud-Native SLOs, CLOUD, 2021.
  4. Nastic, et al., Polaris Scheduler: Edge Sensitive and SLO Aware Workload Scheduling in Cloud-Edge-IoT Clusters, CLOUD, 2021.

LLMを用いた障害の原因診断やログ分析

  1. Ahmed, et al., Recommending Root-Cause and Mitigation Steps for Cloud Incidents using Large Language Models, ICSE 2023.
  2. Gupta, et al., Learning Representations on Logs for AIOps, CLOUD 2023.

主要な参考文献

  1. rrreeeyyy, ”Webサービスの信頼性と運用の自動化について”, 情報処理学会第40回インターネットと運用技術研究会 招待講演, 2018年.
  2. Matt Might, The illustrated guide to a Ph.D.
  3. 小野田 淳人, “博士課程の誤解と真実 ー進学に向けて、両親を説得した資料をもとにー“, 2018年.
  4. 論文の種類の違い, 2008年.
  5. 論文の種類と位置づけ.
  6. 品川 政太郎, ”論文の読み方・書き方・研究室の過ごし方 - NAIST”, 2020年.
  7. 落合 陽一, ”先端技術とメディア表現#1 #FTMA15”, 2015年.
  8. 本多 倫夫, ”システム系論文の読み方と探し方”.
  9. joisino, ”論文読みの日課について”, 2023年.
    1. Keshav, “How to Read a Paper”, ACM SIGCOMM Computer Communication Review, 2007.
  11. mmi, ”システム系論文の情報収集方法”, 2020年.

発表を終えて

以前からできる限り自分にしかできない話をしようと思っていて、今回もおそらく自分らしい発表ができたのではないかと思います。ひさびさに20分枠で話ましたが、分量の調整には苦労しました。他のネタも検討しましたが、その中でもSREコミュニティでコンテキストをより共有しやすいものとして、論文の世界に招待する話に帰着しました。

今回の講演に対して、現地で具体的なフィードバックをいただくことは少なかったですが、論文を毎週1本読んでみようかなとか、最近のSRE論文のトレンドはなにか？といったコメントや質問をいただけました。一方で、記事の冒頭でも説明した、未普及技術論文を読む動機こそが最も伝えたい主張でしたが、その主張に対してSNSも含めてコメントはありませんでした。うまく伝えられなかったのか、あるいは自明だったのか、期待とは違ったのかはわかりません。そもそも今回の不確実性の高い提案に現実的に取り組める環境やスキル、モチベーションをもつエンジニアの数は僅かではあると思います。いずれにせよ、コミュニティの中で長い目で取り組んでいくものだと考えています。

今後はSRE LoungeのSlackワークスペースの#sre-paperなどで情報共有をしていきたいです。早速、講演中に紹介したMeaningful Availability論文を読んでの感想を書いてくださっている方もいらっしゃいます。僕が博士号を取得できたら、AIOps研究も含めて活動の幅を広げていきたいと思っています。また、さくらインターネット研究所で、この講演の内容を含む研究開発を一緒にやってみたい方はぜひyuuk1までご連絡ください。

カンファレンス全体を通して

参考になった講演

はてな時代に長く上司としてお世話になったwtatsuruさんのプロダクトオーナーとしてSLOに向き合う。Mackerelチームの事例です。この発表のメッセージは、「エラーバジェットを使い切ったときに、プロダクトの責任者に開発速度と信頼性のどちらを優先するかの意思決定を求めることにするとよい」であると理解しました。SLO違反時のアクションは開発を停止することであると言われているものの、プロダクト開発の事情はそのときどきで変化します。変化により適応するには、意思決定内容を事前に決めるのではなく、意思決定すべき条件（SLO）だけを決めるのがよいのでしょう。

次は、@ymotongpooさんの基調講演 信頼性目標とシステムアーキテクチャーです。決められた信頼性目標からその目標に適した分散システムアーキテクチャやオペレーションを導出する方法が語られていました。職人の直感だけに頼らない工学的な設計手法です。アクセス数などの想定ワークロードを基にシステムやデータ構造を設計することはよくやっていましたが、SLO駆動のシステムの設計法を意識的に考えたことはなかった気がします。研究としてももっと深く掘っていけそうなポイントを発見できました。

Topotalブース

副業先のTopotalによるスポンサーブースが非常に賑わっていました。今回展示していたWaroomは2年以上ディスカッションさせてもらっているSREのためのSaaSプロダクトです。賑わっていたり引き合いがあると聞くと一緒に喜べるのは嬉しいですね。

最後に

東京で開催されるイベントへのオフライン参加は3年半ぶりでした。SNSでは以前から見知っていたがはじめてお会いする方々やコロナ禍以降お会いできていなかった方々に挨拶や雑談ができてうれしかったです。

カンファレンスは当たり前に開催されるものではないはずなので、運営スタッフの皆さまには大変感謝しています。ジョブボードやスタンプラリー、コーヒースポンサーなど現地会場を盛り上げるための様々な仕掛けや、オンラインと現地会場にハイブリッドで配信する技術など、ハイクオリティでとてもよいカンファレンスだったと思います。コミュニティとしてSREを盛り上げていけるように自分も取り組んでいきたいと思っています。

*1:ただし、論文のアイディアが特許取得済みのケースに注意すること。特許が取得されていると、実装の公開や商用環境での使用に制限がある場合がある。