architecture-paradigm-pipeline

パイプライン（パイプとフィルター）パラダイム

このパラダイムを採用する場合

• ETL ジョブ、ストリーミング分析、CI/CD パイプラインなど、データを固定された順序の個別の変換処理に通す必要がある場合。
• 個々の処理ステージを単独で再利用したり、ボトルネックとなっているステージを他のステージとは別にスケールしたりする必要がある場合。
• ステージ間の障害分離が重要な要件である場合。

採用すべきでない場合

• 対話型のリクエスト／レスポンスシステム（ archetypes:architecture-paradigm-client-server を使用してください）
• このパターンでは表現できない、変更可能な状態を共有する必要があるステージ

導入手順

1. フィルターを定義する：各ステージ（フィルター）が、明確に定義された単一の変換を実行するように設計します。各フィルターには、明確な入力と出力のデータスキーマが必要です。
2. パイプで接続する：「パイプ」を使用してフィルターを接続します。パイプはストリーム、メッセージキュー、またはインメモリチャネルとして実装できます。これらのパイプがバックプレッシャーとバッファリングに対応していることを検証します。
3. フィルターをステートレスに保つ：可能な限り、フィルターはステートレスに設計します。必要な状態は外部に永続化するか、パイプラインの境界で管理します。
4. 各ステージを計測する：各フィルターに監視機能を実装し、レイテンシー、スループット、エラー率などの主要な指標を追跡します。
5. デプロイをオーケストレーションする：各ステージを水平スケールし、独立してアップグレードできるデプロイ戦略を設計します。

主な成果物

• フィルター、選択したパイプ技術、エラー処理戦略、データ再生用ツールを記録したアーキテクチャ決定記録（ADR）。
• 各フィルターのコントラクトテスト一式と、代表的なエンドツーエンドのパイプライン実行を網羅する統合テスト。
• ステージレベルの主要業績評価指標（KPI）を可視化するオブザーバビリティダッシュボード。

リスクと軽減策

• 単一ステージのボトルネック：
  • 軽減策：個々のフィルターに自動スケーリングを実装します。単一のフィルターが引き続きボトルネックとなる場合は、より細分化されたサブパイプラインへのリファクタリングを検討します。
• ステージ間のスキーマドリフト：
  • 軽減策：共有リポジトリでスキーマ定義を一元管理し、破壊的変更を防ぐため、CI/CD プロセスの一環として互換性テストを徹底します。
• バックプレッシャーの障害：
  • 軽減策：大容量のシナリオをシミュレートする厳密な負荷テストを実施します。高負荷時に、バッファリング、リトライロジック、バックプレッシャー機構が想定どおりに動作することを検証します。

具体的なコンポーネント

このパラダイムの実装でよく使用されるツールや抽象化の用語です。依存関係ではなく、tools: フロントマターでもありません。

• stream-processor：フィルターを実行するランタイム（例：Flink、Apache Beam、Faust）
• message-queue：フィルター間の永続的なパイプ（例：Kafka、RabbitMQ、インメモリチャネル）
• data-validator：フィルターの入力時と出力時に、すべてのレコードのスキーマを検証します

完了基準

• ADR に、パイプライン内のすべてのフィルター、選択したパイプ技術、エラー処理戦略（DLQ、リトライ回数、デッドレターへのルーティング）、データ再生の仕組みが記録されていること。
• 各フィルターに入力と出力のスキーマを網羅するコントラクトテストがあり、隣接するフィルター間のスキーマドリフトが CI の互換性チェックで検出されること。
• パイプラインを本番環境に昇格する前に、ステージごとのレイテンシー、スループット、エラー率を表示するオブザーバビリティダッシュボードが設定されていること。
• 負荷テストにより、想定されるピークスループットの 2 倍の負荷でも、バックプレッシャーとバッファリングの仕組みがデータ損失を防ぐことが検証されていること。