List or Search Usersエンドポイントの代替手段
Management APIのList or Search Usersエンドポイント (GET /users) は、レイテンシーが重視される処理や正確性が求められる処理には適していません。
このエンドポイントは結果整合性モデルを採用しているため、直近の書き込みが検索結果に反映されていない場合があります。また、共有インフラストラクチャ上で短いクエリ制限時間 (約2秒) のもとで実行されるため、大規模なテナントや高負荷時にはクエリが制限時間を超過することがあります。
- List or Search Usersエンドポイントは、認証処理やアカウントのリンク、または即時の整合性が求められる場面では使用しないでください。代わりに、Management APIのエンドポイントでIDまたはメールアドレスによりユーザーを取得してください。
- List or Search Usersエンドポイントは、ユーザーの列挙やエクスポートには使用しないでください。代わりに、ユーザーの一括エクスポートを使用してください。
-
List or Search Usersエンドポイントへのポーリングや、
post-loginアクションなどのログインフローの拡張ポイント内での検索は行わないでください。代わりに、Event Streamsをサブスクライブ (user.created、user.updated、user.deleted) して、外部システムとユーザーデータを継続的に同期してください。
パフォーマンスに関する推奨事項
ユーザー検索のパフォーマンスを向上させるには、次のガイドラインに従ってください。-
デフォルトでは、List or Search Users エンドポイントは決定的な順序で結果を返します。そのため、同じクエリを実行すると、毎回同じ論理順序で結果が得られます。
非決定的な検索のほうが高速です。ユースケース上、決定的な検索が不要な場合は、
primary_order=falseを設定して非決定的な検索を使用してください。 -
スペース文字はエスケープしてください (たとえば、
q=name:John Doeはq=name:John\ Doeと記述します) 。 - 特に大規模なデータセットでは、ワイルドカードの使用を最小限に抑えてください。ワイルドカードを使用する場合は、検索語の先頭ではなく末尾に付けることをお勧めします。
-
自由形式のフィールドや複数値フィールド (
app_metadataやuser_metadataなど) ではなく、インデックス付きの最上位フィールドでフィルタリングや検索を行うことをお勧めします。 -
app_metadataおよびuser_metadataのユーザー定義属性については、次の点に注意してください。- メタデータフィールドは 2 KB 以下に抑えてください。
- メタデータのプロパティには、一貫したデータ型と固定の名前を使用してください。
- スキーマのサイズが大きくなりすぎたり、構造が深くなりすぎたりしないようにしてください。
- 1,000 件を超える結果が返される検索条件は避けてください。
- 存在クエリ (たとえば「値に関係なく、特定のプロパティを持つすべてのユーザーを取得する」など) は避けてください。
制限事項
- クエリに一致するユーザーがそれ以上いる場合でも、検索で返されるユーザーは最大1,000人です。APIを使用する場合、結果が多いときはページ分割されます。
- Auth0のユーザープロファイルには10 KBのサイズ制限があります。
- List or Search Usersエンドポイントでインデックス作成、クエリ、返却ができるユーザーデータには、ユーザーあたり1 MBの制限があります。
- 現在のサイズ制限が導入される前に作成されたユーザープロファイルは、制限サイズを超えている可能性があります。サイズの大きいユーザープロファイルからすべてのユーザー属性を取得するには、IDまたはメールアドレスでユーザーを取得してください。
-
List or Search Usersエンドポイントは、
app_metadataまたはuser_metadataによる並べ替えに対応していません。