機密台帳の制限をAzureする

Azure機密台帳では、すべての台帳のパフォーマンスと可用性を予測可能に保つために、サブスクリプション内の台帳の数と、台帳に格納されるデータとコードの数が制限されます。 この記事では、これらの制限、要求が要求を超えたときの台帳の応答方法、および台帳に期待されるパフォーマンスについて説明します。

Note

この記事の制限は既定値です。 場合によっては、個々の台帳に異なる制限を設定できます。たとえば、制限が導入される前に作成された台帳などです。 より高い制限を要求したり、制限事項について話し合ったりするには、Azure サポートにお問い合わせください。

サブスクリプションの制限

次の制限は、各Azure サブスクリプションに適用されます。

Limit Value
サブスクリプションあたりの台帳 2

台帳データの制限

既定では、すべての台帳に次の制限が適用されます。

Limit 既定値 エラー コード
台帳あたりのコレクション数 5,000 CollectionCapacityExceeded
コレクション ID の長さ 256 バイト CollectionIdTooLong
台帳エントリの内容のサイズ 8 KiB (8,192 バイト) EntrySizeCapacityExceeded
台帳ごとのタグ (パブリック台帳のみ) 10,000 TagCapacityExceeded
  • 台帳ごとのコレクション: 既定のコレクションはカウントされません。 台帳が上限に達すると、新しいコレクションを作成する書き込みが拒否されます。 既存のコレクションへの書き込みは引き続き成功します。
  • コレクション ID の長さ: 長さは、URL デコード後に UTF-8 でエンコードされた ID のバイト単位で測定されます。 この制限は、書き込みによって新しいコレクションが作成される場合にのみ適用されるため、この制限が導入される前に作成されたコレクションへの書き込みとコレクションからの読み取りを維持できます。
  • 台帳エントリの内容のサイズ: サイズは、JSON デコード後に UTF-8 でエンコードされた contents 値のバイト単位で測定されます。 正確に 8,192 バイトの内容が受け入れられます。 この制限は、新規コレクションと既存のコレクションの両方への書き込みに適用されます。 要求のコレクション ID、タグ、およびその他のフィールドは、この制限にカウントされません。 要求全体も、台帳の最大要求本文サイズの対象となります。
  • 台帳ごとのタグ: タグは、それを使用するコレクションごとに 1 回カウントされます。 たとえば、2 つのコレクションで使用 chocolate タグは 2 つのタグとしてカウントされます。 台帳が制限に達すると、コレクションに新しいタグを追加する書き込みが拒否されます。 タグのない書き込み、またはコレクションで既に使用されているタグを使用した書き込みは引き続き成功します。

制限を超える書き込みは HTTP 状態コード 400 (無効な要求) で拒否され、要求内の何も台帳に書き込まれます。 応答には、エラー コードと、台帳に適用される制限を含むメッセージが含まれています。 例えば次が挙げられます。

{
  "error": {
    "code": "EntrySizeCapacityExceeded",
    "message": "Entry contents of 9000 bytes exceed the limit of 8192 bytes."
  }
}

書き込みあたりのタグ制限

タグは、パブリック台帳でのみサポートされます。 次の制限は、すべてのパブリック台帳に適用されます。

Limit Value
書き込みあたりのタグ数 5
タグの長さ 63 文字

タグは空にすることはできません。また、 A-Z、 a–z、 0–9、 -、 _、 .、 ~の文字のみを含めることができます。 これらの制限を超える書き込み、または無効なタグを含む書き込みは、HTTP 状態コード 400 と NotAllowed エラー コードで拒否されます。

ユーザー定義関数の制限

次の制限は、すべての台帳のユーザー定義関数 (UDF) に適用されます。 要求を超える要求は、HTTP 状態コード 400 で拒否されます。

Limit Value エラー コード
台帳あたりの UDF 数 100 UserDefinedFunctionCapacityExceeded
UDF ID の長さ 256 バイト InvalidFunctionId
UDF コード サイズ 64 KiB (65,536 バイト) InvalidInput
書き込みあたりの事前フック数 5 InvalidInput
書き込みあたりのポストフック数 5 InvalidInput

UDF の数と ID の長さの制限は、UDF を作成する場合にのみ適用されます。 既存の UDF のコードが 64 KiB 内に収まる場合は、引き続き更新できます。

UDF の実行時に適用されるランタイム オプションについては、「UDF の 実行」を参照してください。 プリフックとポストフックの詳細については、「 トランザクションフック」を参照してください。

ユーザー定義のエンドポイント ランタイム オプション

PATCH /app/userDefinedEndpoints/runtimeOptionsで設定する値は、次の範囲内である必要があります。 それ以外の場合、要求は HTTP 状態コード 400 と InvalidInput エラー コードで拒否されます。 要求が変更された値を持つオプションのみがチェックされます。

ランタイム オプション 許可される値
max_heap_bytes 最大 209,715,200 (200 MiB)
max_stack_bytes 1 ~ 10,485,760 (10 MiB)
max_execution_time_ms 最大 10,000 (10 秒)
max_cached_interpreters 1 ~ 20

Performance

台帳のパフォーマンスは、エントリのサイズ、同時に送信する要求の数、読み取りと書き込みの組み合わせなど、ワークロードによって異なります。 次のガイダンスでは、何を期待するかについての一般的な考え方を示します。 これは保証ではありません。

スループット

  • 台帳は、1 秒あたり何百もの書き込みを維持できます。 エントリが小さくなり、同時要求が多いほど、レートが上がります。 関数のコードによっては、ユーザー定義関数を実行する書き込みに時間がかかります。
  • コレクションの最新のエントリを読み取る場合、書き込みよりも使用されるリソースが少ないため、台帳は通常、これらの要求の多くを処理できます。 台帳が最初にストレージからデータを読み込むため、トランザクション ID によるエントリの取得、受信確認、および範囲クエリでは、最新のエントリの読み取りよりも多くのリソースが使用されます。 これらの要求のレートが高い場合、書き込みに残っているスループットが低下します。
  • 次の要求を送信する前に各応答を待機するクライアントは、台帳へのラウンドトリップ時間によって制限されます。 台帳を最大限に活用するには、要求を同時に送信し、接続を再利用します。

ワークロードで継続的な高スループットが必要な場合は、運用環境に移行する前に台帳でテストします。 より多くのスループットが必要な場合は、Azure サポートにお問い合わせください。

Latency

  • 既定では、書き込み要求は、台帳が書き込みを受け入れ、その直後に書き込みをコミットするとすぐに返されます。 たとえば、書き込みに頼ってレシートを取得する前に、その状態が Committedされていることを確認します。 クライアント ライブラリは、コミットを待つことができます。
  • トランザクション ID でエントリを取得し、レシートを取得し、範囲クエリは最初に Loading 返すことができますが、台帳はデータを読み込みます。 結果が返されるまで 1 分以内に要求を繰り返します。
  • 待機時間は、距離と負荷にも依存します。 新しい各接続には台帳との TLS ハンドシェイクが必要であるため、接続を再利用し、台帳のリージョンの近くでクライアントを実行します。 台帳の負荷が維持可能な時間に近づくにつれて、待機時間が長くなることが予想されます。

関連するコンテンツ

  • 最終更新: