Introduction to Alibaba's large-scale Flink cluster operation and maintenance system

1. 発展の歴史と運用保守の課題

Alibaba のリアルタイムコンピューティングは過去 10 年間で急速な発展を遂げ、大きく 3 つの時代に分けることができます。


1.0 時代：2013 年から 2017 年まで、3 つのリアルタイム計算エンジンが併存していました。
なじみ深い Jstorm と Blink は、当時はどちらもストリーミングコンピューティングと呼ばれていました。


2.0 時代：2017 年、グループは 3 つの主要なリアルタイム計算エンジンを統合し、Blink が卓越したパフォーマンスと効率的なスループットにより唯一のリアルタイム計算エンジンとなり、システムの統一を実現しました。
その後 4 年間で、グループのすべてのリアルタイムコンピューティングサービスが Blink に移行されました。
Alibaba のリアルタイムコンピューティングビジネスは最も急速な成長を遂げ、プラットフォームの規模も千から万へと拡大しました。
リアルタイムコンピューティングはすべて Blink の上に構築されています。


3.0 時代：2 年前にドイツで Flink の買収が行われ、Alibaba 中国チームとドイツチームが共同で、新しいクラウドネイティブ基盤の上に新しいオープンソースエンジン Flink を搭載した新 VVP プラットフォームを構築しました。
2021 年の独身の日に、新 VVP プラットフォームはパフォーマンスの大幅な向上を伴いながら安定して独身の日のトラフィックを支え、Alibaba のリアルタイムコンピューティングが新しい 3.0 時代に入ったことを宣言しました。


現在、Alibaba のリアルタイムコンピューティングは数百万規模のコンピューティング能力、数万台の物理マシン、数万件のジョブを有し、真に超大規模なリアルタイムコンピューティングプラットフォームを形成しています。
さらに、ビジネスの急速な発展に伴い、プラットフォームの全体アーキテクチャはクラウド下の Hadoop Flink からクラウドネイティブな K8s プラス Flink へと大規模な進化を遂げています。


このような巨大なリアルタイムコンピューティングを前に、運用保守も時代の変化に応じて異なる課題に直面しています。


第 1 段階はプラットフォームの運用保守です。
超大量規模のプラットフォーム運用保守を SRE が解決することを支援することが核心であり、Flink Cluster のクラスター運用保守の問題です。

第 2 段階はアプリケーションの運用保守です。
クラスター上の多数のリアルタイムコンピューティングユーザーのために、アプリケーション側での Flink ジョブ運用保守の複雑な問題を解決することが核心です。

第 3 段階は、3.0 時代の到来に伴い、クラスター基盤が完全にクラウドネイティブ化され、グローバルデータもクラウドネイティブに合わせて標準化されました。
運用保守の能力をクラウドネイティブかつインテリジェントに迅速に進化・向上させることが、新たな課題となっています。


2. クラスターの運用保守 Flink Cluster

一方では、非常に典型的なビジネスが Flink プラットフォーム上で稼働しています。
独身の日のプロモーションにおける GMV のメディア取引用ターナーであり、取引量を伝える有名な大画面でもあります。
このビジネスは安定性に対して非常に高い要求を持っています。
GMV の表示だけでなく、Flink は Alimama、広告の計量課金、検索レコメンデーション、機械学習プラットフォームなど、コア E コマースビジネスの重要なリアルタイムシナリオを含め、Alibaba 内のすべての重要なリアルタイムコンピューティングサービスをホストしています。
これらのリアルタイムシナリオは重要であると同時にリアルタイム性にも敏感であり、安定性が最優先の課題です。


他方では、プラットフォームの巨大な規模——数万台の専用マシン、複数リージョンへのデプロイ、プラットフォームの成長に伴うデプロイの複雑さの増大——により、局所的な異常が常态化し、安定性に対する 2 番目に大きな課題となっています。


重要かつ繊細なビジネス、大規模なプラットフォーム、複雑な構造という二重の課題に直面して、クラスターの安定性をどのように維持するかが大きな問題です。


当初、Flink Cluster は障害回数を用いて安定性を測定していましたが、実際には粒度が非常に粗いものでした。
障害持続時間の基準を満たさない多くの安定性異常があり、それらが最終的な障害回数に反映されず、安定性問題の盲点が生じていたからです。
その後、分単位の可用性に基づく複数の SLA 可用性を作成し、クラスター全体の安定性を測定しました。


SLI は SLA を算出するためのゴールデン指標であり、Flink Cluster の可用性を表します。
クラスターは仮想的な論理概念であるため、Flink ジョブの状態を定義して SLI としました。
Flink ジョブの状態自体は非常に複雑ですが、スケジューリング中、正常実行中、異常実行中の 3 つの状態に単純に抽象化できます。
各ジョブについてこれら 3 つの状態を計算し、クラスターレベルに集約してジョブの割合を算出します。
異常の割合が一定のしきい値を超えると、クラスターが利用不可と判断されます。
こうして SLI が測定され、年間を通じた利用不可時間が算出されます。


最終的な SLA 可用性の測定は、シンプルな数式で表すことができます。
SLA 可用性 = SLA 例外の数 × 各 SLA 例外の平均持続時間、となり、分単位の可用性でクラスターの安定性を精緻に測定できます。


精緻な定量化が可能になったことで、次は改善のパスです。
前述の式から 2 つの要素を最適化できます。
すなわち、SLA 例外の数を減らすための予防と、SLA 発生後の異常からの迅速な復旧による SLA 持続時間の短縮です。
これにより、全体の可用性が向上します。


まず SLA 例外の予防部分です。
重要な考え方は、クラスターの点検を徹底し、異常の隠れリスクを積極的に発見し、タイムリーに排除することで、SLA 異常の発生件数を減らすことです。


SLA 例外を引き起こす隠れリスクとは何でしょうか。
たとえば、多数の超大型ジョブが一度に起動し、クラスター内の数百台のマシンの負荷が高くなったりディスクが一杯になったりして、大量のジョブのハートビートタイムアウトが発生する場合があります。
また、ある Flink バージョンに重大な安定性问题或缺陥があり、オンラインの約千件のジョブに影響を与える場合もあります。
一見稀に見えるこれらの障害シナリオも、超巨大クラスターと多様なビジネスシナリオでは実際にはほぼ毎日発生しており、プラットフォームが一定の規模に発展した際の不可避な課題です。
さらに、クラスター規模が大きいほどバタフライ効果が起きやすく、影響範囲も大きくなりがちです。
加えて、各クラスター異常の特定には複雑さと時間がかかります。
これらの SLA 例外をどのように排除するのでしょうか。


私たちのアプローチは、Flink Cluster 例外自己修復サービスを構築することです。
オンライン運用の全量行動データ——ジョブの遅延、フェールオーバー、バックプレッシャーなど——を定期的にスキャンし、これらの大量データに対して異常分析と意思決定を行うことで、隠れリスクを発見します。
大別すると 2 種類の異常があります。


1 つはユーザー自身のジョブ行動に起因するもので、対応するジョブの変更をユーザーに通知します。
たとえば、リソース割り当ての不合理による OOM や、ジョブのバックプレッシャーによる遅延などです。

もう 1 つはプラットフォーム側の問題のあるバージョンに起因する異常で、プラットフォーム側が大規模な積極的なアップグレードを行い、問題のあるバージョンを排除します。

最終的に、プラットフォーム側とユーザー側の両方が SLA 例外自己修復のクローズドループを形成し、SLA 例外の発生件数を削減します。


異常自己修復サービスで最も複雑なのは、基盤ルールの識別と判断です。
長年の蓄積を経て、ビジネス側で最も頻度の高い数十の例外ルールと対策を蓄積し、完全に自動識別して以前は「見えなかった」隠れリスクを排除することで、真の安定性予防を実現しています。


SLA 例外の式に基づき、予防による SLA 件数の削減に加え、もう 1 つの手段は SLA 発生後の異常持続時間を短縮することです。


課題は、1 つのオンライクラスターには約 1 万件のジョブがあるにもかかわらず、クラスターレベルの障害はすべて特定が困難で復旧に時間がかかることです。
さらに、クラスター数が多く分布も広範囲なため、障害の確率も上昇します。
2 つが重なり合い、年間数件の障害がほぼ常态となっており、全体の安定性が非常に受け身な状態にあります。
受け身から積極的に転換する必要があります。
障害シナリオでトラフィックを迅速に切り替えてクラスターレベルのディザスタリカバリを実現できれば、SLA 異常復旧の短縮だけでなく、その確実性も高められます。


ディザスタリカバリシステムは主に 3 つの部分で構成されています。


1 つ目は切り替え先です。
リアルタイムコンピューティングではネットワークの遅延がミリ秒レベルである必要があり、都市間での数十ミリ秒の遅延はリアルタイム要件を満たせません。
そのため、プラットフォーム側のデプロイアーキテクチャでは、同一都市内 2 つのデータセンターにコンピューティングをデプロイし、2 対 2 のディザスタリカバリ、相互マスター・バックアップのフロー切り替えレイアウトを採用しています。
これにより、障害シナリオに対応し、切り替え先を確保します。


2 つ目はリソース容量の制約です。
これほど大規模なプラットフォーム向けにディザスタリカバリリソースを予算として用意することは不可能なため、トレードオフが必要です。
高優先度ビジネスと低優先度ビジネスの優先度をどのように区別するのでしょうか。
プラットフォームはビジネスシナリオに基づいた Flink ジョブの優先度基準を確立し、申請から対策、是正、ダウングレードまでの全流程を自動化した管理システムを備えています。
ビジネス側で細かく優先度を付け、真に高品質なビジネスにリソースを集中することで、限られたリソースの下で高品質ビジネスを重点的に維持します。


最後が最も複雑な、ジョブの透過的切り替えです。
核心はストレージを再利用し、コンピューティングの透過的切り替えを確保して、ビジネスへの無感覚を実現することです。


Flink ジョブはすべて長寿命で、ステートフルな中間計算結果を持ちます。
まず、クラスターデプロイアーキテクチャでは、コンピューティングとストレージクラスターを物理的に分離する必要があります。
コンピューティングクラスターにインフラ異常などの障害が発生した場合、フロー切り替えによりすべての Flink ジョブを別のディザスタリカバリクラスターに再配置できますが、ストレージは引き続き古いストレージクラスターを指したままとなり、元の状態ポイントから復元できます。
これにより真に透過的な移行を実現し、ユーザーに無感覚です。


日々の安定性に加え、独身の日は安定性の大規模なテストです。
独の日に向けた Flink の特別保護は、4 ブロック 8 文字に要約できます。
ストレステスト、スロットリング、ダウングレード、ホットスポットです。
各ブロックの背後に成熟した保証システムを構築しています。


1 つ目のブロックはストレステストです。
ストレステストプラットフォームは、まずユーザーにプロダクションをシャドウ操作にワンクリックでクローンする機能を提供し、次に大規模かつ正確な負荷生成・制御・安定化機能を提供し、ジョブの自動化パフォーマンスチューニングを行い、最終的にワンクリック起動の完全自動化ワンストップストレステストソリューションを提供します。

2 つ目のブロックはダウングレードです。
ダウングレードプラットフォームは、大プロモーションの 0 時ピーク時に低優先度ビジネスを迅速にダウングレードし、水位の合理的な制御を実現します。


3 つ目のブロックはスロットリングです。
大プロモーション時にダウングレードできないが短い遅延を受け入れられる中品質以上のビジネスもあります。
そのため、プラットフォームは Linux カーネルの Cgroup に基づいてジョブ Pod リソースの隔離と制限を実現し、ジョブ粒度の計算に対する正確なスロットリング効果を達成します。


4 つ目のブロックはホットスポットマシンで、大プロモーションの最も複雑なポイントでもあります。
クラスターの観点から見ると、クラスターが販売するリソースとユーザーが使用するリソースには差異があります。
たとえば、ある Flink ジョブが 10 CPU を申請しても実際に使用するのは 5 CPU であり、ピークとボトムによりクラスターレベルでの水位の不均一が生じます。


前述の 1 つ目の図は、クラスターレベルのスケジューリングにおける全マシンのリソースレベルが非常に均等で、CPU とメモリがほぼ同一線上にあることを示しています。
しかし、クラスター上で実際に稼働している全マシンの物理的水位は不均一です。
スケジューリングが物理的使用量を認識しないため、クラスターの水位が継続的に上昇するにつれ、たとえば大プロモーションの 0 時ピークの到来により、クラスター内のホットスポットマシンがさらに高くなります。
特定次元でのリソースがパフォーマンスボトルネックに達し、CPU 使用率が 95% 以上になるなどして、ホットスポットマシンが発生します。


分散システムでは、オンボードサービスのすべてがステートフルで関連性を持っています。
局所的なホットスポットマシンはクラスターの安定性に影響を与えるだけでなく、クラスターのパフォーマンス向上のボトルネックとなり、コストの無駄を引き起こします。
つまり、ホットスポットマシンはクラスターの安定性と水位向上のショートボードとなります。


ホットスポットマシンの解決は非常に困難な問題で、通常 4 つのプロセスを経る必要があります。


第 1 歩はホットスポットマシンの発見です。
CPU、メモリ、ネットワーク、ディスクのホットスポットマシンを特定します。
難しさは、ホットスポットマシンのしきい値が SRE の豊富なオンライン経験に由来することです。

第 2 歩は分析です。
ホットスポットプロセスを特定するための一連のマシン診断ツール——CPU のプロセス特定、IO のプロセス特定など——を開発しました。
難しさは、ユーザーが Linux システム全体の原理について深い理解と分析を持っている必要があることです。

第 3 歩はビジネスの意思決定と戦略です。
ホットスポットマシンプロセスの関連付けからビジネスデータを経て意思決定を行い、異なる優先度で異なる戦略を受け入れます。

最後のステップは実際にホットスポットマシンを解決することです。
低優先度はダウングレードまたはバランス化され、中・高優先度は流出によってホットスポットマシンを軽減します。


このプロセスの背後には、優先度、リソース、設定プロファイルなどのビジネス理解、リソース割り当て戦略やスケジューリング戦略などのスケジューリング原理の理解、システムカーネルの深い調査分析、そしてビジネス経験と戦略——制限するかダウングレードするか——が関与しています。
全リンクの定義と分析は非常に複雑な技術的問題です。


私たちが行っているのは、ホットスポットマシンに対する完全なソリューションを定着させ、K8s クラウドネイティブに基づいた Flink Cluster AutoPilot を構築し、ホットスポットマシンの完全自動自己修復を実現することです。


デプロイ形態の観点では、AutoPilot のサービスは K8s に基づいてフルマネージドされ、クラスター次元に応じて軽量デプロイが行われ、設定ファイルを通じて管理・運用保守が容易です。
実行フェーズでは、K8s を使用して最終状態と最終一貫性を保証します。
AutoPilot の技術能力の観点では、ホットスポットマシンの包括的分析プロセスを 6 つの段階に抽象化しています。
ホットスポットマシンの定義、認識、分析、意思決定、実行、可観測性の全プロセスを含み、ホットスポットマシンの完全自動自己修復と高い可観測性を実現し、クラスターの安定性向上とコスト削減に貢献します。


過去数年間、運用保守の安定性、コスト、効率性の 3 つの核心价值を中心に、SRE は Flink Cluster の超大規模クラスター運用保守において大量の運用保守能力と優れた運用保守プラットフォームを蓄積してきました。
しかし、クラウドネイティブ化の大きな波の到来に伴い、運用保守の能力をクラウドネイティブに基づいてより標準化し、運用保守プロセスのインタフェース、運用モード、実行モード、可観測性に対するより統一された標準を確立する方法が、今後の重要な发展方向となります。
Flink Cluster AutoPilot は、クラウドネイティブな新技術のキャリアとなり、運用保守システムの継続的な進化とアップグレードを担います。


3. アプリケーションの運用保守 Flink Job

リアルタイムコンピューティングの大きな潮流に伴い、Flink のユーザー数とジョブ数は急速な成長を遂げ、現在プラットフォーム上のジョブ数は数万件に達しています。
しかし周知の通り、Flink ジョブの運用保守は非常に複雑な問題です。
以下は、日々のユーザーから最も頻繁に寄せられる問い合わせの一部です。
ジョブの起動が遅い理由、フェールオーバーが発生する理由、バックプレッシャーが発生する理由、遅延する理由、リソース割り当てを調整してコストを削減する方法などです。
一見単純なこれらの質問も、実際には非常に複雑です。


Flink のジョブ運用保守の難しさには 2 つの側面があります。
一方では、分散システムにはフルリンクのコンポーネントが多く、依存関係が非常に複雑です。
他方では、Flink 自体、特にランタイムレベルでは非常に複雑な原理を持っています。
そこで、システムのフルリンクの呼び出しプロセス、各コンポーネントの動作原理の深い理解、日々の運用保守や独身の日プロモーションでの豊富なトラブルシューティング経験、優れたトラブルシューティングのアイデアを、データとルールのアルゴリズムに変換し、運用保守製品機能として定着させることを目指しています。


この製品には主に 2 つの機能があります。
1 つは Flink Job Adviser で、ジョブの異常を発見・診断します。もう 1 つは Flink Job Operator で、ジョブの異常を修復します。2 つが連携して Flink 運用保守の問題を解決します。

前述の図は Flink Job Adviser がユーザーに提示する最終的な効果です。ユーザーはジョブ名またはリンクを入力し、ロボットを @ するだけで Adviser サービスが呼び出されます。

たとえば Case1 では、リソース不足によりジョブが起動できません。Adviser は診断結果を提供します。特定ジョブのリソース不足が原因であり、改善提案を添えてコンソールで対応するリソース数を拡張するよう促します。

たとえば Case2 では、ユーザーの特定ジョブでフェールオーバーが発生し、その理由を知りたいとします。グローバルデータの関連付けを通じて、Adviser はプラットフォーム側のマシンオフラインまたはハードウェア障害の自己修復が原因と判断します。ユーザーは何も行う必要はなく、自動復旧を待つだけでよいと推奨します。

もう 1 つの例として Case 3 では、ユーザーのジョブのメモリ設定が不合理なため頻繁に OOM が発生しフェールオーバーを引き起こしています。Adviser は対応するコンピューティングノードのメモリ設定を調整し、新しいフェールオーバーを回避するようアドバイスします。

Flink Job Adviser の背後には、複雑なシナリオに対する数十の異常診断能力があり、巨大な経験デシジョンツリーを形成しています。発生中の異常を特定できるだけでなく、異常を予防する能力も持っています。主に 3 つの部分で構成されています。

事前の部分では、ジョブの運用指標とシステムのグローバルイベントに基づいて予測を行い、リスクを事前に発見して予防の効果を達成します。たとえば、ジョブでフェールオーバーやバージョン問題が発見された場合、これらの問題を事前に特定します。
事中の部分では、ジョブ実行の全ライフサイクルに対する診断を行います。起動停止の問題——起動エラー、起動遅延、停止エラーなど——や、実行時のパフォーマンス不足、遅延、実行中のエラー、データ整合性、精度の問題などを含みます。
事後の部分では、ユーザーが過去の操作の完全なバックトラッキングを行うことを支援します。たとえば、昨夜の深夜に発生したフェールオーバーの理由を確認したい場合などです。

デシジョンツリーの具体的な実装では、複雑さを持つ典型的なノードをいくつか選んで共有します。

1 つ目は、ジョブの全ライフサイクルの状態を確認することです。ジョブはコンソールからリソース割り当て、動作環境、依存関係のダウンロード、Top の作成、アップストリーム・ダウンストリームのロード、そしてデータ処理へと進みます。全リンクは非常に複雑なプロセスです。Adviser はキーノードの時間消費と全量イベントを統一的に収集・分析し、最終的にジョブのあらゆる状態の異常を診断・特定できます。
2 つ目は、ジョブの実行状態とパフォーマンスの問題です。主に各種リアルタイムモニタリング指標の異常を検出し、経験値としきい値の判断を通じて異常を発見・分析します。たとえばジョブに遅延がある場合、ノードを使用してバックプレッシャーが発生しているノードを特定し、TM が配置されているノードを特定し、マシンの異常を分析し、最終的に特定マシンの高負荷を発見します。このようにして全リンクのエビデンスチェーンの推論を形成し、関連するドリルダウン分析を行うことで真の根本原因を特定できます。
3 つ目は最も頻度の高い、ジョブ実行中のエラー報告の問題です。核心は、提出ログ、スケジューリングログ、フェールオーバーログ、JM や TM とのログなど各種コンポーネントのログを収集し、自然言語処理や実際の抽出を含むログクラスタリングアルゴリズムを通じてこれらの大量の例外ログを処理し、非構造化ログを構造化データに変換し、類似項目を圧縮統合し、最後に SRE と R&D が原因アノテーションと提案を行い、完全な専門家経験セットを形成することです。

デシジョンツリーの最初の実装は静的ルールでしたが、シナリオの複雑化、特にデータの爆発とパーソナライズされたシナリオの出現に伴い、静的ルールではニーズを満たせなくなりました。各ジョブの遅延の個別正規化やエラー報告は、正規表現マッチングでは維持できなくなっています。積極的に各種 AI を導入してこれらのパーソナライズされた問題の解決を試みています。

Flink Job Adviser で異常を特定した後、Flink Job Operator によって異常を修復し、クローズドループを形成します。

Operator の能力は主に 4 つの部分で構成されています。

1 つ目の能力はアップグレードです。ジョブの問題のあるバージョンを透過的にアップグレードし、設定をホットアップデートすることで、コードや設定などのジョブ安定性の隠れリスクと異常を解決します。
2 つ目の能力は最適化です。Alibaba 内部の Autopilot に基づいてジョブの設定とパフォーマンスの最適化を行い、ユーザーのパフォーマンスとコストの問題を解決します。
3 つ目の能力は移行です。ジョブをクラスター間で透過的に移行し、大規模ジョブシナリオでの効率的なジョブ管理をユーザーに提供します。
最後は自己修復です。Adviser が診断した様々なリスクとルールに基づき、ワンクリック修復の自己修復能力を備えています。

リアルタイムコンピューティングの発展に伴い、運用保守も人手からツールベース、プラットフォームベース、インテリジェント、クラウドネイティブへと進化・アップグレードを遂げてきました。超大規模リアルタイムコンピューティング運用保守の問題を解決するためのコンピューティング管理制御製品です。

システム全体では、中央にクラスターとアプリケーションの 2 つの運用保守対象があります。外周の運用保守の目標と価値は常に安定性、コスト、効率性の 3 つの目標を中心に据えています。運用保守システムのキャリアである技術と製品はリアルタイムコンピューティング管理制御であり、リアルタイムコンピューティング管理制御を通じて上位のリアルタイムコンピューティングユーザー、業界研究、SRE、そして私たち自身にサービスを提供します。同時に、運用保守管理制御の技術的核心は、インテリジェンスとクラウドネイティブ化に向けて全力で進化しています。

一言で要約すると、インテリジェンスとクラウドネイティブを技術的核心として、超大規模 Flink クラスターの運用保守とアプリケーション運用保守で遭遇する安定性、コスト、効率性の 3 大問題を解決するリアルタイムコンピューティング運用保守管理制御製品を構築します。