パイプラインアーキテクチャとは

パイプラインアーキテクチャとは

ソフトウェアの歴史の中で繰り返し出現するスタイルが、このパイプラインアーキテクチャスタイルだ。

関数型プログラミング言語の考え方を拡張したかのようなアーキテクチャで、 bashpowershellなどのシェル言語に近い構造を持つ。

今回のアーキテクチャはより高次元に拡張し、ビジネスアプリケーションレベルにも使用できる。

概要

パイプラインアーキテクチャには以下の構成要素が出てくる

  • フィルター

  • パイプ

パイプ

パイプはフィルター間の通信チャネルである。

このパイプは1方向かつP2Pの仕組みであり、あるソースからの入力を別のソースに渡す。

パイプを通るペイロードデータはどんな形式であって構わないものの、パフォーマンス上の観点から少量の方が望ましい。

フィルター

フィルターは情報を持たない関数のようなもの、言わばステートレスな要素である。

フィルターは前のフィルターからパイプを通して送られてくるデータを変形し、新たなパイプを通して次のフィルターへ明け渡す。

これを繰り返すことでデータの変更を行うシステムが、「パイプラインアーキテクチャ」である。

一つのパイプは一つの処理のみを行い、この原則を守ることによって構成の再利用を促す。

フィルターには次の4種類がある

  • プロデューサー:処理の出発点

  • トランスフォーマー:受け取ったデータをあらかじめ設定した関数に全て通して、全てあるいは一部のデータを変形する。関数型プログラミング言語ではmapとも呼ぶ

  • テスター:受け取ったデータから、一つの統計データを出力する。関数型プログラミング言語ではreduceとも呼ぶ。

  • コンシューマー:処理の終了地点。ここまで変形したデータをUIに表示したり、永続化したりする。

パイプラインアーキテクチャの威力

パイプとフィルターのそれぞれの一方向性とシンプルさは、構成の再利用を促す。

特に、powershellbashシェル、関数型プログラミングに触れたことがある人ならばその威力を把握しているだろう。

具体例1:関数型

課題:例えば、配列comment_listの全ての値を文字列にして「。」で繋げたいと思った時に、あなたならどうするでしょう?

for文を使うと4行かかりましたね(console.logは除く)

var comment_str = ""
for(var i in comment_list){
    comment_str += comment_list[i]
}
console.log(comment_str)

こいつを関数型で再現するとどうなるでしょう?

console.log( comment_list.join("。") )

はい、一行で終わりました。

https://qiita.com/kawadasatoshi/items/948d4b5facd53139c6c7

具体例2:Apache kafka

Apache Kafkaはスケーラビリティに優れた分散メッセージキューです。

複雑なシステムをサービス単位で分割して疎結合に保つことで、迅速な機能追加や不良修正が可能なマイクロサービスが多くの企業で導入されています。 Kafkaはこのようなサービス間で、大量のデータを受け渡すためのハブとして活用されています。

そのkafkaの内部ですが、Kafkaにストリームされるさまざまな種類のデータを処理するのにパイプラインアーキテクチャを使用しています。

パイプラインアーキテクチャのメリット

パイプとフィルターのそれぞれの一方向性とシンプルさは構成の再利用性を極限まで高める。

例えば、EDIツール(電子データ交換ツール)。

EDIとは「Electronic Data Interchange」の略称で、日本語では「電子データ交換」を意味します。企業間における契約書や、受発注をはじめとした商取引に関する文書を専用回線や通信回線を用いてやり取りする仕組みのことです。

例えば、あるWeb-EDIでは、CSVでブラウザ越しに渡した商用データを、パイプライン内部での変換を繰り返してコンシューマ(データベースの永続化)を実施している。

データベース同士を連携できるTalendも同様に動いているのだろう。グラフィック画面に映るデータの変形パネルは正しくパイプラインそのものだ。

もしかしたらログ管理ツールなどにも使われているのかもしれない。

このように一方向でステートレスなシステムでは構成の再利用性を高めたとても強力なパターンである。

モジュール性、シンプルさ、全体的なコストはパイプラインアーキテクチャの主な強みだ。

デメリット

このアーキテクチャモノリスである。(分散されたシステムではない)

したがって、デプロイの儀式、リスク、デプロイの頻度、テストの完全性などはこのアーキテクチャでは担保できない。

加えてスケーラビリティと弾力性は低い。(仮にこれらの要素を上げようとしても、マルチスレッドや内部メッセージングなど このアーキテクチャには適さないタイプの設計技術が必要になる。)

加えてコンポーネントの一部がメモリ不足などでダウンすると全体がクラッシュしてしまうのもこのシステムのデメリットである。

備考

title:パイプラインのメリット・デメリット【アーキテクチャ用語集】

description:関数型プログラミング言語の考え方を拡張子かのようなアーキテクチャbashpowershellなどのosの言語に近い構造を持つ。プログラミング言語は低いレイヤーの話であるが、今回のアーキテクチャはより高次元である。

category_script:page_name.startswith("2")

img:https://github.com/kawadasatoshi/techblog/blob/main/0/inhouse_se/2002pipline_arch/pipline.png?raw=true