SRE NEXT 2023にオフラインで参加してきた

はじめに

keiです.

はてなブログを作成してからほとんど投稿してなかったのですが,SRE NEXT 2023に参加して学びが多かったので書いていこうと思います.

今年に新卒SREとして会社に入社してから初めてのオフラインイベントかつ,初めてのSRE関連のイベント参加でしたが非常に学びもありつつ,楽しんで参加できました.

参加したトラック

自分が参加したトラックは以下になります.

  • 11:00 - 11:20 TrackC LINEスタンプのSREing事例集:大量のスパイクアクセスを捌くためのSREing Twitter(X)
  • 11:30 - 11:50 TrackC 備えあれば患いなし:効率的なインシデント対応を目指すSREの取り組み Twitter(X)
  • 12:00 - 12:20 TrackA エンジニアのためのSRE論文への招待 Yuuki Tsubouchi
  • 13:10 - 14:00 TrackA 【コミュニティコラボ企画】パネルディスカッション 〜信頼性に関わる、ご近所さんが集まりました〜 青山 真也草間 一人,岡本 宗之
  • 14:15 - 14:35 TrackA 開発者がインフラ設計や運用に参加したら信頼性が上がった話~CloudWatch Evidently~ 上田 璃空
  • 14:45 - 15:05 TrackC プロダクトオーナーとしてSLOに向き合う。Mackerelチームの事例 渡辺 起
  • 15:15 - 15:35 TrackA SLOを組織文化にするための挑戦 〜 Biz/Dev/SREが一丸で進めるSLOジャーニー 〜 金城 佑治
  • 15:50 - 16:10 TrackA ブルームバーグのセントラル・テレメトリー・システムが業務にもたらす価値 兪 雪蕾,Dardan Fejza
  • 16:20 - 16:40 TrackB エラーバジェット運用までの取り組み - 信頼性の低下に対するアクションを定義しよう 佐々木 優太
  • 16:50 - 17:10 TrackB 開発者とともに作る Site Reliability Engineering 近藤 健司
  • 17:20 - 18:00 TrackA 信頼性目標とシステムアーキテクチャ山口能迪

どれもためになる内容ばかりでした.事前に聴いてみたいセッションをリストアップしていたのですが,当日はかなりの人が参加していて,早めに席を取っていないと前の方で聴けない事が多々合りました.先にリストアップしておいてよかったです.

SRE NEXT 2023 Schedule

発表の感想

LINEスタンプのSREing事例集:大量のスパイクアクセスを捌くためのSREing

LINEのあけおもLINEのスパイク対応に関する発表でした.日本・台湾・タイでスパイクの時間差があるのは知らなかったです.

本番環境のインスタンスを減らして高負荷の状態を再現し,LINEスタンプのマイクロサービスごとの処理性能を確認するアプローチは興味深かったです.こういう方法もあるんだなぁと思いましたね.

備えあれば患いなし:効率的なインシデント対応を目指すSREの取り組み

自分が最近インシデント対応するために色々準備をしているので,個人的に気になっていました.インシデントの重大度をSecurity Levelsで定義して誰でも簡単に判定できるように,シンプルな表現にすることはとても勉強になりました.またAWS Resilience Hubというサービスを知らなかったので,調べたいなと思いました.

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

個人的に一番気になっていたセッションでした.去年まで大学の研究室でk8sクラウド関連の論文を読んでいたので,SRE論文というタイトルですぐにこのセッション聞きたい!と思いましたね.

ずっとGoogle Scholarから適当に検索して探していたので,カンファレンスから論文を探すアプローチは地味に実践していませんでした.以下でカンファレンスを一覧してくれたのはありがたいです.

https://gist.github.com/yuuki/60b768fcb6bdf3f3552ee59f5a9e4972

【コミュニティコラボ企画】パネルディスカッション 〜信頼性に関わる、ご近所さんが集まりました〜

こちらのセッションはオフライン限定でした.Cloud Native Days,Platform Engineering,DevOps Dayの運営メンバーがSREとの関連性について議論する感じでした.

個人的に印象に残っているのは,多様なセッションを行うために,運営メンバー側でも多様なメンバーを入れることを意識している点でした.自分はイベントの運営などはしたことはないのですが,運営メンバーは立ち上げ人とその友達で固まっているという偏見が少なからず合りました(すいません...).大きなイベントになってくると,そういうことも意識しているんだなぁと思いました.またCFPはどなたでも応募してほしいとのことです.今回SRE NEXTにオフラインで参加して自分も発表をしてみたいと思ったので,とりあえず出してみようかなぁ?と考えることができたセッションでした.

CNDT2023のプロポーザルに応募したいなぁ

開発者がインフラ設計や運用に参加したら信頼性が上がった話~CloudWatch Evidently~

ユーザへ価値を早く届けるためにDevOpsを実践した話です.開発者がインフラ参加をしていくためにはTerraformなどによるIaC化やコンテナ移行は有効なんだぁと改めて実感したセッションでした.自分は今年に新卒のSREとして入社をしましたが,こういう文化ができつつあったのはこの辺のおかげなのかなぁと思いました.

プロダクトオーナーとしてSLOに向き合う。Mackerelチームの事例

こちらは株式会社はてなのMackerelのSLOを定義した際のセッションでした.最近SLOサービスレベル目標の輪読会を社内で主催しているので,色々勉強になるセッションでした.はてなのSREがSLIにと仮の値のたたき台を作ってとりあえず始めてみたのは「すげぇ,流石はてなのエンジニア...」と思いました.そして信頼性を数値化するのは難しんだなぁ,しかもユースケースによるからなおさら難しい.

SLOを組織文化にするための挑戦 〜 Biz/Dev/SREが一丸で進めるSLOジャーニー 〜

ビジネスサイドも巻き込んでSLOの導入をして至ったのはすげぇと思いました.またビジネスサイドに合わせた資料作りや,逆にビジネスサイドに頼ったワークショップを設計したのも面白いと思いました.エンジニア以外を巻き込むのは難しいと思いますが,それを実践したのはなかなかできることじゃないですし.

ブルームバーグのセントラル・テレメトリー・システムが業務にもたらす価値

世界で展開しているだけ合って規模感が桁違いだと思ったセッションでした.昨年の処理したデータ量は3000億と聞いてあぁもう桁が違うと思いましたね... メトリクスやログなどを収集しているGrand Unified Telemetry System(GUTS)を初めて聞いたのですが,OSSではなく社内の独自システムですかね?ブルームバーグが処理するデータ量が桁違いだから作られたシステムなのかな?と気になりましたね. 調べたら以下にGUTSの発表と論文が合ったので後で見てみようと思います. Managing User Requests With the Grand Unified Task System (GUTS)

エラーバジェット運用までの取り組み - 信頼性の低下に対するアクションを定義しよう

エラーバジェットの重要性と運用をするための他チームとの合意形成が大変だなと思ったセッションでした.エラーバジェットを定義してもチームごとに障害判定がバラバラになってしまうので,そこを乗り越えるためのハードルが多い,定義したSLOがサービスの成長とともに合わなくなってくるのでUpdateも必要になるので,それも他チームとの合意が必要そう?と思うとやっぱり大変だなと聞きながら思いました.

最後の「エラーバジェットの運用は関係者との合意形成の旅」というスライドが↑で疑問だった内容をまとめてくれました.

開発者とともに作る Site Reliability Engineering

開発チームとSREチームの交換短期留学は面白いなと思いました.開発チームからSREチームに来た人がKubernetes ClusterのUpgradeを完遂したのは震えました(すごすぎて...).ただ他チームの文化を体験するためにも短期留学はやってみたいですね.

信頼性目標とシステムアーキテクチャ

SRE NEXTの最後のセッションはGoogle 合同会社の山口さんでした.個人的には,上でも書いたように社内でSLOサービスレベル目標の輪読会をやっているので,その翻訳者のセッションは絶対に聞きたい!!と思っていたので聞けてよかったです.つかみに「実践 住宅ローン申請」というタイトルのスライドが出てきたのは笑いました.というか山口レベルでも住宅ローンの審査って厳しのかと場違いながら思ってしまいました...

最初の方の説明でユーザ目線から見てCPU使用率が高かろうが,ユーザに機能が提供できていれば問題ないという話を聞いて去年までやっていた学部の研究を思い出しました.自分の研究の提案手法をCPU使用率で評価しようとしましたが,レビューのときに「ユーザに高速でレスポンスできているのにCPU使用率が高いと何が悪いの?」と言われました.当時の自分はSLOやエラーバジェットなどの単語が聞いたことがなかったので,CPU使用率が高いから減らさなきゃだめだろと思ってしまっていましたが,SREとして色々勉強してくるとあのときは正しかったと思いました.

ただレイテンシに関してもDashboardで見えるレイテンシとユーザから見えるレイテンシは違うと山口さんがおっしゃっていたので,いやーユーザ目線にたったSLOを定義するのは難しいなと改めて思いましたね.

まとめ

今年新卒として入社してから初めてのオフラインのイベント参加でしたが,自分にとって非常に刺激になるイベントでした.SREとしてまだまだ未熟ですが,こういったイベントにはどんどん顔を出していきたいなと思いました.またチャンスがあるならCFPにも出して自分も発表をしていきたいですね.

とりあえず頑張るぞー!

ジョブボード

余談

初めて九段下に来たので,靖国神社でお参りしました.最近良くない事が起きるので参拝と厄除けのお守りも買わせていただきました.

初ブログ

初めに

はじめまして!私は都内田舎の情報系大学に通っているkeiです。現在研究室に配属されたばかりの学部3年です。主にクラウドKubernetesについて研究しています。

なぜブログを始めた?

ブログを始めたきっかけはアウトプットするためです。研究室に配属されてからインプットの量が多くなり、パンク寸前でした。そのため、少しでもアウトプットをするために、ブログを開設しました。

どういった記事を書く?

主にIT関係を記事にしていきたいと考えています。特にITは独特の単語が多いため、自分がインプットした単語を後で振り返ってもわかりやすく書いて行きたいと思っています。

最後に

ブログを書くのは初めてではありますが、よろしくお願いします!