はじめに
1/26（日）にSRE Kaigi 2025に参加してきました！
とても活気にあふれていて楽しく、学びがあったので備忘録を兼ねてレポートしたいと思います。
イベント概要
SRE Kaigi 2025のコンセプトを引用すると、
SRE Kaigi 2025は、「More SRE !」をテーマに開催される、SREを中心として知見の共有と参加者との交流を楽しむ技術カンファレンスです。
SREは世界的に注目され続けている領域であり、現場によって抱える課題や取り組みはそれぞれ異なります。
そうした多様な事例から得られた知見を共有する場は、まだまだ不足している現状です。「さらにSREに関わる技術者の活躍の場を増やすため」
「さらにSREを理解し、興味を持っていただける技術者を増やすため」この2つの“More”を目指し、参加者の皆様とコミュニティをより盛り上げていけたらと思います。
とのことで、今回が初めての開催となります。
JR中野駅からほど近い中野セントラルパーク カンファレンスで開催されました。
ナレーションがなんと声優の杉田智和さんが担当する！！というのも話題になりました。
APC ACS事業部からはこちらの4名で参加しました！
すでに小原さん、青木さんがレポートを公開しているので合わせてご覧ください。
セッション以外のところ
スポンサーの各社がブースを出展したり、オライリーの書籍が10%OFFで販売されていたり、というのに加え、
なんと休憩スペースではおでんとたこ焼きの出店があり、おでんをいただいちゃいました！（お酒もありましたが飲んだらイベントが終わると思ったので泣く泣く断念…）
さらに指圧をやってくれるスペースもありました。後半の時間帯にお願いしようかな？と思ってましたが、人と話してるうちにタイミングを逸してしまったので次回に期待です。
スポンサーブースではスタンプラリーが開催されており、参加者とブースが話しやすい場になっていて、シールやポストイットを使ったアンケートでも共感が生まれたりしててとても楽しかったです。
クイズやくじ引きなどもあり、私はスタンプラリーのくじ引きでかなりレアそうなキーホルダーを頂いたので早速カバンにつけました！！
参加したセッション
セッションに参加した感想や学びをサッとご紹介します。
Site Reliability Engineering on Kubernetes（スリーシェイク nwiizoさん）
KubernetesはSREを実践するのに優れた基盤であることを紹介されていました。
最近ではAKSを使っているとAzureのマネージドな機能を使ったり、Observerbility等であればサードパーティのツールを利用することが多くなってきていましたが、
Kubernetesネイティブな機能やカスタムリソースでもいろいろなことができることを改めて気づかされました。
可用性とコストのリバランス：テレビ砲の過負荷へ対応した話と増強したリソースを適正化した話(ブルーモ証券 下村さん)
テレビ砲による想定外のリクエストでサービスが遅延してしまったことを受けて、
最初は安全側に倒してリソースを10倍にし、落ち着いてからはコスト重視で落としどころを探るという他人事に感じない話でした。
偉い人やユーザーが求める「サクサク動く」を具体的に言語化して、それに沿ったキャパシティプランをする、という営みは非常に参考になりました。
サービスローンチを成功させろ！〜SREが教える30日間の攻略ガイド〜 (CyberAgent 松田さん)
サービスローンチの信頼性を高める手法・ツールとしてProduction Readiness Checklist（PRC）のご紹介でした。
リリース直前にチェックしても修正する時間はないので、シフトレフトして可能であれば開発初期からPRCを導入し、チェック項目の対応状況の記録やアクションプランを作成するという営み
インフラコストとセキュリティ課題解決のためのリアーキテクチャリング（Autify 東口さん）
マネージドなサービス・機能を使ってサービス展開をしていましたが、マネージド故の制約（インスタンスタイプ等）によってコストが最適化できなかったり、仕様（オートスケールの仕組み等）が要件に合わなかったので、
比較的自由度の高いEKSに移行して、中でもオートスケールについては要件に合わせた仕組みをLambdaでin-houseで実装してしまったというのは驚きでした。
インフラおじさんがSREになるお話（レバテック 金澤さん、小室さん）
SREが開発チームの内部に入り込めずインフラとモニタリングのの変更・管理するだけになってしまいがちなところを、
アプリケーションチームから選出してアプリケーションチームの内部にEmbedded SREを立ち上げてイネーブリングしていったことで、インフラおじさんから脱却したというお話でした。
組織の壁を上手に乗り越えた一例だと感じました。
個人的には杉田さんのナレーションで「インフラおじさん」というワードが聞けたのが面白かったですｗ
SREじゃなくてもできる！インシデント対応で鍛えたCREチームの5年史（ANDPAD まゆぞーさん、島根さん）
わかる人が属人的な対応をしていたインシデント対応を、サポートとソフトウェアエンジニアの間にCustomer Reliability Engineerとして入り、
やることリストを作って対応を型化したり、ポストモーテムの作成や分析を進めることでプロダクトチームが本当に知りたいことを知ることができるようになったとのこと。
インシデント対応に注力することでインシデントを減らして信頼性を高める基盤を整える取り組みは非常に参考になりました。
2週に1度のビッグバンリリースをデイリーリリース化するまでの苦悩 ~急成長するスタートアップのリアルな裏側~（_KNOWLADGE WORK madoさん）
スタートアップにおいてデプロイ頻度の低さはビジネス競争力にも影響があるため、高頻度にする取り組みです。
モノリスなシステムのままだとリリースタイミングの調整が難しかったり、オーナーシップが不明確な部分があったので、デプロイの独立性を担保するためにサービスを分割する全社プロジェクトを立ち上げるところから始まり、
デプロイ時に全機能がリリースされていたものを分離して頻繁なデプロイを可能にしたり、時間をかけていたQAをE2Eの自動テストを強化することで解消したりと、様々な部分をケアしているところが印象的でした。
Platform EngineeringがあればSREはいらない!? 新時代のSREに求められる役割とは（メルカリ 渋谷さん、那珂さん）
Platform Engineeringが進化していき開発者がセルフサービスで開発できるようになればSREは不要になるのか？という疑問に対し、
Platform Engineeringの技術やツールを使いこなすのにも知識や経験が必要になり、細かい設定をするにはより知識が必要になる上に、
プラットフォームチームと開発チームに距離感があることもあり、その橋渡しやイネーブリング役としてSREの活躍の場があるというお話でした。
コード化されていない稼働中のサーバを移設/再構築する技術（IVRy/SRE NEXT 渡部さん）
タイトルから「Terraform Importとかの話かな？」と思って参加してみたところ、
稼働しているプロセスからアプリの情報を調査していくリバースエンジニアリング染みた手法の紹介でした。
いい意味で予想が裏切られて、そういう知識も必要になるケースもあるよな…と再認識させられました。
おわりに
SRE Kaigiは今回が初開催ということですが、知っている人はもちろん、知らない人とも会話するきっかけが作りやすいとても良いイベントだったと感じています。
そしてSREをやってる人、やりたい人、もっと良くして行きたい人がこんなにたくさんいるんだということを体感できたのもうれしかったです！
本ブログは以上になります。ここまでお読みいただきありがとうございました。
私の所属するACS事業部では、開発者ポータルBackstage、Azure AI Serviceなどを活用し、Platform Engineering＋AIの推進・内製化のご支援をしております。
www.ap-com.co.jp www.ap-com.co.jp www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です！
我々の事業部のCultureDeckはこちらです。
www.ap-com.co.jp
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
www.ap-com.co.jp
