ワークフロークラスターは、安全で効率的な方法でオブジェクトを管理するために使用される完全にホストされたArgoサービスです。 ワークフロークラスターは、強化された機能も提供します。 標準のArgoワークフローと比較して、ワークフロークラスターには、バッチ処理、データ処理、継続的統合などのシナリオで利点があります。 このトピックでは、ワークフロークラスターを使用してオブジェクトを安全かつ効率的に管理する方法について説明します。
複雑なワークフローオーケストレーションにおけるストレージの課題
Argo Workflowsは、オープンソースのクラウドネイティブワークフローエンジンであり、cloud native Computing Foundation (CNCF) の段階的なプロジェクトです。 Argoワークフローは、Kubernetes上の複雑なワークフローを自動的に管理できます。 Argoワークフローは、CronJobs、機械学習、Extract Transform Load (ETL) 、データ分析、モデルトレーニング、データフローパイプライン、CI/CDなどのさまざまなシナリオに適しています。
ジョブのオーケストレーションにArgoワークフローを使用する場合、特にモデルトレーニング、データ処理、バイオインフォマティクス分析などのデータ集約型のシナリオでは、アーティファクトを効率的に管理および保存する必要があります。 オープンソースソリューションを採用すると、次の課題に直面する可能性があります。
特大オブジェクトはアップロードできません: クライアントのアップロード制限により、5 GiBを超えるオブジェクトはアップロードできません。
オブジェクトクリーンアップメカニズムの欠如: 一時オブジェクトまたは完了したジョブの出力結果がタイムリーにクリーンアップされない場合、object Storage Service (OSS) ストレージスペースが無駄になります。
Argo Serverのディスク使用率が高い: Argo Serverを使用してオブジェクトをダウンロードする場合、オブジェクトを転送する前にオブジェクトをディスクに保存する必要があります。 ディスクの使用量が多いと、サーバーのパフォーマンスに影響し、サービスの中断やデータの損失につながる可能性があります。
分散ArgoワークフローのKubernetesクラスター (ワークフロークラスター) は、オープンソース仕様に準拠した完全ホスト型のArgoワークフローサービスです。 ワークフロークラスターは、大規模で高セキュリティのオブジェクト管理の課題に対応できます。 ワークフロークラスターは、大規模なオブジェクトのアップロード、アーティファクトのガベージコレクション (GC) 、アーティファクトのストリーム送信などの拡張機能を提供します。 上記の機能は、Alibaba Cloud上のOSSオブジェクトの効率的で安全できめ細かい管理を実現するのに役立ちます。
完全にホストされたArgoワークフローサービスとして、ワークフロークラスターは、アーティファクト管理におけるオープンソースソリューションよりも次の利点を提供します。
機能 | ワークフロークラスター | オープンソースArgoワークフロー |
オブジェクトのアップロード | ラージオブジェクトのマルチパートアップロード機能がサポートされています。 | 5 GiB未満のオブジェクトのみアップロードできます。 大きなオブジェクトはアップロードできません。 |
GC | アーティファクトGCがサポートされています。 | GCはサポートされていません。 |
オブジェクトのダウンロード | ストリーム送信がサポートされています。 | オブジェクトを転送する前に、オブジェクトをディスクに保存する必要があります。 このプロセスは面倒です。 |
シナリオ1: 大きなオブジェクトのアップロードのサポート
オープンソースのArgoワークフローは、大規模なオブジェクトのアップロードをサポートしていないため、データ集約型ジョブでの使用が制限されます。 この問題を解決するために、ワークフロークラスターは大きなオブジェクトをOSSにアップロードするためのロジックを最適化し、マルチパートアップロードと再開可能アップロードをサポートします。 これにより、大きなオブジェクト処理の効率と信頼性が大幅に向上します。 このソリューションを使用して、各部品の整合性を個別に検証することもできます。これにより、データの整合性とシステムのフォールトトレランスが強化されます。
例
デフォルトでは、ワークフロークラスターに対してラージオブジェクトアップロードが有効になっています。 アーティファクトを設定した後、サンプルワークフローを送信して、OSSからtestfile.txtという名前の20 GiBオブジェクトを取得できます。 これは、大きなオブジェクトをOSSにアップロードできることを示します。
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: artifact-
spec:
entrypoint: main
templates:
- name: main
metadata:
annotations:
k8s.aliyun.com/eci-extra-ephemeral-storage: "20Gi" # Specify the size of the additional temporary storage space.
k8s.aliyun.com/eci-use-specs : "ecs.g7.xlarge"
container:
image: alpine:latest
command:
- sh
- -c
args:
- |
mkdir -p /out
dd if=/dev/random of=/out/testfile.txt bs=20M count=1024 # Create a 20-GiB object.
echo "created files!"
outputs: # Trigger the system to upload the object to OSS.
artifacts:
- name: out
path: /out/testfile.txtシナリオ2: オブジェクトのクリーンアップメカニズムの設定
オープンソースのArgoソリューションは、OSSオブジェクトを自動的にクリーンアップできないため、ストレージとO&Mのコストが増加します。 Argoワークフローは、アーティファクトGCメカニズムを使用して、ワークフローの完了後に不要になったオブジェクト (中間結果やログなど) をクリーンアップします。 これにより、ストレージスペースが節約され、コストが削減され、ストレージリソースの無制限な使用が回避されます。
ワークフロークラスターは、OSSオブジェクトのクリーンアップロジックを最適化します。 簡単なクリーンアップロジックを設定することで、次の機能を使用できます。
自動クリーンアップ: ワークフローが完了するか、管理者がワークフロー関連のリソースを一定期間手動でクリーンアップすると、OSSにアップロードされたオブジェクトは自動的にクリーンアップされます。
クリーンアップの柔軟な設定: 失敗したログの削除を回避するために、成功したワークフロータスクに対してのみクリーンアップポリシーを設定するオプションがあります。 これにより、その後の問題の追跡とトラブルシューティングが容易になります。 失敗したワークフロータスクに対して排他的クリーンアップポリシーを設定して、無効な中間出力を削除することもできます。
ライフサイクル管理ポリシー: OSSが提供するライフサイクル管理ポリシーを使用して、時間やプレフィックスなどのパラメーターに基づいてポリシーを設定できます。 ポリシーは、古いアーティファクトを自動的に削除したり、履歴アーティファクトをコールドストレージにアーカイブしたりできます。 これにより、データの整合性が確保され、ストレージコストが削減されます。
例
この機能を有効にするには、アーティファクトのGCポリシーを設定します。 次の例では、ワークフローのグローバルアーティファクトのGCポリシーは、ワークフローが削除されたときにアーティファクトをクリーンアップします。また、on-completion.txtファイルのGCポリシーは、ワークフローが完了したときにアーティファクトをクリーンアップします。 ワークフローが送信された後、ワークフローが完了するとon-completion.txtファイルがクリーンアップされ、ワークフローが削除された後もon-deletion.txtファイルがクリーンアップされることがOSSでわかります。
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: artifact-gc-
spec:
entrypoint: main
artifactGC:
strategy: OnWorkflowDeletion # The global cleanup policy. The artifact is cleanup when the workflow is deleted. This policy can be overridden.
templates:
- name: main
container:
image: argoproj/argosay:v2
command:
- sh
- -c
args:
- |
echo "hello world" > /tmp/on-completion.txt
echo "hello world" > /tmp/on-deletion.txt
outputs: # Upload an object to OSS.
artifacts:
- name: on-completion
path: /tmp/on-completion.txt
artifactGC:
strategy: OnWorkflowCompletion # The global cleanup policy. The artifact is cleaned up when the workflow is completed. This policy overrides the global cleanup policy.
- name: on-deletion
path: /tmp/on-deletion.txtシナリオ3: ストリーム伝送メカニズムのサポート
オープンソースソリューションでは、Argo Serverがオブジェクトをダウンロードするときに、オブジェクトを転送する前にディスクに書き込む必要があります。 これにより、ディスクの使用量が増加し、サーバーのパフォーマンスに影響を与え、サービスの中断やデータ損失を引き起こす可能性があります。
ワークフロークラスターは、OSSのOpenStream API操作をサポートしています。 Argo Workflowsユーザーインターフェイスでオブジェクトをダウンロードすると、オブジェクト全体をオンプレミスサーバーにダウンロードしてユーザーに提供するのではなく、Argo ServerはオブジェクトをOSSサーバーからユーザーに直接ストリーミングできます。 このストリーム伝送メカニズムは、大規模なデータ伝送およびストレージワークフロータスクを処理するのに適しています。 以下のセクションでは、このメカニズムの利点について説明します。
ダウンロードパフォーマンスの向上: オブジェクトはOSSサーバーからユーザーに直接ストリーミングされるため、オブジェクト全体がArgo serverにダウンロードされるのを待つ必要がなくなります。 これにより、ダウンロードの待ち時間が短縮され、応答速度が向上し、よりスムーズなユーザーエクスペリエンスが提供されます。
リソース消費量の削減による同時実行性の向上: ストリーム送信により、Argo Serverのメモリとディスクの需要が削減されます。 これにより、Argo Serverは同じハードウェアリソースでより多くのオブジェクトを並行して転送でき、システムの同時実行レベルが向上します。 ストリーム送信は、サービスを効率的にスケールアウトして、増加するユーザー数とファイルサイズの増加に対応できます。 Argo Serverのディスク容量制限について心配する必要はありません。
強化されたセキュリティコンプライアンス: ストリーム送信メカニズムは、Argo Serverの一時的なデータストレージを回避し、セキュリティリスクと起こりうるデータリークを軽減し、データ保護とコンプライアンス要件を満たします。
ストリーミングを使用してアーティファクトを転送することで、Argo Serverの負荷を軽減し、UIファイルのダウンロードパフォーマンスを向上させることができます。 これにより、Argo Serverは、負荷の高いストレージおよびコンピューティングセンターではなく、軽量のデータ転送センターに効果的に変換されます。
お問い合わせ
ACK Oneについてご質問がある場合は、DingTalk 35688562に参加してください。