AWS Solution Days 2017 メモ

# AWS Solution Days 2017 メモ
## ~AWS DB Day~
![main_solutionday2017_DB.jpg](https://qiita-image-store.s3.amazonaws.com/0/163591/68622be0-29ef-6bc2-813a-0d178d219c98.jpeg)


#基調講演 Opening
## 10:00-11:40

### 講談者
>大久保　順
（アマゾン ウェブ サービス ジャパン株式会社　事業開発本部　プラットフォーム事業開発部　部長)

### メモ
・DB移行
>	RDBMSのクラウド移行
	オープンソースDBの活用
	NoSQLの活用
		
・データレイク


・ビックデータ活用
・AI / 機械学習
> ４レイヤーから構成されるAWSの機械学習サービス
> いずれにせよ鍵となるのがデータレイク、どのようにデータを集めるのか

ハッシュタグは`#AWSDBDay`

-----------

#Aurora for PostgreSql compatibility を評価して

### 概要
>SRA OSS は、長らく PostgreSQL の開発にもかかわり、サポートサービス等を中心にビジネスを行っています。今回、現在 AWS でプレビュー中の「Amazon Aurora for PostgreSQL Compatibility」を一足早く評価させていただきましたので、長く PostgreSQL にかかわっている企業の立場から、評価結果をご紹介します。

### 講談者
>石井　達夫 氏
(SRA OSS Inc.　日本支社　取締役支社長)

### メモ
・PostgreSQL 20年間の成長
> 規模は７倍
> 本格的なRDBMS
> 高性能化
> 高可用性
>　 レプリケーション
> 多機能化
> 　全文検索・JSON対応


Oracleからの移行先として注目されている
複雑なクエリやJOINも問題なく実行できる

・Auroraとの比較
> Read性能を向上させる技術
> 　スケールアウト
> 　パラレルクエリ

・Write性能の向上は難しい
> 　と思われていたが、Auroraなら向上する？？

#Kinesis Firehoseによるデータストリーム

### 概要
>ミッションクリティカルな領域での AWS 、Amazon RDS 利用事例が増えるとともに、クラウドへの移行を機に商用からオープンソースへ、AWS Database Migration Service を乗せ換える動きがあります。先行する各社が、どのように DB 移行に取り組んできたか、コンサルティングで関
わってきた経験を元に、事例を交えつつ、その成功のポイントを説明します。
### 講談者
>川上　明久 氏
(株式会社アクアシステムズ　執行役員技術部長)


#シェアードナッシング型 Web アプリケーションと Kinesis Firehose による大規模データストリーム処理

### 概要
>AWS の重要な特徴に、サービスの展開に合わせた拡張性を実現するための柔軟なスケールアウトが挙げられます。オンラインゲームのバックエンドデータベースは、ゲーム中リアルタイムに参照・更新されるため、定常状態における同時接続数が数万〜数十万にまで登るものであり、高いスケーラビリティが要求されます。本セッションでは、ゲームアプリを事例として、AWS 上に構築したシェアードナッシング型 Web アプリケーションと、Amazon Kinesis Firehose を組み合わせることにより、数十分間で約１テラバイトものデータストリームを処理するスケールアウト・アーキテクチャを紹介します。
### 講談者
>倉林　修一 氏
（株式会社Cygames　技術顧問 兼 サイゲームスリサーチ所長）

### メモ

数十万〜数百万の同時接続数、しかも24h365d

シェアードナッシング型のWebアプリケーション
Amazon kinesis firehose, amazon SQSを組み合わせることで
数十分間で役１テラバイトものデータストリームを処理するスケールアウト・アーキテクチャーを紹介

サービスを急激にスケールアウトするノウハウ

* twitter
40000/sec peek

* mobile game
100,000/sec always
200,000/sec peek

極めて高い頻度でのDB書き込み


分散システム分析の諸理論（CAP定理）

QRコードではなく、TV放送コンテンツそのものを認識してチェックイン
日本全国の視聴者が、土曜日２４時に一斉にアクセスする。3000 req / sec 動画...
5秒間の動画　合計400時間

一貫性　Consistency
* 可用性　Availability
* 分断性　Partition-tolerance

--------------

#クラウド上のデータ活用デザインパターン
## 13:00-13:45

### 概要
>クラウドとオンプレミスはさまざまな点で違いがあるためクラウド上で新たに構築されるデータ活用基盤も従来のオンプレミスのそれとは大きく異なります。本セッションでは，クラウド上のデータ活用基盤とオンプレミスの違いについていくつかの例をあげて説明し、その上で，クラウド上で構築されるデータ活用基盤についてデザインパターンとしてご紹介させていただきます。

### 講談者
>志村　誠
(アマゾン ウェブ サービス ジャパン　株式会社　ソリューションアーキテクト)

### メモ

・Hadoopログ解析
・データ分析etc....


・流れ、目的
> ビジネスの問題を把握
> 新しい知見
> 効果的な施作を実行・解析

> １貯める・２可視化・３サイエンス

> If your company isnt good at analytice 
> its not ready for ai
> @ harverd business review

> ツール
> 　加工整形
> 　可視化ー基礎集計　SQL・パイプライン処理・BIツール
> 　Deep Learningフレームワーク・Hadoopクラスタ・notebook
> ツールやモデルによって必要なリソースも異なる

> 試行錯誤
> 　データの量・中身に応じた継続的な対応
>　 機械学習モデルの構築・改善サイクル
> 　ビジネスモデルの状況変化に伴う、指標の定期的な見直し

・オンプレでありがちな問題
> 「柔軟性」がないため、試行錯誤のサイクルが回しにくい
> 
>  　* 時間の柔軟性
>  　　ハードの減価償却サイクルが長く、
>　  　技術が進歩するスピードやデータ量の増加に追従できない。
>  　　　これって社内のリソースに関しても同様なことが言える。。。。
>  　
> 　* アーキテクチャの柔軟性
> 　　既存のアーキテクチャに投資してしまっており、
> 　　そこに付け加える形での買う長を前提に考えがち
>
>　* リソースの柔軟性
>　　　需要に合わせてリソースを変動させることができない。
>　　　CPUだけ買い足すってできなよね？
>
> 　* ワークロードの柔軟性
> 　　　ワークロードにより、異なるリソースを適宜用意するのが難しい
 

・AWS上でのデータ活用事例
> Agility 
> Broadest and Deepest Capabilities
> Get to insights faster
> Scalability
> Low cost
> DAta migrations made easy

・データレイク
> S3によるデータレイク、S3を起点としたデータマイニング・活用をしていく
> データストアとデータ処理の分離
> 用途に応じた適切な処理方法の選択

・Amazon Kinesis
> strams
>　ストリームデータを処理・分析するためのデータを格納
>firehose
>　ストリームデータをS3にetc...

・EMR
> S3上のデータを直接読んで、、、戻す
> 運用コストでHadoopを使用

・Athena
> フルマネージドで運用コストがかからない
> S3に直接SQLを投げることができる。

・Redshift
> エンタープライスデータウェアハウスサービス
> 簡単
> MPP　Massibely Parallel Prossesing
> 2PBまでいける
> Redshift Spectrum

・P2インスタンス（EC2）＋　Deep Learning AMI
> 最大16個のGPUを使うことでDeep learningのモデル構築にかかる時間を大幅に短縮可能
> 主要フレームワークがすべてプリインストールされた状態でインスタンスが立ち上がる

### AWSにおけるデータ活用のデザインパターン
・パイプライン
> Redshift AthenaでS3上のさまざまなデータを可視化
> 既存のデータウェアハウス・Bi環境を活用
> 必要なデータはすぐにアクセスでき、簡単に可視化ができる環境
> Athenaで生データに直接アクセスすることも可能
> 新規のサービスの仮モニタリングとかに向いてる。クイック。
> 
> ログ収集JS
> APサーバ
> fluentd
> S3

・データサイエンスパイプラインパターン
> Kinesis経由でしゅとくした　ストリームデータに前処理と機械学習モデルを適応
> モデルの適用結果をすぐにAPI経由で利用できるようにする。
> S3に貯めたデータを　使って、定期的にモデルを更新

・複数レイヤの分析
・マルチクラスタパターン
> ワークロードに応じて、最適なスペックのクラスタを使用
> 各コンピュートリソースが明確に分かれており、互いに影響を与えることなく、並列で処理を実行可能
> 用途に応じてクラスタを分けて立てる。終わったら捨てる。

・ホットデータパターン
> 蓄積したデータについて、直近のホットデータとコールドでーたでアクセスの方法を変える
> コストをさげつつ、　全データへのアクセシビリティを確保
> ホットデータはRedshift・コールドデータはPresto

・ラムダアーキテクチャパターン
> 取得したデータについて、スピードレイヤーとバッチレイヤーの２系統で処理を行う。
> 分けるのが重要
> サービスの状態をモニタリング対応しつつ、貯めたデータをじっくり分析

・分析の柔軟性
・マルチノードパターン
> パラメタやデータを変えて、複数のモデルを並列で走らせる
> AWS　Batchで複数のECSコンテナを立ち上げ、。。。

・マルチツールパターン
> Zeppelin　Jupyter　Rstudioなどで必要なデータを深く分析
> モデル作成に必要なデータは生データまで遡ってとれるように
> Netflixもこの仕組み

・スタンプパターン
> あらかじめ自分たちのモデル構築に必要な環境を、AMIのシャトルズ連絡もうたちで構築しておくことで、同じ環境を簡単に環境構築可能
> Deep learning ami をベース ＋　独自のパッケージを追加


・品質の担保
・ABテストパターン
> 複数の機械学習モデルを平行稼働させ、パフォーマンスおw見ながら採用するモデルおw決める
> 各モデルへのトラフィック配分の変更や切り戻しも容易
> 90% ok 10% ngで切り分ける

・データマネジメントパターン
> データだけでなく、めたでーたも合わせて管理
> 生データも加工済みデータもS3に置いて再利用性を保つ
>カタログサーチパターンなんてのもある


### AWS上のデータ活用事例
・すかいらーく
> お客様に応じた「パーソナライズ化」
> CMを含むプロモーションに対し、ABテスト
> POSでーたの項目を戦略的に追加し、分析の軸を増やす
> お客様の属性に合わせtえ配信

・日経新聞のAI記者
> 決算サマリーの自動生成
> 速報や定型業務をAIに任せて、より付加価値の高い業務に集中
> 編集現場では仕事を取られるという意識はなく、サポートとしての　期待が大きい。




------------

#ETL をサーバーレスで実現する新サービス AWS Glue のご紹介
## 14:00-14:45

### 概要
>AWS では、データレイクの Amazon S3、DWH サービスである Amazon Redshift、Hadoop/Spark 基盤である Amazon Elastic MapReduce、BI サービスである Amazon QuickSight 等の多様なサービスでビッグデータ分析のための環境をご用意しております。このファミリーに新しく加わるのが AWS Glue で、各種データソース (DB) からデータを取り出し (Extract)、変形し (Transform)、別のデータソースに投入する (Load) を行う ETL 処理をサーバーレスで実現する新サービス (現在 preview 中) です。このセッションでは AWS Glue の概要、特長やその機能についてご説明します。

### 講談者
>下佐粉 昭
(アマゾン ウェブ サービス ジャパン　株式会社　ソリューションアーキテクト)

### メモ

### はじめに
> AWS Glueは現在Preview中のサービスです。

### データレイクを中心とした大規模データ分析基盤
・大規模データ分析 on クラウド
> データはデータレイクに集め、多様な分析につなげる
> 分析はスケールアウト可能なインフラの上で実現
> 収集
> データレイク（保存）
> ↑API⇩
> 分析　（スケールアウト可能な技術）
> 可視化

・データレイク
> 多様なデータおw一眼的に保存
> データを失わない
> サイズ制限からの解放 ←クラウドの大きな価値
> 決められた方法（API）ですぐにアクセスできる
> API呼び出しによってセンサーデータ、RDBMS、テキストファイル、非構造化ファイルを連携する

・AWSによるデータレイクの実現
> S3
> 上限なし：サイジング不要
> 高い耐久性：99.99999999%
> 安価
> APIアクセス
> S3に全てのデータを集約し、そこからデータ活用を行うのがAWSのスタンダード

・スケールアウトが鍵
> スケールアップもスケールアウトもクラウドでは容易
> しかし、スケールアップには限界がある
> スケールアウト可能なテクノロジー　＝　規模の増加に耐えうる設計

・スケールアウト　≠　高価
> クラウドではスケールアウトがコスト・時間お両面で効率的
> 必要な時に必要なだけノードを追加できrう
> **ノードを増やしても利用時間が短くなればコストは同じ！**

・スケールアウト可能な分析サービス
> Amazon Redshift
> 　マネージドDWH(RDB)
> 　SQL標準
> 　ユーザ操作でスケールアウト
> Amazon EMR
> 　マネージドHadoop/Spark環境
> 　Hadoop / Spark
> 　ユーザ操作でスケールアウト
> Amazon Athena
> 　マネージドクエリ環境
> 　SQL標準
> 　自動でスケールアウト

* 全体図
> データをデータレイクに集め、多彩な分析につなげる
> 分析はスケールアウト可能なインフラの上で実現
> データソースからの収集やプリプロセス（ETL）は？

### クラウド上のETL　AWS　Glue

・構築の背景
>データをたくさん貯めていくと、前捌きのニーズが大きくなってきた
>巨大データへのETL処理を「スケールアウト」で対応、「サーバレス」で提供

・スケールアウト処理を実現
> ベース技術にSparkを採用
> 大規模データに対し、自動的にスケールアウト

・サーバレスのジョブ実行
> プロビジョン・コンフィグ・パッチなどが不要に
> 処理にかかったリソースのみへの支払い

・ビックデータ処理もサーバレスで実現可能に
>収集とプリプロセスをGlueで
>データレイクはS3
>分析はAthena
>可視化はQuickSight

・EMRとGlue
> EMR
> 　汎用Hadoop/Spark環境
> 　スケールアウトはユーザ設計で
> 　Hadoopエコシステム上の多様なアプリケーション
> Glue
> 　ETL処理に特化（Sparkベース）
> 　スケールアウトは自動で
> 　PySparkをカスタマイズしてね ← python

・Glueの全体像
> データソースをクロールし、メタデータ（データの特徴）を取得
> メタデータはデータカタログで管理
> メタデータを元にジョブを作成（PySpark）
> ジョブはサーバアレスな環境で実行される

・Glueの構成要素
>データカタログ
>ジョブオーサリング
>オーケストレーション

・データカタログ（Data catalog）
> 表のメタデータをHiveメタストアで管理
> 
> メタデータ
> 　列・プロパr日
> 　データロケーション（URI)
> 　接続情報
> 　更新情報
> 
>クローラーによる自動チェックと登録

・クローラーによるデータカタログの自動更新
> クローラーが自動的にスキーマを推測
> 　ファイルタイプを識別し、どのような内容が含まれているのかを分類し、スキーマとして抽出
>クローラーをスケジュールじっこうすることで新しいデータやスキーマの変更を発見
>クローラーを使わず手動での登録も可能
>ログはCloud Watch

・クロールする範囲（接続）
> RDB
> 　接続情報を定義
> 　ホスト名、ID、パスワード＋セキュリティグループでアクセスを制限
> S3
> 　S3バケットを指定
> 　IAMでアクセスを制限

・対応データソース
> Amazon RDS
> Amazon Redshift
> EC2上のRDBにも
> S3

・ジョブオーサリング
> データソースとターゲットを指定してETLジョブを定義
> GUIで定義を決めるとPySparkのコードが出力される
> 　基本的な処理のみであればコードは書かなくてOK
>人間が読め、編集しやすいコードを出力
>PySparkのライブララリを活用して高度なカスタマイズも可能

・開発者に優しいETLスクリプト
> 生成されたコードはETL図に連動したアノテーションが人間が読める形で記載されている
> 任意の開発環境で開発可能
> 　AWSにはAWS CodeStar等の開発環境なども
> 変換処理をPySparkのextentionとして用意済み
> 多彩な出力フォーマットに対応：プログラミング不要
> ライブラリ豊富

・オーケストレーション＆リソース管理
・ジョブの定義と実行
> 作成したETLスクリポトをよも混んで実行
> 　IAMロールで権限を設定
> ジョブの実行開始方法
> 　APIコール・トリガー
> リトライ回数の制限、パラメータを渡すことも可能
> 実行ログはCloud Watchに


##感想

>**ビックデータ解析はサーバレスでいける時代になった！最高！**
>収集、プリプロセス： AWS Glue
>データレイク：S3
>分析：Amazon Athena
>可視化： Quick Site

>補足
>４ノードで８時間 掛かった時と
>１６ノードで２時間掛かった時の
> 支払い料金は同じ。なるほど

------------

#オンプレミスから RDS for Oracle / SQL Server への Lift & Shift
## 15:00-15:45

### 概要
>オンプレミスで動かしている Oracle や SQL Server を AWS クラウドへ持ってくる際、ファーストチョイスとなるのが Amazon RDS です。本セッションでは、オンプレミス環境から　Amazon RDS for Oracle 　/　SQL Server　への移行を検討する際に知っておくべき基本について解説します。

### 講談者
>北川　剛
(アマゾン ウェブ サービス ジャパン株式会社　事業開発マネージャー)

### メモ

・データグラビティ/ クラウドファースト
> 企業内システムのクラウド上の以降
> 企業活動で生まれるデータのクラウド上への集約

・データベース運用上の課題
> 導入・保守コストが高い
> 社内担当者のスキル
> 運用管理の手間
> 統合ができていない

・これからのデータベースの課題
> データ容量増大
> 　コネクテッドデバイスが指数関数的に増大していくだろう
> 他システムとの連携
> 　社内で利用されている様々なシステムのデータを連携ささせて利用する
> データ再利用
> 　AIや機械学習の活用において、ビジネスの中で生成された各種データは極めて重要

**今、このタイミングでデータベースをクラウドに移行しなければ・・・**

**lift and shift**

・クラウド化を検討するキッカケ
> サポート切れ
> システムの更新
> 拡張性の確保
> コスト削減

・Homogeneous
> 同じDBプラットフォームを使用する

・Heterogeneous
> コスト削減のため、別のDBプラットフォームを利用する。

・On EC2 or RDS
> 従来の運用・管理手法が利用できるEC2上にDBを構成する
> クラウドのメリットをさらに享受できるサービスとしてつかう

・Oracle Data Pump
> ダンプファイルを送ってデータ移行を行う

・Data Migration Services(DMS)
> オンラインでの継続的なレプリケーションに対応

------------

#第 2 回 Aurora 事例祭り
## 16:00-17:30

### 概要
>本年 3 月に大盛況で開催された「Aurora 事例祭り」の第 2 回です。Aurora を実際に活用いただいているお客様が登壇し、実際に携わった担当の皆様に本音で熱く語っていただきます。また、SA 星野が実際に苦労した点など登壇者の皆様からリアルな現場の声を引き出し、また会場の皆様との Q&A も予定しています。
Twitter ハッシュタグ #AuroraMatsuri

### 講談者
>* 星野　豊
(アマゾン ウェブ サービス ジャパン株式会社　ソリューションアーキテクト)
* マガシーク株式会社
* 株式会社サイバーエージェント・クラウドファンディング
* 株式会社CyberZ
* ファンプレックス株式会社

### メモ

### マガシーク株式会社
・移行理由
> **事業要員**
>　 年２回のセールがアクセスピーク
>　 セール期はアプリサーバをクラウドでスケール
>　 システム全体のスケーラビリティを確保したい
>　アプリケーションだけではなく、DBサーバも気軽に拡張したいという要件が出てきた。
> **システム要員**
> 　ハード・ソフトの老朽化
> 　システムのレガシー化
> 　　スピード感出さないと変えられない
> **外部要因**
> 　2015/10月　東京リージョンでAuroraが使用可能になった

・ゴール設定
> RDBはOracle RACからAmazon Aurora
> システム全体をオンプレ環境からクラウド環境

・接続アーキテクチャ
> PHP基盤にMariaDB Connector / Javaドライバーのようなものをどうつける？
> 
> **要件**
> 　Auroraのフェールオーバーに即時対応
> 　レプリカのスケール管理が容易
> 　利用システムごとにレプリカノードを分別
> 　read-write splitの実現
> 　　レプリケーソンをうまく活用したい
> **検討案**
> 　DBロードバランサの導入>
> 　Cluster EndpointとReader Endpointの活用
>　 アプリケーション独自基盤で実装


・DBロードバランサの導入>
> マスタとレプリカの振り分けが意図した挙動にならなかった。
> 自分たちの検証時間が足りなかった？？
> 手間かかった
> 不採用

・Cluster EndpointとReader Endpointの活用
> フェールオーバー時３０秒程度の書き込み不能時間が発生
> ECサイトでは止まっちゃダメだろう
> 不採用

・アプリケーション独自基盤で実装
> MariaDB Connecor / java ドライバアーキテクチャを参考
> 独自基盤で開発
> 要件通りの制御やオプションを実現
> 採用

・DMSによるデータ移行
・トラブル事例
> DELETE処理やSELECT FOR UPDATE処理におけるロック範囲が不適切で強豪がハッセい
> MySQL独自のロック機構

・最後に
> ECサイト全体のパフォーマンスが向上
> 　100 - 200msの向上
> バッチ処理お性能が大幅に向上
> 　全体的に役３倍のパフォーマンス向上
> 
> AWSのサービスを組み合わせることで
> 検証やリハーサルが簡単に！
> 別のワークに集中することができるようになった
> アプリケーション移行・問題解決・タスクマネジメント
> 
> これからやりたいこと　**AWSならできるよね**
> 
> 　サーバレス
> 　DevOps
> 　マイクロサービス
> 　アプリケーション改善
> 　データ分析
> 　Iot
> 　人工知能

#### 疑問点
> read replica と master instance との同期のタイミングとかはどうなってる？
> reader のレプリカラグはほぼ０らしい

### 株式会社サイバーエージェント・クラウドファンディング　Makuake

>障害時に無停止でフェールオーバーができるわけではない
>無停止でバージョンアップができるわけではない

>データベースも定期的に健康診断が必要

>**営業もエンジニアも分析クエリ・グラフ・数値を見る文化になっている**
>**データドリブンな組織文化を築けたのもAuroraのおかげ**

>資料は明日公開

### 株式会社CyberZ

・ビジネス上の課題
> DBへの書き込みが激しい
> Fusion-IOを容量ギリギリまで利用
> システムコストが把握しにくい


### ファンプレックス株式会社

>技術的負債の返済
>耐障害性の向上
>コスパの最適化
>運用の最適化

・移行方法
>mysqldump
>XtraBackUp
>DMS

・mysqldump
> MySQLの機能だけで済む
> BUlk Data loadingでデータ移行の高速化
>
> mysqlimportの際にやりすぎてAuroraがハングアップした
> 　1000万件を９本並列を流し込んだ
> 　aurora（db.r3.8xlarge)が耐えられなかった
>
>サービス停止を伴う
>　３億件規模で１３時間所要


・XtraBackup
> XtraBackupを取得
> S3に転送
> Aurora構築
>
>mysqldumpと比べてBackupRestoreが高速
>Aurora構築が簡単
>DBサーバにXtraBackupをインストールする必要があった
>
>サービス停止を伴う
>　６億件規模で５時間くらい所要
>いくつか制約あり
>　プロシージャは対応しないなど

・DMS
> 東京リージョンで使えるようになったのが去年の３月
> snapshot取得
> snapshotで構築
> MySQL 5.1から5.5へVerUp
> Aurora構築
> Replication Instance構築
> DMSタスクでデータ移行
> Replication設定
> Replication設定

> 以降当日の作業が簡単
> 　Behindが無いことを確認して
> 　AuroraへEndpointを変更するだけ
> DMSの制約あり
> 　Drop Table, Rename Table できないなど