忙しい方向けサマリ
- EKS化・IaCの浸透・DB改善活動が、ここ数年のfreeeのインフラ事情の主だった動きです。
- 一方で組織・サービスも増えてきており、従来のワンチームSREでは色々と厳しくなってきました。
- 基盤も進化し、課題も変化した。それに伴い、SREの組織構造を、チームトポロジ的に再編しました。
本文
こんにちは、freeeでSREのマネージャをやっている河村です。
freeeは会計年度の開始月が7月となっており一つの節目となっています。加えて今年はfreee創業10周年ということで、一つのマイルストーンとして、freeeのSREの現状と、それを受けた今後の展望について整理してみました。
この数年の中で、EKS化やAurora化といった基盤の刷新が進む一方、プロダクト・組織規模拡大に伴う従来型SREチームのスケール限界が顕在化してきています。それに対し、新しい基盤に合わせた仕組みの開発に加えて、現在の組織規模に見合ったSRE再考活動が進んでいます。
組織成長に伴うスケールの問題は、世間の多くの企業がそれぞれのステージで直面する課題であり、freeeも例外では有りませんでした。解決への道は平坦なものではなく、今後も数多くのチャレンジが予想されます。本稿はその途上の一例として、参考にしていただければ幸いです。
freee SREの成り立ち
私は社歴5年ほどなので、それ以前の話は、当時からいるメンバーからの情報と当時の資料を元に、ある程度想像で補完しています。特に異論がなかったので概ねあってそうです。
SREを名乗り始めたのは2017年のはじめの頃のようで、それまでは情シス、データ基盤、業務向け基盤など、基盤・インフラ系ひとまとめのチームだったようです。
そもそもにおいて、創業期の開発規模の小さい段階は、チームを分ける余地はなく、開発、そして場合によっては営業・経営、全てを織り交ぜた１チームであったと思われます。そこから、組織が徐々に大きくなり、複数プロダクトを開発するようになってきてから、効率化の観点からある程度共通化できる基盤部分を切り出した、横断チームという形で誕生したのが上記のインフラチームです。
更にこのインフラチームから、サービスのインフラの構築・運用を担うチームとしてSREが生まれたというのが経緯で、基本的にはこれが今のfreee SREの原型であり、責務という意味では誕生当時から今まで大きく変わっていません。
SRE、freeeの成長、そして顕在化する組織課題
以下はfreeeのプロダクト・組織の規模推移を示しています。
前述の通り、freeeのSREは単一の中央集権的チームであり、すべてのプロダクトに対して責務を持っています。つまり、新しくプロダクトが増える毎に、担当がつき、インフラ構築を行い、運用環境を整備し、運用自体はなるべくSRE全員で対応する、というようにしていきました。
結果、プロダクトの増加に合わせて負荷も増えていくので、SREも人数を増やして、プロダクト数増加への対応、既存基盤の保守改善、そして次世代基盤移行を並列で回していきました。その結果、私の入社した2018年初頭から現在までに、メンバーの総数は4倍以上になっています。
しかしこの枠組みも、プロダクトの数が一定以上なってくると、SREの受け持つ責務が広がりすぎ、認知負荷の増大することで、対応の限界が見えてきています。
従来型のSREでは、単純増員でサービスの増加に対応するのは難しく、freee全体としての生産性のボトルネックになってしまう可能性が出てきました。
こういった背景を受けて、現在freeeのSREは、自分たちの在り方とfreee全体としてのSREの実現という視点で議論を続け、変革の最中にあります。具体的には、SREのチーム再編と、プロダクトチームへのSRE機能移譲による、プロダクトライフサイクル完結型チームの実現に向けた活動です。
freeeの基盤技術変化
現在のSREの組織体制の説明に移る前に、この数年での技術的変化について触れておきたいと思います。 振り返ると様々な変化が有りましたが、主なところでいうと基盤の刷新とIaCの推進、また、DB改善活動の活発化が挙げられます。
基盤刷新(EKS化)
2018年の頭頃、freeeではコンテナ化の動きが始まった頃で、Kubernetes clusterをEC2上に構築・運用し、一部の新規プロダクトにパイロット採用したり、本格稼働に向けた周辺コンポーネント(monitoring, security, deploy、cluster管理、etc)の技術検証を進めたりしていました。その後2019年にEKSのTokyo region GAに合わせてEKS移行し、さらに3年ほどを費やして、昨年2021年に、主要プロダクトのEKS化を完了しました。
このあたりのエピソードは、弊blogの記事 もご参照下さい。
それなりに長く、失敗も多くあり、また現在進行系の課題もありますが、得られるものも多く有りました。以下は実感として得られたメリットです。
旧環境が刷新された
EKS化以前もある程度共通化された仕組みは有りましたが、長く使っていると複雑化・特殊化によって保守性は徐々に悪化していきました。もちろん改修は続けていたのですが、基盤刷新PJの後半になってくると、特に規模の大きいサービスは専用の仕組みも多々入り込み、修正するのにもかなり気を使うようになっていました。
仕組みが刷新され、またKubernetesの提供する枠組みにのることで、よりシンプルな管理・運用に移行することができました。加えて、新旧システムを並列メンテする必要がなくなりリソースの集中ができるようにもなりました。
障害が減った
freeeで発生した障害でそれなりに重篤なもののうち、主にインフラレイヤが原因の障害の数の推移を示したのが以下の図です。
ここ1年ほどで減少を続け、なんと前Qは0件でした。EKS化という過渡期があったというのもありますが、EKS化以前は頻発していた、デプロイやプロビジョニングに関連する障害がだいぶ減った印象です。
例えば以下の図はslackのfreee会計のdeploy channelでのSREへのメンション数です。deployは基本的にDeveloperがオーナーですが、トラブル時はSREが対応していました。それが、EKS化以降はかなり低くなっています。
宣言的構成管理でのdeploy、self healingやauto scalingなどのKubernetesの提供する仕組みが期待通り効果を発揮した印象です。
IaC
基盤刷新に合わせてIaCも進みました。現在、freeeの殆どのインフラはterraformで構成管理されています。IaCのメリットは一般的にも広く説明されていますが、特に体感している部分を挙げます。
標準化が進んだ
構成が整理され、自社固有・サービス個別の特殊事情が減り、オンボーディングや認知負荷の軽減が実現、また、標準化により、仕組みの横展開が容易になりました。
例えば、Argo CDや、同じくArgo familyのArgo RolloutsによるCanary deployは、ファーストリリース後の第二のプロダクトへの適用は、開発チームがDocとSREのサポートを受けながら実施することができており、かなりスムーズに実現できました。
Argo CDの導入に関するエピソードは、興味あればこちらの記事を参照ください。
移譲がすすんだ
アプリケーションの実行環境、例えば環境変数やミドルウェアのバージョン管理はSREの領域でしたが、EKS化により、Dockerfileとmanifestを開発チームが主体的にメンテしていくことになりました。結果、これまで発生していた、設定変更依頼と動作確認依頼のコミュニケーションが不要になり、設定待ちの解消によってリードタイムが短縮、SRE側も問い合わせの負荷が減る、といった効果が得られています。
同様に、SREへのインフラ改修依頼も、PRベースで受けることが増えてきています。以下はSREへの問い合わせ内容に関する分析ですが、現在最も多い依頼カテゴリーはPR review依頼です。
DB改善活動
これまではサービス・組織の数に起因する課題由来の話が多かったですが、一方でサービスそのものの規模の拡大により顕在化してくるものとして、パフォーマンスの問題、主にデータストアのスケーラビリティが難問として立ちふさがってきます。
freeeでのDBのパフォーマンス限界に関する議論は非常に長く、危なくなりそうなタイミングで都度チューニングやスケールアップで対応を続けていました。これに対し、3年ほど前に、DBパフォーマンス改善の組織横断PJが発足し、freee会計のDBをRDSからAWS Auroraに移行しました。詳しくはこちらの記事を参照ください。
これがfreeeでのAuroraの初事例であり、以降新規プロダクトについては基本的にはAuroraが使われています。また、標準がAuroraに変わったというだけでなく、このプロジェクトを契機に、より長期的かつ継続的なDB性能・運用改善への投資が必要、という機運が社内に生まれました。
freee SREの現在
サービス・組織の増加、サービス規模の拡大、これらに伴う課題により効率的に対応していくため、SREの組織自体も変化してきました。
先に見たとおり、5年前に5人ほどだったメンバーが、今では20人を超える勢いです。この規模になると流石にチーム全体で同じミッションを持ち、同じ技術領域をカバーし、同じタスクを分担してやっていく、という状態を続けるには、認知負荷やオーナシップ、コンテキストスイッチの問題が顕著になりました。また、組織的な活動が取りづらく、OKR単位でチームは組んでいたものの、組織運営という観点での改善活動が取りづらくなっていました。
そこで、昨年頃から担当ドメインを元にMicroservice Infra、DBRE(DataBase Reliability Engineering)、DX(Developer eXperience)に分割、そこから少し間をあけて、Microservice InfraチームをPlatformとEnablingに分割して、今のチーム構成になっています。
DBRE
DBにまつわる課題のうち、特にパフォーマンスに関するものは、スケールアップによる対応であったり、一部の熟練エンジニアの腕力便りになっている部分が多く、組織としての技術の蓄積や、より抜本的な対応を検討するためのリソース確保、という点が問題となっていました。
DBREは、前述のfreee会計のDBのAurora化を目的としたJoint Projectが元となっています。現在も引き続き会計DBのスケーラビリティの課題に取り組みつつも、データストア系全般でのパフォーマンスの課題や運用改善を担うチームです。
今年の確定申告でDBに関連するアラートが激減していたのは、DBREにチームがオーナシップを取って改善を進めてくれた点が大きいですし、pt-oscの活用といったこれまでの運用前提を変えるような仕組みの検討など、先を見据えた施策を打てるようになったのは、DBREメンバの精力的活動によるところも大きいですが、かなりの進歩を感じます。
DX
安定性と生産性の両立は、SREとしてもフォーカスすべき大きなテーマです。一方で、目に見えている障害ポテンシャルへの備えや、レガシーシステムの改修など、喫緊で安定稼働に影響を及ぼしそうな案件に優先度を割きがちで、より開発者生産性に対してダイレクトに手をうつことはできていませんでした。
一方で、エンジニアの数も増加傾向、今後大きな問題となる前に、基盤側として明確にリソースを割いていくべく発足したのがDeveloper eXperienceチームです。元々はコンテナ向けのCI/CD基盤としてArgoCD導入やデプロイ全体の改善に取り組んでいたチームで、インフラ技術に加えてリリースリードタイムへの感度の高さを併せ持っています。
また、7月よりDXチームはサービス基盤チームという、より開発に近い部署にチームごと移ることになりました。組織横断の生産性改善活動委員会や開発チーム、QAチームと連携することで、開発環境や評価環境の刷新や開発支援の仕組みを作っていくと期待しています。
Platform/Enabling
Platform/Enabling teamのミッションはfreeeのSREのRebuildです。これまでの中央集権的なSREへの依存を脱して、プロダクトチーム主体で運用までを担うセルフサービスチーム化を目指す、という考え方が主軸となっています。
Platform teamが共通基盤としてプロダクト横断な仕組みを作り、開発チームはこのPlatformを使って開発・運用を行う。Enablingチームは開発チームのサポートをしつつ、開発チームでのSRE実現を担う、という役割分担です。
この流れは、インフラ担当をチームとして切り出したfreee SREの発足の経緯とは逆方向になりますが、本来、より早く、確実な価値提供の改善イテレーションを回すことができるのは、価値提供のライフサイクルを一つのチームで完結させるスタイルです。
一方でこの組織運営は、技術コントロールをしっかりやらないと、チームごとに独立した方法が育ってしまい、品質のばらつきや可搬性低下による低い生産性、同じ会社で開発しているのに技術的な分断が起きる、など色々問題が起きそうです。
今の仕組みが十分というわけでは有りませんが、コンテナ化やIaCによりインフラの標準化が進んできたという点、Devの運用への参加がある程度認知されてきた点、SREのメンバーが増えてきて余裕が出てきた点、など、ある程度条件が揃ってきたと感じています。
まとめと今後
改めて整理してみると、当時の議論がそのまま今も課題として残っていたり、思ったとおりに行っていないところも多々ありますが、少なくとも前に進んでいるなという感触は得られました。
来年のSREはどうなっているのか。ロードマップについては各チームで議論が進められており、後日何かしらの形でblog化できるかもしれませんが、色々意欲的なテーマを掲げています。
それらは、すぐにできるかもしれないし、ものによっては1年よりもっとかかると思われます。とりあえずは着実に前に進めていき、来年の振り返りでその足跡が確認できればと思います。そのためには、SREはまだメンバーが不足しており、引き続き積極的に募集しています。もし興味を持っていただけたら、まずはお気軽にカジュアル面談におこしください。詳細は採用ページをご確認下さい。
というところで本稿は以上です。
