SRE NEXT 2023 に参加しました!

Infra Squad の川井 (@fohte) です。

2023 年 9 月 29 日に九段会館テラスで開催された、SRE トピックを扱う国内のカンファレンスである SRE NEXT 2023 に参加しました。
SRE 活動に対してのモチベーションが湧く、興味深いセッションが目白押しでした。
本記事では、筆者が拝聴したセッションを参加者目線でそれぞれ紹介します。

Keynote『ギークがイオンに飛び込んだ結果がやばい〜Reliabilityと経営〜』

イオンネクスト株式会社の樽石将人さんによる Keynote でした。

イオンでの、ソースコードを取得するために数週間かかるところから内製化チームを立ち上げて改善していったり、イオングループの会社間を跨ぐ Microservices architecture ならぬ Micro-companies architecture を設計するなど、イオングループの組織全体の改善を実施しやり切った貴重な経験談を聴ける、良いセッションでした。

特に「IT 人材はグローバルを見すぎて日本のデジタル化に真剣になっていなかったのでは」「イオンが変われるなら日本中も変われる」といった言葉が印象的でした。

『SREとして向き合うGenerative AI』

スライド: [SRE NEXT 2023 CfP]SREとして向き合うGenerative AI - Speaker Deck

株式会社スリーシェイクの橋本玄基さんによる、SRE の取り組みに Generative AI を活用する事例を紹介するセッションでした。

Generative AI の基礎知識から、社内のドメイン知識などの情報検索のハードルを下げたり、toil 削減のための自動化実装として Generative AI を活用するといった事例が紹介されました。

特に toil 削減のために、コストレポートなどの定期的なレポートの first insight を Generative AI に任せる、ドキュメントを最新の状態に保つために Terraform コードから Mermaid.js でのグラフを作成する、IAM ポリシーを非エンジニア向けに自然言語で翻訳するなど、具体的な事例が紹介されており、日々の SRE 業務を取り組むためのアイデアの着想を得られる刺激的なセッションでした。

『プラットフォームSREによる脆弱性対策を意識したコンテナビルドフロー構築』

株式会社スクウェア・エニックスの橋本和宏さんによる、コンテナの脆弱性をどのように検知し、検知後の triage の考え方について紹介するセッションでした。

脆弱性検知にはビルド時やランタイムで sysdig を活用されていることや、triage する際は internet-facing でなければ優先度を下げたり、コンテナはアプリケーションチームが管理していて対応が難しいので多層防御するとよい、といった話が紹介されました。

スクウェア・エニックス社での脆弱性対策の事例が知れる、興味深いセッションでした。

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

弁護士ドットコム株式会社の上田璃空さんによる、開発者がインフラを触れるようにする工夫や、feature flag を管理するための AWS マネージドサービス CloudWatch Evidently を導入するに至った背景や導入後の効果について紹介するセッションでした。

意図しないトラブルを避けたかったり、組織が拡大し Dev/Ops で分離してしまうなどで、運用者しかインフラを触らなくなってしまうという課題に対し、Terraform とその CI/CD での実行基盤の整備や、コンテナに移行することで解決する話が紹介されました。
また、開発者がスピーディーに開発するために CloudWatch Evidently を導入し、新機能リリースのタイミング調整やロールバックの容易さなどのメリットや、それによりリリースブランチに merge しやすくなったり、CI を通さずにロールバックできるため切り戻しが楽になったといった良い効果についても紹介されました。

DevOps の実践事例が知れ、改めて DevOps 実践の重要さが分かるセッションでした。

『SREを以てセキュリティエンジニアリングを制す ― class Dev"Sec"Opsの実装に向けて』

スライド: SREを以てセキュリティエンジニアリングを制す / SRE, Security Engineering, and You - Speaker Deck

株式会社 Flatt Security の米内貴志さんによる、セキュリティ指標を SLI/SLO に適用するための考え方を紹介するセッションでした。

セキュリティスキャナーのスコアを指標にしてもそれがどのくらい重要なのかが分かりにくいため、数値での割合に執着せず、明確な目標を立て必要なアクションを整理し、問題の重大さを定義することが重要であると話されていました。
エラーバジェット的な考え方は、今アクションが必要なものや優先度が低い Dependabot のセキュリティ通知のようなものに対してはマッチせず、後者に関しては「次からは増やさない」という教育に活かすのが良い、と話されていました。

セキュリティという文脈でも SLI/SLO を定義するならどうすれば良いのかという考え方が知れる、学びのある良いセッションでした。

『電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践』

スライド: 電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践 - Speaker Deck

株式会社 Luup の Wataru Tsuda さんによる、LUUP において開発チームに SRE 文化を浸透させていくための SLO 導入の取り組みを紹介するセッションでした。

Enabling SRE ではスコープが広いので Enabling SLO として SLO 導入を進めていたり、そのために PdM 含む開発組織全体で SLO の習熟度調査や勉強会を実施したり、IoT デバイスの信頼性を担保するための SLI 設計について紹介されました。

特に SLO をまず導入していく話だったり、「SLO の習熟度調査をオンボーディング時に実施すると個別のフォローアップにも使える」という話が、実際に活かせそうな興味深い内容でした。
Enabling SRE (SLO) をどのように進めるのか、LUUP での事例が知れる良いセッションでした。

『Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵』

スライド: Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵 - Speaker Deck

面白法人カヤックの池田将士さんによる、Warning アラートとの上手な付き合い方に関するセッションでした。

Warning アラートは重大な事故に繋がる兆候を発見できるものの、その調査が toil であるため、これを改善するアプローチとしてアラート発生時にログやメトリクスを収集する prepalert という OSS を作成したという話がされていました。
また、それによって初期判断や調査のハードルを下げられたり、収集するログやメトリクスの数や種類を増やすモチベーションにも繋がったり、外部からの攻撃が来たときに迅速に気づけたなどの良い効果も紹介されていました。

Critical ではないアラートは放置されがちですが、それを放置せずに向き合い、さらに良い効果を得られている、良い話を聞けるセッションでした。

『Runbookに何を書き、どのようにアラートを振り分けるか？』

スライド: Runbookに何を書き、どのようにアラートを振り分けるか？ - Speaker Deck

グリー株式会社の岩堀草平さんによる、Runbook の整備によりアラート疲れを軽減させるアプローチについてのセッションでした。

アラートが増えるに従ってコンテキストが失われてしまい対応が困難になるという課題に対し、エスカレーション先の担当者をターゲットとして Runbook を整備し、またアラート新規作成時のフローやガイドラインについても整備することで、未知のアラートを受ける機会を減らせたことが紹介されていました。
また Runbook は短期解決より長持ちする情報を記載し、Why を記載し背景の共有を重視するといった Runbook のフォーマットなど、実際の運用についてもイメージがしやすく紹介されていました。

アラートのコンテキストを失わせないための具体的な取り組みや、Runbook の重要さを改めて知れる、個人的にはとても学びがあり、良いセッションでした。

『1,800万人が利用する『家族アルバムみてね』におけるK8s基盤のアップグレード戦略と継続的改善』

スライド: 1,800万人が利用する『家族アルバムみてね』におけるK8s基盤のアップグレード戦略と継続的改善 / FamilyAlbum's upgrade strategy and continuous improvement for K8s infrastructure - Speaker Deck

株式会社 MIXI の杉本浩平さんによる、『みてね』の EKS アップグレードに関するセッションでした。

EKS アップグレードは基盤なので簡単ではなく、そのためにアップグレード手順の改善を都度行っているという話をされていました。
また、Blue/Green 方式でアップグレードしており、その際に Argo CD を新クラスターに手動インストールする作業が発生してしまう課題に対し、アプリケーション用クラスターと Argo CD を置くための ops クラスターに分割し、前者は Blue/Green、後者は in-place でアップグレードすることで改善した、という改善事例も話されていました。

EKS アップグレードは Wantedly でも継続的に取り組んでおり、積極的に工数削減のための改善にも取り組んでいるため、非常に興味深く、知見を得られたセッションでした。

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

スライド: 信頼性目標とシステムアーキテクチャー / Reliability Objective and System Architecture - Speaker Deck

グーグル合同会社の山口能迪さんによる、SLI/SLO やエラーバジェットの基礎的な解説から、信頼性を向上させるために必要なアーキテクチャーに関するセッションでした。

SLO の基礎的な知識の他、r9y.dev という SLO ごとに必要なアーキテクチャーをまとめたプロジェクトについて紹介されていました。

「SLO はどういったもので、なぜ有用なのか」ということを丁寧に解説されていたため、特に SLO の初学者にぜひ聞いてほしいセッションだと感じました。
また、r9y.dev は組織規模による適切なシステム構成について知れて、信頼性を向上させるために必要なアクションを取りやすくなったり、逆にオーバーエンジニアリングを防いだりする、非常に良いプロジェクトだと感じました。