giantneco’s blog

技術メモ

SRE NEXT 2024 参加してきた

8/2, 8/3 に行われていた SRE NEXT 2024 に参加してきたのでそれの感想など。

SRE NEXT 2024 について

SRE NEXT は今年で 4 回目の SRE に関するイベントで、同じく SRE に関する勉強会の SRE Lounge が中心なって開催している。

自分はこれが 2 回目の参加で、最後の参加は 2022 の回。動画のみ視聴だったせいかあまり記憶に残っていない。 今回は久しぶりに現地参加ということもあってか結構影響を受けることができたのではないかと思う。

参加したセッション

Reliable Systems through Platform Engineering

キーノートではSRE を導入するにはどこから始めるか、またどのような指標を持つべきか、という話がメインだった。

印象的だったのは最初に提示された「99.99 を 99.9 の上に達成することができるか」というお題。 最初にはできないと考えてたが、提示されたように RAID のことなどを考えると確かに達成できるなという感想だった。

どこから SRE 始めるかとして次の順序でやるとよいと紹介されていた:

  1. SLO,エラーバジェットを可視化
  2. 振り返り
  3. 定期的な振り返りのレビュー
  4. リスク評価と優先順位付け
  5. 信頼度のためのバックログ作成

ここらへん自分の組織でどの程度できているかな? SLO のダッシュボードはあるが、それが活用できているかはあやしい。 そもそも開発チーム側からフィードバックはあまりない気もする。

またDORA 指標を紹介していた。

  • 速度に関する指標
    • Deploy 頻度
    • 変更にかかる時間
  • 安定性に関する指標
    • 変更失敗率
    • 復旧にかかる時間

この指標はあまり意識していなかった。こういうのも意識するべきか。

工学としてのSRE再訪

このセッションは工学的あるいは学術的な見地から SRE をどのように扱うかという話だった。

論文をさがしてみるか、という気になったのでこのセッションはかなり感謝がある。

また印象にのこった言葉として書籍からの引用であるが「ウェブオペレーションは技芸であって科学ではない」というのがあった。 実際自分としても一部の指標を勘と経験、度胸(よくいう KKD)で決めることもあるので、なるべく「科学」側に倒したいというのはあったりする。

工学からの貢献として以下のものが紹介されていた。

  • 信頼性の予算化(=エラーバジェット?)
  • オブザーバビリティ
  • 開発生産性の指標
  • 開発組織の設計

このあたりのアイディアが工学から来ているのはちょっと以外だった。

また工学から見た SRE のオープンチャレンジとしてつぎの問題が挙げられた。

  • オオカミ少年アラート問題
  • トレースデータがほとんど参照されない問題
  • インシデント対応の改善がなかなかできない問題
  • インシデント対応がソフトウェアで扱えていない問題

ココらへんは SRE あるあるという感じである。

いくつか論文も紹介されていたのでこれから目をとおしていきたいところだが、 まず SREcon に目を通すといいらしい。

おすすめされていたトピックはつぎのようなもの:

  • Gray Failure
  • Cross-system interaction Failures
  • A policical Scientist's Insights
    • "Only Complexity Can Reduce Complexity"
  • Measuring Reliability Culture
  • Irones of Automation
    • 人間を排除して自動化するほど、人間に高度なスキルを要求する皮肉
    • また自動化システムが人間の能力不足を隠蔽してしまう新しい皮肉
  • Process Feeling
  • Controlling the Costs of Coordination

DevSecOpsの内回りと外回りで考える持続可能なセキュリティ対策

セキュリティ対策の話。 ここでの内回りはShift Left 戦略で、一方外回りは運用でのセキュリティ対応している。

比較すると、内回りは低負担・非網羅的、外回りは網羅的だが高負担となる。 連携としてはまず外回りからはじめてある程度落ち着いたら内回りに着手というのがよいとこのこと。

宇宙科学研究所の探査機運用システムにおけるSREのプラクティスの導入と月着陸実証機SLIMでの利用

Isas/Jaxa で、探索機運用システムや月着陸時のモニタリングに SRE のプラクティスを導入したという話。

Grafana の見慣れた画面で宇宙船のモニタリングをしているのには素直に驚いた。

この手の組織に Grafana とか OSS を導入するにはやはりそこそこ苦労があったっぽい。

オブザーバビリティのマクロからミクロまで〜あるいはなぜ技術書を翻訳するのか

SLO はボトムアップで設定するか?トップダウンで設定するか? => ユーザに近い方 = トップダウンのほうが良い

マクロレベルではラムズフェルドの4象でいう unkonwn-unkonwn を減らすことが重要。 マクロレベルのオブザーバビリティでは複数のコンポーネントとの関係性、他のシグナルとの関連付け、また長期的な観点で分析可能であることが必要となり次のようなシグナルが重要になる:

  • 分散トレース
  • メトリクス
  • ログ
  • 継続的プロファイル

一方ミクロ側では確実に信頼性を担保したい。つまり known-known を確実にして、knwon-unknown を減らしたい。

そこで TFBO フロー(test -> fix -> benchmark -> optimiazaiton) が重要となる。

またミクロレベルでも SLO が必要( RAER (Resource-Aware Efficiency Requirements) といったもの)

ところで詳解システム・パフォーマンスでタイムスケールと紹介されいたものが、効率的な Go ではナプキン計算と紹介されているらしい。 どういう経緯でそうなったのかわからん。

のようにおおよそのコストを把握するのも重要。

SLO を満たせなくなったら

SLO を満たせなくなったらどうするか?

対応例:

  • カナリアリリース
  • マルチリージョン化
  • SLO の見直し

やるべきなのは

  • incident を理解する
  • ポストモーテム
  • リスク分析

incident の影響については次の指標を使うのが役に立つ:

  • ETTD = Estimated Time To Detection
  • ETTR = Estimated Time To Resolution
  • ETTF = Estimated Time To Failure

また障害時に対応できる playbook を作っておくのが理想

徹底的な自動化とトイルの撲滅で実現する効率的なSREの実践例

mixi の SRE は embedded + central の形式

対象は webサイトで、運用方針として少人数のため徹底的に自動化、割り切りができる。

実践していること

  • Iac (Teffafrom + in house tool)
    • モジュール化、テンプレート化
  • モノレポ
    • CI/CD 効率化
  • 脆弱性対応
  • モニタリング・アラート
  • 障害対応

500万人が利用する「友達と遊べるたまり場アプリ パラレル」におけるデータベース基盤の継続的改善

パラレルでの構成は CLB -> Rails -> Sidekiq -> CloudSQL という流れ。

  • クエリの処理づまりで全体に影響があるよりも個別にタイムアウトするほうが良い
    • サーキットブレーカー導入
    • クラウドメンテナンス中の API エラー

サーキットブレーカーのテスト -> toxiproxy コネクションプーリングプロキシ -> vitess

SREの技術トレンド2024

このセッションは公開の予定はないのであんまり詳しく書かないほうがいいのかな?

話題として LLM の話が多かった。

SRE における LLM の活用例として障害対応の slack スレッドを AI に要約させるというのがあった。 これにより後から参加する人も障害の対応状況に追いつきやすくなる利点がある。 (これは試してみたい

また LLM は要約、分類が得意なので、ポストモーテムやラベリング、将来的には障害対応訓練などに使えるかもしれないという話があった。 ただやはり LLM をワークフローに組み込めないといいサービスができないのではという話もされていた。

他の話題として:

  • SRE のトレンドを追いかけるなら SREcon America をみるとよい
  • SRE のトレンドとして incident management 関連の話が多い
  • 分散トレーシングはゴミ

という話があった。 あと SRE のプラクティスがサービス化されるなら将来的に今の職は危ないのかも。

敵対的SRE: 300個のジョブをAIチーム全員で支える技術

AI を提供する企業での大量かつ重さもそれぞれな学習ジョブが走っている環境で SRE を導入した話。

ここでの「敵対的」は GAN からの流用で SRE と AIチームとのフィードバックループのこと。

単純なアラートから、詳細化、スロージョブを検出するための SLO の設定、ジョブの軽重による SLO の適用方法変更をフィードバックループをまわして適用していったとこのこと。

まとめとしてはチームと SRE が互いに学習しながら成長するのが良く、一方的に設定するのはアンチパターンである。

個人的な感想

感想としては SRE 一般のトピックが多かった印象で、あまり個別の技術要素についてはふれられていなかったかもしれない。 これは社内の情報になるのでパブリックに出せないのも仕方ないのかも。

また現在コスト関連の作業をしているのでそのあたりの話も聞きたかったが全然話題になってなかった。 これはどちらかというと AWS 関連の勉強会で話題になることなのでしかたないかもしれない。

その他:

  • 会場に wifi がなかったのでメモを取るのに苦労した。
  • 久しぶりの現地参加というのもあるが、メモをとる環境がイマイチできていない気がする。
    • notion にしろ scrapbox にしろネットにつながっていないと使えないので…
    • メモを取るときは実のところ図を書くことはなくほぼテキストですませているので、
    • obsidian と dropbox あたりをうまいこと組み合わせてメモを同期できるようにするのがよいかもしれない。

個人的な TODO

  • 論文探してみる
  • SRECon 2024 の発表に目を通してみる