本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。

Apache Flink® コミュニティをフォローして、最先端のストリーム処理チュートリアルとアーキテクチャの詳細な解説を入手しよう。

はじめに

あなたはこのような状況に遭遇したことがありますか？会議中に全員が深く議論しているときに、突然誰かが退出してしまうという状況です。最悪なのは、ホストが「よし、最初からやり直そう！」と言う瞬間です。全員が困惑します。「なぜ一人が切断しただけで全員が再開しなければならないのか？時間の無駄ではないか？」と。Flink の初期バージョンでは、タスクの障害処理がまさにこのように動作していました。つまり、一つのタスクが失敗すると、すべてのタスクが再起動する必要がありました。今日の FLIP-1 は、この「一つが失敗すれば全員が影響を受ける」問題を特に解決することを目的としています。この改善は二つの段階で行われました。Flink 1.3 では部分的な回復メカニズムが導入され、Flink 1.9 では中間データの取り扱いがアップグレードされました。

古い方法の何が問題だったのか？

大規模な電子商取引プラットフォーム向けの注文処理システムを管理していると想像してください。そのシステムには、それぞれ注文の一部を処理する100個のタスクが並列で動作しています。そして突然、あるタスクに問題が発生します。古い方法では、100個すべてのタスクが停止して再起動する必要がありました。これにより三つの大きな問題が発生しました。

問題 1: リソースの浪費

一人が退出しただけで会議全体を再開するのはばかげているのと同じように、一つのタスクが失敗しただけで全てのタスクを再起動するのは非常に無駄です。特にシングルスデーのようなピークイベントの際、小さな不具合が原因で注文システム全体が再起動する影響を想像できますか？

問題 2: 回復の遅さ

完全な再起動は、すべてのタスクが再度準備を行うことを意味します。マシンリソースの再割り当て、以前保存された状態の再読み込み、タスク間の接続の再確立…まるで、大規模な会議が再編成されるようなものです。全員が席を見つけ、ネットワークに再接続し、資料を準備する必要があり、非常に時間がかかります。

問題 3: ネットワークの混雑

すべてのタスクが同時に状態を回復しようとすると、オフィスの全員が一度に同じファイルをダウンロードしようとするようなもので、ネットワークが必然的に遅くなります。この集中したダウンロードは他のシステムの通常運用にも影響を与える可能性があります。この状況は異なる種類のタスクによって異なった形で現れます。

ストリーム処理タスク（継続的にデータを処理する必要があるタスク）の場合、タスクが緊密に結合されている場合、例えば注文システムにおける「注文→支払い→配送」の順序のように、一箇所での問題が全体のフローに影響を与えることがあります。しかし、タスクが独立している場合、例えば異なる地域からの注文を処理する場合、全員が再起動する必要はありません。
バッチ処理タスク（一度に大量のデータを処理するタスク）の場合、さらに状況は悪化します。中間状態を保存していないため、エラーが発生するとすべての計算を最初からやり直す必要があります。Excel がクラッシュしてすべての計算をやり直す必要があるようなものです。

FLIP-1 はこれをどのように解決するのか？

まず、従来の回復メカニズムと FLIP-1 を視覚的に比較しましょう。

FLIP-1 のアプローチは巧妙で、二つのステップで構成されています。

ステップ 1: タスクをブロックのように分解する

まず、タスクをブロックに分割します。各ブロック内のタスクは関連性があり、異なるブロックは比較的独立しています。タスクが失敗した場合、そのブロックのみが再起動し、他のブロックは引き続き動作することができます。例として、異なる都市からの注文データを処理していると仮定しましょう。北京の注文処理システム（タスク A1 と A2）と上海の注文処理システム（タスク B1 と B2）は独立しています。北京の A1 タスクが失敗した場合、A1 と A2 のみが再起動し、上海の B1 と B2 は通常通り動作を続けることができます。ただし、タスク間でデータを交換する必要がある場合は話が複雑になります。例えば、A2 が B1 にデータを送信する必要がある場合、A1 が失敗すると B1 も再起動が必要になるかもしれません。ドミノ倒しのように、それらの接続を確認する必要があります。次の二つの異なるシナリオを見てみましょう。

ステップ 2: 賢い中間データ管理

第二段階では主にデータ転送の問題に対処します。システムは三つの保存方法を設計しました。

信頼できるストレージ: 各タスクに独自の USB ドライブを提供するようなもので、必要な時にいつでもデータを保存し、簡単に復旧できます。
メモリバッファ: メモリ内に一時データ用のメモ帳を置くようなものです。この方法は高速ですが揮発性であり、短期記録に適しています。
完全なバッチ: バッチ処理専用に設計されており、出荷が完了するまで待つようなものです。待ち時間が長くなるものの、データの完全性を保証します。

実装方法

実装は二つの重要なポイントに焦点を当てています。

まず、指揮官（JobMaster）が全体の回復プロセスを調整します。プロジェクトマネージャーのように、各タスクの状態を把握し、リソースを合理的に割り当て、正しいデータ伝送を確保します。また、システムにはハートビートメカニズムも含まれており、「まだそこにいますか？」と定期的に確認することで、各タスクが生きていることを保証します。

次に、三つの回復戦略を提供します。

全体再起動（最も安全な方法）
失敗したタスクのみ再起動（最も軽量な方法）
関連領域のスマート再起動（最もバランスの取れた方法）

どのような利点をもたらすのか？

これらの改善により、Flink には具体的な利点がもたらされます。

まず、リソースを節約します。医者が患者を治療するときのように、今では病気の人だけを治療でき、全員が健康診断を受ける必要はありません。

次に、回復が速くなります。問題を正確に特定できるため、回路の修理のように、短絡の場所がわかればその箇所だけを修理すればよく、回路基板全体を交換する必要はありません。

実用的な使用のヒント

FLIP-1 の新しいメカニズムを使用する際、この機能を最大限に活用するためのいくつかの実践的なヒントを紹介します。

1. 適切な回復戦略の選択

医師が適切な薬を処方するように、異なる種類のジョブには適切な回復戦略が必要です。