Workflowsのシステム制限
Workflowsにはベストプラクティスとシステム制限があり、フローの設計と成功に影響する可能性があります。
Workflowsのスケールとパフォーマンスについてのガイド
Okta Workflowsは、ID認証プロセスを自動化するための強力で柔軟なプラットフォームです。増加するライフサイクル管理、データ同期、タスク自動化のユースケースのセットに合わせて設計、テスト、最適化されており、対応範囲はさらに増え続けており、拡張によってさらに多くの用途に適合できます。
このセクションでは、一般的なユースケース、フローを構築するときに留意すべき重要な原則と制限、および正しいデプロイを保証する方法について解説します。
Workflowsを最適に使用するには、次のタスクを行ってください。
-
サポートされているユースケースを理解する。サポートされるユースケースを参照してください。
-
ベストプラクティスと強力なアーキテクチャを使用してフローを構築する。 フロー構築のベストプラクティスを参照してください。
-
システムのハード制限について理解する。Workflowsプラットフォームの制限を参照してください。
サポートされるユースケース
Workflowsは多くの作業を行えますが、IDに関連する特定のタスクセットを行うために最適化されています。これらは、当社のヘルプセンターと、Workflows内の両方に、各種のリソースを使用してドキュメント化されています。
ユースケース | テンプレート | コネクタ |
---|---|---|
Workflowsは、中核となる従業員のIDと顧客のIDに関するユースケースのセットに最適化され、テストが行われています。 Okta Workflowsのユースケースのユースケースを参照してください。 | Oktaはインポート可能なテンプレートのライブラリーを開発し、精選しており、このライブラリーは拡大が続けられています。これらはリリースの前にOktaによるレビューを受けます。 利用可能なWorkflows Templatesを参照してください。 | Oktaは多数のネイティブSaaSコネクターのセットを保守しており、これには簡単なAPI接続、使い勝手とドキュメンテーションの改善、およびバックオフと再試行機能の内蔵などの最適化が含まれています。 コネクタを参照してください。 |
ユースケースは大まかにゾーンに分類できます。
グリーンゾーン | イエローゾーン | レッドゾーン |
これらのユースケースは入念にテストされており、充実したサポートが提供されています。
| これらのユースケースでは、アーキテクチャとベストプラクティスに十分な注意を払う必要があり、システムの制限や他の警告に陥るリスクが高くなります。サポートはベストエフォートであり、確実な成功のためには専門的なサービスとの連携をお勧めします。
この分野での一般的な課題には次のものがあります。
| 次のようなユースケースは現在サポートされていません。
|
Workflowsプラットフォームの制限
カテゴリ | 制限のタイトル | 制限 | 説明 |
フロー
| 組織あたりのアクティブフロー数 | プランによって異なります | 管理者は、これらのティアーに従って最大数のアクティブフローを実行できます。
無効になっているフローは制限にカウントされません。この制限は組織単位で構成できます。フロー制限を参照してください。 従来のWorkflowsエンタイトルメント(たとえば、高度なライフサイクル管理のもの)を保有している場合、アクティブな親フローが100までに制限されます。 |
エクスポート先フォルダーのフロー数 | 400 | フォルダーに配置できるフロー数に制限はありません。ただし、フォルダーのエクスポートを成功させるには、フロー数をこの制限未満にする必要があります。 | |
フローの実行 | Workflowsインスタンスのメモリ制限 | 100MB | 実行の一環としてフローに保存されるインスタンス変数の制限。 |
最大一時停止期間 | 30日 | 終了前に人間またはシステムの応答を待機する間、フローを一時停止できる期間。 | |
フローあたりの最大ステップ数 | 200万 | 1つのフロー内で実行できる最大ステップ数。 | |
フロー実行のレート制限 | フローあたり1秒間に10回の呼び出し | イベントとインラインフックの配信で制限が異なります(以下を参照)。ただし、APIから直接フローを呼び出す場合、1フローあたり1秒間に10回の呼び出し制限が適用されます。この制限を超えると、429応答コードが発生します。 | |
ペイロード制限 | 1MB | フロー履歴でサイズが1MBを超えたメッセージは保存されません。出力フィールドのエントリーは次のメッセージに置換されます。 データは正常に返されましたが、サイズが大きすぎて表示できません。 ![]() メッセージのサイズが制限を超えてもエラーは発生しません。フローの成功には影響がなく、データは引き続き想定どおりに処理されます。 | |
フローファイル
| 添付ファイル | 10MB | Gmailコネクタ用の「添付ファイル付きメールの送信」などのアクションカードで使用される添付ファイルに関する、フロー内のファイルのサイズ制限。 |
ダウンロードとアップロード | 2GB | ダウンロードまたはアップロードのアクションカードからの、フロー内でのファイルのサイズ制限、たとえば次のようなもの。
| |
保持期間 | 30日 | Workflowsファイルシステム内にファイルを保存できる最長期間。 | |
フロー履歴 | データのTime to Live | 30日 | Workflows Designerコンソールに表示されるフロー実行履歴の有効期限。 |
フローテーブル | テーブル数 | 100 | 1つの組織で利用できるテーブル数。 この制限は組織単位で構成できます。 |
行制限 | 100,000 | 1つのテーブル内での最大行数。 制限に達するとテーブルに行を追加できなくなります。 | |
列制限 | 256 | 1つのテーブル内での最大列数。 制限に達するとテーブルに列を追加できなくなります。 | |
セル制限 | 16KB | 単一のWorkflowsテーブルセルのサイズ制限。 テーブルセルを更新し、入力がこの制限より大きい場合、エラーが返されます。 | |
API | タイムアウト | 60秒 | APIエンドポイントへの受信HTTP接続が同期フローを呼び出す場合、この時間内に応答がないと接続を終了します。ただし、フロー自体は終了しません。 |
APIエンドポイント | ファイルペイロードのサイズ | 合計100MB、パート1つあたり25MB | HTTPマルチパートリクエストの場合、最大ペイロードサイズは100MBです。各パート(ファイル、テキスト、パスワード、メディアなど)の制限は25MBです。 |
レイテンシ
Workflowsでは実行レイテンシが保証されません。大半のケースで、フローは非常に高速で実行されます。ただし、Workflowsはマルチテナントシステムであるため、レイテンシのSLAがありません。
フローの実行時間はさまざまな理由により変動します。
-
フローの複雑さ(組み込みの待機を含む)
-
システムリソースの需要が増加してから、Oktaが容量を増やすまでの遅延
-
サードパーティAPIによるレイテンシまたはレートの制限
特定のレイテンシは保証できないため、トークンへの情報付加や承認決定のカスタマイズなど、実行時間がシナリオにとって非常に重要なフローではWorkflowsを使用しないでください。
フック
フローのトリガーに使用されるOktaのイベントには制限があります。
イベントフックの配信とフロー実行順序は、いずれも保証されません。完全に非同期的な環境です。単一のユーザーに対して複数のイベントが同時に実行され、イベントが実行されたあとでユーザーの状態が変わっている可能性がある点について考慮することが重要です。たとえば、ユーザーが誤って非アクティブ化された直後に再アクティブ化される場合があります。非アクティブ化イベントに応答するフローは、再アクティブ化イベントの前と後のどちらにも実行される可能性があります。同様に、非アクティブ化フローが実行される時点で、ユーザーが非アクティブでない場合もあります。
より複雑な考慮事項がいくつかあります。インフラストラクチャのフェールオーバーなどの例外的なケースでは、フェールオーバーが完了するまで読み取り専用モードでOktaが一部のリクエストを処理する場合があります。つまり、完了できないプロセスに対してイベントが実行される場合があるということです。ワークフロー製品で現在サポートされていないパスワードインポートインラインフックもこの好例の1つです。このフックを実行することはできますが、読み取り専用モードであるためパスワードはインポートされません。リスナーは、user.import.password
イベントの成功が確認できるまでレガシーシステムからユーザーパスワードを削除せず、フックの実行が十分であるとみなさないようにする必要があります。
機能 | 制限の種類 | 制限 | 説明 |
イベントフック | タイムアウト | 3秒 | Oktaのイベントフックでは、1回の再試行における完了タイムアウトが3秒になっています。 エンドポイントが4xx HTTPエラーコードを返した場合、リクエストは再試行されません。 2xxコードはすべて成功とみなされるため、リクエストは再試行されません。外部サービスエンドポイントがリダイレクトで応答した場合、リダイレクトされません。 |
1日あたりのイベントフック数 | 200,000 | 1つの組織につき、1日に最大20万のイベントフックを起動できます。制限を超えたイベントフックは記録されず、再実行されることもありません。1日あたりの制限を超えると、特定の回数制限までWorkflowsのイベントフックが再試行されます。 | |
1組織あたりの最大イベントフック数 | 10 | 1つの組織につき、最大10個のアクティブなイベントフックを構成できます。複数のイベントタイプを配信するよう各イベントフックを構成できます。 | |
| ペイロードあたりの最大イベントフック数 | 100イベント | 各イベントフックのペイロードで、最大100のイベントをグループ化できます。複数のイベントタイプを配信するよう各イベントフックを構成できます。 |
その他のガイドラインについては、イベントフックを参照してください。
自動化
Oktaに自動化では、Oktaグループに割り当てられているエンドユーザーのライフサイクル中に発生する状況に備えて対処することができます。
カテゴリ | 制限のタイトル | 制限 | 説明 |
自動化
| 1組織あたりの最大自動化数 | 50 | 組織のアクティブおよび非アクティブな自動化を合計した場合の最大数は50です。 |
自動化1つあたりの最大グループ数 | 10 | 自動化1つあたりの最大グループ数は10です。 | |
自動化1つあたりの最大ユーザー数 | 100万 | 単一の自動化に適用される、グループメンバーシップの最大合計ユーザー数は、100万を超えることはできません。 複数のグループで自動化を設定すると、グループにユーザーが追加されるたびにユーザー数が増加します。 合計ユーザー数が100万人を超えると、自動化は実行されず、イベントがシステムログに記録されます。 |
その他のガイドラインについては自動化を参照してください。
Okta API
Okta APIには、Workflowsが実行するすべてのアクションに適用される、特定の組織単位のレート制限があります。これらのレート制限はエンドポイントと価格プランによって異なりますが、Workflowsアクションと外部アプリのアクション両方に適用されます。詳細については、「レート制限」を参照してください。
Okta APIを使ったカスタム統合があり、新しいWorkflowsデプロイメントでテストも行っている場合、Oktaのレート制限を超過し、両方のアクティビティが停止することがあります。このような問題を避けるため、プレビュー環境で新しいフローを開発することをおすすめします。停止が発生した場合は、次の 1 分間がレート制限に引っかからなくなるまで、新しいフローをすべて一時停止します。
セルのサポート
Workflowsは北米、EU、アジア太平洋/日本(APJ)の本番セルとプレビューセルで利用できます。
Okta WorkflowsはOkta事業提携契約(BAA)(該当する場合)の対象外で、サービスサポートの場所の要件、データのローカリゼーション、適用される他のすべてのHIPAA標準のいずれも満たしていません。また、Okta WorkflowsはOktaのFedRamp承認パッケージでも対象外となります。