【ゆるSRE勉強会 #12 SRE乗り越え体験まつり 〜聞いてくれ俺の武勇伝〜 】参加レポート

はじめに

こんにちは！TechBull 運営チームの@Cooking_ENG です！今回、ゆるSRE勉強会 #12 SRE乗り越え体験まつり 〜聞いてくれ俺の武勇伝〜に参加してきたので参加レポートとしてブログに残したいと思います！

イベント概要

ゆるSRE勉強会の概要などは以下のCompassのページからご確認ください。

Compass

LT会アジェンダ

【オブザーバビリティコミュニティの近況報告】

まず最初に、会場スポンサーであるLINE ヤフー株式会社の@msksgmさんによる【オブザーバビリティコミュニティの近況報告】です。

Otel(OpenTelemetry)の翻訳PJやO11y con Tokyoのイベントのお話などをしていただきました！

オブザーバビリティミートアップが熱いとのことで、興味がある方は10月に開催されるO11y con Tokyoにぜひ行ってみてください！

【技術的負債で信頼性が限界だったWordPress運用をShifterで完全復活させた話】

2人目のLTは、我らが@adachin0817さんによる『技術的負債で信頼性が限界だったWordPress運用をShifterで完全復活させた話』です。

当時のWordPressの運用では「メンテナンス状況がわからない」という課題に加え、脆弱性件数が2024年に比べて68％増加（最も多い脆弱性はXSS）するなど、メンテナンス状況だけでなく、セキュリティ面でも懸念がある環境だったそうです。しかし、Shifterを導入することで、これらの問題がほぼ解消されたとのことでした。

（Shifterとは、WordPressを静的サイトに変換してホスティングできるSaaSとのこと）

Shifterの主なメリットとして、以下の点を挙げられていました：

• PHPの実行環境を直接持たないため、プラグインの脆弱性リスクが大幅に減少
• WordPressのバージョンアップを自動で実行してくれるため、SREチームの運用負担を軽減
• 自動バックアップ機能と簡単ロールバック機能により、問題発生時も迅速に復旧可能

Shifterというサービスも私自身知りませんでしたが、LTを聞いただけでも移行するメリットがわかる内容だったと思います。

また、最後にAIを使ってコーポレートサイトの修正（タイポなど）のAIを使って@kouzyunJaさんが自動化し、工数を削減した話もしてくださり、Shifterへの移行→AIによるトイルへの対応と盛りだくさんの内容でした。

【Enablingについに成功した話】

3人目は@_kei_s さんの『Enablingについに成功した話』です。

ToB向けのサービスとして、組織の中にAWSの知見がある人が少ない中、品質と速度、そして信頼性を担保していくためのチームにしていくためにどのようにアプローチしたかを中心にLTしてくださいました。

印象的だったのは、学習を以下の4つの段階にわけて「現状のチームはどの段階で、どこまで引き上げる必要があるか」をまず判断、また各段階でどのようにチームにアプローチしていくかしっかり決めていることでした。

（具体的な内容は資料をご確認いただければと思います。今回は「無意識的無能」→ 「意識的有能」へ）

• 無意識的無能（知らないからできない）
• 意識的無能（わかっているけどできない）
• 意識的有能（意識する時だけできる）
• 無意識的有能（意識しなくてもできる）

「ログが見づらかったので整形して出力するようにした！」など、小さな取り組みでもSREの活動として、:sre-jan:スタンプがついた投稿を#pick-you-are-sre というSlackのチャンネルに集約する取り組みも、SREを意識させる仕組みとしてすごくいいなと思いました！

今回はチームとしてのアプローチでしたが、「小さな取り組みでもSREをしている」という意識は、個人的にも常に持っていたいと思いました。

【EOLを迎えたベースイメージで動く属人化したNginxプロキシを無停止移行した話】

4人目は@egusumi1219さんによる『「EOLを迎えたベースイメージで動く属人化したNginxプロキシを無停止移行した話」』です。

退職予定のエンジニアの方に属人化していたNginxのプロキシメンテナンス作業を、SREチーム一丸となって安全に移行したお話をしてくださいました。

LTは、OSがEOLを迎えていたため移行作業を進めることになったという背景からスタート。調査を進めると、「コンテナの中にイメージが2つある」「Nginxのイメージがない」など、次々と謎が発覚する環境に遭遇したそうです。属人化していたことで、システムが完全にブラックボックス化していたとのこと。

このブラックボックスに対して、1人で調査するのではなく、SREチーム全員で担当を分担して調査を実施。各自が調査結果を構成図としてアウトプットすることで、チーム全体での理解を深めていったそうです。

チーム調査でも解明できなかった部分については、ドキュメントにまとめた上で、担当者の方に丸1日かけてヒアリングを実施したとのこと。

これまで、このような環境調査は基本的に1人が中心となって進めることが多かったので、チーム全体で1つのシステムを調査したという取り組みは、自分にとって新しい視点で学びの多いLTでした。

個人的には、現行のNginxと公式イメージのモジュールを1つずつ比較したという作業の話も印象的でした。AIの時代でもこう言った地道な調査が必要なんだなと思わせてくれたLTでした。

【o11yツールを乗り換えた話】

5人目は@tak_0x00さんによる『o11yツールを乗り換えた話』です。

O11yツールをDataDog → NewRelicに乗り換えた背景と経緯についてLTしてくださいました。

乗り換えた背景の大きくは「コスト」と「APMの導入可否」でした。

LLMOps基盤として「Langfuse」を採用しどのように構築して行ったかのお話をしていただきました。

データストアとしてS3, postgreSQLなど聞いたことあるリソースがあるなか、トレースデータを貯めるのに使われた「ClickHouse」というデータベースについての説明もありました。

「Langfuse」「ClickHouse」どちらも自分はまだ聞いたこと無い名称でしたが、インフラ構成図でどのように使っているかの説明もしていただき、ECS on Fargate の環境で動いているLLMアプリケーションでのデータの流れはイメージがしやすかったです。

※Langfuse：AIアプリケーションの品質を管理・改善するためのオープンソースツール。AIを使ったサービスを開発・運用する際に、パフォーマンスの測定、エラーの原因調査、コスト管理、ユーザー満足度の把握などを効率的に行うことができる。

※ClickHouse：高性能な列指向 SQL データベース管理システム

【新卒がSRE作ってみた】

7人目は @expected_tokenさんの『新卒がSRE作ってみた』です。

新卒でSREをされていて、障害の恒久対応や検知まわりの強化を担当されているのもすごいと思ったのですが、何よりSREとしてのマインドがかなり高い領域にあることに刺激を受けました。

研修を早く終わらせて早期配属してもらったり、レガシーな環境でSREの「文化醸成をする」という目標のために、SREチームのリーダーとして立候補するなど、これからSREを始める自分にとって、マインドを含めてお手本になるような内容でした！

まとめ

初めてSREのイベントに参加して、イメージできること、できないことはありましたが、登壇者の方々のSREとしての取り組みや考えが直に感じれてとてもいい刺激になりました！

次回もゆるSREに参加していきたいと思います！