AWS Summit Japan 2025
先日開催されましたAWS Summit Japan 2025に参加してきました。
本記事では印象に残った「Amazon S3 による データレイク構築と最適化」について要点をまとめたいと思います。
セッション概要
本セッションでは、架空企業「AnyCompany」の事例を軸に、S3を活用したデータレイクの構築と運用の課題、解決策、そして最適化までのプロセスが紹介されました。
下記6つのフェーズに沿って、課題、対応策、重要な点について分かりやすく解説します。
1.課題の認識
2.スケーラブルなアーキティクチャ設計
3.データセキュリティとガバナンス
4.クエリの最適化
5.データの管理
6.継続的な改善
1.課題の認識
壁紙クロスのオンライン販売を行う「AnyCompany」ですが、グローバル展開による多様なデータの処理について、いくつかの問題があがってきます。
初めは注文履歴、問い合わせ内容、アクセス情報などの情報を一元的に管理し、分析に活かすべく、S3を中心としたデータ分析基盤を構築しました。
しかし、運用を始めてみると、現場からはさまざまな不満や課題が上がります。
データサイエンティスト：クエリが遅い
セキュリティ担当：全社的に個人情報にアクセスできてしまう
経理部：必要なデータがどこにあるかわからない
経営層：データ量の増加に比例してコストも膨張
「とにかくS3に保存すれば良い」という考えでは限界がありました。
ここで重要なのは、課題を定義し、現状を正しく認識すること。このフェーズでは、“分析できる状態とは何か”を改めて見つめ直すところから始まります。
2.スケーラブルなアーキティクチャ設計
AnyCompanyが次に取り組んだのは、保存構造の見直しです。セッションでは、データを3つのレイヤーに分けて管理する「ストレージレイヤーアーキテクチャ」が紹介されました。
生データ（Raw）：加工せずそのまま保存。監査や再処理用
処理済みデータ（Processed）：ETLを通じて整形され、分析可能になる
キュレーションデータ（Curated）：特定の業務や分析目的に特化し、即座に活用できるよう集計されたデータ
このレイヤー設計により、データの特性ごとに適切な形で保存・利用ができるようになります。
加えて、AWS Glue Data Catalog を活用することで、データのスキーマ情報や検索性も大きく改善されました。
さらに、パフォーマンスの要となる「S3のPrefix設計」も改善ポイントとして取り上げられました。
S3はプレフィックス単位でスループットが分散される仕組みがあるため、セッションIDなどのランダム性を上位階層に置くことで、リクエストの集中を避け、S3のスケーラビリティを最大限活用できます。
ここでのポイントは、「どこに保存するか」より「どう保存するか」です。構造の最適化が、分析のしやすさやコストにも直結します。
3.データセキュリティとガバナンス
分析が進むと、次なる課題として浮かび上がったのが「誰がどのデータにアクセスできるべきか？」という問題です。特に個人情報や顧客データを扱う企業では、セキュリティとガバナンスの確保が不可欠です。
ここで活用されたのが、AWS Lake Formation と Amazon SageMaker Data & AI Governance です。
Lake Formationでは、行レベル・列レベルのアクセス制御をJSON形式で柔軟に設定でき、例えば「フランスの営業チームにはフランスの注文データのみを見せる」「データサイエンティストにはPII情報を非表示にする」といったポリシーを実装可能にします。
また、SageMakerのAI Governance機能を使うことで、ドメインごとのデータ所有を明確にしたデータメッシュアーキテクチャも実現できます。データの所有・責任を明確化し、部門ごとにガバナンスを分散することで、組織全体のデータ活用が加速されます。
ここでのポイントは、「セキュリティとアクセシビリティの両立」。守りつつ、使えるデータ基盤を作ることが次のフェーズへの土台となります。
4.クエリの最適化
新たに浮上してきたのが「クエリの遅延」という課題です。特に、過去数年分売上データなどを横断的に分析しようとすると、実行に時間がかかり業務に支障をきたすというフィードバックがデータサイエンティストから上がってきました。
この原因を探っていく中で見えてきたのは、パーティションの設計と活用方法でした。Amazon S3ではデータを年・月・日ごとに分割（パーティション）することで、不要なデータのスキャンを避けてクエリ処理の効率を向上させることが可能です。しかし、実際のクエリではこのパーティション情報が正しく使われていない、という状況が多発していたのです。
そこでAnyCompanyが採用したのが、Apache Iceberg をはじめとする「オープンテーブルフォーマット」でした。
Icebergは、スキーマの変更や動的なパーティション設定、タイムトラベル（任意の時点のデータに戻れる）といった高機能を備え、クエリ実行をよりスマートかつ高速にします。
特に注目されたのは、Amazon S3との統合によりフルマネージドでIcebergテーブルを運用できる「Amazon S3 Tables」です。これにより、Icebergの持つパフォーマンス最適化（コンパクション、パーティションプルーニング）をS3側で自動的に実行でき、開発者やデータエンジニアの運用負荷を大幅に下げることができます。
ここでのポイントは、保存構造とクエリ最適化は密接に関わっているということです。
5.データの管理
データ量の増加に伴い、分析の基盤は強固になっていきますが、それと同時に浮上するのがコストの問題です。
S3に蓄積された膨大なデータのうち、分析で頻繁に使われるものもあれば、長期間アクセスされないアーカイブ用途のデータも存在します。
AnyCompanyでは、S3のストレージクラスの使い分けとライフサイクルポリシーの活用によってコストの最適化を実現しました。
たとえば、生データのように初期数日間だけ参照され、その後は保管だけされるデータについては、数日後に自動でS3 GlacierやDeep Archiveへ移行するよう設定。また、アクセスパターンが不定な処理済みデータには「S3 Intelligent-Tiering」を適用し、AWSが自動的に最適なストレージ階層へ移動するようにしました。
このように、利用実態に応じたストレージ戦略を採ることで、ユーザーが明示的に操作せずとも自動でコストが抑えられる仕組みが構築されました。
このフェーズのポイントは、「保存コストの最適化」という考え方です。コストを抑えつつ、必要なときに必要なデータへ即座にアクセスできる状態を保つことが重要です。
6.継続的な改善
データレイクの構築は、ビジネスと変化するニーズに対応するためには、継続的に改善を行う体制が求められます。
ここでAnyCompanyが取り組んだのは、モニタリングとアラートの強化でした。
Amazon CloudWatchを使って、S3、Glue、Athena、EMRなどからメトリクスを収集し、
データ増加のトレンド
クエリ失敗率
アクセス頻度の急変
セキュリティ設定の変更
といった重要な指標をKPIとして設定します。それらに対してSNSでアラート通知を行うことで、トラブルの兆候をいち早く検知・対応する仕組みを構築しました。
ここでのポイントは、「作ったあとも成長させていく」という意識を持つことです。データ基盤は一度作って終わりではなく、変化に応じてアップデートし続ける必要があります。
おわりに
今回のセッションでは、「Amazon S3 を中心としたデータレイク構築」の実例を通して、理想的なデータ活用基盤の在り方を具体的に学ぶことができました。
印象に残ったのはデータレイクが「作って終わり」ではなく、構築 → 最適化 → 管理 → 改善というサイクルを通して成長していく様子です。構造設計、セキュリティ、クエリ性能、コスト、運用体制など、色々な角度から改善を積み重ねていくことが成長につながるのだと感じました。
Discussion