Amazon EKS と Torch Distributed Elastic を使用した分散トレーニング

多くの業界でデータ サイズが増大しているため、分散型ディープ ラーニング モデルのトレーニングはますます重要になっています。 現在、コンピューター ビジョンおよび自然言語処理の多くのアプリケーションでは、ディープ ラーニング モデルのトレーニングが必要になっています。ディープ ラーニング モデルは、複雑さが指数関数的に増大しており、多くの場合、数百テラバイトのデータでトレーニングされています。 このような大規模なモデルのトレーニングをスケーリングするには、広大なクラウド インフラストラクチャを使用することが重要になります。

開発者は、PyTorch などのオープンソース フレームワークを使用して、直感的なモデル アーキテクチャを簡単に設計できます。 ただし、オーケストレーションの複雑さが増すため、これらのモデルのトレーニングを複数のノードにスケーリングすることは困難な場合があります。

分散モデル トレーニングは、主に次の XNUMX つのパラダイムで構成されます。

• モデルパラレル – モデルの並列トレーニングでは、モデル自体が大きすぎて単一の GPU のメモリに収まらず、モデルをトレーニングするために複数の GPU が必要です。 3 億のトレーニング可能なパラメーター (サイズは約 175 GB) を持つ Open AI の GPT-350 モデルは、この良い例です。
• データ並列 – データ並列トレーニングでは、モデルは単一の GPU に常駐できますが、データが非常に大きいため、モデルのトレーニングに数日または数週間かかる場合があります。 複数の GPU ノードにデータを分散すると、トレーニング時間を大幅に短縮できます。

この投稿では、PyTorch モデルをトレーニングするためのサンプル アーキテクチャを提供します。 トーチ分散エラスティック を使用した分散データ並列方式のフレームワーク Amazon Elastic Kubernetesサービス (Amazon EKS)。

前提条件

この投稿で報告された結果を複製するための唯一の前提条件は、AWS アカウントです。 このアカウントでは、EKS クラスターと 光沢のためのAmazonFSx ファイルシステム。 また、コンテナ イメージを Amazon エラスティック コンテナ レジストリ アカウントの (Amazon ECR) リポジトリ。 これらのコンポーネントをセットアップする手順は、必要に応じて投稿全体で提供されます。

EKS クラスター

Amazon EKS は、AWS で Kubernetes アプリケーションを実行およびスケーリングするためのマネージド コンテナ サービスです。 Amazon EKS を使用すると、最新の分散トレーニング ジョブを効率的に実行できます。 アマゾン エラスティック コンピューティング クラウド 独自のコントロール プレーンやノードをインストール、運用、維持する必要のない (Amazon EC2) インスタンス。 人気です オーケストレーター 機械学習 (ML) および AI ワークフロー向け。 AWS の典型的な EKS クラスターは次の図のようになります。

オープンソース プロジェクトをリリースしました。 EKS 用 AWS DevOps (aws-do-eks)は、EKS クラスターをプロビジョニングし、分散トレーニング ジョブを実行するための、使いやすく構成可能なスクリプトとツールの大規模なコレクションを提供します。 このプロジェクトは、の原則に従って構築されています フレームワークを行う: シンプルさ、柔軟性、普遍性。 を使用して、目的のクラスターを構成できます。 eks.conf ファイルを実行して起動します。 eks-create.sh 脚本。 詳細な手順については、 GitHubレポ.

Torch Distributed Elastic を使用して PyTorch モデルをトレーニングする

Torch Distributed Elastic (TDE) は、可用性に基づいてコンピューティング リソースを動的にスケーリングすることが重要な大規模なディープ ラーニング モデルをトレーニングするためのネイティブ PyTorch ライブラリです。 の Kubernetes 用の TorchElastic コントローラー は、TDE トレーニングに必要なポッドとサービスのライフサイクルを自動的に管理する、TDE のネイティブ Kubernetes 実装です。 必要に応じて、トレーニング中にコンピューティング リソースを動的にスケーリングできます。 また、ノード障害からジョブを回復することにより、フォールト トレラント トレーニングも提供します。

この投稿では、PyTorch をトレーニングする手順について説明します EfficientNet-B7 & レスネット50 使用するモデル ImageNet TDE を使用した分散方式のデータ。 PyTorch を使用します 分散データ並列 API と Kubernetes TorchElastic コントローラーを使用して、複数の GPU ノードを含む EKS クラスターでトレーニング ジョブを実行します。 次の図は、このモデル トレーニングのアーキテクチャ図を示しています。

TorchElastic for Kubernetes は主に、TorchElastic Kubernetes Controller (TEC) とパラメーター サーバー (etcd) の XNUMX つのコンポーネントで構成されます。 コントローラーはトレーニング ジョブの監視と管理を担当し、パラメーター サーバーは分散同期とピア検出のためにワーカー ノードを追跡します。

トレーニング ポッドがデータにアクセスするには、各ポッドがマウントできる共有データ ボリュームが必要です。 共有ボリュームのいくつかのオプション コンテナ ストレージ インターフェイス (CSI) に含まれるドライバー EKS 向け AWS DevOps 　 AmazonElasticファイルシステム （Amazon EFS）および 光沢のためのFSx.

クラスターのセットアップ

このクラスター構成では、システム ポッドに 5.2 つの c4xlarge インスタンスを使用します。 24 つの p50d.3.8xlarge インスタンスをワーカー ポッドとして使用して、EfficientNet モデルをトレーニングします。 ResNetXNUMX トレーニングでは、pXNUMXxlarge インスタンスをワーカー ポッドとして使用します。 さらに、FSx 共有ファイル システムを使用して、トレーニング データとモデル アーティファクトを保存します。

AWS p4d.24xlarge インスタンスには、 エラスティックファブリックアダプター (EFA) ノード間のネットワークを提供します。 EFA については、この記事の後半で詳しく説明します。 EFA を介した通信を有効にするには、.yaml ファイルを使用してクラスターのセットアップを構成する必要があります。 アン サンプルファイル GitHub リポジトリで提供されています。

この .yaml ファイルを適切に構成したら、GitHub リポジトリで提供されているスクリプトを使用してクラスターを起動できます。

./eks-create.sh

Job Status ページの下部にある GitHubレポ 詳細な手順については、

p4d.24xlarge と p3.8xlarge でのジョブの実行に実質的な違いはありません。 この投稿で説明されている手順は、両方で機能します。 唯一の違いは、p4d.24xlarge インスタンスで EFA を利用できることです。 ResNet50 のような小さなモデルの場合、EFA ネットワーキングと比較して、標準ネットワーキングはトレーニングの速度にほとんど影響しません。

FSx for Lustre ファイル システム

FSx はハイ パフォーマンス コンピューティング ワークロード向けに設計されており、ソリッド ステート ドライブ ストレージ ボリュームを使用してミリ秒未満のレイテンシーを提供します。 FSx を選択したのは、多数のノードにスケーリングしたときにパフォーマンスが向上したためです。 注意すべき重要な点は、FSx は単一のアベイラビリティーゾーンにしか存在できないということです。 したがって、FSx ファイル システムにアクセスするすべてのノードは、FSx ファイル システムと同じアベイラビリティー ゾーンに存在する必要があります。 これを実現する 2 つの方法は、クラスターを作成する前に、特定のノード グループのクラスター .yaml ファイルで関連するアベイラビリティー ゾーンを指定することです。 または、クラスターのセットアップ後にこれらのノードの Auto Scaling グループのネットワーク部分を変更し、単一のサブネットの使用に制限することもできます。 これは、Amazon ECXNUMX コンソールで簡単に実行できます。

EKS クラスターが稼働中で、アベイラビリティーゾーンのサブネット ID がわかっていると仮定すると、必要な情報を fsx.conf で説明されているファイル README と実行 デプロイ.sh のスクリプト FSX フォルダ。 これにより、ファイル システムにアクセスするための正しいポリシーとセキュリティ グループが設定されます。 このスクリプトは、 CSI ドライバー デーモンセットとして FSx 用。 最後に、単一の .yaml ファイルを適用することで、Kubernetes で FSx 永続ボリューム クレームを作成できます。

kubectl apply -f fsx-pvc-dynamic.yaml

これにより、 fsx.conf ファイルを作成し、永続的なボリューム クレームも作成します。 fsx-pvcこれは、クラスター内の任意の Pod によって読み取り/書き込み/多 (RWX) 方式でマウントできます。

この実験では、12 クラスに分割された 1,000 万を超えるトレーニング画像を含む完全な ImageNet データを使用しました。 からデータをダウンロードできます。 ImageNet Web サイト. 元の TAR ボールにはいくつかのディレクトリがありますが、モデルのトレーニングでは、 ILSVRC/Data/CLS-LOC/含まれています train & val サブディレクトリ。 トレーニングの前に、画像を並べ替える必要があります val PyTorch が必要とするディレクトリ構造に一致するサブディレクトリ 画像フォルダ クラス。 これは、単純な Pythonスクリプト 次のステップでデータが永続ボリュームにコピーされた後。

からデータをコピーするには Amazon シンプル ストレージ サービス (Amazon S3) バケットを FSx ファイル システムに追加するには、このタスクのスクリプトを含む Docker イメージを作成します。 サンプルの Dockerfile とシェル スクリプトは、 CSI GitHub リポジトリ内のフォルダー。 を使用してイメージを構築できます。 build.sh スクリプトを作成し、それを Amazon ECR にプッシュします。 push.sh 脚本。 これらのスクリプトを使用する前に、ECR リポジトリの正しい URI を .env GitHub リポジトリのルート フォルダーにあるファイル。 Docker イメージを Amazon ECR にプッシュした後、ポッドを起動して、関連する .yaml ファイルを適用してデータをコピーできます。

kubectl apply -f fsx-data-prep-pod.yaml

ポッドはスクリプトを自動的に実行します データ準備.sh Amazon S3 から共有ボリュームにデータをコピーします。 ImageNet データには 12 万を超えるファイルがあるため、コピー プロセスには数時間かかります。 Python スクリプト imagenet_data_prep.py 再配置するためにも実行されます val PyTorch が期待するデータセット。

ネットワーク アクセラレーション

Elastic Fabric Adapter (EFA) を組み合わせて使用​​できます。 サポートされている EC2 インスタンス タイプ クラスター内の GPU ノード間のネットワーク トラフィックを高速化します。 これは、標準のネットワーク通信がボトルネックになる可能性がある大規模な分散トレーニング ジョブを実行する場合に役立ちます。 ここで使用する EKS クラスターに EFA デバイス プラグインをデプロイしてテストするためのスクリプトは、 efa デバイス プラグイン GitHub リポジトリのフォルダー。 EKS クラスターで EFA を使用してジョブを有効にするには、必要なハードウェアとソフトウェアを備えたクラスター ノードに加えて、EFA デバイス プラグインをクラスターにデプロイする必要があり、ジョブ コンテナーには互換性のある CUDA と NCCL が必要です。 バージョン インストールされています。

NCCL テストの実行と p4d.24xlarge インスタンスでの EFA のパフォーマンスの評価を実証するには、対応する デプロイ.sh のスクリプト mpi オペレーター フォルダ。 次に、 デプロイ.sh スクリプトを作成して更新する テスト-efa-nccl.yaml マニフェスト so 制限とリソースのリクエスト vpc.amazonaws.com 4 に設定されています。p4d.24xlarge ノードで使用可能な XNUMX つの EFA アダプターは、最大のスループットを提供するために一緒にバンドルされます。

ラン kubectl apply -f ./test-efa-nccl.yaml テストを適用し、テスト ポッドのログを表示します。 ログ出力の次の行は、EFA が使用されていることを示しています。

NCCL INFO NET/OFI Selected Provider is efa

テスト結果は、次の出力のようになります。

[1,0]<stdout>:#                                                       out-of-place                       in-place
[1,0]<stdout>:#       size         count      type   redop     time   algbw   busbw  error     time   algbw   busbw  error
[1,0]<stdout>:#        (B)    (elements)                       (us)  (GB/s)  (GB/s)            (us)  (GB/s)  (GB/s)
[1,0]<stdout>:           8             2     float     sum    629.7    0.00    0.00  2e-07    631.4    0.00    0.00  1e-07
[1,0]<stdout>:          16             4     float     sum    630.5    0.00    0.00  1e-07    628.1    0.00    0.00  1e-07
[1,0]<stdout>:          32             8     float     sum    627.6    0.00    0.00  1e-07    628.2    0.00    0.00  1e-07
[1,0]<stdout>:          64            16     float     sum    633.6    0.00    0.00  1e-07    628.4    0.00    0.00  6e-08
[1,0]<stdout>:         128            32     float     sum    627.5    0.00    0.00  6e-08    632.0    0.00    0.00  6e-08
[1,0]<stdout>:         256            64     float     sum    634.5    0.00    0.00  6e-08    636.5    0.00    0.00  6e-08
[1,0]<stdout>:         512           128     float     sum    634.8    0.00    0.00  6e-08    635.2    0.00    0.00  6e-08
[1,0]<stdout>:        1024           256     float     sum    646.6    0.00    0.00  2e-07    643.6    0.00    0.00  2e-07
[1,0]<stdout>:        2048           512     float     sum    745.0    0.00    0.01  5e-07    746.0    0.00    0.01  5e-07
[1,0]<stdout>:        4096          1024     float     sum    958.2    0.00    0.01  5e-07    955.8    0.00    0.01  5e-07
[1,0]<stdout>:        8192          2048     float     sum    963.0    0.01    0.02  5e-07    954.5    0.01    0.02  5e-07
[1,0]<stdout>:       16384          4096     float     sum    955.0    0.02    0.03  5e-07    955.5    0.02    0.03  5e-07
[1,0]<stdout>:       32768          8192     float     sum    975.5    0.03    0.06  5e-07   1009.0    0.03    0.06  5e-07
[1,0]<stdout>:       65536         16384     float     sum   1353.4    0.05    0.09  5e-07   1343.5    0.05    0.09  5e-07
[1,0]<stdout>:      131072         32768     float     sum   1395.9    0.09    0.18  5e-07   1392.6    0.09    0.18  5e-07
[1,0]<stdout>:      262144         65536     float     sum   1476.7    0.18    0.33  5e-07   1536.3    0.17    0.32  5e-07
[1,0]<stdout>:      524288        131072     float     sum   1560.3    0.34    0.63  5e-07   1568.3    0.33    0.63  5e-07
[1,0]<stdout>:     1048576        262144     float     sum   1599.2    0.66    1.23  5e-07   1595.3    0.66    1.23  5e-07
[1,0]<stdout>:     2097152        524288     float     sum   1671.1    1.25    2.35  5e-07   1672.5    1.25    2.35  5e-07
[1,0]<stdout>:     4194304       1048576     float     sum   1785.1    2.35    4.41  5e-07   1780.3    2.36    4.42  5e-07
[1,0]<stdout>:     8388608       2097152     float     sum   2133.6    3.93    7.37  5e-07   2135.0    3.93    7.37  5e-07
[1,0]<stdout>:    16777216       4194304     float     sum   2650.9    6.33   11.87  5e-07   2649.9    6.33   11.87  5e-07
[1,0]<stdout>:    33554432       8388608     float     sum   3422.0    9.81   18.39  5e-07   3478.7    9.65   18.09  5e-07
[1,0]<stdout>:    67108864      16777216     float     sum   4783.2   14.03   26.31  5e-07   4782.6   14.03   26.31  5e-07
[1,0]<stdout>:   134217728      33554432     float     sum   7216.9   18.60   34.87  5e-07   7240.9   18.54   34.75  5e-07
[1,0]<stdout>:   268435456      67108864     float     sum    12738   21.07   39.51  5e-07    12802   20.97   39.31  5e-07
[1,0]<stdout>:   536870912     134217728     float     sum    24375   22.03   41.30  5e-07    24403   22.00   41.25  5e-07
[1,0]<stdout>:  1073741824     268435456     float     sum    47904   22.41   42.03  5e-07    47893   22.42   42.04  5e-07
[1,4]<stdout>:test-efa-nccl-worker-0:33:33 [4] NCCL INFO comm 0x7fd4a0000f60 rank 4 nranks 16 cudaDev 4 busId 901c0 - Destroy COMPLETE
[1,0]<stdout>:# Out of bounds values : 0 OK
[1,0]<stdout>:# Avg bus bandwidth    : 8.23785

テスト結果から、最大スループットは約 42 GB/秒、平均バス帯域幅は約 8 GB であることがわかります。

また、単一の EFA アダプターを有効にして、EFA アダプターを使用せずに実験を行いました。 すべての結果を次の表にまとめます。

また、ImageNet のような比較的小さなモデルの場合、高速ネットワークを使用すると、エポックあたりのトレーニング時間が 5 のバッチ サイズで 8 ～ 64% しか短縮されないこともわかりました。モデルが大きく、バッチ サイズが小さい場合、重みのネットワーク通信の増加が必要な場合、高速ネットワークの使用はより大きな影響を与えます。 バッチ サイズ 15 の EfficientNet-B18 のトレーニングでは、エポック トレーニング時間が 7 ～ 1% 減少することが観察されました。トレーニングに対する EFA の実際の影響は、モデルのサイズによって異なります。

GPUモニタリング

トレーニングジョブを実行する前に、セットアップすることもできます アマゾンクラウドウォッチ トレーニング中の GPU 使用率を視覚化するメトリクス。 リソースが最適に使用されているかどうかを確認したり、トレーニング プロセスでのリソースの不足やボトルネックを特定したりすることが役立つ場合があります。

CloudWatch をセットアップするための関連スクリプトは、 GPU メトリクス フォルダ。 まず、Docker イメージを作成します。 amazon-cloudwatch-agent & nvidia-smi. で Dockerfile を使用できます gpu-metrics このイメージを作成するフォルダー。 ECR レジストリがすでに設定されていると仮定すると、 .env 前のステップのファイルを使用して、イメージをビルドしてプッシュできます build.sh & push.sh. この後、 deploy.sh スクリプトは自動的にセットアップを完了します。 デーモンセットを起動します amazon-cloudwatch-agent さまざまなメトリクスを CloudWatch にプッシュします。 GPU メトリックは、 CWAgent CloudWatch コンソールの名前空間。 残りのクラスタ メトリックは、 ContainerInsights 名前空間

モデルトレーニング

PyTorch トレーニングに必要なすべてのスクリプトは、 エラスティックジョブ GitHub リポジトリのフォルダー。 トレーニング ジョブを開始する前に、 etcd これは、ワーカーの検出とパラメーター交換のために TEC によって使用されます。 の デプロイ.sh のスクリプト elasticjob フォルダはまさにそれを行います。

p4d.24xlarge インスタンスで EFA を利用するには、 Amazon ECR パブリック ギャラリー EFA を介した NCCL 通信をサポートします。 トレーニング コードをこの Docker イメージにコピーするだけです。 の ドッカーファイル 下 サンプル フォルダーは、p4d インスタンスでトレーニング ジョブを実行するときに使用するイメージを作成します。 いつものように、 build.sh & プッシュ.sh フォルダー内のスクリプトを使用して、イメージをビルドおよびプッシュします。

　 imagenet-efa.yaml ファイルには、トレーニング ジョブが記述されています。 この .yaml ファイルは、トレーニング ジョブの実行に必要なリソースを設定し、前のセクションで設定したトレーニング データを使用して永続ボリュームをマウントします。

ここで指摘する価値のあることがいくつかあります。 レプリカの数は、クラスターで使用可能なノードの数に設定する必要があります。 この場合、p3d.4xlarge ノードが 24 つあるため、これを XNUMX に設定します。 の中に imagenet-efa.yaml ファイル、 nvidia.com/gpu リソースの下のパラメーターと nproc_per_node 下 args これは、p4d.24xlarge の場合は 8 です。また、Python スクリプトの worker 引数は、プロセスごとの CPU の数を設定します。 これを 4 に選択したのは、私たちの実験では、これが p4d.24xlarge インスタンスでの実行時に最適なパフォーマンスを提供するためです。 これらの設定は、クラスターで使用可能なすべてのハードウェア リソースを最大限に活用するために必要です。

ジョブが実行されているとき、クラスター内のすべての GPU について、CloudWatch で GPU の使用状況を観察できます。 以下は、クラスター内に 4 つの p24d.100xlarge ノードがあるトレーニング ジョブの XNUMX つの例です。 ここでは、各ノードから XNUMX つの GPU を選択しました。 前述の設定では、エポックのトレーニング フェーズ中の GPU 使用率は、クラスター内のすべてのノードで XNUMX% 近くになります。

p50xlarge インスタンスを使用して ResNet3.8 モデルをトレーニングするには、p4d.24xlarge を使用した EfficientNet トレーニングで説明したのとまったく同じ手順が必要です。 同じ Docker イメージを使用することもできます。 前述のように、p3.8xlarge インスタンスには EFA が装備されていません。 ただし、ResNet50 モデルの場合、これは重大な欠点ではありません。 の imagenet-fsx.yaml GitHub リポジトリで提供されるスクリプトは、p3.8xlarge ノード タイプに適したリソースを使用してトレーニング ジョブをセットアップします。 ジョブは、FSx ファイル システムからの同じデータセットを使用します。

GPU スケーリング

GPU の数を増やすことで、EfficientNet-B7 モデルのトレーニング時間がどのようにスケーリングするかを観察するために、いくつかの実験を行いました。 これを行うために、トレーニング実行ごとにトレーニング .yaml ファイルでレプリカの数を 1 から 3 に変更しました。 完全な ImageNet データセットを使用している間、単一のエポックの時間のみを観察しました。 次の図は、GPU スケーリング実験の結果を示しています。 赤い点線は、GPU の数を増やすことによって、8 つの GPU を使用した実行からトレーニング時間がどのように短縮されるかを表しています。 ご覧のとおり、スケーリングは予想に非常に近いものです。

同様に、p50xlarge インスタンスでの ResNet3.8 トレーニングの GPU スケーリング プロットを取得しました。 この場合、.yaml ファイルのレプリカを 1 から 4 に変更しました。この実験の結果を次の図に示します。

クリーンアップ

アイドル状態のインスタンスの実行に関連するコストを回避するために、モデルのトレーニング後にリソースをスピンダウンすることが重要です。 リソースを作成する各スクリプトでは、 GitHubレポ それらを削除するための一致するスクリプトを提供します。 セットアップをクリーンアップするには、クラスターを削除する前に FSx ファイル システムを削除する必要があります。これは、FSx ファイル システムがクラスターの VPC 内のサブネットに関連付けられているためです。 FSx ファイル システムを削除するには、次のコマンドを実行するだけです ( FSX フォルダ）：

kubectl delete -f fsx-pvc-dynamic.yaml
./delete.sh

これにより、永続ボリュームが削除されるだけでなく、FSx ファイル システムも削除され、ファイル システム上のすべてのデータが失われることに注意してください。 この手順が完了したら、次のスクリプトを使用してクラスターを削除できます。 EKS フォルダ：

./eks-delete.sh

これにより、既存のすべてのポッドが削除され、クラスターが削除され、最初に作成された VPC が削除されます。

まとめ

この投稿では、EKS クラスターで PyTorch 分散データ並列モデル トレーニングを実行するために必要な手順について詳しく説明しました。 この作業は大変に思えるかもしれませんが、 EKS 向け AWS DevOps AWS の ML フレームワーク チームによって作成されたプロジェクトは、プロセスを簡素化し、分散モデル トレーニングに簡単にアクセスできるようにするために必要なすべてのスクリプトとツールを提供します。

この記事で使用されているテクノロジーの詳細については、次の Web サイトをご覧ください。 アマゾンEKS & トーチ分散エラスティック. ここで説明するアプローチを、独自の分散トレーニングのユースケースに適用することをお勧めします。

リソース

著者について

イムラン・ユーヌス AWS の ML フレームワーク チームのプリンシパル ソリューション アーキテクトです。 彼は、Amazon EKS や AWS ParallelCluster などの AWS サービス全体にわたる大規模な機械学習と深層学習のワークロードに焦点を当てています。 彼は、コンピューター ビジョンおよび産業用 IoT におけるディープ ラーニングのアプリケーションで豊富な経験を持っています。 Imran は高エネルギー素粒子物理学の博士号を取得し、ペタバイト スケールの実験データの分析に携わってきました。

アレックス・イアンクルスキ は、フルスタックのソフトウェアおよびインフラストラクチャ アーキテクトであり、深く実践的な作業を行うのが好きです。 彼は現在、AWS で自己管理型機械学習のプリンシパル ソリューション アーキテクトを務めています。 彼の役割では、コンテナを利用した AWS サービスでの ML および AI ワークロードのコンテナ化とオーケストレーションで顧客を支援することに重点を置いています。 彼はオープンソースの作者でもあります フレームワークを行う 世界最大の課題を解決しながら、イノベーションのペースを加速するためにコンテナー テクノロジーを適用することを愛する Docker キャプテン。 過去 10 年間、Alex は気候変動との闘い、AI と ML の民主化、旅行の安全化、ヘルスケアの改善、エネルギーのスマート化に取り組んできました。