This documentation is for an unreleased version of Apache Flink. We recommend you use the latest stable version.

Flink の構造 #

Flink は分散システムであり、ストリーミングアプリケーションを実行するために計算リソースの効果的な割り当てと管理を必要とします。Flink は、Hadoop YARN や Kubernetes のような全ての一般的なクラスタリソースマネージャーと一体化されますが、スタンドアローンクラスタやライブラリとしても使えます。

このセクションでは、Flink のアーキテクチャの概要と、Flink の主要コンポーネントがどのようにアプリケーションと相互作用して障害から回復するかについて説明します。

Flink クラスタの内部構造 #

Flink ランタイムは、1つの JobManager と、1つ以上の TaskManagers という2種類のプロセスで構成されます。

The processes involved in executing a Flink dataflow

クライアント はランタイムおよびプログラムの実行の一部ではありませんが、データフローを準備しジョブマネージャーに送信します。そのあとで、クライアントは切断(detached mode)、あるいは接続を維持して進捗レポートを受信できます(attached mode)。クライアントは、実行をトリガーする Java/Scala プログラムの一部として、あるいはコマンドラインプロセス ./bin/flink ...の中で実行されます。

ジョブマネージャーとタスクマネージャーは様々な方法で開始できます: スタンドアローンクラスタとしてマシン上で直接。コンテナ内。YARN のようなリソースフレームワークによって管理。タスクマネージャーはジョブマネージャーに接続し、自身が利用可能であることを通知し、作業が割り当てられます。

ジョブマネージャー #

_ジョブマネージャー_には、Flinkアプリケーションの分散実行の調整に関する多くの責任があります: 次のタスク(あるいは一連のタスク)をいつスケジュールするかを決定し、完了したタスクあるいは実行の失敗に対して反応し、チェックポイントを調整し、障害時に他のマネージャー間でリカバリを調整します。このプロセスは次の3つの異なるコンポーネントで構成されます:

ResourceManager

ResourceManager は、Flink クラスタでのリソースの割り当て/解除と、プロビジョニングを担当します。Flink クラスタでのリソーススケジューリングの単位である、タスクスロットを管理します(TaskManagers を参照してください)。 Flink は様々な環境と、YARN、Kubernetes、スタンドアローン配備のようなリソースプロバイダに複数の ResourceManagers を実装します。スタンドアローンセットアップでは、ResourceManager は使用可能なタスクマネージャーのスロットを配布するだけで、新しい TaskManagers を独自に開始することはできません。
Dispatcher

Dispatcher は、実行のために Flink アプリケーションを送信するための REST インタフェースを提供し、送信されたジョブ事に新しい JobMaster を開始します。また、Flink WebUI を実行して、ジョブの実行に関する情報を提供します。
JobMaster

JobMaster は、単一の JobGraph の実行を管理する責任があります。 Flink クラスタ内では複数のジョブを同時に実行でき、それぞれに独自の JobMaster があります。

常に少なくとも1つの JobManager が存在します。高可用性セットアップには複数の JobManagers が存在する場合があり、そのうちの1つは常に leader であり、その他は standby です(High Availability (HA)を参照してください)。

TaskManagers #

TaskManagers (workers とも呼ばれます)はデータフローのタスクを実行し、データストリームをバッファして交換します。

常に少なくとも1つのタスクマネージャがあるはずです。TaskManager でのリソーススケジューリングの最小単位は、、タスク_スロット_です。TaskManager でのタスクスロットの数は、同時処理タスクの数を示します。タスクスロットでは複数のオペレータが実行される可能性があることに注意してください(タスクとオペレーションチェーンを参照してください)。

タスクとオペレータのチェーン #

分散実行の場合、Flink はオペレータのサブタスクをチェーンしてタスクにします。各タスクは1つのスレッドによって実行されます。オペレータをタスクに繋ぎ込むことは有用な最適化です: スレッド間のハンドオーバーとバッファバッファリングのオーバーヘッドを減らし、レイテンシを減らす一方で全体のスループットが向上します。繋ぎ込みの挙動は設定できます; 詳細は、繋ぎ込みのドキュメント参照してください。

以下の図のデータフローは5つのサブタスク、つまり5つの並列スレッドで実行されます。

タスクスロットとリソース #

各ワーカー(TaskManager)はJVM プロセスで、個々のスレッド1つ以上のサブタスクを実行する可能性があります。タスクマネージャーが受け付けるタスクの数を制御するために、タスクマネージャーは(少なくとも1つの)いわるゆタスクスロットを持ちます。

各タスクスロットはタスクマネージャーのリソースの固定のサブセットを表します。3つのスロットを持つタスクマネージャーは、管理対象メモリの1/3を各スロットの専用にしますリソースをスロット化することは、サブタスクが管理メモリを他のジョブのサブタスクと競い合わないことを意味しますが、その代わりにある程度の管理メモリが予約されることを意味します。ここではCPUの分離は起こらないことに注意してください。現在のところ、スロットはタスクの管理メモリを分割するだけです。

タスクスロットの数を調整することで、ユーザはサブタスクがお互いに分離する方法を定義できます。タスクマネージャーごとに1つのスロットを持つことは、各タスクグループが別個のJM内で実行することを意味します。(例えば、別個のコンテナ内で開始することができます)。複数のスロットを持つことは、多くのサブタスクが同じJVMを共有することを意味します。同じJVM内のタスクは(マルチプレクサを使って)TCP接続とハートビートメッセージを共有することを意味します。まあ、データセットやデータ構造を共有することもできるため、タスクごとのオーバーヘッドが削減されます。

デフォルトでは、サブタスクが異なるタスクのサブタスクであっても、同じジョブのものからである限り、サブtラスクがスロットを共有することを許可します。その結果、1つのスロットにジョブのパイプライン全体が保持される可能性があります。このスロット共有を許可すると、次の2つの主な利点があります:

Flinkクラスタには、ジョブで使われる最も高い並列処理と正確に同じ数のタスクスロットが必要です。プログラムが全体でどれだけの数の(異なる並行度の)タスクを含むかを計算する必要はありません。
より良いリソースの利用をすることが容易です。スロット共有がないと、非集中型の source/map() サブタスクは、リソース集中型の window サブタスクと同数のリソースをブロックします。スロット共有により、この例の基本並列性を2から6に増やすと、重いサブタスクをタスクマネージャに公平に分散するようにしながら、スロット付きリソースを最大限に活用するようにします。

Flink アプリケーションの実行 #

_Flink アプリケーション_は、main() メソッドから1つ以上の Flink ジョブを生成するユーザプログラムです。これらのジョブの実行は、ローカル JVM (LocalEnvironment) または複数のマシーンを持つクラスタのリモートセットアップ (RemoteEnvironment) で実行されます。プログラムごとに、ExecutionEnvironment がジョブの実行を制御(例えば、並列処理の設定など)し、外部とやりとりをするためのメソッドを提供します(Flink プログラムの内部構造を参照してください)。

Flink アプリケーションのジョブは、長時間実行されている Flink セッションクラスタ、専用の Flink ジョブクラスタ(非推奨)、Flink アプリケーションクラスタです。これらの選択肢の違いは、主にクラスタのライフサイクルとリソース分離の保証に関連しています。 isolation guarantees.

Flink アプリケーションクラスタ #

クラスタのライフサイクル: Flink アプリケーションクラスタは、1つの Flink アプリケーションからのジョブのみを実行する専用のクラスタであり、main() メソッドはクライアントではなくクラスタで実行されます。ジョブの送信は1ステップのプロセスです: 最初に Flink クラスタを起動してから既存のクラスタセッションにジョブを送信する必要はありません; 代わりに、アプリケーションロジックと依存関係を実行可能なジョブを JAR にパッケージ化し、クラスタエントリーポイント (ApplicationClusterEntryPoint) が JobGrraph を抽出するために main() メソッドを呼び出す責任があります。これにより、例えば Kubernetes 上の他のアプリケーションと同じように、Flink アプリケーションを配備できます。従って、Flink アプリケーションクラスタのライフタイムは、Flink アプリケーションのライフタイムに制限されます。
リソースの分離: Flink アプリケーションクラスタでは、ResourceManager と Dispatcher は単一の Flink アプリケーションに限定され、Flink セッションクラスタよりも懸念事項が適切に分離されます。

Flink セッションクラスタ #

クラスタのライフサイクル: Flink セッションクラスタでは、クライアントは複数のジョブの送信を受け付けることができる既存の長時間実行中のクラスタに接続します。全てのジョブが終了した後でも、クラスタ(とJobManager)はセッションが手動で停止されるまで実行を続けます。従って、Flink セッションクラスタのライフタイムは、Flink ジョブのライフタイムに制限されません。
リソースの分離: TaskManager のスロットはジョブの送信時に ResourceManager によって割り当てられ、ジョブが完了すると解放されます。全てのジョブは同じクラスタで共有しているため、ジョブの送信フェーズでのネットワーク帯域幅など、クラスタのリソースの競合が発生します。この共有セットアップの制限の1つは、1つの TaskManager がクラッシュすると、この TaskManager でタスクが実行ｓれている全てのジョブが失敗することです; 同様に、JobManager で致命的なエラーが発生した場合、クラスタ内で実行されている全てのジョブに影響します。
その他の考慮事項: 既存のクラスタがあると、リソースの適用と TaskManager の起動にかかる時間を大幅に節約できます。これは、ジョブの実行時間が非常に短く、起動時間が長いとエンドツーエンドのユーザエクスペリエンスに悪影響を与えるシナリオで重要です。これは、ジョブが既存のリソースを使って迅速に計算をすることが望ましい、短いクエリの対話型分析の場合と同様です。

以前は、Flink セッションクラスタはセッションモードの Flink クラスタとも呼ばれていました。

Flink ジョブクラスタ (非推奨) #

per-job モードは YARN でのみサポートされており、Flink 1.15 で非推奨になりました。 FLINK-26000 でドロップされます。 YARN 上でジョブごとに専用のクラスタを起動するアプリケーションモードを検討してください。

クラスタのライフサイクル: Flink ジョブクラスタでは、(YARNのような)利用可能なクラスタマネージャーは送信されたジョブごとにクラスタをスピンアップするために使われ、このクラスタはそのジョブでのみ使われます。ここで、クライアントはまずクラスタマネージャにリソースを要求して JobManager を起動し、このプロセス内で実行されている Dispatcher にジョブを送信します。その後、TaskManagers はジョブのリソース要求に基づいて遅延的に割り当てられます。ジョブが完了すると、Flink ジョブクラスタは破棄されます。
リソースの分離: JobManager での致命的なエラーは Flink ジョブクラスタで実行中の1つのジョブにのみ影響します。
その他の考慮事項: ResourceManager は、外部リソース管理コンポーネントが TaskManager プロセスを開始してリソースを割り当てるために依頼して待つ必要があるため、Flink ジョブクラスタは実行時間が長く、高安定性の要件で、長い起動時間を気にしない大規模なジョブにより適しています。

以前は、Flink ジョブクラスタはジョブ(またはジョブごと)モードの Flink クラスタとも呼ばれていました。

Flink ジョブクラスタは YARN でのみサポートされます。