📚
SRE Kaigi 2025に行ってきた
Re:Define 可用性を支えるモニタリング、パフォーマンス最適化、そしてセキュリティ
- CPUの飽和などはクラウドの弾力性やスケーリング性能を考えるとノイジーアラートになりがち
- セマンティックアラートが有用
- 無視できるアラートは出すな
- たまに落ちる...
- メトリクスの粒度g当てなくて真因をアラートに設定できていない
- 当事者のスキル、モチベーションに課題があり適切なアラートが設定できていない
- 忙殺されている
- システムパフォーマンスのチューニング
- 金で殴るはSREの視点では負け
- いかに妥当なコストで問題を解決するか
- SREと開発チームの役割
- どんなに新機能を作ってもユーザーに使われなければ価値は生み出さない
- SREだけではなく、開発者や管理者も信頼性に責任を持つべき
- セキュリティ
- 多層防御
- ヒューマンエラーがあっても防げる仕組み
- 多層防御
- 全部やる
- 可能な範囲でSREがコードをいじりシステムの可用性やパフォーマンスを改善するアプローチが有効
- 感想
- SREがどこまでやるか議論で、「全部やる」と言い切っていたのが印象的だった。
- SREがどこまでやるのか。弊社でも度々議論になるのだが、ビシッとした結論が出たことはない。
- ただ、やはりSREという職種はやることが広く、全部やるとなると採用のハードルが上がりそうな気配はある。一方、採用市場で強くなるということでもあるので個人的にはやっていこうと思った。
実践: Database Reliability Engineering ~ クラウド時代のデータベースエンジニアの役割 ~
- SRE と DevOps はタスクの注力の方向が違う
- データを中心に据えた視点で、本番環境の信頼性、可用性、継続的成長性を確保
- クラウドによってDBAの役割が薄れDBAがいない組織も増加傾向
- ドキュメント作成ツールを作った
- DDLやER図を出せる
- 稼働中のデータベースから取得するので、「生きているドキュメント」にできる
- 最初は自分が問い合わせを受けた時に使うものだったが、AWSに乗せてchatops的に使えるようになっている
- 書いてあることは間違ってないが、ガイドラインを遵守しようとするとめちゃくちゃ大変
- 踏み台にログインできてしまったら強権限になってしまう
- インスタントな踏み台サーバを構築する
- EC2 instance with SSM agent
- CREATE USER の発行。DROP USERも最後にする。
- AI Schema review
- スキーマは一度作られると変更しにくいので、作るときにレビューしたい。
- 生成AI(Bedrock)を使ってPRコメントに変更するべきところをコメントしてくれる
- 感想
- DBREのお仕事に対してほとんど理解していなかったので貴重な体験だった。
- ドキュメント作成ツールやインスタントな踏み台サーバの構築など、Platform Enginnering 的な要素があり、ニーズがありそうならうちでも作るのアリだなと思った。
- こういった具体なアイデアが得られるセッションはとてもありがたい。
もっとSREを広げるための初学者向け技術研修設計
- SREに求められるスキルが幅広い
- 組織の経営に資する
- 組織社会化
- kubenetes が動いているからこの組織では
kubectlを打てる必要があるんだな。とか - 新卒研修
- コンテナ技術についてやArgoCDの使い方を知るといった内容
-
private-isuでパフォーマンスチューニング実践 - 新卒研修で教育を受けた人が現場に投入される
- 研修では人に伝わるように作る
- kubenetes が動いているからこの組織では
- エンジニアの寿命はシステムより短い
- ハンズオン
- 検証環境で
kubectlを叩いてみる - つまりポイントを同期的に解決する
- 検証環境で
- プレモーテム
- 障害を想定して対応を考えてみる
- https://www.amazon.co.jp/dp/B0B37Z76BY 初学者にいい
- SREを広げるために新卒研修やオンボーディングでトレーニングを実施している。
- 知識と経験、WhyとHowで設計する。
- 感想
- 新卒研修の文化がある会社は強い。しかも結構なボリュームではないだろうか。
-
kubectlを叩くというのは、それだけでも新卒研修でやっておくといいなと思った。が、どのエンジニアの研修でもやっているのだろうか。フロントエンドエンジニアは対象外とかなのだろうか。 - SREを広めていくに際して、新卒研修という武器が切れるのはとても羨ましい環境だなと思った。
インフラコストとセキュリティ課題解決のためのリアーキテクチャリング
- ECSからEKSへ移行した理由
- メモリが大きくて vCPUが小さいコンテナが必要 だが、ECS Fargateがサポートしている メモリ・CPUセットとのギャップ があり、過大なCPU値を割り当てたタスクを使用 していた
- HPA vs in-house
- スケールインアウトはサーバーメトリクスベースではなくビジネス要求に基づく
- Terraform Helm で再構築
- GKEクラスタは shell script で実施。
- 構築後のクラスタ設定変更は手動ハンネにすることに
- helm は terraform-provider-helm を介してデプロイ
- セキュリティ課題
- サービスの価値に直接影響するようなことをしている気がした。
- 大規模なアーキテクチャ改善、しかも構成図の一部を出している。
- キャリアめちゃくちゃ強そう
- ADR
- ナラティブスタイル
- 口頭の説明が要らず、ドキュメントを見れば完結する
- レジリエンステスティング
- 予期していない状態でシステムがどのように振る舞うか。
- AWS Fault Injection Service
- 感想
- ECSからEKSへ移行する理由にはリソースセットが理由になった。という話は興味深かった。確かに考えてみるとその通りだ。K8sはリソースコントロールがしやすい面があるかもなという収穫があった。
- ADRの話で出てきた"ナラティブスタイル"という手法に興味を持った。口頭の説明が要らず、ドキュメントを見れば完結するというのは確かに理想的なADRだ。
横断SREの立ち上げと、AWSセキュリティへの取り組みの軌跡
- 過去資料
- どちらかというと、エンジニアがコードをガリガリ書きやすいようなセキュリティをやっている
- マルチクラウドの管理ためにSecurityHubじゃなく、SHISHO Cloudを使っている
- Embbed SRE 向けに情報共有の場を設ける。
- SecurityHubは触ったことあるが、運用が回ってないのが多い
- 運用課題
- わかりにくい、誤検知...
- 運用課題
- 感想
- SecurityHubの運用が回ってないという話は経験があるので同感した。特に有効化した初期は大量のアラートが出て何から手をつけたらいいかとか、膨大すぎて心理的なハードルが大きくて困る。
- マルチクラウド体制なら確かに一元的に管理できるCSPMは欲しい。
SREじゃなくてもできる！インシデント対応で鍛えたCREチームの5年史
- PdMがインシデントコマンダーをやる
- CREがエスカレーションを受けてSWEに通知
- 普段Bizと連携しているCREが適任だった
- 原因分析には原因種別の整理フロー図を用いている
- QA、QCのチームを作った
- 障害発生原因やチームや工程を分析する
- CREはBizとの連携が強いイメージ
- プロダクトコード、ドメイン知識が頭にある程度入ってないと厳しいと思うがいかがか？
- 日々の開発シーンの関わり方とか気になる
- 分析基盤と活用し、インシデントを開発部門の財産としたい。
- CREはコードの調査まで行う。
- 新機能がリリースされるのであれば、devチームから紹介されたりする。
- SRE DBREはインフラレイヤー
- DBREはmodel層のレビュー
- SREはインフラの設定構築
- SREとDBREは割りと近い。
- CREはBizとプロダクトコード
- CRE が プロダクトに1人ついている状態
- CRE1人あたり、5プロダクトまでというlimitが存在する
- 感想
- PdMがインシデントコマンダーをやるというのが衝撃だった。確かにプロダクトとセールスを総括するような立場で適任な気もするのだが、インシデント発生中にはコマンダー以外にも求められる動きがあるような気がしていて。あとは普通に多忙でMTG中とかありそう。みたいな。
- 組織として層が厚いなと思った。SRE、DBRE、CRE、QA、QCなどプロダクトの開発をメイン進めるチーム以外にこんなにも支えるチームがあるのは開発生産性が高そう。
AWSにおける横断的なログ分析とコストの管理
- SRE teamはフレームワークを提供している。
- dev team はそのテンプレートを利用する
- フィードバックループでテンプレートを育てる
- 1人のSREが2~3のプロダクトを見る
- イベントログに一番着目している
- AWSのイベントログはAWS内に閉じている。
- CloudTrail CloudWatch
- アプリケーションログはDatadogに送信
- Fluentd
- ログのフィルタリングが柔軟に操作できる
- Logging as a Service は便利な反面、コストを意識しなければならない
- アプリケーション例外についてはSentry
- 開発者はSlackのチャンネルを見ながら、開発を行う
- SentryもTerraformで対応している。
- datadog アカウントを横断したアラートの可視化を
srestでできる - コストを信頼性として扱う
- インフラ構築をEnableしていくときとか、メンタルモデルが複雑になって困らないですか？
- 全部SREチームがやっている。
- 今後組織が多くなっていくとインフラ構築はEnableしていくとか考えられるけど、今はない。
- Serverless Framework と Terraform の使い分け
- 感想
- Serverless と Terraform の使い分けは驚いた。LambdaをTerraformでプロビジョニングしようとするとまぁ大変なので、Serverless使うか。ぐらいの温度感で使っているのだがこうした区分けもあるんだなと。
- インフラをフレームワークとして構築してdevチームに提供するのがすごい。Platform Enginneringの理想的な形っぽい気もする。マルチプロダクトになっていくと、特定の要望が出てきたりして、それをフレームワークに組み込む形になるのかなとか。そういった線引きに悩みがありそうだなと思ったりした。
Platform EngineeringがあればSREはいらない!? 新時代のSREに求められる役割とは
- セルフサービス機能とインフラストラクチャ・オペレーションの自動化をし、開発体験を上げていく
- Platformチームは提供するサービス・ツールを利用しない。
- 実際のユースケースとツールの距離
- サービスチームの生産性が上がりづらい
- たくさんあるツールを理解
- 日々のメンテや更新
- 開発チームの一員として開発者のからのフィードバックを集める
- メルカリハロを作りながらPlatformに飛び込んで状況や思想を理解
- Early Adaptor になった。
- Hallo SRE 1人、 Hallo Backend 1人 メルカリSRE1人
- 隠蔽化されている抽象化レイヤーへの理解が必要。
- メルカリSRE が Platform を提供していて、Hallo SRE として Platform に飛び込んだということ。
- 追加して、フィードバックループを回すための工夫を教えてほしい。
- SRE は Platform の活用のスペシャリストなの？手先なの？
- Platform が発展していくことで、SREの非機能要件のカバー範囲が減る
- Platform が Reliability を担保してくれる。内包してくれる。
- 感想
- Early Adaptorがいるのはよい。Platformを構築していく上でエンジニアのフィードバックがもらえない状況は辛い。広範にアンケートを取ってもアンケートの設計だったりPlatformへの興味を持ってもらえないとうまく回らないので、いい状況だなと思った。
あなたの興味は信頼性？それとも生産性？ SREとしてのキャリアに悩むみなさまに伝えたい選択肢
- そもそも信頼性ってなんだったか
- 信頼性を上げる最も効率の良い方法
- 何もしないこと -> 何かするから障害が起きる
- 信頼性を上げる最も効率の良い方法
- 大きな会社だから Platform Enginerring が必要になっていくんでしょ？
- そうではない。
- 開発者がアプリをエンドツーエンドでデプロイし、実行するのが理想
- Platform チームが必ずしもX-as-a-Service をするわけではない。
- 理想はそれ。だけどそれよりも前にいろんな関わり方があるでしょ。
- DevOps は Platform Engineering と読み替えても良い。
- タイトル的にはSREだけどやっていることはPlatform Engineeringということもままある。
- それぞれの定義は定義で理解しつつもの、実態としては調整すればよい
- ちっちゃいチームはSREがPEみたいなことをしたりもするでしょ？
- 自分のモチベが右から左なのか、左から右なのか考えていた方がいい。
- そうすることで適した情報源に当たりやすくなる。
- Platform 的なツールにAI agentを入れる可能性
- 感想
- Platformが必ずしもX-as-a-Serviceをするわけではないという指摘が良かった。教科書通りにやろうとして、X-as-a-Serviceに固執してしまわないようにする。
- Platform と SRE の関心の方向性はなるほど。と思った。完了したら最初に戻ってボトルネックを最適化というループを意識していきたい。
Discussion