はじめに
freee会計のイベントに参加しましたので、その感想や要約を書きました。
https://freee-tech-night.connpass.com/event/388524/
#概要
今回行った確定申告期間を乗り切るためのインフラ施策
日常的に開発チーム内部でインフラ改善に取り組み続ける『インフラ管理組合』といった委員会活動
解決が難しいプロダクト固有の課題を開発チームに入り込んで解決する『Embedded SRE』としての取り組みエピソード
発表内容
毎年2〜3月の確定申告時期は、かなりアクセスが集まる。
今年はSREチームではなく、プロダクトチームが主体的に対応した。
確定申告はfreeeのエンジニアとしては、繁忙期のお祭りである。
今年は例年よりもトラブル(障害など)は少なかった。
しかしトラフィックは例年より少し多かった。
プロダクトチームが主体的になってもアラートが少なく、スムーズな期間になった。
プロダクトチームでアプリの改善をしたため、トラフィックが増えてもスケールアップをする判断をしなかった。
今年のインフラ管理は、会計チームが対応して、SREチームはその支援(キャパシティプランニングの設定など)をした。
キャパシティプランニングはDBのスケーリングやAIのクォーターの設定や見積をした。
AI駆動で動くシステムが増えたため、AIのキャパシティを考えないといけなくなった。
プロダクトチームとSREチームのコラボレーションがしっかりできたことが良かった。
年々トラフィックとコストが増えているため、コストを注意した。
インフラ組合はダッシュボードでトラフィックを確認していた。
オートスケールがないものでもアラートが来たら、オートスケールを追加してた。
これらの取り組みは、確定申告以外でも対応できそうな感じ。
アプリ側がキャパシティプランニングをすることで、PdMを巻き込むことができ、効率よくできた。
この体制になるまで、3年ぐらいかかった。
API単位のキャパシティプランニングは、SREよりもプロダクトチームが効率がいいと感じた。
Embedded SREがいた事で、SREとプロダクトチームのコラボレーションが効率よく進んだ。
リソースの重み付けやトラブル対応をSREに支援してもらった。
最終的にはプロダクトチームが、SREなしでも自立できることを目指した。
プロダクトチームにインフラ権限を移譲する事はスムーズにできた。
理由は、SREチームはプロダクトチームのインフラに詳しい人に渡す制度整備を進めていたから。
インフラの権限渡す人は、プロダクトの危険操作やダッシュボードを見て判断ができる人を対象にした。
DBスケールアップを今年はやらなかった。
今年は日々の改善によって、スケールアップをしなくてもいいと判断した。
しかし緊急時のため、スケールアップができるような体制を構築してた。
今回のこのような取組ができたのは、インフラ管理組合がモニタリング体制をちゃんとしてたため。
インフラ管理組合の誕生秘話は、2年前の確定申告でDBの負荷を軽減することを目的に生まれた。
そしてDB管理以外にも対応するようになった。
確定申告の具体的な改善
DBの状態をモニタリング検索して、改善対応した。
アラート(通知)もいらないものを削って、取捨選択していった。
SREチームもアプリを直接触って改善をした。
確定申告期間中のトラフィック
毎日トラフィックを確認していたが、急激なトラフィックは少なった。
そのためお客様に迷惑をかけることがなかった。
質問タイム
インフラ管理組合は誰でもなれる？
会計チームに携わっているなら誰でもなれる。
平常期間中のインフラ管理組合は、インフラの改善業務をしている。
負荷の高いクエリを監視するのは大変だった？
毎日見ていると慣れて、すぐに判断ができるようになった。
DBが死んだらどうしてた？
後からのDBスケールアップやフェイルオーバーは、設定したSLOを基準に行う事を考えていた。
トランザクションや秒ロックの振り返りは何使った？
DataDogを使った。
確定申告の振り返り
日頃から監視して改善をすることで、確定申告時期を乗り越えることが理想。
今回DBスケールアップをしなかったことが、理想に近づけた気がした。
会計のマイクロサービスにはたくさんのプロダクトチームがあるため、まだまだ理想は完璧ではない。
しかし今回の確定申告時期は大きな一歩になった。
今後やってみたいこと
SREチームが今後、プロダクトチームでキャパシティプランニングができるように整備していきたい。
プロダクトチームは、自分たちでもEmbedded SREような活動をして、自分たちでも信頼性を高めていきたい。
今後のイベント
次回は6月に開催！！！