Skip to main content
NetApp artificial intelligence solutions
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

10.セキュリティに関する考慮事項、検証およびテスト

共同作成者 nkarthik
PDF

カーティケヤン ナガリンガム、NetApp

この統合されたセクションでは、AIパイプラインを安全に運用するために必要な制御と、設計が代表的な環境で期待どおりに動作することを証明するために使用される検証活動について説明します。パイプラインで使用されるストレージ階層の分離、最小権限アクセスモデル、チェックポイントロジック、および実行範囲の系統追跡といった要素は、検証計画と運用上の安全対策にも反映されます。

[[10-1-security-considerations]]
== 10.1 セキュリティに関する考慮事項

セキュリティ対策は、監査に必要なデータ系列を維持しつつ、各ストレージ層とパイプライン機能を分離する必要があります。StorageGRID 生データ、ONTAP NAS で準備されたデータ、選択した XCP 宛先、および StorageGRID アーカイブには、それぞれ個別の最小権限の認証情報を使用してください。ネットワーク トラフィックを暗号化し、すべてのシークレットは DAG 定義、使用例、およびシェル履歴の外部に保存してください。

領域 推奨事項

認証情報管理

Airflow Connections/Variables またはシークレットマネージャーを使用し、インラインプレーンテキストは避けてください。 dag_run.conf

転送中のデータ

TLS対応のS3エンドポイントを使用し、サポートされている場合は暗号化されたNFS/Lustreトランスポートを使用する

アクセス制御

ロールごとにS3クレデンシャルのスコープを設定し（StorageGRID 生データ、ONTAP NAS 準備済みデータ、XCP 宛先、StorageGRID アーカイブ）、最低限必要な権限に制限する

設定ファイル内のシークレット

テスト中に公開された認証情報はすべてローテーションし、トリガースクリプトやシェル履歴は機密情報として扱ってください。

監査証跡

コンプライアンスの証拠として、データ準備マニフェスト、チェックポイント記録、およびアーカイブマニフェストを活用してください。

[[10-2-validation-and-testing]]
== 10.2 検証とテスト

検証により、パイプラインの構成可能な動作が、ルーティング、障害処理、データ転送、および複数ファイル検出の各パス全体で確実に機能することが確認されました。各検証テスト領域は、実際のAirflow DAGトリガーを使用して代表的な環境で実行され、ログ出力とストレージマニフェストの正確性が検証されました。

[[10-2-1-functional-routing-validation]]
=== 10.2.1 機能ルーティングの検証

このテスト領域は、 `enable_xcp=true`の際のエンドツーエンドのデータとアーティファクトのルーティングを検証します。

  • 目的： データ準備、XCP移動、モデルトレーニング、ファインチューニング、および推論において、選択されたXCP宛先が一貫して使用されることを検証します。(s3`または `lustrefs）

  • テスト手順： トリガーされた DAG は以下で実行されます xcp_copy_destination="s3"`および `xcp_copy_destination="lustrefs"。XCom の出力、有効構成ログ、および保存場所を確認しました。

  • 検証結果：

    • `data_prep`では、フォーマットされた表形式の分割ファイルとテキストファイルが、 `<xcp_prefix>/formatted/<run_stamp>/data/`配下のONTAP NAS準備済みデータ層にステージングされました。

    • `xcp_copy`では、準備されたデータセットが、下流のモデルステージのために選択されたXCP宛先に転送されました。

    • model_training`では、モデル入力は XCP 宛先からロードされ、ベースラインアーティファクト（(`regression_model.bin、 text_vectorizer.bin、 text_classifier.bin、 train_metrics.json）は `<xcp_prefix>/formatted/<run_stamp>/artifacts/`に公開されました。

    • `fine_tuning`では、ベースベクトライザー/分類器アーティファクトがXCP宛先から具体化され、段階的に調整され、 `text_classifier_tuned.bin`および `fine_tune_metrics.json`として公開されました。

    • `inferencing`で、調整済みのテキスト分類器とベースライン回帰モデルおよびベクトル化器がXCP宛先から具体化され、予測が生成されました。

[[10-2-2-local-fallback-and-non-xcp-execution-validation]]
=== 10.2.2 ローカルフォールバックと非XCP実行検証

このテスト領域では、XCPデータモビリティが無効になっている場合のパイプラインの動作を検証します(enable_xcp=false）。

  • 目的： SSH接続、リモートXCPホスト、またはXCP認証プロファイルを必要とせずに、直接ローカルで準備されたデータパスを使用してパイプラインがシームレスに動作することを確認します。

  • テスト手順： トリガーされたパイプラインを `enable_xcp=false`およびデフォルトのS3/ローカルパスで実行しました。

  • 検証結果：

    • XCPのプリフライトおよびコピー処理は安全にスキップされました。

    • model_training、 fine_tuning、および `inferencing`は、ローカルに準備されたデータディレクトリから直接読み込み、アーティファクトをローカルに公開します。

    • XCPを無効にした際に、XCP S3認証情報の解決エラーやSSHプリフライトエラーが発生しなかったことを確認しました。

[[10-2-3-performance-and-tier-comparison-ontap-s3-vs-lustrefs]]
=== 10.2.3 パフォーマンスとティアの比較（ONTAP S3 対 LustreFS）

このテスト領域では、ONTAP S3 オブジェクトストレージと LustreFS 並列ファイルシステム階層間の I/O レイテンシ、検出オーバーヘッド、およびトレーニングスループットを評価します。

  • 目的： LustreFS を使用した Eシリーズと、ONTAP S3 アクティブトレーニングティアを使用した ONTAP AFF/AFX のパフォーマンス特性を定量化する。

  • テスト手順： 同一のデータセットサイズ（14,400+ 行、複数ファイルのテキスト/表形式入力）で、ファイル検出時間、トレーニングデータセットの読み込み遅延、および成果物の公開/具体化時間を測定しました。

  • 検証結果：

    • LustreFS Tier: モデルトレーニング中のファイル検出オーバーヘッドが低く、ランダムアクセス読み取りレイテンシが高速であることが実証されており、ファイル数が多く、GPU 負荷の高い並列トレーニングワークロードに最適です。

    • ONTAP S3 ティア： シンプルなマルチプロトコル管理で高いスループットを提供し、クライアント側ファイルシステムのマウントを必要とせずに、コスト重視の弾力的なアクセスが可能なアクティブストレージに最適です。

[[10-2-4-failure-recovery-and-training-checkpoint-validation]]
=== 10.2.4 障害回復とトレーニングチェックポイントの検証

このテスト領域では、 `model_training`を対象としたチェックポイント再開システムを検証します。

  • 目的： パイプラインリカバリが、以前の成功したトレーニング実行を正確に検出し、アーティファクトの整合性を維持しながら冗長な計算をスキップすることを確認します。

  • テスト手順：

    1. パイプラインを `checkpoint_enabled=true`と `checkpoint_store="formatted_s3"`で実行しました。

    2. タスクの失敗または再実行のシミュレート（ `training_checkpoint_reuse_mode="resume_if_exists"`を使用）。

    3. テスト済み `verify_only`および `off`再利用モード。

  • 検証結果：

    • `resume_if_exists`が設定され、有効なチェックポイント JSON + すべてのコアアーティファクトが S3/LustreFS に存在していた場合、 `model_training`は決定 `RESUMED_FROM_CHECKPOINT`とともに即座に終了し、 `[checkpoint] resume_summary: decision=RESUMED_FROM_CHECKPOINT`をログに記録しました。

    • Downstream `fine_tuning`および `inferencing`検証済みのチェックポイント成果物を正常にマテリアライズしました。

    • `verify_only`が設定されると、ガードはトレーニングをスキップせずにアーティファクトの存在を検証しました。

[[10-2-5-scalability-and-multi-file-dataset-validation]]
=== 10.2.5 スケーラビリティと複数ファイルデータセットの検証

このテスト領域では、大規模な複数ファイルからなる表形式およびテキスト形式のデータセット全体にわたるパイプラインのスケーラビリティを検証します。

  • 目的： データセットの自動検出、Spark変換エンジンの実行、およびLakehouseテーブル形式のサポートを確認する（(delta`および `iceberg）。

  • テスト手順：

    1. StorageGRID 生データプレフィックス(s3_raw_prefix）配下の数十個のCSV/Parquetファイルに対して取り込みと準備を実行しました。

    2. 明示的なファイル選択をテストしました s3_tabular_object_keys`自動全ファイル検出との比較(`sample_count=0）。

    3. PySparkを使用して `table_format="delta"`および `table_format="iceberg"`で準備を実行しました。

  • 検証結果：

    • Sparkの分散処理により、大規模な複数パートからなる表形式データセットの取り込み、フィルタリング、分割、およびフォーマットが正常に完了しました。

    • 自動検出機能は、有効な表形式のCSV/Parquetオブジェクトをすべて正確に識別し、表形式ではないアーティファクトを無視しました。

    • Delta LakeとIcebergのテーブル形式はどちらも正しく作成され、 `tables/`に登録され、下流のモデルトレーニングがフォーマットされた分割データを検出して読み込みました。

[[10-2-6-example-customer-evaluation-workflow-sizing-assumptions-and-validation-metrics]]
=== 10.2.6 顧客評価ワークフローの例、サイジングの前提条件、および検証指標

このワークフローは、設計が自社のAIパイプラインの成熟度、データ主権に関する要件、およびパフォーマンス目標に適合するかどうかをお客様が評価するのに役立ちます。まず代表的なデータセットと1回のパイプライン実行から始め、各受入基準が満たされた後にのみ、データ量、ファイル数、モデルの複雑さ、および同時実行数を増やしてください。結果を `run_stamp`ごとに記録し、ONTAP S3とLustreFSの比較で同じ入力データと設定を使用するようにしてください。

評価ステップ ワークフローの例 サイズ決定の前提条件／決定事項 検証指標と受容証拠

1.基準値を設定する

限定されたサンプルに対して `enable_xcp=false`を使用して、Python準備パスを実行します。

セクション7.1.1の参照検証環境を、初期の機能ベースラインとして使用してください。

DAGの完了成功、入力行数と出力分割数、モデルメトリクス、タスク実行時間、CPU、メモリ、ローカルディスクの使用率。

2.データ主権の検証

生データ、準備済みデータ、アクティブなトレーニングデータ、およびアーカイブは、承認済みのストレージエンドポイントとリージョンに保管してください。各階層の認証情報および保持ポリシーを確認してください。

データを移動する前に、許可された場所、アクセスロール、暗号化要件、および保持ポリシーを定義してください。

エンドポイント、バケット、プレフィックス、リージョンは、有効な構成とマニフェストに記録されている。最小権限アクセス検証。アーカイブおよび削除ポリシーの証拠。

3.データモビリティの検証

XCP を有効にして、同じ準備済み実行を ONTAP S3 にコピーし、次に LustreFS に繰り返します。

準備済みの実行、アーティファクト、作業スペース、および同時実行のために、10 GbE 接続と十分な宛先容量を確保してください。

XCP 完了ステータス、コピーされたバイト数とファイル数、コピー時間とスループット、ソース/宛先ファイル数とチェックサムまたはマニフェスト比較、プリフライトの成功。

4.トレーニング層への適合性を検証する

選択した各宛先に対して、同じデータセットとモデル設定を使用して、トレーニング、ファインチューニング、および推論を実行します。

オブジェクトベースのワークフローには ONTAP S3 を使用し、並列トレーニング I/O やファイル数の多さが正当化される場合は、E シリーズと LustreFS を使用します。

データセットの検出と読み込み時間、トレーニング、ファインチューニング、推論の所要時間、成果物の公開/具体化の所要時間、該当する場合の CPU/GPU 使用率、モデル品質の一貫性。

5.スケールと回復を検証する

すべての行に対して増加 `sample_count`させ、ファイル数と同時実行数を増やし、チェックポイントの再利用とアーカイブをテストします。

保持される実行スコープのデータセットとアーティファクトのサイズ容量および将来の拡張のための余裕；SparkおよびAirflowの同時タスクに必要なCPUとメモリのサイズを算出する。

エンドツーエンドの経過時間、実行成功率、キュー時間、チェックポイント再開の決定と経過時間、アーカイブの完全性、実行ごとのストレージ増加量、リカバリ時間目標（RTO）の達成率。

評価を開始する前に、お客様はエンドツーエンドの実行時間、XCP スループット、トレーニングデータの読み込み時間、最大同時実行数、復旧時間、およびストレージ保持時間に関する定量的な目標を定義する必要があります。測定されたベースラインと各スケールテストの結果をこれらの目標値と比較し、アーキテクチャが意図されたワークロードと運用要件を満たしているかどうかを判断する必要があります。