SNCFが実現した、K8sの無駄削減と大規模環境での信頼性向上

SNCFはKubeConでPerfectScaleに出会い、本番環境レベルの最適化コントロールプレーンとして採用しました。決め手となったのは、稼働中の本番環境にも安全に適用できる、リスクを考慮したインプレースのライトサイジング推奨です。PerfectScaleはCustom ResourcesとArgoCDを介して統合され、Autopilotをフィーチャーフラグとしてnamespace単位で有効化できます。SNCFは標準のAutopilot設定を非本番環境全体に自動展開し、エッジケースにはきめ細かなオーバーライドで対応しました。本番環境では、クラウドネイティブスタック(Datadog、Kyverno、KEDA、AWS Load Balancer Controller、Karpenter)から段階的に自動化を導入し、その後アプリケーションのnamespaceへと拡大しました。最適化は一過性のプロジェクトではなく、継続的なガバナンスとなりました。

SNCFは欧州最大級の輸送グループであり、TGV、OUIGO、Eurostar、TER、Transilien、Keolisといったブランドを通じて、フランスの全国鉄道網とグローバルなモビリティサービスを運営しています。従業員数27万人超、年間売上高400億ユーロ超を誇るSNCFは、発券、時刻表、車内サービス、リアルタイムの運行ロジスティクスを支える高可用性のデジタルシステムに依存しています。これらのサービスの多くは、ミッションクリティカルな環境で稼働する数百のクラスタ上のKubernetesによって支えられています。全社的なデジタルモダナイゼーションと効率化の推進の一環として、SNCFはレジリエンスを犠牲にすることなく、これらのクラスタの運用コストの増大を抑える必要がありました。

プラットフォームチームは、KubernetesにおけるFinOpsの理想と、信頼性や稼働率に対する開発者のリスク許容度、そして経営層からの高まる財務的プレッシャーの板挟みになっていました。手動のライトサイジングには属人的な知識、長時間の会議、再起動が必要で、オーナーが変わったりエンジニアが異動したりするたびに、最適化の取り組みをやり直さなければなりませんでした。Datadogベースの分析は集計の影響で利用量を過大に見積もることが多く、推奨内容への不信を招いていました。作業は一貫性を欠き、時間がかかり、200超のプロジェクトと最大250のクラスタという全体をカバーすることは到底できませんでした。SNCFに必要だったのは、実際の挙動に基づく信頼できるライトサイジングの知見を提供し、本番環境で安全に機能し、信頼性を損なわずにコストを削減し、単発ではなく継続的に稼働し、クラスタやチームを横断して摩擦なくスケールするシステムでした。フランスで開催された2024年のラグビーワールドカップとオリンピックを経て、SNCFは鉄道プラットフォームのモダナイゼーションを減速させることなく、デジタルコスト効率への再注力を求められました。

SNCFがPerfectScale(現PerfectScale by DoiT)と出会ったのはKubeConでした。決め手は、単なるダッシュボードではなく、稼働中の本番環境に安全に適用できる、リスクを考慮したインプレースのライトサイジング推奨を生成できる点でした。SNCFのシニアスタッフエンジニアであるThomas Comtet氏は次のように語ります。「私たちを納得させたのは、PerfectScaleが理論を信じろと言わなかったことです。安定性を損なわずに何を変えられるのかを、正確に示してくれました」

PerfectScale by DoiTはCustom ResourcesとArgoCDを介して統合されるため、Autopilotをフィーチャーフラグとしてnamespace単位で有効化できます。SNCFは標準のAutopilot設定を策定して非本番環境全体に自動展開し、エッジケースにはきめ細かなオーバーライドで対応しました。本番環境では、クラウドネイティブスタック全体(Datadog、Kyverno、KEDA、AWS Load Balancer Controller、Karpenter)から段階的に自動化を導入し、信頼性を検証したうえでアプリケーションのnamespaceへと拡大しました。

SNCFはライトサイジングを一過性の取り組みとして進めるのではなく、PerfectScale by DoiTのガバナンスによって自動的に適用される、継続的な運用プラクティスへと変えました。推奨は観測されたワークロードの挙動に基づき、自動化によって適用されるため、もはや議論の対象ではなく、ポリシーとして実行されます。また、PerfectScaleチームは、インプレースのリサイズによって再起動を伴う最適化の隠れたコストが解消されることも見込んでいました。この機能がなければ、SNCFは同等の仕組みを独自開発するか、数十のチームに安全な適用方法をトレーニングする必要があったはずです。

導入以来、SNCFのKubernetes利用量はクラウドコストを増やすことなく約30%増加しました。利用量が増えたにもかかわらず、2025年9月の実際のクラウド請求額は2025年1月を下回りました。年間換算の削減額は約50万ユーロと推定され、その大半(約35万ユーロ)は非本番環境の自動化によるものです。現在SNCFは、非本番namespaceの45%、本番namespaceの1%、そして両環境のクラウドネイティブスタックの100%で自動化を有効化しています。つまり、クラスタを横断する最も重要な共有インフラが自動的にガバナンスされているのです。さらに、PerfectScaleが需要カーブと障害リスクに基づいてリソースを再配分したことで、過剰なキャパシティを排除しながらCPU枯渇の発生確率が下がり、クラスタの安定性も向上しました。

SNCFは今後、さらに多くの非本番namespaceへ自動化を拡大し、アーリーアダプター向けに一部の本番環境へも段階的に展開していく計画です。また、再起動による中断を最小限に抑え、ワークロードの安定性を高めるために、インプレースのPodライトサイジングも評価中です。自社の導入ロードマップにとどまらず、SNCFはPerfectScaleの製品進化にも積極的に貢献しています。JavaワークロードのサポートやインプレースのPodライトサイジングといった最近の機能強化は、SNCFのフィードバックが直接反映されたものです。「本番環境で実証できました」とThomas Comtet氏は語ります。「今は、うまくいく手法をスケールさせながら、製品をさらに良くする手伝いをしています」