Netflix、3万件以上のストリーミングジョブ向けにオープンソースのFlinkオートスケーラーの導入を推進

原文リンク(2026-09-07)

Netflixは、処理要件が異なるオペレーターを含む複雑なステートフルパイプラインに対し、従来のクラスターレベルのアプローチでは効果が不十分であるとの判断から、複数のAWSリージョンにまたがる3万件以上のストリーミングジョブ向けに、オープンソースのApache Flinkオートスケーラーの導入を進めている。 Netflixの報告によると、あるチームはFlink関連のコンピュート費用を年換算で58%削減し、年間約110万ドルの節約を実現した。

Netflixの2つのFlinkオートスケーラーの比較（出典：Netflixブログ記事）

Netflixは2017年からApache Flinkを運用しており、2019年頃に最初のオートスケーラーを構築した。 このシステムはMantis上で動作し、Atlasからのクラスターレベルのテレメトリ（CPU、ネットワーク使用率、Kafkaのラグ、入力レート、消費レートなど）を活用していた。これによりTaskManagerの総数を調整し、数千のパイプライン全体でリソース使用量を25％から45％削減した。

課題はスケーリング単位にあった。当初のオートスケーラーは個々のオペレーターではなくクラスター単位で判断をしていたため、ジョブ内のすべてのオペレーターが事実上、同じスケーリング決定を共有することになっていた。これは、分岐や結合、テラバイト規模の状態情報を含むステートフルなパイプラインには不向きであった。こうしたパイプラインでは、データフローの異なる部分ごとに異なる処理要件が生じ得るからだ。

これに対し、Apache Flinkオートスケーラーは、実行中のジョブから公開されるメトリクスを使用して、スループットとビジー時間から各オペレーターのTrue Processing Rate（実効処理レート）を推定する。その後、ジョブグラフを走査し、各頂点（vertex）に必要な並列度を計算する。 このアプローチはFLIP-271で説明されており、FLIP-271では、異種ストリーミングジョブのオートスケーリングと、ステートフルアプリケーションのリスケーリングコストへの対応について説明されている。

この技術は、DS2プロジェクトの研究成果も基盤としている。この研究に携わったシステム研究者のVasiliki Kalavri氏によると、プロジェクトでは当初、クリティカルパス解析を検討していたが、その後、よりシンプルな基本指標としてTrue Processing Rate（真の処理レート）を採用した。結果として、この極めて単純なアイデアが非常にうまく機能したことが判明した。このアプローチはその後、Flinkのオートスケーリング機能の一部となった。

Netflixは、Flink Kubernetes Operatorを通じて直接デプロイするのではなく、このオートスケーラーを自社の内部コントロールプレーンに統合した。Spring Bootサービスは、Temporalワークフローを使用して、個々のジョブに対するオートスケーリングの決定を分離している。 またNetflixは、最大3,000個のサブタスクを持つジョブに対応できるようJobManagerのメトリクス収集を修正し、サーバーサイドでのメトリクスフィルタリングを追加し、スケーリング中に前方接続されたサブグラフを維持し、シンクのバックプレッシャーへの対応を追加した。

Temporalワークフローを採用したOSSベースのFlinkオートスケーラーアーキテクチャ（出典：Netflixブログ記事）

フォワード接続に関する問題は、Apache Flinkの開発者間の議論でも取り上げられている。FORWARD接続を跨いで並列度を変更する場合、再分散が必要になることがあるが、Netflixの実装ではフォワード接続されたオペレーターをまとめて保持している。別のオープンイシューFLINK-38538では、負荷の高いオペレーターが出力比率に基づくスケーリング決定の影響を受ける可能性があるケースが指摘されている。

頂点ごとの現在および目標の並列度を示すFlinkジョブDAG。（出典：Netflixブログ記事）

外部のメトリクスやイベントに基づいてワークロードをスケーリングするKEDAのような汎用的なイベント駆動型オートスケーラーとは異なり、Flinkのオートスケーラーは内部のデータフローグラフとオペレーターのキャパシティに基づいて推論する。 Netflixは現在、大規模なステートフルジョブの過度なリスケーリングを抑えるため、Flinkのコミュニティデフォルトである0.7を下回る0.45の利用率目標を採用している。 同社は、残りの社内オートスケーリングのユースケースをオープンソースの実装へ移行する計画であると同時に、スケーリング時の状態復旧コストに対処するため、Flink 2のストレージ分離型ステートアーキテクチャについても調査を進めている。