目の前に僕らの道がある

勉強会とか、技術的にはまったことのメモ

JAWS-UG SRE支部 #2 突撃!となりのSRE

jawsug-sre.connpass.com

聞いてきましたのでメモと感想を残しておきます。

LT

マネーフォーワードのマイクロサービス基盤のこれまでとこれから by マネーフォワード @grezarjp

マネーフォワードのマイクロサービス基盤の移り変わりの紹介。中央集権構造 => 権限移譲フェーズ => これから

  • 中央集権構造
    • サービスごとに開発チームが存在、サービスにまたがってインフラチームが存在
    • 開発チームはインフラを気にしなくてもすんだ。メンバーが少ないうちはなんとかなった
    • 組織の規模に対してインフラチームがスケールしなくなった
    • 責務の分解点を再定義 DevOpsへ
  • 権限移譲フェーズ
    • 開発チームに権限を渡していく
    • AWSとKubernatesを使用
    • ランタイム、ミドルウェアも開発チームが管理
    • サービスごとにNamespaceを切る、Namespace内で開発チームは権限を持つ
    • マイクロサービスごとにAWSアカウント管理して、リソースを管理する
  • これから
    • 権限は渡したが、運用まではむつかしい
    • 開発の運用を負荷を下げるために
      • Terraformのモジュール化、設定のバリデーションの整備
      • AWSアカウントの統制、コスト可視化を進めたい
      • アプリケーションランタイムのSnadbox化
        • 特殊要件なアプリケーションで使えるように

開発チームにここまでインフラの権限を渡せて、運用できるのはすごいなと思った。

  • QA
    • Q: 開発チームの権限移譲の苦労、運用面、技術面
    • A: マルチアカウントをつかって 技術上の考慮点があった
    • 人と人とのかかわりに関しては銀の弾丸はないので、地道な作業が必要
    • ドキュメントとかで監視項目を揃えてあげるのに力を入れた
    • Q: 開発とインフラでスキルセットの違いはあった?
    • A:インフラはアプリをあんまり見てこなかったのでそのへんのギャップはあった
    • Q: EKSのテナント分割の単位
    • A: 権限分類と障害の影響範囲の最小化はシングルテナントが有利とは言われるが
    • 運用負荷を下げるためにマルチテナントを選んだ

SREグループのマネージャーという立場になって真っ先にやったこと by ミクシィ@isaoshimizu

内容に関しては、スライドに詳しく書いてあるので参照。

SREのミッション・バリューいいなあと思った。うちのチームでもちゃんと考えたい。

SRE Lounge #13 LTでも今回と近いことを書いてるので参照してほしいとのこと↓

組織にSREの文化を作り上げていくEnabling SRE | Money Forward Engineers' Blog

  • QA
    • Q: SRE主導でやるべきではなかったこと
    • A: SREは万能な人がおおくでできてしまう
      • 開発側のリソースが足りなくて急がないといけないことをSREがやってしまう
      • 本来はそうじゃないよねって話

自分としては、SREでも開発分野でも巻き取れることはやってしまってもいいと思うんですよね。線を引きすぎるとセクショナリズムになってあまり良くない気がしてる。組織のあり方はそれぞれで、コンテキスト分かってないので、言い切ることはできないですが。

Containerサービス と Toil と by スリーシェイク  @tt0603

ECSとEKSについてToilと紐付けての話題。

  • Toilの削減ステップ
    • 特定
    • 計測
    • 削減

ただこのプロセスはつらい。

SREとしては長期的なエンジニアリング に時間を使いたい。本質的なことをすることが目的。Toilを削減することが目的ではない。

技術選定として、まずマネージドで考える。チームとして何を大事にしているかを考える。自分たちの”サイズ”で技術選定をして価値あるエンジニアリングをする。

個人的にはEKSとECSのまとめがわかりやすくてよかった。

  • QA
    • Q: セルフホステッドを選択する場合は?
    • A: 監視するとき Prometheus使うときとかつらいので
    • Fargateは起動が遅い スケールが遅い

パネルディスカッション

  • MFのSREの組織のやり方で工夫してるところ

  • 技術支援からSREの組織

    • 変数がいくつか システムの規模 性質 組織規模、レベル感など
    • pure sreではじめて権限移譲していく
    • 自分たちのサイズに合わせて組織を作っていく
  • 開発とSREのベストの距離感

    • タイミングによって違う固定されたものじゃない
    • 構成をいかにシンプルにできるかが大事
    • SREが開発に使いやすいサービスを提供する
    • SREのAPIを提供するので好きに使って的な
    • 横断組織SREと開発チーム内SREというパターンもある
    • お互いのコミュニケーションは大事
  • 採用する際に求めるスキルセットやレベル感

    • なんでもかんでも能力を持ってる人はいない。特定の領域に得意を持ってるといい、最低限のレベル感はほしい
    • コミュニケーション 大事 ソフトスキルの担保が大事
    • 会社のバリューにあってるか
    • SREワークブックの最後の方求められるスキル書いてある
    • すべてのインフラコードはIaCに寄せたい、チームにはソフトウェアスキル、インフラスキルそれぞれ持つメンバーがほしい
    • 変更時のトラブルシューティングはできるべき
    • コードレビューできるスキルを持っていてほしい
    • コーディングあるていどできる人
    • 組織による
  • 開発をSREに興味をもってもらうはどうしたらいいのだろうか

    • SLOを決めて共通言語で話す
    • 留学すると面白いかも
      • お互いがどういう観点で仕事してるかがわかってよい
    • どこまで開発に移譲するか
      • エラーバジェット、SLO、SLIは必要
      • SREが設定するSLOより開発者が設定するSLOの方がいい
      • 開発者にとってうまいところを教えるアプローチ
      • 開発者にとってもバグが出ないことによって、気持ちよく開発できるよ!

開発者の観点じゃなくてビジネス観点でSLO設定するんじゃないのかなって思う。。。?

あと、留学いいなあと思った。開発チームに留学したい。

  • SREチームが存在しない。どんなフェーズになったらSREチームを作ったほうがいいというしきい値あります?

    • 開発者が開発以外に手を取られて開発スピードが落ちてるのが目に見えたら
    • 兼務の限界値がある。得意なことにバリューを出せるようにしたい
    • 開発しながらAWSの新機能をキャッチアップするのはたいへん
    • devとopsのバランスが崩れているとき SREのプラクティスをいれるといいのかも
    • エラーバジェットが判断軸になるかも
    • どれくらいのチームが困ってるかが判断軸になる
  • Toil撲滅の意味で費用対効果高かったLambdaランキング

    • 今Lambdaを殆ど使ってない
      • chatbotが出たのでLambdaの役割を終えた
      • EKS上にアプリケーションを作ってしまうことが多い
    • 必要悪としてのLambda コードを書くのは最終手段。書いた瞬間に負債になる
    • 時刻でEC2終了するLambda
      • オートスケーリングでいいのでは?
    • terrafromでLambda扱いにくい問題
  • SREとしてセキュリティに対しての役割サービス

    • Inspector
      • ECRのイメージスキャン
        • CI/CD成立してからじゃないとイメージスキャンできない
    • GuardDuty
    • SSO
      • IAM Userを撲滅できた
      • ただ個別要件に対応しにくい
    • SREが見てるケースが多い
    • コーポレートセキュリティは範疇じゃないが、アプリケーションセキュリティは範疇
    • 5,6人目にセキュリティが強い人がほしい
    • 着想の段階からセキュリティの観点をいれておきたい
  • モニタリングロギングの観点で使用してるAWSのサービス

    • AMP
      • EKS使ってるので
      • コスパが良かった
    • CloudWatch log
      • 通知考えるとLambda使わないと
    • Athena
      • わずらわしい
      • 検索しにくい
      • Lokiとかに寄せたい
    • ログをどこにおく
      • S3

Lokiってこれかな?

雑感

他の会社のSREの話を今まであまり聞くことがなかったので、気づきを得る部分が多かった。SREのミッション・ビジョン・バリューはちょっと考えてみたいなと思った。

オンライン開催の形式はYouTube Liveがいいなあって思った。聞き逃しても巻き戻して聞き返せるのがすごい体験として良い。