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

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

このような背景から、自分は以前から論文や研究というものに関心を寄せていました。ブログ記事「インフラエンジニア向けシステム系論文」を公開したのは9年前のことです。インフラエンジニアが取り扱う、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.
  10. 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:ただし、論文のアイディアが特許取得済みのケースに注意すること。特許が取得されていると、実装の公開や商用環境での使用に制限がある場合がある。

Googleが数千台もある10年前のLinuxディストリをライブアップグレードした話

Googleが、太古のディストリビューションであるRed Hat 7.1から、10年新しいDebianベースのディストリビューションへ、ライブアップグレードした話を紹介する。 そのあと、自分の身の回りの環境と比較し、参考にすべきポイントを考察する。

原文は USENIX LISA の投稿論文だ。しかし、中身は論文体というよりは、事例の紹介といった適切かもしれない。

MERLIN, M. Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One. In Proceedings of the 27th conference on Large Installation System Administration (LISA) (2013), pp. 105–114

ペーパーのPDFが Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One | USENIX にて公開されている。 LinuxCon Japan 2013で、同テーマの発表があり、発表資料は http://marc.merlins.org/linux/talks/ProdNG-LC2013-JP/ProdNG.pdf にて公開されている。

この文章は、原文の邦訳では決してなく、自分が理解しやすいように組み立てなおした文章であるため、誤りないし誤解を生む可能性がある。正しい記述を知りたいのであれば、原文を参照してほしい。

概要

Googleでは太古のディストリであるRed Hat 7.1を独自パッチを重ねて10年間運用してきた。

Googleのサーバでは、アプリケーションはルートパーティションの外側のchroot jail環境で動作するため、ルートパーティションの変更がアプリケーションに影響しない。 これまで、Red Hat 7.1のゴールデンイメージのファイルをルートパーティションへ同期することにより、パッケージを更新してきた。

この方法は長い間驚くほどうまくいっていた。しかし、永久にアップグレードを延期するわけにはいかない。実際、モダンなシステム上でパッケージをビルドできないなどの問題があった。

そこで、DebianベースのProdNGという新しいディストリビューションへ移行することにした。 ProdNGは以下のような特徴をもつ。

  • セルフホスティング
  • ソースから完全にリビルドする
  • すべてのパッケージは不要な依存を取り除かれる (xml2, seLinux library, libacl2など)
  • upstart、dbus、plymouthなど複雑なものを取り入れない
  • 小さければそれだけ同期や再インストール、fsckが速くなる
  • 新しいパッケージが常に優れているわけではない。ときには古いもののほうがよいこともある
  • 隔離されている。新しいパッケージをビルドするたびに、ProdNGのchroot jail環境を作り、ビルドツールをインストールする

ProdNGへの移行の手順は以下のようなものだ。これらはOSの再起動なしに実施されている。

  1. ProdNG上でビルドしたDebianパッケージをRPMへ変換する
  2. 現行のRed HatディストリからX Serverやfonts、localesやman pageのような不要なパッケージの削除
  3. 現行ディストリのlibc 2.2.2から、ProdNGのlibc 2.3.6へのアップグレード
  4. chroot jail環境でスクラッチからビルドされた約150パッケージのアップグレード ProdNGと現行Red Hatイメージの両方に配置
  5. 現行Red HatイメージにしかないRPMをdebパッケージに変換 alien(1)と独自のchangelogコンバータの組み合わせ
  6. ここまでで、ProdNGが現行Red Hatイメージと同様に動作するようになったため、リグレッションテストをパスして、手動レビューしたのちにProdNGをデプロイする

これらの手順は、一言でいうと、本番環境で2つのディストリを並行して運用することなく、常に均一な状態を保って、新しいディストリに移行している。各ステップで数千台のホストを均一な状態に保つことは、非常に手間がかかり、全工程を数年かけてやり遂げた。

トピック

前節でペーパーの概要をまとめた。ここでは、概要から省いた、いくつかの興味深いトピックを紹介する。 これらのトピックに加えて、実際の移行時のトラブルや泥臭いlibcアップグレード方法など、興味深いトピックはいくつかある。

前提環境

Googleの本番Linuxはカーネル・デバイスドライバ、ユーザスペース、アプリケーションの3レイヤで管理されている。

カーネル・デバイスドライバはディストリビューションからは切り離されていて、頻繁に更新される。 このレイヤは別のチームがメンテナンスしており、今回の話には関係がない。

各アプリケーションはchroot jail環境で動作する。このjailはアプリケーションの動作に必要なすべてのプログラム、共有ライブラリ、データファイルを含む。

残りのユーザスペース部分は、initスクリプト、/usr/binバイナリなどだ。 OSのパッケージシステムはこの部分にのみ使われる。ペーパーでフォーカスしているのはこの部分になる。 1~2人でメンテナンスされているらしい。

(※ペーパーのタイトルに数千台のサーバとあるが、Googleのサーバはもっと多いはず。どのセクションのサーバの話なのかは書かれていなかった。)

従来のパッケージアップデート

最初期には、sshループでインストール・アップデートコマンドを走らせていた。 sshループは実行に時間がかかり、失敗するホストもあり、スケールしない。 一般的に、プッシュベースの手法は失敗するように運命付けられている。

次に、cronでapt-get/yumを実行した。だいたい期待した更新はできた。 しかし、数千台のサーバでapt-get/dpkg/rpm/yumを走らせていると、ランダムで失敗することがある。 更新中に再起動やクラッシュすると、パッケージデータベースが壊れた。 パッケージデータベースが壊れなくても、設定ファイルがコンフリクトしたり、パッケージアップデートによりホストを予期しない状態になったりなどの多くの問題があった。

ファイルレベルのファイルシステム同期ならば、どの状態からでもリカバーできて、パッケージマネージャーに依存しなくなる。 各サーバを均一に保ち、サーバ固有のパッケージと設定ファイルは同期するエリアの外に置く必要がある。 各サーバはサーバ固有ファイルのリスト(ネットワーク設定やresolve.conf、syslogなど)を持ち、リスト内のファイルは同期からは除外される。 ホスト全体にマスタイメージからrsyncするのはサーバ側(※おそらくマスタイメージを保有する中央サーバ)がスケールしない。 さらに、特定のファイルが変更されたときに、デーモンが再起動するためのトリガーが必要だ。

そのため、独自のrsyncライクなソフトウェアを書いた。基本的に、マスタイメージから全ホストへファイルレベル同期を行う。適切にシェルトリガーを設定できる。I/Oはスロットリングされるため、各ホストの負荷に影響はない。 (※ rsyncライクなソフトウェアとは、おそらく、多数のサーバへ同期をかけられるように、クライアント側を効率化したようなものではないか。各ホストでサーバソフトウェアが起動していて、マスタイメージを保有するホスト上のクライアントプロセスが各サーバへ接続し、ファイル同期を行う。これをrsyncでやると、1つのサーバに対して1つのクライアントプロセスを毎回起動することになり効率が悪い。)

ただし、この手法は各ホストが均一な状態である必要がある。前述のようにルートパーティション外のchroot jailにアプリケーションをデプロイしているからこそできるといえる。

このファイルレベルの同期はProdNGディストリの更新にも用いらている(はず)。ProdNGの場合は、マスターイメージがパッチを重ねたものではなく、毎回クリーンな環境でスクラッチでビルドされたイメージとなる。

どのディストリビューションがよいか

Debianは標準のRed Hatに比べて、多くのパッケージをもつ。(昔のRed Hat 9が1500パッケージで、当時のDebianが15000パッケージ。今日のFedore Core 18が、13500パッケージに対してDebian Testingが40000パッケージ。) Ubuntuは、upstartやplymouthのようなオプションでもなく、信頼もできないいくつかの複雑さを強制される。

ディストリのInitシステムについても、以下のような議論がなされている。

  • Sysv: /etc/rcX.d/Sxxdaemonのようなシーケンシャルなブートがわかりやすい。しかし、遅い。
  • Upstart: シンタックスが完全に異なる(シェルよりはよい)。ブート順の保証がない。何かがおかしかったらデッドロックすることがある。場合によっては、upstartは再起動を要求する状態に陥ることがある。デバッグが難しい。
  • Systemd: 大きな混乱をもたらす。Linuxシステムのブートの大きな再設計。Linuxの低レベルな多くのコア部分を置き換える。自動で依存関係を計算してくれるという理想に反して、手動な依存関係の解決が要求される。Upstart同様にブート順を指定できない。
  • Insserv: 再起動前に、insservは指定された依存を解析して、initスクリプトをS10やS20のようにリネームする。S10以下のすべてのスクリプトは同時に起動し、S20はS10xxのすべてが起動してから起動する。依存関係の可視化とレビューが簡単。ProdNGではこれが採用された。

はてなとの比較と考察

はてなの本番環境のOSはほぼすべてLinuxで、ディストリはCentOS5とDebianが混在している。 数年前からDebianに移行し始めたため、最近のサービスはすべてDebian上で動作している。

とはいえ、まだまだCentOS5のホストが数多く残っており、来年3月のEOLに向けて、今まさに撤退中というステータスだ。

レガシーOSを数多く抱えているという状況は、ペーパーに書かれていたGoogleの状況に近い。 ホスト数のオーダーも同じだ。

大きく異なるのは、レイヤごとに分離していないことだ。(というより一般的には、分離していない環境が多いと思う) はてなの環境では、カーネル、ユーザスペース、アプリケーションが密結合している。 OSをアップグレードしようと思うと、これらすべての変更を意識しないといけない。 特にApache + mod_perl と古いCPANモジュールを新しいOSで動作させるのが課題になっている。

レガシーOSの撤退と一口にいっても、環境により課題は異なり、Googleの事例は特殊にみえる。 どちらかというと、アップグレードの手法よりも、レイヤ別にOSを管理する手法を参考にしたい。 毎回EOLが迫るたびに、すべてをアップグレードするのは現実的とはいえない。

以前に、chrootベースのアプリケーションデプロイを提案 した。 アプリケーションを隔離するという方向性は間違ってないと思う。

マスターイメージのファイル同期による管理は、ChefやAnsibleのようなサーバ構成管理ツールで管理する手法とは大きく異なる。 サーバ構成管理ツールにより、プログラマブルに柔軟な構成ができる一方で、複雑化しやすく、10年もつ仕組みとは言い難い。

そこで、ルートパーティションのみ、ファイル同期で更新して、アプリケーションはchroot jailのようなコンテナで動かす。この手法が、自分の中で長期の運用に耐えやすい手法なのではないかと思えてきた。

あとがき

Googleでさえ、太古のディストリビューションのメンテナンスに苦しんでいる。そして、解決するためにかなり泥臭い方法を選択しているというのは、サーバの構成管理の本質的な難しさが現れているのかもしれない。

手法自体は泥臭い一方で、できるかどうかわからなかったライブアップグレードする技術力があるのはさすがで、既存のディストリにそのまま依存すべきではなくProdNGという新しいディストリをデザインするところもさすがといえる。

やりたいことを実現できる技術力と、長期運用するためにディストリはどうあるべきなのかというビジョンと、レガシーな環境を技術で解決するぞというやっていく気持ちを感じられた。

インフラエンジニア向けシステム系論文

この記事ははてなエンジニアアドベントカレンダー2014の23日目とシステム系論文紹介 Advent Calendar 2014の23日目を兼ねています。

今回は、インフラエンジニア向けにシステム系論文を読むということについて書きます。 ここでいうインフラエンジニアは、Webサービスを作る会社のサーバ・ネットワーク基盤を構築・運用するエンジニアを指しており、はてなではWebオペレーションエンジニアと呼んでいます。 人が足りなくて普通に困っているので採用にご興味のある方はぜひこちらまで。 SRE (Site Reliability Engineer) 職 - 株式会社はてな

はてなでは、id:tarao さんを中心に有志で論文輪読会を定期的に開催しており、システム系論文にかぎらず、言語処理系、機械学習についての論文などが読まれています。 だいたい1人でインフラまわりの論文を読んでいて、インフラエンジニア向けの論文知見が溜まってきたので、紹介したいと思います。

続きを読む

Dockerは速いのか?Dockerのパフォーマンスについて重要なことは何か?

だいぶ前からDocker(Linuxコンテナ)のパフォーマンスについて、速いことは速いだろうけどどの程度速いのか、もし遅いことがあるなら何がパフォーマンスにとって重要なのか(AUFSが遅いとかそういうの)が気になっていたので、今回は

で紹介されていた Docker のパフォーマンス検証に関する IBM の Research Report を読んだ。Report の内容をベースに、Docker のパフォーマンスの勘所などをまとめてみた。 Report のタイトルは An Updated Performance Comparison of Virtual Machines and Linux Containers 。 GitHub にベンチマークコードと実験データが置いてあってちゃんとしてる。

続きを読む

Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて

社内で論文輪読会みたいなことやってて、そこで紹介した論文の内容についてです。

最近、Graphite に保存しているデータのバックアップ(データ同期)に rsync 使ってて、かなり遅いので困ってた。 LISA っていう 大規模システム、sysadmin 系のカンファレンスがあって、ここから論文探してたら、ちょうど巨大データの高速バックアップの実装の話があったので読んでみた。

論文概要

dsync: Efficient Block-wise Synchronization of Multi-Gigabyte Binary Data - https://www.usenix.org/conference/lisa13/technical-sessions/presentation/knauth - Thomas Knauth and Christof Fetzer, Technische Universität Dresden - In Proceedings of the 27th Large Installation System Administration Conference (LISA ’13)

GB単位のデータだと、rsyncがとにかく遅い。 rsync はブロック分割されたデータのハッシュ値の比較により差分検知して、ネットワーク転送するデータ量をとにかく減らそうとしている。 その反面、同期させたいデータサイズに対してハッシュ値計算のCPU時間は線形に増加する。 さらに、ハッシュ値計算のために全データブロックを読み出す必要があり、I/Oコストも高い。 バックアップ時に、差分を事後計算しようとすると、どうしてもこうなる。 そこで発想を変えて、カーネルのブロックデバイスレベルで、更新のあったブロックを常に記録(トラッキング)しておき、バックアップ時にフラグのあったブロックだけを転送することにする。

発想自体はシンプルだけど、既存の device mapper の Snapshot 機能だけでは実現できなくて、パッチをあてる必要があったのがやや難点。 カーネルのメインラインに取り込まれてほしい。

実装はこちら。 https://bitbucket.org/tknauth/devicemapper/ Linuxカーネル 3.2 の device mapper モジュールにパッチを当てるような感じになってそう。

追記 2014/05/26 16:10

それ ZFS でできるよと DRBD でいいのでは系のコメントをいくつかいただきました。 ちなみに論文の本文には両者に関して言及があります。

"どうせブロックデバイス使うなら実績のあるDRBDでいいんじゃないかと思う。非同期モードで。" http://b.hatena.ne.jp/n314/20140526#bookmark-196769866

ZFS について

ブロックデバイスレベルで実現できてうれしい点は、ZFS など特殊なファイルシステムに依存しないことだと思います。 ext3 のような壊れにくいLinux環境で実績と運用ノウハウがある ファイルシステムを使いつつ、差分バックアップできるのは実運用上でうれしいことが結構あると思います。 あとは、ZFS で定期的に差分バックアップとるときに、スナップショット分のディスクサイズオーバヘッドが気になります。(これは論文にも比較データはないのでどれほどかわかりませんが) ちなみに dsync のオーバヘッドは、10 TiB データに対して、320 MiB 程度のようです。(ただしディスクではなくメモリオーバヘッド)

DRBD について

そもそも非同期モードだろうが同期モードだろうが、DRBD はオンラインなレプリケーションには使えても、定期バックアップに使うものではない気がします。 例えば、プライマリノードで、間違えて重要なファイルを rm してしまったときに、即座にセカンダリノードにその rm の結果が伝播してしまうので、データが壊れた時に復旧するためのバックアップ用途には向いてない気がします。

何か勘違いがありましたらご指摘いただけると幸いです。

スライド

Keynote のテンプレートは、Azusa にお世話になっています。

LISA の他の論文

LISA はオペレーションエンジニアにとって興味深い論文が結構ある。 一例をあげてみる。 今回のように実装が公開されてたいたりするので、あんまりアカデミック感がなくてよい。

所感

たまにサーバ管理ツールとか作ってて、サーバ負荷の未来予測とかサービス間のトラッフィク依存関係(AサービスがBサービスのDB引いてるとか)を可視化できたらいいねとか言ってたりしてた。 今回、LISAの論文眺めてたらちょうどそういうのあって驚きがあった。 研究の世界はできないことができるようになる系統の技術において先を行っていて、ブログとかウォッチしているだけでは追いつけないので、たまに論文もよみたい。

カーネルのI/Oシステム周りの知識に乏しいので、詳解Linuxカーネルを読みつつ知識を補填していた。

詳解 Linuxカーネル 第3版

詳解 Linuxカーネル 第3版

  • 作者: Daniel P. Bovet,Marco Cesati,高橋浩和,杉田由美子,清水正明,高杉昌督,平松雅巳,安井隆宏
  • 出版社/メーカー: オライリー・ジャパン
  • 発売日: 2007/02/26
  • メディア: 大型本
  • 購入: 9人 クリック: 269回
  • この商品を含むブログ (71件) を見る

超高速なパケットI/Oフレームワーク netmap について

の続きで,最近論文読んだやつのプロジェクトの紹介です.

概要

今の汎用OSは高速なパケットI/Oを考慮してない.
20年前のAPIをそのまま使っている.
ネットワークがどんどん高速になっているので,NICとかOSカーネルのパケット処理がボトルネックになってる. (http://news.mynavi.jp/news/2013/04/04/094/index.html)

こういうの解決するために既存手法がいろいろある.

netmapはその試みのひとつ.

  • ユーザプロセス-NIC間の効率のよいパケットI/Oフレームワーク
  • 汎用的な10Gbps環境で14.88Mppsものスループット
  • 60-65 クロックサイクルでwire - userspace間のデータ移動
  • 標準的なデバイスドライバと比較して10-20倍の性能向上
  • FreeBSDにはもう取り込まれている ([base] Revision 227614)

Usenix ATC'12でベストアワード,SIGCOMM 2011でベストアワードを受賞してるらしい.やばそう.

アーキテクチャ

f:id:y_uuki:20130803161153p:plain

netmapは既存の性能向上手法をいくつか使っている.
NICのパケットバッファの(mmapとかで)メモリマッピング,I/Oバッチング,NICのリングキューとマッチするような送信・受信キューのモデリングなど.

既存のものとは違うのはnatmapを使うユーザプロセスのアプリケーションがOSをクラッシュさせることができないようになっていること.
natmapのクライアントはユーザ空間で動作するため,デバイスレジスタやカーネルメモリポインタにダイレクトアクセスできない.

プログラミングモデルは固定長バッファのリングキューを扱うだけなので非常に単純で,アプリケーションは標準的なシステムコールしか使わない.
(ノンブロッキングioctl()でNICと同期,poll()可能なファイルディスクリプタ)

パフォーマンス

f:id:y_uuki:20130803161216p:plain

netmapはCPUのクロックレートが1GHz以下で10Gbpsの上限に達してる.
pktgen(Linuxのカーネルで動作するパケットジェネレータ)やnetsend(UDPを使ったユーザランドで動作するパケットジェネレータ)よりもかなり高いスループットがでてる.

インタフェース

サンプルコードが書いてあった.
/dev/netmapで開いたディスクリプタに対してioctl()とmmap()でリングキューやバッファのメモリ領域を取得して,NETMAP_xxxなインタフェースでリングに対する操作とバッファの中身を読めるイメージ.

重要なのは,1パケットごとにpollとかするんじゃなくて,リングの複数スロットにまとめて1回のシステムコールを発行するところ.
これにより,パケット単位のシステムコールのオーバヘッドを削減できる.

struct netmap_if *nifp;
struct nmreq req;
int i, len;
char *buf;

fd = open("/dev/netmap", 0);
strcpy(req.nr_name, "ix0"); // register the interface
ioctl(fd, NIOCREG, &req); // offset of the structure
mem = mmap(NULL, req.nr_memsize, PROT_READ|PROT_WRITE, 0, fd, 0);
nifp = NETMAP_IF(mem, req.nr_offset);
for (;;) {
    struct pollfd x[1];
    struct netmap_ring *ring = NETMAP_RX_RING(nifp, 0);

    x[0].fd = fd;
    x[0].events = POLLIN;
    poll(x, 1, 1000);
    for ( ; ring->avail > 0 ; ring->avail--) {
        i = ring->cur;
        buf = NETMAP_BUF(ring, i);
        use_data(buf, ring->slot[i].len);
        ring->cur = NETMAP_NEXT(ring, i);
    }
}

ソースコード

システムコール(ioctl,select/poll)に対するパッチとNICドライバのパッチを除いて,現行バージョンは約2000行程度らしい.
さらに,各デバイスドライバのパッチはそれぞれ500行程度で, デバイスドライバの変更を最小にするために機能のほとんどが各ドライバで共通したコードで実装されている.

デバイスドライバパッチのソースをちょっと読んでみた感じだと,リングキューの初期化処理と同期処理(netmap自前のリングとNIC自体のリング)を書けばよいだけみたいだった. 同期処理はちょっと書くのめんどくさそうだった.

資料

あんまり咀嚼して書けてない.

感想

正直,アーキテクチャについてはよくわからない部分が結構あったけど,サンプルコードみたらだいたいイメージ湧いてきた. もうちょっと既存研究あたったほうがよさそう.

netmapで遊ぼうとおもったけど,持ってるNICがMellanox製で,netmap対応ドライバがまだないからつらい. 自分でドライバパッチ書けってことか…

100Gbpsソフトウェアルータの実現可能性に関する論文

前回のGPUを用いたSSLリバースプロキシの実装について - ゆううきブログ に続いて,同じ研究グループが出している100Gbpsのソフトウェアルータの実現可能性に関する論文を読みました.

Sangjin Han ; KAIST, Daejeon, South Korea ; Keon >Jang ; KyoungSoo Park ; Sue Moon

"Building a single-box 100 Gbps software router" Local and Metropolitan Area Networks (LANMAN), 2010 17th IEEE Workshop on

IEEE Xplore - Building a single-box 100 Gbps software router

論文紹介

現在または予測可能な未来の技術を用いて,100 Gbpsのソフトウェアルータを構築することができるかどうかが考察されています. できるかどうかは明言されていませんが,I/O周りのボトルネックの削減がまだ難しそうという印象でした.

論文では,近年のIntel/AMDの改良されたアーキテクチャ(マルチコアプロセッサ,CPU統合メモリコントローラ,PCI Express,マルチCPUソケット,QPIなど)を用いて,100Gbpsソフトウェアルータを実現しようとするとどこがボトルネックとなるかが書かれています. IPルーティングまでは考えておらず,パケットの送信,受信,フォワーディング性能のみ考慮されています.

具体的には,以下のようなCPUソケット2個,IOハブ2個,2ポートの10GbE NICを6個もつNUMAな構成を例にとり,CPUサイクル,I/O帯域幅,メモリ帯域幅の観点で何がボトルネックとなるかが議論されています.

f:id:y_uuki:20130514233714p:plain

CPUサイクル,メモリ帯域幅については測定値というよりは理論性能を元に考察されていますが,I/O帯域幅については上記構成を単純化したいくつかの構成を用いて,どのリンクがボトルネックかを実験で測定した値を用いて議論されています.

CPUサイクルについては,パケットの動的確保をやめて静的に確保して使いまわすなどいくつかの最適化を施し,なおかつパケットI/O以外のIPルーティングなどの処理をFPGAまたはGPUにオフロードすれば,CPUサイクルはさほど問題にならないということでした.

ちなみに,IPルーティングやIPsecをGPUで高速化する話は下記の論文にあります.

PacketShader - GPU-accelerated Software Router

I/O帯域幅については,PCIeリンクおよびQPIリンクの実効帯域はさほど問題ではないが,マルチIOハブ構成時にIOハブ数にパケットの受信性能がスケールしないようです.IOハブのchipsetがマルチIOに対して最適化されていない?ような感じでした.

(PCIeについてはPCIe 2.0 x8で実効帯域幅が双方向で32Gbps以上なので2ポートの10GbE NICの帯域を損なわない. QPIについては双方向で100Gbpsくらいでるので,一方のノードに受信パケットが偏っていてなおかつそれらのパケットをもう一方のノードにフォワーディングするような状況でなければ,問題ない.)

スライド

詳細については原文または輪講で使用した以下のスライドを参照してください.

補足

論文が書かれた2010年時点ではPCIe 2.0が最新でしたが,現在は "PCIe 3.0"が最新です. 実効帯域幅は約2倍となっています.

感想

どうでもいいですが,論文の3ページ目に"By Googling, we find that …"とか書いてあってお茶目な感じでした.

日本アイ・ビー・エム Intel Xeon Processor X7560 8C 2.26 GHz 24MB Cache 130w 60Y0311

日本アイ・ビー・エム Intel Xeon Processor X7560 8C 2.26 GHz 24MB Cache 130w 60Y0311