Future Tech Blog
フューチャー技術ブログ
Infrastructureカテゴリ

SREの探究 - Spotifyの事例：Ops-in-Squads

はじめに

こんにちは、TIG 岸下です。
秋のブログ週間の5本目になります。

最近、Netflixで配信中のSpotify創業ドキュメンタリー：The Playlistを見ました。創業ドキュメンタリーは鳥肌モノが多く、なんだかパワー貰える感じがして自分も頑張ろうと思わせてくれるので非常にオススメです1。

そんなわけでSpotify熱が高まっていたこと、自分がプロジェクトの方でSRE活動に関わっていることもあり、SREの探究：7章「SREのいないSRE：Spotifyのケーススタディ」を読んでみました。

そもそもSREって？

恥ずかしながら、自分も現在のプロジェクトに配属されるまでSREの存在を知りませんでした。

SREはSite Reliability Engineeringの略で、サービスの信頼性をソフトウェアエンジニアリングの力で高めていこうぜ！ というGoogle発祥の試みになります。

もはや、試みという枠組みからは抜け出していて一種の文化です。

詳しく知りたい人はオライリーのSRE本が有名どころです。
が、かなり分厚くて読むのが辛い人もいると思うのでTopotal社がやっているPodcast：もう一度読むSREをオススメします。

SRE活動の例として、

  • 標準化
    • 開発に使うツールやクラウドサービスの設定標準を決めておく
  • エラーバジェット
    • あるサービスの許容できるエラーの量を数値で決めてしまって、機能開発のリリース可否を定性的に判断しよう
  • 自動化
    • 人間が手作業でデプロイするといつか事故るから、できるだけ自動化しよう
  • アラートの改善
    • 多すぎるアラートはノイズにしかならないから、利用ユーザーの機会損失となるようなバグだけアラートを飛ばそう

などの活動になります。
SREは文化なので、SRE活動はSREの伝道師となってエンジニアリングチームに対して、恒常的にサービスの信頼性を維持・向上させる文化を醸成していきます。
以下の記事も参考にしてみてください。

SpotifyのSRE：Ops-in-Squads

この章のタイトルでは「SREのいないSRE」と書いていますが、SpotifyにSREが居ないわけではありません。
Spotifyではプロダクトリリース前から運用に重きを置いた開発を行っており、例えば

  • プロダクトリリース前の段階で開発メンバーの中に運用エンジニアを組み込む
    • 開発に関する議論の中で運用の健全性を対等なテーマとして扱う社風の醸成
  • ベータ版時点で、運用をソリューションのライフサイクルに組み込む
    • スケーラビリティ、信頼性、保守性など運用上の品質を早い段階で議論
  • 運用の責任をそのノウハウのあるところ、開発者の近くに移す
    • 自分で構築したものは自分で実行・運用

などの試みによって文化を根付かせていたそうです。

また、Spotifyのバックエンドは創業当初から多くの小さなサービスで構成、現代で言えばマイクロサービスパターンを採用することを構想しており、これらを組み合わせることでSpotifyのクライアントにコンテンツを提供しています。

これら2つの文化・構想が現在のOps-in-Squadsという運用体型を生み出しました。
直訳すればOpsはOperations（運用）、Squadsは分隊で、運用を細かく分けられた分隊が行う形態となります。
つまり、Ops-in-Squadsは各サービスの開発チーム側でデプロイから運用までの世話を見る、つまり開発チーム側でサービスの信頼性の担保に責任を持とうぜという文化になります。

Ops-in-Squads確立までの道のり

では、どのような経緯でOps-in-Squadsが確立されていったのでしょうか？
ざっくりではありますが、その経緯を要約します。

ベータ版リリースとユーザー数の急激な増加（2007年～2010年）

場所はスウェーデン、時はインターネットが民主化し皆がエンタメコンテンツを渇望するような時代で、一世を風靡していたファイル共有サイト：パイレートベイ（Wiki）が問題視され、遂に閉鎖されたという背景があります。
そんな中、音楽コンテンツ配信の新生児Spotifyがベータ版リリースということでスウェーデン中の元パイレートベイユーザーがSpotifyへどっと流れ込みました。
詳しくはThe Playlistのエピソード1～2を御覧ください。

ユーザーの急激な増加はプロダクトに深刻な問題を発生させます。稀にしか起こらない、ほとんど理論上の問題点が大規模に顕在化したわけです。
具体的には

  • ピーク時間帯にバックエンドサービスでサービス障害
  • 使用率の高い状況で重要なデータを扱っているサーバーが反応しなくなる
  • サーバーのラックへの格納と積み重ねの日々

などが本書で挙げられています。

利用ユーザーの多いサービスに関わったことのない自分としてはどれぐらいのつらみだったのか想像し難いのですが、
「プロダクトの成功とは、負荷との格闘で今にも落ちそうになるシステムを手作業で何とか動かし続けるために、ノートPCを前にして過ごす数え切れないほどの夜という犠牲の上に成り立つのだ」 という名言から、想像を絶する感があります😇

これに対して、

  • スケーラビリティと信頼性を全面に打ち出す
    • 運用を重視する文化から、運用チームだけでなく開発チームも率先して運用の問題解決に協力
  • スプリント期間中に開発チームのメンバーに「システム所有者デー」を設ける
    • この日は主に各自のサービスのメンテナンス、アップグレード、一般的な改善強化に専念する時間が与えられる
  • コアサービスの定式化
    • （当時は）様々なバックエンドサービスが依存しあっており、あるサービスが別のサービスを救うための犠牲になることがあった
    • これによって、（睡眠不足の）運用エンジニアの意思決定に常に迷いを生じさせてしまっていた
    • そこで、コアサービスをユーザーに音楽コンテンツを届けるプロセスと定義し、他のサービスから依存関係を分離した
  • ゴールキーパーの導入
    • 曜日毎などで、運用に関する問い合わせの一次受付の人間を決めておき、コンテキストスイッチが起こる人間の数を最小限に留めておく

などによって、この苦難を乗り越えていきました。

私が所属するプロジェクトでも曜日毎でゴールキーパー役が決まっており、その曜日以外は問い合わせを気にしなくて済むのでタスクに集中できる環境を作り出し、非常に良い試みだと思います。

手作業の行き詰まり（2012年）

今日では、CI/CDなど自動化の取り組みが一般化しつつありますが、2012年後半に100万ユーザーを突破したSpotifyは未だ手作業でのデプロイを行っていました。
デプロイ方法はというと、社内チャットで 「～～ DEPLOY!」と叫ぶことで他のユーザーが別のデプロイ作業を行わないように排他制御を確保 してから、手作業でスクリプトを実行するやり方を取っていたそうです。
まさに人間的排他制御…！ 2012年時点で100万ユーザーを抱えていたサービスがこのデプロイ方法を取っていたのは驚きです😮

手作業によるデプロイに加え、新規サーバーの購買と設置、インフラの変更に対するレビューとマージ、アラートの設定など運用チームの負担がどんどん増え、新しい機能や改良した機能をデリバリする能力はどんどん低下していきました。

バックエンドのアーキテクチャは初期の段階からスケールできるような設計が議論されておりスケールアップに対応済みでしたが、それに合わせた運用業務のスケールアップは集中型の運用SREチームでは対応できないことに気づかされ、Ops-in-Squads（分隊型運用）を確立させる動きが始まるのでした。

分隊型運用の導入（2013～2015年）

まずは運用チームの負担を減らすための大きな変革として、

  • Jiraチケットで起票することで、新規サーバーのプロビジョニング自動化
  • サーバー用のDNSレコードの追加・デプロイを自動化
  • 内製ツールを用いたDNS SRVレコードに関するテストとデプロイの自動化2
  • デプロイ権限を運用チームから開発チームへ移譲
    • 他の誰かからApproveを貰えた場合はセルフマージ可

などの自動化が導入されました。
ただ、これらの導入によって一時的に解決の兆しが見えたと思いきや、新たな問題が生まれます。
これまでは運用チームが行っていた「サニティーチェック」が取り除かれたことによって、バックエンドのカオス化を生み出してしまいました。
また、オンコール担当の運用エンジニアも「プロダクションで何が実行されているか」という対処に必要な理解を欠いていたりする事例が目立つようにもなりました。
運用チームの作業負担を減らすための自動化によって、今度は運用チームが全てを把握できなくなってしまい、全ての運用の面倒を見ることができなくなってしまったわけです。

そんなこんなでOps-in-Squads、つまりサービスに対するオンコールと運用の責任を開発チームが負うスタイルを形成する運びとなりました。
ただ、いきなり「運用チームはもう面倒見きれないから、サービスの面倒は自分たちで見てね」と言われても反発は必至です。
そこで、運用チームから運用エンジニアを開発チームに派遣することで 「運用の地ならし」 を行い、徐々にオンコールと運用の責任を開発チームへ移譲していくことでOps-in-Squadsを確立させていったようです。

この活動は当にEnabling SREで、中央のSREチームのメンバーが伝道師となり、他の開発チームでSREができる（Enabling）ように文化を根付かせていったわけですね🧐
Enabling SREに関しては以下の記事が参考になります。
参考：Money Forwad社：組織にSREの文化を作り上げていくEnabling SRE

おわりに

今回、本書を読みながら感想記事を執筆したことでエンジニアリング（主に運用）の側面で見たSpotifyの成長とその運用形態であるOps-in-Squadsの成り立ちを学ぶことができました。組織に文化を根付かせる＝組織の人の意識を変えさせることになるので、本当に労力と根気のいる作業だと改めて思いました。

昨今ではマイクロサービスパターンが流行っていることもあり、規模の大きいサービスではOps-in-Squadsも1つの選択肢としてポジションを確立させていくのかなと思いました。
各サービス・機能の運用は各分隊に任せて、中央のSREチームは各分隊が運用コストを下げられるためのツール開発や新しい技術の標準化を進めていくスタイルとなりそうです。

また、本書では泥臭ストーリーが包み隠さず書かれており、更に事前にThe Playlistを見ていたこともあって、脳内に情景を浮かぶような解像度で読むことができました。
詳細なストーリーを読みたい方、他の事例を読みたい方は是非本書を手に取ってみてください。
自分もこの話を励みに、プロジェクトでの活動を邁進していきたいと思います。

アイキャッチはRosy - The world is worth thousands of picturesによるPixabayからの画像を利用させていただきました。

  1. 1.スペースXドキュメンタリー：Return to spaceはイーロン・マスクの気迫に鳥肌が立ちました。 ↩
  2. 2.https://github.com/spotify/rspec-dns ↩