😆

ゆるSRE勉強会#4に参加しました!!!

2024/02/23に公開

はじめに

先日、ゆるSRE勉強会#4に参加してきたので、その感想を書きます😆

ゆるSREとはなんぞや?みたいな人にも雰囲気がわかるように書いていくので、ぜひ読んでいってください!!!

ゆるSRE勉強会とは?

connpassのイベントページから引用します

"ゆるSRE勉強会"は、ゆるい雰囲気で肩肘張らずにSRE関連のトピックについて話す勉強会です。
「こんな問題を解決した!」や「他チームとのコミュニケーション/コラボレーションでこんなことをやった!」などなど、様々なお話を聞いたり話したりしていきましょう。
初心者SREの方や他職種からSREに挑戦中の方もお気軽にご参加ください!

まとめると、初心者や挑戦したいという人でも行きやすいSREの勉強会です!

ゆる」なので文字通りゆるい感じですし、「マサカリはダメ!」とアナウンスがあるくらい安心して参加できます👍

雰囲気はXでハッシュタグ#yurusreや、イベントの写真を投稿しているゆるSRE勉強会運営のずんだまる(仮)さんのXを見るととてもよくわかります!!!!

https://x.com/zuncha318/status/1760613057733280128?s=20

参加した動機

私自身はSREというよりクラウドエンジニアですが、SREの考え方が好きなので参加してみました!

知見が得られて業務に活かせればラッキーぐらいの気持ちで参加してます😎

LT会

イベントではLT会と交流会がありましたので、まずは各LTの簡単な概要に触れ、新しいしい知見や学び、興味深かったポイント、強く印象に残ったについて触れていきます!

19:35-19:40 会場スポンサーLT

発表者:会場提供していただいたHRBrainのCTOの鈴木さんでした!

SREはいないがプラットフォームチームがあるとのことで、そちらのLTでした

以下のようなことを実施されているようです。

  • dev環境が多いので、PR単位で自動で環境構築をするように
  • ビックバンリリースが増えたので、Feature Flag機能の提供
    • テスト環境だけ機能使えるようにしたりなど便利そうでした
  • ローカル開発の関連サービスで20個ぐらいコンテナが必要だったので、Cloud Workstationsの導入

私の担当しているサービスでもdev環境が多数存在しており、ちょうどPRベースの環境を自動で構築できるように実装しているので参考になりました!

なんでもローカルに再現すれば良いのでは?とちょっと思い始めていたので、Cloud Workstationsという新しい知見を得ることができたのが収穫です

19:40-19:45 『監視SaaSが使えなくなった話』

発表者:wadayさん X(旧Twitter): @waday_x
https://x.com/waday_x/status/1760663049638424694?s=20

前提として、夜間バッチの処理が大事なシステムのお話でした。

簡単な流れとしては、ECSからDatadogに連携し、PggerDutyでオンコールする感じです

メインのお話は以下でした

  • PagerDutyで電話ができなくなった障害が発生!
    • 対策として、Amazon Connect経由にしたとのこと
  • Datadogが使えなくなった障害が発生!
    • 一部のログをメトリクスフィルターでもPagerDutyに連携

確かに、何かのSaaSに依存して監視している場合に監視SaaS自体が停止していたら、監視できていない状態になってしまいますね😖

そこまで意識したことはなかったものの、絶対に障害の発生しないサービスは存在しないので、備えておくことは大事だなと知見を得ました!!!

ただ作り込んじゃうと大変なので、最低限だけ別経路を用意しないと

災害対策ですね!

19:45-19:50 『Lambdaのパフォーマンス改善』

発表者:mickさん X(旧Twitter): @sre_tsutsumi
https://x.com/sre_tsutsumi/status/1760684791576617337?s=20

そもそも、Lambdaとはサーバレスのイベント駆動型コンピューティングサービスです

提供しているサービスは、障害がダッシュボード的に見られるものとのことでしたが、表示遅い!

DatadogのAPMで計測した画面がスライドに載っており、行ごとの内訳が確認できていました!

結果、ColdStartで6秒かかって遅くなっていたとのこと

対策として、Lambdaを定期実行したり、プロビジョンドコンカレンシーを有効化をしたものの、サーバレスのメリットがなくなる

結果としては、計測と改善を繰り返して、パフォーマンスを改善!

正直にいうと、私はAPMはちゃんと使ったことがないです😇
だけど、スライドのスクショを見る限りではかなりわかりやすそうでした...

APMってすごそう...!
そして、何事も計測は大事!
測って現状を把握し、改善し、数値がどう改善されたかを見る!この一連の流れを繰り返していけば良いものになりますね

そして、聞く前にコールドスタートらへんの話かなと予想していましたが、当たりました
最近ちょうど勉強したんですよね😋

19:50-19:55 『インシデントコマンダーやってみた』

発表者:川井 颯人 (Fohte)さん X(旧Twitter): @fohte
https://x.com/fohte/status/1760622519755931840?s=20

発表者の川井さんがLoL好きらしい☺️

結論:障害対応訓練には価値がある!

Wantedlyさんは、障害が発生して#war_roomに通知が来ると笑笑と集まる文化があるとこのと。これはすごい羨ましいw

ただ、それでもインシデントコマンダーをやる人が固定化されている課題がある
わかっている人がやる傾向があり、これはどこでも似た感じなのかな...

なので訓練を始めたとのこと!

  • 効果は、障害対応ハードルが下がる
    • 役立てることがわかり、何やれば良いかがわかると
  • ただリモートだと混線する
    • わからないことがあっても、聞きにくい

そもそも、Wantedlyのエンジニアリングハンドブックすごい過ぎるんですよねー!
参考にさせていただいております!!

障害対応訓練は、自分の担当範囲でもやってみても良さそうだと知見を得ました😎

いかんせん、私の在籍しているチームは担当しているサービスが多いので、何が重要かは初見でわからないんですよね...

レクチャーも兼ねて、ナレッジを横展開するという意味合いを含めてできそうと思いましたので、試しにやってみたい!

19:55-20:00 『SentryでRailsアプリケーションのエラー監視を始めた話』

発表者:田中 章悟さん X(旧Twitter): @shogo__452
https://x.com/shogo__452/status/1760653799100985357?s=20

  • Sentryとは
    • エラー監視ツール
    • パフォーマンスの監視もできる
    • テストカバレッジもわかる
    • リリースマネジメントもできる
    • 色々機能がある!

コストやアラート面で別サービスから切り替えたとのこと。

サンプリングレートを100%にすると、外部通信料が増えますのが注意点

私も、サンプリングレートが高いとコストが高いというのは聞いたありました

運用としてはドキュメント整備を行い、誰でも使いやすいようにしているとのこと

確かに、ツールを入れたとしても使いこなせなければ宝の持ち腐れなので、ドキュメント整備や布教活動は大事ですね!!

20:10-21:00 パネルディスカッション:今さら聞けないObservabilityのキソ

司会:北野 勝久 さん X(旧Twitter): @katsuhisa__
パネリスト:松木 雅幸 (Songmu) さん X(旧Twitter): @songmu
パネリスト:清水 勲さん X(旧Twitter): @isaoshimizu
パネリスト:加我 貴志さん X(旧Twitter): @TAKA_0411

司会もパネリストの人もお酒片手にゆるいディスカッション会ですw

まずは自己紹介から始まりました。
SRE Nextの代表理事の人が司会とのことでビックリです
いつかは行きたい...

話題としては、事前に用意した質問や、Slidoで集めた質問をもとに進んで行きました

話題としては以下のものがありました

  • ツールの使い分け
    • コスト的に複数のサービスを使い分けたり、1つのツールに集約したりなど実務ベースでのお話が多かった印象です
  • コストの問題
    • すべてのログやメトリクスをO11y(Observability)のSaaSなどに流すとコストがかかりすぎるので、サンプリングレートを調整して取得したりなどコスト削減はしないといけなさそう
    • O11yは「未知の未知」を扱うために、いろんな情報をいっぱい集める必要があるので、サンプリングは本質的ではないというお話もあり、なるほどなぁと自分は頷いていました
  • o11yで助かったこと
  • 予算を確保するために工夫したこと
    • O11yなど、運用ツールって結構高かったりするので、その予算確保方法についてでした
    • ビジネスサイドを納得させる理由はいるけど、もうお金のかかる時代になっていると価値観を変えることも大事だなぁと感じました
  • ベテランが障害対応することを自重してもらう時ある?
    • ベテランが勘と経験で障害を解決してしまうと、知見が残らない問題
    • 思考の過程を残したり、ちゃんと振り返りを行いましょうというお話でした
      • ちょうど自分も障害時にどのような流れでどういったポイントで確認を行うかをドキュメント化していたりしていたので、方向性は合っていたんだなと嬉しくなりましたw
  • ダッシュボードを眺めたり、エラーを見る回は大事!!!
    • 障害対応時に練習になる

最後に、o11yとは何かで締めくくられていました

21:00-21:30 交流タイム

ゆるSREの運営の方のツイートを拝借しますが、和気藹々と交流させていただきました!

https://x.com/zuncha318/status/1760638558690500709?s=20

交流会では、HRBrainのCTOの鈴木さんに直接質問させていただきました。
CTOとか技術職トップの人とお話する機会はそうそうないので、参考になりました!

また、何人かの方とお話させていただきましたが、1時間にも満たない時間でしたのでもう少し時間が欲しかったなぁという感想です

お話していてマサカリはとんでくることはなかったので、そこは安心です!!!

まとめ

全体を通しての感想は、「銀の弾丸的な解決策はないので、現在の状況を踏まえて何をどうするか考えていけないなぁ」です!

どんなことにも言えそうですけど!

最後に、ゆるSRE勉強会は隔月で開催されていますので、皆さんも参加してみませんか!?
いろんな知見を得たり、他社のエンジニアさんとも交流することができるので、SREあんまりわからないよぉ...という人でもオススメです!!!👍

「開発をやっているけど、SRE方面に興味があるので来ました!」という人もいましたので、広く受け入れてくれます😁

参考リンク

ゆるSRE勉強会-connpassページ-

GitHubで編集を提案

Discussion