ラスター解析の構成

ラスター解析は、組み込みのツールや機能として、前処理、オルソ補正やモザイク処理、リモート センシング解析、数学や三角法のさまざまな演算を使用できます。 カスタム関数により、組織の解析能力をさらに強化できます。

ラスター解析機能の設計では、コラボレーションや共有が、円滑かつ簡便に行えることも考慮しました。 組織全体のユーザーが、データや処理モデルに貢献し、画像処理プロジェクトで力量を発揮し、処理結果をエンタープライズ内の個人、部門、組織全体で共有できます。

ラスター解析の概要

ArcGIS Enterprise on Kubernetes において、ラスター解析は柔軟なラスター処理、格納、共有システムで、分散コンピューティングおよび格納技術を活用しています。 ラスター解析では、ArcGIS のラスター解析ツールとラスター関数を適用するか、カスタム関数とツールを構築するか、さまざまなツールと関数を組み合わせてラスター処理チェーンを作り上げ、収集した大量のラスター データに対してカスタム アルゴリズムを実行します。 ソース データと処理結果は、要件や優先度に応じて、社内横断的に保存、公開、共有できます。

クラウド コンピューティングの能力やリソースを利用すれば、この豊富な機能をさらに強化できます。 その結果、数日から数週間もの期間を要していた画像処理ジョブや画像解析ジョブが、今や数分から数時間で終わり、広範囲に及ぶ巨大なジョブも実行できるようになりました。

ヒント:

クラウド データ格納は、オンプレミスおよびクラウドのデプロイメントでは必須です。 これは、ラスター解析の出力を格納するために使用されます。

管理者が、このプレミアム機能をサポートするのに十分なリソース クォータとワーカー ノードを割り当てていることを確認します。

ラスター解析の有効化

次の構成手順を実行するには、組織での ArcGIS の配置方法を変更することが必要な場合があります。次に進む前に、注意して調べてください。 ラスター解析を組織の機能として有効化するには、次の手順を実行します。

1. 組織に必要なラスター ストアがどちらもあることを確認してください。1 つはクラウド ストア、もう 1 つはリレーショナル ストアです。

   クラウド ストアは、解析のラスター出力を格納するために使用されます。 組織をクラウド環境にデプロイする場合は、同じクラウド プロバイダーのクラウド ストレージ サービスを使用することをおすすめします。 リレーショナル ストアは、ホスト イメージ レイヤーの作成時またはラスター解析がコレクションの出力を生成するときに、モザイク データセットを格納するために使用されます。 ラスター ストアを追加する方法については、「ラスター ストアの管理」をご参照ください。

2. ArcGIS Enterprise Manager で、サイドバーの [機能] ボタンをクリックします。

   機能ページが表示されます。

3. [ラスター解析] 切り替えボタンをオンにします。

   プロセスの有効化にはしばらく時間がかかる場合があることを示すメッセージが表示されます。

4. [有効化] をクリックします。

   ラスター解析を有効化するリクエストが送信されます。 このプロセスでは、前提条件を検証して、サポート リソースを有効化します。 次のシステム サービスが自動的に開始されます:

   • RasterAnalysisTools
   • RasterProcessing
   • RasterProcessingGPU
   • RasterRendering

機能を有効化できない場合は、上述の手順を繰り返し、ラスター ストアが追加されており、ラスター解析のライセンスが有効かつ利用可能で、システム サービスが開始していることを確認します。 ログを確認して、この機能の要件を明確化してください。

これで、ラスター解析が構成されました。 ラスター解析ツールを使用し、組織で画像をホストできるようになります。 ラスター解析とディープ ラーニングを使用する方法をご確認ください。

さらに、ラスター解析の調整方法に関するワークフローもご参照ください。

ラスター解析用の GPU リソースの有効化

ラスター解析 (特にディープ ラーニング解析と AI ツール) では、クラスターで GPU (グラフィックス処理装置) を使用できます。 GPU リソースを構成し、ディープ ラーニング モデルと推論ツールのパフォーマンスを強化できます。 ディープ ラーニングの場合、GPU は処理速度、リソース効率性、組織のスケーラビリティーを実現します。 GPU は、大規模な並列計算を処理できるため、ラスター解析とディープ ラーニングに不可欠です。 GPU がサービスごとに構成されていると、個々のサービスが両方のタスクでより適切に機能します。

組織のラスター解析用の GPU リソースを有効にするには、クラスター管理者と連携して次の手順を実行します:

1. Kubernetes クラスター内のノードに対し、GPU を有効化します。

   GPU ノードのカスタム ラベルを作成することをおすすめします。 たとえば、key に raster、value に GPU を使用してnode1 というノードをラベリングするには、次のコマンドを使用します:

   kubectl label nodes node1 raster=GPU
   

2. 管理者として ArcGIS Enterprise Manager にサイン インします。
3. ラスター解析が有効化されていることを確認します。
4. GPU を必要とするサービスが GPU 対応ノードにスケジュールされるよう、ポッドの配置設定を使用します。

   GPU ノードを利用してデータ処理を行えるラスター解析サービスには、RasterAnalysisTools と RasterProcessingGPU の 2 つがあります。 RasterProcessingGPU サービスが GPU を利用できるよう、ポッドの配置を構成することをおすすめします。 ワークフローでモデルのトレーニングを行う場合は、RasterAnalysisTools サービスのポッドの配置も構成することをおすすめします。

   1. [サービス] → [システム サービス] をクリックします。
   2. サービス名をクリックし、[ポッドの配置] をクリックします。
   3. サービスのポッドを確実に GPU ノードにスケジュールするノード アフィニティー ルールを適用するには、次の情報を [ノードのアフィニティー] セクションに入力して [追加] をクリックします:
      • [Type] - Required
      • [Key] - GPU ノードのラベリングに使用するキー (例: raster) を指定します。
      • [Operator] - In
      • [Value] - GPU ノードのラベリングに使用する値 (例: GPU) を指定します。
   4. ラスター解析ワークロードを GPU ノード上で実行し、テイントを使用してこれらのノードから他のワークロードを除外するには、[Tolerations] セクションに次の情報を指定して [Add] をクリックします:
      • [Effect] - No Execute
      • [Key] - nvidia.com/gpu
      • [Operator] - Exists

   5. [保存] をクリックし、ポッドがスケジュールされるまで待ちます。

      注意:

      ポッドのスケジュールが設定されるのを待ってから次に進むことが重要です。 スケジュールが設定される前に次に進むと、Kubernetes は GPU リクエストと配置ルールに一致する適切なノードを見つけることができないため、ポッドは保留状態のままになります。

5. GPU を使用するよう構成する必要がある各サービスに対し、GPU を有効にします。
   1. サービス ページの上部で [設定] をクリックします。
   2. [GPU の有効化] をオンにします。
   3. [保存] をクリックします。
6. 必要に応じ、他のワークロードが GPU 対応ノードにスケジュールされないよう、GPU ノードをテイントします。

   kubectl taint nodes <your-node-name> nvidia.com/gpu=Exists:NoExecute
   

ラスター解析の調整

ラスター解析で最適なパフォーマンスとスケーラビリティーを実現するには、次の推奨事項を検討してください。

• 組織を作成する場合、オブジェクト ストアにクラウド ストレージ サービスを使用します。
• ワーカー ノードを増やします。 ラスター解析などの追加されたプレミアム機能をサポートするには、アーキテクチャー プロファイルごとに最低 1 つの追加のワーカー ノードが必要です。 組織作成時に選択したアーキテクチャー プロファイルを特定し、それに応じてワーカー ノードを増やすには、管理者にお問い合わせください。 実行する解析によっては、複数ノードの追加が必要な場合があります。
• 可能な場合は、GPU 対応ノードを使用します。 必要に応じて、GPU ワークロードを GPU ノードのみで実行するようノードのアフィニティと耐障害性を構成します。 これは、ディープ ラーニングおよび AI のワークフローを実行する際にますます重要になっています。
• 追加のポッドとリソースでサービス デプロイメントを変更することによって、次に示すように、ワークフローの全体的な可用性とスループットを高めることができます。
  • ディープ ラーニングと AI を含まないワークフローでは、[RasterProcessing] サービス デプロイメントをスケーリングします。
  • ディープ ラーニング ワークフローでモデルをトレーニングするワークフローを実行する際に、RasterAnalysisTools サービス デプロイメントをスケーリングします。
  • 推論のワークフローを実行する際に、[RasterProcessingGPU] サービス デプロイメントをスケーリングします。
• 一部のラスター解析ツールは、複数のワーカー ポッドに計算を分散し、解析の実行中に一時データを書き込みます。 処理用の一時領域にデータを読み込む必要がある大規模なジョブで分散ラスター解析を実行する際は、一時的ボリュームを使用します。 詳細については、「一時的ボリュームの構成」をご参照ください。
• ラスター解析プロセスを実行するときは、ログ レベルを [デバッグ] から下げることをおすすめします。 問題のトラブルシューティングをアクティブに行うのでなければ、[警告] レベルを使用してください。 より詳細なログが必要な場合は、代わりに別のログ レベルを使用してください。
• データの処理に使用できるラスター処理サービス インスタンスの数を制御するために、並列処理ファクターを設定することを検討してください。
• 解析ワークフローのタイプおよび処理されるデータのサイズに基づいて、メモリー要件の監視と増加が必要になる場合があります。 たとえば、ディープ ラーニングと AI のワークフローでは、バッチ サイズが大きくなるとより多くのメモリーが必要になります。
• ラスター解析ツールには制限が事前に構成されています。 ツールが適切に機能するには、一部のジョブで追加の容量が必要になる場合があります。 スケーリング プロパティを編集して、さまざまなマイクロサービスのメモリーを増やすことができます。