HTTP タスクは HTTP または HTTPS プロトコル上で実行されるため、MSE XXL-JOB は、ソフトウェア開発キット (SDK) を統合することなく、あらゆるプラットフォーム上のあらゆる言語で記述されたワークロードをスケジューリングできます。ワークロードが実行される場所に応じて、MSE XXL-JOB は Kubernetes Service またはゲートウェイを介してターゲットサービスにアクセスします。
HTTP タスクを使用する理由
ワークロードを HTTP タスクとしてスケジューリングする理由はいくつかあります：
既存のワークロード — 既存のサービスを修正することなく接続できます。
多言語対応 — さまざまな言語で実装されたタスクに対して、1 つの接続方式を使用できます。
AI エージェントとワークフロー — AI エージェントとワークフローのタスクを HTTP 経由でスケジューリングできます。
HTTP タスクの接続方式
MSE XXL-JOB は、HTTP タスク用に 2 つの接続方式をサポートしています。この方式によって、MSE XXL-JOB のスケジューリングセンターが個々のバックエンドインスタンスに直接アドレス指定するか、ルーティングをゲートウェイに委任するかが決まります。
Kubernetes 環境 — Kubernetes クラスター内の Service をアプリケーションにバインドします。ワークロードのスケーリングに伴ってインスタンスが変更されるコンテナ化されたサービスには、この方式を選択します。
非 Kubernetes 環境 — HTTP ドメイン名をアプリケーションにバインドし、ゲートウェイを介してサービスにアクセスします。Kubernetes の外部で実行されるサービスや、既存のゲートウェイシステム配下で実行されるサービスには、この方式を選択します。
接続方式はアプリケーションレベルで選択するため、アプリケーション内のすべてのタスクで共有されます。アプリケーションとタスクを作成する前に、以下の比較をご確認ください。
接続方式の比較
次の表は、HTTP タスクの 2 つの接続方式を比較したものです。
| 比較項目 | Kubernetes 環境：Service を介した接続 | 非 Kubernetes 環境：ゲートウェイを介した接続 |
| 接続モード | Kubernetes Service に基づいてバックエンド Pod に直接アクセスします。 | 統一されたゲートウェイを介してリクエストをプロキシし、ターゲットのドメイン名サービスに転送します。 |
| サービスディスカバリーのメカニズム | エンドポイントの変更を常に監視し、Pod リストを動的に維持します。 | サービスディスカバリーをサポートせず、バックエンドノードのステータスを認識できません。 |
| 実行ターゲットの粒度 | 特定の Pod の IP アドレスとポートにタスクをスケジューリングして、ポイントツーポイントの直接呼び出しを実現できます。 | リクエストはゲートウェイに送信され、ゲートウェイが内部の負荷分散とインスタンスルーティングを完了します。スケジューリングセンターは、実際のバックエンドノードを認識できません。 |
| ルーティングポリシー | 単一インスタンスのルーティングポリシーと ブロードキャストシャーディング をサポートします。 | ルーティングポリシーをサポートせず、ゲートウェイのルーティングポリシーを使用します。 |
| ブロードキャストシャーディング | ブロードキャストシャーディングモードをネイティブにサポートしており、大規模な並列バッチ処理シナリオに適しています。 | ブロードキャストシャーディングをサポートしていません。すべてのタスクは単一のポイントで実行され、ノード間の協調処理は実装できません。 |
| ヘルスステータス管理 | エンドポイントのステータスをリアルタイムで同期し、準備ができていない、またはすでに終了した Pod を自動的に削除します。 | ドメイン名の可用性を手動で維持する必要があります。 |
| 拡張性と柔軟性 | クラウドネイティブ環境に適応し、伸縮自在なスケーリングやローリングデプロイなどのシナリオをサポートします。 | 従来のアーキテクチャや異種システムの統合により適しています。強力な互換性を提供し、既存のゲートウェイシステムに簡単に接続できます。 |
| 一般的なシナリオ | コンテナ化されたマイクロサービス、シャーディングされたバッチジョブの実行、および高同時実行性が求められるスケジュールタスク。 | 非コンテナ環境、ハイブリッドデプロイメントアーキテクチャ、レガシーシステムの接続、および統一されたゲートウェイガバナンスが必要なエンタープライズレベルの API スケジューリング。 |
ブロードキャストシャーディングには Kubernetes 接続方式が必要です。ゲートウェイを介して接続する場合、すべてのタスクは単一のポイントで実行され、バインドされたドメイン名の可用性はユーザー自身で維持する必要があります。
Kubernetes 環境：Service を介した接続
Kubernetes 環境では、Kubernetes クラスター内の Service をアプリケーションにバインドすることで、HTTP タスクをスケジューリングできます。バインドが完了すると、アプリケーション内のすべてのタスクは、その Service に関連付けられた Pod リソースを共有します。
アプリケーションで Kubernetes Service を設定すると、スケジューリングセンターは関連する Pod の情報を自動的に取得します。タスクを設定する際には、特定の Pod アドレスではなく、HTTP リクエストパスのみを指定します。タスクがスケジュールどおりにトリガーされると、スケジューリングセンターはあらかじめ設定されたルーティングポリシーに基づいてターゲット Pod に HTTP リクエストを送信します。タスクの実行結果は記録され、後で表示および分析するために Simple Log Service (SLS) にプッシュされます。
スケジューリングセンターは、サービスディスカバリーのスレッドを使用して、Pod のスケールアウトおよびスケールインイベントと異常ステータスを定期的に検出し、最新の Pod 情報を Pod マネージャーに自動的に同期します。これにより、Pod クラスターの動的な監視とステータス維持を実現します。
Pod マネージャーは Pod のネットワークアドレスとヘルスステータスを維持し、複数のタスクルーティングポリシーをサポートします。単一インスタンスルーティングに加えて、ブロードキャストシャーディングのルーティングモードを提供します。このモードでタスクが一度トリガーされると、リクエストはターゲットサービス配下のすべての Pod にブロードキャストされます。スケジューリングセンターは、シャードインデックスとシャードの総数を含むシャーディングコンテキストを HTTP リクエストヘッダーに挿入します。これにより、タスク実行中にきめ細かいロジック制御とデータパーティショニングを実現できます。挿入されるヘッダーの名前については、HTTP タスクのリクエストヘッダーをご参照ください。
非 Kubernetes 環境：ゲートウェイを介した接続
非 Kubernetes 環境では、ターゲットの HTTP ドメイン名をアプリケーションにバインドして、アプリケーションレベルで統一されたドメイン名管理とルーティングポリシー制御を実現します。複数のドメイン名がアプリケーションにバインドされると、アプリケーション内のすべてのタスクがこれらのドメイン名設定を共有します。
スケジューリングセンターは、ドメイン名マネージャーを介してドメイン名情報を維持します。タスクを作成する際には、ドメイン名ではなく、リクエストパスのみを設定します。タスクがトリガーされると、スケジューリングセンターはあらかじめ設定されたルーティングポリシーに基づいて適切なドメイン名を自動的に選択し、リクエストをゲートウェイに送信します。ゲートウェイが認証、トラフィック制御、および負荷分散を完了した後、リクエストをターゲットサービスに転送します。実行結果は最終的に SLS に同期されます。
ドメイン名マネージャーはドメイン名情報を維持します。ドメイン名の追加、削除、変更、およびタグベースのルーティングの設定をサポートします。ビジネスタグに基づいてトラフィックを分散でき、さまざまなスケジューリングおよび負荷分散要件を満たすために複数のルーティングポリシーをサポートします。
前提条件
インスタンスのエンジンバージョンは 2.3.0 以降が必要です。現在のエンジンバージョンが 2.3.0 より前の場合は、2.3.0 以降にアップグレードしてください。
アップグレード中にインスタンスが再起動します。
接続手順
MSE XXL-JOB コンソールにログインし、上部メニューでリージョンを選択します。
左側メニューで、[Task Scheduling] > [XXL-JOB Version] を選択します。
ターゲットインスタンスをクリックします。左側メニューで [Application Management] をクリックし、次に [Create Application] をクリックします。アプリケーションタイプを HTTP アプリケーションに設定し、[OK] をクリックします。
HTTP エグゼキュータを接続します。手順については、HTTP アプリケーションのエグゼキュータへの接続をご参照ください。
左側メニューで [Task Management] をクリックし、次に [Create Task] をクリックします。関連アプリケーションには、ステップ 3 で作成したアプリケーションを選択します。タスクタイプには HTTP を選択します。ビジネス要件に基づいて、[Task description]、[Priority]、[Task weight]、[Input parameters] (JSON 形式をサポート) などの情報を指定することもできます。
HTTP タスクのリクエストドメイン名、パス、リクエストメソッド、タイムアウト期間を設定します。[Request method] には、GET や POST などの HTTP メソッドを選択します。[Timeout] の単位は秒です。
HTTP タスクのリクエストパラメーターを設定します。要件に応じて [Header]、[Query]、[Body] を指定します。[Body] は、[form-data]、[x-www-form-urlencoded]、[raw-json] の 3 つのデータ形式をサポートしています。複数のパラメーターグループを追加するには、[+ Add] をクリックします。
HTTP タスクのレスポンス定義 (成功レスポンスの解析モードと成功結果の解析モードを含む) を設定します。解析モードには、レスポンスコード、レスポンスコンテンツ、レスポンスボディの 3 つの解析タイプがあります。たとえば、解析モードとして [HTTP response code] を選択した場合、成功の基準として [HTTP response code] フィールドに期待されるレスポンスコード (200 など) を入力します。
HTTP タスクの失敗リトライ (リトライ回数とリトライ間隔を含む) を設定します。リトライ回数が 0 より大きい場合は、タスクが失敗した後にリトライが行われます。この場合、リトライ用のドメイン名とインターフェイスパスを設定して、失敗したタスクがそのドメイン名とパスに送信されるようにすることもできます。[retry interval] の単位は秒です。
HTTP タスクのリクエストヘッダー
MSE XXL-JOB が HTTP タスクを実行すると、次のシステムパラメーターがリクエストヘッダーに追加されます：
| 名前 | 説明 | 値の例 |
| schedulerx-appId | アプリケーション ID | 12 |
| schedulerx-jobId | タスク ID | 35 |
| schedulerx-jobName | タスク名 | http-test-job |
| schedulerx-scheduleTimestamp | スケジューリングタイムスタンプ (ミリ秒単位) | 1760164985000 |
| schedulerx-dataTimestamp | データタイムスタンプ (ミリ秒単位) | 1760164980000 |
| schedulerx-user | ユーザー情報 | 1344371792 |
| schedulerx-maxAttempt | 最大リトライ回数 | 3 |
| schedulerx-attempt | 現在のリトライ回数 | 1 |
| schedulerx-jobExecutionId | タスク実行 ID | 1417474640397221891 |
| schedulerx-logId | ログ ID | 1417474640531439619 |
| schedulerx-shardingIndex | シャードインデックス (ブロードキャストシャーディング) | 0 |
| schedulerx-shardingTotal | シャードの総数 (ブロードキャストシャーディング) | 3 |