[初参加 🔰] SRE NEXT 2025 参加レポ [手書き100%]

primeNumber という会社で SRE をやっている中村です。
SRE NEXT 2025 に参加してきました。SRE NEXT はオンライン含め初参加でした。個人的に面白かったセッションを弊社の課題と照らし合わせたりしながら紹介します。

セッション

SRE不在の開発チームが障害対応と向き合った100日間

https://speakerdeck.com/shin1988/100-days-dealing-with-issues-without-sres

ログラスさんでの CS からのインシデント対応に関するフィードバックをきっかけにプロジェクトを立ち上げてインシデント対応の改善を行った話でした。
インシデントコマンダー候補を何人か選出してその人たちのスキルアップを行う、フロー整備、社内発信などのアプローチで改善を行っていました。また、インシデントを定量的にとらえて、インシデントコマンダー業務の定型化と自動化を行っていました。インシデントマネジメントの SaaS Waroom を導入したり Runbook を整備するなどといったことを行っていました。
ビジネスサイドとの対話が活発な印象を受け、日頃からの対話があったからこそ CS からのフィードバックもあったのかなと勝手に想像しました。
これからは、専任インシデントコマンダーが Enabling していくような形でメンバーへの展開をしていきたいとお話されていました。

SREチームの越境と対話〜どのようにしてイオンスマートテクノロジーは横軸運用チームの廃止に至ったか〜

https://speakerdeck.com/aeonpeople/the-cross-border-and-dialogue-of-sre

イオンスマートテクノロジーさんの SRE チームにおける越境と対話をテーマにした様々な取り組みをお話されていました。
個人的に印象に残ったのは "だっしゅぼーどを眺める会" と "SLI/SLO 策定のためのワークショップ" です。
だっしゅぼーどを眺める会は、その名の通り New Relic のダッシュボードを開発チームと見る会です。オブザーバービリティツールは開発チームが使いこなすことが大事だということをお話されていて、使いこなし促進のための会として実施されていたようです。ただ、それだけではなく、課題棚卸しやタスク共有、アイスブレイクなどの場にもなっていたとのことでした。
SLI/SLO 策定のためのワークショップは、エンジニアとビジネスチームが参加する SLI/SLO 策定ワークショップのことです。みんなで New Relic を見ながら SLI/SLO について考えたそうで、New Relic の方にも強力していただいたみたいです。結果として、エンジニアとビジネスでの考え方の違いが分かった、ビジネスサイドから SLI/SLO の提案をしたいというようなフィードバックがあったようです。
すばらしい取り組みをされており、マネしたいなと思うことが多く、とても勉強になりました。

モニタリング統一への道のり - 分散モニタリングツール統合のためのオブザーバビリティプロジェクト

https://speakerdeck.com/niftycorp/sre-next-2025

ニフティさんでは顧客向けシステムとカスタマーサポート向けシステムの複数システムをもっており、その中でそれぞれのシステムごとに監視ツールが異なっていた中で存在したいた課題を解決した話です。
課題として学習コスト、運用コストの問題、ノウハウ共有が難しい、監視実装に統一性がないことが挙げられていました。モニタリングツール統一先の候補として Grafana + Prometheus、Datadog、Amazon CloudWatch、Azure Monitor の4つを比較して Azure Monitor で統一したそうです。自分は Azure Monitor は初めて聞いたのですが DCR という機能が便利なのかなという印象を受けました。
弊社でもモニタリングツールを複数利用していて、規模が違うながらも近しい課題を持っており、このセッションは気になっていたのですが、10分という短い時間だったため詳細な内容が聞けなかったのが残念でした。弊社は AWS を中心に利用しており、Azure は利用していないので Azure Monitor は候補に入ってこないのですが、新たな知見を得られて勉強になりました。

対話型音声AIアプリケーションの信頼性向上の取り組み ~ Webアプリケーション以外でどうSREを実践するのか ~

https://speakerdeck.com/ivry_presentationmaterials/dui-hua-xing-yin-sheng-aiapurikesiyonnoxin-lai-xing-xiang-shang-noqu-rizu-mi

IVRy さんの音声対話 × AI のプロダクトでの、LLM API と WebSocket、そして SLI/SLO 運用についての話です。
LLM API の運用では1タスクを分割して処理する AI workflow と名づけられていたシステムや E2E テストによるハルシネーション抑制を行っていました。LLM API の不安定さに対応するためのアプローチとしては複数の LLM API を利用した fallback を実装していました。また、その時点で完璧な賢い LLM を使う必要はないためユースケースにあったモデルを選択しているとお話されており、それができるのは AI workflow を実装しているからこそだということでした。
SLI/SLO の運用における難しさとして以下の3点を挙げていました。

• 音声対話システムではユーザー体験が主観的なものになり定量化がしづらい
• 会話失敗の原因がインフラの問題、AI の回答が上手くいってない、音声認識の問題など複雑になる
• 通常の Web アプリケーションとは異なり1リクエスト1トランザクションというわけではない

これに対して、ユーザーの目的達成を阻害する要因を考え、システム要因と対話要因の2つをに切り分けて考えたそうです。
通常のアプリケーションとは異なる点が多いプロダクトのため、とても興味深い内容が多く面白かったです。弊社も LLM API をプロダクトに組み込んでいるので、非常に参考になる内容でした。

〜『世界中の家族のこころのインフラ』を目指して”次の10年”へ〜 SREが導いたグローバルサービスの信頼性向上戦略とその舞台裏

https://speakerdeck.com/kohbis/towards-the-next-decade-enhancing-global-service-reliability-through-sre

MIXI さんの "家族アルバム みてね" における AWS マルチリージョン構成移行における取り組みやコスト最適化についての話です。
海外ユーザー増加に伴い、地理的な要因でレイテンシー悪化の課題が出てきたため、マルチリージョン構成へ移行したそうです。
インフラの様々なレイヤーごとに適切な構成をとり、ユーザー体験に直結する機能にフォーカスして改善を行うことで、ユーザー体験向上とコスト最適化の両方を実現しており、非常に高い技術力があることを感じました。
弊社プロダクトは海外展開しており、AWS マルチリージョン構成なのですが、ビジネス的な要件などからインフラを構成する基本的なコンポーネントは全てそれぞれのリージョンに構築してあります。ただし、今後この構成が変化していく可能性は少なからずあると思うので、その時は MIXI さんのアプローチを参考にさせていただきたいと思いました。

アクセスピークを制するオートスケール再設計: 障害を乗り越えKEDAで実現したリソース管理の最適化

https://speakerdeck.com/myamashii/akusesupikuwozhi-suruotosukeruzai-she-ji-zhang-hai-wocheng-riyue-ekedadeshi-xian-sitarisosuguan-li-nozui-shi-hua

マネーフォワードさんでの KEDA を使ったイベントをトリガーにした Pod スケール導入の話です。
オンプレ VM から EKS への移行の際に、過去データを元にリクエスト数と CPU 使用率に相関があると考察して、CPU 使用率を閾値に設定した HPA を導入していました。しかし、アクセスのピーク時に想定通りにスケールしない問題が発生したそうです。この時の反省ポイントとして、将来的にボトルネックになるシステム的なメトリクスは変化する可能性があったことを挙げていました。
この課題に対して、cron などによる静的スケーリングとリアルタイムでの変動に対応できる動的スケーリングの比較検討などをされていました。そして、最終的に KEDA によるリクエスト数でのスケールの導入を行っていました。KEDA ではリクエスト数と CPU 使用率の2つのメトリクスでのスケールを行うようにしていました。CPU 使用率を引き続き採用した理由として以下2点を挙げていました。

• リクエスト数で捉えきれない負荷への対応
• リクエスト数をとっている Datadog ダウン時のフェイルセーフとすることで可用性を上げる

Memory 使用率は GC により不規則に変動するもので、予測性や信頼性に欠けるため採用しなかったとのことです。
弊社のプロダクトでは同じく EKS を採用しており、スケジュール実行により同じ時間帯に Job が大量に作成されます。この時、大量の Node の急速なスケールが必要になるですが、この対策として静的スケーリングを採用しています。スケジュール実行なので予測可能な部分が多いのですが、このスケール方法には改善の余地があります。今後この辺りを改善していくにあたり、マネーフォワードさんの改善のアプローチは参考になりそうです。

さいごに

初の SRE NEXT、色々勉強になることが多く、参加して良かったと思いました。今回の学びを積極的に業務で活かしていこうと思います。

TROCCO を開発する primeNumber では、一緒に信頼性向上を実現してくれる SRE を絶賛募集中です！
信頼性向上が選ばれる理由になる、裁量の大きいSRE【データ分析基盤総合支援SaaS TROCCO®/地方フルリモート有】
SREの知見を全社横断で適用し、組織の信頼性を高める Corporate SRE