はじめに
こんにちは！
GENEROSITYのSREを担当している川口です。
4/4に行われた ゆるSRE勉強会#10 に参加してきたのでレポートします！
私自身はじめての参加でした。
非常に勉強になる内容ばかりでしたが、イベント名の通り適度にゆるく、いい意味で敷居の低いとても良いイベントだなと感じました。
登壇資料や雰囲気のわかる写真を掲載しますが、Xにて #yurusre で検索すると多くの方がポストされているので、ぜひこちらもご覧ください！
イベント概要
"ゆるSRE勉強会"は、ゆるい雰囲気で肩肘張らずにSRE関連のトピックについて話す勉強会です。
「こんな問題を解決した！」や「他チームとのコミュニケーション/コラボレーションでこんなことをやった！」
などなど、様々なお話を聞いたり話したりしていきましょう。
公式のイベント説明を引用しています。
スポンサー紹介
gifteeさんから会場提供、Sentry Japanさんからお食事と飲み物の提供、転職DRAFTさんからビールの提供がありました！
参加費無料でここまでもてなしていただいて良いのだろうか。。と不安になるほどでした🤣
写真はすべて ゆるSRE勉強会運用担当 の方から提供いただいたものを添付しています。
登壇資料まとめ
登壇者の方々が展開されていた資料のリンクを添付しています。
ぜひご覧ください！
資料が見つけられなかった登壇内容に関しましては、私自身のメモを基に内容をまとめます。
正確性に欠ける部分があるかもしれませんが、その点はご容赦ください。
また、資料をお持ちの方はぜひリンクのご提供お願いいたします！
会場スポンサーLT ：『小さく始める障害訓練』 牧純平さん@株式会社ギフティ
新規プロダクトのリリース前障害訓練について
メンバーにバレないようにこっそり小さな障害を起こし、困っている時には手を差し伸べつつ訓練をしたという内容でした。
障害内容は以下をもとに選定
- 目的に沿った簡単なもの
- ビジネスクリティカルなもの
- 準備が簡単なもの
以下内容でポストモーテム（振り返り）を実施
- どのようなフローで対応したのか
- 誰が、いつ、何を実施したか
- すべてを一度に解決せず、クリティカルな対応から実施しよう
「初手から盛り込みすぎず、（まずは小さく）訓練を重ねて重要性を認識してもらう」ことが重要だとおっしゃっていました。
所感
- 小さいことの積み重ねが大事 は私もその通りだと感じます
- 何事もPDCAを回してより良い形を目指すという初心を忘れないことが重要だと再認識しました
スポンサーLT：『もしSentryがなかったら』@Sentrys
Sentryさんが開発したモニタリングツールを軸に
導入しているケースとしていないケース（つまりモニタリングできてる？）でどうなるかについてお話しされていました。
https://sentry.io/welcome/
もしSentryがなかったら？
- 通知はしているが、原因特定に時間かかる
- エラーの管理どうする？
- 深夜まで調査・改修。つらい。。
所感
- Sentryさんのツールにお世話になっているという声も上がっていました！
- 弊社ではモニタリング管理がまだまだ成長途中ですので、改めて重要性を再認識しました
『入社後SREチームのミッションや課題の整理をした話』 Morixさん
X(旧Twitter): @morix1500
https://speakerdeck.com/morix1500/ru-she-hou-sretimunomitusiyonyake-ti-nozheng-li-wositahua
『新しいプロダクトのデプロイパイプラインに Argo CD を使った話』 北野 敦資さん
X(旧Twitter): @Aquamarine_1010
https://speakerdeck.com/cloudace/xin-siipurodakutonodepuroipaipurainniargo-cdwoshi-tutahua
『スロークエリとの戦いの軌跡2024』 r_takaishiさん
X(旧Twitter): @r_takaishi
個人サイト: https://repl.info/
https://speakerdeck.com/takaishi/yurusremian-qiang-hui-number-10
『負荷試験でAWSから予想外の請求が来た話』 田幸久志さん
X(旧Twitter): @htako_tech
selemiumを使ってブラウザアクセスを想定した試験を繰り返した結果、とんでもなく高額な費用が請求されてしまっというお話しでした。
高額請求の原因（問題点）
- Fargateのタスク起動→落ちるを何度も繰り返す
- コンテナのタスク定義のリージョンが想定と異なっていた
- 異なるリージョンを参照することでコストが発生
どのように修正したか
- ECRからVPCエンドポイントを利用して接続
- 取得先リージョンを期待と一致させる
など
教訓
- ちゃんと調べよう（無意識にコピペしない）
- いきなり大量に実行しない
- AWS実行直後はすぐにコストが反映されないため
所感
- 理解せずに手を動かして後になって問題発覚！はあるあるだな〜と感じました
- 各セクションで設計や実装の意味を理解することで、事故を減らし、自己成長にもつながります
- いきなり大量に実行しない！もその通りで、改めてまずは最小限を徹底したいと思います
『SES運用監視オペレーターから自社開発のSREになるまでの話』 原昂司さん
X(旧Twitter): @kouzyunJa
https://speakerdeck.com/kouzyun/sesyun-yong-jian-shi-operetakarazi-she-kai-fa-nosreninarumadenohua
『スタートアップの1人目SREがSREチームを分割しようと考えるに至るまで』 髙塚広貴さん
X(旧Twitter): @tk3fftk
席を外していて拝聴することができませんでした。。（申し訳ございません）
資料をお持ちの方はぜひご一報ください🙇
『(みんなやっているはずなのに情報の少ない) DNSレコード管理の改善』 Kouさん
X(旧Twitter): @arbnhrn
Bluesky: @arbnhrn.bsky.social
DNAレコードの一元管理により、運用の多くに発生しているトイル削減に取り組んだというお話しでした。
一元管理による課題
- レコード変更が手間
- 開発スピード低下
- 依頼が重なった場合にPR統合の調整が必要
改善のアプローチ
- Terraform × GitHub Actions × Slack を組み合わせた運用を構築
- PRのレビューは開発者が行い、デプロイは自動化されるような仕組みを構築
所感
- 「分散 × セルフサービス × 自動化」というアプローチは、今後の参考にしたいと思います
- TerraformとGitHub Actionsを組み合わせ、SlackでのChatOpsまで見据えた運用は、運用効率化と属人化の回避の両立が見込める良い例だなと感じました！
参加した感想
今回のSRE勉強会に参加して、多くのセッションから非常に有益な情報を得ることができました。
特に、各登壇者の経験談や実践的なアドバイスは、現場で活かせる知見が多く、非常に参考になりました。
また、各スポンサー様から提供された飲食も豪華で、参加者同士の交流がより活発になり、快適な環境で学びを深めることができましたと感じます！
またゆるSRE勉強会に積極的に参加したいなと感じる素晴らしいイベントでした！
SREに少しでも関心がある方は、ぜひ参加してみてはいかがでしょうか。
ここまで読んでいただきありがとうございました！
