Platform For AI:Lingjun ローカルキャッシュアクセラレーション

基本概念

ローカルキャッシュには、次の機能が含まれます。

• 高速キャッシング：コンピュートノード上のローカルディスクを使用して読み取りキャッシュを構築し、データセットとチェックポイントへのアクセスを高速化し、データアクセスレイテンシを削減します。

• 水平スケーリング：キャッシュスループットはコンピュートノード数に比例して線形にスケーリングし、数百から数千のノードで構成されるクラスターをサポートします。

• RDMA 高帯域幅アクセラレーション：RDMA (Remote Direct Memory Access) プロトコルを使用して、高い同時実行性のデータ読み取りにおいて高速ネットワーク帯域幅を最大限に活用し、スループットを向上させます。

• データウォームアップ：トレーニングジョブの開始前に指定されたデータをローカルキャッシュにロードし、最初のエポックでのコールドスタート遅延を防ぎます。

• クライアント側の帯域幅制限：各 DLC ジョブクライアントの読み取り帯域幅に上限を設定し、単一のジョブが過剰なストレージ帯域幅を消費して他のジョブに影響を与えることを防ぎます。

• サーバーレス運用：ワンクリックで有効化または無効化できます。コード変更は不要です。この機能は非侵襲的であり、運用メンテナンスを必要としません。

ユースケース

ローカルキャッシュは、データセットが 1 回のパスで読み取られるデータよりもはるかに大きく、データが繰り返しアクセスされるマルチエポックトレーニングジョブに適しています。RDMA アクセラレーション、データウォームアップ、クライアント側の帯域幅制限は、それぞれ異なるトレーニング特性に対応しており、必要に応じて組み合わせることができます。

制限事項

• 対応ストレージ：Object Storage Service (OSS) および CPFS (Cloud Parallel File System) がサポートされています。

• 適用可能なリソース：Lingjun コンピューティングリソースのみ。有効にすると、コンピュートノードリソースが消費されます。1 つのファイルシステムまたは OSS バケットをマウントすると、ノードあたり 4 vCPU と 14 GB のメモリを使用します。追加のマウントごとに 1 vCPU と 2 GB のメモリを使用します。有効にする前にリソースを確保してください。

• RDMA リソース消費：RDMA モードでは、1 つのファイルシステムまたは OSS バケットをマウントすると、ノードあたり 8 vCPU と 16 GB の RAM を使用します。追加のマウントごとに 1 vCPU と 2 GB のメモリを使用します。ノードには RDMA ネットワークカードが必要です。高スペックの Lingjun ノードはデフォルトでこれをサポートしています。

• 容量とエビクションポリシー：最大キャッシュ容量は Lingjun インスタンスタイプによって異なります。エビクションポリシーは LRU (Least Recently Used) です。

• アクセラレーション範囲：読み取りアクセラレーションのみ。書き込み操作は高速化されません。

• データ可用性：高可用性は保証されません。キャッシュされたデータが失われる可能性があります。重要なトレーニングデータは速やかにバックアップしてください。

• 最初のエポックのパフォーマンス：最初のエポックでは、ストレージインスタンス (OSS や CPFS など) から読み取り、キャッシュに書き込むため、ストレージから直接読み取るよりもわずかに遅くなります。その後のエポックでは、ローカルキャッシュから直接読み取るため、より高速になります。最初のエポックの遅延を回避するには、データウォームアップを使用してください。

ローカルキャッシュアクセラレーションの有効化

ローカルキャッシュアクセラレーションを有効にするには、次の手順を実行します。

1. リソースクォータのローカルキャッシュを有効にします。

2. セキュリティグループのインバウンドルールを設定します。

3. キャッシュを有効にした DLC ジョブを作成します。

4. オプションで RDMA アクセラレーション、クライアント側の帯域幅制限、データウォームアップを設定します。

   ステップ 1：リソースクォータのローカルキャッシュの有効化

   1. 左側のナビゲーションペインで、リソースクォータ > Lingjun リソース をクリックし、目的のクォータ名を見つけてクリックすると管理ページが開きます。

      説明

      マルチレベルのネストされたクォータの場合、トップレベルクォータでのみローカルキャッシュを有効化できます。

   2. [Local cache] タブに切り替えて、[Local cache acceleration] をオンにし、キャッシュするストレージパスを設定します。キャッシュパスは、トレーニングデータが存在するストレージディレクトリを指す必要があります。

      

   3. RDMA 高速化を使用するには、キャッシュ設定ページで RDMA 対応 スイッチをオンにします。

   ステップ 2：セキュリティグループのインバウンドルールの設定

   エンタープライズセキュリティグループの場合、キャッシュサービスが VPC ネットワーク経由で通信できるようにインバウンドルールを設定します。

   1. リソースクォータページで、ネットワーク情報セクションでセキュリティグループ名または ID を確認します。

   2. そのセキュリティグループに移動します。セキュリティグループのタイプが [Enterprise] の場合、次の設定でインバウンドルールを追加します。

      • 承認ポリシーを [Allow] に設定します。

      • 優先度を [1] に設定します。

      • プロトコルを [Custom TCP] に設定します。

      • 送信元を IPv4 に設定し、VPC CIDR ブロックを入力します (例: 10.0.0.0/8)。

      • 宛先ポート範囲を10080/(10080+n-1) および 10070/(10070+n-1) に設定します。n はストレージサービスエントリの数 (n ≤ 10) を表します。たとえば、4 つのストレージサービスが設定されている場合、ポート 10080/10083 と 10070/10073 を開放します。

   説明

   ソースは、リソースクォータで使用される vSwitch の CIDR ブロックに設定してください。宛先ポートの数は、キャッシュ設定のストレージサービスの数と一致する必要があります。

   ステップ 3：キャッシュを有効にした DLC ジョブの作成

   1. 対象のリソースクォータの Lingjun リソースを使用して、DLC (Distributed Learning Container) ジョブを作成します。

   2. DLC ジョブの ストレージのアタッチ パラメーターを設定する際、OSS マウント URI とマウントパス (例: /mnt/data/) を選択します。

   3. マウントされたストレージアドレスが設定されたキャッシュパスと一致する場合、キャッシュの使用 スイッチが自動的にオンになります (必要に応じてオフにできます)。

      

   ステップ 4：クライアント側の帯域幅制限の設定 (オプション)

   DLC ジョブの作成時に、データセットの詳細設定で mountOptions パラメーターを追加して、クライアントごとの読み取り帯域幅を制限します：

   {
     "mountOptions": "-o g_tier_DadiSdkGetTrafficLimit=3221225472"
   }

   パラメータの説明：

   • g_tier_DadiSdkGetTrafficLimit: クライアントの読み取りレート制限のしきい値 (単位: B/s (バイト/秒))。デフォルト値は 3221225472 (3 GB/s) です。

   一般的な速度制限値：

   目標制限	値 (バイト/秒)
   1 GB/s	1073741824
   3 GB/s (デフォルト)	3221225472
   4 GB/s	4294967296
   5 GB/s	5368709120

   ステップ 5：データウォームアップの設定 (オプション)

   トレーニングジョブの開始前に、データウォームアップを使用して指定されたデータをローカルキャッシュにロードし、最初のエポックでのコールドスタート遅延を回避します。

   コンソール

   ウォームアップタスクの作成

   1. ローカルキャッシュタブで、データウォームアップセクションまでスクロールし、右上隅にある[+ ウォームアップタスクの作成]をクリックします。

      

   2. ダイアログボックスで、必要に応じて次のフィールドを入力します。

      フィールド	必須	説明	推奨事項
      キャッシュデータソース	はい	ドロップダウンから選択します。ステップ 1 で設定されたストレージインスタンスのみ選択できます。	トレーニングジョブが読み取るバケットを選択します。
      ウォームアップサブディレクトリ	いいえ	選択したデータソース内のサブディレクトリを指定します。パスを手動で入力するか、フォルダアイコンをクリックして参照します。空白のままにすると、データソース全体がウォームアップされます。	データセットまたはチェックポイントのサブディレクトリを指定して、不要なトラフィックを削減します。
      マッチパターン	いいえ	サブディレクトリを基準とする正規表現。デフォルトは .*（すべてに一致）です。	たとえば、JPEG ファイルのみをウォームアップするには： .*\.jpg$。

   3. 複数のロケーションをウォームアップするには、下部にある[+ パスの追加]をクリックしてエントリをさらに追加します。行を削除するには、行の先頭にある削除アイコンをクリックします。

   4. [OK] をクリックして送信します。タスクは、データウォームアップリストにすぐに表示されます。

   キャッシュインスタンスごとに一度に実行されるウォームアップタスクは 1 つのみです。追加のタスクは FIFO 順にキューに入り、Creating ステータスのままになります。合計ウォームアップ量がキャッシュ容量を超えないようにしてください。超えた場合、データは LRU ポリシーによってエビクションされます。

   ウォームアップの進行状況の表示

   ウォームアップタスクリストには、次の情報が表示されます。タスク ID、パス (データソース + サブディレクトリ + 一致パターン)、ステータス、作成時刻、完了時刻、一致したファイル数/バイト数、失敗理由。

   ステータスの説明：

   • Creating：送信され、実行待ちキューに入っています。

   • Running：ローカルキャッシュにデータをプルしています。

   • Completed：ウォームアップが完了し、キャッシュがロードされました。

   • Cancelled：手動でキャンセルされました。

   • Failed：ウォームアップが失敗しました。失敗理由を確認してください。一般的な原因：パスが存在しない、またはパターンに一致するファイルが存在しなかったこと。

   ウォームアップタスクのキャンセルまたは削除

   • 「作成中」または「実行中」ステータスのタスクを停止するには、行の末尾にある[キャンセル]をクリックします。

   • Completed または Failed レコードは監査目的でのみ保持され、直接削除できます。

   重要

   ローカルキャッシュアクセラレーションのスイッチをオフにする前に、現在のキャッシュに依存している実行中のトレーニングジョブがないことを確認してください。このスイッチをオフにすると、すべてのウォームアップレコードとキャッシュされたデータがクリアされます。

   API

   ウォームアップポートの決定

   各キャッシュ設定エントリには、10070～10079 の範囲の専用ウォームアップポートがあります。

   キャッシュインデックス	ウォームアップポート
   1 番目のキャッシュ	10070
   2 番目のキャッシュ	10071
   3 番目のキャッシュ	10072

   データウォームアップの開始

   同じクォータ配下の Data Science Workshop (DSW) または DLC インスタンスで次のコマンドを実行して、ウォームアップを開始します。

   注：ウォームアップ API は、キャッシュサービスと同じクォータ配下の DSW または DLC インスタンスからのみ呼び出すことができます。DSW インスタンスには、必要なロール権限がデフォルトで設定されており、追加の設定は不要です。

   # getDataCacheService レスポンスで isShareded = true の場合、このコマンドを使用します：
   curl -s "http://<CacheServiceId>-svc-0.t<AccountId>.svc.cluster.local.<clusterId>.t<AccountId>:<Port>/v1/warmup/load?target_path=<path1>,<path2>&pattern=<glob_pattern>"
   
   # それ以外の場合は、このコマンドを使用します：
   curl -s "http://<CacheServiceId>.t<AccountId>.svc.cluster.local.<clusterId>.t<AccountId>:<Port>/v1/warmup/load?target_path=<path1>,<path2>&pattern=<glob_pattern>"

   パラメータの説明：

   • isShareded：コンソールのクォータ詳細ページで [ローカルキャッシュ] タブに移動し、ブラウザーの開発者ツール (F12) を開き、getDataCacheService API レスポンスにある isShareded フィールドを確認します。

   • CacheServiceId: GetQuota API を呼び出して対象のリソースクォータを照会し、最上位のクォータ (第 1 レベルのリソースクォータ) のレスポンスから CacheServiceId を取得します。

   • <プライマリアカウント ID>: コンソールで、右上隅にあるユーザーアバターをクリックすると、プライマリアカウント ID が表示されます。

   • clusterId: isShareded と同じです。getDataCacheService API のレスポンスを確認してください。

   • Port：前の手順で決定されたウォームアップポートです。

   • target_path：ウォームアップするパス。複数のパスはコンマで区切り、マウントディレクトリ配下の相対パスである必要があります。たとえば、BMCPFS 上の /path1/path2 をウォームアップするには、target_path=path1/path2 と設定します。

   • pattern(オプション)：正規表現をサポートするファイルのマッチングパターンです。 たとえば、 pattern=.*.txt と指定すると、 .txt ファイルのみがウォームアップされます。

   例：

   # マウントディレクトリ内の dataset/train 下のすべての .txt ファイルをウォームアップ
   curl -s "http://cacheservice-xxxx.t10953*******.svc.cluster.local.ca076dea628***********.t10953*******:10070/v1/warmup/load?target_path=dataset/train&pattern=.*.txt"

   ウォームアップステータスの確認

   次のコマンドを実行して、ウォームアップの進行状況を確認します。

   # getDataCacheService レスポンスで isShareded = true の場合、このコマンドを使用します：
   curl -s "http://<CacheServiceId>-svc-0.t<AccountId>.svc.cluster.local.<clusterId>.t<AccountId>:<Port>/v1/warmup/stat?target_path=<path1>,<path2>&preceding_time=<minutes>"
   
   # それ以外の場合は、このコマンドを使用します：
   curl -s "http://<CacheServiceId>.t<AccountId>.svc.cluster.local.<clusterId>.t<AccountId>:<Port>/v1/warmup/stat?target_path=<path1>,<path2>&preceding_time=<minutes>"

   パラメータの説明：

   • target_path: ウォームアップリクエストで使用されるパスと同じパス。

   • preceding_time：過去 N 分間のウォームアップステータスを照会します。

   例：

   # 過去 10 分間の dataset/train のウォームアップステータスを確認
   curl -s "http://cacheservice-xxxx.t10953*******.svc.cluster.local.ca076dea628***********.t10953*******:10070/v1/warmup/stat?target_path=dataset/train&preceding_time=10"

   注意事項

   • ウォームアップ API は、キャッシュサービスと同じクォータ配下の DSW または DLC インスタンスからのみ呼び出すことができます。

   • target_path には、マウントディレクトリからの相対パスを使用してください。絶対パスは使用しないでください。

   • 多階層でネストされたリソースクォータの場合、 CacheServiceId がトップレベル (第 1 レベル) のリソースクォータから取得されることを確認してください。

   • ウォームアップは非同期で実行されます。進捗状況は /v1/warmup/stat API を使用して確認できます。

よくある質問