AWS Solution Days 2017 メモ

~AWS DB Day~

#基調講演 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 できないなど