Zenoh 0.7.0-rc のリリースについてのブログ投稿(Zenoh Charmander が町にやって来た)でお知らせしたとおり、この度、新製品のAmazonS3/MinIO バックエンド導入により、バックエンドストレージ能力が向上しました。
これは、もうすぐ roadmapに登場するDiscord上の当社のコミュニティからの要請による機能です。
このS3 バックエンドは、パッケージをhttps://download.eclipse.org/zenoh/zenoh-backend-s3/latest/からダウンロードすることでインストールできます。ソースコードは、eclipse-zenohリポジトリにあります: https://github.com/eclipse-zenoh/zenoh-backend-s3。READMEでAmazon S3とMinIOの両方についてこのバックエンドのセットアップ方法についての詳細な説明を記載しています。
目次
このブログ投稿では、S3バックエンドについて説明します。バックエンドのコンセプトは何か、どのようにS3バックエンドがそこに適合しているか、どのように設定され、その限界のいくつかや、このバックエンドを使用する際の注意点なども見ていきます。
目次
Zenoh バックエンド
「バックエンドって何?」と思っておられるかもしれません。Zenohにおけるバックエンドとは、Zenohで作成されたキー / 値の公開を保存し、クエリに対して返送できるストレージ技術のことを指します。様々なストレージ技術で様々な場合に基づいてキー / 値を保存することができます。
現在、当社は3つのバックエンドシステムを有しています。
- InfluxDB: IoTや分析アプリ、クラウドアプリを開発するデベロッパー用の時系列データプラットフォーム
- RocksDB: 高速ストレージ環境のための高性能永続的キーバリューストレージ
- FileSystem: このバックエンドは、ホストのファイルシステムを利用して、ストレージを実装します
AmazonS3は、クラウドストレージサービスにデータを保存する能力を得て、このリストに加わりました。
特にオブジェクト志向のストレージの場合に、ストレージ能力が強化されるでしょう。現在のところ、オブジェクトストレージを使うには、ホストのファイルシステムに制限されているシンプルなストレージオプションとして設計されているファイルシステムバックエンドを使う場合に限られています。これは、セキュリティ、データ利用性、および性能に関してクラウドストレージが提供するメカニズムの多くを欠いており、スケーラビリティについてもあまり優れていないバックエンドです。
当社のユーザは、クラウド上で簡単にセットアップでき、性能、セキュリティ、データ利用性を提供でき、スケーラブルであるなら、オブジェクトストレージ技術を使用する可能性を探していました。Amazon S3はこれらの条件のすべてを統合したもので、すぐに提案されました。今日まで、システム産業において幅広く使用されている実績のある技術です。
特徴
S3 ストレージ
Amazon S3(Simple Storage Serviceの略)は、アマゾンウエブサービスのオブジェクトストレージ能力を提供するもので、「業界最高のスケーラビリティ、データ利用性、セキュリティ、および性能」を提供します。
このバックエンドにより以下のことができます:
- S3 バケットのファイル/オブジェクトとして値を保存
- バケットを作成
- 既存のバケットを再使用
- キーエクスプレッションにより提供されたパスの下、特定された値でストレージのファイルを作成、更新するためにストレージに値を置く
- 以下のものを有するクエリ値/ファイ
- 具体的なキーエクスプレッション
- ワイルドカード(‘\*’ and ‘\*\*’)を含むキーエクスプレッション(これは、そのパスがキーエクスプレッションとマッチするファイルの値を返します)
- ファイルの削除
- 保存の削除
MinIOとの互換性
MinIOは、高性能を提供するオープンソースのマルチクラウドオブジェクトストレージであり、S3 対応のオブジェクトストレージです。私たちはお客様が用途に合わせてAmazonS3とMinIO のどちらでも選べるようにこのバックエンドを開発しました。どちらを選ぶか決める際には多くのファクターがあります。考慮する事項のひとつは、ストレージとのインターアクションの量です。Zenohの場合はストレージに保存する、または読み出すためのリクエストを何千と受け取ることができますが、Amazon S3を使用する場合はストレージの料金に影響を与えるかもしれません。
TLS support
AmazonS3自身もHTTPSサポートを提供しますが、もしMinIOを使って自社のS3インスタンスをセットアップするなら、TLSを使って接続を保護したいと考えるでしょう。そのためにはサーバーを認証できるように証明を特定する必要があります。認証機関からの証明は設定ファイルで指定できます。
設定
下記の一例である設定ファイルは当社レジストリにあります。この設定ファイルのなかには、「ボリューム」と「ストレージ」というパラメーターがあります。
{
"plugins": {
"storage_manager": {
"volumes": {
"s3": {
// This field is mandatory if you are going to communicate with an AWS S3 server and
// optional in case you are working with a MinIO S3 server.
"region": "eu-west-1",
// Endpoint where the S3 server is located.
// This parameter allows you to specify a custom endpoint when working with a MinIO S3
// server.
// This field is mandatory if you are working with a MinIO server and optional in case
// you are working with an AWS S3 server as long as you specified the region, in which
// case the endpoint will be resolved automatically.
"url": "https://s3.eu-west-1.amazonaws.com",
// Optional TLS specific parameters to enable HTTPS with MinIO. Configuration shared by
// all the associated storages.
"tls": {
// Certificate authority to authenticate the server.
"root_ca_certificate": "./certificates/minio/ca.pem"
}
}
},
"storages": {
// Configuration of a "demo" storage using the S3 volume. Each storage is associated to a
// single S3 bucket.
"s3_storage": {
// The key expression this storage will subscribes to
"key_expr": "s3/example/*",
// this prefix will be stripped from the received key when converting to database key.
// i.e.: "demo/example/a/b" will be stored as "a/b"
"strip_prefix": "s3/example",
"volume": {
// Id of the volume this storage is associated to
"id": "s3",
// Bucket to which this storage is associated to
"bucket": "zenoh-bucket",
// The storage attempts to create the bucket, but if the bucket already exists and is
// owned by you, then with 'reuse_bucket' you can associate that preexisting bucket to
// the storage, otherwise it will fail.
"reuse_bucket": true,
// If the storage is read only, it will only handle GET requests
"read_only": false,
// strategy on storage closure, either `destroy_bucket` or `do_nothing`
"on_closure": "destroy_bucket",
"private": {
// Credentials for interacting with the S3 bucket
"access_key": "AKIAIOSFODNN7EXAMPLE",
"secret_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
}
}
}
}
},
// Optionally, add the REST plugin
"rest": { "http_port": 8000 }
}
}
S3ストレージの当社の概念では、各ストレージは、S3バケットと関連付けされており、ボリュームは、サーバーと関連付けられています。ボリュームは、多数のストレージと関連付けられることができ、これは、すべてのS3バケットが同じサーバーに保存されるということを意味します。
必要とされるボリュームの設定は、サーバーがどこに配置されるのか(Amazon S3を使用する場合は、領域のみを特定するだけでよいのですが、inIOを使用する場合は、URLを提供する必要があります)と、TLS証明パスを特定することだけです。それに関連付けられているすべてのストレージが同じ設定を共有します。
ストレージ設定では、キーエクスプレッション、バケットの名前、アクセスに必要なクレデンシャル、ストレージの作成に関連するいくつかのポリシー、そして読み取り、書き込みの許可などを特定します。例示の設定ファイルにはより詳細が提供されています。
注意点
このS3バックエンドは、まだ開発中のもので、もう少し作業が必要だと見込まれていることをご留意ください。
このバックエンドを現段階で使用するにはいくつか注意点があります。MinIO とAmazonS3がどのように作動するかに関するものと、このバックエンドの開発状態に関するものです。
同名のファイルとディレクトリ
MinIOとAmazonS3の間の差異に関し、MinIO は「S3互換性」ですが、これは同じように動作するという意味ではありません。
開発中に当社が気付いた差異のひとつは、ある疑問から生じたものでした。もしある値をキー「a/b」に付し、別の値をa/b/cに付したらどうなるかです。Zenohでは、これは可能であると予想できます。Zenohでは、値を a/b/c に付しても、a/bに付してもパブリッシュでき、例えばa/\*\*をサブスクライブしている受信者は、リスナーがストレージであろうとなかろうと、どちらのイベントも受信できるはずです。
この状況に対処する時、システムはどのように挙動するのでしょう?
└── a
├── b
│ └── c
└── b
パブリケーションをa/bで行い、その後a/b/cで行う(またはその逆)ということは、/aの下で同じ場所で同じファイルとして同じ名前でディレクトリを有するということです。
MinIOでは、そのような挙動は許されておらず、しようとしてもエラーメッセージが出ます。しかし、Amazon S3はそれにまったく苦情は言わないのです!これは、Amazon S3は、ファイルとディレクトリを整理するフラットネームスペースを用いており、MinIOは、ファイルシステムヒエラルキーを保存に使っているからです(詳細については、こちらの議論をご参照ください)。このファイルシステムでは、同じ場所のディレクトリとして同じ名前のファイルを持てないようになっています。当社は、少し前にファイルシステムバックエンドの開発時にこの問題に直面しました。この挙動を許し、両方のイベントの値を保存するメカニズムを開発する必要がありました。しかし、この新しいS3バックエンドでは、現時点ではそのためのメカニズムを実装しておりません。なので、今の段階でこのバックエンドをMinIOと使用する時は、この点に注意する必要があります。
サンプルタイムスタンプ
サンプルのタイムスタンプはまだ考慮していません。これは、エッジのケースでは問題を生じる可能性があります。例えば、同じキーエクスプレッションでPUTの直後にDELETEを送信する場合、DELETEの操作が、PUTの操作の前にストレージに到着することが起こりえます。そうすると、順番の問題で削除するはずのファイルが保存されたままになります。タイムスタンプを考慮すると、この例の場合には、PUT操作を破棄し、ストレージの問題を回避できます。これはこれからインプリメンテーションするのですが、問題 はすでに公開されています。
レプリカサポート
レプリケーションは、Zenohサイドではまだサポートしていません。同じキーエクスプレッションにサブスクライブしている2つのS3バックエンドを装備しているなら、データ再生の際に欠損しているデータを他のバックエンドから得て同期させる必要があります。これはまだインプリメンテーションしていません。しかし、Amazon S3とMinIOの両方が提供するレプリケーションメカニズムを利用することができます。
他のレプリケーションの問題は、複数の異なるバックエンド、例えば、S3 とRocksDBを装備したいときに生じます。現時点でこれを回避する策はありません。ユーザが主導で同期を行う必要があります。
Aws-sdk-s3 ライブラリ
最後に、このインプリメンテーションはAmazonの aws-sdk-s3 Rust crateに依存しています。これも現在開発中であるため、「注:SDKは現在デベロッパーの確認作業中で、フィードバックの目的に限定したものです。このSDKを製造ワークロードに使用しないでください」と明記していますから、生産リリースをする前に絶対にこの点に注意する必要があります。
現時点では、このクレートを開発中のAmazonのエンジニアリングチームが新しいバージョンを定期的に発表しています。その結果、依存するバージョンを更新するために、このバックエンドの新しいバージョンが今後も期待できます。
さあ、次です!
これが、当社の最近のS3バックエンドのインプリメンテーションによりZenoh のストレージとしてS3をどのように使用するかについての投稿の最後になります。
まだ開発中ではありますが、その最初のバージョンでも以下のような多くの機能が可能です。
- S3ストレージからのデータをクエリするためのキーエクスプレッションを使用するなどのZenohの特性を利用できる
- TLSを用いてS3ストレージとの通信を安全化する
- MinIOを Amazon S3の代わりに使用する
しかし、近い将来に取り組む課題もあります。
アップデートを見逃さないでください。Discordについての Zenohチームからのお知らせと、ロードマップについての新しい機能を確認するのをお忘れなく。