【CNDW2024】PlayStation Networkの大規模Kubernetesマニフェスト管理の成功例

2024年3月時点で1億1800万人の月間アクティブユーザーを抱えるPlayStation Network。その運営の中核にあるKubernetesマニフェスト管理の仕組みについて、ソニー・インタラクティブエンタテインメントの太田氏がCloudNative Days Winter 2024で講演を行った。本レポートでは、セッションからPlayStation Networkが抱える課題とその解決策、さらに将来展望を詳しく解説する。

EnginEチームの役割と目標

冒頭で太田氏は、自己紹介を交えながらEngineering Enablement（通称、EnginE）チームの役割を説明した。このチームの目的は、PlayStation Networkの開発チーム向けに内部開発プラットフォーム（IDP）を提供することである。2021年から始まったプラットフォーム統一プロジェクトにより、異なる拠点が独自に開発していたプラットフォームを、一つのIDPに統合する取り組みが進んでいる。

セッションの主題は「多様なユースケースを持つ1000人の開発者にKubernetesマニフェストを提供する課題をどう解決したか」である。太田氏は次のように語った。「Kubernetesマニフェスト管理をどのように効率化し、開発者がアプリケーション開発に集中できる環境を提供するかについてお話しします」

またこのセッションではPlayStation Networkの規模感も紹介された。2024年3月時点で、1億1800万人以上の月間アクティブユーザー（MAU）を抱え、1秒間に270万リクエストを処理する大規模サービスを運営している現状が説明された。PlayStation Networkは単なるオンラインプラットフォームではなく、ゲームの購入やマルチプレイ、トロフィーシステムなどの多機能を提供する第3の収益柱として機能している。

複数環境による認知負荷

PlayStation Networkの運用において、開発チームが直面している課題は多岐にわたる。その中でもとくに重要な問題として、以下の3つが挙げられた。

• 認知負荷の高さ
• ガバナンス対応の負担
• サービス数の増加

開発チームが抱える問題

認知負荷の高さについては、複数の環境が存在することが主な原因だ。本番環境やステージング環境、開発環境に加え、QAチームやストア掲載用の環境など、さまざまな目的で構築された環境が複雑化を助長している。そのためどの環境がどの目的で使用されているのかを理解するだけでも時間がかかり、結果的に開発者の負担が増加していた。

次にガバナンス対応の負担だ。サービス情報やコストの可視化のためのタグ付け、またセキュリティ基準を満たすための設定作業に多大な時間を要している。例えば特定のKubernetesリソースにラベルやアノテーションを付与する作業や、リードオンリールートファイルシステムのセキュリティコンテキストを適用するなど、個別対応が求められるケースが頻発していた。

さらにサービス数の増加が開発チームに新たな課題をもたらしている。PlayStation 3や4向けの既存サービスを維持しつつ、PlayStation 5向けの新サービスを開発する必要があり、開発者が担当するサービス数が増加している状況が説明された。この結果、サービスごとに異なるマニフェストや設定ファイルの管理が求められ、チームは多くの時間を運用管理に費やさざるを得ない。

太田氏はこれらの問題について「開発者のリソースを最適化し、彼らがイノベーションに集中できる環境を作ることが急務です」と語った。

Engineering Enablementチームが提供する価値

EnginEチームが提供する価値は、開発チームの負担軽減と効率化にある。とくに認知負荷を軽減し、ガバナンス対応を自動化する仕組みを構築することで、開発者が本来の業務であるアプリケーション開発に専念できる環境を提供している。

Engineering Enablementチームが提供する価値

まず認知負荷の軽減について。開発者の約8割がアプリケーションコードのみを管理したいという前提に基づき、KubernetesマニフェストやDockerファイルなどの設定管理をプラットフォーム側で引き受けている。この取り組みにより開発者はアプリケーションコードに集中できるようになり、複雑な設定作業から解放される。

またガバナンス対応については、自動化による効率化を実現した。共通のラベルやセキュリティ設定は、ライブラリチャートに一元化されており、開発者が個別に対応する必要はない。この仕組みにより、セキュリティ基準を満たす設定が自動的に適用される。

さらにEnginEチームはHelmを活用して、柔軟なテンプレート設計を行っている。これにより開発チームは必要最低限の設定変更でマニフェストを利用できるようになり、運用効率が大幅に向上している。太田氏は、「標準化と柔軟性のバランスを取りつつ、チーム全体の生産性を向上させる仕組みを構築しました」と語る。

Kubernetesマニフェスト管理の仕組みと5つのチャレンジ

EnginEチームが採用したKubernetesマニフェスト管理の仕組みは、Helmを中心に構築されている。その中核となるのがsubchartとライブラリチャートである。

まずsubchartは各ワークロードに特化したテンプレートを提供する。WebAPIやバッチ処理など、用途に応じたテンプレートを用意し、開発者は必要なsubchartを選択するだけで基本的な設定が完了する仕組みだ。たとえば、WebAPI系のサービスであれば、外部トラフィックを受けるためのKubernetesサービスやIngressオブジェクトがテンプレートに含まれている。

一方ライブラリチャートは共通設定を一元管理しており、ガバナンス要求にも対応している。具体的には、特定のラベルやセキュリティ設定が自動的に適用されるよう設計されており、開発者が意識せずとも規定の要件を満たす設定が反映される仕組みとなっている。

Library chart

また多言語対応やクラスター固有の設定を柔軟に行えるテンプレートも提供されている。例えば、Java環境であれば専用の設定が適用されるようになっており、異なる言語や環境に対しても適切な設定を自動的に適用できる仕組みが整っている。

さらにこの仕組みの運用中には5つの主な課題が浮かび上がった。それぞれの課題とその解決アプローチは以下の通りだ。

チャレンジ1 valuesが増えすぎる問題

開発チームが管理するvaluesファイルの項目が増えすぎ、マニフェストの管理が煩雑化する問題。この課題に対して、エンジンチームは「Golden Path」を定義するアプローチを採用した。具体的には、秘匿情報の管理方法を統一し、AWS Secrets Managerを利用した情報取得方法を標準とすることでパターンを絞り込み、設定増加を抑制している。

チャレンジ2 subchartの構成が複雑

Helmのsubchartが複雑化し、レンダリング結果が予測しづらくなる問題。これに対しては、提供しているsubchartの構文チェックやユニットテスト、スナップショットテストを導入し、品質と可読性を向上させる取り組みを検討している。

チャレンジ3 subchartの更新が重い

subchartの更新時に、dependenciesのバージョン管理やレンダリング結果の確認が必要になることで、開発者の認知負荷が増加。これを解消するため、subchartの更新を検知して自動でPull Requestを生成する仕組みを導入し、更新作業を効率化している。

チャレンジ4 ConfigMapの.File.Get問題

subchartからa-service-chartのファイルを取得できない問題が発生。これに対して、a-service-chart側でConfigMapをレンダリングするテンプレートを設け、直接取得が可能となるよう対応した。

チャレンジ5 ConfigMapの後方互換性担保

ConfigMapの変更が既存のPodに影響を与える問題を防ぐため、ConfigMapの名前にデータフィールドのハッシュ値を追加し、後方互換性を確保するアプローチを採用した。

さらなる改善への取り組み

太田氏は「現在の仕組みをさらに改善し、開発チームの負担を減らすことが目標です。また新しいツールへの移行も視野に入れています」と、これまでの取り組みを総括した。

今後の課題としては、Helmの持つ限界への対応が挙げられた。とくにsubchartの構成が複雑であることや、ConfigMapの管理における課題が引き続き解決を必要としている。これらに対して、スナップショットテストやユニットテストの導入が検討されている。またkptやtimon、tankaなどの新しいツールの調査も進めており、将来的にはこれらへの移行も視野に入れている。

将来の展望

最後に太田氏は、「今後は継続的に課題を解決しつつ、将来のクリエーションにも備えていきます」と語り、セッションを締めくくった。