Workflowsのシステム制限
Workflowsにはベストプラクティスとシステム制限があり、フローの設計と成功に影響する可能性があります。
- Workflowsのスケールとパフォーマンスについてのガイド
- サポートされるユースケース
- Workflowsプラットフォームの制限
- レイテンシ
- フック
- 自動化
- コネクタービルダー
- Okta API
- Oktaコネクター
- セルのサポート
Workflowsのスケールとパフォーマンスについてのガイド
Okta Workflowsは、IDプロセスを自動化する強力かつ柔軟なプラットフォームです。ライフサイクル管理、データ同期、タスク自動化ユースケースに対応できるように設計、テスト、最適化されていますが、もっと多くのことを行えるように拡張できます。
ここでは、デプロイメントを確実に成功させられるように、一般的なユースケース、重要な原則、フローを構築するときに留意すべき制限について説明します。
Workflowsのエクスペリエンスを向上させるには、次の事項を理解する必要があります。
-
サポートされるユースケース。「サポートされるユースケース」を参照してください。
-
ベストプラクティスと強力なアーキテクチャを使ったフローの構築。「フロー構築のベストプラクティス」を参照してください。
-
システムのハード制限。「Workflowsプラットフォームの制限」を参照してください。
サポートされるユースケース
Workflowsは多くの作業を行えますが、IDに関連する特定のタスクセットを行うために最適化されています。
ユースケース |
テンプレート |
コネクター |
---|---|---|
Okta Workflowsは、中核となるワークフォースアイデンティティーとカスタマーアイデンティティーに関するユースケースのセットに最適化され、テストが行われています。 |
Oktaは、拡大を続けるインポート可能なテンプレートのライブラリを開発、精選しています。Oktaは、テンプレートをリリースする前にテンプレートのレビューとテストを行います。 |
Oktaは、大規模なSaaSコネクターセットを維持しています。これらのコネクターは、ユーザーにわかりやすいノーコードインターフェイスでAPIコールを処理し、組み込みのバックオフや再試行などの最適化機能を備えています。 |
「Okta Workflowsのユースケース」を参照してください。 |
「利用可能なWorkflowsテンプレート」を参照してください。 |
「コネクター」を参照してください。 |
ユースケースは大まかに3つのゾーンに分類できます。
グリーンゾーン |
イエローゾーン |
レッドゾーン |
---|---|---|
これらのユースケースは入念にテストされており、充実したサポートが提供されています。
|
これらのユースケースでは、アーキテクチャとベストプラクティスに十分な注意を払う必要があり、システムの制限や他の警告に陥るリスクが高くなります。サポートはベストエフォートであり、確実な成功のためには専門的なサービスとの連携をお勧めします。
この分野での一般的な課題には次のものがあります。
|
次のようなユースケースは現在サポートされていません。
|
Workflowsプラットフォームの制限
カテゴリー |
タイトル |
制限 |
説明 |
---|---|---|---|
フロー | 組織あたりのアクティブフロー数 | プランによって異なる |
実行可能なアクティブフローの最大数はプランによって異なります。
無効になっているフローは制限にカウントされません。この制限は組織単位で構成できます。「フロー制限」を参照してください。 従来のWorkflowsエンタイトルメント(たとえば、高度なLifecycle Managementのもの)を保有している場合、アクティブな親フローが100までに制限されます。 |
エクスポート先フォルダーのフロー数 |
プランによって異なる |
Export FlowまたはExport Folder関数カードでは、エクスポートできるフローの最大数はWorkflowsのサブスクリプションプランによって異なります。組織で利用できるエクスポートキャパシティは、15分おきにリセットされます。 エクスポートを成功させるには、エクスポートするフローの数が割り当て制限を超えないようにします。これを超過するとエクスポートは失敗し、フローは一切エクスポートされません。 カウントされるフローの総数には、サブフォルダー内のフローが含まれます。 フロー制限は、フォルダーサイドバーから表示する[Export(エクスポート)]ダイアログを使って行うエクスポートには適用されません。 |
|
フローの実行
|
Workflowsインスタンスのメモリ制限 |
100 MB |
実行の一環としてフローに保存されるインスタンス変数の制限。 |
最大一時停止期間 |
30日 |
終了前に人間またはシステムの応答を待機する間、フローを一時停止できる期間。 |
|
フローあたりの最大ステップ数 |
200万 |
1つのフロー内で実行できる最大ステップ数。 |
|
フロー実行のレート制限 |
フローあたり1秒間に10回の呼び出し |
イベントおよびインラインフックの配信は、それぞれレート制限が異なります(次の表を参照)。ただし、APIから直接フローを呼び出す場合、1フローあたり1秒間に10回の呼び出し制限が適用されます。 制限を超過すると、429エラーコードが返されます。 |
|
再帰制限 |
250 |
ヘルパーフローがそれ自体を呼び出すことができる最大回数。この制限を超過したフローには、次のエラーメッセージが返されます:Stack limit exceeded(スタック制限超過)。 |
|
ペイロード制限 | 1 MB |
フロー履歴で単一メッセージが1 MBを超過する場合、そのメッセージは保存されません。出力フィールドのエントリは次のメッセージに置換されます。 データは正常に返されましたが、サイズが大きすぎて表示できません。 メッセージのサイズが制限を超えてもエラーは発生しません。これは、データの処理やフローの最終的な成功には影響しません。 |
|
フローファイル |
添付ファイル |
10 MB |
Gmailコネクター用のSend Email with Attachmentなどのアクションカードで使用される添付ファイルに関する、フロー内のファイルのサイズ制限。 |
ダウンロードとアップロード |
2 GB |
ダウンロードまたはアップロードのアクションカードからの、フロー内でのファイルのサイズ制限、たとえば次のようなもの。
|
|
SFTPファイル転送 |
25 MB |
SFTPコネクターカードを使って転送されるファイルのサイズ制限。 |
|
保持期間 |
Workflowsファイルシステム内にファイルを保存できる最長期間。 |
||
フロー履歴 | データのTime to Live | 30日 | Workflows Designerコンソールに表示されるフロー実行履歴の有効期限。 |
フローテーブル |
テーブル数 |
100 |
1つのOrgで利用できるテーブル数。 この制限はOrganization単位で構成できます。 |
行制限 |
100,000 |
1つのテーブル内での最大行数。 制限に達するとテーブルに行を追加できなくなります。 |
|
列制限 |
256 |
1つのテーブル内での最大列数。 制限に達するとテーブルに列を追加できなくなります。 |
|
セル制限 |
16 KB |
単一のWorkflowsテーブルセルのサイズ制限。 制限を超える入力でテーブルセルを更新しようとすると、エラーが返されます。 |
|
セルの文字制限 |
16,000 |
テーブルセルの文字数制限。 |
|
API
|
タイムアウト - 同期 |
60秒 |
同期フローを呼び出すAPIエンドポイントへの受信HTTP接続の場合は、接続を終了するまでの待機時間。ただし、フロー自体は終了しません。 |
APIエンドポイント |
ファイルペイロードのサイズ |
合計100 MB、パート1つあたり25 MB |
マルチパートのHTTPリクエストでは、ペイロードの最大サイズは100 MBです。各パート(ファイル、テキスト、パスワード、メディアなど)の制限は25 MBです。 |
レイテンシ
Okta Workflowsでは実行レイテンシは保証されません。通常、フローは高速に実行されます。ただし、Workflowsはマルチテナントシステムであるため、レイテンシのSLAがありません。
フローの実行回数は以下に基づきます。
-
フローの複雑さ(組み込みの待機を含む)
-
システムリソースの需要が増加してからOktaがキャパシティを増やすまでのタイムラグ
-
サードパーティAPIによるレイテンシまたはレートの制限
フック
フローのトリガーに使用されるOktaのイベントには制限があります。
フローは完全に非同期的な環境で実行されるため、イベントフックの配信順序またはフローの実行順序は保証されません。単一のユーザーに対して複数のイベントが同時に実行され、イベントが実行されたあとでユーザーの状態が変わっている可能性がある点について考慮することが重要です。
たとえば、ユーザーが誤って非アクティブ化され、その後直ちに再アクティブ化される場合があります。非アクティブ化イベントに応答するフローは再アクティブ化イベントの前か後に実行される可能性があります。そのため、ユーザーは非アクティブ化イベントが実行されたときに非アクティブ化されない場合があります。
イベントフック呼び出しからの遅延は、通常は60分以内に解決されます。イベントフック呼び出しが60分以上遅延している場合は、Oktaサポートに連絡してください。
インフラストラクチャのフェイルオーバーなどの例外的なケースでは、フェイルオーバープロセスが完了するまで参照専用モードでOktaが一部のリクエストを処理する場合があります。その結果、完了できないプロセスに対してイベントが実行される可能性があります。
パスワードインポートインラインフックは、Okta Workflowsが現在サポートしていない具体的な例の1つです。このフックを実行することはできますが、読み取り専用モードであるためパスワードはインポートされません。リスナーは、成功したuser.import.passwordイベントを受信するまでレガシーシステムからユーザーパスワードを削除できません。フックの実行が十分であると想定しないでください。
機能 |
制限の種類 |
制限 |
説明 |
---|---|---|---|
イベントフック |
タイムアウト |
3秒 |
Oktaイベントフックは、完了タイムアウトが3秒で、再試行を1回行います。 エンドポイントが4xx HTTPエラーコードを返した場合、リクエストは再試行されません。 2xxコードはすべて成功とみなされるため、リクエストは再試行されません。外部サービスエンドポイントがリダイレクトで応答した場合、リダイレクトされません。 |
1日あたりのイベント数 |
400,000 |
Oktaは、各orgの24時間以内のイベント数を400,000件に制限しています。orgがこのしきい値に達すると、それ以上のイベントフックはトリガーされなくなります。イベント制限に達する前に(イベント数が280,000に達した時点で)System Logは警告を受信します。イベント制限は、最初のイベントから24時間後にリセットされます。 リクエストが3秒後にタイムアウトすると、イベントフックは1回再試行されます。再試行はorgの制限値にカウントされません。 |
|
orgあたりのイベントフックの最大数。 |
10 |
1つのOrgにつき、最大10個のアクティブなイベントフックを構成できます。複数のイベントタイプを配信するよう各イベントフックを構成できます。 |
|
ペイロードあたりの最大イベントフック数 |
100イベント |
各イベントフックのペイロードで、最大100のイベントをグループ化できます。複数のイベントタイプを配信するよう各イベントフックを構成できます。 |
|
インラインフック |
タイムアウト |
3秒 |
Oktaインラインフックは、完了タイムアウトが3秒で、再試行を1回行います。 エンドポイントが4xx HTTPエラーコードを返した場合、リクエストは再試行されません。 2xxコードはすべて成功とみなされるため、リクエストは再試行されません。外部サービスエンドポイントがリダイレクトで応答した場合、リダイレクトされません。 |
1組織あたりの最大インラインフック数 |
50 |
組織ごとに設定できるインラインフックの最大数は50です。これは、インラインフックタイプの任意の組み合わせの合計です。 |
詳しいガイドラインについては、「イベントフック」と「インラインフック」を参照してください。
自動化
Okta自動化により、Oktaグループに割り当てられているエンドユーザーのライフサイクル中に発生する状況に備えて対処することができます。
カテゴリー |
タイトル |
制限 |
説明 |
---|---|---|---|
自動化 | 1組織あたりの最大自動化数 | 50 |
Orgのアクティブおよび非アクティブな自動化を合計した場合の最大数は50です。 |
自動化1つあたりの最大グループ数 |
10 |
自動化1つあたりの最大グループ数は10です。 |
|
自動化1つあたりの最大ユーザー数 |
100万 |
単一の自動化に適用される、グループメンバーシップの最大合計ユーザー数は、100万を超えることはできません。 複数のグループで自動化を設定すると、グループにユーザーが追加されるたびにユーザー数が増加します。 合計ユーザー数が100万人を超えると、自動化は実行されず、イベントがシステムログに記録されます。 |
その他のガイドラインについては「自動化」を参照してください。
コネクタービルダー
コネクタービルダーは、APIエンドポイントと、認証とブランディングを使用するデータ操作関数が含まれるパッケージを作成します。
カテゴリー |
タイトル |
制限 |
説明 |
---|---|---|---|
提出
|
orgあたりのテストデプロイメントの最大数 | 1日に100 |
すべてのコネクターのテストデプロイメントの最大数が1日に100です。 |
Okta API
Okta APIには、すべてのWorkflowsアクションに適用される特定のレート制限があります。これらのレート制限はエンドポイントと価格プランによって異なりますが、Workflowsアクションと外部アプリのアクションの両方に適用されます。詳細については、「レート制限」を参照してください。
Okta APIを使用するカスタム統合を利用しているが、新たにWorkflowsの開発も試している場合、Oktaのレート制限を超過してしまう可能性があります。この場合、どちらのアクティビティも中断されてしまいます。このシナリオを回避するために、新規フローの開発はプレビュー環境内で行ってください。中断が生じたときは、60秒後にレート制限がリセットされるまで新規フローを一時停止してください。
Oktaコネクター
Workflows内のOktaコネクターは、Okta APIを介して通信します。ただし、この内蔵コネクターのレート制限は、Okta APIの通常の制限とは若干異なります。
Category(カテゴリ) |
タイトル |
制限 |
説明 |
---|---|---|---|
APIリクエスト - 同時並行処理
|
WorkflowsからOkta org |
30 |
全エンドポイントを対象とする、WorkflowsからOkta orgへの同時並行処理リクエストの最大数。 |
特定ユーザーのGETまたはREADリクエスト |
15 |
Workflowsから/api/v1/users/${id}エンドポイントへの同時並行処理リクエストの最大数。 この制限は、同時並行処理Workflowsリクエスト制限にカウントされません。 |
|
APIリクエスト - 合計 |
WorkflowsからOkta org |
1分間に6000 |
全エンドポイントを対象に、WorkflowsからOkta orgに対して行われる全リクエストの最大数。 |
Okta APIへの接続で[Authenticate with API Connector cards(APIコネクターカードを使った認証)]を選択している場合は、標準のOkta APIレート制限が適用されます。「レート制限」を参照してください。
内蔵のOktaコネクターには標準のレート制限が適用されないため、Workflowsがこのコネクターを介して行うリクエストはレート制限ダッシュボードに表示されません。
レート制限の修復
すでに購入済みの製品サブスクリプションのデフォルトのレート制限ではニーズを満たせなくなった場合は、DynamicScaleアドオンサービスを購入できます。このアドオンは、本番テナント用には年単位、サンドボックステナント内のテスト用には一時的に購入できます。「DynamicScaleレート制限」を参照してください。
さらに、2021年1月7日より後に作成されたOkta Workforce orgでは、デフォルトのレート制限が引き上げられました。「Workforce乗数レート制限」を参照してください。
環境でDynamicScaleまたはWorkforce乗数を利用している場合、Oktaコネクターの制限は次のように変更されます。
Category(カテゴリ) |
タイトル |
制限 |
説明 |
---|---|---|---|
APIリクエスト - 同時並行処理
|
WorkflowsからOkta org |
プランによって異なる |
全エンドポイントを対象とする、WorkflowsからOkta orgへの同時並行処理リクエストの最大数。
|
特定ユーザーのGETまたはREADリクエスト |
プランによって異なる |
Workflowsから/api/v1/users/${id}エンドポイントへの同時並行処理リクエストの最大数。
この制限は、同時並行処理Workflowsリクエスト制限にカウントされません。 |
セルのサポート
Okta Workflowsは、北米、EU、アジア太平洋/日本(APJ)の本番およびプレビューセルで利用できます。
フローで次のいずれかを送信または保存する場合は、Okta Regulated Moderate Cloudを購入し、Oktaのビジネスアソシエイト契約(BAA)を締結する必要があります。
-
保護された健康情報
-
個人の健康データ
-
医療保険の相互運用性と説明責任に関する法律(HIPAA)の対象となるその他の機密データ
セルに関係なく、Okta WorkflowsはOktaのFedRAMP承認パッケージの対象外となります。