atama plusでSREチームのエンジニア兼プロダクトオーナーをしている塚本です。

前回はSREチームの紹介noteを書きました。たくさんの方にお読みいただきありがとうございました。

今回は、現在のSREチームがどのように作られたか、そしてどのように変化してきたかについて書いていこうと思います。

2019年2月〜 SREチームの前身となる「監視したい会」発足

atama plusの多くのチームではレトロスペクティブ（以下、レトロ）を毎週実施しています。ある時、プロダクトチームのレトロの中で監視が足りてないのではないかという話題が出ました。話し合った結果、興味のある人が集まり監視をどうしていくかを話し合う「監視したい会」が立ち上がりました。組織上の正式なチームではなく、有志が参加する集まりです。
最初は「監視入門」などを読み、監視をどうしていくかをみんなでアイデアを出し合って進めていきました。

2019年5月〜 SREチーム立ち上げ

この時期にatama＋として提供しているプロダクトの一部のバックエンドが高負荷となる問題、クラウドベンダー側でのインシデントなどに起因する問題が発生しました。これらが契機となり可用性やキャパシティなどのプロダクトの信頼性に関わる領域にフォーカスするチーム(現在のSREチームで、当時はインフラチームと呼んでいました)が立ち上がりました。

チームメンバー

専任メンバーは私1人で、もう1人(監視したい会に参加していたメンバーの一人)が兼務で入ってくれました。この時に私は痛風デビューしてしまいチームメンバー全員が痛風という平均尿酸値が高いチームが出来上がりました。

担当領域

当時のチームが担当していたのはatama＋という一つのサービスのみでした。一つのサービスと言ってもアプリケーションとしては複数のモバイルアプリケーション及びWebアプリケーションから構成され、バックエンドのインフラもAWSやHeroku、Firebaseなど複数のクラウドサービスから構成されていました。

取り組み

チームを発足した理由の一つに負荷問題があり、まずは現在利用しているクラウドサービスの使用状況や各種サービスの上限値、及びそれらの上限が手間をかけずに上げることができるのかを洗い出しました。集めた情報を元に利用量が増えていった時にどこがボトルネックになるか分析を行い、その情報に基づいて負荷対応のタスクの優先順位をつけて取り掛かりました。

また、チームが発足する原因となったRealtime Databaseの負荷問題の対応のため、シャーディング構成(https://firebase.google.com/docs/database/usage/sharding)に変更する対応をアプリチームの開発者と一緒に進めていました。

2019年8月〜 拡大に備える

ユーザー数とともにatama＋のアプリチームのメンバー、チーム数も増えはじめた時期です。今後の組織の大規模化、システムの複雑化に備えて様々な環境整備に着手し始めました。

チームメンバー

トッティーさんと業務委託社員を含めて3人の専任メンバーだけのチームになりました。

担当領域

引き続きatama＋のサービスの信頼性に関わる領域を担当していました。マイクロサービスのように動作するサブシステムが1つ増えましたが、構成に大きな変化はありませんでした。

取り組み

SSO化
今後開発者の数が増えていくことが予想されていたので、AWSや各種クラウドサービス上でユーザ管理がしやすいようにIdPからSSOできる環境を整えていきました。

IaC化の推進
チームメンバーも増えインフラの変更をする人が増えてきたことで、インフラの設定や構成の背景がわからなくなる問題が出てくるのではという懸念がありました。また設定変更のレビューのしやすさやatama plusでの開発環境のインフラの構成などの前提を踏まえて、このタイミングでインフラのコード化に取り組みをはじめました。

続・システム構成変更
ユーザー数の増加に対応するためのシステム変更は引き続き行っていました。具体的にはRDSからAuroraへ移行、Cloud Functionsのデプロイに時間がかかる問題の取り組み、DBを頻繁に更新するような処理を見つけ出しコードの最適化を行うなどボトルネックになる部分に手を入れるということを行っていました。

2020年4月〜 多様化

オンライン模試サービスの開発がはじまり、アプリチームもatama＋を開発するチームとオンライン模試を開発するチームにわかれた時期です。

開発期間が非常に短いこともあったため最初のリリースまではSREメンバー（私）がオンライン模試サービスの開発に加わりました。アプリチームのデイリーミーティングにも参加し作るものをリアルタイムに把握しながら、それに適したインフラ構成を考え、負荷問題が出そうな部分についてはその場でアプリチームと調整し初期段階から信頼性を作り込むことができました。

チームメンバー

あきちゃんときったんが参加し4人チームの体制になりました。

担当領域

オンライン模試及びデータ分析基盤の一部も取り扱うようになり、多様なプロダクトに関わるようになりました。

取り組み

オンライン模試のインフラの立ち上げやキャパシティプランニングなどに取り組みつつ、atama＋側で準備し始めていたTerraformの基盤を活用してインフラ構築を行いオンライン模試は最初からほぼ全てをTerraformで管理する形で立ち上げました。

データ分析をしているチームの基盤部分を一部SREチームで引き受け始め、データ転送構成の最適化などに取り組みました（引き続き取り組んでいます）。

一つのチームが複数のプロダクトのインフラを扱うことで、自然にプロダクト間の差異に注目するようになりました。扱っている技術に差異があることで、異なるプロダクトのタスクに取り組む際にコンテキストスイッチのコストが高くなるのを感じていました。

今後作り出されるプロダクトにおいて必要以上の多様化を防ぐため、そして新しいプロダクトのローンチを素早く効率的におこなえるようにしたいという考えからTerraformで書いたインフラ構築時のパターン集を作成しはじめました。パターン集は具体的にはリファレンス用のTerraformリポジトリを作成し、atama plusでよくある構成のサンプルを集約するというものです。新しいプロダクトを立ち上げる際はこのパターン集から必要なものを取り入れて作ることでプロダクトの立ち上げを素早くしつつ、SREチームとしても慣れた構成のインフラを立ち上げられる仕組みを作り上げました。

2022年2月〜 これからのSREチーム

SREチームがこれからどうなっていくのかは、まだ何も決まっていません。引き続きSREが一つのチームとして動いていくのか、それぞれのプロダクト、またはプロダクトの中で扱っているドメインで分割していくこともあるかもしれません。

チームトポロジーに書かれているような認知負荷を基準としてチーム構成を考えるという話は、次のチーム構成を考える上でも非常に参考になりそうだと思っています。チームの認知負荷を踏まえて、SREチームの新しい形をチームメンバーやチーム外のメンバーとともに探っていこうと思っています。

今atama plusではSREチームが、そしてSREエンジニアがプロダクトチームの中でどうあるべきなのかというところから考え、チームの設計に関われるよいタイミングだと思います。そんなテーマが気になる方はぜひatama plus SREに応募してみてください。We are hiring!

また、エンジニア向けのTwitterアカウントも始めましたので、よろしければフォローください。