しばらくApache Flinkを試してみたので、感想を書いておこうと思う.

試したこと

• standalone modeでのクラスタ構築
• ストリーミングジョブを書いてみる
  • TumblingTimeWindowやSlidingTimeWindowでの集計
  • Kafka SourceとElasticsearch Sinkの利用
  • 必要だったので、カスタムトリガは書いた
• 幾つかのジョブで性能測定
• 社内の本番fluentdからKafka経由でFlinkにストリームを投入し、ジョブを十数日くらい連続稼働してみる
• state backendをHDFSやRocksDBにしてみる
• JobManager HA
• TaskManagerやJobManagerを落としてみる
• Flink on YARN (ジョブを起動してみただけ)

試してないこと

• DataSet APIの利用
• savepoint, savepointからの復旧
• event timeやingenstion timeの利用(processing timeしか使ってない)
• 複数ジョブの相乗り
• 高トラフィックかつ複数ジョブでの連続稼働
• Flink on YARNをもうちょっと色々使ってみる
• (多分他にも色々)

所感

全体としてはすごく良く出来ていると思う. プロセスが落ちたりしても勝手に復旧するし、性能も出るし、WebUIやREST APIで色々情報取れるので運用もしやすそう. 今後は本番に入れていこうと思っている.

• ちゃんと動く？
  • 期待通りに動かなくて、MLで聞いたらBugだ、って言われて直してくれたのが2件
  • ContinuousProcessingTimeTriggerは期待通りの動作をしなかったので、修正版を書く必要があった
  • 後は、上記の範囲では特に問題なく動いている
• 処理の書きやすさ
  • APIがハイレベルなので、割と少ないコードで処理を書くことができて良い
  • 状態の保存とか、windowとか、自分で書くのは大変なのでその辺の面倒はFlinkが見てくれる
• 性能
  • もちろん処理によるが、単純なものであれば1CPUで10万records/sec以上は普通に処理できそう
• 耐障害性
  • ジョブ実行中にJobManagerやTaskManagerを落としてみたが、勝手に復旧された. すごい.
  • HDFS障害でどう振る舞うか？はまだ試せてないけど気になるところ
• 運用
  • WebUIやREST APIで色々取れる. WebUIで大抵のものは見える印象.
  • スロット数とかはもちろん、ジョブ内のオペレータ単位で処理レコード数とか取れる
  • チェックポイントの所要時間やサイズも取れる
• 不安なところ
  • チェックポイントのサイズには注意がいりそう. FsStateBackendの場合、状態は全て各TaskManagerのメモリに持ち、チェックポイントでHDFSに書き出される. 差分スナップショット的なものはないので、状態が大きくなってくるとスナップショットに時間がかかり、性能劣化する. キー(keyByで指定する奴)の数が大きいケースでは、RocksDBを使うことで改善されるらしいが、まだそれが有効なケースに出会ってない.
  • FlinkジョブをYARNで動かす場合を除いて、各TaskManagerは1プロセスで、その中で複数ジョブがスレッドとして動く形になっているのでisolationの部分は不安. あるジョブに引きづられてTaskManagerが固まるとかありそう.
  • ストリーム処理のプロダクトはいくつかあるし、Facebook, Twitter, Likedinみたいな大御所がバックにいるわけではないので、生き残っていくのだろうか

まとめ

ということで、自分がしばらく試しての所感を書いてみた. 実績の少ないプロダクトという意味での不安感はあるけど、性能、拡張性、耐障害性、APIの使いやすさは素晴らしいと思うので、使っていきたい. これ以上は使ってみないとわからないと思うし. あと、Flink on YARNの場合はYARNが動くクラスタがあれば、別途サーバを用意しなくてもFlinkジョブを動かすことができるので、既にHadoop環境がある場合なんかは、とりあえず試してみると良いんじゃないかと思う.