【レポート】セルフハンズオン AWS ではじめるデータ分析〜データレイクハンズオン〜はデータ分析を始めたいあなたにぴったりのセッションです #AWSSummit

"データ分析始めてみたいぞ、でも何からしたらいいかわからん。"そんな方はいませんか。私も同じです、新卒エンジニアのたいがーです?

”AWS ではじめるデータ分析〜データレイクハンズオン〜”は、そんなデータ分析を始めたい！あなたの悩みを解決してくれる、入門者にとても易しいセッションでした。最後まで取り組むことでデータの可視化も行うことができます。早速、取り組んでいきましょう！

ハンズオンの動画についてはこちらからご覧ください。

セッション概要

冒頭に、データ分析の概要と AWS でデータ分析をはじめる上で大切な考えであるデータレイクについて簡単に解説します。続いて、公開されているデータレイクハンズオンの一部分の内容をもとに、Amazon S3、Amazon Kinesis Data Firehose、AWS Glue、Amazon Atnahena、Amazon QuickSight を実際に操作しながら、データレイクを始める方にもわかりやすく丁寧に解説します。

スピーカー

アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト 倉光 怜氏 アマゾン ウェブ サービス ジャパン株式会社 パートナー技術本部 パートナーソリューションアーキテクト 大林 加奈子氏

セッション対象者

• これまでデータ分析の経験がなく、何から始めていいかわからない方
• "これからデータ分析を始めたい!"というエンジニアの方

セッションのゴール

• AWSでデータ分析する上で重要な考え方である"データレイク"について理解する
• 具体的なソリューションを実際に手を動かしながら体感する事で、データレイクの基本を理解するとともに、データ分析する上での初めの一歩を踏み出す
• よりデータ分析を深く理解するためのNext Actionに繋げる

環境変化とデータ活用の課題

データ活用の目的は何か？

データに基づいてビジネスに役立つ意思決定をする事。意思決定に必要なデータが不足している場合にはデータを集める必要がある。

データウェアハウス(DWH)とリレーショナルデータベース(RDB)の違い

これまでアプリケーションに必要なデータはRDBに格納されており、そのデータを分析する際はDWHに送信し、そこからDIツールを使い分析していた。

しかし、データ量は飛躍的に増加したり、データを活用とする動きが出てきたりしている。それを分析可能しようとする技術により、その活用パターンは増えてきている。

データレイクとは？

全てのデータを生のフォーマットのままで安全に貯めておき、必要な時に必要なデータを取り出して分析できるようにする。

これまで、DWHのストレージ容量制約によって捨てていたデータや、あまり分析に使ってこなかった画像や動画データをデータレイクに集約させる。これにより、データを削除する事なく保存しておくことができ、今は不要でも将来的に必要なデータも保存することができる。データレイクは未来の不確実性に対処する術である。

データレイクに必要な要件

すぐに利用できる状態であることが重要である。

• AWSのデータレイク=S3
• S3はさまざなAWSサービスと利用することができる。

ハンズオンの概要

シナリオ

ハンズオンで使っていくサービス

• Amazon S3(Simple Storage Service)
  • 容量無制限で高い堅牢性を持ったオンラインストレージサービス
• Amazon VPC
  • AWS上にプライベートネットワークを構築できる
• Amazon EC2
  • 仮想マシン
  • 物理からOSまでの環境をAWS側で準備、ユーザー側でエンドウェアや独自アプリケーションを入れて実行可能
• AWS CloudFormation
  • Infrastructure as Codeなサービス
• AWS IAM
  • AWSサービスを操作するためのアクセス権限を管理、付与
• Amazon Kinesis Data Firehose
  • サーバーレスで様々なデータストアと直接連携可能なストリーミングサービス
  • 今回のハンズオンではEC2で生成されたログをS3に配置
• Amazon Athena
  • サーバーレスでS3にあるデータに対して標準SQLを使用し、簡単に分析できるインタラクティブクエリなサービス
• Amazon QuickSight
  • サーバーレスで様々なAWSサービスと統合可能なDIサービス
  • 今回のハンズオンではAthenaでクエリを行ったのち、QuickSightで可視化していく

ハンズオン

今回は東京リージョンで実施。

こちらのハンズオンの中の、Lab1とLab4に取り組んでいく。

Lab1：始めの準備

• ログを生成し続けるEC2を作成。(2分おきに10件前後のログが出力され、10分おきに300件のエラーログを出力)
• CloudFormationからVPCやEC2を構築し、手動でFluentedをインストールする。その後、IAMロールを一つ作成し、EC2をアタッチする。

EC2ダッシュボードからキーペアを作成する

マネジメントコンソールのEC2ダッシュボードからキーペアをクリックし、キーペアを作成する。

CloudFormationでVPC, EC2を作成する

CloudFormationのスタックを作成していく。

ここで使用するCloudFormationのテンプレートは、資料として配布されているフォルダの中である/labs1/asset/ap-northeast-1/1-minlake-ec2.yamlに格納されている。

次にスタックの詳細を設定をしていく。

スタックの名前をhandson-minlake、EC2インスタンスのインスタンスタイプはデフォルトのt2.microのまま、KeyPairは先ほど作成したhandsonを選択する。

最後に、スタックオプションの設定を行う。

タグには、キーをName、値をhandson-minlakeに設定する。

それ以外は設定せず、スタックを作成していく。

SSMからEC2に接続するため、IAMロールを作成する。

次にIAMロールを作成していく。

ロールの作成から、AWSサービス/EC2を選択する。

SSMで検索し、AmazonEC2RoleforSSMを選択する。

次のセクションでタグは設定せず、次に進む。

名前をhandson-minlakeとし、ロールを作成する。

IAMロールをEC2インスタンスに割り当てる

先ほど作成したIAMロールをEC2インスタンスに割り当てる。

EC2インスタンスの一覧から先ほどCloudFormationで作成したインスタンスを選択した上でアクション→インスタンスの設定→IAMロールの割り当て/置換を選択する。

先ほど作成したIAMロールを選択し、適用させる。

SSMからインスタンスに接続する

左ペインからセッションマネージャーを選択し"、セッションを開始する"を選択する。

先ほど作成したインスタンスが表示されているので、選択し、セッションを開始する。

インスタンス上で操作していく

まずは、ログインユーザーを調べていく。

$ whoami
ssm-user

デフォルトのssm-userでログインされていることがわかる。

今回は、ec2-userにスイッチする。

$ sudo su - ec2-user

ログが2分起きに出力されていることを確認するため、rootユーザーに切り替え、ログを確認する。

$ sudo su -
# tail -f /root/es-demo/testapp.log

ログの出力時間を確認すると、2分おきに出力が確認できる。

[2020-09-15 23:52:01+0900] INFO prd-web001 uehara 1001 [This is Information.]
[2020-09-15 23:52:01+0900] INFO prd-web001 kimura 1001 [This is Information.]
[2020-09-15 23:52:01+0900] INFO prd-web001 uehara 1001 [This is Information.]
[2020-09-15 23:54:01+0900] INFO prd-web001 uehara 1001 [This is Information.]

ここまでで分析用のログを出力できたことを確認できる。

続いて、ログ収集ソフトのFluentdのインストールと設定を行なっていく。(引き続きrootユーザーのままで作業を行う)

# yum -y install redhat-lsb-core gcc

既に提供されているAMIは今回インストールされるamzn-main、amzn-updatesを提供されているので、Nothing to doと表示されている。

続いて、td-agentをインストールする。

# rpm -ivh http://packages.treasuredata.com.s3.amazonaws.com/3/redhat/6/x86_64/td-agent-3.1.1-0.el6.x86_64.rpm

続いて、rd-agentの実行ユーザーであるTD_AGENT_USERをtd-agentからrootに変更していく。

# vi /etc/init.d/td-agent

18行目にあるTD_AGENT_USERの指定を、以下のように変更していく。

TD_AGENT_USER=root

変更後、Fuluentdの自動起動設定を行う。(実際の起動は後ほど行う。)

chkconfig td-agent on

Lab4: アプリケーションログの永続化と長期間データの分析と可視化

EC2で出力されるログをストリームデータとして見立て、Fluentdを使ってAmazon Kinesis Data Firehoseを介し、Amazon S3にデータを取り込む。取り込んだデータに対し、AWS Glueを使ってテーブルを作成し、そのテーブルに対しAmazon Athenaを使ってアドホックな分析を行い、Amazon QuickSightで可視化させていく。

S3バケットの作成

ログデータを取り込むS3バケットを作成していく。マネジメントコンソールでS3バケットのページを開き、バケットを作成するを選択する。

バケット名を設定し、作成を選択する。

Kinesis Data Firehoseの作成

次に、Kinesis Data Firehoseを作成していく。

真ん中の"配信ストリームを作成"を選択する。

Step 1ではDelivery stream nameをminilake1設定し、Nextを選択する。

こちらで設定する名前を他のものに設定した場合、/etc/td-agent/td-agent.confの設定時に利用する/lab4/asset/ap-northeast-1/4-td-agent2.confの中のdelivery_stream_nameの値を編集する必要があります。

Step 2ではデフォルトのままでNextを選択する。

S3 destinationのセクションで、先ほど作成したS3バケットを選択する。

そして、S3 prefixではminlake-in1/と設定し、ディレクトリ以下にログが配信されるようにしておく。(スラッシュは忘れないようにする)

次へ進みます。

S3 buffer conditionsでBuffer sizeはデフォルトのまま、Buffer Intervalは60secondsに変更する。このどちらかの条件を満たした際に、Amazon S3への配信がトリガーされるようになる。それ以外の設定はそのままにし、Nextを選択する。

最後のReview画面で確認し、Create delivery streamをクリックする。StatusがCreatingになっているので、そのまま次のステップに進む。

IAMロールのポリシーを追加し、Kinesis Data Firehoseへの権限を付与する

IAMロールの一覧から、先ほど作成したIAMロールを選択する。

"ポリシーをアタッチする"を選択する。

AmazonKinesisFirehoseFullAccessのポリシーをアタッチする。

アタッチしたことを確認し、再びSSMからセッションマネージャーでEC2インスタンスに接続する。

FluentdからKinesis Data Firehoseにログデータを送信するための設定をする

rootユーザーに切り替え、Kinesis Data Firehoseのプラグインをインストールする。インストールが終了したら、インストールを確認する。

$ sudo su -
# td-agent-gem install fluent-plugin-kinesis -v 2.1.0
# td-agent-gem list | grep plugin-kinesis

次に、Fluentdのconfigファイルの中身を編集していく。

# vi /etc/td-agent/td-agent.conf

すでに記載されている全文を削除(viコマンドの":%d"などで削除)し、ハンズオンの資料のフォルダの中の/lab4/asset/ap-northeast-1/4-td-agent2.confファイルをエディタ等で開き、コピーしペーストする。

次に、/etc/init.d/td-agentファイルにリージョンの設定を追加していく。

# vi /etc/init.d/td-agent

14行目辺りにこちらの文面を追記します。

export AWS_REGION="ap-northeast-1"

これで、リージョンの設定は完了した。リージョンを変更した場合は適宜こちらの記載を変更する。

Fluentdの設定ファイルの変更が終わったので、Fluentdを再起動する。

# /etc/init.d/td-agent restart

ここまで設定を終えたら、EC2のログデータがFluentdを介しS3にデータを出力されているはずだ。(この処理は数分程度かかります)

マネジメントコンソールのS3の画面から確認していこう。先ほど作成したS3バケットを開いてみる。

先ほどKinesis Data Firehoseの作成時に設定したprefixでファイルが作成されていることが確認できる。

どんどん階層を降りていくと、ログファイルが格納されている。

次にKinesis Data Firehoseでも確認してみる。Kinesis Data Firehoseの一覧から先ほど作成した物を開き、そのMonitoringタブを開く。

• Records delivered to Amazon S3
• Bytes delivered to Amazon S3

こちらの2点が急上昇しているのが確認できた。

ここまでの手順により、EC2のログがFluentdを使ってAmazon Kinesis Data Firehoseに連携され、Amazon S3に取り込まれるようになった。

ここからは、取り込まれたデータをGlueを使ってテーブルを作成し、そのテーブルに対して、Athenaでクエリ分析を行う。また、QuickSightを使って可視化も行っていく。

Glueをを操作するためにIAMロールの設定を変更していく

IAMロールの一覧から先ほど同様にポリシーをアタッチしていく。

今回アタッチするポリシーはこの二つ。

• AWSGlueServiceRole
• AmazonS3ReadOnlyAccess

この二つを追加することによって、IAMロールにアタッチされているポリシーはこの4つになる。

• AmazonEC2RoleforSSM
• AWSGlueServiceRole
• AmazonS3ReadOnlyAccess
• AmazonKinesisFirehoseFullAccess

続いて信頼関係タブに移動し、"信頼関係の編集"をクリックする。

{
		"Version": "2012-10-17",
		"Statement": [
   		{
     		"Effect": "Allow",
     		"Principal": {
       		"Service": [             
         		"glue.amazonaws.com",
         		"ec2.amazonaws.com"
       		]                        
     		},
     		"Action": "sts:AssumeRole"
   		}
 		]
}

このように変更し、信頼関係にGlueを追加する。"信頼ポリシーの更新"を行い、信頼するエンティティにGlueが追加されていることを確認する。

Glueのクローラ機能を使ってスキーマの自動作成をする

マネジメントコンソールのAWS Glueを開く。

今すぐ始めるをクリック。

左ペインから"クローラ"を選択し、"クローラの追加"をクリックする。

クローラの名前に任意の名前を入力し、"次へ"をクリック。次の画面でも"次へ"をクリックする。

次の画面ではインクルードパスを設定する。横のファイルマークを選択すると、"S3パスを選択"という画面が表示される。

先ほど作成した"minlake-in1"というファイルを選択する。設定ができたら次へ進む。

次の項目に関しても変更せず、次へを選択する。

IAMロールの設定画面に関しては、先ほど変更したIAMロールを使用するので、真ん中の既存のIAMロールを選択を選ぶ。

先ほどのIAMロールを選択し、次へ進む。次のスケジュール設定もそのままで、次へ進む。

続いてクローラの出力の設定では、データベースの追加を選択する。

データベース名に任意の名前を設定し、次へ進む。内容に関して確認し、問題なければ完了する。

すると、クローラの一覧のページに戻る。

先ほど作成したクローラを選択し"クローラの実行"を行う。ステータスがReadyからStartingになったら、しばらく待つ。

再び、ステータスがReadyに戻ると、画面上部にこのようなコメントが表示される。

左ペインからテーブルを選択すると、新たなテーブルが作成されていることが確認できる。

作成されたテーブルを選択すると、テーブルの定義情報、スキーマの定義情報が確認できる。

Athenaを使い、クエリを実行する

マネジメントコンソールでAthenaの画面を開く。

今すぐ始めるをクリックすると、このようなメッセージが表示される場合がある。

表示されている場合、"Amazon S3 でクエリ結果の場所を設定する"をクリックし、設定していく。

クエリの結果の場所には先ほど作成したS3バケット/resultというように指定し、保存する。

続いて、クエリを実行していく。

データベースには先ほど作成したデータベース(今回の場合であればminilake)が選択されていることを確認する。

テーブルの中にある先ほど作成したminilake_in1の右に表示されている三点をクリックし、テーブルのプレビューをクリックする。

すると、minilake_in1テーブルの最初の10行に対してクエリが実行される。

+ボタンを押し次に新しいページを開き、クエリを実行していく。

Where句の日付にはデータが実在する物を入力する必要がある。例えば、今回の場合はハンズオンを実行している日時を記載する必要がある。

partition_0には年を、partition_1には日を、partition_3には時間を入力する。partition_3の時間に関しては、Kinesis Data　Firehoseで取り込まれた後にパーティションする際の時間になっているので、JSTではなくUTCになっている。そのため、現在実行する時間から9時間前の時間を記載する必要がある。

SELECT * FROM "minilake"."minilake_in1" where partition_0 = '2020' AND partition_1 = '09' AND partition_2 = '16' AND partition_3 = '13';

処理結果として、このように大量のログを出力した。

QuickSightのアカウントを作成する

マネジメントコンソールでQuickSightの画面を開くと、このように表示される。

Sign Up for QuickSightを選択する。

今回のシナリオではEnterpriseを選択していた。

(最初の設定でも"Enterprise"が選択されていますが、今回のシナリオはStandardでも可能なようなので、私はStandardを選択しました。)

続いて、QuickSight アカウントの作成を行う。初期段階ではバージニア北部リージョンになっているので東京リージョンに変更する。

変更する際このようなメッセージが出てくるが、OKを選択する。

QuickSightのアカウントの作成を進めていく。アカウント名、メールアドレスを設定し、完了をクリックする。

しばらく経つとアカウントの作成が終了し、このような画面が表示されるので"Amazon QuickSightに移動する"をクリックする。

QuickSightのセキュリティとアクセス権限を設定する

QuickSightからAthenaにアクセスし、クエリを実行するため、セキュリティとアクセス権限を設定していく。

右上の人型アイコンをクリックし、QuickSightの管理を選択する。

メニューの中からセキュリティとアクセス権限ペインを選択する。

"接続された製品とサービス"セクションの"追加または削除する"をクリックする。

Athenaはすでに選択されているのでS3を選択していく。Amazon S3の項目の中の詳細をクリックする。

"S3バケットを選択する"が表示されるため、クリック。

先ほどしたバケットを選択し、"バケットの選択"をクリックする。

このように表示されたら下の更新ボタンをクリックし、更新する。更新が終了したら下のトップ画面に戻る。

この画面、右上の"新しい分析"をクリックする。

この画面の"新しいデータセット"を選択する。

今回はAthenaを使っていく。

まず、データソース名に任意の名前(今回はminilake1)を入力し、接続を検証する。

接続が検証されたら、"データソースを作成"をクリック。

データベース、テーブルともに先ほど作成したものを選択する。

今回はQuickSight上でデータを保持するSPICEを使用するので、そのままの設定で"Visualize"をクリックする。

インポートが完了するとこのようなメッセージが右上に表示される。それでは取り込んだデータを使って可視化を行なっていく。

例えば水平棒グラフでalarmlevelを見てみる。

続いて、ユーザーを追加してみる。

このように簡単に可視化を行うことができる。左上の追加からビジュアルを追加し、さらにいろいろなグラフを表示させることも可能である。

Clean up

最後に全てのリソースを削除していく。

QuickSight

先程設定したQuickSightの管理から、アカウント設定ペインを選択する。

サブスクリプション解除を選択。

次にS3バケットを削除していく。マネジメントコンソールでS3バケットの画面を開く。

先程作成したS3バケットを選択し、削除する。

続いて、Kinesis Data Firehoseを削除していく。

左ペインからData Firehoseを選択し、先程作成したstreams選択、deleteをクリックし、削除する。

続いてGlue。

左ペインからクローラを選択し、作成したクローラを選択。アクションでクローラの削除をクリックする。

続いて、左ペインからテーブルを選択し、作成したテーブルを選択。アクションでテーブルの削除をクリックする。

最後に、データベース。こちらも作成したものを選択し、アクションから削除していく。

CloudWatch Logsのロググループも削除していく。AWsマネジメントコンソールのCloudWatchのページの左ペインからロググループを選択する。今回削除するのはこの二つ。

• /aws-glue/crawlers
• /aws/kinesisfirehose/minilake1

これらはどちらも削除していく。

続いてCloudFormationのスタックを削除する。

こちらも削除を選択する。

次に作成したIAMロールの削除を行う。IAMロールの一覧からロールの削除を選択する。

最後に、最初に作成したkaypairも削除する。これでハンズオンの全て行程が終了。

セッションの振り返りとNext Action

これまでデータ分析にあまり馴染みのなかった方もすぐに始められることを体感できたのではないだろうか。

Nextアクションとしては以下のようなものが挙げられる。

• データレイク ハンズオンの残りのLabを取り組めば、DWHを使ったものからリアルタイム分析まで含まれており、より理解が深まるだろう。
• 個々のAWSサービスについて、さらに理解を深める
• 社内で勉強会を実施し、アウトプットを行う

感想

可視化まですごく早いスピードで達成することができ、驚きました。

今回、データ分析で使ったAWSサービスには、初めて使うものも多かったため、非常にワクワクしました。他のハンズオンに関しても取り組んでみたいです。

以上、たいがーでした！