機械学習は「データが9割」。MLA-C01でもドメイン1（データ準備）が配点28%で最大です。その入口がこのテーマ、「データをどこから取り込み、どこに保存するか」。AWSにはストレージもデータ取り込みの方法も複数あり、試験では「この要件ならどのサービス？」という使い分けの判断が繰り返し問われます。この記事では、S3/EBS/EFS/FSxの違いから、ストリーミング取り込み、データ形式の選び方までを、図とクイズで一気に理解できるように解説します。全体像は シラバスマップ をどうぞ。
なぜ「取り込みと保存」が最重要なのか
どんなに良いアルゴリズムでも、データが汚かったり、必要なときに高速に読み込めなければ学習は進みません。MLA-C01が問うのは「コスト・性能・データ構造を踏まえて、最適なストレージと取り込み方法を選べるか」。まずは保存先となるストレージの3分類から押さえましょう。
土台：3種類のストレージ（オブジェクト／ブロック／ファイル）
AWSのストレージは大きく3タイプ。それぞれ「どう読み書きするか」が違い、ML文脈での使いどころも変わります。
| サービス | 種類 | 同時アクセス | MLでの主な使いどころ |
|---|---|---|---|
| Amazon S3 | オブジェクト | 多数から（HTTP） | 学習データの保管庫・データレイク（最も基本） |
| Amazon EBS | ブロック | 原則1インスタンス | 単一EC2/ノートブックの高速ローカルディスク |
| Amazon EFS | ファイル（NFS） | 複数から同時 | 分散学習で複数インスタンスがデータ共有 |
| Amazon FSx | ファイル（高性能） | 複数から同時 | 超高速I/Oが要る大規模学習（FSx for Lustre） |
Amazon S3：すべての出発点（オブジェクトストレージ）
S3は機械学習データの「定位置」です。容量無制限・高耐久（イレブンナイン）で、SageMakerの学習ジョブは基本的にS3上のデータを読み込みます。HTTP経由でどこからでもアクセスでき、データレイクの中心。「とりあえず生データはS3」が鉄則で、迷ったらまずS3と考えて問題ありません。ただしファイルシステムとして直接マウントして共有読み書きするような用途には向きません（その場合はEFS/FSx）。
Amazon EBS：1台のEC2にくっつく高速ディスク（ブロック）
EBSはEC2インスタンスにアタッチして使うブロックストレージ（PCの内蔵SSDのイメージ）。原則として同一AZの単一インスタンスに紐づきます。ノートブックや単一ノードでの前処理など、ローカルに高速な作業領域が欲しいときに使います。高いI/O性能が必要なら、Provisioned IOPS（io1/io2）でIOPSを保証できます。「複数インスタンスで共有」はできない点がEFSとの分かれ目です。
Amazon EFS／FSx：みんなで共有するファイルストレージ
分散学習で複数の学習インスタンスが同じデータセットを同時に読みたいとき、共有ファイルストレージが要ります。EFSはNFSでマウントできるフルマネージドの共有ファイルシステム。さらに高いスループットが必要ならFSx for Lustre——S3と連携して学習データを超高速に供給でき、大規模ML/HPCの定番です（エンタープライズNAS用途では FSx for NetApp ONTAP も対象）。
保管・データレイク＝S3／1台で高速＝EBS／複数で共有＝EFS／複数で超高速＝FSx for Lustre
データベースからデータを取り出す（RDS／DynamoDB）
学習データは必ずしもファイルとは限りません。業務データがリレーショナルDB（Amazon RDS）やNoSQL（Amazon DynamoDB）にあることも多く、ここから抽出してS3に集約し、前処理するのが定石です。RDSは表形式の構造化データ、DynamoDBは高速・大規模なキー値データ、という性格の違いを押さえておきましょう。
リアルタイムに取り込む：ストリーミング取り込み
センサーやログ、クリックストリームのように絶え間なく届くデータを扱うなら、ストリーミングサービスを使います。試験では特に「コードを書く必要があるか」「変換・配信まで任せられるか」で使い分けます。
| サービス | 役割 | ポイント |
|---|---|---|
| Kinesis Data Streams | リアルタイム取り込み | 低遅延だが処理（コンシューマ）の実装が必要 |
| Amazon Data Firehose | 配信（S3等へ） | コード不要でS3/Redshift等へ。Parquet/ORC変換も可 |
| Amazon MSK | Kafka互換 | 既存Kafka資産・エコシステムを活かす場合 |
| Managed Service for Apache Flink | ストリーム処理 | 到着データをリアルタイムに集計・変換 |
よくある判断：「ストリームをそのままS3へ、コードを書かずに貯めたい」→ Data Firehose。「低遅延でカスタム処理したい」→ Kinesis Data Streams＋コンシューマ。この対比が頻出です。
データ形式の選び方：行指向か、列指向か
同じデータでも保存フォーマットで読み込み効率とコストが変わります。鍵は「行指向 vs 列指向」。アクセスパターン（全カラム読む？一部だけ？）で選びます。
| 形式 | 分類 | 向いている用途 |
|---|---|---|
| Parquet / ORC | 列指向 | 一部カラムの分析・集計。高圧縮で大規模分析に最適 |
| CSV / JSON | 行指向（テキスト） | 人が読める・連携が簡単。小〜中規模、全カラム利用 |
| Avro | 行指向（バイナリ） | スキーマ進化・ストリーミング書き込み |
| RecordIO | バイナリ（protobuf） | SageMaker組み込みアルゴリズムへの効率的な学習入力 |
覚え方：「数百カラムから数カラムだけ繰り返し読む分析」＝列指向（Parquet/ORC）、「1レコードを丸ごと書き込む/読む」＝行指向（CSV/Avro）。Athena等での分析を見据えるならParquetが定番です。
SageMakerへの取り込み（Data Wrangler／Feature Store）
集めたデータをSageMakerに取り込む入口も押さえましょう。SageMaker Data Wranglerは、S3・Athena・Redshiftなど多様なソースからデータを取り込み、GUI中心で前処理までつなげられるツール。SageMaker Feature Storeは、作った特徴量を一元管理・再利用する保管庫で、学習用（オフライン）と推論用（オンライン）で一貫した特徴量を供給できます（詳しくは M1-2 で）。
取り込みを速く・安く：最適化のオプション
- S3 Transfer Acceleration：CloudFrontのエッジ経由で遠隔地からの大容量アップロードを高速化
- EBS Provisioned IOPS（io1/io2）：高いIOPSが要る処理でブロックストレージの性能を保証
- 複数ソースのマージ：散らばったデータの結合は AWS Glue（サーバーレスETL）や EMR上のApache Spark で。大規模な結合・変換に向く
- 保存先の初期判断：コスト・性能・データ構造で決める。迷ったら「生データはS3、共有が要ればEFS/FSx」
確認クイズ
Q1. あなたは大規模な画像分類モデルの学習基盤を担当しています。学習データは数TBに及び、Amazon S3に保存されています。コスト効率のため多数のGPUインスタンスで分散学習を行っていますが、各エポックの開始時に全インスタンスがS3から同一のデータセットを読み込むため、データ読み込みがボトルネックとなり、GPUの待機時間とコストが増大しています。読み込みのスループットを高めて学習を高速化する必要があります。この状況で最も効果的な構成はどれですか。
Q2. あなたはデータ分析基盤の担当者です。数十億行・約200カラムに及ぶイベントログをAmazon S3にCSV形式で蓄積し、Amazon Athenaで集計しています。多くのクエリは200カラムのうち金額や日時など3〜4カラムだけを対象にしますが、クエリの実行が遅く、スキャンされたデータ量に応じた課金も高額になっています。クエリ性能とスキャンコストの両方を改善する必要があります。最も効果的な対策はどれですか。
Q3. あなたはWebサイトのクリックストリームを収集するパイプラインを設計しています。絶え間なく届くイベントを、運用・実装するコードを最小限に抑えながらAmazon S3にParquet形式で保存したいと考えています。さらにS3へ保存する前に、各レコードへ派生フィールドを付与する軽量な変換も必要です。運用負荷を最小化しつつ要件を満たす、最も適切な構成はどれですか。
Q4. あなたはオンプレミスのデータセンターに保管された200TBの履歴データを、一度だけAmazon S3へ移行する作業を任されました。データセンターの外向きネットワーク帯域は限られており、通常業務への影響も避ける必要があります。移行は1週間以内に完了させなければなりません。この制約のもとでデータ移行を最も確実に完了できる方法はどれですか。
よくある質問（FAQ）
Q. 学習データは結局どこに置くのが正解？
A. 基本はS3です。データレイクとして生データを集約し、必要に応じてEFS/FSx（共有・高速）やSageMakerへ取り込みます。「迷ったらS3」で大きく外しません。
Q. EBSとEFSの一番の違いは？
A. 同時共有できるかどうかです。EBSは原則1インスタンス専用、EFSは複数インスタンスから同時マウントできます。分散学習でデータ共有が要るならEFS（さらに高速ならFSx for Lustre）。
Q. Kinesis Data StreamsとData Firehoseの使い分けは？
A. カスタム処理が要るかで分けます。低遅延で独自処理したいならData Streams（要コンシューマ実装）、コードを書かずにS3等へ貯めたい・変換したいならData Firehose（マネージド）です。
Q. なぜCSVよりParquetが勧められるの？
A. Parquetは列指向で、必要なカラムだけを読めて高圧縮。大規模データの分析では読み込み量・コスト・速度の面でCSVより有利になりやすいためです。
まとめ
- 保存先は3分類：S3（オブジェクト/データレイク）・EBS（1台で高速）・EFS/FSx（複数で共有/超高速）
- ストリーミングは「コード要＝Data Streams／不要＝Data Firehose」が基本の対比
- 形式は一部カラム分析＝列指向(Parquet/ORC)・丸ごと＝行指向(CSV/Avro)、SageMaker入力はRecordIOも
- 高速化はTransfer Acceleration（アップロード）・Provisioned IOPS（EBS）、結合はGlue/EMR Spark
- ➡ 次の記事：M1-2 データ変換と特徴量エンジニアリング（Glue／DataBrew／Data Wrangler／Feature Store）※準備中
- ➡ シラバスマップに戻る ／ MLA-C01とは？
※本記事はAWS公式試験ガイド(MLA-C01)および各サービスの公開ドキュメントに基づき、エンジニアKが作成しています。サービス仕様は更新されることがあるため、最新は必ずAWS公式でご確認ください。本サイトはAmazon Web Services, Inc.の公式サイトではありません。AWSは同社の商標です。
コメント