BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース SpringXDがアーキテクチャと名称を変更し,Spring Cloud Data Flowに

SpringXDがアーキテクチャと名称を変更し,Spring Cloud Data Flowに

原文(投稿日:2015/09/25)へのリンク

Pivotalは先週のSpringOne2GXカンファレンスで,同社のビッグデータ製品であるSpring XDを完全に再設計し,名称をSpring Cloud Data Flowに改めることを発表した。新しい製品では,実行可能なアプリケーションをモジュールの基盤として使用し,そのオーケストレーションを重視する。最上位レベルのREST APIやシェル,UIはSpring XDのものを使用して後方互換性を確保しているが,それ以下の部分では大きく異なっている。

Spring XDで使用されていたZookeeperベースのランタイムは廃止され,Pivotal Cloud FoundryLatticeYarnといった他システムを利用して,マイクロサービスのローンチやスケールアップ,モニタを行うサービスプロバイダインターフェース(SPI)に置き換えられた。従って,例えばLattice用のSPIでは,receptor APIを使用してモジュールのローンチを行う。Cloud Foundry上ではクラウド管理APIが使用される。旧XDのシングルノードのように,プロセス内で動作するローカル実装も用意されている。

Spring XD 1.x to Spring Cloud Data Flow

“基本的な方針として,上位APIは維持されています”と,Pollack氏はカンファレンスで語った。“ただしその下では,これまでに確認された基本的な制限を克服するために,大幅なアーキテクチャの変更を行っています。”

ここで言及された制限には,スケーリング能力やカナリアデプロイメント,モジュール毎に別々のメモリアロケーションを提供するなどのリソース管理,分散トレースなど,現行のアーキテクチャがサポートしていないものが含まれる。その他,独立したマイクロサービスアプリケーションアーキテクチャがフラットなクラスローダを必要とするのに対して,旧式の親子型クラスローダ階層が使用されているという制限もある。

そのクラスローダの問題を解決するため,既存のインテグレーションとバッチモジュールが,独立型のフラットなクラスローダを備えたSpring Bootアプリにリファクタされた。再設計の結果,ストリームアプリケーションとバッチアプリケーションはともに,それぞれ独立した発展の可能なデータマイクロサービスとして実行可能になった。いずれのモジュールも,Spring Cloud Data Flowの関与がまったくなくても動作する – Javaの -jar がその代用をする – が,データフロー層があれば,プロパティの設定など手間のかかる作業の大部分が不要になる。さまざまな改善の中でもっとも分かりやすいのは,ZookeeperベースのXDコンテナで実行されていた頃と違い,独立したモジュール用のユニットテストが記述可能になったことだ。これによってコミュニティからのコントリビュータの数も増えて,マーケットの立ち上がりに弾みが付くことだろう。

Bootモジュールの下には,Spring Cloud StreamとSpring Cloud Taskという2つのプロジェクトがある。それぞれSpring IntegrationとSpring Batchに,自動構成機能を提供する目的で開発されたものだ。

Modules to Microservices

プログラミングモデルの概要を理解するために,Mark Fisher氏とDave Syer氏が2回目のプレゼンテーションで紹介したインバウンドチャネルアダプタ(Spring Integrationの標準的なアノテーションを使用している)のコードを示す。このアダプタは,既定値ではSpring Integrationによって毎秒コールされる。

@EnableBinding(Source.class)
public class Greeter {
	@InboundChannelAdapter(Source.OUTPUT)
	public String greet() {
		return "hello world";
	}
}

@EnableBindings(Source.class)アノテーションがクラスパス上にあるバインダ実装を検索し,そのバインダをチャネルアダプタ生成時に利用する。このアノテーションは,インターフェースによってパラメータ化されている。SourceとSink, Processorは提供されているが,独自に定義することも可能だ。次の例は,Sourceそれ自体がメッセージチャネルインターフェースである場合だ。

public interface Source {
  @Output("output")
  MessageChannel output();
}

@Outputアノテーションは出力チャネル(モジュールを出るメッセージ)の確認に,@Inputアノテーションは入力チャネル(モジュールに入るメッセージ)の確認に使用する。チャネル名をパラメータ指定することも可能で,省略時はメソッド名で代用される。

対応するSinkは別プロセスなので,例えば10プロセスを同時に実行するようなことも可能だ。このプロセスは他のミドルウェア統合チャネルを監視して,メッセージが到着するとアクティベートする。

@EnableBinding(Sink.class)
public class Logger {
	@ServiceActivator(inputChannel=Sink.INPUT)
	public void log(String message) {
		System.out.println(message);
	}	
}

これらの部品をつなぎ合わせる役割を持つのがSpring Cloud Data Flowだ。現在はマイルストンリリースが公開されている。

この記事に星をつける

おすすめ度
スタイル

BT