Airflowを運用しています。チームもそれを知っています。DAGは動作しています。それなのに、なぜ突然「リアルタイムが必要だ」と聞こえてくるのでしょうか？そして、実際にどうすればいいのでしょうか？
消えない要求
最初はビジネス側から来ます。通常はSlack経由で: 「ダッシュボードを1日1回以上更新できますか？」 次にプロダクトから: 「不正防止チームは、数秒以内に問題を把握したいと言っています。」 そして次の計画会議でCTOから: 「なぜ我々はまだバッチを実行しているのに、競合他社はリアルタイムで動いているのか？」
あなたはAirflowの担当者です。堅実なバッチ運用を構築しました。DAGはスケジュール通りに実行されます。チームはそれをデバッグできます。ランブックも持っています。そして今、皆が一夜にしてストリーミングエンジニアになることを求めています。
このガイドはその瞬間のためのものです。リアルタイムが重要である理由を説明するものではありません — おそらくそれはすでに理解しているでしょう。これは、リアルタイムの要求が来たときに、既存のAirflowセットアップで実際に何をするかについてのものです。
Airflowが限界に達するところ
Airflowはワークフローオーケストレーターです。スケジュールやトリガーでタスクを実行します。それは非常に便利で、多くの場面で適切なツールです。しかし、限界を見せ始める本当のユースケースがあります。
明らかなのはレイテンシです。 最短のスケジュールが15分であれば、すべてのダウンストリームは最低でも15分待ちます。あるWorkflows — 日次レポート、バルクAPI同期、機械学習トレーニングパイプライン — ではそれで問題ありません。しかし、他のもの — 不正アラート、在庫更新、ユーザー通知 — では15分は永遠です。
高頻度のトリガーは高コストになります。 数秒ごとにタスクをスケジュールすることは、毎秒数千のイベントに反応する必要があるときに崩壊します。条件をポーリングするセンサータスクを持つことになりますが、それはAirflowが設計された目的ではありません。
イベント間の状態が扱いにくい。 Airflowタスクはステートレスで短命です。数百万の個々のイベントにわたって状態を維持する必要がある場合 — セッションウィンドウの追跡、リアルタイム集計の構築、順序外到着の処理 — パラダイムと戦うことになります。
これはAirflowの批判ではありません。異なるツールを選ぶべき時を知ることです。
現実的な4つの選択肢
チームが「ストリーミングに移行すべきか？」と尋ねるとき、実際の質問は「リアルタイム機能への最も低コストな道は何か？」です。ここにチームが実際に取る4つの道があります：
1. すべてをAirflowに維持し、より頻繁にスケジュールする。 一部のチームにとって、DAGを5分ごとに実行することは十分です。「リアルタイム」が「数分以内」を意味する場合、cronレベルのスケジューリングで新しいインフラを追加せずにそこに到達できます。より速く反応するためにKafkaが必要だと仮定しないでください — 現在のツールがすでにできるか確認してください。
2. Airflowの横にストリーミングレイヤーを追加する。 これは成熟したチームにとって最も一般的な道です。バッチWorkflows、複雑な依存関係ツリー、人間が関与するステップを含むものにはAirflowを維持します。イベント駆動の低レイテンシのワークロードにはストリーミングプラットフォームを追加します。これらは共存します。
3. 特定のパイプラインを完全にストリーミングに移行する。 時にはAirflowで実行されるワークフローが、そもそもAirflowにあるべきではないことがあります — それが構築されたときに利用可能な唯一のツールだっただけです。高ボリュームのイベント駆動パイプラインには、ストリーミングインフラへの完全な移行が理にかなっています。
4. Airflowを完全に置き換える。 めったに正しい選択ではありませんが、組織がイベント駆動アーキテクチャに完全にコミットし、すべてを処理する1つのシステムを望む場合に発生します。移行コストは高く、リスクは現実です。
ほとんどのチームは、特定のパイプラインに対してオプション2または3を実行します。それが実際的な現実です。
実際に持っているものを評価する方法
何かを計画する前に、実際のワークロードをマップします。理論ではなく、実践で。
レイテンシに敏感なパイプラインを見つける。 どのDAGが顧客やユーザーが直接やり取りするダウンストリームシステムにフィードしていますか？どのDAGが、データが5分古いのか5秒古いのかでビジネスの成果を変えるデータを提供していますか？そこから始めます。
ハンドオフを数える。 データが複数のDAGを順番に通過するパイプラインを見てください。各ハンドオフはレイテンシと失敗の表面を追加します。ストリーミングはしばしば複数のバッチステップを1つの連続したフローにまとめることができます。
消費者と話す。 エンジニアリングリードではなく、実際のビジネスユーザーと話します。彼らにとって「リアルタイム」が何を意味するのかを尋ねます。ビジネスにとっての「リアルタイム」が彼らにとって「1時間以内」であることが多く、それが優先順位を完全に変えます。
運用能力を評価する。 ストリーミングは異なる失敗モードを導入します：消費者の遅れ、パーティションの偏り、ブローカーディスクの使用量。チームがすでにバッチパイプラインの維持で手一杯の場合、ヘッドルームなしでストリーミングを追加すると問題が発生します。
すべてを壊さない移行
最悪の移行方法は、それを書き直しとして扱うことです。DAGを取り除き、ストリーミングバージョンを構築し、本番で機能することを願う。
実際的な道は段階的です。
ステップ1: シャドウモード。 レイテンシに本当に敏感なバッチパイプラインを1つ選びます。そのストリーミングバージョンを並行して構築します。ストリーミングの出力をテストまたはステージングの消費者にルーティングし、本番にはしません。少なくとも1つの完全なサイクルの間、並行して実行させます。
ステップ2: 検証。 ストリーミングパイプラインがバッチバージョンと同じ結果を生成するか確認します。集計の場合、これは数値を比較することを意味します。イベントルーティングの場合、期待されるすべてのイベントが期待される目的地に到達したことを確認します。このステップをスキップしないでください。
ステップ3: デュアルライト期間。 非クリティカルな本番消費者をストリーミング出力に向け、バッチ出力を主要なソースとして維持します。エラーレート、レイテンシ分布、消費者の遅れを監視します。壊れたものを修正します。
ステップ4: 切り替え。 成功したデュアルライト期間の後、ストリーミング出力を主要にします。定義された期間 — 1週間、2週間 — バッチパイプラインをスタンバイとして実行し続け、廃止します。
ステップ5: 繰り返し。 教訓を適用します。各移行は前回よりも速くなります。
ハイブリッド期間はオプションではありません — 新しいシステムを検証している間、データへの信頼を維持する方法です。
既に構築したAirflow DAGはどうする？
これは誰もよく答えない質問です。現実には、既存のDAGはデータとWorkflowsに関する蓄積された知識を表しています。それを捨てないでください。
一部のDAGはストリーミングに移行すべきです。他のものはバッチのままであるべきです — なぜならワークフローが本当にバッチ指向であり、レイテンシ要件が現実的であり、毎時の間隔で管理可能であるか、変換ロジックが複雑であり、再構築する価値がないからです。
有用なヒューリスティック：パイプラインが主にスケジュールに従ってデータをAからBに移動するために存在する場合、それはストリーミングの候補かもしれません。複数ステップの変換を条件付きロジックと人間の承認ゲートでオーケストレーションするために存在する場合、Airflowはおそらくまだ適切な場所です。
目標はAirflowを置き換えることではありません。それが役に立つところにストリーミングを追加し、各ツールが実際に得意なことをさせることです。
うまくいっているときの良い例
移行がうまくいくと、ビジネスが気づきます — インフラではなく。
以前は発生から6時間後にフラグ付きトランザクションをレビューしていた不正アナリストが、今では1分以内にレビューしています。昨日の数字を確認するために毎朝ダッシュボードをチェックしていたプロダクトマネージャーが、今ではイベントが発生するたびに更新を見ています。これらは最適化する価値のある成果です。
インフラチームも気づきますが、別の方法で：バッチジョブの失敗に関する緊急ページが減り、改善作業に費やす時間が増え、データがどこで流れているか、どこでバックアップしているかを正確に示す観測可能性ダッシュボードが増えます。
より速い意思決定。手動の監視が減少。重要なものを構築するための時間が増加。
始める前に
ストリーミングロジックの最初の行を書く前に、いくつかのことを明確にしてください：
最も重要なワークフローでのレイテンシの実際のコストは何ですか？仮定ではなく、実際の数字です。不正パイプラインが6秒ではなく6時間かかる場合、財務的な影響は何ですか？それが優先順位のシグナルです。
ロールバックプランは何ですか？ストリーミングパイプラインが午前2時に壊れた場合、何が起こりますか？バッチへの自動フォールバック？手動介入？PagerDutyのエスカレーション？これを開始前に定義してください。
チームの学習曲線は何ですか？新しい概念を学ぶ必要があります：消費者グループ、パーティションキー、オフセット管理、ウォーターマークポリシー。これらを理解するための時間をチームに確保してください — 実装するだけでなく。
そして、正直な答えが、チームが現在のAirflowパイプラインと並行してストリーミングシステムを運用する余裕がないという場合 — それで大丈夫です。そう言ってください。ビジネスからのストリーミングの緊急性はしばしばビジネスが考えるよりも低く、サポートできない移行にチームを過剰にコミットすることは、ノーと言うよりも悪いです。
実際的な前進の道
これをうまく行うチームは1つの特性を共有しています：彼らは海を沸かそうとしません。
彼らは1つの高価値でレイテンシに敏感なパイプラインを選びます。それを既存のバッチバージョンと並行してストリーミングで構築します。厳密に検証します。自信があるときに切り替えます。そして次のものを行います。
Airflowは残ります。それが得意なことを処理します。ストリーミングは、レイテンシの価値が現実的で測定可能なところに追加されます。結果は、各ワークロードに対して適切なツールを使用するアーキテクチャです — 週末の書き直しにすべてを賭けるビッグバン移行ではありません。
1つのパイプラインから始めます。それを正しく行います。知らないことを学びます。そしてそこからスケールします。
ストリーミングレイヤーのプラットフォームを評価している場合、layline.ioは分散システムの専門知識を必要とせずにストリーミングパイプラインをプロトタイプし、デプロイできるVisual Workflow Designerを提供しています。Community Editionは無料で試すことができます — クレジットカードは不要です。
