修行の場

知人が言っていました。これは修行だと。

学習パイプラインのスケールのさせ方 on AWS

背景

機械学習をするに当たって学習データを用意するパイプライン作成は重要です。 データ量が増えたり、収集・加工処理が重くなるに従いうまくスケールさせる必要があります。 今回は、選択肢が多いAWSのストレージのスケールの選択肢に関して調査しました。

ストレージ

ストレージの種類は公式のユーザガイドに載っています。 また、EC2インスタンスの種類によってもストレージの制限が変わってくるため、インスタンスタイプごとの違いを理解しておく必要がありそうです。

ストレージの種類をざっくりまとめると、

選択肢としては、1. 最もシンプルなのは基本EFSにML用のデータを置きつつ、 処理ログ数に応じてEC2インスタンスやEFSをスケールさせていく使い方が理想かと思います。 この方法だと処理を各インスタンスアサインすることだけすればいいので、 ほぼプログラムを変更せずにできます。

それ以外の方法だと、2. 複数インスタンスに分散配置することで上限突破する方法があります。 もしくは、3. 自前で分散ファイルシステムをEC2インスタンス上に構築して、 その上で実行するという手もあるでしょう。ただ、EFSと比べると遅くなるのではというイメージです。

選択肢2: EBSを使い将来的に分散配置+分散実行

数百テラバイトのデータなら一台のインスタンス+EBSで十分カバーできます。 EBS Optimizedなら下記の通り専用線のようなものを使っているようで他の通信に邪魔されないとのことです。 LVM on EBSで16TB以上のファイルシステムを作り、当面はこれで対応する予定です。

  • EBS-optimized instances deliver dedicated throughput between Amazon EC2 and Amazon EBS, with options between 500 and 4,000 Megabits per second (Mbps) depending on the instance type used.
  • The dedicated throughput minimizes contention between Amazon EBS I/O and other traffic from your EC2 instance, providing the best performance for your EBS volumes.

From https://aws.amazon.com/ec2/instance-types/#EBS

どのEBSを使うかはアプリケーション依存です。 すでにアプリがあるなら実際に測定して試してみると良いでしょう。

LVMにより数百TBまでデータをスケールさせEBSの制限を超えたら分散配置するということになるでしょう。