翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS Glue スキーマレジストリ
注記
AWS Glue スキーマレジストリは、アジアパシフィック (ジャカルタ) と中東 (UAE) リージョンの AWS Glue コンソールではサポートされていません。。
AWS Glue スキーマレジストリを使用すると、データストリームスキーマを一元的に検出、制御、展開できます。スキーマは、データレコードの構造と形式を定義します。AWS Glue のスキーマレジストリを使用すると、Apache Kafka、Amazon Managed Streaming for Apache Kafka
スキーマレジストリは、AVRO (v1.10.2) データ形式、Everit ライブラリextensions または groups のサポートが含まれないプロトコルバッファ (Protobuf) バージョンの proto2 および proto3、Java 言語対応をサポートしており、今後は他のデータ形式や言語にも対応していきます。サポートされている機能には、互換性、メタデータを介したスキーマのソーシング、スキーマの自動登録、IAM 互換性、ストレージとデータ転送を削減する ZLIB 圧縮のオプションがあります。スキーマレジストリはサーバーレスで無料で使用できます。
プロデューサとコンシューマの間のデータ形式契約としてスキーマを使用すると、データガバナンスおよびデータ品質の向上につながります。さらにデータのコンシューマは、上流で行われる互換性に関する変更に対する復旧力を得ることができます。
スキーマレジストリを使用すると、異なるシステムでシリアル化と非シリアル化用のスキーマを共有できます。例えば、データのプロデューサーとコンシューマーを考えてみます。データの公開時、プロデューサーはスキーマを把握しています。Schema Registry は、Amazon MSK や Apache Kafka などの特定のシステム用に、シリアル化と非シリアル化の機能を提供します。
詳しくは、「スキーマレジストリの仕組み 」を参照してください。
トピック
スキーマ
スキーマは、データレコードの構造と形式を定義します。スキーマは、信頼性の高いデータの公開、利用、または保存のための仕様をバージョニングしたものです。
この例の Avro のスキーマでは、形式と構造はレイアウトとフィールド名によって定義され、フィールド名の形式はデータ型 (例:string、int) により定義されています
{ "type": "record", "namespace": "ABC_Organization", "name": "Employee", "fields": [ { "name": "Name", "type": "string" }, { "name": "Age", "type": "int" }, { "name": "address", "type": { "type": "record", "name": "addressRecord", "fields": [ { "name": "street", "type": "string" }, { "name": "zipcode", "type": "int" } ] } } ] }
この例の JSON 用の JSON スキーマ draft-07 では、形式を JSON スキーマ組織
{ "$id": "https://example.com/person.schema.json", "$schema": "http://json-schema.org/draft-07/schema#", "title": "Person", "type": "object", "properties": { "firstName": { "type": "string", "description": "The person's first name." }, "lastName": { "type": "string", "description": "The person's last name." }, "age": { "description": "Age in years which must be equal to or greater than zero.", "type": "integer", "minimum": 0 } } }
この例の Protobuf では、データ形式を Protocol Buffers l言語のバージョン 2 (proto2)
syntax = "proto2"; package tutorial; option java_multiple_files = true; option java_package = "com.example.tutorial.protos"; option java_outer_classname = "AddressBookProtos"; message Person { optional string name = 1; optional int32 id = 2; optional string email = 3; enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; } message PhoneNumber { optional string number = 1; optional PhoneType type = 2 [default = HOME]; } repeated PhoneNumber phones = 4; } message AddressBook { repeated Person people = 1; }
レジストリ
レジストリはスキーマの論理コンテナです。レジストリを使用すると、スキーマを整理したり、アプリケーションのアクセス制御を管理したりできます。レジストリは Amazon リソースネーム (ARN) を持っており、これにより、レジストリ内のスキーマ操作に対するさまざまなアクセス許可の整理と設定を可能にしています。
レジストリはデフォルトのまま使用することも可能ですが、必要な数の新しいレジストリを作成することもできます。
|
|
|
|
スキーマのバージョニングと互換性
各スキーマは、複数のバージョン作成することができます。バージョニングは、スキーマに適用される互換性ルールによって制御されます。新しいスキーマバージョンの登録に関するリクエストについては、この規則に対するチェックが Schema Registry により行われ後で処理が続行されます。
チェックポイントとしてマークされたスキーマバージョンは、スキーマの新しいバージョンを登録する際の互換性判断のために使用されます。スキーマが最初に作成されると、最初のバージョンがデフォルトのチェックポイントになります。スキーマのバージョンが増加した場合には、CLI/SDK により、一連の制約に従う UpdateSchema APIを使用しながら、チェックポイントに使用するスキーマのバージョンを変更できます。デフォルトでは、コンソールでスキーマの定義または互換モードを編集することで、チェックポイントが最新バージョンに変更されます。
互換モードを使用すると、スキーマを時間の経過とともにどのように増加させるか、あるいは増加させないかを制御できます。これらのモードは、データのプロデューサおよびコンシューマである、アプリケーション間の契約を形成します。スキーマの新しいバージョンがレジストリに送信されると、そのスキーマ名に適用されている互換性規則を使用して、新しいバージョンの受け付が可能かどうかが判断されます。互換モードには、NONE、DISABLED、BACKWARD、BACKWARD_ALL、FORWARD、FORWARD_ALL、FULL、FULL_ALL の 8 種類があります
Avro データ形式では、フィールドはオプションまたは必須の両方の場合があります。フィールドがオプションの場合、Type には null が含まれます。必須フィールドでは、Type は null に設定されません。
Protobuf のデータ形式の場合、 proto2 構文ではフィールドを (繰り返しを含み) オプションまたは必須にすることができます。一方、proto3 構文ではすべてのフィールドが (繰り返しを含み) オプションとなります。すべての互換性ルールは、Protocol Buffers の仕様と、Google の Protocol Buffers ドキュメント
NONE: 互換モードは適用されません。このモードは、開発向けのシナリオか、スキーマに適用する互換モードがわからない場合に使用できます。新しいバージョンが追加されたとき、互換性チェックを受けずに受け入れられます。
DISABLED: 互換性についてこの選択をすると、特定のスキーマのバージョン管理が不要になります。新しいバージョンを追加することはできません。
BACKWARD: これは推奨の互換性モードで、コンシューマは、現在および過去のスキーマバージョンの両方からの読み取りが可能です。このモードを使用すると、フィールドの削除や任意のフィールドの追加を行う際に、以前のスキーマバージョンとの互換性をチェックできます。アプリケーションが最新のスキーマ用に作成された場合などが、BACKWARD の一般的なユースケースです。
AVRO
例えば、名前 (必須)、姓 (必須)、E メール (必須)、電話番号 (オプション) で定義されているスキーマがあるとします。
次のスキーマバージョンで、必須である E メールフィールドが削除されたとしても、これは正常に登録されます。後方互換性のために、コンシューマは、現在および 1 つ前のスキーマバージョンを読み取れることが必要です。古いメッセージの余分な E メールフィールドが無視されるため、コンシューマーは新しいスキーマを読み取ることができます。
仮に、郵便番号などのフィールドを必須として追加する新しいスキーマバージョンが提案された場合、BACKWARD の互換モードでは正常に登録されません。新しいバージョンのコンシューマーは、必須な郵便番号フィールドを含まない、スキーマが変更される前の古いメッセージを読み取ることができないためです。ただし、新しいスキーマで郵便番号フィールドがオプションとして設定されていれば、提案されたバージョンは正常に登録されます。郵便番号フィールドはオプションなので、コンシューマーはこのフィールドなしでも古いスキーマを読み取れるためです。
JSON
例えば、あるスキーマバージョンが、名 (オプション)、姓 (オプション)、E メール (オプション)、電話番号 (オプション)で定義されているとします。
仮に、次に続くスキーマバージョンで電話番号プロパティがオプションとして追加された場合でも、元のスキーマバージョンで
additionalPropertiesフィールドを false に設定しプロパティの追加を禁止しているのであれば、この新しいバージョンは正しく登録されます。後方互換性のために、コンシューマは、現在および 1 つ前のスキーマバージョンを読み取れることが必要です。コンシューマは、電話番号プロパティが存在しない元のスキーマで生成されたデータを読み取ることができます。BACKWARD の互換モードで、オプションの電話番号プロパティを追加する新しいスキーマバージョンが提案された際に、元のスキーマバージョンで
additionalPropertiesフィールドを true に設定し任意のプロパティの追加を許可していると、このバージョンは正しく登録されません。新しいバージョンのコンシューマは、スキーマが変更される前の古いメッセージを読み取ることができません。これは、別の型 (数ではなく文字列など) で記述された電話番号プロパティデータを、読み取ることができないためです。PROTOBUF
例えば、
first name(必須)、last name(必須)、email(必須)phone number(オプション) フィールドを持つ、proto2 構文の MessagePersonで定義されているスキーマバージョンを考えます。AVRO での場合と同様に、次に続くスキーマバージョンで、必須である
emailフィールドが削除されたとしても、これは正常に登録されます。後方互換性のために、コンシューマは、現在および 1 つ前のスキーマバージョンを読み取れることが必要です。古いメッセージでは、余分なemailフィールドが無視されるため、コンシューマーは新しいスキーマを読み取ることができます。BACKWARD の互換モードでは、仮に
zip codeなどのフィールドを必須として追加する新しいスキーマバージョンが提案された場合、これは正常に登録されません。スキーマが変更される前の古いメッセージには、必須なzip codeフィールドが含まていないため、新しいバージョンのコンシューマーは、そのメッセージを読み取ることができないためです。ただし、新しいスキーマでzip codeフィールドがオプションとして設定されていれば、提案されたバージョンは正常に登録されます。zip codeフィールドはオプションなので、コンシューマーはこのフィールドなしでも古いスキーマを読み取れます。gRPC ユースケースの場合、新しい RPC サービスまたは RPC メソッドを追加することで、後方互換性が変更されます。例えば、2 つの RPC メソッド
FooおよびBarを使用する RPC サービスMyServiceで定義されている、スキーマバージョンがあるとします。次に続くスキーマバージョンで、
Bazという新しい RPC メソッドが追加された場合、これは正常に登録されます。新しく追加された RPC メソッドBazはオプションのため、コンシューマーは元のスキーマで生成されたデータを、BACKWARD 互換性に従って読み取ることができます。提案された新しいスキーマバージョンで、既存の RPC メソッド
Fooを削除する場合、BACKWARD 互換性では正常に登録されません。新しいバージョンのコンシューマーは、スキーマが変更される前の古いメッセージを読み取ることができません。これは、gRPC アプリケーション内に RPC メソッドFooが存在せず、データを理解して読み取れないためです。BACKWARD_ALL: この互換モードでは、コンシューマは現在および過去のすべてのスキーマバージョンの読み取りが可能です。このモードを使用すると、フィールドを削除したり任意のフィールドを追加する際に、以前のすべてのスキーマバージョンとの互換性をチェックできます。
FORWARD: この互換モードにより、コンシューマは現在とその次のスキーマバージョンの両方を読み取ることができますが、それより後に続くバージョンを必ずしも読み取れる訳ではありません。このオプションを使用すると、フィールドを追加したり、任意のフィールドを削除したりする際に、最新のスキーマバージョンとの互換性をチェックできます。過去のスキーマ用に作成されたアプリケーションが、より新しいスキーマを処理できる必要がある場合などが、FORWARD の一般的なユースケースです。
AVRO
例として、名前 (必須)、姓 (必須)、E メール (オプション) で定義されているスキーマバージョンを考えます。
この場合、電話番号などのフィールドを必須として追加する新しいスキーマバージョンは正常に登録されます。FORWARD 互換モードでは、新しいスキーマで生成されたデータを、コンシューマーが以前のバージョンを使用して読み取れることが必要です。
必須である名 (ファーストネーム) のフィールドを削除するスキーマバージョンが提案されとしても、FORWARD 互換モードでは正常に登録されません。名の必須フィールドがないので、以前のバージョンのコンシューマーが提案されたスキーマを読み取ることができなくなるためです。しかし、名 (ファーストネーム) のフィールドが本来オプションであれば、オプションの名のフィールドを持たない新しいスキーマに基づいたデータをコンシューマーが読み取りできるため、提案された新しいスキーマは正常に登録されます。
JSON
例えば、あるスキーマバージョンが、名 (オプション)、姓 (オプション)、E メール (オプション)、電話番号 (オプション)で定義されているとします。
オプションの電話番号プロパティを削除する新しいスキーマバージョンの場合、このスキーマバージョンで
additionalPropertiesフィールドを false に設定しプロパティの追加を禁止しているのであれば、正しく登録されます。FORWARD 互換モードでは、新しいスキーマで生成されたデータを、コンシューマーが以前のバージョンを使用して読み取れることが必要です。オプションの電話番号プロパティを削除するスキーマバージョンが提案された際に、この新しいスキーマバージョンで
additionalPropertiesフィールドを true に設定し任意のプロパティの追加を許可していると、FORWARD の互換モードでは正しく登録されません。提案されたスキーマが、異なる型 (数ではなく文字列など) の電話番号プロパティを持つ場合には、以前のバージョンを使用するコンシューマで、このスキーマの読み取りが不可能になるためです。PROTOBUF
例えば、
first name(必須)、last name(必須)、email(オプション) のフィールドを持つ、proto2 構文の MessagePersonで定義されているスキーマバージョンを考えます。AVRO の場合と同様に、
phone numberなどの必須フィールドを追加する新しいスキーマバージョンの場合、これは正常に登録されます。FORWARD 互換モードでは、新しいスキーマで生成されたデータを、コンシューマーが以前のバージョンを使用して読み取れることが必要です。必須である名
first nameフィールドを削除するスキーマバージョンが提案されとしても、FORWARD 互換モードでは正常に登録されません。必須であるfirst nameフィールドがないので、以前のバージョンのコンシューマーは、提案されたスキーマを読み取ることができなくなるためです。しかし、first nameフィールドが本来オプションであれば、新しいスキーマにfirst nameフィールドがないとしてもこれはオプションであるため、コンシューマーはこのスキーマ基づいたデータを読み取ることが可能であり、したがって提案された新しいスキーマは正常に登録されます。gRPC ユースケースの場合、RPC サービスまたは RPC メソッドを削除すると、前方互換性が変更されます。例えば、2 つの RPC メソッド
FooおよびBarを使用する RPC サービスMyServiceで定義されている、スキーマバージョンがあるとします。次に続くスキーマバージョンが、
Fooという名前の既存の RPC メソッドを削除する場合も、これは FORWARD 互換性に従って正常に登録されます。コンシューマーは、新しいスキーマで生成されたデータを、以前のバージョンを使用して読み取ることが可能です。RPC メソッドBazを追加するスキーマバージョンが提案され場合、これは FORWARD 互換モードでは正常に登録されません。RPC メソッドBazがないので、以前のバージョンのコンシューマーは、この提案されたスキーマを読み取ることができないためです。FORWARD_ALL: この互換モードでは、任意の新しい登録済みスキーマのプロデューサーによって書き込まれたデータを読み取ることを、コンシューマに許可します。この選択は、フィールドを追加したり、オプションフィールドを削除したり、以前のすべてのスキーマバージョンとの互換性を確認したりする必要がある場合に使用できます。
FULL: この互換モードにより、コンシューマーは、1 つ前または次のバージョンのスキーマを使用するプロデューサーによって書き込まれたデータを読み取ることができますが、それ以前またはそれ以降のバージョンについては読み取れません。このモードでは、任意のフィールドを追加または削除する際に、最新のスキーマバージョンとの互換性をチェックできます。
FULL_ALL: この互換モードにより、コンシューマーは、過去の任意のスキーマバージョンを使用するプロデューサーによって書き込まれたデータを読み取ることができます。このモードは、オプションのフィールドを追加または削除する際に、過去のすべてのスキーマバージョンとの互換性をチェックするために使用できます。
オープンソース Serde ライブラリ
AWS では、データをシリアル化および非シリアル化するためのフレームワークとして、オープンソースの Serde ライブラリが用意されています。このオープンソースなライブラリ設計により、一般的なオープンソースのアプリケーションやフレームワークが、それぞれのプロジェクトでこれらのライブラリをサポートできるようにしています。
Serde ライブラリの仕組みの詳細については、「スキーマレジストリの仕組み」を参照してください。
Schema Registry のクォータ
AWS のクォータ (制限とも呼ばれます) は、AWS アカウントのリソース、アクション、および制限の最大値です。以下に、AWS Glue の Schema Registry におけるソフト制限を示します。
スキーマバージョンのメタデータでのキー値ペアの数。
AWS リージョンごとの各 SchemaVersion において、最大 10 個のキーと値のペアを使用できます。
メタデータでのキーと値のペアは、QuerySchemaVersionMetadata アクション (Python: query_schema_version_metadata) または PutSchemaVersionMetadata アクション (Python: put_schema_version_metadata) APIを使用して表示または設定できます。
AWS Glue の Schema Registry でのハード制限は次のとおりです。
レジストリ
このアカウントでは、AWS リージョンごとに最大 100 のレジストリを使用できます。
SchemaVersion
このアカウントでは、AWS リージョンごとに最大 10000 のスキーマバージョンを使用できます。
各新しいスキーマは新しいスキーマバージョンを作成します。したがって、各スキーマに 1 つのバージョンしかない場合、リージョンごとの各アカウントには理論的に最大 10000 のスキーマを使用できます。
スキーマペイロード
スキーマペイロードには、170 KB のサイズ制限があります。
