# AWS Glue スキーマレジストリ
**注記**
AWS Glue スキーマレジストリは、中東 (UAE) リージョンの AWS Glue コンソールではサポートされていません。
AWS Glue スキーマレジストリを使用すると、データストリームスキーマを一元的に検出、制御、展開できます。*スキーマ* は、データレコードの構造と形式を定義します。AWS Glue のスキーマレジストリを使用すると、Apache Kafka、[Amazon Managed Streaming for Apache Kafka](https://aws.amazon.com/msk/)、[Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/)、[Amazon Managed Service for Apache Flink](https://aws.amazon.com/kinesis/data-analytics/)、[AWS Lambda](https://aws.amazon.com/lambda/) と便利な統合を使用するデータストリームアプリケーションでスキーマを管理して実施することができます。
スキーマレジストリは、AVRO (v1.11.4) データ形式、[Everit ライブラリ](https://github.com/everit-org/json-schema)を使用した JSON スキーマ検証を含むスキーマ用 (Draft-04、Draft-06、Draft-07 仕様) の [JSON スキーマ形式](https://json-schema.org/)の JSON データ形式、`extensions` または `groups` のサポートが含まれないプロトコルバッファ (Protobuf) バージョンの proto2 および proto3、Java 言語対応をサポートしており、今後は他のデータ形式や言語にも対応していきます。サポートされている機能には、互換性、メタデータを介したスキーマのソーシング、スキーマの自動登録、IAM 互換性、ストレージとデータ転送を削減する ZLIB 圧縮のオプションがあります。スキーマレジストリはサーバーレスで無料で使用できます。
プロデューサとコンシューマの間のデータ形式契約としてスキーマを使用すると、データガバナンスおよびデータ品質の向上につながります。さらにデータのコンシューマは、上流で行われる互換性に関する変更に対する復旧力を得ることができます。
スキーマレジストリを使用すると、異なるシステムでシリアル化と非シリアル化用のスキーマを共有できます。例えば、データのプロデューサーとコンシューマーを考えてみます。データの公開時、プロデューサーはスキーマを把握しています。スキーマレジストリは、Amazon MSK や Apache Kafka などの特定のシステム用に、シリアル化と非シリアル化の機能を提供します。
詳しくは、「[スキーマレジストリの仕組み](schema-registry-works.md) 」を参照してください。
**Topics**
+ [スキーマ](#schema-registry-schemas)
+ [レジストリ](#schema-registry-registries)
+ [スキーマのバージョニングと互換性](#schema-registry-compatibility)
+ [オープンソース Serde ライブラリ](#schema-registry-serde-libraries)
+ [スキーマレジストリのクォータ](#schema-registry-quotas)
+ [スキーマレジストリの仕組み](schema-registry-works.md)
+ [スキーマレジストリの開始方法](schema-registry-gs.md)
## スキーマ
*スキーマ* は、データレコードの構造と形式を定義します。スキーマは、信頼性の高いデータの公開、利用、または保存のための仕様をバージョニングしたものです。
この例の 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 スキーマ組織](https://json-schema.org/)が定義しています。
```
{
"$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)](https://developers.google.com/protocol-buffers/docs/reference/proto2-spec) で定義しています。
```
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) を持っており、これにより、レジストリ内のスキーマ操作に対するさまざまなアクセス許可の整理と設定を可能にしています。
レジストリはデフォルトのまま使用することも可能ですが、必要な数の新しいレジストリを作成することもできます。
**AWS Glue スキーマレジストリでの階層**
| |
| --- |
| [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/schema-registry.html) |
| [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/schema-registry.html) |
| [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/schema-registry.html) |
| [See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/schema-registry.html) |
## スキーマのバージョニングと互換性
各スキーマは、複数のバージョン作成することができます。バージョニングは、スキーマに適用される互換性ルールによって制御されます。新しいスキーマバージョンの登録に関するリクエストについては、この規則に対するチェックがスキーマレジストリにより行われ後で処理が続行されます。
チェックポイントとしてマークされたスキーマバージョンは、スキーマの新しいバージョンを登録する際の互換性判断のために使用されます。スキーマが最初に作成されると、最初のバージョンがデフォルトのチェックポイントになります。スキーマのバージョンが増加した場合には、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 ドキュメント](https://developers.google.com/protocol-buffers/docs/overview#updating)を詳細に把握した上で定義されています。
+ *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 構文の Message `Person` で定義されているスキーマバージョンを考えます。
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 構文の Message `Person` で定義されているスキーマバージョンを考えます。
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-works.md)」を参照してください。
## スキーマレジストリのクォータ
AWS のクォータ (制限とも呼ばれます) は、AWS アカウントのリソース、アクション、および制限の最大値です。以下に、AWS Glue のスキーマレジストリにおけるソフト制限を示します。
**スキーマバージョンのメタデータでのキー値ペアの数。**
AWS リージョンごとの各 SchemaVersion において、最大 10 個のキーと値のペアを使用できます。
メタデータでのキーと値のペアは、[QuerySchemaVersionMetadata アクション (Python: query\_schema\_version\_metadata)](aws-glue-api-schema-registry-api.md#aws-glue-api-schema-registry-api-QuerySchemaVersionMetadata) または [PutSchemaVersionMetadata アクション (Python: put\_schema\_version\_metadata)](aws-glue-api-schema-registry-api.md#aws-glue-api-schema-registry-api-PutSchemaVersionMetadata) APIを使用して表示または設定できます。
AWS Glue のスキーマレジストリでのハード制限は次のとおりです。
**レジストリ**
このアカウントでは、AWS リージョンごとに最大 100 のレジストリを使用できます。
**SchemaVersion**
このアカウントでは、AWS リージョンごとに最大 10000 のスキーマバージョンを使用できます。
各新しいスキーマは新しいスキーマバージョンを作成します。したがって、各スキーマに 1 つのバージョンしかない場合、リージョンごとの各アカウントには理論的に最大 10000 のスキーマを使用できます。
**スキーマペイロード**
スキーマペイロードには、170 KB のサイズ制限があります。