Cygnus¶

ここでは、Cygnus、特に cygnus-ngsi のさまざまな用途を対象としたレシピを見つけることができます。すでに Cygnus に精通していると仮定しますが、そうでない場合は、公式ドキュメントを参照してください。

これらのレシピをテストするための環境の準備方法については、ドキュメントのインストールセクションに記載されています。

HA に関するいくつかの考察¶

最初に留意すべき点は、cygnus を使用して高可用性について話す場合、cygnus エージェントが処理したデータが最終的なストレージ・ソリューションにドロップされる前に、そのデータの可用性を言及することです。したがって、公式ドキュメントに記載のとおり、さまざまなシンクによって、さまざまなストレージ・ソリューション (mongodb, mysql, hdfs など) で永続性を持たせることができます。永続化されたデータを HA モードに維持することは、異なる課題であり、実装は使用されるソリューションに依存します。MongoDB の場合、MongoDB Replicaset Recipe を見ることができます。だから、このレシピはいくつかのバックエンドに接続する方法を示しますが、それらを管理する方法はあなた次第です。

さらに、エージェントを単一の構成可能なエンティティとして展開する方法についても説明します。しかし、エージェント内には、Advanced Cygnus Architectures で説明されているように、複数の利用可能な構成 (単一または複数のソース、チャネル、およびシンクを使用) が存在することに注意してください。これらの内部拡張アーキテクチャのセットアップ方法とそれぞれの利点については、公式ドキュメントですでに説明しているため、ここでは説明しません。

Cygnus をデプロイするためには、ステートレスまたはステートフルなサービスかどうかを理解する必要があります。エージェントのソース部分とシンク部分はデータを保持しませんが、データが処理されてシンクによってチャネルから取り出されるまで、チャネルは少なくとも短期間は実行されます。Cygnus と Flume のドキュメントから読むことができるように、チャンネルは MemoryChannel と FileChannel の形式で提供されます。

MemoryChannel とバッチ処理では、イベントがチャネルから取り出される前にエージェントがクラッシュした場合など、データ損失の可能性があります。事実、各イベントのストレージへのアクセスを避けるため、Cygnus にはバッチ・サイズとバッチ・フラッシュ・タイムアウトのデフォルト値が付属しています。副次的なことは、ダイナミックな要求に応じて動的に変更することができればうれしいことですが、これは後で検討するのは興味深い点です。

したがって、FileChannel を使用すると、レイテンシを犠牲にして、"処理中のデータ (inflight data)"に永続性を持たせることができ、この方法では、エージェントでソフトウェアの障害/クラッシュが発生した場合に完全な損失を防ぐことができます。ただし、コンテナ内のこのファイルの場所はカスタマイズ可能ではないため、コンテナのクラッシュによってフラッシュされない値が失われることに注意してください。

これらのチャネルをどこか別の場所に維持する方法や、異なるコンテナにまたがってチャネルを共有する方法を模索することができます。あるいは、Solace のようなメッセージ・ベースのソリューションをチャネル・レベルで使用することを探しているかもしれません。しかし、もちろんこれには、このプロジェクトの範囲を超えていて、Cygnus に対するいくつかの更新が必要です。