【セッションレポート】 Amazon S3 によるデータレイク構築と最適化（AWS-04） #AWSSummit

コーヒーが好きな emi です。

本記事は 2025 年 6 月 25 - 26 日の 2 日間幕張メッセで開催中の AWS Summit Japan 2025 のセッションレポートとなります。
私が行った時は土砂降りで大変足元が悪かったのですが、帰りは雨がやんでいました。

セッション概要

• 日時: 2025年6月25日（水）14:50 - 15:30
• レベル: 300（中級者向け）
• テーマ: Data
  • ストレージ、データレイク・分析・BI
• 登壇者: 吉澤 巧（アマゾン ウェブ サービス ジャパン合同会社デジタルサービス技術本部 デジタルサービスソリューション部 ソリューションアーキテクト）

データレイクの構築において、Amazon S3 の特性を理解することは欠かせません。Amazon S3 にデータを収集できても、その先の効果的な運用管理に課題を感じている方も多いのではないでしょうか？本セッションでは、架空の E コマース企業を例として、データレイクの構築から効果的な運用に至るまでのロードマップを具体的に示します。データレイクの構築要素の中心となる Amazon S3 の特性を踏まえ、セキュリティとガバナンス、クエリパフォーマンス改善やデータ品質管理を容易にするために有効活用できるサービスと方法について学ぶことができます。

データレイクの課題と解決策

本セッションでは、壁紙クロスを販売している架空の企業 「AnyCompany」 を例に、Amazon S3を中心としたデータレイクの構築から効果的な運用までのロードマップを具体的に解説されました。

AnyCompany ではデータ基盤を作りましょう、となり、ひとまず S3 バケットにデータを入れるところまで実施しました。そこで発生した数々の問題を紐解きながら改善していく、というストーリーです。

Phase 1: 課題の認識

初期データ基盤構築において、以下の課題が明らかになりました。

• データサイエンティストチーム：クエリの遅延（年単位での処理時間）
• セキュリティチーム：全データに個人情報を含む状態でアクセス可能
• 運用チーム：データ量の増加（毎日1TB増加）に伴うコスト爆発
• 経理部：必要なデータの見つけやすさが低下

Phase 2: スケーラブルなアーキテクチャ設計

3層データレイクアーキテクチャ

データを3つのエリアに分割して配置するのが良いそうです。

1. Raw Data Layer（生データ層）

   • アプリケーションログ、クリックストリームなどを無加工で保存
   • 監査要件にも対応可能

2. Processed Data Layer（処理済みデータ層）

   • ETL 処理によるデータクレンジング、正規化
   • Parquet 形式での圧縮保存

3. Curated Data Layer（キュレーションデータ層）

   • ビジネス特有の質問に答えるための高度に最適化されたデータ
   • 探索的分析に適した形式

S3のパフォーマンス最適化

• パス構成の最適化
  • セッション ID を年月日よりも上位プレフィックスに配置し、ランダム性を持たせることで負荷分散

Phase 3: データセキュリティとガバナンス

AWS Glue Data Catalog の活用

• メタデータ管理による自動スキーマ検出
• パーティション情報の詳細保存
• データの検索と管理の簡素化

AWS Lake Formation によるアクセス制御

• 最小権限の原則：行レベル、列レベルでの細かいアクセス制御
• 個人情報保護：必要な列のみのアクセス許可
• 地域別アクセス制御：
  • 例：フランス拠点はフランスのデータのみ閲覧可能、など

データメッシュアプローチ

• Amazon SageMaker Data & AI Governance
  • データの分散所有権管理
• データ生産者による気軽なデータ公開
• データコンシューマーによる GUI 検索・管理

Phase 4: クエリの最適化

Apache Iceberg の導入

Iceberg は従来の Parquet/CSV を置き換えるものではなく、新しいテーブル形式のこと。

• テーブルスキーマ情報：統計情報を含むメタデータ管理
• 動的パーティション：新しいパーティションの自動生成
• コンパクション：小さなファイルの統合によるパフォーマンス向上
• スキーマ進化：後からのカラム追加・変更対応

パフォーマンス向上の実現

• イベントタイムカラムを使用した効率的な日付クエリ
• 一般的なクエリパターンの監視と最適化
• Amazon S3 Tables などとの統合による高速アクセス

Phase 5: データの管理

コスト最適化戦略

S3ストレージクラスの活用

• データアクセスパターンの理解に基づく適切なストレージクラス選択
• インテリジェントティアリング：自動的なアクセス頻度に応じたストレージ移行
• ライフサイクルポリシー：監査要件を満たしながらの自動アーカイブ

Phase 6: 継続的な改善

メトリクス収集と可視化

• CloudWatch：全AWSサービスからのメトリクス収集
• ダッシュボード作成：KPI 監視と SNS アラート設定
• パフォーマンス監視：リクエスト数、機密データ流出検知

主要 KPI

• リクエスト数の監視
• データ取り込み状況の確認
• セキュリティ設定の適切性チェック

まとめ

• パーティション最適化とPrefix設計
  • Icebergを利用したAmazon S3 Tablesでの活用
• AWS Lake Formation
  • きめ細かなアクセス管理の実現
• Amazon SageMaker Data & AI Governance
  • データメッシュアプローチの実現
• Amazon S3ストレージクラス
  • ライフサイクルポリシーによるコスト最適化

これらのアプローチにより、AnyCompany はデータレイクを安全でスケーラブル、コスト効率的に修正し、データの価値を最大化することができました。
S3 プレフィックスをランダムにする話はうっすら聞いたことがありましたが、改めてちゃんとお話が聞けて勉強になりました。