プラットフォームってつくることより計測することが重要なんじゃないかという話 / I think it's more important to measure a platform than to create it

Transcript

1. 2024年4月19日 株式会社コドモン 佐々木真也 プラットフォームってつくることより 計測することが重要なんじゃないかという話 Platform Engineering Meetup #8
2. 2 • 名前 ◦ 佐々木真也 • 所属 ◦ 株式会社コドモン ▪ 2023年11月〜 ▪ SREチーム • X ◦ @taishin 自己紹介
3. 3 Mission
4. 4 すべての先生に 子どもと向き合う 時間と心のゆとりを こんなプロダクトを開発しています メインプロダクトは、保育・教育施設向けWebアプリケーション。 保護者と施設のやり取りを支えるモバイルアプリケーションや、施設職員向けモバイル版 アプリケーション、外部サービスと連携するAPIなども開発しています。
5. 5 導入施設数推移（ICT） 2021年4月 8,000 2020年4月 5,200 2019年4月 3,000 2018年4月 1,500 2017年4月 500 2016年4月 120 全国導入数 18,000 施設 2022年2月 11,000 18,000 2024年3月 （2024年3月時点） 14,000 2023年4月
6. コドモンSREチームにおける プラットフォームエンジニアリング
7. 7 • 最重要課題は開発者の認知負荷を減らす • なるべく聞かなくても、依頼しないでもできる環境を目指す ◦ チームトポロジーのX-as-a-Service • 新しいものをつくるより、自分たちのプラットフォームを定義した ◦ これやるときはこれ ◦ それできないっていうのがはっきりしてるだけでも認知負荷は減るはず ◦ 強制はしない、開発者自身でメンテしていくなら別のものでもOK 自分たちのプラットフォームエンジニアリング
8. 8 • 提供しているプラットフォームが ◦ 使われていない ◦ パフォーマンスがいつのまにか悪くなっている ◦ 開発者の認知負荷の改善に貢献していない 避けないといけないこと 計測が必要
9. プラットフォームにおける計測の考え方
10. 10 https://tag-app-delivery.cncf.io/wgs/platforms/whitepaper/
11. 11 As with other aspects of internal platforms, though, platform teams should use the smallest viable effort to gather the feedback they need. We’ll suggest metrics here but simple surveys and analysis of user behavior may be most valuable initially. How to measure the success of platforms 計測することにそんなにがんばらなくてもいい 最初は簡単なアンケートとユーザー行動の分析でも意味あるよ (意訳)
12. 12 ソフトウェアアーキテクチャメトリクス https://www.oreilly.co.jp/books/9784814400607/
13. 13 • 小さく始める • 重要なことを計測する • 計測に基づいて行動する • 早期に開始する • 計測を可視化する • 計測を継続的に行う 7章 ソフトウェアアーキテクチャにおける計測の役割 • 計測ではなく、仕組みにフォーカスし てしまう • やりやすいものを基準に計測を選択し てしまう • ビジネスの計測よりも技術的な計測に 重点を置いてしまう • 行動を起こさない • 有用性よりも正確性を優先してしまう • 計測しすぎる 7.4 始め方 7.6 落とし穴
14. 14 • 小さく始める • 重要なことを計測する • 計測に基づいて行動する • 早期に開始する • 計測を可視化する • 計測を継続的に行う 7章 ソフトウェアアーキテクチャにおける計測の役割 • 計測ではなく、仕組みにフォーカスし てしまう • やりやすいものを基準に計測を選択し てしまう • ビジネスの計測よりも技術的な計測に 重点を置いてしまう • 行動を起こさない • 有用性よりも正確性を優先してしまう • 計測しすぎる 7.4 始め方 7.6 落とし穴
15. 15 • 小さく始める • 重要なことを計測する • 計測に基づいて行動する • 早期に開始する • 計測を可視化する • 計測を継続的に行う 7章 ソフトウェアアーキテクチャにおける計測の役割 • 計測ではなく、仕組みにフォーカスし てしまう • やりやすいものを基準に計測を選択し てしまう • ビジネスの計測よりも技術的な計測に 重点を置いてしまう • 行動を起こさない • 有用性よりも正確性を優先してしまう • 計測しすぎる 7.4 始め方 7.6 落とし穴
16. 16 • 小さく始める • 重要なことを計測する • 計測に基づいて行動する • 早期に開始する • 計測を可視化する • 計測を継続的に行う 7章 ソフトウェアアーキテクチャにおける計測の役割 • 計測ではなく、仕組みにフォーカスし てしまう • やりやすいものを基準に計測を選択し てしまう • ビジネスの計測よりも技術的な計測に 重点を置いてしまう • 行動を起こさない • 有用性よりも正確性を優先してしまう • 計測しすぎる 7.4 始め方 7.6 落とし穴
17. 計測項目と方法
18. 18 • (開発環境の)パフォーマンスが悪くなっていないか • 使ってもらっているか • 認知負荷は減ったか • 使用感に問題がないか 本来はFour Keysとかで生産性が向上したかを計測するべきかもしれないが、 SREチーム側でコントロールできないことも多いので、一旦は除外した 計測したいこと
19. 19 • (開発環境の)パフォーマンスが悪くなっていないか • 使ってもらっているか • 認知負荷は減ったか • 使用感に問題がないか 本来はFour Keysとかで生産性が向上したかを計測するべきかもしれないが、 SREチーム側でコントロールできないことも多いので、一旦は除外した 計測したいこと 実行時間の計測 回数のカウント アンケート
20. 20 • 計測する項目 ◦ CI/CD パイプライン、Github Actionsの実行時間 • 計測方法 ◦ CodeDeployの実行時間 ◦ Datadog CI Visibility ◦ 実行時間の変動や成功率を可視化 実行時間の計測
21. 21 • 計測する項目 ◦ 使われた回数 ◦ 開発チームからの問い合わせ回数 • 計測方法 ◦ JIRAのチケット • 考慮点/選定理由 ◦ 簡単に始められる ◦ 効果的な取得方法、項目は最初から正確に分からないので、追加の情報が必要 になったときに容易に追加できる ▪ ラベルの付与等 ◦ 手動でも自動でも計測できる 回数のカウント
22. 22 • 計測する項目 ◦ 実際の使用感のフィードバック ◦ その他課題感 • 計測方法 ◦ Google Forms ▪ 定期的に依頼 ▪ 定点観測的に同じ質問 ◦ Slackのpolly ▪ 簡易的な質問 アンケート
23. 実施した計測とアクションの例
24. 24 • 計測したい項目 ◦ CI/CD Pipelineの実行時間 • 計測方法 ◦ CodeDeployの実行時間、成功率を グラフ化 • アクション ◦ SLOを定義し、エラーバジェットに 基づく運用を開始 1.CI/CD Pipelineのパフォーマンス
25. 25 • 計測したい項目 ◦ 新旧のテスト環境利用回数の比率 ▪ 新規に構築したテスト環境があまり使われてないのでは？ • 計測方法 ◦ 新環境(PRベース) ▪ PR発行時にJIRAチケット発行 ◦ 既存環境 ▪ Github Actions実行時にJIRAチケット発行 ◦ それぞれのチケット数を集計し、グラフ化 2.構築したテスト環境が使われているか？
26. 26 • 結果 • アクション ◦ アンケートを実施 ▪ 知らなかった ▪ 使い方を知らない ◦ アピールとドキュメントに注力 2.構築したテスト環境が使われているか？ 既存環境 新環境 既存環境 新環境 理想 現実
27. 27 • 計測したい項目 ◦ 開発チームからの依頼数や問い合わせ数 ▪ 依頼数や問い合わせ数の減少が、開発チームの認知負荷の軽減と言えるの では？ • 計測方法 ◦ Slack上にフォームをつくって問い合わせ受付 ◦ Githubでのレビュー依頼 ▪ → チケットの自動発行 ◦ 個別にもらった依頼 ▪ → 手動でチケット発行 ◦ 内容に応じてラベルを付与 3.開発チームの認知負荷を軽減できているか？
28. 28 • アクション ◦ 依頼の多い項目に対して、依頼せずにできる環境に変更 ▪ 例) • 権限が足りないので付与してほしい ◦ 開発チーム向けの権限を再検討して、権限の許可範囲を広げた • Terraformのレビュー依頼 ◦ tfstateの範囲がなるべく小さくなるように再構成し、開発チーム内でレ ビューできるようにした • 結果 ◦ 徐々に減ってきている ◦ よく分からないので聞かなくなった 等の理由で減っている可能性もあるので、 アンケートでフォロー 3.開発チームの認知負荷を軽減できているか？
29. 29 • アンケート ◦ SREチームに相談しにくい ◦ 深堀り ▪ 相談する場があればいいかも • アクション ◦ Office Hourの時間を設けた ▪ 毎日同じ時間にSREのメンバーがGatherで待機 ◦ アンケートでフィードバックをもらう 4.アンケートの深堀り
30. まとめ
31. 31 • 大事なことは、プラットフォームをつくることではなく、計測することで もなく、計測結果をもとに改善につなげること ◦ 計測することにがんばりすぎない ◦ 最初は何が最適か分からないので、自動化とかいろいろ考える前に手動で でも始めたほうがいい ◦ アンケート結果はヒントがたくさんあるので深掘る まとめ