ApsaraVideo Media Processing:非同期タスク処理

「合計完了時間」と「処理時間」の違い

この違いを理解することは、非同期タスクに対する期待を管理する上で重要です。

本ドキュメントにおける処理速度、速度倍率、または時間例への言及は、タスクが実際の処理段階に入った後のパフォーマンス特性のみを説明しています。

結果を受け取るまでに必要な時間は、次の要因に依存します。

1. 処理が開始される前にタスクがキューで待機する時間。

2. タスクが開始されてから処理にかかる時間。

したがって：

• 参考処理時間 ≠ 合計完了時間

• 参考処理時間を使用してタスクの納品時間を予測することはできません。

• 同じ仕様のタスクを異なる時間に送信した場合、合計完了時間が大幅に異なる可能性があります。

一般的な待機時間

タスクが送信されると、サービスはタスクタイプ、全体のタスク量、および内部の処理戦略に基づいて処理をスケジューリングします。

以下のような状況では、待機時間が増加する可能性があります。

• 短期間に大量のタスクが送信された場合。

• 同じ時間帯にタスク量が大幅に変動した場合。

• 計算量の多い複雑なタスクがキューに高い割合で存在する場合。

現在のサービスステータスを理解するには、以下の点を考慮してください。

• 待機時間は、タスク量やタスク特性など多くの要因に影響されます。待機時間の増加だけでは、サービスの問題を示す信頼できる指標にはなりません。現在のサービスステータスを確認するには、テクニカルサポートにご連絡ください。

• 広範囲に影響を及ぼすサービスの問題が発生した場合、Alibaba Cloud は影響を受けるユーザーにサイト内メッセージ、SMS、またはその他のチャネルを通じて通知します。

一般的な処理時間

実際の処理時間は、タスクタイプ、ソースファイル特性、およびタスク設定によって異なります。機能ごとにタスク所要時間の見積もりモデルが異なります。

トランスコードタスクのステータス

例えば、トランスコードタスクを送信した後、クエリ結果のステータスフィールドに「Transcoding」と表示されることがあります。

「Transcoding」ステータスは、タスクがトランスコードプロセスに入ったことを意味しますが、必ずしも実際のトランスコードが開始されたことを意味するわけではないことに注意してください。

タスクの段階をさらに判断するために、`TranscodeProgress` フィールドを使用できます。

トランスコードタスクの場合、待機中は通常、独立したステータスではありません。タスクステータスとトランスコードの進捗を組み合わせて判断される段階です。

トランスコード速度の参考

典型的な H.264 720p トランスコードシナリオにおいて、異なるトランスコードアルゴリズムの処理速度特性は以下の通りです。

速度 = 単位時間あたりに処理できる動画の持続時間の倍率

例：
3 倍速とは、1 分間の処理で約 3 分間の動画コンテンツを処理できることを意味します。
したがって、30 分の動画の場合、理論上の処理時間は約 10 分です (待機時間を除く)。

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 が設定されていれば、サービスは結果通知を送信できます。このコールバックを使用すると、継続的なポーリングなしでタスクの完了を自動的に検出できます。

タスクのクエリ

タスク ID を使用して、タスクの現在のステータスと結果を能動的にクエリできます。これは、以下のシナリオで役立ちます。

• コールバック通知を設定していない場合。

• コールバックを設定しているが、現在の進捗を確認する必要がある場合。

• タスクの持続時間が、ビジネス上の期待を超えています。

• コールバック通知が失敗した場合のフォールバックメソッドとして。

タスク情報のクエリ

クエリ API は、主にタスクのステータス、進捗、および結果情報を返します。タスクが予想よりも大幅に長くかかる場合は、タスクステータスの変更、送信時間、およびタスク設定を確認してトラブルシューティングすることを推奨します。それでも原因を特定できない場合は、テクニカルサポートに連絡し、分析のためにタスク ID を提供してください。

1. タスクの完了を確認する

タスク ID を使用して、タスクの現在のステータスまたは結果をクエリします。

• タスクが完了している場合は、結果を取得し、かかった合計時間を評価します。

• タスクが失敗した場合は、エラーコードとエラーメッセージを確認します。

• タスクがまだ完了していない場合は、次のステップに進み、待機段階か処理段階かを判断します。

2. タスクタイプ別に段階を判断する

• トランスコードタスクの場合：「Transcoding」ステータスと「TranscodeProgress」フィールドを確認して、タスクが実際の処理段階に入ったかどうかを判断できます。

• 他の非同期タスクの場合：クエリ API によって返されるフィールドと、その特定のタスクのドキュメントをご参照ください。トランスコードタスクで使用される同じ解釈方法を適用しないでください。

3. タスク特性別に原因を特定する

4. テクニカルサポートへの情報提供

トラブルシューティングのためにテクニカルサポートに連絡する際は、以下の情報を提供してください。

• タスク ID

• タスク送信時間

• タスクタイプ (例：トランスコード、編集、スナップショット、または分析)

• ソースファイルの持続時間、解像度、およびエンコード形式

• テンプレート設定または処理パラメーター

• アイテムをバッチで送信するかどうかを指定

• 問題とその影響の説明

統合に関する推奨事項

• 本番環境では、非同期コールバックの使用を優先してください。

• 不要なリクエストを減らすために、高頻度のポーリングは避けてください。

• 重複を避けるために、タスク送信時にべき等性コントロールを実装してください。

• バッチタスクの場合、短時間で大きなキューが作成されるのを避けるために、送信をずらしてください。

• タスクのタイムアウトモニタリング、アラート機能、および手動フォールバックのメカニズムを確立してください。

• 重要なビジネスシナリオでは、十分なバッファー時間を確保し、サービス低下計画を設計してください。

• 本番環境での納品コミットメントに処理速度の参考値を使用しないでください。