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

デプロイメント #

Flinkは多用途のフレームワークであり、様々なデプロイメントシナリオを組み合わせてサポートします。

以下では、Flinkクラスタの構築要素、その目的、利用可能な実装について簡単に説明します。 Flinkをローカルで起動するだけの場合は、スタンドアローンをセットアップすることをお勧めします。

概要とリファレンスアーキテクチャ #

以下の図は、全てのFlinkクラスタの構成要素を示しています。常にどこかでクライアントが実行されています。Flinkアプリケーションのコードを取得し、それをJobGraphに変換し、JobManagerに送信します。

JobManagerは、実際のオペレータ(ソース、変換、シンクなど)が実行されているTaskManagerに作業を分散します。

Flinkをデプロイする場合、各構成要素に複数のオプションが利用できることがあります。それらを図の下の表にリストしました。

Figure for Overview and Reference Architecture

コンポーネント	目的	実装
Flinkクライアント	バッチまたはストリーミングアプリケーションをデータフローグラフいｎコンパイルし、JobManagerに送信します。	}}">コマンドラインインタフェース }}">RESTエンドポイント }}">SQLクライアント }}">Python REPL
ジョブマネージャー	JobManagerはFlinkの中央作業調整コンポーネントの名前です。これには、高可用性、リソース割り当て動作、サポートされるジョブの送信モードが異なる様々なリソースプロバイダ用の実装が含まれます。 JobManager ジョブ送信用のモード: アプリケーションモード: 1つのアプリケーションに対して排他的にクラスタを実行します。ジョブのメインメソッド(またはクライアント)はJobManager上で実行されます。アプリケーション内で`execute`/`executeAsync`を複数回呼び出すことがサポートされています。 Per-Jobモード: 1つのジョブに対して排他的にクラスタを実行します。ジョブのメインメソッド(またはクライアント)は、クラスタの作成前にのみ実行されます。セッションモード: 1つのJobManagerインスタンスが、同じTaskManagerクラスタを共有する複数のジョブを管理します。	}}">スタンドアロン (これは、JVMの起動のみを必要とするベアボーンモードです。}}">Docker、Docker Swarm / Compose、}}">非ネイティブKubernetes、他のモデルを使ったデプロイは、このモードでの手動セットアップによって可能です) }}">Kubernetes }}">YARN
TaskManager	TaskManagersは、Flinkジョブの作業を実際に実行するサービスです。
外部コンポーネント (全てオプション)
高可用性サービスプロバイダ	FlinkのJobManagerは高可用性モードで実行でき、FlinkがJobManagerの障害から回復できるようになります。フェイルオーバーを高速化するために、複数のスタンバイJobManagersをバックアップとして起動することができます。	}}">Zookeeper }}">Kubernetes HA
ファイルストレージと一貫性	チェックポイント(ストリーミングジョブの回復の仕組み)の場合、Flinkは外部ファイルストレージシステムに依存します。	}}">FileSystemsページを参照してください。
リソースプロバイダ	Flinkは、KubernetesやYARNなどの様々なリソースプロバイダフレームワークを通じてデプロイできます。	上記のJobManager実装を参照してください。
メトリクスストレージ	Flinkコンポーネントは内部メトリクスをレポートし、Flinkジョブは追加のジョブ固有のメトリクスもレポートできます。	}}">メトリクスレポーターページを参照してください。
アプリケーションレベルのデータソースとシンク	アプリケーションレベルのデータソースとシンクは技術的にはFlinkクラスタコンポーネントのデプロイメントの一部ではありませんが、新しいFlinkプロダクションデプロイメントを計画する際には考慮する必要があります。頻繁に使われるデータをFlinkと同じ場所に配置すると、パフォーマンスが大幅に向上します	例えば: Apache Kafka Amazon S3 Elasticsearch Apache Cassandra }}">Connectorsページを参照してください。

反復可能なリソースクリーンアップ #

ジョブが完了、失敗、キャンセルのいずれかのグローバルな最終状態に達すると、そのジョブに関連付けられた外部コンポーネントはリソースがクリーンアップされます。リソースのクリーンアップ時に失敗した場合、Flinkはクリーンアップの再試行を試みます。使用する再試行戦略を設定できます。再試行が成功せずに最大回数に達すると、ジョブがダーティ状態のままになります。そのアーティファクトは手動でクリーンアップする必要があります(詳細は高可用性サービス/JobResultStoreのセクションを参照してください)。まったく同じジョブを再起動すると(つまり、同じジョブIDを使って)ジョブを再実行せずにクリーンアップが再開されます。

現在、通常のCompletedCheckpoint管理の一部として組み込む時に削除に失敗するというCompletedCheckpointのクリーンアップの問題があります。これらのアーティファクトは反復可能なクリーンアップの対象ではないため、依然として手動で削除する必要があります。これは、FLINK-26606でカバーされます。

デプロイメントモード #

Flinkは次の3つの方法のいずれかでアプリケーションを実行できます:

アプリケーションモード。
セッションモード
Per-Jobモード(非推奨)。

上記のモードは次の点で異なります:

クラスタのライフサイクルとリソース分離の保証
プリケーションのmain()メソッドがクライアントで実行されるかクラスタで実行されるかどうか。

アプリケーションモード #

他の全てのモードでは、アプリケーションのmain()メソッドはクライアント側で実行されます。このプロセスには、アプリケーションの依存関係をローカルにダウンロードし、main()を実行してFlinkのランタイムが理解できるアプリケーションの表現(つまり、JobGraph)を抽出し、依存関係とJobGraph(s)をクラスタに追加します。これにより、依存関係をダウンロードしてクラスタにバイナリを送信するためにかなりのネットワーク帯域幅が必要になる可能性があり、main()を実行するためにCPUサイクルが必要になるため、クライアントは大量のリソースを消費します。この問題は、クライアントがユーザ間で共有されている場合にさらに顕著になる可能性があります。

この観察に基づいて、アプリケーションモードは送信されたアプリケーションごとにクラスタを作成しますが、今回はアプリケーションのmain()メソッドがJobManagerによって実行されます。アプリケーションごとにクラスタを作成することは、特定のアプリケーションのジョブ間でのみ共有されるセッションクラスタを作成し、アプリケーションの終了時に停止することと見なすことができます。このアーキテクチャーでは、アプリケーションモードはPer-Jobモードと同じリソース分離と負荷分散の保証をアプリケーション全体の粒度で提供します。

アプリケーションモードはユーザのjarsがアクセスする必要がある全てのFlinkコンポーネントのクラスパス(usrlibフォルダ)上ですでに利用可能であるという前提に基づいて構築されます(JobManager、TaskManager)。つまり、アプリケーションはFlink配布物にバンドルされています。これにより、アプリケーションモードでは、他のデプロイメントモードのようにRPC経由でFlinkコンポネントに配布する必要がなくなり、デプロイメント/回復が高速化されます。

アプリケーションモードはユーザのjarsがFlink配布物にバンドルされていることを前提とします。

クラスタ上でmain()メソッドを実行することは、registerCachedFile()を使って環境に登録したパスにアプリケーションのJobManagerがアクセス可能である必要があるなど、コードに他の暗黙の前提があることを意味します。

*Per-Job (非推奨)*モードと比較して、アプリケーションモードでは複数のジョブからなるアプリケーションを送信できます。ジョブの実行順序はデプロイメントモードに影響されませんが、ジョブの起動に使われる呼び出しによって影響されます。 to launch the job. ブロックしているexecute()を使うと順番が決められ、“this"ジョブが終了するまで"next"のジョブの実行が延期されます。ブロックしないexecuteAsync()を使うと、“this"ジョブが完了する前に"next"ジョブが開始されます。

アプリケーションモードは複数のexecute()アプリケーションが可能ですが、この場合高可用性はサポートされません。アプリケーションモードの高可用性は、単一のexecute()アプリケーションでのみサポートされます。

さらにアプリケーションモードで実行中の複数のジョブ(例えばexecuteAsync()を使って送信されたもの)のいずれかがキャンセルされると、全てのジョブが停止されJobManagerがシャットダウンされます。通常のジョブの完了(ソースのシャットダウンによる)がサポートされています。

セッションモード #

セッションモードは、既に実行中のクラスタを想定し、そのクラスタのリソースを使って送信されたアプリケーションを実行します。同じ(セッション)クラスタ内で実行されるアプリケーションは同じリソースを追懐、その結果同じリソースをめぐって競合します。これには、送信されたジョブごとに完全なクラスタをスピンアップするリソースのオーバーヘッドが発生しないという利点があります。ただし、ジョブの1つが誤動作したりTaskManagerがダウンしたりすると、そのTaskManagerで実行している全てのジョブが障害の影響を受けます。これは、障害のお原因となったジョブへの悪影響とは別に、再起動中の全てのジョブがファイルシステムに同時にアクセスし、他のサービスが利用できなくなる可能性がある大規模な回復プロセスを意味します。さらに、単一のクラスタで複数のジョブを実行すると、クラスタ内の全てのジョブの記録を担当するJobManagerの負荷が増加することになります。

Per-Jobモード(非推奨) #

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

より優れたリソース分離の保証を提供することを目的として、Per-Jobモードは利用可能なリソースプロバイダフレームワーク(例えば、YARN)を使って送信されたジョブごとにクラスタを起動します。このクラスタはそのジョブでのみ利用可能です。ジョブが終了すると、クラスタは破棄され、残っているリソース(ファイルなど)はすべて消去されます。これにより、誤動作したジョブはそれのTaskManagerのみをダウンさせることができるため、リソースの分離が向上します。さらに、ジョブごとに1つのJobManagerがあるため、複数のJobManagerにログの記録の負荷が分散されます。

概要 #

セッションモードでは、クラスタのライフサイクルはクラスタ上で実行されているジョブのライフサイクルから独立しており、リソースは全てのジョブ間で共有されます。 アプリケーションモードは、アプリケーションごとにセッションクラスタを作成し、クラスタ上でアプリケーションのmain()メソッドを実行します。したがって、リソースは単一のmain()メソッドから起動されたジョブによってのみ使われるため、リソースの分離が向上します。これは、アプリケーションごとに専用のクラスタを起動するという代償が伴います。