クラスメソッド データインテグレーション部は、AWSをベースとしたデータ分析基盤構築案件を多数手掛けています。 本セッションでは、その経験上得られたデータ分析基盤をAWSサービスで構成する際のノウハウをお伝えします。

1. 実案件で見る データ分析用AWS基盤の構築方法
Developers.IO 2017
2017/7/1
甲木 洋介
1

2. 2自己紹介
甲木 洋介(id: yokatsuki)
• クラスメソッド株式会社 データインテグレーション(DI)部
• AWS基盤の上でDWH構築、ETL処理設計実装
• 好きなサービスはAmazon Redshift

3. 3本セッションでお伝えする内容
“DI部の経験”
• データ分析基盤の色々
• 得たノウハウ
• 基盤構築後発生した問題とその解決
• 今後導入したいAWSサービス

4. 4
データ分析基盤の色々

5. 5ログデータ分析
基幹システムのデータをRedshiftに格納しBI参照

6. 6ログデータ分析
S3のデータをEMRで集計し、Redshiftに格納

7. 7ログデータ分析
Auroraのデータを直接集計し、別システムに提供

8. 8既存DWHリプレース
保守期限切れのタイミングでクラウド化
Nettezza
Teradata
SQL Server など
PoC(後述)を経て移行する事が多い

9. 9PoC(Proof of Concept: 概念実証)
既存BIシステムに枝分かれする形で環境構築、検証

10. 10
得たノウハウ

11. 11プロジェクトの傾向とポイント
開発3ヶ月、調整3ヶ月位が多い
要件は確定しないと覚悟して
「まずは作って動かしてみる」が大事
調整期間を長く設ける
少数で始める
船頭多くして船沈む
予算は柔軟性を持たせる
スタートに成功すると相乗りが増え、基盤への負担が増える

12. 12「データレイク」構想
まずはS3に貯めておく
従来はオンプレマシンのストレージ容量制限で過去データを
捨てざるを得なかった
「13ヶ月保存ルール」はその名残
今は従量課金で保存可能
より安いモデルもある
AWSのサービスはS3をコアにしている
今のところのお勧めは
<バケット>/<テーブル名>/<YYYY>/<MM>/
<テーブル名><YYYY><MM><DD>.tsv

13. 13RDB or EMR
データ量で判断する
1台に収まらないデータ
「ひたすら力ずく」な処理はEMR
機械が吐くログデータの集計など
リアルタイム性で判断する
応答時間の速さが必要ならRDB優先
関係者のスキルセットで判断する
Hadoopエンジニアが多いかRDBエンジニアが多いか

14. 14Redshift or Aurora
同時アクセス数で判断する
Redshiftは並列実行が得意ではない
「1つ1つのクエリをいかに早く終わらせるか」という志向
クエリの特性で判断する
集計ではなく1行検索なら、インデックスを持つ方が有利
可用性要件で判断する
ダウンダイムが全く許容できなければAurora
(データ分析基盤で24x365が必要かどうかは要検討)

15. 15ETL or ELT
現在のところは「ELT」
T(Translation)よりも先にターゲットDWHへL(Load)
RDBの場合、CTAS(CREATE TABLE AS SELECT)等を
駆使してデータ集計、マート作成
今後は「ETL」へ回帰の兆し
DWHへのTranslation負担増を外出しにする必要が増加
Hadoop基盤がここで伸びる可能性

16. 16ETL(ELT)処理
ETL(ELT)処理の決定版はまだない
高機能な製品は高価格(クラウドと比較してより際立つ)
現在までに弊社で主に扱った技術、製品
・シェルスクリプト
・Javaアプリケーション
・Pythonスクリプト
・Talend Open Studio
・Alteryx Designer / Server
AWS Glue欲しい!!!

17. 17
基盤構築後発生した問題とその解決

18. 18主には「性能問題」
「Redshiftで検索が遅い」
Redshiftクラスタサイズを”データ量”基準で決めた
処理性能(CPU)不足、ネットワークI/O帯域不足が発生
同時接続多過ぎ問題
「EMRの処理性能が出ない」
S3に格納したデータ量とEMRインスタンスの
バランスが悪い
「物理で殴る」解決が結果として一番楽

19. 19クラウド流、性能改善の考え方
チューニング
現在の構成でひたすらチューニング
時間
目標性能
現在性能
目標確認
目標確認
目標達成、継続運用
性能
構成を縮小しつつ
費用と性能のバランス調整
構成を変更する
ノード追加、スケールアップ
お薦めの方法
従来の方法
結果が出るまで時間が掛かる
目標達成の保証もない
追加費用は発生するが
早く性能向上が確認できる

20. 20チューニングより構成変更
従来型のチューニング作業は掛けた時間と効果が比例しない
構成変更は掛けた金額に比例して性能を上げることができる
先にスケールアップ/アウトで性能を上げておけば、
その後でチューニングの機会を増やすことができる
 60分のクエリ1回調査
vs 5分のクエリ12回調査

21. 21Redshift固有のチューニング
データ圧縮
I/Oごとのデータを高密度化
ソートキーの非圧縮
圧縮すると、不要なブロックも読み込んでしまう
JOINを考慮した分散キーの設定
結合キーが同じデータが同じノードに配置されるように
(ノード間の再分散を発生させない)
小さいデータは全ノードにコピー(ALL)する手もある

22. 22
今後導入したいAWSサービス

23. 23Amazon Athena
S3格納のファイルをテーブルとして直接SQLクエリ
「試しにテーブル問い合わせ」が可能
2017.6.23 東京リージョンでも提供開始

24. 24Redshift Spectrum
S3格納のファイルをRedshiftのテーブルとして定義
ETL処理を省く
クラスタ間のマルチマスタも可能

25. 25AWS Glue
フルマネージドETLサービス
データ構造の管理 / 連携コードの生成 / スケジュール管理

26. 26まとめ
データ分析基盤構築
「どの要件でも使える」構成はない
各AWSサービスの特徴を理解し使い分ける
今後、ETL処理もAWSで提供できるよう事を期待
最適な構成は変化する
新機能を「どう役に立てられるか」をイメージ
“定番”に固執し過ぎない

27. 27今後もDevelopers.IOで情報提供