聞いてきましたのでメモと感想を残しておきます。
LT
マネーフォーワードのマイクロサービス基盤のこれまでとこれから by マネーフォワード @grezarjp
マネーフォワードのマイクロサービス基盤の移り変わりの紹介。中央集権構造 => 権限移譲フェーズ => これから
- 中央集権構造
- サービスごとに開発チームが存在、サービスにまたがってインフラチームが存在
- 開発チームはインフラを気にしなくてもすんだ。メンバーが少ないうちはなんとかなった
- 組織の規模に対してインフラチームがスケールしなくなった
- 責務の分解点を再定義 DevOpsへ
- 権限移譲フェーズ
- これから
- 権限は渡したが、運用まではむつかしい
- 開発の運用を負荷を下げるために
- 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は起動が遅い スケールが遅い
技術選定において、自分たちの「サイズ」っていう要素が存在するというのは暗黙的なものになりがちなので、ちゃんと具体的に捉えておくの大事な気がした。 #jawsug_sre
— Tomoya Kitaura (@kitta0108) 2022年2月25日
先程はパッと答えられませんでしたが、弊社の場合はMicroServiceを運用する際にはIstioを利用するケースが非常に多く、現状では対応していないため、EKSの場合はSelf Hostedを利用するケースが多いですー#jawsug_sre
— TakuyaTezuka@3-shake (@tt0603) 2022年2月25日
パネルディスカッション
MFのSREの組織のやり方で工夫してるところ
- もともと中央集権的だった、開発に権限移譲していった
- 権限を渡していっていながらそれ以上にプロダクトが開発が増えてしまったので負荷が増えてしまった
- enabling SREを広げる役割もつくる
- SREというポジションじゃなくてもSRE的な動きができるように
- 組織にSREの文化を作り上げていくEnabling SRE | Money Forward Engineers' Blog
技術支援からSREの組織
- 変数がいくつか システムの規模 性質 組織規模、レベル感など
- pure sreではじめて権限移譲していく
- 自分たちのサイズに合わせて組織を作っていく
開発とSREのベストの距離感
- タイミングによって違う固定されたものじゃない
- 構成をいかにシンプルにできるかが大事
- SREが開発に使いやすいサービスを提供する
- SREのAPIを提供するので好きに使って的な
- 横断組織SREと開発チーム内SREというパターンもある
- お互いのコミュニケーションは大事
採用する際に求めるスキルセットやレベル感
- なんでもかんでも能力を持ってる人はいない。特定の領域に得意を持ってるといい、最低限のレベル感はほしい
- コミュニケーション 大事 ソフトスキルの担保が大事
- 会社のバリューにあってるか
- SREワークブックの最後の方求められるスキル書いてある
- すべてのインフラコードはIaCに寄せたい、チームにはソフトウェアスキル、インフラスキルそれぞれ持つメンバーがほしい
- 変更時のトラブルシューティングはできるべき
- コードレビューできるスキルを持っていてほしい
- コーディングあるていどできる人
- 組織による
開発をSREに興味をもってもらうはどうしたらいいのだろうか
- SLOを決めて共通言語で話す
- 留学すると面白いかも
- お互いがどういう観点で仕事してるかがわかってよい
- どこまで開発に移譲するか
- エラーバジェット、SLO、SLIは必要
- SREが設定するSLOより開発者が設定するSLOの方がいい
- 開発者にとってうまいところを教えるアプローチ
- 開発者にとってもバグが出ないことによって、気持ちよく開発できるよ!
開発者の観点じゃなくてビジネス観点でSLO設定するんじゃないのかなって思う。。。?
あと、留学いいなあと思った。開発チームに留学したい。
SREチームが存在しない。どんなフェーズになったらSREチームを作ったほうがいいというしきい値あります?
Toil撲滅の意味で費用対効果高かったLambdaランキング
- 今Lambdaを殆ど使ってない
- chatbotが出たのでLambdaの役割を終えた
- EKS上にアプリケーションを作ってしまうことが多い
- 必要悪としてのLambda コードを書くのは最終手段。書いた瞬間に負債になる
- 時刻でEC2終了するLambda
- オートスケーリングでいいのでは?
- terrafromでLambda扱いにくい問題
- 今Lambdaを殆ど使ってない
SREとしてセキュリティに対しての役割サービス
- Inspector
- ECRのイメージスキャン
- CI/CD成立してからじゃないとイメージスキャンできない
- ECRのイメージスキャン
- GuardDuty
- SSO
- IAM Userを撲滅できた
- ただ個別要件に対応しにくい
- SREが見てるケースが多い
- コーポレートセキュリティは範疇じゃないが、アプリケーションセキュリティは範疇
- 5,6人目にセキュリティが強い人がほしい
- 着想の段階からセキュリティの観点をいれておきたい
- Inspector
モニタリングロギングの観点で使用してるAWSのサービス
- AMP
- EKS使ってるので
- コスパが良かった
- CloudWatch log
- 通知考えるとLambda使わないと
- Athena
- わずらわしい
- 検索しにくい
- Lokiとかに寄せたい
- ログをどこにおく
- S3
- AMP
Lokiってこれかな?
雑感
他の会社のSREの話を今まであまり聞くことがなかったので、気づきを得る部分が多かった。SREのミッション・ビジョン・バリューはちょっと考えてみたいなと思った。
オンライン開催の形式はYouTube Liveがいいなあって思った。聞き逃しても巻き戻して聞き返せるのがすごい体験として良い。
