Spotify、フリート管理でエンジニアの満足度と最新のコードを維持

※この投稿は米国時間 2023 年 10 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

2016 年以来、Spotify と Google Cloud は、Spotify の開発者、Google Cloud ユーザー、オープンソース コミュニティ向けのソリューションを共同で開発してきました。最も集中的かつ生産的なパートナーシップの一つは、Spotify の成長と拡大にも寄与するあり方で、Google Cloud テクノロジーを開発および最適化するための取り組みです。このパートナーシップの最近の例としては、自動化されたフリート管理ソリューションが挙げられます。このソリューションによって、Spotify の開発者は安全かつスケーラブルで管理しやすいアプリとサービスを、これまでよりも迅速に提供することができます。

フリート管理が必要とされた理由

Spotify は 3,000 名を超えるエンジニアを抱える定評のある大企業ですが、現在もスタートアップのマインドセットを持っています。500 を超える「スクワッド（分隊）」には具体的な目標があり、それを達成するための権限が与えられています。各スクワッドは自らの製品戦略と技術戦略を持ち、コンスタントにイテレーションを行っています。

課題は、Spotify のスクワッドが 1 万を超えるコンポーネントを共同で管理しており、これらすべてのバックエンド サービス、データ パイプライン、ウェブサイト、API、フロントエンド ライブラリが複雑な網の目のように接続され、相互依存関係にあることです。たとえば、プレイリストを管理するスクワッドは、Spotify の大部分のエンジニアが使用するフルスタックのコンポーネントを提供しています。そのため、プレイリスト スクワッドは、提供しているコンポーネントが 5 億 5 千万を超える世界中のユーザーのニーズを安定して満たすようにするだけでなく、定期的なソフトウェア アップデートを管理し新しいプレイリスト機能を開発するための時間も確保しなければなりません。

前例のない規模には新たなアプローチが必要

Spotify の複雑さは増すばかりです。Spotify のユーザー、コンテンツ、コンポーネントは指数関数的に増加しています。需要に応え、エンジニアにかかる負担を軽減するために、Spotify は数年前、自社プラットフォームを Google Cloud にリフト＆シフトし、可能な限り多くのインフラストラクチャを抽象化しました。マネージド サービスによって手動だった多くの調達タスクとプロビジョニング タスクが自動化されましたが、エンジニアは依然としてソフトウェアのメンテナンスに膨大な時間を費やしていました。リリース、ソフトウェア アップデート、セキュリティの新たな脅威に対応するために、スクワッドは退屈なタスクに取り組まざるをえませんでした。また、プラットフォームの移行には数百のチームの多大な労力が数か月にわたって求められ、新しい開発を行うこともできませんでした。

Spotify は進化する必要があると考えていました。さもなければ、十分なスピードで拡張や革新を行うことができなくなり、目標はおろか、要件を満たすこともできなくなります。同社は自動化の利用を増やし、フリート管理モデルを採用しました。Infrastructure as a Service の一歩先を行くフリート管理は、バックエンド サービス（ライブラリの更新、セキュリティ パッチ、さらにはソフトウェアのオブザーバビリティなど）をインフラストラクチャの一環として提供することで、開発者を多くの反復的なタスクから解放します。

VP 兼チーフ アーキテクトである Niklas Gustavsson 氏は、「開発者の作業が生産的で楽しいものになるように、私たちはより多くのレベルの技術スタックを抽象化し、当社プラットフォームのより多くのコモディティ要素を管理したいと考えています」と述べています。

フリート管理への移行

Spotify がフリート管理を導入するうえで最大の難関の一つが、開発者の信頼を獲得することでした。同社は、取り組みを一歩進めて人間の介入をなくし、自動化されたプロセスがコード変更をコンポーネントに push するようすを見ているだけで済むようにできることを彼らに示す必要がありました。自動化が機能することを、エンジニアに自分の目で確認してもらわなくてはなりませんでした。

現在は Cloud Native Computing Foundation オープンソース プロジェクトとなっている Spotify の Backstage ポータルは、ソフトウェア コンポーネントとクラウド リソースを一元的に管理できるものでしたが、それだけでは十分ではありませんでした。同社は、エンジニアがすべてのコンポーネントの変更とその影響を確認できるように、フリート全体のオブザーバビリティと制御を提供する必要がありました。Spotify は、BigQuery を使用してこれらの高度な分析機能を提供しました。

現在、開発者は Backstage を使用して、コンポーネントを管理運用するスクワッドから権限を奪うことなく、コンポーネントで使用されているコードを規模を問わず更新してフリート全体の変更を行うことが可能です。

後戻りはありえない

現在、Spotify の本番環境コンポーネントの 80% 以上がフリート管理されています。その結果、開発者の満足度が向上し、スクワッドが劇的に速くイテレーションを行って新機能をリリースできるようになり、セキュリティも向上しています。スクワッドが一貫性のないプロセスを使用してライブラリを更新するのに数週間、数か月を費やす代わりに、2,600 のコンポーネントをサポートする内部および外部のソフトウェア ライブラリが毎日自動的に更新されます。また、バックエンド サービスで使用される内部サービス フレームワークの更新には 1 週間もかかりません。以前は、これらのアップデートに数か月もかかっていました。

Spotify の開発者の 95% 以上が、フリート管理によりソフトウェアの品質が向上したと述べています。これは、更新の高速化によって、最新の内部および外部ライブラリ、フレームワーク、コード改善、バグ修正、セキュリティ パッチを備えた、より健全なコンポーネントが実現するためです。Log4j の脆弱性が出現したとき、開発者はわずか 9 時間でフリート管理のバックエンド サービスにセキュリティ修正をロールアウトしました。残りの 20% の非マネージド サービスに修正を手動でロールアウトするには 8 日かかりました。

既存プロダクトの新たな用途の発見

Spotify はフリート管理モデルの拡大を続けながら、トイルをさらに削減し Spotify やその他の組織における開発者のエクスペリエンスを向上させるための、より複雑な変更を検討しています。Gustavsson 氏は、「私たちは、これを部分的に外部化するかどうかを検討しているところです」と述べています。

Spotify は長年にわたって多くのツールを外部化してきましたが、Backstage は最も成功した例です。現在、2,200 を超える世界中の利用者が Backstage フレームワークから開発者ポータルを構築し、自社の開発者エクスペリエンスと生産性を向上させています。2022 年 12 月、Spotify はオープンソース Backstage を強化するため、利用者向けに商用プラグイン バンドル サブスクリプションもリリースしました。今後、さらに多くのプラグインをこのバンドル向けにリリースする予定です。

Gustavsson 氏は次のように語っています。「フリート管理用に構築したインフラストラクチャの一部は、もちろん Spotify だけにとどめておく必要はありません。そのため、どの部分をオープンソース化または商業化できる可能性があるかを見極めたいと考えています。各企業が独自にポータルを構築したりプラグインを作成したりする代わりに、それぞれの要件を目指すことができる 1 つの共有フレームワークを考案する方がよいと思いませんか。」

Spotify でのフリート管理について詳しくは、Spotify Engineering ブログをご覧ください。

• パート 1: Spotify によるフリート ファースト マインドセットへの移行
• パート 2: 宣言型インフラストラクチャまでの道のり
• パート 3: フリート全体のリファクタリング

Spotify R&D の公式テック ポッドキャストである NerdOut@Spotify を視聴することもできます。

• エピソード 12: フリート ファースト
• エピソード 22: 宣言型インフラとその先へ

-Google Cloud、プリンシパル アーキテクト Andreas Strid