【レポート】ビッグデータアーキテクチャパターンとベストプラクティス #reinvent #ABD201
原題
ABD201 - Big Data Architectural Patterns and Best Practices on AWS
概要
In this session, we simplify big data processing as a data bus comprising various stages: collect, store, process, analyze, and visualize. Next, we discuss how to choose the right technology in each stage based on criteria such as data structure, query latency, cost, request rate, item size, data volume, durability, and so on. Finally, we provide reference architectures, design patterns, and best practices for assembling these technologies to solve your big data problems at the right cost.
このセッションでは、収集、格納、処理、分析、視覚化といったさまざまな段階からなるデータバスとして、大規模なデータ処理を簡略化します。次に、データ構造、クエリ待ち時間、コスト、要求率、アイテムサイズ、データ量、耐久性などの基準に基づいて、各段階で適切な技術を選択する方法について説明します。最後に、これらのテクノロジを組み立てるための参照アーキテクチャ、デザインパターン、およびベストプラクティスを提供して、大きなデータ問題を適切なコストで解決します。
登壇
Siva Raghupathy - Sr Manager, Solutions Archtiecture
セッションレポート
このセッション
- はじめに
- ビッグデータのチャレンジ
- アーキテクチャの原則
- どうやってシンプルにビッグデータを処理するか？
- 何のテクノロジーを使うことが必要か？
- なぜ
- どのように？
- リファレンスアーキテクチャ
- デザインパターン
- まとめ
はじめに
データの急拡大に伴い、多様性（Variety）、ボリューム（Volume）、発生速度（Velocity）の３つは新しい進化を必要としています。ビッグデータ処理はバッチ処理とストリーム処理という要求に加えて、更にAIという進化があります。クラウドも仮想マシンとマネージドサービス、更にサーバレス化という進化が見られます。現在はAWSサービスはもちろん、AWS以外の製品・ソリューションなどさまざまなテクノロジが存在しますので、代表的なビッグデータアーキテクチャパターンと最適なベストプラクティスを解説します。
ビッグデータのチャレンジ
なぜ？（Why?）、どのように？（How?）、何のツールを使えばよいか？（What tools should I use?）、適切なアーキテクチャは？（Is there a reference architecture?）という観点でパターン分けします。
アーキテクチャの原則
アーキテクチャの原則は、データ分析要件を鑑み、最適なツールを選択して、伸縮自在・高可用性・セキュア・管理者不要を満たすように設計します。また、ログデータのようなイミュータブルデータはデータレイクに保存してマテリアライズするなどの適切なデザインパターンを適用します。決してビッグデータであるからと言って、コストも「ビッグ」になってはなりません。最終的にはAI/MLはアプリケーションから活用します。
どうやってシンプルにビッグデータを処理するか？
一般的なビッグデータ処理では、収集（Collect）、保管（Store）、処理/分析（Process/Analyze）、活用（Consume）の流れになります。答えが得られるまでの時間（Latency）・スループット・コストなどの要件が求められますが、一般的なデータ特長をHot、Warm、Coldを分類して表します。
テクノロジーは何を使えばよいか？
- アプリケーションデータ
- 構造化データをレコード形式で格納するのでトランザクションデータとしてインメモリやSQL、NoSQLに保存するのに適しています。
- データ転送・ログファイル
- メディアファイルやログファイルはファイルとして保存するのが適しています。
- IoTデバイス情報
- データストリームはイベントストリーム（DynamoDBStream、Kinesis Stream、Kafka）に保存するのが適しています。
- ストリームストレージが適している理由は、疎結合なProduceers-Customersパターンと、並列かつ永続的なキューでデータ損失がないこと
- 一方、SQSは標準ではFIFOではなく、ストリーミング MapReduce や並行読み込みができない
ストリーム/メッセージストレージは何を使うべきかを分類したのが、以下の表になります。Kinesis Stream と Kinesis Firehose の違いは、Firehoseはキャパシティが伸縮自在である代わりに順序保証されません。
ファイルオブジェクトストレージ、特に永続的なファイルストアはS3を使います。ビッグデータフレームワーク（Spark, Presto, Hive）がネイティブサポートであり、ストレージとコンピューティングを分離できるからです。イレブン・ナイン可用性、低価格、セキュリティ（SSL）、リージョン内リプリケーションにコストが発生しないという長所があります。HDFSにデータを退避するとしたら同じデータセットを何度も読む場合です。
キャッシュのデータベースは、ElastiCache、DynamoDB、DynamoDB(DAX)、RDSが挙げられます。アプリケーションからこれら適切なデータベース層を使うのがベストプラクティスです。具体的にはKinesis ConsumerやLambdaファンクションからデータストアに保存して、アプリケーションからキャッシュのビュー・サーチビュー・（イミュータブルな）ファイルとして見えるようなマテリアライズドビューを提供します。
データ構造やアクセスパターン毎の選択を分類すると以下の表になります。
データ構造とその他で分類すると一般に以下の傾向が見られます。
つまり、どのユースケースに、どのデータソースを使うのが適切であるかは以下の表にしてください。
リファレンスアーキテクチャ
将来的に小さな多くのファイルをピーク時に10億回呼び出し、1.5TB/月になる想定のもと、コスト感覚を持って設計するとします。S3とDynamoDBで比較した場合、アクセス要件が異なるとコストが逆転することが起こりえます。
- 処理/分析（Process/Analyze）の予測分析は Amazonn AIの中から選択します。
- インタラクティブ・バッチ分析は Amazonn ES、Redshift(Spaectrum)、Athena、EMRのサービスの中から選択します。
- ストリーミング/リアルタイム分析はSparkストリーミングを利用したEMR、KCL、Lambdaのサービスの中から選択します。
どのストリーム処理テクノロジを使うべきかは以下の表になります。
どの分析ツールを使うべきかは以下の表になります。
ETLは何を使うかは、AWS Glueの他に、データインレギュレーションパートナーの製品（Alteryx等）を使うという選択肢があります。
活用（Consume）は、何らかのコンピューティング上でデータサイエンスツールやBIツールを用いて可視化するのが一般的です。
デザインパターン
ビッグデータアーキテクチャは、データソースは最もHotなのがリアルタイム、最もColdなのがバッチ処理と分類されます。一方、テクノロジはリアルタイム、インタラクティブ、バッチ毎に適切なテクノロジを採用します。
リアルタイム分析
インタラクティブ・バッチ分析
データレイク
まとめ
- 連携したシステムを構築する
- ジョブに適したツールを選択する
- 効果的なAWSのマネージドサービスを採用する
- ログ中心のデザインパターンを採用する（データレイクの実現）
- コスト意識を持つ
- AI/MLアプリケーションに取り込む
感想
この一年間で、Amazon Athena、Amazon Redshift Spectrum、AWS Glue（とAWS環境共通で利用できるデータカタログ）の登場によって、ビッグデータアーキテクチャのベストプラクティスに大きな変化が起こりました。Glueによって全てのデータストアは統合され、Redshift Spectrum/Athenaによってデータレイクがより身近になりました。この変化は、ビッグデータアーキテクチャパターンの多様化をもたらしましたが、本セッションでは複雑化したソリューションを最適化するためのベストプラクティスを提供しています。この変化は必然であり、あるべきデータ分析基盤を再設計するチャンスと受け止めて頂けたら幸いです。
