Skip to main content
Rules は、Custom Database Anatomy Best Practices で説明されているように、認証に必要なアーティファクトが生成されるパイプラインの一部として実行されます。そのため、有効になっている Rule は、すべてのログイン処理 (インタラクティブかどうかを問わず) 、すべてのサイレント認証、さらに API 呼び出しのためにユーザー認証情報に関連する が生成されるたびに実行されます。つまり、小規模なデプロイメントであってもパフォーマンスが問題になる可能性があり、デプロイメントの規模が大きくなるほど、その影響はさらに大きくなります。

​
不要な実行を避ける

実行は、条件付きロジックに基づいて実装することを推奨します。たとえば、特定のアプリケーションに対してのみ Rule を実行する場合は、特定の clientID や clientMetadata を確認します。特に、複数のアプリケーションに共通する単一の clientMetadata 値を確認する場合に有効です。clientMetadata を使用すると、新しいクライアントの追加が容易になるほか、Rule コードも読みやすくなります。特に、多数のアプリケーションが定義されている場合は、環境間で必要になるコード変更や設定値を減らせます。 アプリケーションのクライアントメタデータは、 で Application Settings > Advanced Settings > Application Metadata に移動して手動で設定することも、Auth0 の Update a client endpoint を使用してプログラムから設定することもできます。

​
早めに終了する

最適なパフォーマンスを得るには、できるだけ早く処理を完了する Rules を記述してください。たとえば、Rule を実行するかどうかを判断するために 3 つのチェックを行う場合は、最初のチェックで大半のケースを除外し、次に 2 番目に多いケースを除外するチェックを行い、その後も同様に続けます。各チェックの শেষেでは、コールバック関数を必ず実行してください。理想的には、(JavaScript の) return と組み合わせて (Rule の) 関数を終了します。

​
API リクエストを最小限に抑える

API 呼び出し、特にサードパーティ API の呼び出しは、ログインの応答時間を遅くする可能性があります。また、呼び出しのレイテンシーによって Rules のタイムアウトが発生し、最終的に認証エラーにつながることもあります。Rule 内では、可能な限り API リクエストを最小限に抑え、有料サービスへの過剰な呼び出しは避けることを推奨します。また、サードパーティかどうかにかかわらず、API に送信する情報は必要最小限にとどめ、潜在的なセキュリティ リスクを抑えることも推奨します。 global オブジェクトは、API 呼び出しで取得した情報をキャッシュするために使用でき、その情報は後続でパイプライン内のすべての Rules から利用できます。API を繰り返し呼び出すのではなく、情報の保存にはこれを使用することを推奨します。さらに、global オブジェクトは、Rules の実行間でほかの情報をキャッシュするためにも使用できます。

​
有料サービスへの呼び出しを制限する

Twilio 経由で SMS メッセージを送信する場合など、有料サービスを呼び出す Rules がある場合は、それらのサービスは必要な場合にのみ使用するようにしてください。これによりパフォーマンスが向上するだけでなく、不要な追加料金の発生も抑えられます。有料サービスへの呼び出しを減らすには、次の方法があります。
  • 公開サインアップを無効にして、サインアップして有料サービスへの呼び出しを発生させる可能性のあるユーザー数を減らす
  • Rule が、許可された一部のユーザーやその他の適切な条件に対してのみトリガーされるようにする。たとえば、有料サービスへの呼び出しをトリガーする前に、ユーザーのメールアドレスのドメイン、ロール/グループ、サブスクリプションレベルなどを確認するロジックを追加するとよいでしょう。

​
Management API の呼び出しを抑える

Auth0 Management API の呼び出しは、できるだけ避けてください。Auth0 Management API にはレート制限があるため、auth0 オブジェクトを使用する場合でもその点を考慮する必要があります (そのため、使用は必要最小限にとどめてください) 。詳しくは、Management API Endpoint Rate Limitsを参照してください。 また、Management API の関数は処理時間がそれぞれ異なるため、それに応じてレイテンシも異なります。たとえば、Management API の List or Search users endpoint の呼び出しは、回数を最小限に抑え、どうしても必要な場合にのみ実行してください。これは auth0 オブジェクト経由で実行する場合でも同様です。 Rules の context オブジェクトで利用できる接続関連のプロパティを拡張したため、接続情報は Auth0 Management API を呼び出さなくても context オブジェクトから取得できるようになりました。詳しくは、Rules の Context Object Properties を参照してください。 実際の動作を確認するには、Check if user email domain matches configured domain Ruleテンプレートを使用している場合、GitHub の最新バージョンを確認する か、Auth0 Dashboard > Auth Pipeline > Rules に移動して Create を選択してください。注: 今回の変更で機能自体は変わりませんが、これまで Management API の呼び出しに依存していた Rules のパフォーマンスは向上します。 Management API への呼び出し (および適切なアクセストークンを取得するために必要な追加の呼び出し) をなくすことで、Rule コードのパフォーマンスと信頼性が向上します。

​
API 呼び出し時には明示的にタイムアウトを設定する

API を呼び出したり外部サービスにアクセスしたりする場合は、明示的なタイムアウトの設定を検討してください。設定するタイムアウト値は通常、ユースケースによって異なりますが、一般的には、外部サービスのパフォーマンス特性を考慮したうえで、可能な限り短い値を選ぶことを推奨します。 明示的なタイムアウトを使用する場合でも、暗黙的なタイムアウト処理を使用する場合でも、タイムアウト期間の満了によって発生する可能性のあるエラーや例外に常に対処できるようにしてください。詳細については、エラー処理のベストプラクティスを参照してください。

​
Auth0 への呼び出しを減らす

レート制限を超えた場合は、Auth0 への呼び出し回数を減らす必要があります。詳細はユースケースによって異なりますが、以下を推奨します。
  • /.well-known/* のレスポンスをキャッシュする: この情報は頻繁に変わらないため、通常はキャッシュすることで Auth0 への呼び出し回数を減らせます。
  • ユーザー情報を取得するために /userinfo を呼び出す代わりに、id_token をリクエストすることを検討してください。
  • 一括削除や一括ロック解除などの一括呼び出しを減らしてください。

​
詳しく見る