【レポート】AWSクラウドで実現するBigData活用

DI部の川崎です。

AWSJ主催のセミナー「AWSクラウドで実現するBigData活用」を受講する機会がありましたので、その模様をお伝えします。

セミナーの概要

Big Data という言葉を聞くようになって久しいですが、様々なツールを使い Big Data からビジネス価値を導き出しているお客様も増えております。 当セミナーでは Big Data に対して AWS が提供するソリューションを紹介するとともに、様々な AWS サービスを組み合わせた Big Data パイプラインの具体的な実現方法、当社が提供するサポートについてご紹介いたします。 貴社への Big Data 導入に向けて具体的に役立つ情報が得られます。ぜひご参加ください。

【参考】 ビッグデータパイプライン

本セミナーのキーワード「ビッグデータパイプライン」に関して、参考になりそうなリンクを挙げておきます。

ビッグデータ 101 ～ AWS で始めるビッグデータパイプラインの設計と実装～ | AWS Summit Tokyo 2016
（動画 | セッション資料）
[レポート] ビッグデータ 101 ～ AWS で始めるビッグデータパイプラインの設計と実装～ #AWSSummit
Developers.IO 2017セッション「AWSで始めるビッグデータ分析」で話しました #cmdevio2017
→「 パイプラインで考えるデータ分析基盤」

タイムテーブル

時間	講演内容
13:30-14:15	「Collecting Data onto AWS」 アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト　半場　光晴
14:15-15:00	「Processing/Storing Data on AWS」 アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト　川村　誠
15:30-16:15	「Analyzing Data on AWS」 アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト　志村　誠
16:15-17:00	「AWS Big Dataサービスとセキュリティ」 アマゾン ウェブ サービス ジャパン株式会社 プロフェッショナルサービス　松本　照吾
17:00-17:30	「Big Data 取り扱い方のクラウドとオンプレミスとの違い」 アマゾン ウェブ サービス ジャパン株式会社 テクニカルトレーナー　上原　誠

講師陣のみなさま

セッション1：Collecting Data onto AWS

ビッグデータパイプライン（Collect：収集）

• データを集める前に
  • GIGO：Garbage in, garbage out
    • 「ゴミを入れればゴミが出てくる」
• データを集めることの重要性
  • データマイニング界の格言
    • More data usually beats better algorithms.
    • （大量のデータは、高度なアルゴリズムに勝る）
  • Deep Learning：学習データの量は重要なファクターのひとつデータを集めることの重要性
• データを集める

• S3にデータを集める

• S3に集めたデータを活用しやすくする
  • データカタログーメタデータインデックス
    • DynamoDBに属性（メタデータ）を保存する
  • データカタログ―サーチインデックスを作る
  • S3ストレージインベントリ
    • バケット内のオブジェクトのリストと、各オブジェクトのメタデータ
      • CSVファイル（圧縮済）で出力される
• S3と関連するAWSサービス
  • Amazon Athena
    • テーブルの作成
  • S3とRedshift
    • Amazon Redshift Spectrum
  • S3とEMR
    • EMRFS：S3をHDFSのように扱う
      • 計算資源とストレージを分離
      • クラスタのシャットダウンが可能
        • クラスタを消してもデータをロストしない
      • 複数クラスタ間でデータ共有が簡単
      • データの高い耐久性
• S3に効率よくデータを集める
  • バッチ分析：DMS（Database Migration Service）
  • リアルタイム分析：Kinesis
  • S3とDMS
    • マネージド型データベース移行サービス
    • AWSの外からも、中に閉じても、実行可能
      • オンプレDB→クラウド間
      • VPC間
    • ワンショットだけでなく、継続的なレプリケーション（CDC）の可能
  • S3とKinesis
    • ストリームデータを収集・処理するためのフルマネージドサービス群
      • Amazon Kinesis Streams
      • Amazon Kinesis Firehose
      • Amazon Kinesis Analytics

• まとめ
  • データを集める目的を具体的に持とう
  • たくさん、データを集めよう
    • 高度なアルゴリズムと同様に、大量のデータも重要
    • さらに、早く、データを集めよう
  • 基本的に、S3に集めよう
    • 容量無制限、高い耐久性と可用性
    • より低いレイテンシ、より高いI/Oやスループットが必要なら、Kinesis（からのS3）
    • 構造化・半構造化データということが明白なら、DynamoDBもあり

セッション2：Processing/Storing Data on AWS

ビッグデータパイプライン（Process/Store：処理/保存）

• Store
  • データ種別に応じたストレージを利用する

• データ特性に応じたストレージを利用する

• データレイク

• Process
  • ビッグデータ処理の課題
    • データサイズ増大による新たな課題
      • リアルタイムストリーム処理
      • 複雑なデータ処理と分析の増大
      • インタラクティブなアドホッククエリの増大
  • 処理種別に応じた適切な処理基盤を利用する

• Hadoopエコシステム
  • EMRは、インストールされたソフトウェアの設定の最適化を可能にするコンポーネントを提供

• ラムダアーキテクチャ
  • ラムダを使って、バッチ処理の結果に、最新のストリーミング処理をマージ
• まとめ
  • Store
    • データ種別／特性に応じたストレージを利用する
  • Process
    • 処理パタンに応じた適切な処理基盤を利用する
  • データレイク／ラムダアーキテクチャ
    • 効率的なデータライフサイクルを設計する

セッション3：Analyzing Data on AWS

ビッグデータパイプライン（Analyze：分析）

• アナリティクスとはなにか
  • データに対してさまざまな処理を行うことで、なにがしかの価値を導き出すこと
• アナリティクスの種類
  • レポーティング
    • あらかじめ決めたKPIに沿って定期的に集計を行い、結果を表やグラフとして可視化
  • アドホック分析
    • ビジネス課題を解決する糸口を見つけるため、探索的にデータを加工、集計、可視化する
  • データサイエンス
    • ビジネス上の意志決定に使うための高度な分析や、機械学習モデルを含んだシステムを構築する
• レポーティング
  • SQL + BI ツール
  • Redshift + QuickSight
• アドホック分析
  • SQL + BI ツール
  • Athena or Redshift + QuickSight
• データサイエンス
  • R / Python / Hadoop
  • Jupyter notebook on EC2 / EMR
• 事例
  • すかいらーくさま：データを活用した取り組み
    • 多様なマーケティング施策の実施
      • CMを含む各種プロモーションに対し、ABテスト
      • POSデータの項目を戦略的に追加し、分析の軸を増やす
    • パーソナライズ施策の実施
      • 広告、クーポンを各お客さまの属性に合わせて配信
  • 日本経済新聞社さまのAI 記者
    • 決算サマリーを自動生成して配信
    • 2017/1/25-5/26 で6787 サマリーを生成、1-2 分で記事を公開
• まとめ
  • AWSを活用することで、アナリティクスのどのフェーズにおいても、高速かつスケーラブルに分析を実行することができる
  • Redshift+QuickSight
  • Athena / Redshift Spectrum + QuickSight
  • Jupyter notebook on EC2 / EMR

セッション4：AWS Big Dataサービスとセキュリティ

• 今日話さないこと
  • BigDataを応用したセキュリティ
  • BigDataサービスの詳細なセキュリティ
• ビッグデータを取り巻く現状―個人情報を中心に―
  • 改正個人情報保護法 2017年5月30日に施行
    • 時代の変化
    • プライバシー
    • ビジネスの源泉としての個人情報
  • 保護法改正の主な目的（BigDataの観点から）
    • 匿名加工情報の合意不要な第三者提供
    • 定義を明確にする
    • 適切な取り扱いによるビッグデータとしての利用
  • 個人識別符号が含まれるもの（今回追加）
    • 「個人識別符号」の定義
      • バイオメトリクス
      • マイナンバー、運転免許証番号など
      • （クレジットカード、会員証の番号→識別番号ではない）
  • 「匿名加工情報」の定義
    • 措置を講じて特定の個人を識別することができないように個人情報を加工して得られる個人に関する情報
    • 当該個人情報を復元することができないようにしたもの
    • 当該個人情報に含まれる記述を一部削除
  • 利用者がやるべきこと
    • 「個人情報」の適正な管理と利用によるビジネスへの貢献
    • 「匿名加工情報」への適切な過去
    • 「匿名加工情報」の適正な利用によるビジネスへの貢献
    • プライバシーへの配慮を忘れない

• ビッグデータとAWS
  • こんなこと言われてませんか？
    • 個人情報だからAWSにはおけない
    • AWSを使った個人情報利用はリスクがある
  • オンプレミスで個人情報を管理する場合：
    • 保管する環境の耐久性、コストは？
    • アクセスに対する発見的なコントロール、自動化されたセキュリティの組み込みはあるか？
  • リスクはセキュリティだけのものではない
    • 単純な「リスクの有無」だけではない。リスクは可能性とインパクトで考えるもの。
    • 「消失」「漏えい」「改ざん」まで含めたリスクに対応する必要がある
  • AWSのセキュリティの考え方：責任共有モデル
    • AWSが管理するセキュリティ ＋ お客様が管理するセキュリティ → 求めるべきセキュリティレベル
  • AWSがお客様にもたらすのは、豊富な選択肢
  • お客様がAWS上でデータを管理する意義
    • 1)消失リスク
      • データへのアクセスが失われることはビジネスの中断につながる
      • →耐久性の高いストレージ
    • 2)漏洩、不正アクセス
      • 信用の失墜、第三者による悪用につながる
      • →適切なアクセスコントロール
    • 3)処理のワークロード
      • 処理の遅延、リアルタイム性の欠如などは、ビジネスの意義を損なう
      • →処理に見合った選択肢
    • 4)管理者による不正リスク
      • 論理的、物理的な分離の欠如によるセキュリティリスクの発生
      • →継続的な投資/統制に対する説明責任
  • イノベーションを推進するためのセキュリティガバナンス
    • 陳腐化したルールは組織のイノベーションを阻害する
    • 「ルール」を変える負荷は通常高いと考えらえが組織の目指す姿を踏まえて越えるべき壁である
• ビッグデータのセキュリティ
  • BigDataセキュリティ＝暗号化、アクセスコントロール、だと思っていませんか？
  • Cloud Adaption Framework（CAF)
    • Cloud Journeyを助けるAWSのフレームワーク
    • AWSが提唱するCloud Adaption Framework
  • CAFによるビッグデータセキュリティ
    • IAM → 認証認可
    • インフラセキュリティ → NWセキュリティ
    • 発見的コントロール → モニタリング/アラート
    • データ保護 → 暗号化
    • インシデントレスポンス → 証拠保全、対応の自動化
• まとめにかえて
  • 「データを守る」ためにAWSを活用しよう
  • 個人情報でなくともビッグデータでは高い価値がある
    • しっかり守れる機構としてのAWSを
  • セキュリティを理由にビッグデータ活用が進まないなら、それは大きな課題
    • ポリシーを見直していく努力を
  • 単に暗号化、匿名化ではビッグデータのセキュリティを守れない
    • 発見的なコントロール、インシデントレスポンス等の多様な観点での保護を
  • AWSでは多面的にデータを保護し、活用するためのサービス、支援を展開
    • トレーニングの機会などを通じて、活用とセキュリティのバランスを

セッション5：Big Data取り扱い方のクラウドとオンプレミスとの違い

• 「オンプレ」で「こんなことできません」
• 「クラウド」で「こんなことできました」
• オンプレだと大変なことがある
  • １ハードウェアの世代問題
  • ２サイジングの課題
  • ３バージョンアップの課題
  • ４本番規模でのテストしづらい問題
  • ５ストレージの課題（データは増え続ける）
• １ハードウェアの世代問題
  • オンプレの課題
    • まったく同じスペックのものは調達できない。Hadoopクラスタのノード設計時に困る。
    • →サーバーを使い続けることによる問題
  • クラウドで解決
    • Hadoopクラスタのノードは使い捨て
    • クラスタ単位で使い、終わったら消す
    • 古いものを使い続ける必要がない
• ２サイジングの課題
  • クラスタサイズを2倍にすると、ノード数もディスクも2倍に
  • MapReduceとHDFSが密結合なので仕方ない
  • オンプレの課題
    • 箱に入るサイズのジョブを用意
    • どうしてもすきま（無駄）ができる
  • クラウドで解決
    • それぞれのジョブにクラスタを立てる
    • 使い捨てこそがクラウドのメリット

• 3バージョンアップの課題
  • オンプレの課題
    • 本番クラスタをバージョンアップ
    • 唯一無二のクラスタをバージョンアップするから怖かった
  • クラウドで解決
    • バージョンアップも事前に試せる
• 4本番規模でテストしずらい問題
  • オンプレの課題
    • 「テストしたいから同規模のクラスタをサクッと用意 して」と言われても辛い
  • クラウドで解決
    • 新しいツールも試しやすい
    • 使い捨てこそがクラウドの メリット(2回目)
• ５ストレージの課題
  • オンプレの課題
    • データは増え続ける
    • 「数百TBや数PBのストレージが欲しい」
    • 「と言うか理想は容量無限のストレージが欲しい」
    • 数PBのバックアップどうする？？
  • クラウドで解決
    • S3
      • 耐久性99.999999999%（イレブン・ナイン）
      • 容量無制限（1ファイルあたり最大5テラバイト）
      • Hadoopから接続しやすい
      • クロスリージョンレプリケーションでバックアップも可
      • 低コスト
• まとめ
  • クラウドしさとは
    • リソースをすぐに使えて不要になったら捨てる
    • 容量無制限のストレージ
    • バージョンアップの気軽さ、本番スケールのテストのしやすさ
    • ジャストサイズでプロビジョニング
    • 運用負荷軽減で本来やりたいことに注力
    • データローカリティは下がる
    • HDFSはテンポラリ
    • NameNodeのメタデータ操作にびびらない。NameNodeも作って壊す
    • 役立つサービス：Athena、Kinesis、Redshift、SnowBall、QuickSight
  • クラウドならではのベスト・プラクティス
    • なるべくマネージド・サービスを使って運用負荷軽減
    • できるだけ一時クラスタを使う
    • スポットインスタンス、「スポットフリート」
    • 新しいインスタンスに移行してパフォーマンスを活用
    • 最適なサイジングのためのモニタリング
• トレーニングの紹介
  • AWS トレーニング | Big Data on AWS

まとめ

「ビッグデータパイプライン」というキーワードは、これまで耳にしたことがあったものの、詳細についてはよく知りませんでした。

AWSでは現時点で（プレビュー段階のものも含めると）100近くのサービスが提供されており、 ビッグデータ分野だけでも、相当な数になります。 それらのサービスの位置付けを理解する上で「ビッグデータパイプライン」という考え方は、非常に有用だと感じました。