v1.5-SNAPSHOT
プロダクションの準備ができたチェックポイント
プロダクションの準備ができたチェックポイント
このプロダクションの準備ができたチェックリストの目的は、Flinkのジョブをproductionに持っていくことを計画する場合に、重要で慎重な考慮を必要とする設定オプションの要約された概要を提供することです。これらのオプションのほとんどについて、FlinkはFlinkの使用と適用が簡単になるようにそのまま使えるデフォルトを提供します。多くのユーザとシナリオについて、これらのデフォルトは開発にとって良い開始点であり、“one-shot” ジョブに完全に満足なものです。
しかし、いったんFlinkアプリケーションをプロダクションに移す計画を立てると、要求は一般的に増加します。例えば、ジョブを(re)スケーラブルにしたいと思い、ジョブと新しいFlinkバージョンのための良いアップグレード ストーリーを持ちたいと思います。
以下では、ジョブをプロダクションに入れる前にチェックしなければならない設定オプションのコレクションを紹介します。
明示的にオペレータの最大並行度を設定
最大並行度はFlink 1.2で導入された設定パラメータで、Flinkのジョブの(再)スケーラビリティに重要な意味合いを持ちます。ジョブごと および/または オペレータごとの粒度で設定することができるこのパラメータは、オペレータをスケールすることができる最大の並行度を決定します。(現時点では)ジョブを完全に最初から再開することを除いて、ジョブが開始された後でこのパラメータを変更する方法がないことを理解することが重要です (つまり、以前のチェックポイント/セーブポイントからではなく、新しい状態で)。Even if Flink would provide some way to change maximum parallelism for existing savepoints in the future, you can already assume that for large states this is likely a long running operation that you want to avoid. この時点で、このパラメータのデフォルトとしてとても高い値を単に使わないのか不思議に思うかもしれません。この背景の理由は、Flinkは最大並行度と共に増加するかもしれない再スケールの機能のために特定のメタデータを維持する必要があるため、高い最大並行度はアプリケーションのパフォーマンスと状態のサイズにさえになんらかの影響を持つかもしれません。一般的に拡張性の必要に見合うのに十分高い最大並行度を選択する必要がありますが、できる限りそれを低くすることでパフォーマンスがわずかに良くなるかもしれません。特に、128より高い最大並行度は一般手kにキー付けされたバックエンドからわずかに大きな状態のスナップショットになるでしょう。
最大並行度は以下の条件を満たす必要があります:
0 < parallelism <= max parallelism <= 2^15
setMaxParallelism(int maxparallelism)によって最大並行度を設定することができます。デフォルトでは、Flinkは最大並行度をジョブが最初に開始した時の並行度の機能として選択するでしょう:
128: for all parallelism <= 128.MIN(nextPowerOfTwo(parallelism + (parallelism / 2)), 2^15): for all parallelism > 128.
オペレータのためのUUIDを設定
セーブポイントのドキュメントで述べられたように、ユーザはオペレータのためのuidを設定しなければなりません。Those operator uids are important for Flink’s mapping of operator states to operators which, in turn, is essential for savepoints. デフォルトではオペレータのuidはJobGraphの行き来とあるオペレータのプロパティのハッシュによって生成されます。ユーザの視点からこれは快適ですが、JobGraphへの変更(例えば、オペレータの交換)は新しいUUIDに繋がるため、これはとても脆くもあります。安定したマッピングを確立するために、setUid(String uid)を使ってユーザによって提供される安定したオペレータのuidが必要です。
状態のバックエンドの選択
現在のところ、Flinkはセーブポイントを取った同じ状態バックエンドのためのセーブポンとから状態を回復することだけしかできないという制限があります。例えば、このことはメモリー状態のバックエンドを持つセーブポイントを取ることができず、RocksDB状態バックエンドを使い回復するためのジョブを変更することができないことを意味します。将来バックエンドを共通利用できるようにする計画をしていますが、まだできません。このことは、プロダクションに行く前にジョブのためにどのバックエンドを使うかを注意深く考慮しなければならないことを意味します。
一般的に、RocksDBは現在のところ大きな状態(つまり、利用可能なメインメモリを超える状態)と非同期のスナップショットをサポートする唯一の状態バックエンドなため、RocksDBを使うことをお勧めします経験上、非同期のスナップショットはオペレータをブロックせず、Flinkはスナップショットをストリームの処理の停止無しに書くことができるため、大きな状態にとってとても重要です。しかし、RocksDBは、例えばメモリーベースの状態バックエンドよりも、パフォーマンスが悪いかもしれません。状態がメインメモリを超えることがなく、書き込むためにストリームの処理がブロックされることが問題では無い場合は、RocksDBのバックエンドを使わないことも判断することができます。しかし、この時点ではプロダクションのためにRocksDBを使うことを強くお勧めします。