はじめに
先週末SRE Next 2025に参加して「久々に対外的にアウトプットするか」と思い記事を書き始めました。（ついでに会社に出す報告レポートも兼ねよう・・・）
余談ですが、久々に記事を書くにあたり、最近Zennも流行ってるし、どっち使おうかなと思いつつアカウント持ってたQiitaで書くことにしましたが、Zennを使い始めるかどうかはこれから考えます。
印象的だったセッション
SRE不在の開発チームが障害対応と向き合った100日間(Day1)
「システム障害の教科書」に則り、ベストプラクティスを導入したらどうなったかについて詳しく紹介されました。
自分たちではうまくいっていると思っていた障害対応も外から見れば改善ポイントが多数。コミュニケーションや平時の準備が十分ではなかったとのこと。
まずは、専任メンバーとインシデントコマンダーを兼任で体制づくりからはじめ、インシデント対応練度の向上と定量的なモニタリングから始めた流れとうまくいったこといかなかったことについて説明いただきました。
これから体制づくりをやっていく自分に取ってはどのように進めていくのが良さそうか、他社事例が聞けて良かったのと、障害時のコミュニケーションの大切さを感じました。
システム障害の教科書は読み直します。
対話型音声AIアプリケーションの信頼性向上の取り組み ~ Webアプリケーション以外でどうSREを実践するのか ~(Day1)
電話の自動応答サービスを展開しているIVRyでは電話での会話というSLI/SLO導入が難しい場面に対してどう導入を進めたかについて紹介いただきました。
LLM APIが不安定な中、信頼性向上のため様々な安全策を投入されています。複数のLLMを併用したり、DatadogのInferred servicesを利用して外部サービスの監視をおこなったりされていました。
また、SLI/SLOの導入は音声対話システムには難しく、Webサービスと異なりセッションベースでの設計が必要だったとのこと。システム的Anomalyと対話的Anomalyに分類し、それぞれでSLI/SLOを導入することで計測可能性を高めていった。
普段仕事ではWebサービスばかり関わっているので、別の観点からのSLI/SLOについての議論がなされていて新しい発見だった。とはいえ、結局SLI/SLOを決める方法としては、ユーザー体験が損なわれないようにするという点で同じなのでそこは忘れないでおきたい。
すみずみまで暖かく照らすあなたの太陽でありたい(Day2 Keynote)
ヨドバシにおける信頼性=Service Reliability Engagementの話。
オンサイトプライベートクラウドと呼ばれる、自社データセンター内で自社向けに提供しているクラウド環境の話をされました。オンプレとは異なりきちんと拡張性やオンデマンド性を担保して提供しているとのこと。
Google Cloudで定義されているデプロイアーキタイプに則り、リージョンもしくはマルチリージョンで提供しているとのこと。この構成のおかげでオンコール対応はほぼなく、いつでもアクセスできる(いつ行っても欲しいものが置いてあるお店)を実現している。
ヨドバシをAmazonにちょっと対抗した単なる小売と侮っていましたが、やってることはAmazonそのもの。
後々のAWSと同じようにさくらのクラウドに次ぐ、国産クラウドとしてサービス提供を目論んでるんじゃないかと思うレベルでした。
オンコール対応がほぼほぼ無いように設計するのは簡単ではないと思いますが、詳しい話をまたどこかで聞きたいなと思いました。
（家に帰ってオンサイトプライベートクラウドの話をしたら「それオンプレやん」って言われてきちんと否定できたのは良かったです）
ABEMA の本番環境負荷試験への挑戦(Day2)
サービスの成長に伴いシステムが複雑化したAbemaが都度都度負荷試験環境を用意するのは容易ではなかったため、本番環境を使って負荷試験をおこなった話をされました。
k8sを使っていたため、同じクラスタ内に別のNode/Podをカスタムリソースを使って自動構築し、istioで負荷試験用のルーティングを設定して負荷試験を実施。もちろんDBも本番DBを利用しているため、書き込みリクエストはなく読み込みリクエストのみ試験ではおこなわれていました。
負荷試験ツールはk6を利用し、DB含め性能チェックを随時おこない、少しでも性能が下がると停止するような仕組みも導入されています。
負荷試験環境を都度都度用意するのは大変なので、どのようにおこなわれているのかすごく参考になりました。
本番環境で負荷試験をすることで、リリース時のエンジニアの安心感やコストダウンなども得られており、「本番環境で負荷試験なんて・・・」と思わずにどの企業でもぜひ導入していってもらいたい思想でした。
とはいえ、事前の根回し(コミュニケーション)がすごく重曹で段階的に本番環境を使うことへの周囲の不安をなくされていったのは印象的でした。
ARR150億円、エンジニア140名、27チーム、17プロダクトから始めるSLO(Day2)
信頼性が課題となったときには巨大なサービス/組織になりすぎており導入に苦労した話です。
SmartHRリリース当初は労務担当者のみ使われるサービスだったので、24/365での信頼性は不要だったが、新しいプロダクトも始まり信頼性の向上が必須となったとのこと。
最初、SLOをシンプルにイネイブリングのみおこなうようにしてきたが、うまく回らず。会社の成長のためには新機能開発が優先され、改善に手をつけられていなかった。
大規模障害が発生し、SLOを設定しておけばうまく対処できたのかも？という考えから社内にSLO文化が根付いていった。
大規模障害があると組織は動くというのを体現された話でした。
個人的にはもっとSLI/SLO導入してうまくやってる感じの会社だったので少し驚きました。
障害は起こってほしくないですが、障害きっかけでもSLO文化が導入されて、それがうまく文化として入り込んでいるのですごいなと思いました。
その他
スポンサーブース
スポンサー企業のブースがありました。SREに関するアンケートに答えるとノベルティをもらえたり、システム構成図を公開されていたり、各企業のSREとしての活動状況について会話したりと楽しかったです。
アンケートブース
意外とNewRelicが少ない！！！！（Grafanaより少ない！）
まとめ
実際のSREを運用している人の声が聞けて、具体的にどうやっていけばいいのかみたいな想像が膨らみました。
技術技術したカンファレンスと違って、手法？みたいな情報が多かったのでより自身のチームに取り入れやすい話が多く、直近のSREの活動でもうまく取り入れていきたいなと感じました。
とりあえず「システム障害対応の教科書」を読み直します。
最後に
資料をまとめてくださってる方がいるので感謝しつつリンクを張っておきます。
https://zenn.dev/r4ynode/articles/srenext2025-documents