■概要
- 全体のアーキテクチャを設計するための方法論、適切な 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に任せてアプリケーションの開発に集中しましょう
- Right Tools for the Job
- ストリームデータ
- 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 から引用させて頂きました