こんにちは！バクラク事業部Platform Engineering部SREグループのtaddy( id:sadayoshi_tada )です。
8/8開催のゆるSRE勉強会 #12 SRE乗り越え体験祭り 〜聞いてくれ俺の武勇伝〜 に、同僚のSRE上原が登壇することになり現地参加しました。この記事では各発表ごとに内容や学びをまとめた、勉強会参加レポートを書きます。
勉強会の会場の様子は以下のような感じでした。なお、画像は@syossan27さんのツイートをお借りしました。ツイートの画像使用を承諾いただき、ありがとうございました！
#yurusre pic.twitter.com/l0YWzS6jy1
— しょっさん@ʕ ◔ϖ◔ʔ (@syossan27) August 9, 2025
始まりました！LINEヤフー様、株式会社スタディスト様、転職ドラフト様、スポンサーありがとうございます！！🙇#yurusre pic.twitter.com/oS9kLgVbTe
— しょっさん@ʕ ◔ϖ◔ʔ (@syossan27) August 8, 2025
- オブザーバビリティコミュニティの近況報告
- 技術的負債で信頼性が限界だったWordPress運用をShifterで完全復活させた話
- Enablingについに成功した話
- EOLを迎えたベースイメージで動く属人化したNginxプロキシを無停止移行した話
- o11yツールを乗り換えた話
- LLM機能を支えるLangfuse/ClickHouseのサーバレス化
- 新卒がSRE作ってみた
- 終わりに
オブザーバビリティコミュニティの近況報告
LINEヤフー株式会社 Masaki SugimotoさんによるスポンサーLTで、OpenTelemetryの公式ドキュメント翻訳プロジェクトと、10/27開催のObservability Conference Tokyo 2025(略称がオリコン東京2025)の紹介でした。
オリコン東京のキーノートには『オブザーバビリティ・エンジニアリング』著者のLiz Fong-Jonesさんが登壇されることが予定されており、8/24までCfPも募集中とのことです。
発表資料
技術的負債で信頼性が限界だったWordPress運用をShifterで完全復活させた話
発表のトップバッターは、ファインディ株式会社Adachi.Ryoさんによる4つのWordPressサイトをAmazon LightsailからShifterに移行した発表でした。
Shifterへの移行前はWordPressサイト1つにつきAmazon Lightsail 1サーバーで運用されていて、サイトによってはメンテナーが不明瞭なことやサーバーの中がブラックボックス化していたことで課題を抱えていました。
そんな中、CM放映が予定されていたためインフラ強化の必要性がでてきたこと、既存の属人化したWordPress環境を集約・統制するために、WordPressを静的に変換・ホスティングする、Shifterへ移行されました。
移行後は運用体制として各チームの責任範囲を明確化するだけでなく、Devinを使って非エンジニアがコーポレートサイトの修正作業を自動化し、エンジニアはレビューだけすればよい体制を構築されたそうです。抱えていた課題を解決するだけでなく、AIを使ってエンジニアの業務自体を少なくする取り組みが素敵だと思いました。
発表資料
Enablingについに成功した話
2番目に千株式会社 ササキさんによる横断SREチームが負荷集中によるボトルネックになっていたことで、各プロダクトチームで信頼性の担保が難しくなっていたため、その課題解決に取り組まれた発表でした。
この取り組みでは学習の4段階モデルを基にした独自のアプローチで、SREのプラクティスについてプロダクトチームが「無意識的無能(知らないからできない)」の状態から「意識的有能(意識するときだけできる)」の状態へ移行するためにやったことを紹介されました。
個人的に勉強になったこととして、開発チームがSREのプラクティスを実践した際にはSlackで「それってSRE!」スタンプを押して認識・称賛する文化を醸成したことです。SREのプラクティスを認知し広めてもらうために限られたメンバーで全てをやるのは難しいと思うため、こういった認知の広げ方もあるのだと勉強になりました。
現在は同じアプローチを他チームへも展開する計画を進めておられ、今後の発展も気になる発表でした。
発表資料
EOLを迎えたベースイメージで動く属人化したNginxプロキシを無停止移行した話
3番目に株式会社コドモン すみやさんによる、EOLを迎えたOSで動作しているNginxプロキシの運用が退職予定者に依存していたという課題解決にあたった発表でした。
まず、当該課題に対してSREメンバー間でブラックボックス化したコンテナの構成を詳しく調査・共有し、メンテナンス担当者へのヒアリングを実施されたそうです。担当者がまだ在籍していたのが幸いだったお話は私も過去に同じような対応したことがあるため印象的でした。
また、Nginxプロキシの構成変更を検討し検証した結果、公式イメージを利用することで現行運用を継続できることがわかり構成もシンプルにされました。切り替えの際はALBの荷重設定を活用して無停止で移行を実現されました。
課題に対して既存の運用状態を疑って地道な取り組みで従前の運用を改善された、素晴らしい取り組みと思いました。
発表資料
o11yツールを乗り換えた話
4人目に福本隆弘さんによるDatadogからNew Relicへの監視ツール移行に関する発表でした。
移行の主な理由は、サーバー台数が10台から100台へと大きく変動するため予算予測が困難だったことと、Datadogでは対象システムにAPMを導入できなかった点です。
移行にあたっては、3ヶ月の十分な準備期間を設定し、開発者が混乱なく作業できるようNew RelicでDatadogと同様のダッシュボード構成を再現したり、データ損失を防ぐため並行運用期間を設け、エンジニアには旧ダッシュボードのキャプチャ取得を促しました。
この移行により、コスト予測が容易になっただけでなく、従来導入できなかったAPMも実装できるようになり、監視体制が強化された事例でした。
発表資料
LLM機能を支えるLangfuse/ClickHouseのサーバレス化
5人目として弊社上原によるLLMOpsのLangfuse/ClickHouseをサーバーレス化した取り組みの発表でした。
バクラク申請・経費精算でAIレビュー機能を提供しているのですが、このLLMOps基盤を構築する必要が出てきました。この基盤にLangfuseとClickHouseを採用しています。バクラクのインフラの大部分がサーバーレスで構成しており、そのためのCI/CDや監視設定等コードの自動生成もあるためLangfuseとClickHouseもサーバーレス化を目指すことになりました。
基盤ができて運用開始したところ、Langfuseでトレースが記録できないエラーが連続的に出力される状態になっていました。調べてみたところClickHouseが使用しているEFSのスループット設定がBurstingモードになっていたことで問題が発生しましたが、Elasticモード変更によってこの問題を解決することができました。
AIをプロダクトに組み込んで運用していく中で重要になってくる基盤なので、今後も注視し改善に取り組んでいきます。
発表資料
関連記事
新卒がSRE作ってみた
最後に、tenso株式会社 ひびきさんによる所属チームを変革した取り組みに関する発表でした。
SREという名前がついているものの、業務の実態がサービスの運用保守しかしないチームであった状態からSREの文化醸成をしていくことに取り組まれたそうです。そのために既存の業務を改善し、チケット管理ツールの選定・移行を行い、オペレーションの自動化も実現しました。最終的な目標は、各サービスにSREチームを作り、ゆくゆくはグループ横断のSRE組織の構築を目指すとのことでした。
今までのチームを変えるために自分の所属チームを異動し、ドラスティックに既存の業務を改めていくことや周りの方への説明していく地道な活動を正社員1人の中で進められていてまさに偉業、と会場でも盛り上がっていました。個人的に半年前にこの取り組みに関するお話を伺っていたため、その取組状況を知ることができてとても刺激を受けました。
発表資料
終わりに
ゆるSRE勉強会 #12に参加してのレポートをまとめてみました。個人的にはずっと参加したかった勉強会だったので現地参加できてよかったです。企画・運営のみなさん、発表されたみなさん、素晴らしいイベントをありがとうございました。今度は自分が何か発表できるようにしていきたいと感じました！
