メイン コンテンツをスキップする 補完的コンテンツへスキップ

アーキテクチャースタイルとデザインパターン

アーキテクチャースタイルとは

アーキテクチャースタイルとは、システム群の抽象的枠組みを示す粗視化パターンのことです。

データ処理には、バッチ、リアルタイム、イベントドリブン、ストリーミングという4つの主要なアーキテクチャースタイルがあります。

バッチ

バッチ処理とは、指定された時間内に大量かつ反復的なデータジョブを実行する方法のことです。データ処理の場合、このスタイルの処理機能を持つツールは一般的にData Integrationツール、ETLツール( 抽出、変換、ロード)、ELTツール(抽出、ロード、変換、SQL「プッシュダウン」)と呼ばれます。ただし、Talend Data Fabricのような最新ツールはそのような基本的機能をはるかに超えて、データガバナンス機能、そしてバッチだけでなく全アーキテクチャースタイルを実装できる機能が備わっています。

そういったツールが装備されたバッチ処理には次のような特徴があります。
  • レイテンシーに強い
  • 複雑な変換が可能
  • 膨大なボリューム
  • コードが少ない仕様
  • メタデータの再利用

バッチデータ統合の実装によく使われる古典的なデザインパターンの1つに、ビジネス分析とレポーティングのためのデータウェアハウスがあります。

Data Warehouseの図。

リアルタイム

Wikipediaでは、リアルタイムコンピューティングを次のように説明しています。

リアルタイムコンピューティング(RTC)、またはリアクティブコンピューティングは、イベントからシステム応答まで、「リアルタイム制約」に従うハードウェアシステムおよびソフトウェアシステムのコンピューターサイエンス用語である。リアルタイムプログラムは指定された時間内での応答を保証する必要があるが、これはしばしば「デッドライン」と呼ばれる。

リアルタイム処理とは、アクションやイベントに対してほぼ瞬時に反応することです。ミッションクリティカルなアプリケーションは大半がリアルタイムです。

データ処理での「リアルタイム」とは通常、インテグレーションツールを使ったRESTまたはSOAPのWebサービスの実装を指します。したがってこれらのサービスはデータ指向です。Talend Cloud Data Fabricは、次のようなリアルタイムデータ処理アーキテクチャーを実装できる広範な機能を提供しています。
  • APIサービス
  • データサービスの作成 - バッチジョブの作成に使われるコンポーネントと同じパレットを使って、Studio Talendで実装されたSOAPサービスまたはRESTサービス
  • ルート - SOAPサービスやRESTサービスを実装するため、Studio TalendCamelルートをグラフィカルにデザイン
  • マイクロサービス、またはコンテナー内のマイクロサービスとしてTalend Runtimeにデプロイメント
  • ロギングと監視
  • 継続的インテグレーション / デプロイメント

ストリーミング

Wikipediaでは、ストリーミングを次のように説明しています。

ストリーミングデータとは、さまざまなソースから継続的に生成されるデータのことである。そのようなデータは、全データにアクセスすることなく、ストリーム処理技術を使って段階的に処理される必要がある。また、データにはコンセプトドリフトが発生する可能性があるため、ストリームの特性が時間と共に変化することを考慮する必要がある。ストリームは通常、さまざまなソースから高速で生成されるビッグデータのコンテキストで使われる。

ストリーミングの詳細とユースケースは、What is Streaming data?をご覧ください。

ストリーミングには次のような特徴があります。
  • 低レイテンシー
  • シンプルな変換と集計
  • スモールバッチ(「マイクロバッチ」としても知られる)
  • フォールトトレラント
  • データ損失のリスクを最小化
  • スライディングウインドウ機能

    下の図は、データストリームがマイクロバッチの形でSpark Engineによってどのように処理されるかを示したものです。

    データストリームがSpark Engineによってどのように処理されるかを示す図。

イベントドリブン

Wikipediaでは、データドリブンを次のように説明しています。

イベントドリブンアーキテクチャー(EDA)とは、イベントの生成、検出、消費、およびイベントへの対応を促進するソフトウェアアーキテクチャーのパラダイムのことである。

イベントは「状態の大きな変化」と定義できる。たとえば消費者が車を購入すると、その車の状態は「販売中」から「売却済み」に変わる。自動車販売店のシステムアーキテクチャーはこの状態変化をイベントとして扱い、その変化が発生したことをアーキテクチャー内の他のアプリケーションに知らせることができる。形式的な観点でいえば、生成、公開、プロパゲート、検出、消費されるものは「イベント通知」と呼ばれる(通常は非同期の)メッセージであり、メッセージ発信の引き金となった状態変化であるイベントそのものではない。イベントは移動せず、ただ発生するだけある。ただし、「イベント」という用語も通知メッセージそのものを示す目的で同義的に使われることが多く、これが混乱を招くことがある。これは、イベントドリブンアーキテクチャーがメッセージドリブンアーキテクチャー上に設計されることが多いためである。そのような通信パターンでは、各通信をどのように処理すべきかを区別するため、入力の1つがテキストのみの「メッセージ」であることが要求される。

このように、このスタイル(特にデータ処理)は、メッセージドリブンアーキテクチャーの使用と最も一般的に関連しています。ただしTalendで実装可能な他の例として、FTPサーバー上のファイルをポーリングし、FTPサーバーへのアップロード完了時にそのファイルを処理するルートや、非同期プロセスをインスタンス化する(つまりWebサービスはクライアントへの応答前にプロセスが完了するのを待たない)ためのWebサービスの使用などもあります。

イベントドリブンアーキテクチャーの典型的な特徴としては、次のようなものがあります。
  • メッセージベース
  • 確実な配信
  • 再開始/復元
  • トランザクション指向

    下の図は、メッセージがトピックに公開されてサブスクライバーに読み取られるエンタープライズバスを示しています。

    メッセージがどのようにトピックに公開されて読み取られるかを示す図。

デザインパターンとは

デザインパターンとは、与えられたコンテキスト内でよく発生する問題に対する、一般的かつ再利用可能な解決策のことです。

特徴:
  • 一般的なデザイン上の問題に対し、現場でテストされた解決策を提示
  • デザインに携わる大半のIT専門家が再現可能
  • システムのデザインとビルドの方法で一貫性を確保するために使用可能
  • ジョブデザイン、ルートなどのデザインスタンダードの基礎となる
アーキテクチャースタイルによる一般的なデザインパターン
アーキテクチャースタイル デザインパターン
バッチ
  • ETLロード
  • ELTロード
  • CDC (チェンジデータキャプチャー)
  • ファイル転送
定義された頻度によるデータウェアハウスへのロード、日次増分のデータロード、FTP転送、データレプリケーションなど
リアルタイム
  • Webサービス
  • メッセージ交換パターン
  • マイクロサービス
Salesforceのアップデート、読み取りキュー、Enterprise Service Busのメッセージ読み取り、インテグレーション用のAPIサービス
ストリーミング
  • トップN (トレンディング)
  • ストリーム結合
  • 外部ルックアップ
  • スライディング/ローリングウィンドウ
  • 応答シャッフリング
  • アウトオブシーケンス効果
リーダーボード、ツイーターストリーム、ライブストリーム
イベントドリブン
  • 公開/サブスクライブ
  • 非同期プッシュ
  • レシーバーフローコントロール
イベント発生時のセンサーデータ、ワークフローイベント、ファイルトリガー

このページは役に立ちましたか?

このページまたはコンテンツに、タイポ、ステップの省略、技術的エラーなどの問題が見つかった場合は、お知らせください。改善に役立たせていただきます。