バッカー氏によると、Netflixのシステムは用途によって求められる性質が大きく異なる。

　例えばストリーミングサービスでは、世界中から大量のリクエストを処理しなければならない。低遅延を実現するため、バックエンドのマイクロサービスを複数リージョンで稼働させ、障害時のフェイルオーバーも考慮している。一方、映画制作などを支える業務アプリケーションには、比較的ユーザー数が少なく、単一リージョンやリレーショナルデータベースで構成できるものもある。

　つまり、同じNetflixのシステムでも、求められる性能や可用性は一様ではない。では、こうした性質の異なるシステムを、それぞれ別々の技術基盤で構築しているのか。バッカー氏によると、そうではないという。用途ごとの違いはあるものの、バックエンドには共通するアーキテクチャや技術が使われている。

　その一例が、ユーザーがNetflixのアプリケーションでコンテンツを探す際の処理だ。リクエストはFederated GraphQL（複数のサブグラフを1つのスキーマに統合し、ゲートウェイが内容に応じて各サービスへ委譲する仕組み）のゲートウェイを経由し、クエリの内容に応じて複数のマイクロサービスへ分解される。こうしたGraphQLサービスや関連するバックエンドサービスは、JavaとSpring Boot（マイクロサービス構築用のフレームワーク）を中心に構築されている。

　Javaが使われているのは、コンテンツを探すためのバックエンドだけではない。ユーザーが動画を再生すると、処理はNetflix独自のコンテンツ配信基盤「Open Connect」へ移る。Open Connectは、ISP（インターネットサービスプロバイダー）のネットワーク内などに配置したハードウェアから、利用者に近い場所で映像データを配信する仕組みだ。この管理ソフトウェアにもJavaとSpring Bootを使っている。さらに、エンコード処理やストリーム処理、一部のデータストアなどでもJavaを利用しているという。

なぜJavaなのか

　Javaについてバッカー氏は、「実行性能、開発者の生産性、保守性のバランスがよい」と話す。Pythonは開発を始めやすい一方、大規模な処理では実行性能などに違いが出る。C、C++、Rustなどは高性能だが、Netflixでは開発生産性や保守性まで含めて考えると、Javaが適していると判断しているという。

　ただし、「Netflixの全てがJava」というわけではない。テレビ向けアプリケーションやスマートフォンのUIでは、それぞれのデバイスに適した言語を利用する。データサイエンスや機械学習ではPythonも使う。それでもバッカー氏によれば、バックエンドのマイクロサービスは基本的にJavaであり、一部ではJVM上で動くKotlinも使われている。

3000～4000のJavaアプリをどう管理する？

　Javaをバックエンドの共通基盤として幅広く利用するNetflixでは、別の課題も生じているという。管理しなければならないアプリケーションの数だ。バッカー氏によれば、Netflixには約3000～4000のJavaアプリケーションが存在する。これだけの数のアプリケーションについて、利用するツールやフレームワーク、Netflixの社内システムとの接続方法を各開発チームが個別に決めれば、開発や運用は複雑になりかねない。そこでNetflixは、Spring Bootを標準の開発プラットフォームとしている。

　ただし、単に「Spring Bootを使う」というルールを設けているわけではない。Netflixでは、開発者が標準的なツールやフレームワークを使いながら、必要な機能を容易に利用できる環境を「paved road」と呼んでいる。

　このpaved roadを実現するため、NetflixはSpring Bootに自社向けの機能を組み込んでいる。例えば、Netflix独自の認証・認可や動的設定、gRPC（高速にシステム間でデータをやりとりする通信方式）、HTTPクライアント、オブザーバビリティーなどと連携する仕組みだ。分散ログやトレーシング、メトリクスについてもNetflix独自のシステムと統合し、開発者が個別に設定しなくても利用できるようにしている。

　こうして開発基盤を共通化するメリットは、新しいアプリケーションを作りやすくすることだけではない。数千のサービスが同じ基盤に乗っていれば、ライブラリやフレームワークの更新など、共通して必要になる変更をプラットフォーム側から展開しやすくなる。Netflixが数千のJavaアプリケーションを維持する上で、標準化そのものが管理の仕組みになっている。

「古いSpring Bootでいい」と考えない理由

　数千のアプリケーションを抱えると、OSS（オープンソースソフトウェア）のバージョンアップも大仕事になる。

　例えばNetflixが「Spring Boot 2」から「Spring Boot 3」へ移行した際には、「javax」から「jakarta」へのパッケージ名変更が大きな問題になった。アプリケーションだけなら単純な置換で済む場合でも、依存ライブラリまで含めると、新旧のSpring Bootが混在する期間の互換性を確保しなければならない。

　そこでNetflixは、Spring Boot 2からSpring Boot 3への移行作業を、できるだけ自動化する方針を取った。「javax」から「jakarta」への変更には、「Gradle」（ビルド自動化ツール）を使って依存ライブラリのバイトコードを書き換える仕組みを用意した。ソースコードやビルド設定の変更には「OpenRewrite」（ソースコードの自動修正ツール）や「Gradle Lint」（Gradleで構築したプロジェクトの修正箇所検出ツール）なども組み合わせた。

　こうした仕組みによって移行作業の大部分を自動化できたという。しかし、全てを機械的に処理できたわけではない。自動化では対応できない一部の例外的なケースでは、人による確認や修正が必要だったとバッカー氏は語る。Netflixは約2年にわたってSpring Boot 3への移行を進めた。

　ただし、これでバージョンアップ対応が終わったわけではない。Spring Boot 3への移行を終えたNetflixは、既に次のSpring Boot 4への対応を進めている。

　なぜ、正常に動いているアプリケーションをあえて更新し続けるのか。バッカー氏は、Spring Bootを古いバージョンのまま使い続けると、周辺のライブラリやフレームワークだけが新しくなり、やがて互換性の問題が生じると説明する。使いたい新機能が登場しても、古いSpring Bootでは対応するライブラリを利用できない、といった状況になり得る。

　そのためNetflixは、大きな変更を何年分もため込むのではなく、重要なOSSの更新から大きく遅れないよう、継続的に新しいバージョンへ追従する方針を取る。Spring Boot 2から4、5へ一気に移行するよりも、一世代ずつ更新した方が、1回当たりの変更を小さくできるからだ。

　ただし、更新頻度を高めれば、そのたびに数千のアプリケーションを修正する必要が生じる。そこで重要になるのが、バージョンアップを各開発チームの仕事にしないことだ。Netflixでは、プラットフォーム側が移行作業をまとめて実行できる仕組みを整えている。

　Spring Boot 4への移行では、その自動化にAIエージェントを活用しようとしている。開発者一人一人にAIツールを使わせるのではなく、プラットフォーム側から多数のアプリケーションに対して一括で処理を実行する方式だ。移行作業を複数の小さな工程に分け、それぞれを別のプロンプトとサブエージェントに担当させる。全ての工程が正常に完了すれば、Spring Boot 4へ移行したアプリケーションが出来上がる仕組みだ。

　途中で移行に失敗した場合に備えた仕組みも設けた。ソースコードがどの状態まで変更されたかだけでなく、AIがどのような処理を実行したのかという履歴も残す。担当者はそれらを確認することで、自動化では処理できなかった例外的なケースの原因を調べられる。

Javaの性能改善は「コードを書き換えず」に取り込む

　Netflixは、JDK（Java開発キット）の新機能も積極的に取り込んでいる。

　Java 8からJava 17へ移行した際には、「G1 Garbage Collector」（G1 GC）の改善によってCPU使用効率が向上したという。現在は最低でもJava 17を利用し、多くのシステムではJava 21またはJava 25へ移行している。

　特にNetflixが効果を確認したのが「Generational ZGC」だ。従来使っていたG1 GCでは、大容量メモリを搭載したサーバでGCによる停止時間が1秒以上になることがあった。NetflixはRPCのタイムアウトを短く設定しているため、この停止によってリクエストが失敗し、再試行が発生する。

　Generational ZGCへ切り替えるとGCによる停止時間が大幅に減り、IPC（プロセス間通信）のエラーも減少したという。再試行が減ればクラスタへの余計な負荷が下がり、利用者に対する遅延も抑えられる。この結果、NetflixではGenerational ZGCを多くのサービスのデフォルトにした。

　ただし、全てのワークロードでZGCが最適とは限らない。バッチ処理などではGC停止時間よりCPU効率を優先する場合もあり、バッカー氏は実際のワークロードを計測して判断する必要があると説明した。

Netflixは生成AIをJavaサービスにどう組み込む？

　NetflixがJavaサービスへの組み込みで取り組んでいるのが、アプリケーション側で処理手順を制御し、その一部でLLM（大規模言語モデル）を使う取り組みだ。

　例えば、ユーザーから自然言語の入力を受け取り、大規模言語モデル（LLM）で質問の種類を判定して処理先を振り分ける。複数のLLMを順番に呼び出したり、並列実行したりすることもある。一方、ワークフローそのものはJavaアプリケーション側で制御する。

　Netflixではこうした仕組みの構築に「Spring AI」を利用している。LLMの呼び出しだけでなく、ツール呼び出しやMCP（Model Context Protocol）なども組み込めるため、既存のSpringベースのサービスに生成AI機能を追加しやすいという。

　一例が、Springアプリケーションの起動時間を分析する社内向けサービスだ。

　従来の仕組みでは、「どのSpring Beanの初期化に何秒かかっているか」といったプロファイリング結果を開発者に提示していた。しかし、問題を起こしているコードが外部ライブラリにある場合、開発者自身がソースコードを探して原因を分析しなければならなかった。

　そこでNetflixは生成AIを組み込み、プロファイリング結果とソースコードをLLMに分析させ、問題の場所と改善策を提示する仕組みにした。単にデータを見せるだけでなく、「次に何をすべきか」まで開発者に示すことが狙いだ。

　バッカー氏によれば、既存LLMを業務アプリケーションから利用する用途については、Javaのライブラリ環境もこの数年で充実した。「Spring AI」などが登場し、Pythonを選ばなければ生成AI機能を実装できない状況ではなくなったという。

本稿は、Javaが2026年4月12に公開したHow Netflix Uses Java-2026 Editionを基に作成しました。