■概要

全体のアーキテクチャを設計するための方法論、適切な AWS サービスを選択するためのポイント、典型的なユースケースやアーキテクチャパターンの実装例をステップバイステップで一挙紹介

■登壇者

内海英一郎さん（アマゾンウェブサービスジャパン株式会社　技術本部ストラテジックソリューション部ソリューションアーキテクト）

■ビックデータの事例

AdRoll: 600億/1日
FINRA: 5PB 750億イベント/1日
Hearst: 250以上のサイトからクリックストリーム 100GB/1日

■悩ましいところ

テクノロジーや方法論が複雑・高度化

■アーキテクチャ全体のモデリング

最も抽象的な概念から始める
問題領域
- データの断片 => 価値を持った情報に変換すること
ステップは5つ
- データ収集のステージ
  - データソースへのインタフェースを提供
- 前処理
  - 収集したデータを保存ように変換・登録
- データを保存するステージ
  - 繰り返し利用されるデータを蓄積・保持
- 後処理
  - 提供用に変換・登録
- データ利用を提供するステージ
収集の特性
- ストリーム
  - ペイロード小さい
  - 発生件数多い
- ファイル
  - ペイロード大きい
  - 発生件数少ない
前処理の特性
- リアルタム処理
  - レイテンシ重視
- バッチ処理
  - スループット重視
データ保存の特性
- 関連データベース
  - ハードスキーマ
  - アクセスパターンに制限ない
  - スケールに
- NoSQL
  - ソフトスキーマ
  - 捜査限定t系
  - スケール
- サーチエンジン
  - ソフトスキーマ
- データウェアハウス
  - ハード
  - 大容量なkensakuni最適化
- ストリームスキーう
  - スキーマフリー
  - 到着順に一定時間のウィンドウを保持
- データレイク
  - スキーマフリー
  - 後から自由に処理
後処理の特性
- 機械学習
  - 保存データへアルゴリズムを適用
  - 予測など
- クエリ
  - 抽出して並び替え
可視化
- 可視化
  - 人
- API
  - コンピュータ向け

■AWSサービスの選択の着眼点

指針
- Right Tools for the Job
  - やりたいことに最適化
  - 機能的特性と性能的特性の両面から最適なサービスを見極める
- Managed Service First
  - インフラの運用をAWSに任せてアプリケーションの開発に集中しましょう
ストリームデータ
- Kinesis Streams, Kinesis Firehose
ファイル
- S3, AWS Import/Export Snowboll
リアルタイム
- Lambda, EMR
- Firehose(そのままロードしたいとき)
バッチ処理
- EMR, Data Pipeline(複数ジョブの制御)
関連データベース
- RDS
NoSQL
- DynamoDB, Elasticserch Service(検索だけでなく集計なども)
サーチエンジン
- CloudSearch Elasticserch
データウェアハウス
- Redshift
ストリームデータ
- Kinesis Streams(1日デフォ、最大7日I)
データレイク
- S3
機械学習
- Machine Learning, EMR
問い合わせ
- EMR(Hive, Presto), QuickSight(Spice)
※Tips
- ストレージとコンピュートの分離: エンジン交換可能
- gyaku ni
  Redshiftなどは柔軟性を犠牲にしてレイテンシーをゆうせん
可視化
EMR(Hue, zeperlnA1, Elasticserch(Kinaba)
QuicSight
API
- API Gateway, Lambda

■典型的なユースケースの実装方法

ユースケース1: リアルタイムモニタリング
- 要件
  - 数千のセンサー、毎秒、アップロードJSON
  - 特異値だけでもみ
  - ダッシュボード
  - 時系列
- どうする？
  - 収集: リアルタイム
    - Kinesis Streams センサーからSDKで直接
    - Lambda関連付けで前処理、特異値検出、Firehoseに送信、Elasticserchにロード
  - 保存: JSOIN => ソフトスキーマ
  - 照会:
    - Elasticserch
  - ダッシュボード => 可視化
    - Elasticserch
ユースケース2: ログアナリティクス
- 要件
  - 日次で大容量ファイル
  - 数百TBのデータ
  - 分析はログ範囲のみ
  - アドホックに検索したい
- どうする？
  - 収集: ファイル
    - S3
  - 前処理: バッチ
    - Hive (Hive Activityで起動)
    - ORC形式に変換してHiveのテーブルにロード(S3)
  - 保存: データレイク
    - S3
  - 問い合わせ: EMR
    - HiveQL
  - 照会: EMR
    - Hueでクエリしスプレッドシート、グラフ
ユースケース3: ラムダアーキテクチャ
- 要件
  - アクセスログ常時
  - リアルタイムは精度低くても良い
  - 日次で高い制度バッチ
  - セグメントを
- どうする？
  - 収集: ストリーム
    - Kinesis Streams(Kinesis Aagent でlog tail), Lambdaでセグメント判定)
  - 前処理: リアル + バッチ
    - Hive のテーブル, HiveQLでDynamoDBにロード
  - 保存: NoSQL
    - DynamoDB(ユーザをハッシュで)
  - 問い合わせ
    - API Gateway, Lambdaで問い合わせて戻す

■まとめ

モデリング
- 5つのステージ
サービス選択の着岸点
- 適切なサービスを使う
- 一つのサービスも使いわける
ユースケース
- Firehoseの賢い使い方
- Hive - S3の上手な組み合わせ

※当日の生メモです(ほぼ校正していませんm(_ _)m
※登壇者の方の情報など一部 http://www.awssummit.tokyo/devcon/index.html から引用させて頂きました