Cygnus のアーキテクチャ

Cygnus は Flume エージェントを実行します。したがって、Cygnus エージェント・アーキテクチャは Flume エージェントです。このアーキテクチャが最も基本的な構成から最も複雑な構成まで、どのようになっているかを見てみましょう。

Flume アーキテクチャ

flume.apache.org に記載されているとおり :

イベントとは、Flume エージェントを流れるデータの単位です。イベントは、ソースからチャネルへ、そしてシンクに流れ、イベント・インタフェースの実装によって表されます。イベントはペイロード(バイト配列)を持ち、オプションのヘッダ(文字列属性)のセットを伴います。Flume エージェントは、イベントを外部ソースから外部宛先に流すコンポーネントをホストするプロセス(JVM)です。

ソースは特定のフォーマットのイベントを消費し、それらのイベントは Web サーバのような外部ソースによってソースに配信されます。たとえば、AvroSource を使用して、クライアントまたはフロー内の他の Flume エージェントから Avro イベントを受け取ることができます。ソースがイベントを受信すると、ソースは1つまたは複数のチャネルにそれを格納します。チャネルは、そのイベントがシンクによって消費されるまでイベントを保持するパッシブ・ストアです。 Flume で使用できる Channel の1つのタイプは、ローカルファイルシステムをバッキング・ストアとして使用する FileChannel です。シンクは、チャンネルからイベントを削除し、HDFSEventSink の場合 HDFS のような外部リポジトリに入れるか、フローの次のホップでソースに転送する役割を担います。指定されたエージェント内の Source および Sink は、チャネルでステージングされたイベントと非同期に実行されます。

トップ

基本的な Cygnus エージェント・アーキテクチャ

Cygnus を使用する最も簡単な方法は、Apache Flume のドキュメントに記載されているように、source-channel-sink の基本的な構成/フローを採用することです。永続性要素と同じくらい多くの基本コンストラクト/フローが存在することができます。つまり、HDFS 用、MySQL 用などです。

このフローのそれぞれについて、HttpSource を使用しなければなりません。このネイティブソースが Orion 通知を処理する方法は、特定の REST ハンドラ NGSIRESTHandler を使用して行います。どちらも、この基本的なアプローチでは、各ソースが独自のイベント通知を受け取る必要があります。これは、NGSI エージェントの場合に、HDFS ストレージまたは Carto ストレージで終了する必要のあるフローをアーキテクトが明確に定義している場合は問題にはなりません。しかし、HDFS と Carto に同じイベントを同時に保存する必要がある場合はどうなりますか?この場合、コンストラクトはすべてが同じ Http ソースを持つように変更されます。通知されたイベントは、ソースに接続された各チャネルごとに複製されます。

チャンネルに関して、現在のバージョンの Cygnus では、すべてが MemoryChannel 型が推奨されていますが、 FileChannel を避ける必要はなく、JDBCChannel を使用することもできます。

最後に、シンクは独自のもので、現在のバージョンの Cygnus で扱われる各永続性要素ごとに1つあります :

  • NGSI sinks:
    • NGSIHDFSSink.
    • NGSIMySQLSink.
    • NGSICKANSink.
    • NGSIMongoSink.
    • NGSISTHSink.
    • NGSIPostgreSQLSink.
    • NSGICartoDBSink.
    • NGSIDynamoDBSink.
    • NGSIKafkaSink.
  • Twitter sinks:
    • TwitterHDFSSink.

トップ

高度な Cygnus アーキテクチャ

使用する特定の Cygnus エージェントによって異なります。

Cygnus for NGSI の場合、設定例を確認してください。Flume/Cygnus の設定は Flume/Cygnus エージェントのアーキテクチャーに由来しているため、高度な設定例を確認することで、NGSI アーキテクチャのための Cygnus の複雑さを理解することができます。

Twitter 用の Cygnus の場合、エージェントのアーキテクチャは基本的なものに限られています。

トップ

高可用性 Cygnus アーキテクチャ

Flume/Cygnusはそれ自体ハイアベイラビリティ(HA)機構を実装していません。とにかく、Flume/CygnusにHAを実装するのは、ソフトウェアの2つのインスタンスを実行し、それらとデータソースまたはソースの間にロードバランサを置くのと同じくらい簡単です。もちろん、ロードバランサ自体は単一障害点です。これに対する解決策がありますが、このドキュメントの範囲外です。

NGSI エージェントを HA に導入する際の特定の考慮事項については、NGSI のための Cygnus のリライアビリティ・ドキュメントをチェックしてください。

トップ