Cygnusにおけるマルチテナンシー

コンテンツ :

一般的なマルチテナンシーの前提

このセクションでは、特に次のシンクを使用する場合、Cygnus でマルチテナントを実装する際に従うべき一般的なルールについて説明します :

  • NGSIHDFSSink
  • NGSIMySQLSink
  • NGSICKANSink
  • NGSIMongoSink
  • NGSISTHSink

後述するように、NGSIDynamoDBSink, NGSIKafkaSink および NGSITestSink は、マルチテナンシーの面で一般的なルールに従っていません。

一般的なマルチテナンシーの前提は、すべてのユーザ空間に書き込むことができる単一のスーパ・ユーザがシンク内で設定されていることです。このような前提により、1つの Cygnus インスタンスが、複数のテナント(FIWARE services)に関するコンテキスト・データを扱うことができます。そのため、すべてのエンティティの代わりに書き込むことが許可されています。もちろん、複数のテナントは、一度データがCygnusによって保存されると、その特定のユーザー空間をI/Oできる別の特定のユーザーをそれぞれ所有します。

上記の解決策は、コンテキスト・データがユーザ空間ごとに何らかの種類のデータ分離を保証できる場合に、最終的なストレージが履歴ビューを保持する場合にのみ機能することができる。ユーザ空間の例は次のとおりです :

  • A HDFS ユーザフォルダ
  • A MySQL データベース
  • A CKAN organization
  • A MongoDB データベース

トップ

例外

NGSIDynamoDBSink

DynamoDB はクライアントごとに1つのデータベースを処理し、各クライアントに異なるアクセス資格情報を与えます。つまり、1人のスーパ・ユーザは、複数のテナントに代わってデータを書き込むように構成することはできません。すべてのテナントに単一の DynamoDB ユーザ空間が使用され、クライアントごとにテーブルが作成されても、ユーザ空間にアクセスするとすべてのテーブルにアクセスするため、有効な解決策ではありません。

この未解決の問題は、今後、いつか実装されるよりも有効な解決策を取りまとめようとしています。

トップ

NGSIKafkaSink

当分の間、Kafka はどんな種類の認証メカニズムもサポートしていません。これは、テナントごとに1つずつ、いくつかのトピックを作成することができますが、異なるトピックを誰が読むことができるのかを制御することはできません。

トップ

NGSITestSink

これはテスト目的のシンクであるため、マルチテナンシーのサポートは必要ありません。

トップ