NetfixはJavaで出来ている ~2025年のNetflixのバックエンド事情~
情報源・引用元
この辺りになります
前提
NetflixはJavaで出来ている
GO、Pythonも使われているが一部でありJavaがあくまでメイン
大きく2つのシステムで構成される
Netflix Streaming
いわゆる私たち一般ユーザーが見るNetflixのことである
[特徴]
・高RPS（RequestPerSecond）
想像通りとは思うが、トラフィックは膨大であるとのこと
・マルチリージョン（4箇所）
全世界にユーザーが居るため、単一リージョンでは遅延が出る
ユーザー体験の低下に繋がるのでクリティカルである
・大規模なファンアウト（マイクロサービスへ）
・短めのタイムアウト（失敗を許容する）
例えばレコメンドの取得などが失敗しても、とりあえずユーザーは動画の一覧を閲覧しサービスを利用できる
などの性質があるため
・RDBMSは基本使わずNoSQL主体（マルチリージョン、データタイプとの相性）
「typically」といっているので、少しはRDBMSもあるのかもしれないがほぼNoSQLというニュアンス
Netflix Studio
（解像度の高い画像が見つからず..）
動画制作側の関係者が触るシステム
[特徴]
・低RPS（RequestPerSecond）
こちらは関係者が使うものなので、トラフィックはそこまで大きくない
・単一リージョンで十分
わずかな遅延が離脱に繋がるようなものではないため
・RDBMS主体
2024年初頭までJava8を使っていた（恥ずかしかった）
2024年の記事で今年初めまでJava8だったと語られている。
テック業界の最先端を行っているイメージからすると意外だった。
理由としてはフレームワークがSpringBootなどではなくGuiceをベースにした自家製のもので、
古いJava EE APIや、もうメンテナンスされていない古いライブラリに依存していた。
さらに8→11への移行インセンティブが少なかった。
Java17以上へ移行し、CPU使用率が20%程度改善した
現在は最低でも17以上になっている、そのタイミングで独自フレームワークからSpringBootになった
3000近いアプリケーションを自動化ツールを利用しつつ移行した。
この移行でGC時間が削減されCPU使用率が20%改善されたらしい。
重要サービスは20,21,23を使用している。
21移行で登場したVirtualThreadの活用している。
SpringBootの採用理由
歴史があり安定している
Springチームとの良好なパートナーシップ
SpringBootを扱える開発者が多い
通信方法について
フロント - バックエンド
GraphQLを使用
Netflixが開発したJavaでGraphQLを使用するためのDGSFramework(今はOSS)を使っている。
RESTと比較し
・スキーマがある
・余分なデータをフェッチしない
バックエンドサービス間
gRPC
RESTと比較し
・スキーマがある
・高速
ということでRESTは使っていないようだ。
REST IN PEACEというお墓の画像が出てきた。
その他
Kotlinの使用
使用率は低いようだ。
Kotlinは素晴らしい言語だが私達にとっての欠点は、開発者ツールへの投資が増えることです。IntelliJのプラグインや、Springのバージョンアップを支援するGradleベースの自動化ツールなどです。複数の言語を扱わなければならない場合、プラットフォーム・チームにとってこの話はかなり難しくなります。というのも、IntelliJのプラグインであっても、JetBrainsのプラグインであっても、JavaとKotlinの両方を使いたい場合は、IntelliJで2回インスペクションを書く必要があるからだ。手間が増えるだけだ。
と語っている。ただしDGSFrameworkそのものはKotlinで書かれている。（が、Java向けのツール）
最下部の「Participant6」のQ&A
その他出てきた技術スタック
・Kafka
・Spark
・CassandraDB
・Zuul
・EVCache
Discussion