はじめてのFlink：Flinkを利用してストリーミング処理を追加

ストリーミング変換とは、イベントが到着すると同時に処理し、リアルタイムでロジックを適用して、変換後の結果を即座に出力する継続的な処理です。バッチジョブの完了を待つ必要はありません。

Apache Flinkでは、ストリーミング変換処理は継続的に実行され、ストリームから受信する各イベントに応答して処理を行います。これにより、ライブデータに対してリアルタイムで直接データ変換を実行できます。

Kafkaとの連携方法

実際の運用では、ストリーミング変換処理は通常、以下の処理を行います。

• Apache Kafkaのトピックからイベントを読み取る

• シンプルな変換処理（フィルタリング、データ保管、集計、またはデータ形式変更）を適用する

• 結果を別のKafkaトピックまたは下流のシステムに書き込む

Kafkaはデータを移動し、Flinkはデータを変換処理します。

ストリーミング処理とバッチ処理の比較（概要）

データを後から処理するのではなく移動中に処理をする。これが、Flinkを導入する際に最も重要となる考え方の違いです。

ストリーミング処理は、イベントにリアルタイムに継続的に処理を加えることで、Kafkaストリームを単なるデータ転送手段ではなく、アクティブなデータパイプラインへと変えます 。

ストリーミング変換を追加する理由

多くのチームにとって、最初に浮かぶ疑問は「Flinkをどのように使うか」ではなく、「なぜ導入する必要があるのか」でしょう。特にすでに KafkaコンシューマーやバッチETL を行っている場合はなおさらです。

その答えは、スケールや複雑さではありません。重要なのはタイミングです。

ストリーミング処理を利用すれば、数分後や数時間後ではなく、データが発生したその瞬間に処理を実行できます。

バッチ処理やカスタムコンシューマーが抱える課題

開発者は一般的に、次のいずれかのアプローチから始めます。

• スケジュールに従って Kafkaデータを処理するバッチETL ジョブ

• アプリケーションコードに変換ロジックを組み込んだカスタムKafkaコンシューマー

どちらの方法も、最初は十分に機能します。しかし、システムの拡大に伴い、さまざまな制約が生じます。

同じ変換処理済みデータを必要とするチームが増えるにつれて、変換ロジックが複数のサービスに分散し、運用リスクが高まります。

ストリーミング変換処理によって何が変わるのか

ストリーミング変換では、イベントの処理方法を一元化し、標準化できます。

Apache Flinkの変換処理は次のような特長を備えています。

• 継続性 – 常に実行され、常に最新の状態を維持

• 拡張性 – 分散環境でのイベントストリーム処理を前提に設計

• 耐障害性 – 状態（ステート）と処理の進行状況を自動的に保持

これにより、新しいユースケースごとにコンシューマーロジックを書き直すことなく、リアルタイムでデータ拡充、フィルタリング、集計を実現できます。

導入前と導入後の比較：アーキテクチャへの影響

Kafkaは引き続きイベント転送の基盤として機能し、Flinkはリアルタイムの変換レイヤーとしてその役割を担います。

ストリーミング変換の追加に適したケース

システム全体を最初から再設計する必要はありません。ストリーミング変換は、次のような場合に効果を発揮します。

• バッチETLからリアルタイム分析へ移行する場合

• 複数のコンシューマーが拡充またはフィルタリングされた同じデータを必要としている場合

• Kafkaだけで変換処理を実装することが複雑になり、保守が難しくなっている場合

• チーム全体で一貫性のあるデータプロダクトを提供する場合

このような段階的なアプローチは、Kafkaを中心としたアーキテクチャや、ksqlDBによる変換処理を利用しているチームにとって特に有効です。

考え方の転換：受動的なストリームから能動的なストリームへ

ストリーミング変換を利用しない場合、Kafkaストリームは主に受動的になります。データを配信する役割は果たしますが、そのデータに意味を与える処理は後で行われます。

Flinkを利用すると、以下が可能になります。

• ストリームが能動的なものになる

• データの移動中に加工および拡充される

• 下流システムは、そのまま利用できる状態のイベントを受け取れる

これが、スケーラブルなリアルタイムデータ変換パイプラインの基盤となります。

ストリーミング変換を追加する目的は、Kafkaやバッチ処理を置き換えることではありません。レイテンシの削減、アーキテクチャの簡素化、変換ロジックの一元化を実現しながら、リアルタイム処理へ段階的に移行することにあります。

操作の手順：最初のFlinkストリーミング処理を追加する

このセクションでは、実践的かつ既存環境から移行しやすい方法で、最初のFlinkストリーミング変換処理を追加する手順を紹介します。目的は複雑なパイプラインを構築することではありません。既存のKafka環境に最小限の変更を加えるだけで、リアルタイムのストリーム変換を導入することです。

ステップ1：ソースKafkaストリームの特定

まずは、すでにイベントが含まれているKafkaトピックを選択します。最初の変換対象としては、次のようなストリームが適しています。

• 重要度が高く、リスクが低い

• データ構造が明確で安定している

• すでに下流システムで利用されている

Kafkaは引き続きイベントの保存と配信を担当し、Flinkは変換処理のみを担います。

ステップ2：入力スキーマの定義

Flinkで変換処理を行うには、まず受信するイベントの構造を理解する必要があります。

Kafkaベースのアーキテクチャでは、多くの場合、スキーマはSchema Registryで管理され、互換性の維持や安全なスキーマ変更を実現しています。

この段階ではスキーマ自体を変更するのではなく、Flinkがそのスキーマをどのように読み取るかを定義するだけです。

ステップ3：シンプルなストリーミング変換の適用

最初の変換処理は、フィルタリングやフィールドの選択など、状態を保持しない（ステートレスな）シンプルなものにすると、動作を確認しやすくなります。

以下は、Kafkaストリームのイベントをフィルタリングする最小限のFlink SQLの例です。

-- Source Table: Reads raw events from Kafka

CREATE TABLE source_events (
  user_id    STRING,
  event_type STRING,
  event_time TIMESTAMP(3),
  WATERMARK FOR event_time AS event_time - INTERVAL '5' SECOND
) WITH (
  'connector'                  = 'kafka',
  'topic'                      = 'raw-events',
  'properties.bootstrap.servers' = 'broker:9092',
  'scan.startup.mode'          = 'earliest-offset',
  'format'                     = 'json'
);

-- Sink Table: Writes filtered events to Kafka

CREATE TABLE filtered_events (
  user_id    STRING,
  event_time TIMESTAMP(3)
) WITH (
  'connector'                  = 'kafka',
  'topic'                      = 'filtered-events',
  'properties.bootstrap.servers' = 'broker:9092',
  'format'                     = 'json'
);

-- Streaming Transformation: Filter only 'login' events

INSERT INTO filtered_events
SELECT user_id, event_time
FROM source_events
WHERE event_type = 'login';

このFlinkによる変換処理は継続的に実行され、イベントが到着するたびに処理を行い、その結果を新しいKafkaピックに書き込みます。

ステップ4：出力ストリームの確認

ジョブの実行を開始したら、次の点を確認します。

• 出力トピックにレコードが書き込まれていることを確認する

• フィールドの値やイベントのタイミングが正しいことを検証する

• ライブトラフィックで、変換処理が期待どおりに動作していることを確認する

この段階ではオブザーバビリティが重要になります。遅延、スループット、エラーを早い段階から監視することで、後になって問題が表面化するのを防ぐことができます。

ステップ5：変換処理をシンプルに保つ

初のFlinkジョブでは、次の点を意識しましょう。

• 1つのジョブにつき1つの変換処理を基本とする

• 最初は、JOINやウィンドウ処理など、状態を保持する処理（ステートフルな処理）は避けましょう

• 機能の網羅性よりも、分かりやすさを優先する

初のFlink変換処理用のチェックリスト：

1. ソースKafkaトピックを特定したか

2. 入力スキーマを定義したか

3. シンプルな変換処理を適用したか

4. 出力トピックを作成したか

5. 結果を検証したか

最初のFlinkストリーミング変換は、小規模で、ステートレスであり、動作を理解しやすいものにすることが重要です。このように段階的に進めることで、システム全体を再設計することなくFlinkのストリーム処理を導入でき、将来的にはより高度なリアルタイム変換へと発展させるための基盤を構築できます。

一般的な最初のストリーミング変換処理

Flinkを使い始める際は、シンプルで予測しやすく、結果を容易に検証できる変換処理から始めるのが効果的です。こうしたパターンを採用することで、不必要な複雑さを持ち込むことなく、Kafkaの受動的なストリームから、リアルタイムでデータを変換する能動的なストリームへと移行できます。

以下では、本番システムでよく利用されている最初のFlinkの変換処理を紹介します。これは特に、バッチETL、Kafkaのみのコンシューマー、またはksqlDBから移行するチームで広く採用されているものです。

1. イベントのフィルタリング

シナリオ：必要なイベントだけを残し、不要なイベントを除外することでノイズを減らします。

• 入力：さまざまな種類のイベントを含む生のイベントストリーム

• 変換：条件に基づいてイベントをフィルタリング

• 出力：必要なイベントだけを含む、整理されたイベントストリーム

代表的なユースケース

• ログインイベントやセキュリティイベント

• エラーや異常の検知

• 特定機能に関する分析

これは、多くのチームが最初に実装するFlinkストリーム処理の例です。

2. フィールドの選択と再構成

シナリオ：使用しないフィールドを削除したり、列名を変更したりして、イベントを扱いやすい形に整理します。

• 入力：項目数が多く冗長なイベントスキーマ

• 変換：必要なフィールドを選択し、必要に応じて名称を変更

• 出力：コンパクトでコンシューマーが利用しやすいイベントストリーム

代表的なユースケース

• 分析ツール向けのデータ準備

• 下流チーム向けに安定したスキーマの作成

• 高スループット環境でペイロードサイズを削減

このパターンは、再利用可能なデータ変換パイプラインの構築に役立ちます。

3. リアルタイム拡充

シナリオ：システム内を流れるイベントにコンテキスト情報を付加します。

• 入力：識別子（ユーザー ID や製品 ID など）を含むイベント

• 変換：参照データやメタデータを使用してイベントを拡充

• 出力：分析に利用できるコンテキスト情報付きのイベント

代表的なユースケース

• 地理情報や顧客メタデータの付加

• 機械学習パイプライン向けの特徴量の準備

• オブザーバビリティの向上やデバッグの効率化

これは、基本的なフィルタリングの次に取り組むことが多い変換処理です。

4. イベントの集計（入門編）

シナリオ：リアルタイムで更新される集計指標を生成します。

• 入力：大量のイベントストリーム

• 変換：一定期間のイベントのカウント、合計、またはグループ化

• 出力：集計済みメトリクスのストリーム

代表的なユースケース

• リアルタイムダッシュボード

• トラフィック監視

• 運用メトリクスの収集

最初の変換処理では、集計はシンプルで範囲を限定したものにとどめておきましょう。

シナリオのまとめ

これらのシナリオでは、Apache Kafkaが引き続きイベントの転送と永続化を担い、Apache Flinkがリアルタイムのストリーム変換を実行します。

この役割分担により、シンプルでスケーラブルなアーキテクチャを維持できます。

ステートフル変換とステートレス変換

Flinkのストリーム処理を理解するうえで、早い段階で押さえておきたい最も重要な概念の一つが、ステートレス変換とステートフル変換の違いです。この違いは、スケーラビリティや耐障害性だけでなく、ストリーミングアプリケーションが時間の経過とともにどのように動作するかにも影響します。

最初のFlink変換では、適切な種類の変換を選ぶことで、複雑さを抑えながら安心して導入を進めることができます。

ステートレス変換

ステートレス変換では、過去のイベントを記憶することなく、各イベントを独立して処理します。

• 過去の情報（コンテキスト）は不要

• 出力は現在処理しているイベントだけで決まる

• 動作を理解しやすく、テストもしやすい

代表的な例

• イベントのフィルタリング

• フィールドの選択や名前の変更

• シンプルなデータ形式の変換

これらの変換は、Kafkaのみのコンシューマーやバッチパイプラインから移行する際の最初のステップとして最適です。

ステートフル変換

ステートフル変換では、イベント間で情報（ステート）を保持し、そのステートを利用して処理結果を生成します。

Apache Flinkでは、ステートは自動的に管理および永続化されるため、大規模なステートフルストリーム処理を高い信頼性で実現できます。

代表的な例

• 一定期間における集計（件数、合計値など）

• ストリーム同士のJOIN

• 重複排除やセッション追跡

ステートを利用することで、より高度なイベントストリーム処理が可能になりますが、その一方で設計上の考慮事項も増えます。

並べての比較

それぞれを使い分けるタイミング

• 最初の Flinkジョブでは、ステートレス変換から始めましょう

• 時間ベースのロジックや、イベント間のコンテキストが必要になったら、ステートフル変換を導入しましょう

• ステートの範囲は小さく、定義を明確に保つようにしましょう

Kafkaは引き続きイベントを永続的に保存し、Flinkはステートを安全かつ透過的に管理します。

考慮すべき設計上のトレードオフ

最初のストリーミング変換は、意図的にシンプルな構成にします。しかし、シンプルな設計であっても、考慮すべきトレードオフは存在します。こうした点を早い段階で理解しておくことで、Flinkによるストリーム処理が拡大した際によくある落とし穴を避けやすくなります。

重要なのは、早すぎる最適化を行うことではありません。後から見直しや変更が可能な、意図を持った設計判断を行うことです。

1. レイテンシと複雑さ

トレードオフ：レイテンシを低く抑えようとすると、より高度な処理ロジックが必要になることが多くあります。

最初の変換処理では、細かな最適化よりも、分かりやすくシンプルな設計を優先しましょう。

2. ステートレス処理とステートフル処理

トレードオフ：ステートを利用すると、より高度な変換処理が可能になる一方で、運用は複雑になります。

可能であれば、まずはステートレス変換から始め、本当に必要になった段階でステートフル変換へ移行しましょう。

3. 1つのジョブにまとめるか、複数のジョブに分けるか

トレードオフ：複数の変換処理を 1 つのジョブにまとめると運用負荷は軽減できますが、その反面、柔軟性が低下する可能性があります。

このアプローチは、段階的に導入を進める戦略ともよく適合します。

4. スキーマの安定性と柔軟性

トレードオフ：スキーマを頻繁に変更すると、下流のコンシューマーに影響を与える可能性があります。

明確に定義されたスキーマは、信頼性の高いデータ変換パイプラインを支える基盤となります。

5. オブザーバビリティと運用負荷

トレードオフ：可視性を高めるほど、運用コストが増加する傾向があります。

オブザーバビリティを早い段階で整備しておくことで、トラフィックの増加に伴う運用やトラブルシューティングへの対応が容易になります。

最初の変換処理で避けるべきこと

最初のストリーミング変換は、チームが Apache Flinkをどのように活用していくかを方向付ける重要な一歩です。導入の初期段階で問題が起きる原因は、Flinkに必要な機能が不足しているからではありません。多くの場合は、最初から多くのことを、あまりにも早く実現しようとしてしまうことにあります。

最初の導入をトラブル対応に追われる悪夢にしないためにも、次の 5 つのよくある落とし穴は避けましょう。

1. ストリーミングをバッチ処理のように扱う（ETLの落とし穴）

• よくある間違い：すべてのデータがテーブルに蓄積されてから処理されることを前提に、長く複雑な変換処理を設計してしまうことです

• なぜ問題なのか：このような設計では、レイテンシが大幅に増加し、リアルタイム処理のメリットが失われ、障害発生時の復旧が格段に難しくなります

• 対処方法：変換処理は、小さく、独立性を保ち、継続的に実行できるよう設計しましょう。自然なストリーム処理を心がけましょう

2. ビジネスロジックをKafkaコンシューマーに詰め込みすぎる

• よくある間違い：Flink がデータを処理する前に、複雑な変換処理を実行するカスタムコンシューマーアプリケーションを作成してしまうことです

• なぜ問題なのか：ビジネスロジックがデータ転送レイヤーと密結合になり、スケーラビリティや耐障害性の確保が難しくなるだけでなく、時間の経過とともにコードの重複も増えていきます

• 対処方法：Apache Kafka には本来の役割であるデータの転送を任せ、Apache Flinkには変換処理を一元化および標準化する役割を担わせます

3. 最初から複雑なステートフル処理に取り組む

• よくある間違い：最初の本番ジョブに、JOIN、複雑な時間ウィンドウ設定、大規模なステートストアなどを一度に詰め込んでしまうことです

• なぜ問題なのか：運用が大幅に複雑になり、チームの学習負荷も高まります。その結果、初期段階で発生した不具合の原因を特定することが非常に難しくなります

• 対処方法：小さく始めて、段階的に発展させましょう。まずはシンプルなステートレス変換から始め、ステートは、アーキテクチャ上の明確な要件が生じたときにだけ導入しましょう

4. スキーマガバナンスを軽視する

• よくある間違い：イベントスキーマを、エンジニアリング組織の他のチームと調整や検証を行わないまま変更してしまうことです

• なぜ問題なのか：下流のコンシューマーが動作しなくなり、実行時エラーが発生するだけでなく、データプロダクトに対する信頼も損なわれます

• 対処方法：最初からスキーマ互換性ルールを適用し、データ構造は段階的に進化させていきましょう

5. オブザーバビリティを確保しないまま運用を始める

• よくある間違い：監視、アラート、出力データの検証を行わないまま、新しい変換処理を本番環境へ展開してしまうことです

• なぜ問題なのか：障害に気付けないまま破損したデータが下流システムへ伝播し、その結果、エンジニアリングチームは問題対応に追われ続けることになります

• 対処方法：早い段階で出力ストリームを検証し、トラフィックを増やす前に、基本的なシステムメトリクスの監視体制を整えましょう

まとめ: ストリーム処理は短距離走ではなく、マラソンです。まずは、データフロー、シンプルなデータ転送、そして厳格なガバナンスという基本をしっかり固めましょう。そうすれば、複雑なステートフルロジックも、後から無理なく導入できるようになります。

意思決定フロー

Migration Lite（段階的な移行）戦略との関係

Migration Lite戦略とは、データプラットフォーム全体を作り直すことなく、リアルタイム処理の機能を段階的に導入していくアプローチです。Flinkによる最初のストリーミング変換は、小規模かつ管理しやすい変更として設計されており、短期間で安全に価値を生み出せることを目的としています。

このアプローチは、バッチ ETL、Kafka中心のアーキテクチャ、あるいは軽量なSQLベースの変換処理から移行するチームに特に適しています。

Migration Liteの基本的な考え方

Migration Liteは、次の 3 つの原則に基づいています。

• 既存システムを置き換えることなく、新しい機能を追加する

• 初期段階の実験的な取り組みで影響範囲を最小限に抑える

• 複雑さを増やす前に、まず価値を実証する

実際には、Apache Kafkaをイベント基盤としてそのまま活用しながら、リアルタイム変換が必要な部分にだけ Apache Flinkを導入します。

Kafkaは引き続きイベントを確実に移動します。Flinkは、移動しているデータをリアルタイムに変換するために追加されます。

Migration Liteの実践例

最初のFlink変換：

• Apache Kafkaのトピックからを読み取る

• 小規模で目的を絞った変換を実行する

• 新しいKafkaピックへ書き込む

• プロデューサーやコンシューマーは変更しない

そのため、この変更には次のようなメリットがあります。

• 展開しやすい

• ロールバックしやすい

• 動作を理解しやすい

アプリケーションの書き換えは不要です。プラットフォーム全体を作り直す必要もありません。

Migration Liteがリスクを軽減する理由

Migration Liteでは、次のような移行時によくある失敗を避けることができます。

• プラットフォーム全体を一度に作り直してしまう

• ステートフル処理による複雑さを早い段階で持ち込んでしまう

• 変換ロジックとアプリケーションを密結合にしてしまう

代わりに、次のようなメリットが得られます。

• プロデューサー、変換処理、コンシューマーをそれぞれ独立して改良できる

• 変換ロジックの責任範囲を明確にできる

• ステートフルなストリーム処理を段階的に導入できる

こうして一つひとつのステップで成果を確認しながら、次の段階へ安心して進められます。

アーキテクチャにおけるFlinkの位置付け

Migration Lite戦略における位置付け：

• Kafkaは引き続きイベントの記録のためのシステムとして機能します

• Flinkはリアルタイム変換レイヤーとして機能します

• 下流システムは、あらかじめ用途に合わせて整形されたストリームを利用します

この役割分担により、スピーディーに初期導入を行い、長期的なデータプラットフォーム戦略を支えることができます。

FAQs

Flinkにおけるストリーミング変換処理とは何ですか？

Apache Flinkのストリーミング変換処理とは、イベントをバッチとしてまとめて後から処理するのではなく、データのストリーム上に流れるイベントを継続的に変換する処理です。これにより、イベントデータのフィルタリング、拡充、集約をリアルタイムに実行できます。

Kafkaのデータを変換するためにFlinkは必須ですか？

いいえ。Kafkaのデータはカスタムコンシューマーを使用して変換することもできます。ただし、変換ロジックが複雑になるにつれて、Apache Kafkaコンシューマーは拡張や保守が難しくなります。Flinkは、リアルタイムのストリーム変換に特化した耐障害性が高い処理エンジンであり、スケーラビリティやステート管理の機能も備えています。

初めてのストリーミング処理の実装にはどのくらい時間がかかりますか？

フィルタリングやイベントの整形といったシンプルなユースケースであれば、特にFlink SQLを利用する場合、数分で最初のFlink変換処理を実装し、実行を開始できることもあります。

FlinkはKafkaの代わりになりますか？

いいえ。KafkaとFlinkは、それぞれ異なる役割を担います。Kafkaはイベントの永続化と転送を担当し、Flinkはそのイベントに対してリアルタイムのデータ変換とストリーム処理を実行します。

Flinkは本番ワークロードでも利用できますか？

はい。Flinkは、大規模な分散型ステートフルストリーム処理を実現するよう設計されており、低レイテンシ、耐障害性、Exactly-Once処理保証が求められる本番環境で広く利用されています。

システムを再設計しなくてもFlinkを導入できますか？

はい。Migration Liteアプローチを採用すれば、既存のプロデューサーやコンシューマーを変更することなく、まずはシンプルで小規模な変換処理から始めて、Flinkを段階的に導入できます。