運用上の違い
Private Cloud on Entraの各導入オプションを比較できるよう下の表にまとめました。| 機能 | パブリッククラウド | Azureのプライベートクラウド ベーシック * | Azureのプライベートクラウド パフォーマンス * |
|---|---|---|---|
| テナンシー | マルチ | シングル | シングル |
| 要求毎秒（RPS） | 100 | 100 | 500* RPS （5x） 1500* RPS （15x） |
| サービスレベル契約（SLA） | 99.99% | 99.99% | 99.99% |
| データ所在地 | パブリッククラウド領域のみ | 有 | 有 |
| 開発環境 | 無 | 無 | 1 |
| レベル | RPS |
|---|---|
| ベーシック | 55 |
| パフォーマンス5x | 180 |
| パフォーマンス15x | 600 |
| パフォーマンス30x | 1400 |
| パフォーマンス30xバースト | 1400 |
| パフォーマンス60x | 3000 |
| パフォーマンス60xバースト | 3000 |
| パフォーマンス100x | 5000 |
最大可用性
Auth0の顧客やパートナーは、以下のようなさまざまな拡張ポイントや提供サービスを使用して、Auth0製品の動作を変更し、拡張することができます。高需要アプリ
これらの拡張ポイントを使用することで、顧客やパートナーはカスタムコードを書いて、データベースやAPIのようなサードパーティーシステムと連携したり、データの署名や暗号化などの複雑なロジックを実装したりすることができます。リソース所有者のパスワード
カスタム顧客コードには、拡張性の同時実行制限に関するドキュメントに記載されているいくつかの制限が適用されます。 さらに、カスタム顧客コードはプラットフォーム全体のパフォーマンスにも影響を及ぼします。すべてのカスタムコードは、安全なサンドボックス内で実行する必要があり、このため追加のオーバーヘッドが発生します。これらの拡張ポイントの使用に関して、これまでに見られた最大の問題は以下のとおりです。拡張性
データセンターの場所
Private Cloud on Entraインスタンスのサービスレベル契約（SLA）は99.99%を誇ります。- ルール
- フック
- カスタムアクション
- コード不要のアクション統合
- カスタムデータベース
- カスタムソーシャル接続
- カスタムページテンプレート
- 日本
- オランダ
- ノルウェー
- 南アフリカ
- 韓国
- スウェーデン
- スイス
- アラブ首長国連邦
- 英国
- 米国
バーストトラフィック
アプリケーションで膨大な要求毎秒（RPS）が必要な場合は、Entraのプライベートクラウドの利用を検討します。標準のレート制限の詳細については、「レート制限ポリシー」を参照してください。Private Cloud on Entraの導入では、Private Basicのレート制限は100 RPSで、Private Performanceのレート制限は500 RPSおよび1,500 RPSに拡張されます。アドオンの制限
Private Cloud on Entra Performanceの導入には、開発テスト用の完全に分離され個別に更新されたインスタンスが含まれています。また、運用前環境をさらに追加して、ビジネス要件を満たすことができます。その他の開発環境
RPS（1秒間に処理可能な要求数）やSLAの保証は、非運用環境には適用されません。お客様のオンボーディング要件
Private Cloud on Entraは、以下のリージョンで完全に導入することができます。プロジェクト開始のミーティング
Oktaは、組織が予測するトラフィックに基づいて、また購入したRPSプランに応じて、レート制限を設けています。組織が予想以上の高いトラフィックを経験すると、この計画外の使用が最終的にエンドユーザーに影響を与える可能性があります。提供されているプライベートクラウドは、トランザクションレートの段階的な増加（例：10分間で100 RPSから1000 RPSへの増加）について、サービスへの影響なく対応できるように設計されています。ただし、トラフィックが急激に増加すると（数秒足らずで100 RPSから1000 RPSに増加するなど）、新たに生じた負荷の調整を行う間、サービスが不安定な状態になり、遅延が増加する可能性があります。 Private Cloud on Entraを選択したら、オンボーディングと導入のプロセスが始まり、環境を構成します。制限事項
契約締結後、オンボーディング要件に関する主要な情報をご提出いただき、当社で情報を確認いたします。オンボーディング
負荷テスト
オンボーディング要件を確認し終えたら、プロジェクト開始のためのミーティングを設けて実装プロセスを開始します。このミーティングは契約締結後5日以内に開催するよう強くお勧めします。 オンボーディングフォームを確認次第、お客様の環境のプロビジョニングを開始いたします。ペネトレーションテスト
このプロセスを終了したら、環境移管の準備は完了で、Private Cloud on Entra導入を使用することができます。 Private Cloud on Entra導入は、毎週自動更新されます。必要に応じて、週の特定の日時に設定することができます。 このポリシーは、リクエストの提出者であるPrivate Cloud on Entraご利用者に対して、Auth0が負荷テストを実施するために必要な要件をまとめたものです。負荷テストは、サポートセンターから申請してください。［Issue（問題）］フィールドで、［Private Cloud Support Incident（プライベートクラウドのサポートインシデント）］ を選択します。- 本質的に遅い、または信頼性の低い外部APIへの呼び出しが行われる。
- Auth0 への呼び出しが多すぎる（これにより、より多くのリソースが消費され、Auth0テナントのトラフィックが増加する）。
- 公開されている本番レート制限内に収めてください。
データレジデンシー
承認を申請するには、以下の条件を満たさなければなりません。 インフラストラクチャーへの変更が要求された場合、特定の要件に基づいてコストが決定されます。負荷テスト専用に購入された環境には、いかなるサービスレベル契約も適用されません。そのような環境で報告された問題は、運用環境で生じた問題より優先度が低くなります。
テスト容量に関する考慮事項
| サブスクリプション | 負荷テスト容量 | ランプアップ |
|---|---|---|
| プライベートクラウドパフォーマンス500 RPS（5x） | 325 RPS | 100 RPS/分 |
| プライベートクラウドパフォーマンス1500 RPS（15x） | 975 RPS | 100 RPS/分 |
更新
プライベートクラウドでの負荷テストの詳細については、「環境要求の制限（プライベートクラウドのみ）」を参照してください。 高負荷が予想される期間は、イベント発生14日前に必ずアカウントチームに通知する必要があります。この通知により、シナリオを適切にテストする機会を確保し（可能な場合）、イベントに即したサポートを発生後に行うことができます。 Actions、カスタムWebhook、カスタムデータベースアクションスクリプトを含む一部のAuth0プラットフォームのカスタマイズでは、Auth0プラットフォームから自社サービスへの安全なアウトバウンド接続が可能であり、プライベートクラウドの導入と自社サービスとの間にネットワーク接続を確立することができます。 安全なアウトバウンドネットワークは、Azureアカウント内にエンドポイントサービスを確立する形で、Azure Private Linkを使用します。基盤となるサービスにはAzureネイティブのサービスか、データセンターで実行されるサービスを使用でき、プライベートクラウドの導入と同じAzureリージョン内のAzure Virtual Networkに存在する必要があります。ペネトレーションテスト
プライベートクラウドの導入を構成してエンドポイントサービスが利用可能になった後で、Auth0にエンドポイントサービス情報をご提供いただいたら、当社がサービスを導入と統合し、カスタマイズコードからサービスにアクセスする方法をお知らせします。 Private Linkでエンドポイントサービスを設定する方法の詳細については、Azureにお問い合わせください。Auth0とのサービスオンボーディングを調整するには、Auth0のサポートセンターまでご連絡ください。 セキュリティテストを実施するには、前もってAuth0サポートセンターにお知らせください。遅くともテスト開始予定日の1週間（7日）前にAuth0に通知する必要があります。テストを行う
自社のインフラストラクチャ内で限定的にテストを実施する（つまり、Auth0サービスはテストされない）場合は、Auth0への通知は不要です。 必要とされる情報については、「ペネトレーションテストポリシー」を参照してください。 Auth0が管理する証明書（*.auth0app.comの形式）は、Auth0が取得および適用する責任を負います。Auth0はプロセスをエンドツーエンドで管理し、お客様に必要な対応を求めます。安全なアウトバウンドネットワーク
カスタムドメイン用にAuth0が発行した証明書の更新は、Auth0によって管理されます。証明書の更新プロセス
カスタムドメイン用にお客様が管理する証明書（\*.<CustomerName>.comの形式）の更新は、お客様が管理および取得する責任を負います。