翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS KMS 階層キーリング
クライアント側の暗号化ライブラリの名前が AWS Database Encryption SDK に変更されました。このデベロッパーガイドでは、引き続き DynamoDB Encryption Client に関する情報を提供します。 |
注記
2023 年 7 月 24 日の時点では、デベロッパープレビュー中に作成されたブランチキーはサポートされていません。デベロッパープレビュー中に作成したキーストアを引き続き使用するには、新しいブランチキーを作成します。
AWS KMS 階層キーリングを使用すると、レコードを暗号化または復号する AWS KMS たびに を呼び出すことなく、対称暗号化 KMS キーで暗号化マテリアルを保護できます。これは、 への呼び出しを最小限に抑える必要があるアプリケーションや AWS KMS、セキュリティ要件に違反することなく一部の暗号化マテリアルを再利用できるアプリケーションに適しています。
階層キーリングは、Amazon DynamoDB テーブルに保持されている AWS KMS 保護されたブランチキーを使用し、暗号化および復号オペレーションで使用されるブランチキーマテリアルをローカルにキャッシュすることで AWS KMS 、呼び出しの数を減らす暗号化マテリアルキャッシュソリューションです。DynamoDB テーブルは、ブランチキーを管理および保護するキーストアとして機能します。アクティブなブランチキーと、ブランチキーの以前のすべてのバージョンが格納されます。アクティブなブランチキーは、ブランチキーの最新バージョンです。階層キーリングは、暗号化リクエストごとに一意のデータ暗号化キーを使用し、アクティブなブランチキーから派生した一意のラッピングキーを使用して各データ暗号化キーを暗号化します。階層キーリングは、アクティブなブランチキーと、その導出ラッピングキーの間に確立された階層に依拠します。
階層キーリングは通常、複数のリクエストを満たすために各ブランチキーバージョンを使用します。ただし、ユーザーがアクティブなブランチキーを再利用する範囲を制御し、アクティブなブランチキーをローテーションする頻度を決定します。ブランチキーのアクティブなバージョンは、ローテーションされるまでアクティブなままとなります。アクティブなブランチキーの以前のバージョンは暗号化オペレーションの実行には使用されませんが、引き続きクエリを実行して復号オペレーションに使用できます。
階層キーリングをインスタンス化すると、ローカルキャッシュが作成されます。ブランチキーマテリアルがローカルキャッシュ内に格納される最大時間 (ブランチキーマテリアルが期限切れになってキャッシュから削除されるまでの時間) を定義するキャッシュ制限を指定します。階層キーリングは 1 回の AWS KMS 呼び出しを行い、 オペレーションで が初めてbranch-key-id
指定されたときにブランチキーを復号し、ブランチキーマテリアルをアセンブルします。その後、ブランチキーマテリアルはローカルキャッシュに格納され、キャッシュ制限が期限切れになるまで、その branch-key-id
を指定するすべての暗号化および復号オペレーションのために再利用されます。ブランチキーマテリアルをローカルキャッシュに保存すると、 AWS KMS 呼び出しが減ります。例えば、キャッシュ制限が 15 分である場合を考えてみましょう。そのキャッシュ制限内で 10,000 回の暗号化オペレーションを実行する場合、従来の AWS KMS キーリングは 10,000 回の暗号化オペレーションを満たすために 10,000 回の AWS KMS 呼び出しを行う必要があります。アクティブな が 1 つある場合branch-key-id
、階層キーリングは 10,000 回の暗号化オペレーションを満たすために 1 回の AWS KMS 呼び出しを行うだけで済みます。
ローカルキャッシュは、暗号化マテリアルと復号マテリアルを分離します。暗号化マテリアルはアクティブなブランチキーからアセンブルされ、キャッシュ制限が期限切れになるまですべての暗号化オペレーションに再利用されます。復号マテリアルは、暗号化されたフィールドのメタデータで識別されるブランチキー ID とバージョンからアセンブルされ、キャッシュ制限の有効期限が切れるまで、ブランチキー ID とバージョンに関連するすべての復号オペレーションに再利用されます。ローカルキャッシュは、同じブランチキーの複数のバージョンを一度に保存できます。ローカルキャッシュが を使用するように設定されている場合branch key ID supplier、一度に複数のアクティブなブランチキーからのブランチキーマテリアルを保存することもできます。
注記
AWS Database Encryption SDK の階層キーリングに関するすべての言及は、 AWS KMS 階層キーリングを参照しています。
仕組み
次のチュートリアルでは、階層キーリングが暗号化および復号マテリアルをアセンブルする方法と、暗号化および復号オペレーションのためにキーリングが実行するさまざまな呼び出しについて説明します。ラッピングキーの導出とプレーンテキストデータキーの暗号化プロセスの技術的な詳細については、「AWS KMS 階層キーリングの技術的な詳細」を参照してください。
暗号化および署名
次のチュートリアルでは、階層キーリングが暗号化マテリアルをアセンブルし、一意のラッピングキーを導出する方法について説明します。
-
暗号化メソッドは、階層キーリングに暗号化マテリアルを要求します。キーリングはプレーンテキストのデータキーを生成し、ラッピングキーを生成するための有効なブランチキーマテリアルがローカルキャッシュにあるかどうかを確認します。有効なブランチキーマテリアルがある場合、キーリングはステップ 4 に進みます。
-
有効なブランチキーマテリアルがない場合、階層キーリングはキーストアにアクティブなブランチキーをクエリします。
-
キーストアは AWS KMS を呼び出してアクティブなブランチキーを復号し、プレーンテキストのアクティブなブランチキーを返します。アクティブなブランチキーを識別するデータは、 AWS KMSに対する復号呼び出しで追加認証データ (AAD) を提供するためにシリアル化されます。
-
キーストアは、プレーンテキストのブランチキーと、ブランチキーのバージョンなど、それを識別するデータを返します。
-
-
階層キーリングはブランチキーマテリアル (プレーンテキストブランチキーとブランチキーバージョン) をアセンブルし、それらのコピーをローカルキャッシュに格納します。
-
階層キーリングは、プレーンテキストブランチキーと 16 バイトのランダムソルトから一意のラッピングキーを導出します。プレーンテキストデータキーのコピーを暗号化するために、導出されたラッピングキーを使用します。
暗号化メソッドは、暗号化マテリアルを使用してレコードを暗号化して署名します。 AWS Database Encryption SDK でレコードがどのように暗号化および署名されるのかに関する詳細については、「暗号化して署名」を参照してください。
復号および検証
次のチュートリアルでは、階層キーリングが復号マテリアルをアセンブルし、暗号化されたデータキーを復号する方法について説明します。
-
復号メソッドは、暗号化されたレコードのマテリアルの説明フィールドから暗号化されたデータキーを識別し、それを階層キーリングに渡します。
-
階層キーリングは、ブランチキーのバージョン、16 バイトのソルト、およびデータキーの暗号化方法を説明する他の情報を含む、暗号化されたデータキーを識別するデータを逆シリアル化します。
詳細については、「AWS KMS 階層キーリングの技術的な詳細」を参照してください。
-
階層キーリングは、ステップ 2 で特定されたブランチキーのバージョンと一致する有効なブランチキーマテリアルがローカルキャッシュ内に存在するかどうかをチェックします。有効なブランチキーマテリアルがある場合、キーリングはステップ 6 に進みます。
-
有効なブランチキーマテリアルがない場合、階層キーリングは、ステップ 2 で識別されたブランチキーバージョンに一致するブランチキーについてキーストアをクエリします。
-
キーストアは AWS KMS を呼び出してブランチキーを復号し、プレーンテキストのアクティブなブランチキーを返します。アクティブなブランチキーを識別するデータは、 AWS KMSに対する復号呼び出しで追加認証データ (AAD) を提供するためにシリアル化されます。
-
キーストアは、プレーンテキストのブランチキーと、ブランチキーのバージョンなど、それを識別するデータを返します。
-
-
階層キーリングはブランチキーマテリアル (プレーンテキストブランチキーとブランチキーバージョン) をアセンブルし、それらのコピーをローカルキャッシュに格納します。
-
階層キーリングは、アセンブルされたブランチキーマテリアルと、ステップ 2 で識別された 16 バイトのソルトを使用して、データキーを暗号化した一意のラッピングキーを複製します。
-
階層キーリングは、複製されたラッピングキーを使用してデータキーを復号し、プレーンテキストのデータキーを返します。
復号メソッドは、復号マテリアルとプレーンテキストデータキーを使用し、レコードを復号して検証します。 AWS Database Encryption SDK でレコードを復号化して検証する方法の詳細については、「復号化して検証する」を参照してください。
前提条件
階層キーリングを作成して使用する前に、次の前提条件が満たされていることを確認してください。
-
ユーザーまたはキーストア管理者が、キーストアを作成し、少なくとも 1 つのアクティブなブランチキーを作成しました。
-
キーストアアクションを設定しました。
注記
キーストアアクションの設定方法によって、実行できるオペレーションと、階層キーリングで使用できる KMS キーが決まります。詳細については、「キーストアアクション」を参照してください。
-
キーストアとブランチキーにアクセスして使用するために必要なアクセス AWS KMS 許可があります。詳細については、「必要なアクセス許可」を参照してください。
-
サポートされているキャッシュタイプを確認し、ニーズに最適なキャッシュタイプを設定しました。詳細については、「キャッシュを選択する」を参照してください
必要なアクセス許可
AWS Database Encryption SDK は を必要とせず AWS アカウント 、 に依存しません AWS のサービス。ただし、階層キーリングを使用するには、 AWS アカウント と、キーストアの対称暗号化 AWS KMS key(複数可) に対する以下の最小限のアクセス許可が必要です。
-
階層キーリングを使用してデータを暗号化および復号するには、kms:Decrypt が必要です。
-
ブランチキーを作成してローテーションするには、kms:GenerateDataKeyWithoutPlaintext と kms:ReEncrypt が必要です。
ブランチキーとキーストアへのアクセスの制御の詳細については、「」を参照してください最小特権のアクセス許可の実装。
キャッシュを選択する
階層キーリングは、暗号化および復号オペレーションで使用されるブランチキーマテリアルをローカルにキャッシュ AWS KMS することで、 への呼び出し回数を減らします。階層キーリングを作成する前に、使用するキャッシュのタイプを決定する必要があります。デフォルトのキャッシュを使用するか、ニーズに合わせてキャッシュをカスタマイズできます。
階層キーリングは、次のキャッシュタイプをサポートしています。
デフォルトキャッシュ
ほとんどのユーザーにとって、Default キャッシュはスレッド要件を満たします。Default キャッシュは、高度にマルチスレッド化されている環境をサポートするように設計されています。ブランチキーマテリアルエントリの有効期限が切れると、デフォルトキャッシュは、ブランチキーマテリアルエントリの有効期限が 10 秒前になることを 1 つのスレッドに通知 AWS KMS することで、複数のスレッドが呼び出されるのを防ぎます。これにより、1 つのスレッドのみが にリクエストを送信 AWS KMS してキャッシュを更新します。
デフォルトキャッシュと StormTracking キャッシュは同じスレッドモデルをサポートしますが、デフォルトキャッシュを使用するにはエントリ容量を指定するだけで済みます。より詳細なキャッシュのカスタマイズを行うには、 を使用しますStormTracking キャッシュ。
ローカルキャッシュに保存できるブランチキーマテリアルエントリの数をカスタマイズする場合を除き、階層キーリングを作成するときにキャッシュタイプを指定する必要はありません。キャッシュタイプを指定しない場合、階層キーリングはデフォルトのキャッシュタイプを使用し、エントリ容量を 1000 に設定します。
デフォルトキャッシュをカスタマイズするには、次の値を指定します。
-
エントリキャパシティ: ローカルキャッシュに格納できるブランチキーマテリアルのエントリの数を制限します。
MultiThreadedキャッシュ
MultiThreaded キャッシュは、マルチスレッド環境で安全に使用できますが、 AWS KMS または Amazon DynamoDB 呼び出しを最小限に抑える機能はありません。その結果、ブランチキーマテリアルのエントリの期限が切れると、すべてのスレッドに同時に通知されます。これにより、キャッシュを更新するための複数の AWS KMS 呼び出しが発生する可能性があります。
MultiThreaded キャッシュを使用するには、次の値を指定します。
-
エントリキャパシティ: ローカルキャッシュに格納できるブランチキーマテリアルのエントリの数を制限します。
-
エントリのプルーニングテールのサイズ: エントリキャパシティに達した場合にプルーニングするエントリの数を定義します。
StormTracking キャッシュ
StormTracking キャッシュは、高度にマルチスレッド化されている環境をサポートするように設計されています。ブランチキーマテリアルエントリの有効期限が切れると、StormTracking キャッシュは、ブランチキーマテリアルエントリの有効期限が切れることを 1 つのスレッドに通知 AWS KMS することで、複数のスレッドが を呼び出すのを防ぎます。これにより、1 つのスレッドのみが にリクエストを送信 AWS KMS してキャッシュを更新します。
StormTracking キャッシュを使用するには、次の値を指定します。
-
エントリキャパシティ: ローカルキャッシュに格納できるブランチキーマテリアルのエントリの数を制限します。
デフォルト値: 1000 エントリ
-
エントリのプルーニングテールのサイズ: 一度にプルーニングするブランチキーマテリアルのエントリの数を定義します。
デフォルトの値: 1 個のエントリ
-
猶予期間: 期限が切れる前にブランチキーマテリアルの更新を試行する秒数を定義します。
デフォルト値: 10 秒
-
猶予間隔: ブランチキーマテリアルの更新が試行される間隔の秒数を定義します。
デフォルト値: 1 秒
-
ファンアウト: ブランチキーマテリアルの更新の同時試行が可能な回数を定義します。
デフォルトの値: 20 回の試行
-
処理中の Time To Live (TTL): ブランチキーマテリアルの更新の試行がタイムアウトするまでの秒数を定義します。キャッシュが
GetCacheEntry
に応答してNoSuchEntry
を返すたびに、同じキーがPutCache
エントリを使用して書き込まれるまで、そのブランチキーは処理中であるとみなされます。デフォルト値: 10 秒
-
スリープ:
fanOut
を超えた場合にスレッドがスリープする秒数を定義します。デフォルトの値: 20 ミリ秒
共有キャッシュ
デフォルトでは、階層キーリングは、キーリングをインスタンス化するたびに新しいローカルキャッシュを作成します。ただし、共有キャッシュを使用すると、複数の階層キーリング間でキャッシュを共有できるため、メモリを節約できます。インスタンス化する階層キーリングごとに新しい暗号化マテリアルキャッシュを作成するのではなく、共有キャッシュは 1 つのキャッシュのみをメモリに保存します。このキャッシュは、それを参照するすべての階層キーリングで使用できます。共有キャッシュは、キーリング間での暗号化マテリアルの重複を回避することで、メモリ使用量を最適化するのに役立ちます。代わりに、階層キーリングは同じ基盤となるキャッシュにアクセスできるため、全体的なメモリフットプリントが削減されます。
共有キャッシュを作成する場合でも、キャッシュタイプを定義します。StormTracking キャッシュ キャッシュタイプとして デフォルトキャッシュ、MultiThreadedキャッシュ、または を指定するか、互換性のあるカスタムキャッシュを置き換えることができます。
パーティション
複数の階層キーリングで 1 つの共有キャッシュを使用できます。共有キャッシュを使用して階層キーリングを作成する場合、オプションのパーティション ID を定義できます。パーティション ID は、キャッシュに書き込む階層キーリングを区別します。2 つの階層キーリングが同じパーティション ID、logical key store name、ブランチキー ID を参照している場合、2 つのキーリングはキャッシュ内で同じキャッシュエントリを共有します。同じ共有キャッシュで異なるパーティション IDs を持つ 2 つの階層キーリングを作成すると、各キーリングは共有キャッシュ内の独自の指定されたパーティションからのみキャッシュエントリにアクセスします。パーティションは共有キャッシュ内の論理的な分割として機能し、各階層キーリングが他のパーティションに保存されているデータを妨害することなく、独自の指定されたパーティションで独立して動作できるようにします。
パーティション内のキャッシュエントリを再利用または共有する場合は、独自のパーティション ID を定義する必要があります。パーティション ID を階層キーリングに渡すと、キーリングは、ブランチキーマテリアルを再度取得して再承認するのではなく、共有キャッシュに既に存在するキャッシュエントリを再利用できます。パーティション ID を指定しない場合、階層キーリングをインスタンス化するたびに、一意のパーティション ID がキーリングに自動的に割り当てられます。
次の手順は、デフォルトのキャッシュタイプで共有キャッシュを作成し、階層キーリングに渡す方法を示しています。
-
マテリアルプロバイダーライブラリ
CryptographicMaterialsCache
(MPL) を使用して (CMC) を作成します。 https://github.com/aws/aws-cryptographic-material-providers-library -
共有キャッシュの
CacheType
オブジェクトを作成します。ステップ 1 で
sharedCryptographicMaterialsCache
作成した を新しいCacheType
オブジェクトに渡します。 -
ステップ 2 の
sharedCache
オブジェクトを階層キーリングに渡します。共有キャッシュを使用して階層キーリングを作成する場合、オプションで を定義
partitionID
して、複数の階層キーリング間でキャッシュエントリを共有できます。パーティション ID を指定しない場合、階層キーリングはキーリングに一意のパーティション ID を自動的に割り当てます。注記
同じパーティション ID、、logical key store nameブランチキー ID を参照する 2 つ以上のキーリングを作成すると、階層キーリングは共有キャッシュで同じキャッシュエントリを共有します。複数のキーリングで同じキャッシュエントリを共有しない場合は、階層キーリングごとに一意のパーティション ID を使用する必要があります。
次の例では、 と 600 秒のbranch key ID supplierキャッシュ制限を持つ階層キーリングを作成します。次の階層キーリング設定で定義されている値の詳細については、「」を参照してください階層キーリングを作成する。
階層キーリングを作成する
階層キーリングを作成するには、次の値を指定する必要があります。
-
キーストア名
キーストアとして機能するために作成した DynamoDB テーブルの名前、またはキーストア管理者。
-
キャッシュ制限 Time to Live (TTL)
ローカルキャッシュ内のブランチキーマテリアルエントリを使用できる時間 (期限切れになるまでの時間) (秒)。キャッシュ制限 TTL は、クライアントがブランチキーの使用を許可 AWS KMS するために を呼び出す頻度を決定します。この値はゼロより大きくなければなりません。キャッシュ制限 TTL の有効期限が切れると、エントリは提供されず、ローカルキャッシュから削除されます。
-
ブランチキーの識別子
キーストア内の 1 つのアクティブなブランチキー
branch-key-id
を識別する を静的に設定するか、ブランチキー ID サプライヤーを指定できます。ブランチキー ID サプライヤーでは、暗号化コンテキストに保存されているフィールドを使用して、レコードの復号に必要なブランチキーを決定します。デフォルトでは、パーティションキーとソートキーのみが暗号化コンテキストに含まれます。ただし、
SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT
暗号化アクションを使用して、暗号化コンテキストに追加のフィールドを含めることができます。各テナントに独自のブランチキーがあるマルチテナントデータベースには、ブランチキー ID サプライヤーを使用することを強くお勧めします。ブランチキー ID サプライヤーを使用してブランチキー IDs のわかりやすい名前を作成し、特定のテナントの正しいブランチキー ID を簡単に認識できます。例えば、フレンドリ名を使用すると、ブランチキーを
b3f61619-4d35-48ad-a275-050f87e15122
の代わりにtenant1
として参照できます。復号オペレーションの場合、単一の階層キーリングを静的に設定して復号を単一のテナンシーに制限することも、ブランチキー ID サプライヤーを使用してレコードの復号を担当するテナンシーを識別することもできます。
-
(オプション) キャッシュ
キャッシュタイプまたはローカルキャッシュに格納できるブランチキーマテリアルエントリの数をカスタマイズする場合は、キーリングを初期化する際にキャッシュタイプとエントリキャパシティを指定します。
階層キーリングは、デフォルト、MultiThreaded、StormTracking、共有のキャッシュタイプをサポートします。各キャッシュタイプを定義する方法の詳細と例については、「」を参照してくださいキャッシュを選択する。
キャッシュを指定しない場合、階層キーリングは、自動的に Default キャッシュタイプを使用し、エントリキャパシティを 1,000 に設定します。
-
(オプション) パーティション ID
を指定する場合は共有キャッシュ、オプションでパーティション ID を定義できます。パーティション ID は、キャッシュに書き込む階層キーリングを区別します。パーティション内のキャッシュエントリを再利用または共有する場合は、独自のパーティション ID を定義する必要があります。パーティション ID には任意の文字列を指定できます。パーティション ID を指定しない場合、作成時に一意のパーティション ID がキーリングに自動的に割り当てられます。
詳細については、「Partitions」を参照してください。
注記
同じパーティション ID、、logical key store nameブランチキー ID を参照する 2 つ以上のキーリングを作成すると、階層キーリングは共有キャッシュで同じキャッシュエントリを共有します。複数のキーリングで同じキャッシュエントリを共有しない場合は、階層キーリングごとに一意のパーティション ID を使用する必要があります。
-
(オプション) 許可トークンのリスト
階層キーリング内の KMS キーへのアクセスを許可によって制御する場合は、キーリングを初期化する際に必要なすべての許可トークンを指定する必要があります。
次の例は、静的ブランチキー ID、、デフォルトキャッシュキャッシュ制限 TTL が 600 秒の階層キーリングを作成する方法を示しています。
次の手順は、ブランチキー ID サプライヤーを使用して階層キーリングを作成する方法を示しています。
-
ブランチキー ID サプライヤーを作成する
次の例では、ステップ 1 で作成した 2 つのブランチキーのフレンドリ名を作成し、
CreateDynamoDbEncryptionBranchKeyIdSupplier
を呼び出して AWS Database Encryption SDK for DynamoDB クライアントでブランチキー ID サプライヤーを作成します。 -
階層キーリングを作成する
次の例では、ステップ 1 で作成したブランチキー ID サプライヤー、600 秒のキャッシュ制限 TLL、最大キャッシュサイズ 1000 を使用して階層キーリングを初期化します。
検索可能な暗号化のための階層キーリングの使用
検索可能な暗号化を使用すると、データベース全体を復号することなく、暗号化されたレコードを検索できます。これは、ビーコンを使用して暗号化されたフィールドのプレーンテキストの値にインデックスを付けることで実現されます。検索可能な暗号化を実装するには、階層キーリングを使用する必要があります。
キーストア CreateKey
オペレーションは、ブランチキーとビーコンキーの両方を生成します。ブランチキーは、レコードの暗号化および復号オペレーションで使用されます。ビーコンキーは、ビーコンを生成するために使用されます。
ブランチキーとビーコンキーは、キーストアサービスの作成時に指定した AWS KMS key ものと同じ によって保護されます。CreateKey
オペレーションが AWS KMS を呼び出してブランチキーを生成すると、kms:GenerateDataKeyWithoutPlaintext をもう一度呼び出し、次のリクエストを使用してビーコンキーを生成します。
{ "EncryptionContext": { "branch-key-id" : "
branch-key-id
", "type" :type
, "create-time" : "timestamp
", "logical-key-store-name" : "the logical table name for your key store
", "kms-arn" :the KMS key ARN
, "hierarchy-version" : 1 }, "KeyId": "the KMS key ARN
", "NumberOfBytes": "32" }
両方のキーを生成した後、CreateKey
オペレーションは ddb:TransactWriteItems を呼び出して、ブランチキーとビーコンキーを永続化する 2 つの新しい項目をブランチキーストアに書き込みます。
標準ビーコンを設定すると、 AWS Database Encryption SDK はキーストアにビーコンキーをクエリします。その後、HMAC ベースの extract-and-expand 鍵導出関数 (HKDF
ブランチキーとは異なり、キーストアには ごとに 1 つのビーコンbranch-key-id
キーバージョンしかありません。ビーコンキーがローテーションされることはありません。
ビーコンキーソースの定義
標準ビーコンおよび複合ビーコンのビーコンバージョンを定義する際には、ビーコンキーを識別し、ビーコンキーマテリアルのキャッシュ制限 Time To Live (TTL) を定義する必要があります。ビーコンキーマテリアルは、ブランチキーとは別のローカルキャッシュに格納されます。次のスニペットは、シングルテナンシーデータベースの keySource
を定義する方法を示しています。関連付けられている branch-key-id
によってビーコンキーを識別します。
- マルチテナンシーデータベースでのビーコンソースの定義
-
マルチテナンシーデータベースがある場合は、
keySource
を設定する際に次の値を指定する必要があります。-
keyFieldName
特定のテナンシーについて生成されたビーコンに使用されるビーコンキーに関連付けられた
branch-key-id
を格納するフィールドの名前を定義します。keyFieldName
には任意の文字列を指定できますが、データベース内の他のすべてのフィールドで一意である必要があります。新しいレコードをデータベースに書き込むと、そのレコードについてのビーコンを生成するために使用されるビーコンキーを識別するbranch-key-id
がこのフィールドに格納されます。このフィールドをビーコンクエリに含めて、ビーコンの再計算に必要となる適切なビーコンキーマテリアルを特定する必要があります。詳細については、「マルチテナンシーデータベース内のビーコンのクエリ」を参照してください。 -
cacheTTL
ローカルビーコンキャッシュ内のビーコンキーマテリアルエントリを使用できる時間 (期限切れになるまでの時間) (秒)。この値はゼロより大きくなければなりません。キャッシュ制限 TTL の期限が切れると、エントリはローカルキャッシュから削除されます。
-
(オプション) キャッシュ
キャッシュタイプまたはローカルキャッシュに格納できるブランチキーマテリアルエントリの数をカスタマイズする場合は、キーリングを初期化する際にキャッシュタイプとエントリキャパシティを指定します。
階層キーリングは、デフォルト、MultiThreaded、StormTracking、共有のキャッシュタイプをサポートします。各キャッシュタイプを定義する方法の詳細と例については、「」を参照してくださいキャッシュを選択する。
キャッシュを指定しない場合、階層キーリングは、自動的に Default キャッシュタイプを使用し、エントリキャパシティを 1,000 に設定します。
次の例では、ブランチキー ID サプライヤー、キャッシュ制限 TLL が 600 秒、エントリ容量が 1000 の階層キーリングを作成します。
-