S U M M I T - pages.awscloud.coms3 のデータをsql 分析 2. s3 バケットの分け方 3. マルチアカウント構成 4. s3 経由でデータ連携 5. s3...

S U M M I TTo k y o 2 0 1 9

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T

データレイク構築における成功の秘訣～マインドと進め方、設計ベストプラクティス～

畔勝洋平コンサルタントアマゾンウェブサービスジャパン株式会社プロフェッショナルサービス本部

A 2 - 0 4


自己紹介

畔勝洋平（あぜかつようへい）

プロフェッショナルサービス本部

前職は外資系ベンダーでデータベースコンサルタント。現在はビッグデータコンサルタントとしてお客様のデータレイク設計やDB移行などを支援。

好きなAWSサービス： Amazon S3、Performance Insights

趣味：パフォーマンス分析・チューニング

好きな飲み物：担々麺


このセッションについて

• 対象

✓ データレイク設計・実装に関わる（予定の）エンジニア。

• セッションでお伝えすること

✓ 大規模なエンタープライズ・データレイク構築プロジェクト向けのマインド

と進め方、設計ベストプラクティス。

• 本資料について

✓ 後日、スライドと動画を公開予定。


アジェンダ

• データレイクとは

• Amazon のデータレイク事例

• マインドと進め方

• 8の設計ベストプラクティス

• まとめ

S U M M I T © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.


データレイクとは

1. 将来、必要な時に分析できるよう明細データを捨てずに蓄積する「湖」（2010年にJames Dixon（Pentaho CTO）がHadoop Worldで提唱）

分析要件A

別のカットでの分析不可

分析要件A

分析要件B

将来、新たなカットで分析可能



2. 多様なフォーマットのデータをそのまま保存できるストレージ

構造化・半構造化・非構造化データ構造化データ

要件C



3. 全てのデータを一元的に保存できる容量無制限のストレージ（別々のストレージに保存するとサイロ化していく）

サーバやHadoopクラスターの管理が必要

Amazon Simples Storage Service(S3)

サーバやインフラ管理から解放


ゴミ溜めになるのではないか？

• データと共にメタデータを登録しないと後で活用できない。

• DWH でデータ・ディクショナリがないと分析できないのと同じ。

出典：https://www.amazon.co.jp/Data-Lake-Architecture-Designing-Avoiding/dp/1634621174


データレイクは DWH を拡張する

• データウェアハウスに加えてビッグデータ処理なども可能に

1. 明細データを捨てずに蓄積

2. 多様なフォーマットを保存可能

3. 容量無制限なため一箇所に集約

DWH

BI

OLTP ERP CRM LOB SNSデバイス Web センサー

ビッグデータ処理、リアルタイム処理、機械学習

データレイク

+


時間の経過とともにデータの価値は減少する

本セッションでは触れないが、データレイクではリア

ルタイム処理も可能に



Amazon のビジネスとデータ活用

Amazon Data Warehouse

• Amazon はグローバルに様々なビジネスを展開

• そこから生まれる大量のデータを分析してビジネス判断


多様な分析要件と大きなワークロード

80,000 ユーザー

900,000 ジョブ／日

38,000 のデータセット分析ユーザーとユースケースは多種多様


Amazon のデータウェアハウスの課題


”Andes” –データレイク・プロジェクト–

• Amazonの成長に合わせて拡張可能なエコシステムを提供

• オープンなシステムアーキテクチャで、多様なデータ分析の選択肢を提供

• AWSを利用してフィードバック、サービス改善に貢献


“Andes” 以前の DWH のアーキテクチャ

Legacy Data Warehouse

ETLM Workflow Service

Export

Hosted Compute and Storage

Execution DAG

Data

Ingestion

Data Sources

Users

Traditional serverTraditional

serverReporting Systems

Software Applications

AmazonDynamoDB

AmazonAurora

AmazonRedshift

Oracle


“Andes” のアーキテクチャ Synchronized Metadata, Data

AmazonRedshift

AmazonRedshift

AWSGlue

AWSGlue

AmazonAurora

AmazonDynamoDB

Big Data System

Discovery Service

Synchronizers

ETLM Workflow Service

Execution DAG

Data Ingestion

Hoot UI

Data Sources

Glue ETL Orchestration

Spectrum

Andes Metadata & Governance Service

Completion Service

Custom EMR Orchestration

AmazonKinesis

Amazon Simple Storage Service (S3)

AmazonEMR

AmazonEMR

Amazon S3

LOAD

参照


“Andes” 完成（2018年1月移行完了）

• PBクラスの DWH を AWS に移行

• DWH に加えてビッグデータ処理も可能に

動画：https://www.youtube.com/watch?v=PitJL9vOotc

スライド：https://www.slideshare.net/AmazonWebServices/under-the-hood-how-amazon-uses-aws-services-for-analytics-at-a-massive-scale-ant206-aws-reinvent-2018


多くのお客様が AWS 上でデータレイク構築



マインドと進め方

1.Working Backwards

2.スモールスタート

3.ハンズオン・トレーニング

4.PoC ドリブン設計


情報系案件でよくある課題

• ステークホルダーが多く全員の総意を得るのが難しい。

• 調整するうちに本来のゴールから離れ使われない基盤に。


1. Working Backwards

• すべてはお客様を起点に逆算して考える。”Andes” も同じアプローチ。

• ステークホルダーの目線を合わせる。迷子になったら立ち戻る。

• ProServe による有償ワークショップ支援も可能。

Working Backwards ワークショップ

プレスリリースを作る FAQを作るお客様体験を詳細につめる


2. スモールスタート

• AWS サービスや分析アプリの進化は速い。

• 将来を見越した完璧な要件定義・技術選定・標準化に拘りすぎない。

• まずは必要なデータ活用フローを作り、必要に応じて拡張。

ビッグデータ基盤

可視化分析蓄積収集・加工

セキュリティ・ガバナンス

必要なデータ活用フロー


3. ハンズオン・トレーニング

• 座学だけでなく、ハンズオンで体感しないと分からない。

• エンジニアだけでなくIT戦略の意思決定に関わるステークホルダーも。

• 地味に意思決定に効いてくる。


AWS Data Lake ハンズオンセミナー

参考：https://aws.amazon.com/jp/blogs/news/20190405-aws-datalake-handson-seminor/

• 目黒の AWS Japan オフィスで不定期開催（無償セミナー）。

• 2018年から過去6回開催、参加者は100名程度。

• イベント開催予定：https://aws.amazon.com/jp/about-aws/events/

https://aws.amazon.com/jp/about-aws/events/


1～3日の集合研修プロジェクトが開始すると時間の捻出が難しいため事前の受講をおススメ

有償クラストレーニング

設計

開発

運用

AWS Technical Essentials 1

AWS Technical Essentials 2

Architecting on AWS

Developing on AWS

Systems Operations on AWS

AdvancedArchitecting

on AWS

DevOps Engineering

on AWS

初級(各1日)

Big Dataon AWS 3日

DataWarehousing on AWS 3日

SecurityOperationson AWS 3日

Running Container-Enabled Microservices on AWS 1日

Deep Learning on AWS 1日

専門特化

中級(各3日) 上級(各3日)

Architecting on AWS

Developing on AWS

参考：https://aws.amazon.com/jp/training/course-descriptions/


ProServe によるデータレイク・ワークショップ

• プロフェッショナルサービスによる 1～2 Day 有償ワークショップ。

• ご要望に合わせてカスタマイズ可能（範囲と金額は応相談）。

Parquet

ETL

DB接続ツール

収集加工蓄積

分析・可視化

Copy

CSV

AmazonRedshift

Amazon Athena

Business Users

Data Analysts

AWSGlue

Amazon QuickSight


4. PoC ドリブン設計

• クラウドはアジャイル型開発との相性が良いが✓ すぐに全ての企業が適応できるわけでない

• ウォータフォール型開発でも PoC ドリブンで速く高品質な設計✓ 正式な本番・開発用とは別にサンドボックス用のAWSアカウントを用意

✓ 検討や方式設計など初期フェーズから PoC で試しながら設計

検討基本設計

詳細設計

開発UT

ITST

UATフェーズ


マインドと進め方まとめ


8


ベストプラクティスとは

固定的なものや遵守すべきルールではなく、目的に合わ

せて適切に使い、常に学習し改善し続けるもの。

参考：https://ja.wikipedia.org/wiki/ベストプラクティス


8の設計ベストプラクティス

1. S3 のデータを SQL 分析

2. S3 バケットの分け方

3. マルチアカウント構成

4. S3 経由でデータ連携

5. S3 クロスアカウントアクセス制御

6. SSE-KMS による暗号化

7. S3 パブリック公開禁止

8. SCP で特定操作禁止


• やりたいこと

✓ S3 のファイルを SQL で分析したい。

✓ Redshift のコストを抑えたい。

• 解決策

✓ Athena、EMR で SQL で S3 のデータを分析。

✓ Redshift で腹持ちするものと Spectrum で S3 を参照するものを使い分け。

1. S3 のデータを SQL で分析


S3 のデータを SQL で分析

Amazon Athena

収集用バケット

蓄積用バケット

Amazon EMR

AWSGlue

AmazonRedshift


パフォーマンスを引出すの3つポイント

1. フィルタ条件に使うキーでパーティション分割、ただし✓ 細かく分割しすぎない

✓ データ分布が特定パーティションに偏っていない

Amazon Athena

蓄積用バケット


パーティション分割の効果

• Athena でパーティション分割有無で SQL の性能を比較。

• パーティション分割していると読込みサイズが減り実行時間短縮。

パーティション分割スキャンサイズ実行時間利用料

なし 74.1GB 10.41秒 $0.36

あり 871.39MB 2.73秒 $0.004

効果 87%削減 73%高速 98%削減

参考：https://aws.amazon.com/jp/blogs/news/top-10-performance-tuning-tips-for-amazon-athena/

SELECT count(*) FROM lineitemWHERE l_shipdate >= '1996-09-01’ AND l_shipdate < '1996-10-01'

S3 から読むサイズ


パフォーマンスを引出す3つのポイント

2. 読込量を減らすため Parquet などの列指向フォーマットに変換。

select count(id) from table1 where year=2006 and month=03;

Amazon Athena


Parquet のファイルフォーマット

同じ列のデータがまとまっている（Column chunk）ため、圧縮効率がよく、必要な列の

データのみ読込み参考：https://engineer.retty.me/entry/columnar-storage-format

https://parquet.apache.org/documentation/latest/https://eng.uber.com/presto/

FileMetaData の RowGroup に行数（num_rows）をメタデータとして持っている


集計 SQL での列指向フォーマットの効果

データセット S3上のサイズスキャンサイズ実行時間利用料

テキストファイル 1 TB 1.15TB 3分56 秒 $5.75

Parquet 130 GB 2.51 GB 5.13 秒 $0.013

削減／高速化効果 87% 削減 99%削減 34倍高速 99.7%削減

出典：https://aws.amazon.com/jp/blogs/news/analyzing-data-in-s3-using-amazon-athena/

• Athena で S3 上の ELB ログを集計

• 生ログと Parquet で比較

• スキャンサイズは99%削減、利用料は99%削減、実行時間は34倍高速

S3 から読むサイズ

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U M M I T出典：https://aws.amazon.com/jp/blogs/news/seven-tips-for-using-s3distcp-on-amazon-emr-to-move-data-efficiently-between-hdfs-and-amazon-s3/

パフォーマンスを引出す3つのポイント

3. ファイルサイズを小さくしすぎない（128MB～数GB程度）✓ EMRFS はデフォルトで 64MB 単位（fs.s3.block.size）で S3 にアクセス。

✓ 小さいとオーバーヘッドが大きく、API発行回数上限に到達しやすくなる。

✓ 小さなファイル群を 128MB 以上にまとめる方法として S3DistCP。

Amazon Athena

Amazon EMR


ファイルサイズが小さ過ぎると

• Athena で同じサイズのデータに同じ SQL を実行。

• ファイルサイズが小さすぎると実行時間が長くなる。

SQL データサイズファイル数平均ファイルサイズ実行時間

SELECT count(*)

FROM lineitem7GB

5000 1.4MB 8.4 秒

1 7GB 2.31秒

参考：https://aws.amazon.com/jp/blogs/news/top-10-performance-tuning-tips-for-amazon-athena/

Amazon AthenaAmazon S3

3.6倍の差


• 検討項目

✓ データレイクを設計しているがS3バケットを分ける指針が分からない。

• 指針

1. 人が見て直感的に分かりやすい単位で分ける。

収集用バケット、蓄積用バケットなど

2. バケット単位の設定を変えたい場合はバケットを分ける。

バージョニング、ライフサイクルポリシー、オブジェクトロックなど

3. バケット単位のサービス上限に達しないよう分ける。

1アカウント当たりバケット数上限、バケットポリシーサイズ上限など

2. S3 バケットの分け方


S3 バケットの分け方の検討観点

項目説明

バージョニングオブジェクトを上書き、削除しても過去バージョンを保持する

機能。バケット単位の設定。

ライフサイクルポリシー指定した期間を過ぎるとオブジェクトをアーカイブしたり削除

する機能。バケット単位の設定。

オブジェクトロック指定した期間、バージョニングされたオブジェクトの削除を禁

止する機能。バケット単位の設定。

1アカウント当たりのバケット数デフォルト100、ハードリミットは1000。

バケットポリシーサイズバケットポリシーサイズの上限は20KB。

コスト管理コスト配分タグはバケット単位で設定可能。コスト配分を区別

したい単位でバケットを分ける。

監査証跡 S3 アクセスログはバケット単位で出力される。


S3 バケットの分け方の例

収集用バケット蓄積用バケット

データ提供先データソース

項目収集用バケット蓄積用バケット

バージョニング有効有効

ライフサイクルポリシー 1ヶ月以上古いデータは削

除またはアーカイブ

なし

バケットポリシーデータソースに対してア

クセス許可

データ提供先に対してアク

セス許可

加工


3. マルチアカウント構成

• 検討項目

✓ データレイク用アカウントを作るか、既存アカウント内に作るか。

• 推奨案

✓ データレイク用にアカウントを分ける。

✓ 本番、開発、サンドボックスなど用途ごとにアカウントを分ける。

• メリット

✓ アカウント単位で明確に権限、課金、設定変更時の影響範囲を分割。

✓ アカウント単位のリソース上限にかかる可能性を緩和できる。


リージョン

マルチアカウント構成例


4. S3 バケット間コピー

• 検討項目

✓ アカウント間のデータ連携をどのように行うか。

• 推奨案

✓ S3バケット間でコピー。

• メリット

✓ 高速で同一リージョン内ではデータ転送料金がかからない。

✓ VPC 間の通信設定不要（VPC Peering など）。


AWS CLI でコピー時の動作イメージ

• “s3 cp/sync s3:// ... s3://” はS3バケット間でデータ転送され高速。

リージョン

EC2


5. S3 クロスアカウントアクセス制御

• 検討項目

✓ バケットポリシーやIAM信頼ポリシーにアカウントIDを記述すると肥大化。

• 推奨案

✓ バケットポリシーで aws:PrincipalOrgID でアクセス許可。

• メリット

✓ ポリシーサイズ上限の考慮不要。

✓ メンバーアカウント追加時に設定追加不要。

参考：https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_condition-keys.html


連携先アカウントが多くなると

• バケットポリシーの Principal に AWSアカウントID を指定するとアカウ

ント数が増えるとバケットポリシーサイズ上限の 20 KB に抵触{

"Version": "2012-10-17",

"Statement": {

"Sid": "AllowGetObject",

"Effect": "Allow",

"Principal": "*",

"Action": "s3:Getobject",

"Resource": "arn:aws:s3:::datalake-sample/*",

"Principal": {

"AWS": [

"arn:aws:iam::123456789012:root",

"arn:aws:iam::123456789013:root",

"arn:aws:iam::123456789014:root",

"arn:aws:iam::123456789015:root",

"arn:aws:iam::123456789016:root",

"arn:aws:iam::123456789017:root",

"arn:aws:iam::123456789018:root",

"arn:aws:iam::123456789019:root",

"arn:aws:iam::123456789020:root",

"arn:aws:iam::123456789021:root",

"arn:aws:iam::123456789022:root",

"arn:aws:iam::123456789023:root",

"arn:aws:iam::123456789024:root",

"arn:aws:iam::123456789025:root",

"arn:aws:iam::123456789026:root",

"arn:aws:iam::123456789027:root",

"arn:aws:iam::123456789028:root",

"arn:aws:iam::123456789029:root",

"arn:aws:iam::123456789030:root",

"arn:aws:iam::123456789031:root",

"arn:aws:iam::123456789032:root",

"arn:aws:iam::123456789033:root",

"arn:aws:iam::123456789034:root",

"arn:aws:iam::123456789035:root",

"arn:aws:iam::123456789036:root",

"arn:aws:iam::123456789037:root",

"arn:aws:iam::123456789038:root",

"arn:aws:iam::123456789039:root",

"arn:aws:iam::123456789040:root",

"arn:aws:iam::123456789041:root",

"arn:aws:iam::123456789042:root",

"arn:aws:iam::123456789043:root",

"arn:aws:iam::123456789044:root",

"arn:aws:iam::123456789045:root",

"arn:aws:iam::123456789046:root",

"arn:aws:iam::123456789047:root",

"arn:aws:iam::123456789048:root",

"arn:aws:iam::123456789049:root",

"arn:aws:iam::123456789050:root",

"arn:aws:iam::123456789051:root",

"arn:aws:iam::123456789052:root",

"arn:aws:iam::123456789053:root",

"arn:aws:iam::123456789054:root",

"arn:aws:iam::123456789055:root",

"arn:aws:iam::123456789056:root",

"arn:aws:iam::123456789057:root",

"arn:aws:iam::123456789058:root",

"arn:aws:iam::123456789059:root",

"arn:aws:iam::123456789060:root",

"arn:aws:iam::123456789061:root",

"arn:aws:iam::123456789062:root",

"arn:aws:iam::123456789063:root",

"arn:aws:iam::123456789064:root",

"arn:aws:iam::123456789065:root",

"arn:aws:iam::123456789066:root",

"arn:aws:iam::123456789067:root",

"arn:aws:iam::123456789068:root",

"arn:aws:iam::123456789069:root",

"arn:aws:iam::123456789070:root",

"arn:aws:iam::123456789071:root",

"arn:aws:iam::123456789072:root",

"arn:aws:iam::123456789073:root",

"arn:aws:iam::123456789074:root",

"arn:aws:iam::123456789075:root",

"arn:aws:iam::123456789076:root",

"arn:aws:iam::123456789077:root",

"arn:aws:iam::123456789078:root",

"arn:aws:iam::123456789079:root”,

"arn:aws:iam::123456789080:root",

"arn:aws:iam::123456789081:root",

"arn:aws:iam::123456789082:root",

"arn:aws:iam::123456789083:root",

"arn:aws:iam::123456789084:root",

"arn:aws:iam::123456789085:root",

"arn:aws:iam::123456789086:root",

"arn:aws:iam::123456789087:root",

"arn:aws:iam::123456789088:root",

"arn:aws:iam::123456789089:root",

"arn:aws:iam::123456789090:root",

"arn:aws:iam::123456789091:root",

"arn:aws:iam::123456789092:root",

"arn:aws:iam::123456789093:root",

"arn:aws:iam::123456789094:root",

"arn:aws:iam::123456789095:root",

"arn:aws:iam::123456789096:root",

"arn:aws:iam::123456789097:root",

"arn:aws:iam::123456789098:root",

"arn:aws:iam::123456789099:root",

"arn:aws:iam::123456789100:root",

"arn:aws:iam::123456789101:root",

"arn:aws:iam::123456789102:root",

"arn:aws:iam::123456789103:root",

"arn:aws:iam::123456789104:root",

"arn:aws:iam::123456789105:root",

"arn:aws:iam::123456789106:root",

"arn:aws:iam::123456789107:root",

"arn:aws:iam::123456789108:root",

"arn:aws:iam::123456789109:root",

"arn:aws:iam::123456789110:root",

"arn:aws:iam::123456789111:root",

"arn:aws:iam::123456789112:root",

"arn:aws:iam::123456789113:root",

"arn:aws:iam::123456789114:root",

"arn:aws:iam::123456789115:root",

"arn:aws:iam::123456789116:root",

"arn:aws:iam::123456789117:root",

"arn:aws:iam::123456789118:root",

"arn:aws:iam::123456789119:root",

"arn:aws:iam::123456789120:root",

"arn:aws:iam::123456789121:root",

"arn:aws:iam::123456789122:root",

"arn:aws:iam::123456789123:root",

"arn:aws:iam::123456789124:root",

（中略）

]

}

}

}


aws:PrincipalOrgID で記述すると

• 一行の記述で同じ Organization 内のアカウントからアクセス可能

{

"Version": "2012-10-17",

"Statement": {

"Sid": "AllowGetObject",

"Effect": "Allow",

"Principal": "*",

"Action": "s3:getobject",

"Resource": "arn:aws:s3:::datalake-sample/*",

"Condition": {"StringEquals":

{"aws:PrincipalOrgID":["o-xxxxxxxxxxx"]}

}

}

}


6. SSE-KMS による暗号化


✓ 情報漏洩対策・規制対応のため S3 を暗号化したい。

✓ かつ、S3 のデータを SQL で分析したい。

• 解決策

✓ SSE-KMS を利用（SSE: Server Side Encryption）。

• メリット

✓ セキュリティ、パフォーマンス、可用性・耐久性を両立。

参考：https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/UsingKMSEncryption.html


データレイクにおける SSE-KMS のメリット

• サーバーサイド暗号化のためS3側でデータの絞り込みが効く

• 万一、S3でパブリック公開してもアクセス不可

S3 アクセス権のみでデータの中身にアクセス可能

CSE - KMS CSE - C

SSE - S3 SSE - KMS SSE - CServer side

Client side

AWS KMSS3 built-in Custom KMS

中身の参照にCMK への

アクセス権が必要CMK 管理インフラを自前で用意する必要

鍵管理方式

暗号化の場所

S3側で必要なデータを絞り込み可

ダウンロードまで中身を参照不可


データレイクにおける SSE-KMS のメリット

• サーバーサイド暗号化のためS3側でデータの絞り込みが効く

• 万一、S3でパブリック公開してもアクセス不可

S3 アクセス権のみでデータの中身にアクセス可能

CSE - KMS CSE - C

SSE - S3 SSE - KMS SSE - CServer side

Client side

AWS KMSS3 built-in Custom KMS

中身の参照にCMK への

アクセス権が必要CMK 管理インフラを自前で用意する必要

鍵管理方式

暗号化の場所

S3側で必要なデータを絞り込み可

ダウンロードまで中身を参照不可


KMS へのアクセス権がない限りアクセス不可

• S3 バケットをパブリック公開してもアクセス不可。

• S3 のみのアクセス権があってもアクセス不可。

KMS CMK

アクセス不可

Amazon S3IAM Policy (S3) IAMユーザー

アクセス不可

IAM Role B

IAM Policy (KMS) EC2

IAM Role A

Key Policy


7. S3 パブリック公開防止


✓ 作業ミスによる S3 バケットのパブリック公開を防止したい。

• 解決策

✓ S3 Block Public Access をアカウントレベルで有効化。

• 効果

✓ S3 バケットのパブリック公開を一切禁止。

参考：https://aws.amazon.com/jp/blogs/news/amazon-s3-block-public-access-another-layer-of-protection-for-your-accounts-and-buckets//


S3 Block Public Access 有効化

• アカウントレベルでS3 Block Public Accessを有効化


アカウントレベルとバケットレベルの設定

• アカウントレベルで S3 Block Public Access を有効化すればバケッ

トのパブリック公開を防止できる


8. SCP による特定操作の禁止


✓ 作業ミスによる設定変更を防止したい。

• 解決策

✓ Service Control Policy(SCP) で特定アクション禁止。

• メリット

✓ root アカウントでも禁止したアクション実行不可。


AWS Organizations と Service Control Policy

• AWS Organizations で AWS アカウントの親子関係を作る。

• Organization Unit(OU) でメンバーアカウントをグルーピング。

• SCP でメンバーで実行可能なアクションを制限（rootアカウント含む）。

マスター

メンバーメンバー OU

メンバーメンバー

SCP SCP

参考：https://d1.awsstatic.com/webinars/jp/pdf/services/20180214_AWS-Blackbelt-Organizations.pdf


SCP で S3 Block Public Access 設定変更禁止

1. S3 Block Public Access 設定変更禁止 SCP 作成。

2. データレイク用アカウント作成、S3 Block Public Access 有効化。

3. SCP をデータレイク用アカウントまたは属する OU にアタッチ。

マスター

メンバー

OUメンバーメンバー

メンバー

SCP


SCP で S3 Block Public Access 設定変更禁止{

"Version": "2012-10-17",

"Statement": [

{

"Sid": "Statement1",

"Effect": "Deny",

"Action": [

"s3:PutAccountPublicAccessBlock",

"s3:PutBucketPublicAccessBlock"

],

"Resource": [

"*"

]

}

]

}


8の設計ベストプラクティスまとめ

Amazon Athena

AWSGlue



まとめ

• データレイクでは

✓ DWH に加え、ビッグデータ処理、機械学習など様々なデータ処理が可能。

✓ Amazon は PB クラスの DWH を AWS に移行。

• マインドと進め方

✓ Working Backwards でゴールから逆算。

✓ スモールスタートして PoC ドリブン設計で進める。

• 8の設計ベストプラクティス

✓ ベスプラを参考に、Amazon S3 をフル活用してデータ分析を。


関連セッション

• 【初級】AWSでのデータ収集、分析、そして機械学習

✓ C2-05: Day2 14:00-14:40

• 金融ビッグデータのためのクラウドネイティブAI分析プラットフォーム構築のすべて

✓ J2-05: Day2 14:00-14:40

• ML Security on AWS

✓ A2-07: Day2 16:00-16:40


お手元のサミットガイドブックの表紙、受講票にも記載している『QRコード』からご回答ください。

もれなく素敵なAWSオリジナルグッズ＆アイスをプレゼントします。

本セッションのFeedbackをお願いします

プレゼントの引き換えは、EXPOエリア内アンケートコーナー・出口付近のいずれかにお越しください。

涼感マフラータオル（巾着入り）



参考情報• Pentaho, Hadoop, and Data Lakes

✓ https://jamesdixon.wordpress.com/2010/10/14/pentaho-hadoop-and-data-lakes/

• Data lake – Wikipedia

✓ https://en.wikipedia.org/wiki/Data_lake

• Under the Hood: How Amazon Uses AWS Services for Analytics at a Massive Scale

✓ https://www.slideshare.net/AmazonWebServices/under-the-hood-how-amazon-uses-aws-services-for-analytics-at-a-massive-scale-ant206-

aws-reinvent-2018

• Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ

✓ https://www.slideshare.net/ssuserca76a5/hcj2019-hadoop-sparks3

• Building an end to end serverless analytics application

✓ http://aws-de-media.s3.amazonaws.com/images/DevDays%202018/DM5-AWS18_DevDay_serverlessAnalytics.pdf

https://jamesdixon.wordpress.com/2010/10/14/pentaho-hadoop-and-data-lakes/

https://en.wikipedia.org/wiki/Data_lake

https://www.slideshare.net/AmazonWebServices/under-the-hood-how-amazon-uses-aws-services-for-analytics-at-a-massive-scale-ant206-aws-reinvent-2018

https://www.slideshare.net/ssuserca76a5/hcj2019-hadoop-sparks3

http://aws-de-media.s3.amazonaws.com/images/DevDays%202018/DM5-AWS18_DevDay_serverlessAnalytics.pdf


参考情報• Amazon Athena のパフォーマンスチューニング Tips トップ 10

✓ https://aws.amazon.com/jp/blogs/news/top-10-performance-tuning-tips-for-amazon-athena/

• Amazon Redshift Spectrum 10 のベストプラクティス

✓ https://aws.amazon.com/jp/blogs/news/10-best-practices-for-amazon-redshift-spectrum/

• AWS サービスの制限

✓ https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws_service_limits.html

• バケットの制約と制限

✓ https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/BucketRestrictions.html

• AWS グローバル条件コンテキストキー

✓ https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_condition-keys.html

✓ バケットポリシーの例

✓ https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/example-bucket-policies.html

https://aws.amazon.com/jp/blogs/news/top-10-performance-tuning-tips-for-amazon-athena/

https://aws.amazon.com/jp/blogs/news/10-best-practices-for-amazon-redshift-spectrum/

https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws_service_limits.html

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/BucketRestrictions.html

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_condition-keys.html

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/example-bucket-policies.html


参考情報• SSE-KMS によるサーバー側の暗号化を使用してデータを保護する

• https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/UsingKMSEncryption.html

• IAM エンティティおよびオブジェクトの制限

✓ https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_iam-limits.html

• AWS グローバル条件コンテキストキー – aws:PrincipalOrgID

• https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_condition-keys.html

• カラムナフォーマットのきほん～データウェアハウスを支える技術～

✓ https://engineer.retty.me/entry/columnar-storage-format

• Amazon S3 Block Public Access – アカウントとバケットのさらなる保護

✓ https://aws.amazon.com/jp/blogs/news/amazon-s3-block-public-access-another-layer-of-protection-for-your-accounts-and-buckets/

• サービスコントロールポリシーの例

✓ https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_example-scps.html

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/UsingKMSEncryption.html

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_iam-limits.html

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_condition-keys.html

https://engineer.retty.me/entry/columnar-storage-format

https://aws.amazon.com/jp/blogs/news/amazon-s3-block-public-access-another-layer-of-protection-for-your-accounts-and-buckets/

https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_example-scps.html


参考情報• 【AWS Black Belt Online Seminar】AWS Organizations

✓ https://d1.awsstatic.com/webinars/jp/pdf/services/20180214_AWS-Blackbelt-Organizations.pdf

https://d1.awsstatic.com/webinars/jp/pdf/services/20180214_AWS-Blackbelt-Organizations.pdf

Thank you!


Yohei [email protected]

S U M M I T - pages.awscloud.coms3 のデータをsql 分析 2. s3 バケットの分け方 3. マルチアカウント構成 4. s3 経由でデータ連携 5. s3...

Documents