1.　序論

データ処理や機械学習の規模増大に伴い，必要なデータ量や計算量が増加している．そのため，データを蓄積するための大容量ストレージや高速な演算を行う高性能なGPUの重要性が増している．一方，機密性の高いデータを複数の利用者で共有するストレージへの保管を禁止するなどの法令やセキュリティポリシなどの理由から，プライバシ情報などの機密データを取り扱う研究者が多数の利用者による共有利用が前提となる高性能計算機を利用することが困難な現状がある．さらに，そのような高性能計算機は一般的にCPUやメモリなどの構成は静的であり，利用者の様々な要求に対してその資源構成を柔軟に変更することは難しい．本稿では，これらの2点の問題に着眼し，機密データを扱うローカルのサーバに対して，利用者である研究者の必要に応じて遠隔地にプール化された高性能なGPUを接続し，高性能計算処理ができる環境を目指す．本稿では，当該目標を視野に研究者が保有するサーバに対して遠隔地のデータセンタに配備されているGPUを接続するキャンパス規模のGPU-as-a-Service（GPUaaS）の実現を目指している．

GPUaaSはハードウェア（CPU, GPU，メモリなど）を種類別に集約し，資源要求に応じてハードウェアを再構成する資源分離[1]-[5]の考えに基づいている．多くの既存研究では，同一ラック内や同一データセンタ内のハードウェアを対象とする資源分離に着眼がある．一方，キャンパス規模のGPUaaSはデータセンタ内に止まらない広域環境を対象とする資源分離に着眼がある．図1のように，キャンパス規模のGPUaaSは研究者のサーバに対して広帯域なネットワークを経由しデータセンタに配備したGPU BoxのGPUを接続する．この技術により，研究者は機密データを手元のセキュアなサーバ上に格納した状態で，遠隔の高性能なデータセンタ向けGPUを利用することが可能となる．また，多くの研究者は，予算の都合，手元のサーバにコンシューマ向けGPUを搭載している．GPUaaSにより高性能なGPUが利用可能になることにより，アプリケーションの実行時間を短縮できる可能性がある．

本研究では，敷地面積が約1 km²の大阪大学吹田キャンパスを対象とし，キャンパス内の任意の研究室からデータセンタに接続できることを想定し，サーバとGPU間の最大ケーブル長を2 kmと仮定する．数メートルのケーブル長制限があるバス規格PCIeでは図1に示すGPUaaSの実現は技術的に不可能である．そのため，本研究では，PCIe信号をEthernetネットワーク上に伝送することで，PCIe信号の伝送距離を延長する仮想化技術ExpEther [6]を採用する．この技術により，GPUaaSは光ファイバ上でPCIe信号の伝送を実現する．

しかし，光ファイバ上でPCIe信号を低遅延で伝送できるとしても，CPU-GPU間のケーブル長は大きく，CPU-GPU間の通信遅延や帯域幅がアプリケーションの実行に影響を与える可能性が考えられる．事実，ラックを跨いだCPU-GPU間の通信遅延でさえサーバ内のCPU-GPU間の通信遅延の約10倍に及ぶ[7]．このようなCPU-GPU間の通信性能の低下に起因してアプリケーション性能の低下も想定されることから，研究者のコンシューマ向けGPUでのアプリケーションの実行時間と比較して，GPUaaS環境下でのアプリケーションの実行時間が短縮されるか不明である．それゆえ，GPUaaS環境下でのアプリケーションの実行時間がローカルのGPUでの実行時間より短い際，広域環境下におけるGPUaaSが実用上許容可能であると判断する．ローカルのGPUとGPUaaS環境下でのアプリケーションの性能を検証し，広域環境下におけるGPUaaSが実用上許容可能かどうか検証する．

具体的に，本研究では，広域環境下におけるGPUaaS環境を想定し，ExpEtherを利用してローカルのサーバに対してデータセンタに配備されているGPUを接続する実験環境を構築する．そのうえで，GPUの性能評価ベンチマークとして有名なRodinia [8]から3つのアプリケーションと機械学習の性能測定ベンチマークとして代表的なMLPerf [9]から6つのアプリケーションを選定し，当該アプリケーションを対象として性能評価を行う．評価結果から，GPUaaS環境にてアプリケーションの性能がどのように変化するかを考察する．

本稿の構成を示す．2章では既存研究と本研究の違いを示す．3章ではGPUaaSの概要とExpEtherの詳細を説明し，4章でGPUaaS環境におけるアプリケーションの性能を評価する．5章で結論を述べる．

2.　関連研究

本章では，サーバに直接搭載されていないリモートのGPUをアプリケーション実行時に利用可能にする技術を調査し，広域環境下でのGPUaaSの実現にExpEtherが必要な理由を述べる．その後，ローカルのサーバとリモートのGPUを接続することで生じるCPU-GPU間の通信遅延の増加および帯域幅の低下がアプリケーションの実行時間に及ぼす影響を評価した既存研究を示す．これにより，既存研究で用いられた評価方法ではなく，ExpEtherを利用するGPUaaS環境においてアプリケーションの性能の評価が必要な理由を述べる．

2.1　GPUに関する資源分離

rCUDA [10]およびCricket [11]はリモートのGPUを利用してCUDAアプリケーションの実行を可能にするフレームワークである．これらのフレームワークはCUDA APIをフックし，リモートのGPUに演算を委譲する．しかし，CUDAはNVIDIA製GPUに固有のAPIであるため，rCUDAおよびCricketはいずれもAMD製やIntel製など，NVIDIA製以外のGPUに対応していない．

NVIDIA製以外のGPUにも対応したGPUに関する資源分離を実現するため，PCIeスイッチで構成されたPCIeネットワークを利用する手法も提案されている[12], [13]．PCIeネットワーク下では，サーバからリモートのGPUへの通信遅延はサーバに搭載されたGPUへの通信遅延とほぼ同じであり，PCIeネットワーク下でサーバとリモートのGPU間の通信遅延の劣化が低いことが示された．しかし，PCIeの規格ではケーブル長は数メートルであるため，PCIeネットワークで広域環境下におけるGPUaaSを実現することは困難である．

ExpEtherはPCIeやEthernetのレイヤーでローカルのサーバとリモートのGPU間を接続するため，開発企業に依存せずPCIeに対応している多くのGPUに適用可能である．さらに，ExpEtherはPCIe信号をEthernetネットワーク上に伝送するため，PCIeネットワークより広域なネットワークを構築することが可能である．

2.2　GPUに関する資源分離におけるアプリケーションの性能評価

CUDA APIのフックおよびネットワークエミュレータを利用してCPU-GPU間の通信遅延や帯域幅を変更し，リモートのGPUを利用してアプリケーションを実行する際の性能の変化を評価する方法が提案されている[14], [15]．CUDA APIをフックする提案[14]では，CPUメモリとGPUメモリ間でデータ転送を行うmemcpy実行時に遅延を挿入し，LAMMPSとCosmoFlowの実行時間を評価している．ネットワークエミュレータを利用する提案[15]ではCPU-GPU間の通信遅延と帯域幅を変更し，機械学習に関するアプリケーションの実行時間を評価している．

このような手法でCPU-GPU間の通信性能を変更する場合，CUDA APIの処理内容が変更されるためアプリケーションの正確な性能を評価することができない．例として，既存手法にて非同期CUDA APIの処理がどのように変更されるかを説明する．一般的に，非同期CUDA APIが呼び出された際，非同期CUDA APIがGPUに演算命令を送信した後，CPUはGPUでの演算の完了を待たずに演算を再開する．しかし，既存手法では，非同期CUDA APIが呼び出された際，CPUは挿入する遅延分sleepを実行した後，GPUに演算命令を送信する．

ExpEtherはCUDA APIの処理内容を変更せず，リモートのGPUでアプリケーションの実行を可能にする．そのため，既存手法と比較して，ExpEtherを利用する実験環境はGPUaaS環境におけるアプリケーションの正確な性能評価を可能にする．

3.　想定するGPUaaS環境

3.1　GPUaaS

図1に筆者らが想定するGPUaaS環境を示す．複数のGPUが配備されているGPU Box（図1a）は制御システム（図1c）からの指示に従い研究者のサーバに対して搭載しているGPUを接続または切断する機器である．GPU Box群と各研究室のサーバ間は広帯域なExpEtherネットワーク（図1b）を経由して接続される．GPUaaSはExpEtherにより研究者のサーバとGPU BoxのGPU間の通信を実現する．

一般的に，研究者がデータセンタでアプリケーションを実行する際，研究データをデータセンタ内の共有ストレージに格納する．権限の設定誤りなどにより，研究データが他の利用者にアクセスされる可能性があり，セキュリティ上の危険性が存在する．一方，ExpEtherを用いたGPUaaS環境では，研究者が保有するサーバに研究データを格納するため，研究データが他の利用者にアクセスされない．また，研究者のサーバとGPU BoxのGPU間の通信は専用線を経由し，ExpEtherにより暗号化・復号化されるため，サーバとGPU間の通信が盗聴・改竄される危険性は低い．

3.2　ExpEther

ExpEther [6]はPCIeの標準規格に準拠し，サーバに導入されたOSやドライバ，ハードウェアなどを一切変更する事なく，サーバに対して遠隔のI/Oデバイス（GPUやSSDなど）の接続を可能にする技術である．ExpEtherにより利用者はサーバから最大2 km遠隔にあるI/Oデバイスをサーバに直接搭載されたI/Oデバイスのように利用することが可能になる．

図2にExpEtherの接続構成の例を示す．サーバとI/O BoxはそれぞれExpEtherボードを搭載し，ネットワークで接続される．サーバに搭載されているExpEtherボードはCPUから送信されたPCIe TLP（Transaction Layer Packet）をEthernetフレームにカプセル化し，対向のI/O Boxに搭載されているExpEtherボードはEthernetフレームからPCIe TLPを取り出し，I/Oデバイスへ送信する．

ExpEtherは標準のEthernetを拡張した独自のEthernetのプロトコルを採用している．図3にExpEtherで用いる独自のEthernetフレームのフォーマットを示す．図3bが示すタイプは上位層のプロトコルを示し，0x8100が利用される．ExpEther用ヘッダは通常のEthernetフレームのペイロードにあたる部分で構成し，暗号化やフロー制御，帯域制御，パケットロス検知などに必要なデータを含む．

ExpEtherはEthernetネットワークにおいて低遅延かつロスレスな通信を実現するために，遅延ベースのフロー制御とGo-Back-N方式の再送制御を備える．遅延ベースのフロー制御を行うため，ExpEtherは送信元でフレームごとにタイムスタンプを付与し，受信側から応答されるデータを用いてRTTを計算する．このRTTを元にフロー制御を行うことで，ExpEtherはEthernetスイッチのバッファでEthernetフレームを保持する時間であるキューイング遅延を最小化するとともに輻輳を回避する．さらに，Go-Back-N方式の再送制御により，ExpEtherは応答確認（ACK）を待たずに複数のEthernetフレームを送信する．ExpEtherの受信側が誤りを検知する，または送信元がEthernetフレームの応答確認を受信できない場合，送信元が該当するフレーム以降を再送信する．

ExpEtherはセキュアな通信を実現するため，ExpEtherボードで80 bit鍵/128 bit鍵のブロック暗号TWINE [16]によりEthernetフレームの暗号化・復号化を行う．TWINEは軽量な暗号のため，暗号化によりEthernetフレームのサイズは増加しない．暗号化・復号化処理はワイヤレートのスループットで実行可能であり，遅延は数十ns程度である．既存研究より，GPUaaS環境下ではCPU-GPU間の通信遅延は数μs以上であり，暗号化・復号化に要する時間より十分大きい[7]．そのため，暗号化・復号化がアプリケーションの実行時間に与える影響は無視できるほど小さいと考えられる．

4.　評価

サーバに搭載されたCPUとGPU同士で通信する場合と比較して，筆者らが想定するGPUaaS環境下ではCPU-GPU間の通信遅延が増加し，帯域幅が低下する可能性がある．4.1節では，CPU-GPU間の通信性能が異なる評価環境を説明し，4.2節では，評価で用いるアプリケーションを説明する．4.3節では，評価環境におけるCPU-GPU間の通信性能を実測する．4.4節では，評価環境におけるアプリケーションの性能を評価する．4.5節では，広域環境におけるGPUaaSの実用化を想定し，CPU-GPU間の通信距離がExpEtherによる通信距離の上限である2 kmのときに，アプリケーションの性能がどのように変化するかを推定する．その後，広域環境下におけるGPUaaSが実用上許容可能かどうかを考察する．

4.1　評価環境

GPUaaS環境にてCPU-GPU間の通信性能の変化によるアプリケーションの性能の変化を評価するため，CPU-GPU間の通信距離が異なる評価環境を構築した．各サーバの仕様を表1に示す．さらに，GPUの演算性能の差異がアプリケーションの性能にどのような影響を及ぼすかを評価するため，評価環境にNVIDIA H100 GPUとNVIDIA L4 GPUという演算性能の異なる2種のGPUを配備した．H100とL4の演算性能について，Tensorコア利用時のTF32はそれぞれ835 TFLOPSと120 TFLOPSである．図4に構築した評価環境を示す．サーバ1にL4，サーバ2にH100, GPU BoxにL4とH100をそれぞれ搭載した．最大10個のPCIeデバイスを搭載し，計算ノードに対して動的に割当可能なH3社のFalcon 5012をGPU Boxとして利用した．CPU1とL4間およびGPU Box内のPCIeスイッチとL4間はそれぞれPCIe 4.0 x16（理論帯域幅256 Gbps）で接続された．また，CPU2とH100間，および，GPU Box内のPCIeスイッチとH100間はそれぞれPCIe 5.0 x16（理論帯域幅512 Gbps）で接続された．各サーバ内のCPUとExpEtherボード間およびGPU Box内のPCIeスイッチとExpEtherボード間はそれぞれPCIe 3.0 x16（理論帯域幅128 Gbps）で接続された．各サーバとGPU Boxにそれぞれ搭載されているExpEtherボード間はNVIDIA Mellanox SN4600Vスイッチと100 Gbpsの光ファイバの専用線により接続した．データセンタ内のサーバとGPU Box間のケーブル長の合計は20 mであった．また，研究室のサーバとデータセンタのGPU Box間のケーブル長の合計は約200 mであった．なお，本評価環境ではExpEtherボードの暗号化機能を無効化した．

CPU-GPU間の通信性能の変化によるアプリケーションの性能の変化を正確に評価するためには，各評価環境におけるアプリケーションの実行時間に占めるCPUとGPUの演算時間をほぼ同じにする必要がある．しかし，資源的な制約でCPU1とCPU2はコア数と基本動作周波数が異なる．さらに，アプリケーションの実行中にCPUとGPUの動作周波数が変動する可能性がある．そのため，評価環境によって，アプリケーションの実行時間に占めるCPUおよびGPUの演算時間が大きく異なる可能性がある．

まず，CPUのコア数の差による演算性能差を解消するため，アプリケーションを修正し，アプリケーションが利用可能なコア数を32に制限した．評価で用いるアプリケーションはOpenMPまたはPythonを採用している．OpenMPの環境変数OMP_NUM_THREADSおよびPythonのosモジュールが提供するsched_setaffinity関数を利用し，アプリケーションが利用するCPUのコア数を設定した．

次に，CPUとGPUの動作周波数の変動を抑制するため，高負荷時でも常的に維持可能なCPUとGPUの動作周波数を調査した．調査にあたり，CPUやGPUに高負荷を印加するFIRESTARTER [17]を利用した．調査結果から，CPU1とCPU2の動作周波数をそれぞれ2100 MHz, L4の動作周波数を765 MHz, H100の動作周波数を1035 MHzに固定した．CPUの動作周波数はIntel P-State^*1で設定した．また，GPUの動作周波数はNVIDIA System Management Interface^*2で設定した．

4.2　アプリケーション

アプリケーションの性能評価では，実アプリケーションを模擬したGPU向けベンチマーク集Rodinia [8]と機械学習に関するアプリケーションの実行時間を評価するベンチマーク集MLPerf^*3からアプリケーションを選定した．Rodiniaを構成する13種類のアプリケーションからleukocyteとstreamcluster, sradという実行時間に対するCPU-GPU間通信時間の割合が異なる3つのアプリケーションを選定した．leukocyteは血管の動画内の白血球を追跡するアプリケーション，streamclusterはストリーミングデータに対してk-meansでクラスタリングを行うアプリケーション，sradは画像に対してステンシル計算でノイズ除去を行うアプリケーションである．また，先行研究[15], [18]で用いられたアプリケーションBERTとSSD, ResNetをMLPerfから選定した．BERTは自然言語処理，SSDは物体検知，ResNetは画像分類に関する機械学習アプリケーションである．

アプリケーションの実行時間とCPU-GPU間通信時間の観点から，アプリケーションの計算特性を説明する．CPU-GPU間の通信時間はCPUメモリとGPUメモリ間でデータ転送を行うmemcpyの合計実行時間として計算した．GPUを利用するアプリケーション向けプロファイラNVIDIA Nsight Systems^*4を利用し，memcpyの実行時間を取得した．コード1にNsight Systemsを用いたアプリケーションの実行方法を示す．表2にPCIe接続環境（H100）とPCIe接続環境（L4）下での実行時間に対してCPU-GPU間通信時間が占める割合を示す．sradとstreamclusterはCPU-GPU間通信時間の割合が他のアプリケーションと比較して高いことが分かった．また，sradとstreamcluster, SSDの推論を除く6つのアプリケーションはCPU-GPU間通信時間の割合が1%以下と非常に小さいことが分かった．

4.3　CPU-GPU間の通信性能

CPU-GPU間の通信距離やGPUの違いによりCPU-GPU間の通信性能がどのように変化するかを確認するため，評価環境におけるCPU-GPU間の通信遅延および帯域幅を計測した．NVIDIAが公開している帯域幅計測ツールnvbandwidth^*5を利用し，CPUメモリからGPUメモリへのデータ転送（HtoD）とGPUメモリからCPUメモリへのデータ転送（DtoH）の帯域幅を計測した．これらの計測結果はCUDAによるオーバーヘッドを含む．また，ExpEtherボードの機能を利用し，ExpEtherボード間のRTT（Round Trip Time）を計測した．なお，PCIe接続環境下でのCPU-GPU間通信はExpEtherボードを経由しないため，RTTを計測していない．

表3に計測結果を示す．PCIe接続環境（L4）とPCIe接続環境（H100）では，帯域幅（HtoD）はそれぞれ200.8 Gbpsと433.4 Gbps，帯域幅（DtoH）はそれぞれ210.8 Gbpsと455.8 Gbpsであった．PCIe接続環境（L4）の実測帯域幅は理論帯域幅（PCIe 4.0 x16）の78%であった．また，PCIe接続環境（H100）の実測帯域幅は理論帯域幅（PCIe 5.0 x16）の85%であった．ラック内接続環境（L4）とGPUaaS接続環境（L4）では，RTTはそれぞれ1.625 μsと3.640 μs，帯域幅（HtoD）はそれぞれ44.0 Gbpsと33.6 Gbps，帯域幅（DtoH）はそれぞれ30.6 Gbpsと16.1 Gbpsであった．ラック内接続環境とGPUaaS接続環境では，L4とH100のGPUに関わらず，RTTの増加に伴い，帯域幅が低下していることが確認できた．

4.4　評価結果

CPU-GPU間の通信性能の変化によるアプリケーションの性能の変化を評価した．本評価では，各アプリケーションを5回ずつ実行し，実行時間の平均を用いる．図5に各評価環境におけるアプリケーションの実行時間を示す．まず，同一機種のGPUを利用する場合，CPU-GPU間の通信性能の変化により，アプリケーションの実行時間がどのように変化するかを説明する．PCIe環境（H100）での実行時間に対するGPUaaS環境（H100）での実行時間の増加率が高いアプリケーションは順にsradとstreamclusterであり，増加率はそれぞれ562%と40%であった．一方，実行時間の増加率が最も低いアプリケーションはResNetの訓練であり，PCIe環境（H100）とGPUaaS環境（H100）において実行時間はほぼ同じであった．

GPUaaS環境においてアプリケーションの実行時間の増加率は実行時間に対するCPU-GPU間通信時間の割合に関連すると考えられる．表2よりsradとstreamclusterのCPU-GPU間通信時間の割合はそれぞれ45.3%と9.6%であり他のアプリケーションと比較して高い．一方，ResNetの訓練のCPU-GPU間通信時間の割合は0.25%とわずかであった．そのため，GPUaaS環境では，実行時間に対するCPU-GPU間通信時間の割合が高いアプリケーションの性能は大きく低下するが，CPU-GPU間通信時間の割合が低いアプリケーションでは性能低下はわずかであると判明した．

次に，CPU-GPU間の通信性能が同じ場合，高性能なGPUを利用することでアプリケーションがどの程度高速化されるかを説明する．GPUaaS環境（L4）での実行時間に対するGPUaaS環境（H100）での実行時間の短縮率について，SSDの訓練が最も大きく84%であり，streamclusterが最も小さく11%であった．SSDの訓練とstreamclusterについて，GPUaaS環境（L4）での実行時間に対するGPU演算時間の割合はそれぞれ98%と3%であった．そのため，GPUaaS環境下にて，高性能なGPUを利用することにより，GPUの演算が主要なアプリケーションの実行時間は大幅に短縮されると判明した．

4.5　広域環境下におけるGPUaaSの実用性

4.4節の評価結果に基づいて，H100を対象としCPU-GPU間の通信距離がキャンパス規模のGPUaaS環境において想定する最大の2 kmである場合に，アプリケーションの性能がどの程度変化するかを推定した．CPU-GPU間の通信距離に比例してアプリケーションの性能は変化すると仮定した．PCIe接続環境（H100）とラック内接続環境（H100），GPUaaS環境（H100）でのアプリケーションの実行時間に基づいて，最小二乗法によりCPU-GPU間の通信距離に対する実行時間の変化を推定した．図5の凡例「GPUaaS（ケーブル長=2 km，推定）」はケーブル長が2 kmのときに推定される実行時間を示す．

本研究が想定するGPUaaSでは研究者が管理するサーバにH100などデータセンタ用の高性能なGPUを接続する．一方，研究者が管理するサーバに備えられているGPUの多くはワークステーション用のGPUのため，データセンタ用のGPUと比べ演算性能が低い．そのため，GPUaaS環境下で高性能なGPUを利用することによるアプリケーションの実行時間の短縮効果が，CPU-GPU間の通信性能の低下によるアプリケーションの実行時間の増加効果を上回る可能性がある．たとえば，BERTの訓練の実行時間はPCIe接続環境（L4）とGPUaaS環境（H100，ケーブル長=2 km，推定）下では，それぞれ612秒と246秒であり，GPUaaS環境のほうが約2.5倍高速であった．一方，sradの実行時間はPCIe接続環境（L4）とGPU環境（H100，ケーブル長=2 km，推定）下では，それぞれ95秒と563秒であり，PCIe接続環境の方が約5.9倍高速であった．表2より，BERTの訓練は実行時間に対するCPU-GPU間通信時間の割合が低い．一方，sradは実行時間に対するCPU-GPU間通信時間の割合が高い．これらの結果から，アプリケーションのCPU-GPU間通信時間の割合が低い場合，広域環境下におけるGPUaaSは実用上許容可能であると言える．

5.　結論

本研究では，研究者が管理するサーバに対してデータセンタに配備されたGPUを接続するGPUaaS環境下にてアプリケーションの性能評価を行った．サーバと遠隔のGPU間の通信を実現するため，PCIe信号をEthernetネットワーク上に伝送することでPCIe信号の伝送距離を拡張するExpEtherを用いて，ローカルのサーバに対してリモートのGPUを接続する評価環境を構築した．

評価結果より，GPUaaS環境において，実行時間に対するCPU-GPU間通信時間の割合が低いアプリケーションの性能低下は軽微であると判明した．さらに，この評価結果に基づき，サーバとGPU間のケーブル長が2 kmのとき，アプリケーションの性能がどの程度低下するかを推定した．これらの評価結果と推定結果から，アプリケーションのCPU-GPU間通信時間の割合が低い場合，広域環境下におけるGPUaaSは実用上許容可能であると判明した．

本研究では，ExpEtherを利用してサーバに対して1基のGPUを接続し，GPUaaS環境におけるアプリケーションの性能低下を評価した．サーバに対して複数のGPUを接続してアプリケーションを実行する場合，CPU-GPU間通信だけでなくGPU-GPU間通信も生じる．そのため，GPU-GPU間の通信遅延や帯域幅がアプリケーション性能に影響を与えると想定される．GPUaaS環境下では，GPU-GPU間通信は複数の経路が考えられる．たとえば，サーバを経由するGPU-GPU間通信とサーバを経由せずEthernetスイッチで折り返すGPU-GPU間通信，GPU Box内のPCIeスイッチで折り返すGPU-GPU間通信が考えられる．今後，GPU-GPU間通信の経路の違いがアプリケーションの性能にどのような影響を及ぼすか評価する必要がある．

謝辞　本研究はJSPS科研費JP25K15137, JST国家戦略分野の若手研究者および博士後期課程学生の育成事業（博士後期課程学生支援）JPMJBS2402および日本電気株式会社と大阪大学の共同研究「計算需要・ニーズに応じたオンデマンド広域分散型計算環境構築に関する研究」の支援を受けた．