[レポート]ANT201: ビッグデータ分析アーキテクチャのパターンとベストプラクティス #reinvent

AWS re:Invent 2018

#AWS

じょんすみす

2018.11.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、小澤です。

本記事は現地時間2018/11/26-30で行われているre:Invent 2018のセッション「Big Data Analytics Architectural Patterns and Best Practices」のレポートとなります。

セッション概要

本セッションの概要は以下の通りです。

セッションタイトル：
　Big Data Analytics Architectural Patterns and Best Practices

登壇者：
Ben Snively - Principal Solutions Architect, Amazon Web Services

セッション概要：
In this session, we discuss architectural principles that helps simplify big data analytics.

We'll apply principles to various stages of big data processing: collect, store, process, analyze, and visualize. We'll disucss 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.
(このセッションでは、大規模なデータ分析を簡素化するためのアーキテクチャ原則について説明します。

大規模なデータ処理のさまざまな段階、つまり収集、保存、処理、分析、視覚化に原則を適用します。データ構造、クエリの待ち時間、コスト、要求率、アイテムサイズ、データ量、耐久性などの基準に基づいて、各段階で適切なテクノロジを選択する方法を説明します。

最後に、これらのテクノロジを組み立てるための参照アーキテクチャ、デザインパターン、およびベストプラクティスを提供して、大きなデータ問題を適切なコストで解決します。)

セッションレポート

データ活用のタイプ

データ分析を行う際にはまずそれがどのような活用するのかを考えなければなりません。

本セッションではデータ分析の種類として3つをあげています。

バッチ処理やBIなどからのインタラクティブな操作
リアルタイムにストリームデータを処理する
機械学習

また、どのような仕組みを使ってデータ分析の結果を活用するのかも考えなければなりません。

可視化する
マネージドサービス(EMRやRedshiftなど)を活用する
サーバレスな仕組みを活用する(AthenaやGlueなど)

ビッグデータを活用するためのツールは数多くあり、AWS上のサービスも充実しています。

データ分析に必要な処理とその流れ

個別の処理で利用すべきアーキテクチャを開設する前に、まずは単純化したデータ分析の流れ全体像を伝えています。

処理の流れとしては

データを集める
データを蓄える
分析や前処理などデータに対する処理を行う
分析結果から洞察を得る

となっています。ここでは、前処理やデータの加工と分析そのものをProcessとして扱っています。

分析で扱うデータには温度という考え方があります。これは比喩表現ではありますが、扱う頻度やデータ量に応じて3つに分けられます。

Hot、すなわち熱いデータは最も高頻度にアクセスされる少量のデータを表しています。これはリアルタイムに処理されるデータのようにまさにその瞬間のデータとしてほしいものとなります。必要なのはその瞬間のデータのみなので量としてはわずかですが低レイテンシで取得可能なことが求められます。

Warm、温かいデータはHot程ではないがよく利用されるデータとなります。これはたとえば直近〇週間など利用頻度がいろんな場面で分析されることが多くなるデータとなります。

ここまでで何となくわかるかと思いますが、Cold、冷たいデータはめったに利用されないが蓄積はしている過去数年分のデータなどといったものになります。

データの収集・保存

これらの基礎知識を踏まえて各プロセスで必要となる要素を順にみていきましょう。まずは最初の"データを集める"部分となります。

このプロセスでは何で使っているデータかによって適切な保存先が異なります。

Webやモバイルアプリで利用するデータであれば、そのシステムで活用しているデータベースなどが保存先となっています。

ログデータはファイルやオブジェクトストレージに蓄えられます。

ストリームデータは少々特殊ですが、Stream Strageというものに蓄えられます。

ストリームデータはHotなデータです。これはApache KafakaやAmazon Kiensis Data Stream/Data Firehoseといったものつかって処理やデータの保持をしておきます。

ログデータなどサービスが活用されることによって生成されるデータはファイルやオブジェクトストレージに保存しておくことになります。ここではData Lakeとしての性質もあります。そのため、保存先として適切なものはS3となります。

アプリケーションが保持するデータは通常データベースなどに蓄積されています。 RDBやNoSQL、キャッシュなどの選択肢があるのでそれぞれ用途に合わせて適切なものへ保存します。

データの処理・分析

蓄積されたデータには必要な前処理・加工などを行ったり、データを使って分析したりします。

このプロセスではどんな処理を行いたいかによって利用するツールを使い分けます。

「バッチ処理やBIなどからのインタラクティブな操作」では、その名の通り、定期的な処理の実行だったり、人間が都度処理を実行するようなものになります。

データを多角的に分析するためにAthenaやRedshiftを使ってインタラクティブにクエリを実行したり、EMRを使ったバッチ処理をおこなうなど大規模なデータに対してそのまま何らかの処理を行うような場面が想定されます。また、構造化されていない文書データなどはElasticsearch Serviceを利用して検索可能な状態にしておくという使い方も可能です。

「リアルタイムにストリームデータを処理する」ような場面では先ほどのデータの収集・保持でも利用されたKinesisやApache Kaflaをそのまま利用します。そのほか、EMRのSparkでSpark Streamingを利用することも可能です。

機械学習などの予測分析を行う場合は、AWSが提供する機械学習サービスのスタックを利用することが可能です。マネージドサービスがそのまま活用できれば使わない手はないですし、プログラム自体の実装が必要な場合はSageMakerやDeep Learning AMIを利用できます。また、それらを支えるインフラ環境としてP3インスタンス、C5インスタンスなども用意されています。

やりたいことと利用できるサービスの対応をまとめると以下のようになります。

最終的に必要な結果を得るためのソリューション

データ分析では最終的に何らかの洞察を得るか、機械学習による自動化の仕組みを作ることになります。

この流れはProcessの中でETL/ELT処理をした結果を保持して、その結果を加工して...と繰り返す中での最後のプロセスとなります。

例えば機械学習であれば、SageMaker上でJpyter Notebookなどデータサイエンティストが行う処理になります。また、インタラクティブな操作であればデータから洞察を得るためにQuickSightやTableauなどのBIツールを活用します。

おわりに

今回は「Big Data Analytics Architectural Patterns and Best Practices」のセッションレポートを書かせていただきました。データはシステムよりの長寿なので、しっかりと考えて設計する必要があるということも言われる時代です。適切なデータがなければ適切な分析が行えず、適切な分析が行えないと自社サービスにも影響が出る時代ですので、ぜひ参考にしてただければと思います。