ChatworkのSRE部って実は 半分くらいPlatform Engineering部かもしれない

Platform Engineering Meetup #8
https://platformengineering.connpass.com/event/310994/

Transcript

1. © Chatwork ChatworkのSRE部って実は 半分くらいPlatform Engineering部かもしれない Chatwork株式会社
2. 自己紹介 2 • 古屋 啓介 ◦ Chatwork株式会社 CP本部 プロダクト開発ユニット SRE部 ◦ JAWS-UG SRE支部運営メンバー ◦ Platform Engineering Kaigi 2024運営メンバー ◦ ドラム叩きます
3. 会社概要 3 会社名 Chatwork株式会社 代表取締役CEO 山本 正喜 グループ従業員数 463名（2023年12月末日時点） 所在地 東京、大阪 設立 2004年11月11日
4. コーポレートミッション 働くを もっと楽しく、 創造的に 人生の大半を過ごすことになる 「働く」という時間において、 ただ生活の糧を得るためだけではなく、 1人でも多くの人がより楽しく、 自由な創造性を存分に発揮できる社会を実現する 4
5. • 新社名は株式会社kubell (読み：クベル)。3月27日に実施される株主総会の承認を経て、2024年7月に社名変更を実施予定。 • 当社の事業はビジネスチャット単体から、ビジネスチャットを包含するBPaaS事業へと大きく拡大 • グループとして成長する企業群への展開を目指す意志をこめ、社名変更を実施予定 トピック：社名を「kubell」へ変更 5 すべての働く人の心に、薪を「くべる」存在へ。 そのような企業でありたいという想いと決意を、新しい社名に込めています。 株式会社kubell　 kubell Co., Ltd. https://corp.chatwork.com/ja/kubell/ 特設サイトを公開中
6. まえおき 0
7. まえおき（1/3） 7 • なぜ「ChatworkのSRE部って実は半分くらい（略」なのか ◦ Platform SREが一番近いよね、という話を以前からしていた ◦ Platform Engineeringということばが出てきて、よりフィットしそう https://x-tech5.co.jp/2022/02/21/204/
8. まえおき（2/3） 8 • 先人の知恵があるなら乗っかりたい ◦ ただし、何も考えずに乗っかるのはNG ◦ 開発チームとの対話のネタにすればよさそう ▪ いちばんは開発者に気分良く使ってもらえるPlatformを提供すること
9. • おはなしすること ◦ ChatworkにおけるPlatform Engineeringっぽい事例 ◦ Platform Engineeringの考え方をこれからどう適用していくか ▪ Platform Engineer(ing)としてはまだまだ駆け出しひよっこ まえおき（3/3） 9
10. 現状と課題 考えていること まとめ 1 2 AGENDA アジェンダ 3
11. 現状と課題 1
12. • ちいとぽでいうとPlatformチーム ◦ Chatworkユーザに対してのインフラ運用保守 ◦ 開発者に対しての開発環境整備改善 ◦ （あれ？SREは？） Chatwork SRE部の現状（1/2） 12
13. • 守備範囲 ◦ インフラ ▪ EKS、HBase、Kafka、etc... ◦ 開発環境やエコシステム ▪ Argo CD、GitHub Actions、etc… Chatwork SRE部の現状（2/2） 13
14. おさらい: Platform Engineeringとは（PFEM#1より） 14 https://speakerdeck.com/jacopen/platform-engineeringhenozhao-dai?slide=8
15. • 守備範囲 ◦ インフラ ▪ EKS、HBase、Kafka、etc... ◦ 開発環境やエコシステム ▪ Argo CD、GitHub Actions、etc… よくよく考えると... 15 開発者体験と生産性を向上させるセルフサービスなツール を提供できているのでは？
16. • 課題 ◦ AWS検証環境がひとつしかなく、開発者間で利用順番待ちが発生 ChatworkにおけるPlatform Engineeringっぽい事例（1/2） 16 これ、なくしたいな？
17. • 対策 ◦ コマンドひとつでPR環境を生成できる仕組みを構築 ChatworkにおけるPlatform Engineeringっぽい事例（2/2） 17 開発者 Application PR Manifest (helmfile) Charts ECR EKS (manager) Sync 1. Comment 2. Build 4. Update & Create PR 3. Push 6. kubectl apply helmfileから生成された Manifest 5. Polling EKS (app)
18. くわしくは 18
19. • 開発者が新しく考えること（認知負荷？）を増やさない ◦ 自動化・自動化・自動化 ▪ 「コマンドひとつで起動」は死守 ▪ PRを閉じたら自動で環境削除 意識したこと 19
20. • 検証環境順番待ちの解消！ ◦ 多くのチームでたくさん使ってもらえている ▪ （むしろ使われすぎてコストが...そこは別途対応） 結果 20
21. • 検証環境順番待ちの解消！ ◦ 多くのチームでたくさん使ってもらえている ▪ （むしろ使われすぎてコストが...そこは別途対応） 結果 21 めでたし、めでたし？
22. • たまたまうまくいった ◦ 次にやることもこれくらいうまくいく？ • 施策が場当たり的 ◦ 次なにやるの？ほんとにそれが一番の困りごと？ • 計測ができていない ◦ どれくらい効果があったの？ 課題 22
23. 考えていること 2
24. • たまたまうまくいった ◦ 次にやることもこれくらいうまくいく？ • 施策が場当たり的 ◦ 次なにやるの？ほんとにそれが一番の困りごと？ • 計測ができていない ◦ どれくらい効果があったの？ そもそも... 24 ユーザ（開発者）へのヒアリング不足
25. ユーザ（開発者）へのヒアリング不足 を • たまたまうまくいった ◦ 次にやることもこれくらいうまくいく？ • 施策が場当たり的 ◦ 次なにやるの？ほんとにそれが一番の困りごと？ • 計測ができていない ◦ どれくらい効果があったの？ そもそも... 25 Platform Engineeringの観点を使ってよりよくできないか
26. • ポータル（IDP） ◦ 現状 ▪ ない ◦ 思い ▪ 下記にもあるけどまずはドキュメントから • ゴールデンパス ◦ 現状 ▪ あるようなないような... ◦ 思い ▪ 新しく入った人向けのパスはあってもよさそう（単純にドキュメント整備不足） Platform Engineeringの観点（1/3） 26
27. • 開発環境 ◦ 現状 ▪ PR環境！ ◦ 思い ▪ 継続的に改善していきたい • o11y ◦ 現状 ▪ やってるチームとやれてないチームの差がありそう ◦ 思い ▪ やれてないチームをサポートしたい Platform Engineeringの観点（2/3） 27
28. • セキュリティ ◦ 現状 ▪ 権限付与とガードレールで運用中 ◦ 思い ▪ セキュリティ専門部署もあるので要相談 • インフラ構築 ◦ 現状 ▪ terraform + atlantisによるセルフサービス運用中 ◦ 思い ▪ terraformの知識が必要という点は認知負荷になってそうだけど、どうするか... Platform Engineeringの観点（3/3） 28
29. • 以下を軸に対話していけばよさそう？ ◦ PR環境やArgo CDデプロイ周りのドキュメントに困ってないですか？ ◦ Datadog APM、使えてますか？ ◦ インフラの構築で迷うところはないですか？ ◦ その他開発運用するにあたって省力化できたらな、というところはありますか？ ▪ 開発を効率よく進めることを阻害するようなもの ▪ SRE部に都度相談しないとできないもの（セルフサービスになっていないもの） ヒアリングのネタ 29 うちではこんなことやってるよ！っていうのも 教えてもらえると嬉しいです
30. • ヒアリング • 施策の検討 • 優先順位決め • ロードマップの策定 今後やりたいこと 30
31. まとめ 3
32. ChatworkのSRE部って（略 • PR環境をコマンドひとつで構築する仕組みを運用中 ◦ 開発者体験と生産性を向上させるセルフサービスなツールを提供できてそう • いちばんは開発者に気分良く使ってもらえるPlatformを提供すること ◦ 対話のネタとしてPlatform Engineeringの観点を使っていきたい 32
33. 働くをもっと楽しく、創造的に