Purpose-built Data / Analytics Serviceの選択

ゴール

次のように判断できるようにします。

Amazon S3
+
アドホックSQL
+
インフラ管理不要
        ↓
Amazon Athena

データ抽出 / 変換 / 統合
+
メタデータ管理
+
サーバーレス
        ↓
AWS Glue

Spark / Hadoop
+
大規模分散処理
+
フレームワーク制御
        ↓
Amazon EMR

反復的なBI
+
分析用データウェアハウス
        ↓
Amazon Redshift

継続イベント
+
複数コンシューマー
+
再処理
        ↓
Amazon Kinesis Data Streams

継続イベント
+
S3などへマネージド配信
        ↓
Amazon Data Firehose

Apache Kafka互換性
        ↓
Amazon MSK

状態を持つ
リアルタイムストリーム処理
        ↓
Amazon Managed Service
for Apache Flink

データレイクの
集中アクセス制御
        ↓
AWS Lake Formation

1. 最初に「分析」ではなく処理目的へ分解する

「分析基盤」という言葉だけでは範囲が広すぎます。

実際には、

データを問い合わせる

データを変換する

データをカタログ化する

大規模分散処理する

データウェアハウスへ格納する

ストリームを保持する

ストリームを配信する

ストリームをリアルタイム処理する

アクセス権限を管理する

という異なる処理があります。

そのため、

分析

というカテゴリからサービスを選ぶのではなく、

必要な処理

からサービスを選択します。

2. バッチ処理とストリーム処理を分ける

大きな判断軸の1つが、

バッチ処理
（Batch Processing）

と、

ストリーム処理
（Stream Processing）

です。

バッチ処理では、

一定量のデータをまとめる
↓
処理を開始
↓
結果を出力

という形が中心です。

例えば、

毎日深夜に
前日分のログを集計

です。

一方、ストリーム処理では、

イベント到着
↓
継続的に処理
↓
短い遅延で結果を生成

します。

例えば、

取引イベント
↓
リアルタイム異常検知

です。

3. バッチとストリームはデータ量では決まらない

例えば、

10 TB

のデータでも、毎晩まとめて処理するならバッチです。

逆に、

数KB / 秒

しか到着しなくても、

到着後数秒以内に
判定する必要がある

ならストリーム処理です。

決定条件は、

データサイズ

だけではなく、

継続的に到着するか
+
結果が必要になるまでの時間

です。

4. Amazon Athena

Amazon Athenaは、特にAmazon S3に保存されたデータを、

標準SQL

で分析するときに利用できるサーバーレスクエリサービスです。

Amazon S3
     ↓
Amazon Athena
     ↓
SQLクエリ
     ↓
結果

分析クラスターを用意して常時稼働させる必要はありません。

そのため、

Amazon S3にデータがある

必要なときだけSQL分析したい

インフラ管理を減らしたい

という場合に有力です。

5. Athenaは「サーバーレスクエリ」が決定条件

例えば、

アクセスログ
監査ログ
Parquetデータ
CSVデータ

などをAmazon S3へ保存しておき、

障害調査時だけ検索

月次分析だけ実行

データサイエンティストが
アドホックに調査

する場合があります。

このようなとき、

専用分析クラスターを
常時稼働

する必要性が低ければ、Athenaが適します。

ポイントは、

サーバーレスクエリ

です。

6. Athenaとデータウェアハウスを分ける

Amazon AthenaとAmazon Redshiftは、どちらもSQL分析に利用できます。

しかし目的は同じではありません。

Athenaが特に適しやすいのは、

Amazon S3上のデータ
+
必要時のSQL
+
アドホック分析

です。

一方、

分析用データを継続的に管理
+
多数の利用者
+
反復的なBI
+
データウェアハウス

ならAmazon Redshiftを評価します。

つまり、

SQLを使う

だけでは決めません。

7. AWS Glue

AWS Glueは、

データを発見
準備
移動
統合

するためのサーバーレスデータ統合サービスです。

代表的には、

抽出
↓
変換
↓
ロード

というETL処理を実行します。

例えば、

Amazon RDS
+
Amazon S3
+
外部データ
        ↓
AWS Glue
        ↓
変換 / 統合
        ↓
分析用Amazon S3

という処理です。

8. AWS Glue Data Catalog

AWS Glueには、

AWS Glue Data Catalog

があります。

Data Catalogでは、

データの場所
スキーマ
パーティション
テーブル定義

などのメタデータを集中管理できます。

実際のデータそのものをData Catalogへ保存するのではなく、

実データ
↓
Amazon S3など

メタデータ
↓
AWS Glue Data Catalog

と考えます。

9. AthenaとGlueは競合ではなく役割が違う

例えばAmazon S3上に分析用データを作る場合、

AWS Glue
↓
データ変換 / 統合
+
Data Catalog

Amazon Athena
↓
SQL分析

という組み合わせができます。

つまり、

GlueかAthenaか

ではなく、

データを整えるのか

と、

データを問い合わせるのか

を分けます。

10. AWS Glueはバッチ専用ではない

AWS Glueは、

定期的なETL

だけに限定されません。

ストリーミングデータを処理するETLも構築できます。

したがって、

ストリーム
=
Glueではない

とは判断しません。

重要なのは、

データ統合 / ETL

という処理が中心かどうかです。

11. Amazon EMR

Amazon EMRは、

Apache Spark
Apache Hadoop

などのビッグデータフレームワークをAWS上で利用するためのマネージドサービスです。

例えば、

大量データ
+
Spark処理
+
既存Hadoopワークロード
+
オープンソースフレームワーク

という場合に候補になります。

12. EMRではフレームワーク要件を見る

Amazon EMRを選択する決定条件は、

データ量が多い

だけではありません。

例えば、

既存Sparkアプリケーション

複数のHadoop関連ツール

フレームワーク固有設定

特定ライブラリ

クラスター構成の制御

などが必要なら、Amazon EMRが有力になります。

13. GlueとEMRをどう分けるか

AWS GlueでもApache Sparkベースの処理を利用できます。

そのため、

Sparkを使う
=
必ずEMR

ではありません。

大まかな判断軸は、

マネージドな
データ統合 / ETLを重視
        ↓
AWS Glue

Spark / Hadoopなどの
ビッグデータフレームワークを
より直接活用
        ↓
Amazon EMR

です。

AWS GlueとAmazon EMRのどちらにも、インフラ管理を削減できる実行方式があります。

したがって、

サーバーレスだからGlue

だけでは決めません。

14. Amazon Redshift

Amazon Redshiftは、

データウェアハウス
（Data Warehouse）

向けのサービスです。

代表的には、

業務データ
ログ
分析用データ
        ↓
Amazon Redshift
        ↓
SQL
        ↓
BI / レポート / 分析

という構成で利用します。

15. Redshiftを選ぶ条件

例えば、

多数の利用者が
繰り返しSQL分析

大規模な結合 / 集計

分析用データを
ウェアハウスとして管理

BIツールから継続利用

という要件では、Redshiftが有力です。

Amazon Redshiftには、

プロビジョンド

だけでなく、

Amazon Redshift Serverless

もあります。

そのため、

インフラ管理を減らしたい

という理由だけでAthenaを選ぶ必要はありません。

16. AthenaとRedshiftの決定条件

大まかには、

Amazon S3
+
アドホックSQL
+
専用ウェアハウス不要
        ↓
Amazon Athena

反復的な分析
+
データウェアハウス
+
BI
        ↓
Amazon Redshift

と考えます。

ただし両サービスとも利用範囲は広いため、

データの置き場所

だけではなく、

クエリの頻度
+
分析パターン
+
ウェアハウスとして
データを管理する必要性

を確認します。

17. ストリーミングでは役割を分解する

ストリーミングアーキテクチャでは、

取り込む

保持する

複数コンシューマーへ渡す

変換する

状態を持って分析する

最終配信先へ届ける

という役割があります。

1サービスですべてを行うとは限りません。

例えば、

送信元
↓
ストリーム
↓
ストリーム処理
↓
配信先

という構造で考えます。

18. Amazon Kinesis Data Streams

Amazon Kinesis Data Streamsは、

継続的に到着するデータレコード

をリアルタイムで収集・処理するためのストリーミングサービスです。

例えば、

IoTイベント
クリックストリーム
アプリケーションイベント

を、

プロデューサー
↓
Kinesis Data Streams
        ↓
コンシューマーA

        ↓
コンシューマーB

        ↓
コンシューマーC

のように複数の処理へ利用できます。

19. Kinesis Data Streamsではコンシューマーと再処理を見る

Kinesis Data Streamsでは、

ストリームを保持

し、

複数のコンシューマー

がデータを処理できます。

保持期間内であれば、

以前のレコードを
再度処理する

ことも可能です。

したがって、

リアルタイム取り込み
+
複数の独立コンシューマー
+
再処理

が必要なら有力です。

20. Amazon Data Firehose

Amazon Data Firehoseは、

リアルタイムストリーミングデータ

を、

Amazon S3
Amazon Redshift
Amazon OpenSearch Service
HTTPエンドポイント

などへマネージドに配信するサービスです。

基本イメージは、

プロデューサー
↓
Amazon Data Firehose
↓
配信先

です。

21. Firehoseでは「配送」が中心

例えば、

アプリケーションログ
↓
Amazon S3へ保存

したい場合、独自コンシューマーを構築して、

ストリームを読む
↓
まとめる
↓
S3へ書き込む

処理を自分で実装する代わりに、Amazon Data Firehoseを利用できます。

Firehoseはデータを一定量または一定時間バッファリングしてから配信先へ届けます。

したがって、

1件到着
↓
即時に必ず配信先へ反映

するサービスとは考えません。

22. Kinesis Data StreamsとData Firehose

両方ともストリーミングデータに関係しますが、主責任が違います。

Kinesis Data Streams
↓
ストリームを保持
+
コンシューマーが処理
+
複数コンシューマー
+
再処理

Amazon Data Firehose
↓
配信先へ
マネージド配信

です。

例えば、

複数アプリケーションが
同じイベントを独立処理

ならKinesis Data Streamsが有力です。

一方、

受け取ったログを
ほぼそのままS3へ届けたい

ならAmazon Data Firehoseが有力です。

23. Amazon MSK

Amazon Managed Streaming for Apache Kafka（Amazon MSK）は、

Apache Kafka

を利用するアプリケーション向けのマネージドサービスです。

例えば既存環境に、

Kafkaプロデューサー
Kafkaコンシューマー
Kafkaトピック

があり、

Kafka互換性を維持したい

場合に有力です。

24. Kinesis Data StreamsとMSK

Kinesis Data StreamsとAmazon MSKは、どちらもリアルタイムストリーミング基盤として利用できます。

大きな決定条件の1つが、

Apache Kafka互換性が
要件かどうか

です。

例えば、

既存Kafkaアプリケーションを
大きく変更したくない

ならAmazon MSKを評価します。

一方、

Kafka互換性は不要
+
AWSネイティブな
ストリーミングサービスを利用

ならKinesis Data Streamsが有力です。

25. Amazon Managed Service for Apache Flink

Amazon Managed Service for Apache Flinkは、

ストリーミングデータを
リアルタイムで処理 / 分析

するためのサービスです。

例えば、

時間ウィンドウ

状態を持つ集計

継続的な変換

ストリーム間の処理

などを実行できます。

26. Flinkはストリームそのものではなく処理を担当する

例えば、

Kinesis Data Streams
        ↓
Amazon Managed Service
for Apache Flink
        ↓
結果出力

とできます。

また、Apache Kafka系のストリームを入力として処理する構成も可能です。

重要なのは、

Kinesis Data Streams
Amazon MSK

が主にストリーム基盤となり、

Managed Service for Apache Flink

が、

状態を持つ
リアルタイム処理

を担当するという違いです。

27. AWS Lake Formation

AWS Lake Formationは、

データをSQL分析する

サービスでも、

ETLジョブを実行する

サービスでもありません。

主な役割は、

データレイクの
ガバナンス
+
アクセス制御

です。

28. Lake Formationではきめ細かなアクセス制御を集中管理する

例えば、

Amazon S3データレイク
+
AWS Glue Data Catalog

で管理するデータに対して、

データベース
テーブル
列
行

などの単位でアクセスを制御できます。

そのため、

複数の分析利用者
+
複数の分析サービス
+
共通データレイク
+
集中権限管理

が必要ならAWS Lake Formationを評価します。

29. Glue Data CatalogとLake Formationを混同しない

大まかには、

AWS Glue Data Catalog
↓
データのメタデータを管理

AWS Lake Formation
↓
カタログや基礎データへの
権限を集中管理

です。

例えば、

どのテーブルが存在するか

という情報はData Catalogで管理します。

一方、

誰が
どのテーブル / 列 / 行へ
アクセスできるか

というガバナンスではLake Formationが重要になります。

30. データレイクの代表的な組み合わせ

例えば、

Amazon S3
↓
データ保存

AWS Glue Data Catalog
↓
メタデータ

AWS Lake Formation
↓
ガバナンス

Amazon Athena
↓
SQLクエリ

という構成が可能です。

各サービスの役割を分けると、

ストレージ
メタデータ
ガバナンス
クエリ

を別々に選択できます。

31. バッチ分析の代表的な構成

例えば、

業務DB
ログ
外部データ
        ↓
AWS Glue
または
Amazon EMR
        ↓
変換
        ↓
Amazon S3
または
Amazon Redshift
        ↓
Amazon Athena / BI

のように構成できます。

ここで、

AWS Glue
か
Amazon EMR

は、

ETL / データ統合中心

なのか、

ビッグデータフレームワーク中心

なのかで選びます。

32. ストリーム分析の代表的な構成

例えば、

アプリケーションイベント
        ↓
Kinesis Data Streams
        ↓
Managed Service
for Apache Flink
        ↓
リアルタイム集計
        ↓
配信先

とできます。

別の要件では、

アプリケーションログ
        ↓
Amazon Data Firehose
        ↓
Amazon S3

だけで十分かもしれません。

さらに、

既存Kafkaプロデューサー
+
Kafkaコンシューマー

を維持するなら、

Amazon MSK

が候補になります。

33. 「サーバーレス」だけでサービスを決めない

複数の分析サービスで、インフラ管理を減らせます。

例えば、

Amazon Athena

AWS Glue

Amazon Redshift Serverless

Amazon EMR Serverless

があります。

しかし、

サーバーレスが必要

だけではサービスを決められません。

それぞれ、

Athena
→ クエリ

Glue
→ データ統合 / ETL

Redshift
→ データウェアハウス

EMR
→ ビッグデータフレームワーク

という主な役割が異なります。

34. サービス選択の判断表

35. 混同ポイント

36. SAP-C02での判断フロー

データ処理要件
        ↓

何をしたい？

 ├─ S3上のデータへSQL
 │      ↓
 │   Amazon Athena
 │
 ├─ データ統合 / ETL
 │      ↓
 │   AWS Glue
 │
 ├─ Spark / Hadoop
 │   フレームワーク中心
 │      ↓
 │   Amazon EMR
 │
 ├─ データウェアハウス / BI
 │      ↓
 │   Amazon Redshift
 │
 ├─ ストリーミング
 │      ↓
 │   さらに役割を確認
 │
 │   ├─ ストリーム保持
 │   │  複数コンシューマー
 │   │  再処理
 │   │      ↓
 │   │  Kinesis Data Streams
 │   │
 │   ├─ 配信先への配送
 │   │      ↓
 │   │  Amazon Data Firehose
 │   │
 │   ├─ Kafka互換性
 │   │      ↓
 │   │  Amazon MSK
 │   │
 │   └─ 状態を持つ処理
 │          ↓
 │      Managed Service
 │      for Apache Flink
 │
 └─ データレイクのガバナンス
        ↓
     AWS Lake Formation

        ↓

必要に応じて
複数サービスを組み合わせる

まとめ

目的特化型のデータ / 分析サービスを選択するときは、

分析サービス

というカテゴリから考えるのではなく、

実行する処理

へ分解します。

Amazon S3上のデータを必要なときだけSQL分析するなら、

Amazon Athena

を評価します。

データを抽出・変換・統合し、メタデータも管理するなら、

AWS Glue

が有力です。

SparkやHadoopなどのビッグデータフレームワークを活用するなら、

Amazon EMR

を評価します。

データウェアハウスと反復的なBI分析なら、

Amazon Redshift

です。

ストリーミングでは、

ストリーム保持 / 複数コンシューマー
→ Kinesis Data Streams

配信先への配送
→ Amazon Data Firehose

Kafka互換性
→ Amazon MSK

状態を持つストリーム処理
→ Managed Service for Apache Flink

と役割を分けます。

データレイク全体のアクセス制御では、

AWS Lake Formation

を評価します。

最終的には、

バッチ / ストリーム
↓
クエリ / ETL / フレームワーク /
ウェアハウス / ストリーム / ガバナンス
↓
必要な処理遅延
+
互換性
+
運用方式
↓
目的特化型サービス

の順に選択します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional 試験ガイド
• Amazon Athena — デベロッパーガイド
• AWS Glue — デベロッパーガイド
• Amazon EMR — 管理ガイド
• Amazon Redshift — 管理ガイド
• Amazon Kinesis Data Streams — デベロッパーガイド
• Amazon Data Firehose — デベロッパーガイド
• Amazon Managed Streaming for Apache Kafka — デベロッパーガイド
• Amazon Managed Service for Apache Flink — デベロッパーガイド
• AWS Lake Formation — デベロッパーガイド