ステップ2：データストレージの設定 - Amazon S3

今回のステップの概要とデータ分析パイプラインとの関連について

このステップでは、ステップ1で作成したKinesis Data Streamsから収集したデータを保存するためのAmazon S3バケットを構築します。具体的には、データレイクとして機能するS3バケットを作成し、効率的な分析のためのパーティショニング構造を設定します。

データ分析パイプラインにとって、Amazon S3は「データを保管する巨大な倉庫」のような役割を果たします。工場で生産された製品（データ）を、長期間にわたって安全に保管し、必要な時にすぐに取り出せる倉庫のようなものです。この倉庫は、どんなに大量のデータでも保存でき、コスト効率が良く、高い耐久性を持っています。また、データを日付やカテゴリごとに整理して保存することで、後で必要なデータを素早く見つけることができます。

このステップで学ぶこと

• Amazon S3バケットの作成と設定方法
• データレイクとしてのS3の活用方法
• パーティショニングによる効率的なデータ管理
• S3ライフサイクルポリシーによるコスト最適化
• データ分析に適したS3のフォルダ構造

リソースの関わりと構成説明

ステップ2で作成するリソースは、データ分析パイプラインのデータ保存基盤を構築するものです。それぞれのリソースがデータ分析パイプラインにどのように関わるのか、なぜ必要なのか、メリットとデメリットを説明します。

Amazon S3バケットとデータ分析パイプラインの関わり

今回作成するAmazon S3バケット「data-analysis-lake」は、Kinesis Data Streamsから流れてくるデータを永続的に保存するデータレイクとして機能します。

なぜ必要なのか？

データ分析において、リアルタイムで収集したデータを長期間保存し、後から分析できるようにする必要があります。Kinesis Data Streamsは一時的な保存場所であり、データを永続的に保存するには別のストレージが必要です。例えるなら、工場で生産された製品を保管する巨大な倉庫のようなもので、どんなに大量のデータでも保存でき、必要な時にすぐに取り出せる必要があります。

このリソースがあることで得られるメリット：

• 無制限のスケーラビリティ：データ量が増加しても、ストレージ容量を気にせず保存できます（ペタバイト級のデータも保存可能）
• 高い耐久性：99.999999999%（11個の9）の耐久性により、データ損失のリスクが極めて低くなります
• コスト効率：使用量に応じた従量課金のため、データ量が少ない場合は低コストで運用できます
• 柔軟なアクセス：GlueやAthenaなどの分析ツールから直接アクセスできるため、データ分析が容易になります
• 複数のストレージクラス：データのアクセス頻度に応じて最適なストレージクラスを選択でき、コストを最適化できます

このリソースがない場合の問題点：

• データ容量の制限：従来のデータベースでは、データ量が増加すると容量不足になり、システム全体が停止する可能性があります
• コストの増大：データベースのストレージ容量を拡張するには、高額なハードウェア投資が必要です
• 分析の困難：大量のデータをデータベースに保存すると、クエリの実行時間が長くなり、分析が困難になります
• バックアップの複雑さ：大量のデータをバックアップするには、時間とコストがかかります
• 災害復旧の困難：データベースがダウンした場合、復旧に時間がかかり、データ分析が停止します

パーティショニングとデータ分析パイプラインの関わり

パーティショニングは、データを日付やカテゴリなどの属性に基づいて分割して保存する方法です。

なぜ必要なのか？

データ分析において、全データを読み取る必要はなく、特定の期間やカテゴリのデータだけを分析することが多いです。パーティショニングにより、必要なデータだけを効率的に読み取ることができます。例えるなら、倉庫の中で製品を日付別やカテゴリ別に整理して保管するようなものです。

このリソースがあることで得られるメリット：

• クエリパフォーマンスの向上：必要なデータだけを読み取るため、クエリの実行時間が大幅に短縮されます（例：全データを読み取る場合10分かかるクエリが、パーティションフィルタを使用すると1分で完了）
• コストの削減：読み取るデータ量が減るため、Athenaなどの分析ツールのスキャンコストが削減されます（例：1TBのデータから100GBだけを読み取る場合、コストが90%削減）
• 分析の柔軟性：日付範囲やカテゴリを指定して、必要なデータだけを分析できます
• メンテナンスの容易さ：古いデータを削除する場合、特定のパーティションだけを削除すればよいため、メンテナンスが容易です

このリソースがない場合の問題点：

• クエリの遅延：全データをスキャンする必要があるため、クエリの実行時間が長くなります（例：1年間のデータを分析する場合、数時間かかる可能性がある）
• コストの増大：全データをスキャンするため、分析ツールのスキャンコストが高くなります（例：1TBのデータを毎回スキャンする場合、1回のクエリで数万円かかる可能性がある）
• リソースの浪費：不要なデータも読み取るため、ネットワーク帯域やCPUリソースが無駄に消費されます
• 分析の制約：データ量が増加すると、クエリの実行時間が長くなり、実用的な分析ができなくなります

S3ライフサイクルポリシーとデータ分析パイプラインの関わり

S3ライフサイクルポリシーは、データの保存期間に応じて自動的にストレージクラスを変更したり、古いデータを削除したりする仕組みです。

なぜ必要なのか？

データ分析において、データのアクセス頻度は時間とともに変化します。最近のデータは頻繁にアクセスされますが、古いデータはほとんどアクセスされません。ライフサイクルポリシーにより、データのアクセス頻度に応じて最適なストレージクラスに自動的に移行でき、コストを最適化できます。例えるなら、倉庫で古い製品を自動的に別の場所に移動したり、不要になった製品を処分したりするようなものです。

このリソースがあることで得られるメリット：

• コストの最適化：データのアクセス頻度に応じてストレージクラスを変更することで、ストレージコストを最大90%削減できます（例：StandardからGlacier Deep Archiveに移行すると、ストレージコストが約95%削減）
• 自動管理：手動でデータを移動する必要がなく、自動的に最適なストレージクラスに移行されます
• データの長期保存：低コストのストレージクラスを使用することで、長期間データを保存できます
• 運用の効率化：データのライフサイクル管理を自動化することで、運用コストを削減できます

このリソースがない場合の問題点：

• コストの増大：すべてのデータを高コストのストレージクラスに保存するため、ストレージコストが高くなります（例：1TBのデータをStandardクラスで1年間保存する場合、約2.3万円/月かかるが、Glacier Deep Archiveに移行すると約0.1万円/月で済む）
• 手動管理の負担：データのアクセス頻度を監視し、手動でストレージクラスを変更する必要があり、運用負担が大きくなります
• データの長期保存の困難：高コストのストレージクラスでは、長期間データを保存することが経済的に困難です
• コスト予測の困難：データ量が増加すると、ストレージコストが予測不能に増加する可能性があります

実際の手順

実際の手順では、たくさんの設定値を入力することになります。 本文中に設定値が指定されていない場合は、デフォルト値のまま作業を進めてください。

1. S3バケットの作成

Amazon S3は、オブジェクトストレージサービスで、データレイクとして大量のデータを保存するのに適しています。このステップでは、データ分析パイプライン用のS3バケットを作成します。

1-1. S3コンソールへのアクセス

1. AWSマネジメントコンソールにログインします
2. 検索バーに「S3」と入力し、Amazon S3を選択します
3. 左側のナビゲーションペインから「Buckets」を選択します
4. 「Create bucket」ボタンをクリックします

1-2. バケットの作成

1. Bucket nameに「data-analysis-lake-あなたのアカウントID」と入力します（バケット名は全世界で一意である必要があるため、アカウントIDやランダムな文字列を追加してください）

2. 「Create bucket」ボタンをクリックします

2. パーティショニング構造の設定

データ分析を効率的に行うため、S3バケット内にパーティショニング構造を作成します。パーティショニングにより、必要なデータだけを読み取ることができ、分析の速度が向上し、コストも削減できます。

2-1. パーティショニング構造の理解

データ分析パイプラインでは、データを日付やカテゴリなどの属性に基づいて分割して保存します。一般的なパーティショニング構造は以下のようになります：

s3://data-analysis-lake/
  year=2024/
    month=01/
      day=15/
        data-file-1.json
        data-file-2.json
      day=16/
        data-file-3.json
    month=02/
      day=01/
        data-file-4.json

この構造により、特定の日付のデータだけを効率的に読み取ることができます。

2-2. サンプルデータファイルの準備

実際のデータ分析をテストするため、サンプルデータファイルをダウンロードします。

1. サンプルデータをダウンロードします

# 作業用ディレクトリを作成
mkdir data-analysis-sample
cd data-analysis-sample
 
# サンプルデータをダウンロード（wgetを使用）
wget https://www.tenarai-blueprint.com/06_Real_Time_Data_Analysis_Pipeline/sample-data.zip
 
# またはcurlを使用
# curl -O https://www.tenarai-blueprint.com/06_Real_Time_Data_Analysis_Pipeline/sample-data.zip

2. ダウンロードしたファイルを解凍します

# Linux/Mac
unzip sample-data.zip
 
# Windows（PowerShell）
Expand-Archive -Path sample-data.zip -DestinationPath .

3. ディレクトリ構造を確認します

# Linux/Mac
tree year=2024
# または
ls -R year=2024
 
# Windows（PowerShell）
Get-ChildItem -Recurse year=2024

2-3. サンプルデータのアップロード（テスト用）

作成したサンプルデータファイルをS3バケットにアップロードします。パーティショニング構造を維持したままアップロードするため、以下の2つの方法から選択できます。

方法1：AWSコンソールを使用したアップロード（推奨）

1. 作成したS3バケットの名前をクリックします
2. 「Upload」ボタンをクリックします
3. 「Add folder」をクリックして、解凍したyear=2024フォルダを選択します

4. 「Upload」ボタンをクリックします

方法2：AWS CLIを使用したアップロード

AWS CLIを使用する場合も、パーティショニング構造を維持したままアップロードできます。

# バケット名を実際のバケット名に置き換えてください
aws s3 sync year=2024/ s3://data-analysis-lake-あなたのアカウントID/year=2024/ --region us-east-1

{"timestamp": "2024-01-15T10:30:00Z", "user_id": "user123", "event_type": "page_view", "page_url": "/products/item001", "session_id": "session456"}
{"timestamp": "2024-01-15T10:31:00Z", "user_id": "user456", "event_type": "click", "page_url": "/products/item002", "session_id": "session789"}
{"timestamp": "2024-01-15T10:32:00Z", "user_id": "user789", "event_type": "purchase", "page_url": "/products/item003", "session_id": "session012"}

[
  {
    "timestamp": "2024-01-15T10:30:00Z",
    "user_id": "user123",
    "event_type": "page_view"
  }
]

4. 「Upload to」セクションで、パーティショニング構造に従ってフォルダパスを指定します（例：year=2024/month=01/day=15/）

5. 「Upload」ボタンをクリックします

3. ライフサイクルポリシーの設定（オプション）

データの保存期間に応じて自動的にストレージクラスを変更したり、古いデータを削除したりするライフサイクルポリシーを設定します。これにより、コストを最適化しながら、必要なデータは長期間保存できます。

3-1. ライフサイクルポリシーの作成

1. S3バケットの詳細画面で、「Management」タブを選択します
2. 「Lifecycle rules」セクションで「Create lifecycle rule」をクリックします
3. Lifecycle rule nameに「archive-old-data」と入力します
4. Rule scopeで「Apply to all objects in the bucket」を選択します

3-2. ライフサイクルルールのアクション設定

1. Lifecycle rule actionsで「Move current versions of objects between storage classes」を選択します
2. Transition current versions of objects between storage classesで、以下の設定を行います：
   • Transition to Standard-IA after: 30 days
   • Transition to Glacier Flexible Retrieval after: 90 days
   • Transition to Glacier Deep Archive after: 180 days

3. 「Create rule」ボタンをクリックします

このステップで何をしたのか

このステップでは、データ分析パイプラインのデータ保存基盤として、Amazon S3バケットを作成しました。具体的には、データレイクとして機能するS3バケットを作成し、効率的な分析のためのパーティショニング構造を設定しました。また、コスト最適化のためのライフサイクルポリシーも設定しました。

データ分析パイプラインでどのような影響があるのか

この構成により、データ分析パイプラインは大量のデータを効率的に保存できるようになりました。Kinesis Data Streamsから流れてくるデータを、パーティショニング構造に従って整理して保存することで、後でGlueやAthenaを使って効率的に分析することができます。これは、倉庫で製品を日付別やカテゴリ別に整理して保管するようなものです。また、ライフサイクルポリシーにより、データのアクセス頻度に応じてストレージクラスを自動的に変更することで、コストを最適化しながら、必要なデータは長期間保存できます。

技術比較まとめ表

学習において重要な技術的違い

1. スケーラビリティの実現方法

• AWS：無制限のストレージ容量。データ量が増加しても自動的に対応
• オンプレミス：ストレージ容量に制限があり、拡張には追加のハードウェアが必要

2. データの整理方法

• AWS：パーティショニング構造により、Glue/Athenaが自動的にデータを認識。効率的なクエリが可能
• オンプレミス：手動でディレクトリ構造を管理。パーティション管理が複雑

3. コスト構造

• AWS：使用量に応じた従量課金。ストレージクラスによるコスト最適化が可能
• オンプレミス：固定コストが発生。データ量が少なくてもコストがかかる

4. データの保護

• AWS：11個の9の耐久性。自動的なバックアップとレプリケーション
• オンプレミス：自前でバックアップと災害復旧を管理する必要がある

実践チェック：画面キャプチャで証明しよう

下記のチェック項目について、実際にAWSマネジメントコンソールで設定ができていることを確認し、各項目ごとに該当画面のスクリーンショットを撮影して提出してください。

• S3バケット「data-analysis-lake-（あなたのアカウントID）」が作成されている
• バケットの暗号化設定が「Amazon S3 managed keys (SSE-S3)」になっている
• バケットのパブリックアクセス設定がすべてブロックされている
• パーティショニング構造（year=YYYY/month=MM/day=DD/）に従ってサンプルデータがアップロードされている
• （オプション）ライフサイクルポリシー「archive-old-data」が作成されている

提出方法： 各項目ごとにスクリーンショットを撮影し、まとめて提出してください。 ファイル名やコメントで「どの項目か」が分かるようにしてください。

構成図による理解度チェック

このステップで作成したリソースを、データ分析パイプラインの構成図に追加しましょう。

なぜ構成図を更新するのか？

構成図を更新することで、データ分析パイプラインの全体像を視覚的に理解できるようになります。また、各リソースの関係性やデータの流れを明確にすることで、システムの動作を深く理解することができます。

• データの流れの理解: データがKinesis Data StreamsからS3に保存される流れを視覚的に把握できる
• リソース間の関係性: Kinesis Data StreamsとS3がどのように連携しているかを理解できる
• システム全体の把握: パイプライン全体の構造を一目で理解できる

構成図の書き方

ステップ1で作成した構成図をベースに、以下のリソースを追加してみましょう。

1. S3バケット: 図の中央に配置。データが保存される場所として表現
2. パーティショニング構造: S3バケット内のフォルダ構造を表現（year=YYYY/month=MM/day=DD/）
3. データの流れ: Kinesis Data StreamsからS3バケットへの矢印を描く

💡 ヒント: 構成図では、データの流れを左から右に向かって描くと理解しやすくなります。また、S3バケット内のパーティショニング構造を視覚的に表現すると、データの整理方法がより分かりやすくなります。

理解度チェック：なぜ？を考えてみよう

AWSの各リソースや設計には、必ず”理由”や”目的”があります。 下記の「なぜ？」という問いに自分なりの言葉で答えてみましょう。 仕組みや設計意図を自分で説明できることが、真の理解につながります。 ぜひ、単なる暗記ではなく「なぜそうなっているのか？」を意識して考えてみてください。

Q. なぜS3バケットにパーティショニング構造を設定するのでしょうか？パーティショニングにより、どのようなメリットが得られますか？

Q. なぜライフサイクルポリシーを設定するのでしょうか？データのアクセス頻度に応じてストレージクラスを変更することで、どのような効果が得られますか？

Q. なぜS3バケットのパブリックアクセスをブロックするのでしょうか？データ分析パイプラインでは、どのようなセキュリティ対策が重要ですか？

今回のステップで利用したAWSサービス名一覧

• Amazon S3：オブジェクトストレージサービス、データレイク