Sportradarでプラットフォーム・エンジニアリングを導入した4つの方法

本記事は4 ways we implement platform engineering at Sportradarの抄訳記事です。

「Sportradar」（スイスに拠点を置くスポーツデータ配信の大手プロバイダ企業）では定期的に開発者体験を題材とするワークショップを実施しています。そこで社内のエンジニアリング関係者に自分達の経験や課題について共有する場を設けています。これは様々な面で役立つもので、常にそこから、開発者をさらにサポートする方法について多くのアイデアが生まれます。その一つとして行ったのは、プラットフォーム・エンジニアリングを一貫して導入し、開発者チームが自給自足かつ機能横断的に活動できるようにしたことです。

プラットフォーム・エンジニアリングの重要な要素は、顧客やコミュニティのニーズと要望に耳を傾け、それを実現することだと思います。プラットフォームおよびDevOpsのプラクティスを一元的に担当するチームにとっての顧客は、Sportradarの開発者です。 

Sportradarでは、以下の4つの方法でプラットフォーム・エンジニアリングを使用しています。

1. チームが自給自足できるよう再編成する 

Sportradarでは、Spotifyのモデルを導入しています。DevOpsを含む各チーム(スクワッド)が、エンドユーザから見た機能やアプリを構築するために必要な専門性を備えていることを前提とするものです。当社では2019年半ばから独自の「Sportify」型への組織再編を開始し、現在、完全に実現されています。多くの会社同様、Sportradarを成長させる一つの方法は買収によるものです。そのため、新しい会社を買収した際には、新しい社員が当社のモデルに合わせていくのを支援するための移行期間があります。当社の「Sportify」モデルでは、プラットフォームチームが中心機能を果たし、DevOpsのスペシャリストたちはスクワッドに組み込まれています。

このようなスクワッドが成功を収め、会社全体に利益をもたらしている一方で、いくつかの課題もあります。各チームには意思決定を行うための独自の目標や原則があるので、Kubernetesやオブザーバビリティツールなどの共通リソースを活用することが困難になる場合があります。 

この問題に取り組むため、新たにエンジニアリング・イネーブルメントのグループを組織し、各スクワッドにおけるベストプラクティスの活用をサポートしています。これは、DevOpsとプラットフォーム・エンジニア双方に対して共通の原則と目標に基づいて行動するよう促すと共に、一元化されたツールとアプローチを啓蒙するものです。この新しく組成されたチームでは、エンジニアリングに関する大きな課題に目を向け、その課題に対処するためのフレームワークとツールを開発しています。さらに、スクワッド内のDevOpsと、コアプラットフォームチームの間で、完全なる連携がとれるよう尽力しています。

2. すでに整備された方法で開発者の共通タスクを解決する

エンジニアリング・イネーブルメント・グループは、新規プロジェクトのスピードを速め、開発者間の軋轢を低減するために、すでに整備された方法を採用します。これは、他の会社では黄金律またはゴールデンパスと呼ばれることがあります。名称は何であろうと、それは、エンジニアたちが通常よりはるかに迅速に結果を出すことを意味します。 

開発者はアプリケーションを構築する際、そのアプリが高性能で、顧客を喜ばせ、収益を増進させることを願います。整備された方法から外れても結果を出すことはできるかもしれませんが、少し多くの時間がかかることになります。整備された方法に従えば、多くの複雑性を回避できます。そのために、エンジニアリング・イネブルメント、コアプラットフォーム、DevOpsの各チームが連携するのです。これらのチームが中心となって、開発者が整備された方法を活用できるために必要なマネージドサービスを定義し、オブザーバビリティ、ソフトウェア開発ライフサイクルにおける意思決定、CI/CDパイプラインなどを実現する共通スタックやその他のフレームワークやソリューションを共有しています。

3. コアとなる一連の共通メトリクスを設定する

整備された方法に従うと、New Relicのオブザーバビリティ機能がより利用しやすくなると共に、会社全体で標準化されます。すべてのスクアッドは、可用性、信頼性、パフォーマンスという、コアとなる3つのメトリクスを測定しています。新規プロジェクトを始める際、開発者はコアとなるこれらのメトリクスを計測するために、New Relicおよび目的に合わせて構築されたNew Relicのアプリを含む、すでに整備された方法を使います。それにより、開発者はアプリのプラットフォームを構築し管理することから解放され、アプリのためのコードを書くことに専念できます。

最終的に、New Relicは複雑性を除去します。New Relicはマネージドサービスなので、開発者はサーバーを管理する必要がありません。開発者がアプリにエージェントを入れるだけで、自動的に計装がされるため、複雑性が低減します。さらに、整備された方法に含まれている、非本番環境でのアプリケーションの合成テストを実施することもできます。整備された方法に含まれる共通メトリクスは、これらの情報をすべてを集約するうえで役立ち、市場導入までの時間が大幅に短縮されます。

4. マネージドサービスのカタログを公開する

社内向けの開発者ポータルには、会社のすべてのアプリケーションとサービスを対象とするスコアカードがあります。サービスカタログは、プロジェクトを自動で立ち上げるためと、開発者用ポータルにサービスを追加するための両方の目的で使われます。スクアッドの開発者が必要なものを選択すると、カタログは、開発したいアプリまたはサービスに必要なすべてのコンポーネントを含む、独自のスタックを提供します。これにより、開発者は素晴らしいアプリケーションを開発するという、最も重要なことにフォーカスできるようになります。プラットフォームチームは、マネージド・ホスティング・ソリューションとコアサービス、名前解決、ネットワーキング、その他必要なものすべてを提供します。DevOpsに特化したチームは、自動化されたパイプラインとオブザーバビリティ機能を提供します。整備された方法のテンプレートは自動実行されるので、開発者はアプリケーションそのものの複雑性にのみフォーカスでき、その周囲のエコシステムについては気に掛ける必要がなくなります。

さらに、エンジニアリング・イネーブルメント・グループ内にはプロダクトオーナーも存在しており、すべてのプラットフォームとDevOps の機能をチェックし、提供しているプロダクトが合理的であること、および、これらの整備された方法が首尾一貫した形で導入され、開発者のニーズに効果的に役立っていることを確認しています。