アソビューでVPoTをしているdisc99🐼です！

今回は、弊社のSRE(Site Reliability Engineering)と、その役割を果たすSREs(Site Reliability Engineers)について紹介させて頂きます！

アソビューのSREsが向き合う課題

弊社は現在、複数のサービスを提供しており、これらのサービスは規模としても大きく成長しています。

これらの状況の中で向き合う課題も複雑化してきており、代表的なものを上げると以下のようなものがあります。

多数のサービスと複数チームの意思決定を支えるSLO、SLI構築のリード
一秒間に数千リクエストを処理するためのスケーラビリティの向上
年々成長し続けるサービス、増え続ける会員/施設、拡張していくシステムの可用性の強化
人気商品発売やセールなど偏るトラフィックに対するノイジーネイバー問題への対応
数十あるシステムを扱うマルチテナントKubernetesクラスター、2,000を超えるテーブルを扱う複数DBのワークロードの最適化
1,000万会員、1万施設に安心して利用してもらえるサービス提供のためのセキュリティ強化
マイクロサービス、ハイブリットクラウド化しているシステムのオブザーバビリティの向上
モノレポ×マイクロサービス+モジュラモノリス構成におけるCI/CD、リリースエンジニアリングの最適化
100人規模の開発組織、大規模サービスにおける開発生産性や信頼性を高めるためのプラットフォームの構築
システムと開発者、運用課題を深く理解し、最適なDevOps文化浸透及びイネーブリングの推進
これまでの12年で拡張されてきたシステムの統廃合と、次の12年を見据えたアーキテクチャの最適化
成長するサービス、多様化する技術要素への適応とコストの最適化

2024年1月から、これらの課題に取り組むため、Service SRE、Platform SRE、Embedded SREの3つの役割体制へと移行しています。

アソビューの3つのSRE

SREは、GoogleやNetflixなどの大手企業を先駆けとして、現在日本を含む世界中の多くの企業で採用されています。
しかし、企業によってSREsが担う役割は様々で、その背後にはSREがカバーする広範な領域が関係していると思います。

弊社でもSREsは、教科書通りの役割をただ担ってきたわけではありません。サービスを運用していく中で起こった課題を元に、最適な形を求めて改善を続け、現在の体制に辿り着いています。

弊社ではサービスを開始して暫くは、開発者自身がSREの役割も担っていましたが、サービスが成長し信頼性の重要度が高まってきた約6年前から、独立した専門のSREチームを設立しました。

チームで施策を推進していく中でSREsという役割は組織内に定着しましたが、独立したチームであるため開発者の課題を深く理解して最適解を見つけることが難しいとか、逆に開発チームから見るとインフラやCI/CDがブラックボックスになりやすい傾向がありました。

これらに対し開発チームから有志を募り、そのメンバーの業務の10%程度の時間を使って開発チームとSREチームの橋渡しを行ってもらうSREチーム＋Embedded SRE体制に移行しました。
この取り組みにより、開発チームとSREチームの課題の共有や個別最適化されやすかったシステムの全体最適などの促進も図れるようになりました。

一方組織やサービス、システム成長によって、より可用性やセキュリティといった信頼性の側面と、高まる運用コストに対する開発生産性やアーキテクチャの最適化のような側面を一手に開発組織横断チームであるSREチームが抱えるようになってきました。
SREチームで引き続きこの課題を推進し続けることもできましたが、このタイミングで開発生産性やより長期の課題を解決することをミッションとしたプラットフォームチームとしてSREチームと分離したのがPlatform SREチームです。
また従来の信頼性を高めることにフォーカスしたチームをService SREという形で形成するようにしました。