本トピックは、ApsaraVideo VOD、Intelligent Media Services (IMS)、ApsaraVideo Media Processing (MPS) における非同期メディア処理タスクに適用されます。ここでは、非同期タスクのタイミングと動作を理解するための一般的なガイドを提供し、トランスコーディングを例にタスクの状態と処理時間について説明します。ステータスフィールド、進捗インジケーター、クエリメソッドはタスクの種類によって異なります。詳細については、各 API またはサービスのドキュメントをご参照ください。
概要
ApsaraVideo VOD、IMS、および MPS は、さまざまな非同期メディア処理機能を提供します。非同期タスクは API 呼び出しによって送信され、バックグラウンドで処理されます。結果は処理が完了した後に利用可能になります。
タスクの送信が成功したことは、タスクが受理されたことを意味するだけであり、処理が開始されたことや、一定時間内に完了することを保証するものではありません。
非同期タスクは、本質的にオフライン処理ジョブです。同期 API 呼び出しとは異なり、結果が生成されるまでの時間は、タスクスケジューリング、ワークロードの変動、タスクの複雑さ、ソースファイルの特性、パラメーター設定など、複数の要因に依存します。総完了時間は、実処理時間だけよりも大幅に長くなる可能性があります。
そのため、遅延の影響を受けやすいワークフローでは、非同期タスクをブロッキング条件として使用しないでください。本ドキュメントの処理速度ベンチマークを、本番環境での納期タイムラインの予測に使用しないでください。
適用範囲
このガイドは、ApsaraVideo VOD、IMS、および MPS で非同期に送信および実行されるメディア処理タスクに適用されます。これには、以下のタスクが含まれますが、これらに限定されません。
メディアトランスコーディングタスク
メディア編集および合成タスク
スナップショットおよびスプライトシートタスク
メディア分析タスク
AI 支援メディア処理タスク
非同期の送信および取得モデルを使用するその他のメディア処理タスク
処理パイプライン、処理時間の特性、ステータスフィールド、進捗インジケーター、クエリメソッド、および通知メカニズムは、タスクの種類によって異なる場合があります。特定の機能のドキュメントで別途ガイダンスが提供されている場合は、そのドキュメントに従ってください。
一般的なタイミングのガイドライン
タスクを送信する前にこのセクションを読み、それに応じてビジネスロジックを設計することを推奨します。
非同期タスクの総完了時間は、通常、次の 2 つの部分で構成されます。
総完了時間 = キュー待機時間 + 実処理時間ここで、
キュー待機時間：タスクが送信されてから、実処理が開始されるまでの時間。
実処理時間：処理が開始された後、タスクの実行に費やされる時間。
返されたタスク ID は、タスクが正常に作成されたことを確認するだけです。
実際に経験する完了時間は、処理時間だけでなく、総完了時間です。
処理速度のベンチマークは、典型的な処理特性を説明するものです。サービスコミットメント、SLA 保証、納期保証、または補償の根拠を構成するものではありません。
タスクの仕様がベンチマークシナリオとほぼ一致している場合でも、キュー待機時間の増加により、総完了時間が大幅に長くなる可能性があります。
ビジネスで厳格なタイミング要件がある場合は、バッファー時間を組み込み、非同期デカップリング、タイムアウトフォールバック、およびグレースフルデグラデーションを実装してください。
総完了時間と実処理時間
この違いを理解することは、非同期タスクを扱う上で重要です。
このドキュメントで言及されている処理速度、速度倍率、および時間見積もりは、タスクが実処理を開始した後の処理速度のみを指します。
結果が利用可能になるまでに実際に経験する時間は、以下に依存します。
タスクが処理を開始するまでに待機した時間。
タスクの処理にかかった時間。
したがって：
処理時間のベンチマークは、総完了時間と同じではありません。
処理時間のベンチマークは、納期のタイムラインを計算するために使用できません。
異なる時間に送信された同一のタスクでも、総完了時間が著しく異なる場合があります。
キュー待機時間
タスクが送信されると、サービスはタスクの種類、現在のワークロード、および処理ポリシーに基づいてタスクをスケジューリングします。
以下の条件下では、キュー待機時間が増加する可能性があります。
短期間に多数のタスクが送信された場合。
ワークロードの変動は同じタイムウィンドウ内に発生します。
キューには、複雑なタスクが高い割合で含まれています。
送信が成功しても、タスクが処理段階に入ったことを意味するわけではありません。
待機時間は、送信のタイミング、タスクの種類、タスクの量、および処理パイプラインの違いによって変動する可能性があります。
待機期間中に同じタスクを再送信しないでください。重複送信は冗長な処理を引き起こし、全体の待機時間をさらに増加させる可能性があります。
高頻度のポーリングの代わりに、非同期コールバックを使用してタスクの結果を受信してください。
現在のサービスステータスを確認するには：
待機時間の増加だけが、必ずしもサービスの問題を示すわけではありません。多くの要因が待機時間に影響します。現在のサービスステータスを確認するには、テクニカルサポートにお問い合わせください。
広範囲にわたるサービス障害が発生した場合、Alibaba Cloud はコンソール内メッセージ、SMS、またはその他のチャネルを通じて影響を受けるユーザーに通知します。
実処理時間
実処理時間は、タスクの種類、ソースファイルの特性、およびタスク設定によって異なります。機能ごとにパフォーマンスモデルが異なります。
処理時間に影響を与える一般的な要因
要因 | パターン | 説明 |
ソースファイルの持続時間 | ファイルが長いほど処理に時間がかかります。 | ほとんどのメディア処理タスクにおける主要な要因です。 |
出力仕様 | 出力仕様が高いほど時間がかかります。 | 例：より高い解像度や、より複雑な出力フォーマット。 |
アルゴリズムの複雑さ | より複雑なアルゴリズムは時間がかかります。 | 例：高度なトランスコーディングや複雑な分析。 |
カスタムパラメーター | より複雑なパラメーターは時間がかかります。 | 例：エンハンスメントパラメーターや多段階処理。 |
ソースファイルの特性 | 特性が複雑になるほど分散が大きくなります。 | 例：ビットレート、フレームレート、コンテナフォーマット、ストリーム構造。 |
タスクの種類 | タスクの種類によってパフォーマンスモデルが異なります。 | トランスコーディング、編集、スナップショット、分析タスクは直接比較できません。 |
タスクの種類による違い
トランスコーディングタスク：処理時間は通常、動画の持続時間、解像度、コーデック、トランスコーディングアルゴリズム、およびテンプレートパラメーターと相関します。
編集タスク：追加の要因には、セグメント数、再エンコーディングが必要かどうか、カットがキーフレーム境界を越えるかどうか、および複数セグメントの連結が含まれます。
スナップショット、スプライトシート、分析タスク：持続時間の推定方法はトランスコーディングとは異なる場合があります。進捗フィールド、ステータスフィールド、および段階の内訳が存在するかどうかは、特定の機能によって異なります。関連ドキュメントをご参照ください。
タスクのステータスと進捗
ステータスフィールド、進捗インジケーター、クエリメソッド、および結果配信メカニズムは、非同期タスクの種類によって異なります。
このドキュメントで説明されているステータスロジックは、一般的な処理段階を示しています。すべての非同期タスクが同じステータスモデルに従うわけではありません。
一般的な観点から、非同期タスクは通常、以下の段階を経ます。
留意事項：
一部のタスクは、クエリ可能な進捗フィールドを公開します。
一部のタスクは、処理中、完了、失敗など、限られたステータスセットのみを返します。
一部のタスクでは、「待機中」の状態は個別のステータス値ではありません。ステータスフィールドと他のフィールドを組み合わせて判断します。
正確なステータスの定義については、実際の API 応答と対応するプロダクトドキュメントをご参照ください。
トランスコーディングタスクの例
以下のセクションは、トランスコーディングタスクにのみ適用されます。他の非同期タスクでは、異なるメカニズムが使用される場合があります。
トランスコーディングタスクの状態
トランスコーディングタスクを送信すると、クエリ結果のステータスフィールドに `Transcoding` と表示されることがあります。
`Transcoding` はタスクがトランスコーディングパイプラインに入ったことを示しますが、必ずしも実トランスコーディングが開始されたことを意味するわけではないことにご注意ください。
`TranscodeProgress` フィールドを組み合わせて、現在の段階を判断します。
ステータス | TranscodeProgress | 意味 | 解釈 |
Transcoding/Submitted | 0 | タスクは実トランスコーディングを開始していません。 | 待機中 |
Transcoding/Percent/Running | > 0 | タスクはトランスコード中です。 | 処理中 |
Completed | 100 またはタスク完了 | トランスコーディングは正常に終了しました。 | 完了 |
Failed | - | トランスコーディングは異常終了しました。 | 失敗 |
トランスコーディングタスクでは、待機中は通常、個別のステータス列挙値ではありません。タスクのステータスとトランスコードの進捗を組み合わせて推論されます。
トランスコーディング速度のベンチマーク
以下のベンチマークは、実処理が開始された後の典型的なテスト条件下でのトランスコーディングタスクの処理速度を説明するものです。これにはキュー待機時間は含まれず、総完了時間を表すものでもなく、サービスコミットメントを構成するものでもありません。
次の表は、典型的な H.264 720p シナリオを基準として、さまざまなトランスコーディングアルゴリズムの処理速度特性を示しています。
アルゴリズム | 処理速度ベンチマーク | 説明 |
標準トランスコーディング | 約 3 倍速 | 典型的な条件下での処理段階の速度のみを反映します。 |
ナローバンド HD 1.0 | 約 1.5 倍速 | 実処理時間は通常、標準トランスコーディングよりも長くなります。 |
ナローバンド HD 2.0 | 通常 1 倍速を大幅に下回る | 処理時間は通常、ソース動画の持続時間を超えます。実際の結果は変動します。 |
速度倍率の説明
速度倍率 = 処理時間の単位あたりに処理される動画の持続時間の倍数
例：
3 倍速とは、1 分間の処理時間あたりに約 3 分間の動画コンテンツが処理されることを意味します。
30 分の動画は、キュー待機時間を除き、処理に約 10 分かかります。これらのベンチマークは、典型的な H.264 720p トランスコーディングシナリオにのみ適用されます。
タスクの総完了時間を見積もるために使用することはできません。
より高い解像度、より複雑なコーデック、またはより重いパラメーターは、通常、処理速度の低下につながります。
ソース動画のビットレート、フレームレート、コンテナフォーマット、およびストリーム構造の違いは、処理時間に大きな影響を与える可能性があります。
ナローバンド HD 2.0 は通常、標準トランスコーディングおよびナローバンド HD 1.0 よりもはるかに計算集約的です。
実際の処理時間については、タスクステータスのクエリまたは完了通知をご参照ください。
よくある質問
1. 10 分間の 720p トランスコーディングタスクは、常に 3～4 分で完了しますか？
必ずしもそうとは限りません。
「約 3 倍速」というベンチマークは、タスクが実処理段階に入った後の典型的なテスト条件下での処理速度を説明するものです。これにはキュー待機時間は含まれず、本番環境での総完了時間を表すものでもありません。
結果が利用可能になるまでに実際に経験する時間は、最終的な完了時間によって決まります。処理速度のベンチマークを使用して納期タイムラインを見積もらないでください。
総時間が予想を超える場合は、一般的なトラブルシューティングのセクションを参照するか、テクニカルサポートにお問い合わせください。
2. トランスコーディングタスクのステータスが Transcoding で、TranscodeProgress が 0 のままなのはなぜですか？
トランスコーディングタスクにおいて、`Transcoding` はタスクがトランスコーディングパイプラインに入ったことを意味しますが、実トランスコーディングが開始されたことを意味するわけではありません。
`TranscodeProgress = 0` の場合、タスクはまだ待機段階にあります。`TranscodeProgress > 0` の場合、実トランスコーディングが進行中です。
3. 同様の仕様にもかかわらず、タスクがベンチマークよりはるかに時間がかかるのはなぜですか？
考えられる理由：
処理が開始される前に、タスクがキューで長時間待機した。
ソースファイルの特性が、典型的なベンチマークシナリオと異なる。
タスクパラメーターまたはテンプレート設定が、標準設定よりも複雑である。
同じタイムウィンドウでのワークロードの変動により、総完了時間が増加した。
詳細な調査については、テクニカルサポートに連絡し、タスク ID を提供してください。
4. 待機時間の増加は、常にサービスの問題を示しますか？
必ずしもそうとは限りません。
待機時間は、ワークロードやタスクの特性など、複数の要因に影響されます。待機時間の増加だけがサービスの問題を示すわけではありません。現在のサービスステータスを確認するには、テクニカルサポートにお問い合わせください。
5. 処理速度のベンチマークを使用して、ビジネス上の納期を約束できますか？
このアプローチは推奨しません。
処理速度のベンチマークは、タスクの処理特性を理解するのに役立ちます。これらを本番環境の納期タイムライン、ビジネス SLA、またはエンドユーザーへのコミットメントとして直接使用するべきではありません。
厳格なタイミング要件があるシナリオでは、アーキテクチャにバッファー時間を組み込み、タイムアウトフォールバックとグレースフルデグラデーションのメカニズムを実装してください。
6. トランスコーディングのステータスモデルを他の非同期タスクに使用できますか？
必ずしもそうとは限りません。
トランスコーディングの例における `Transcoding` および `TranscodeProgress` フィールドは、トランスコーディングタスクに固有のものです。
編集、スナップショット、スプライトシート、分析、およびその他の非同期タスクでは、ステータスフィールド、進捗インジケーター、および解釈方法が異なる場合があります。特定のタスクの種類については、クエリ API とプロダクトドキュメントをご参照ください。
主な操作
タスクの送信
API を介して非同期タスクを送信すると、サービスはタスク ID を返します。
タスク ID は、ステータスのクエリ、結果通知の関連付け、および問題のトラブルシューティングのためのユニークな識別子です。安全に保存してください。
結果通知
タスクが完了した後、コールバック URL を設定している場合、サービスは積極的に結果通知をプッシュします。継続的なポーリングなしでタスクの完了を自動的に検出するには、コールバックを使用してください。
コールバックのガイドライン
本番環境で結果を受信する主要な方法として、コールバックを使用してください。
コールバック URL が到達不能な場合、サービスは事前定義されたポリシーに基づいて自動的にリトライします。
複数回のリトライ後に配信が失敗した場合は、クエリ API を使用して最終的なタスクステータスを確認してください。
ネットワークの変動やクライアント側の問題により、コールバック通知が遅延したり、複数回配信されたりする可能性があります。
タスク ID をキーとして使用し、コールバックハンドラにべき等性チェックを実装してください。
最終的なタスクステータスの信頼できる情報源は、クエリ API の応答です。
コールバックの設定とリトライメカニズムの詳細については、「コールバックの設定」をご参照ください。
タスクのクエリ
タスク ID によって、タスクの現在のステータスと結果をクエリします。これは、以下のシナリオで適用されます。
コールバック通知を設定していない場合。
コールバックを設定しているが、現在の進捗を積極的に確認したい場合。
タスクは想定より時間がかかっています。
コールバック通知の配信に失敗し、フォールバックメソッドが必要な場合。
タスク情報のクエリ
クエリ API は、主にタスクのステータス、進捗、および結果情報を返します。タスクが予想より大幅に時間がかかる場合は、ステータスの変更、送信時間、およびタスク設定を確認して調査してください。原因を特定できない場合は、テクニカルサポートに連絡し、タスク ID を提供してください。
一般的なトラブルシューティング
タスクが予想以上に時間がかかる場合は、次の手順に従ってください。
ステップ 1：タスクが完了したかどうかを確認する
タスク ID でタスクのステータスまたは結果をクエリします。
タスクが完了した場合、結果を取得し、総所要時間を評価します。
タスクが失敗した場合、エラーコードとエラーメッセージを確認します。
タスクがまだ実行中の場合は、次のステップに進み、待機段階か処理段階かを判断します。
ステップ 2：タスクの種類に基づいて現在の段階を判断する
トランスコーディングタスクの場合：`Transcoding` ステータスと `TranscodeProgress` を組み合わせて、実処理が開始されたかどうかを判断します。
他の非同期タスクの場合：特定のタスクの種類については、クエリ API の応答フィールドとドキュメントをご参照ください。トランスコーディングタスクのモデルを直接適用しないでください。
ステップ 3：タスクの特性に基づいて考えられる原因を特定する
症状 | 考えられる原因 | 推奨されるアクション |
長期間結果がない | ワークロードの変動、待機時間の増加、サービス障害、または複雑なタスク | サービスステータスページを確認してください。必要に応じてテクニカルサポートにお問い合わせください。 |
処理時間が典型的なタスクより大幅に長い | 複雑なソースファイル、重いパラメーター、または高いタスクの複雑さ | ソースファイルと設定を確認してください。必要に応じてサポートにお問い合わせください。 |
タスクが失敗した | ソースファイルの問題、パラメーターエラー、または処理例外 | エラーコードの説明を確認し、修正手順に従ってください。 |
クエリが結果を返さない | 不正なタスク ID またはタスクが正常に送信されなかった | 送信結果とタスク ID を確認してください。 |
ステップ 4：サポートに連絡する際に提供する情報
テクニカルサポートが問題を調査するのを助けるために、以下の情報を提供してください。
タスク ID
タスクの送信時間
タスクの種類（トランスコーディング、編集、スナップショット、分析など）
ソースファイルの持続時間、解像度、およびコーデック
テンプレート設定または処理パラメーター
タスクがバッチで送信されたかどうか
観測された症状と影響範囲
推奨される統合パターン
メソッド | 説明 | ユースケース |
非同期コールバック（推奨） | タスク完了後、サービスが結果をプッシュします。 | 本番環境およびライブビジネスワークフロー。 |
ポーリング | スケジュールに基づいてタスクのステータスと結果をクエリします。 | デバッグ、テスト、およびコールバックが失敗した場合のフォールバック。 |
統合のベストプラクティス
本番環境では、主要な方法として非同期コールバックを使用してください。
不要なリクエストを減らすために、高頻度のポーリングを避けてください。
重複送信を防ぐために、タスク送信時にべき等性制御を実装してください。
短期的なキューの蓄積を避けるために、バッチ送信をずらしてください。
タスクのタイムアウト監視、アラート、および手動介入メカニズムを設定してください。
重要なビジネスシナリオには十分なバッファー時間を確保し、グレースフルデグラデーション戦略を設計してください。
本番環境の納期コミットメントに、処理速度のベンチマークを直接使用しないでください。
SLA と責任範囲
サービス障害がタスク処理の遅延を引き起こしたと疑われる場合は、テクニカルサポートに連絡し、タスク ID と関連情報を提供してください。
サービスの可用性、責任判断、および補償範囲は、正式なサービス契約と SLA に準拠します。
このドキュメントのタスクのタイミングに関する説明、処理速度のベンチマーク、例、および FAQ の内容は、非同期タスク処理を理解するのに役立ちます。これらは、独立した完了時間のコミットメント、サービス補償の根拠、またはビジネス上の責任保証を構成するものではありません。
ヒント
非同期タスクの遅延変動がビジネスに与える影響を軽減するには：
システム設計でメディア処理タスクに非同期デカップリングを使用してください。
同期的にブロックするのではなく、コールバックまたはステータスクエリを使用してタスクの結果を検出してください。
ピーク時、バッチ送信、および複雑なタスクのために、追加のバッファー時間を確保してください。
タスクのタイムアウトアラート、手動介入プロシージャ、およびビジネスフォールバックメカニズムを実装してください。
さらに質問がある場合は、関連するプロダクトドキュメントをご参照ください。