アクセス要求の舞台裏：ワーカータスク | Okta
バックグラウンド
Oktaの受信トレイプラットフォームは、OktaのWorkforce Identity Cloudに含まれるさまざまな製品をサポートし、そこでは人間の入力が必要とされます。Okta Identity Governanceのアクセス要求のフローでは、特に大きな役割を果たします。
Oktaが提供する機能の多くは、トリガーに基づいて動作します。こうしたトリガーとなるものは、場合によっては人間のアクション（たとえば、マネージャーが承認したらアクセス権を付与する）、場合によってはタイムイベント（たとえば、24時間後にアクセス権を取り消す）です。ここでは、Google Pub/SubやGoogle Cloud Tasksなどのメッセージブローカーで非同期タスクを活用し、トリガーに基づいてアクションを実行する方法について説明します。
ワーカータスク
Okta社内では、すべての非同期タスクを「ワーカータスク」と呼んでいます。タスクを作成して実行するためのインターフェイスを公開する内部フレームワークを使用して、タスクがどのメッセージブローカーに送信されるかの詳細を抽象化します。
タスクは、ワーカータスクのフレームワーク内で実行する必要がある関数であり、実行方法を指示するメタデータとともに使用します。概念的には、次に示すように、ライフサイクルと実行を決定するプロパティの集合がタスクです。
ほとんどのメタデータは自明です。パブリッシャーからサブスクライバーへタスクをルーティングするキューサービスは、ドライバーが定義します。上記の例では、GCP Pub/Subで「fast_queue」を使用しています。
注：Google Cloud Tasksを使用しているのは、タスクの実行を遅らせる機能が組み込まれているためです。その他の点では、Google Cloud Tasksの設定はGoogle Pub/Subと類似しています。以下ではGoogle Pub/Subに焦点を当てますが、Google Cloud Tasksにも同様の原則が当てはまります。
キューの設定
ここでのPub/Subは、さまざまなタスクを処理対象とします。トラフィックの特性、優先度、ワークロードのドメインに基づいてワークロードをセグメント化できるように、複数のGCP Pub/Subキューを設定しています。これは、以下を目的としています。
- 優先度の高いタスクの実行を加速する。
- あるドメインのタスク処理でのバックログが、別のドメインのタスクに影響しないようにする。
このような設定により、タスクの優先度に応じて選択的にスケーリングできます。トラフィックの多い状況では、サブスクライバーを簡単にスケーリングして重要タスクを処理し、プラットフォームの安定した状態を確保できます。それとともに、既存の数の通知サブスクライバーが通知を処理できるようにするため、通知に若干の遅延が生じます。
フローの制御
上記の例では、キューの設定によって、状況に応じてスケーリングし、遅延を許容する方法を確認しました。実際には、スケーリングを行わないと、サブスクライバーはタスクの増加に対応できなくなり、クラッシュする可能性があります。これを解決するために、さまざまなステップでフローの制御を使用します。キューの構成には、一度に配信できる保留中のメッセージの最大数が指定されます。この設定により、サブスクライバーは受信タスクのフローを管理することで、トラフィックバーストを適切に処理できます。
残念ながら、サブスクライバーが処理できるタスクの最適な数を具体的に確定するのは困難です。タスクの数以外にも、特定のタスクの複雑さなどの要因が負荷に影響を与える可能性があります。したがって、確実な対策として、CPUやメモリなどのリソースが特定のしきい値を超えると、サブスクライバーはそれ以上のタスクの受け入れを強制的に停止します。このような場合、Pub/Subは指数関数的に再試行します。これは洗練された方法ではありませんが、サブスクライバーをクラッシュさせたり、アクティブなサブスクライバーの数を増やしたりすることなく、可能な限り多くのタスクを効果的に処理できます。
トレードオフ
他のシステムと同様に、このアーキテクチャにもトレードオフがあります。Oktaがお客様に選ばれているのは、信頼できる中立的なベンダーだからです。非同期タスクのインフラストラクチャは、以下の特性を持つことが期待されます。
+ 拡張性
フレームワークは拡張性に優れています。ドライバーを追加することで、RabbitMQ、AWS SQSなどの新しいキューサービスを追加し、すべてのタスクと新しいサービスの互換性を実現できます。
+ 信頼性
信頼性を念頭に置いて設計された中央フレームワークにより、システムに追加された新しい種類のすべてのタスクが、タスク開発者が介入することなく、デフォルトで障害、ダッシュボードレポート、異常検出に関するアラートを受け取るようになります。
+ きめ細かなスケーラビリティ
優先順位とドメインに基づいてタスクをキューに整理することで、遅延のパターンを特定し、スケーリングが必要なサブスクライバについて情報に基づいた決定を下すことができる。 このプロセスにより、ユーザーはローディング画面とにらめっこすることから解放され、同時にインフラへの支出を抑えることができる。
- 失敗したタスクの再試行
Oktaのシステムでは、多くのタスクに副作用があり、べき等ではありません。そのようなタスクは、障害が発生した場合に回復するのが困難です。二重の副作用があるというリスクを負っているのです。現在、このフレームワークには、これらのタスクを回復または再試行する方法がありません。
次のステップは？
現在の非同期タスクの設定は、現在の規模とインフラストラクチャのニーズに合わせて機能するものです。将来的には、Google Cloud Functionsの使用を検討しています。それにより、フローの制御を考慮する必要がなくなります。Google Cloud Functionsは、処理するタスクの数に応じてスケーリングできます。
また、副作用を伴うタスクの「1回限り」の実行に関して信頼性を高めることも、今後の改善点として挙げられます。たとえば、メールの送信には、タスク実行全体を通してべき等のベンダーAPIやきめ細かなチェックポイントを使用する必要があります。現在のアーキテクチャは、これらの改善を実現するための優れた基盤を提供します。
このブログ記事についてのご質問は、[email protected]までご連絡ください。
知識を深めるため、Oktaの洞察力に富んだエンジニアリングブログをご利用ください。
Oktaの情熱的で優秀なエンジニアチームで働きませんか？採用情報ページをご覧ください
現代的で洗練されたアイデンティティ管理の可能性をあなたの組織で解き放ちましょう セールス担当者に問い合わせる
