2017/02/23　株式会社インサイトテクノロジー主催セミナーで講演した際の資料です。DBワークロードをAWSに移行する際にどのような選択肢やツール／サービスがあるかを解説しています。

1. 0
DBワークロードのAWS化と
データベースサービス関連最新情報
2017年2月23日
アマゾン ウェブ サービス ジャパン株式会社
事業開発本部 プラットフォーム事業開発部
部長 大久保 順

2. 1
本日の内容
• 既存RDBMSをアマゾン ウェブ サービス（AWS）上の
EC2（仮想マシン/セルフマネージド）、あるいは
RDS/Redshift（マネージド型DBサービス）に移行する
メリットやその手法
• AWSのマネージド型DBサービスについての最新情報

3. 2
アジェンダ
• RDB移行の背景
• セルフマネージ型 or マネージド型？
• 移行のための手法とツール
• AWSデータベースサービス最新情報
• まとめ

4. 3
RDB移行の背景

5. 4
クラウドへ移行する理由
• 理由はシステムによってそれぞれですが...
変更に時間
が掛かりす
ぎる
HWの保守
が大変
ソフトウェアの
ライセンスや保
守が高い
低い可用性をな
んとかしたい
インフラコ
ストが高い

6. 5
RDBにおける課題
• サイズアップへのタイムリーな対応
– 最初に設計した時より、利用アプリもサイズも増えていく
• 運用の負荷が大きい
– 日々のバックアップ、モニタリング、パッチ当て ...
• 高い可用性を求められる
– 障害を起こすと多くのシステムに影響がある

7. 6
RDBにおける課題をAWSクラウドで解決する
• サイズアップへのタイムリーな対応
⇒ いつでもスケールアップ・スケールアウトが出来る環境
• 運用の負荷が大きい
⇒ハードウェアやネットワークの保守対応が不要に
⇒マネージド・サービスによる運用負荷低減
• 高い可用性を求められる
⇒単体のハードウェア障害についてはAWSが実施
⇒マルチAZによる高い可用性
柔軟なインフラ
運用負荷低減
可用性向上

8. 7
事例：Retty様
• ビジネスの急激な拡大に伴い、VPSから
AWSへ移行
• 急激に増加するユーザーに対して短時間
で負荷分散を実現するため、「自前での
マシンセットアップは極力行わない、運
用コストをとにかく下げる」という方針
• 「特にマネージドサービスの選択が大き
いです。インフラ専任を置かずにひたす
らスケールをさせて、利用開始時から
ユーザー数は 10 倍以上になりましたが、
マネージドサービスをフルに利用する事
で安定してサービスを稼働させる事が出
来ています」
柔軟なインフラ 運用負荷低減

9. 8
• 2011年の大震災を機に事業運
営の安定化のインフラとして
AWSを選択
• ECシステムはRDS＋EC2に移
行（2011年）
• SAPシステムはDB on EC2に
移行（2012年）
事例：ケンコーコム様
https://aws.amazon.com/jp/solutions/case-studies/kenkocom/
可用性向上

10. 9
事例：Sogeti様（DRサイト）
• DRサイトとしてAWS
を活用
• オンプレミスの
ExadataからData
GuardでAWS上の
Oracle+EC2にレプリ
ケーション
https://aws.amazon.com/jp/solutions/case-studies/sogeti/
可用性向上

11. 10
課題：RDBは設計・導入だけでなく運用の負荷が高い
• 運用前（設計・導入）
– サイジング
– 導入作業
– 可用性設計
– バックアップ設計
• 運用開始後
– バックアップの自動実行
– リストア
– モニタリング
– サイズ調整（ディスク追加等）
– SQLチューニング
– 統計情報の更新
– フラグメンテーションの解消

12. 11
課題：RDBは設計・導入だけでなく運用の負荷が高い
• 運用前（設計・導入）
– サイジング
– 導入作業
– 可用性設計
– バックアップ設計
• 運用開始後
– バックアップの自動実行
– リストア
– モニタリング
– サイズ調整（ディスク追加等）
– SQLチューニング
– 統計情報の更新
– フラグメンテーションの解消
クラウド化で楽になる部分
変わらず残る部分

13. 12
クラウドへ移行することで解決できる部分とそうでない部分
サイジングと導入が大幅に軽減
• 数クリックでサーバ起動
• 後からCPUやメモリ、台数を調整可能
• IOPSを保証できるディスク環境
• 運用前（設計・導入）
– サーバサイジング
– ストレージサイジング
– 導入作業
– 可用性設計
– バックアップ設計
• 運用開始後
– バックアップ＆リストア
– パッチのテストと適用
– モニタリング
– サイズ調整（ディスク追加等）
– SQLチューニング
– 統計情報の更新
– フラグメンテーションの解消

14. 13
クラウドへ移行することで解決できる部分とそうでない部分
• 運用前（設計・導入）
– サーバサイジング
– ストレージサイジング
– 導入作業
– 可用性設計
– バックアップ設計
• 運用開始後
– バックアップ＆リストア
– パッチのテストと適用
– モニタリング
– サイズ調整（ディスク追加等）
– SQLチューニング
– 統計情報の更新
– フラグメンテーションの解消
可用性、バックアップ＆リストア、
モニタリングといった、基本要件が
設計済みのマネージドDBを利用することで
解消され、サイズ調整が極めて容易に

15. 14
自動
バックアップ
スナップ
ショット
パッチ更新
AZ-a AZ-b
• フルマネージドのRDBMSサービス
– MySQL、Oracle、SQLServer、PostgreSQL、MariaDB、Auroraから選択可能
• バックアップやフェイルオーバーに対応したDBを数クリックで利用可能
• メンテナンスコストを大幅に削減（パッチ当てやバックアップの自動化）
Amazon RDS (Relational Database Service)
別AZにデータを同期
自動的にフェイルオーバー
負荷分散のための「読み取
り用レプリカ」を作成可能

16. 15
簡単にデータベースを作成・起動
• 数クリックでDBが起動
– DBエンジン
– インスタンスクラス
– ディスクの種類とサイズ
等を選ぶだけ
• 構成は後から変更可能
• 必須の運用管理機能が実装済み
– バックアップ（スナップショット）
– マルチAZ構成による可用性向上
– 監視 (CloudWatch)
• OSへのログイン、常駐アプリの追加
等はできない

17. 16
8GB
16GB
32GB
64GB
128GB
244GB
4core 8core 16core 32core
r3.8xl
2core1core
r3.4xl
r3.2xl
r3.xl
r3.large
m4.2xl
m4.xl
m4.large
4GB
t2.small
t2.micro
m4はm3に変わる標準インスタンス
r3はメモリを多めに搭載したインスタンス
t2はt1に代わる小規模用インスタンス
t2.large
※DBエンジンによって使用できるインスタンスの種類が異なります
※図には記載していない旧世代インスタンスも選択可能です
t2.medium
m4.4xl
m4.10xl160GB
40core
RDSインスタンスのバリエーション

18. 17
高可用性構成もワンクリックで実現
• ワンクリックで耐障害性を向上可能なソリューション
– 高い技術力を持つDBAが行っていた設計をそのままサービス化
– AWS内部の仕組みで同期レプリケーションを実現（※Data Guardではない）
• 同期レプリケーション＋自動フェイルオーバー
– アプリ側での対処は必要なし(エンドポイントは変わらない）
– スタンバイ状態のDBはアクセス不可
• フェイルオーバーの実施タイミング
– インスタンスやハードウェア障害
– パッチ適用などのメンテナンス時間
– 手動リブート時に強制フェイルオーバー指定
http://aws.amazon.com/jp/rds/details/multi-az/ Region
Multi-AZ
Availability
zone
Availability
zone

19. 18
リードレプリカ(RR)機能
• 読み取り専用のレプリカDB
– Aurora, MySQL, PostgreSQLに対応
– Auroraは15台、MySQLとPostgreSQLは5台まで増設
可能
– RRのディスクタイプやインスタンスタイプをソース
とは異なるタイプに変更可能
• 想定ユースケース
– 読み取りのスケーリング、BI等の解析処理の分散
– マルチAZによる耐障害性の代替ではない
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html リードレプリカ
APP
APP
2APP
APP
読み書き
ワークロード
読み取り
ワークロード

20. 19
Amazon Redshift
• 特徴 (http://aws.amazon.com/jp/redshift/)
– 160GBから最大2PBまで拡張可能
– 超並列(MPP)、カラムナ型DBエンジンによ
る高速処理
– 他のAWSサービスとの高い親和性
– 従来のデータウェアハウスの1/10のコスト
• 価格体系 (http://aws.amazon.com/jp/redshift/pricing/)
– インスタンスタイプに応じ、1時間単位（イ
ンスタンスにはストレージを内蔵）
– バックアップストレージは利用量に応じて
フルマネージドのデータウェアハウスサービス
10Gb Ether
JDBC/ODBC
Redshift 大規模分散処理
で分析SQLを
高速実行

21. 20
クラウドへ移行することで解決できる部分とそうでない部分
残念ながら全ての運用が無くなるわけ
ではありません…
• 運用前（設計・導入）
– サーバサイジング
– ストレージサイジング
– 導入作業
– 可用性設計
– バックアップ設計
• 運用開始後
– バックアップ＆リストア
– パッチのテストと適用
– モニタリング
– サイズ調整（ディスク追加等）
– SQLチューニング
– 統計情報の更新
– フラグメンテーションの解消

22. 21
セルフマネージ型
or マネージド型？

23. 22
EC2で動かすか？ RDS/Redshiftを使うか？
マネージド型DBサービスを使うことは、
導入＆運用面でメリットが多い
– ソフトウェアの導入・構成作業が不要、パッチ適用も自動
– バックアップ＆リストアがビルトイン
– 高可用性構成（マルチAZ構成）の設定が容易
– リードオンリーの読み取り専用レプリカのセットアップが容易
– RDSではライセンス込みで、OracleやSQL Server等の商用データベースを
1時間単位で利用できる
まずはRDS/Redshiftで検討し、適合しない場合にEC2

24. 23
データベースをEC2に構築する理由①
RDSで用意されたリソースとニーズが合わないケース
• RDSが対応していないRDBやバージョンを選択したい場
合
• RDSの最大CPU数やメモリサイズでは不足する場合
• RDSの最大ストレージ量より大きいディスクが必要な場
合
– ストレージ領域の最大サイズは6TB (SQL Serverのみ最大4TB）
• メンテナンス時間を完全にユーザがコントロールしたい
場合

25. 24
データベースをEC2に構築する理由②
チューニングの幅が広い
• OS側のパラメータ調整、常駐プログラム
– データベースと同じOS上で常駐プログラムを実行可能
– シェルログインでの作業が必要な場合
– OS（カーネル）に何か特殊な設定が必要な場合
• RDSでは変更に対応していないDBパラ
メータの変更
• ストレージ領域構成の自由度が高い
– 多くのボリュームをOSにマウントし高速化
– REDOログやUNDO表領域のみ別のボリュームに分離
– 一部の表領域に専用のボリュームを割り当て

26. 25
商用DBワークロードをAWS化する際の選択肢
検討すべき
方針
柔軟度
実現したい
こと
現行環境
Oracle/SQL Server
オンプレミス
クラウド化したい
アプリケーション
書き換え可能
Aurora or Redshift
アプリケーションは
変えたくない
Oracle/SQL Server
(RDS or EC2)
商用DBを変えたい Aurora or Redshift

27. 26
移行のための手法とツール

28. 27
DB移行の手法 - その前に確認すべきこと
• 移行データサイズ
• 許容可能なダウンタイム
• AWSとのネットワーク速度
• 通信経路暗号化の必要性
– SCP、VPN、専用線
– ZIPファイルの暗号化…
サイズと時間。サイズが小
さく、時間が長い方が、移
行方法の選択肢が多くなる
移行元-AWS間通信中の
暗号化方法

29. 28
移行の考え方①ワンステップ移行（ダウンタイム有り）
• 抽出~ファイル転送~ロードまでを一度に実施するシンプルな方法
• 完了までDBは停止。1~3日間程度DBが使えない時間が許容される前提
• 小規模DBに向く
ターゲットDB
ソース
DB
イントラネット
Data Data
インターネット
①データ抽出
②ファイル転送
③データロード

30. 29
移行の考え方②２ステップ移行（ダウンタイム有りだが、
それを小さく抑える）
• 初期データのロードと、最新データのロードの二段階に分けた方法
• サービス停止時間を短くしたい中~大規模向け
• 差分抽出の仕組みが必要
ソース
DB
Data Data
①-1 データ抽出し、
サービス再開
①-2 初期データ
の転送とロード
Data
②-1 前回からの
差分を抽出
Data ターゲットDB
②-2 差分データ
の転送とロード

31. 30
移行の考え方③ダウンタイム（ほぼ）無しで移行
• 大規模、もしくはダウンタイムがほとんど取れないシステム向け
• ソースDBから更新データを継続的にターゲットDBに転送し、更新内
容を反映することでソースとターゲットを常に同じ内容に保つ
ソース
DB
Data Data
①-1 データ抽出し、
サービス再開
①-2 初期データ
の転送とロード
ターゲットDB
② 表が更新されるたびに、継続的に更新データが伝搬、反映される
更新
DMS等
更新

32. 31
異なるエンジン間のデータベース移行
• DDL（表やインデックスの定義）を修正してRDBの違い
に対応する必要がある
• RDB標準のツールによるDDL抜き出し
– MySQLではmysqldump
$ mysqldump –u source_db_username –p --no-data --routines --triggers –
databases source_db_name > DBSchema.sql
• その後DDLを手作業で修正
– 型の変換、プロシージャやトリガーの移行

33. 32
AWS Schema Conversion Tool（SCT）
• 異なるRDB間での各種オブジェクトの移行（変換）を補助
するツール
• Windows, Mac, Linux にダウンロードして利用
• 稼動OSは64bit版のみサポート
• ODBCで接続。SSLサポートあり
• ソースコード内のSQL分析に対応
• 移行対象：
• 表、インデックス、トリガー、プロシージャ、制約、ビュー

34. 33
【参考】Schema Conversion Toolスクリーンショット
調査対象のDBを指定
オブジェクトを調査し、
変換可能な量を表示

35. 34
【参考】Schema Conversion Toolスクリーンショット（続き）
変換前（Oracle PL/SQL)
変換後 (Aurora/MySQL Function)

36. 35
Schema Conversion Toolがサポートする組み合わせ
2016/11/18 更新
OLTP 変換
DWH変換
※補足）MySQLからAuroraへの移行の場合、
（SCTを使わなくても）MySQLのバックアップ
イメージからAuroraへ移行することが可能です。
http://docs.aws.amazon.com/ja_jp/Amazon
RDS/latest/UserGuide/Aurora.Migrate.html
https://docs.aws.amazon.com/ja_jp/SchemaConversionTool/latest/userguide/Welcome.html

37. 36
埋め込みSQLの変換支援
• ソースコードをスキャンして、埋め込
みSQL（DML）を発見し、変換（右表
の対応）
• C++,Java,C#に対応
• 事前にスキーマ（DDL）の変換が必要

38. 37
Schema Conversion Tool（SCT）のまとめ
• SCTでDDLを移行し、DMSでデータを移行する
• SCTはDML移行を補助するツール
• SCTの変換が最適な形とは限らない
• 自動変換できないオブジェクトもある
• SCTで大まかな変換と、自動変換できない部分を抽出し...
• 生成されたDDLの最適化
• 自動変換出来なかった部分の修正 移行担当者の作業

39. 38
AWS Database Migration Service（DMS）
• RDBの移行を支援するサービス
• セットアップ・利用が容易
• 使った分だけの安価な費用
• 異種エンジン間のデータ移行にも対応
• 低負荷で継続的なレプリケーション DMS
オンプレミ
ス
RDB
RDS
RDB on
EC2
オンプレミ
ス
RDB
RDS
RDB on
EC2
※オンプレ to オンプレは未サポート
特に異機種間データベースの移行や連携
基盤としての利用に強み
※DMSの詳細は以下の資料を参照してください
http://www.slideshare.net/AmazonWebServicesJapan/black-belt-
online-seminar-aws-amazon-rds

40. 39
移行対象
• 表定義
• プライマリキー
• データ
DMSが移行するもの
移行しないもの
• ビュー
• プロシージャ
• トリガー
• シノニム
• 制約（参照制約やユニーク制
約）
• 等

41. 40
DMSのCDC機能によるゼロ・ダウンタイム移行
CDC=ソースDBの変更をキャプチャし、ターゲットDBに継続的に反映しつづけ
る仕組み。異機種RDB間でも利用可能
処理の流れ
• DMSインスタンスを作成し、通信経路を確保する
• ターゲットDBに初期データをロードする（DMSの機能で、もしくは外部ツールで）
• DMSでCDCタスクを起動し、ソースDBから読み取ったトランザクションログを継続し
て反映し続ける
ソースDB DMS ターゲットDB
オンプレミスDC
VPN
Gateway
Customer
Gateway
VPN

42. 41
サポートするデータベース
ソース ターゲット SSL接続
Oracle on-pre/EC2 10g(10.2以降), 11g, 12c Ent/SE/SE1/SE2 10g, 11g, 12c Ent/SE/SE1/SE2
n/a
RDS 11g(※1), 12c Ent/SE/SE1/SE2 11g(※1), 12c Ent/SE/SE1/SE2
MySQL on-pre/EC2/RDS 5.5, 5.6, 5.7 5.5, 5.6, 5.7 ○
PostgreSQL on-pre/EC2 9.4以降 9.3以降
○
RDS 9.4以降 (※4) 9.3以降
SQL Server on-pre/EC2 2005, 2008, 2008R2, 2012, 2014, 2016
Ent, Std, Workgroup, Developer
2005, 2008, 2008R2, 2012, 2014, 2016
Ent, Std, Workgroup, Developer
○
RDS 2008R2, 2012, 2014, 2016 Ent, Std,
Workgroup, Developer (※2)
2008R2, 2012, 2014,2016 Ent, Std,
Workgroup, Developer
Aurora RDS MySQL互換としてサポート MySQL互換としてサポート ○
MariaDB on-pre/EC2/RDS MySQL互換としてサポート MySQL互換としてサポート ○
Redshift （ソースとしてはサポート無し） ターゲットDBとしてサポート n/a
SAP ASE
(Sybase ASE)
on-pre/EC2 15.7以降 15.7以降 (※3)
n/a
※1：11.2.0.3.v1以降
※2：CDC利用不可
※3：日本語データを含む場合は15.7 SP121以降
※4：RDSでは9.4.9以降もしくは9.5.4以降
2016年10月5日更新

43. 42
データベース移行の手順:SCTとDMSの位置づけ
(SCT)
(DMS)
DDL・スキーマの移行
＋プロシージャ等
データの移行

44. 43
AWS re:Invent 2016で発表された
DB関連の新サービス・機能の紹介

45. P o s t g r e S Q L F o r A u r o r a
Aurora is now fully compatible with
both PostgreSQL and MySQL

46. 1/10th The Cost Of
Commercial Grade
Databases
Fully PostgreSQL
Compatible
Several times better
performance than typical
PostgreSQL database
Scalable,
Durable and Secure
Migrate From
RDS For PostgreSQL
Amazon Aurora PostgreSQL-Compatible Edition

47. 46
Amazon Aurora
PostgreSQL-Compatible Editionを発表
• PostgreSQL 9.6.1互換のAmazon Auroraを発表
– PostgreSQL対応を望むお客様からのご要望に基づく
• チェック制約、マテリアライズドビュー、シーケンス、ウィンドウ関数
• ハッシュ結合、ソート・マージ結合
• プロシージャ、日付書式などの互換性
• PostGIS（地理空間情報）
– RDS for PostgreSQLと同様の機能をサポート予定
– RDS for PostgreSQLのスナップショットからの移行をサポート
• バージニアリージョンでプレビューを開始
– https://pages.awscloud.com/amazon-aurora-with-postgresql-
compatibility-preview-form.html

48. 47
SQL
Transactions
AZ 1 AZ 2 AZ 3
Caching
Amazon S3
• MySQL互換のAuroraと同じストレージ
システムを採用
• SSDを利用し、最大64TBまでシームレス
にスケール
• リードレプリカが同じストレージを参照
する構造をもち、レプリカラグを最小化
• 3AZに各2つ（合計6つ）にデータを複製
– 2つで障害が起きても読み書き可能
– 3つで障害が起きても読み込み可能
• 継続的にS3へ増分バックアップを実施
パフォーマンスへの影響はない
• 障害復旧やホットスポット管理、暗号化
といったタスクを自動的に実施
Amazon Aurora PostgreSQL-Compatible Edition
Auroraストレージの利点をそのまま活用

49. 48
• pgbench (TPC-B-Like) でRDS PostgreSQLの2倍の
最大スループットを実現
• 料金はMySQL互換のAuroraと同様
Amazon Aurora PostgreSQL-Compatible Edition
パフォーマンスと料金

50. 49
RDS向けのチューニング機能を発表
• DBの知識を持ったエンジニアが
いなくとも、クエリパフォーマンス
の評価やDBの状態チェックを可能に
する機能
• Aurora PostgreSQL-Compatible
Editionには組み込み済みの状態で
リリースされる
• 他のデータベースエンジンにも
順次展開予定

51. 50
Aurora MySQLの新機能

52. 51
ゼロダウンタイムパッチ
Networkin
g
state
Applicatio
n
state
Storage Service
App
stat
e
Net
stat
e
App
state
Net
stat
e
BeforeZDP
New
DB
Engine
Old DB
Engine
New
DB
Engine
Old DB
Engine
WithZDP
セッションはパッチ
適用時に切断される
パッチ適用中でも
セッションは維持される
Storage Service

53. 52
Online DDL: Aurora vs. MySQL
 フルテーブルコピー: 全てのインデックスを
再構築 - 数時間から数日かかることも
 DMLクエリ実行のために一時領域が必要
 DDLクエリがDMLクエリスループットに影響
 DMLクエリ実行中にテーブル・ロックが起こる
Index
LeafLeafLeaf Leaf
Index
Root
table name operation column-name time-stamp
Table 1
Table 2
Table 3
add-col
add-col
add-col
column-abc
column-qpr
column-xyz
t1
t2
t3
 メタデータテーブルにエントリーを追加し、
スキーマバージョニングを利用する
 変更を適用するために最新のスキーマへブロック
をアップグレードする際はmodify-on-write
 現在はテーブルの最後にNullableなカラムを
追加する場合に対応
 他のadd column, drop/reorder, modify
datatypesに対応するために実装を行っている
MySQL Amazon Aurora

54. 53
Online DDL performance
On r3.large
On r3.8xlarge
Aurora MySQL 5.6 MySQL 5.7
10GB table 0.27 sec 3,960 sec 1,600 sec
50GB table 0.25 sec 23,400 sec 5,040 sec
100GB table 0.26 sec 53,460 sec 9,720 sec
Aurora MySQL 5.6 MySQL 5.7
10GB table 0.06 sec 900 sec 1,080 sec
50GB table 0.08 sec 4,680 sec 5,040 sec
100GB table 0.15 sec 14,400 sec 9,720 sec

55. 54
Online Point in Time Restore
Online point in time restore はバックアップからリストアを行うこと無く、
データベースを特定の時点へ即座に戻す事が可能
• 意図しないDML/DDLの実行から即座にデータベースを元の状態に戻す
• 所望のデータベースの状態に戻すため複数回実行
• スキーマ変更を高速にリストアを行わずにイテレーションを行える
t0 t1 t2
t0 t1
t2
t3 t4
t3
t4
Rewind to t1
Rewind to t3
Invisible Invisible

56. 55
Database Cloning
ストレージコストを増やすことなく
データベースのコピーを作成
• データをコピーするわけではないため、
クローンの作成はほぼ即座に完了
• データのコピーはオリジナルボリュームと
コピー先のボリュームのデータが異なる
場合の書き込み時のみ発生
ユースケース
• プロダクションデータを使用したテスト
• データベースの再構成
• プロダクションシステムに影響を及ばさずに
分析目的で特定の時点での
スナップショットを保存 Production database
Clone Clone
Clone
Dev/test
applications
Benchmarks
Production
applications
Production
applications

57. 56
Aurora Auditing
MariaDB server_audit plugin Aurora native audit support
• We can sustain over 500K events/sec
Create event
string
DDL
DML
Query
DCL
Connect
DDL
DML
Query
DCL
Connect
Write
to
File
Create event
string
Create event
string
Create event
string
Create event
string
Create event
string
Latch-
free
queue
Write to
File
Write to
File
Write to
File
MySQL 5.7 Aurora
Audit Off 95K 615K 6.47x
Audit On 33K 525K 15.9x
Sysbench Select-only Workload on 8xlarge Instance

58. 57

59. 58
Amazon Athenaを発表
• Amazon S3に置いたデータをインタラクティブに
SQLで直接クエリできるマネージドサービス
• データをS3から取り込む手間はない
• ペタバイト級のデータに対するクエリをサポート
• 標準のANSI-SQLでクエリを表現でき、JOINや
ウィンドウ関数もサポート
• バージニア、オレゴンのリージョンで利用可能

60. 59
これまでのデータ処理フロー
複数のソースから
S3にデータを
アップロード
Amazon EMR を
使用してETL
ETLされた
データを
S3に保存
データを
Redshiftに
ロード
QuickSight で
分析

61. 60
Athenaも加えたデータ処理フロー
複数のソースから
S3にデータを
アップロード
Amazon EMR を
使用してETL
ETLされた
データを
S3に保存
データを
Redshiftに
ロード
QuickSight で
分析
SQLを使用して生データに
アドホックアクセス
集計したデータを
クエリすることも可能

62. 61
他のBig Dataサービスとの使い分け
• Amazon Redshift
– 多くの結合や副問合せを含む非常に複雑なSQLで最も高速なパフォーマンスを提供
– 様々なデータソースからのデータを共通フォーマットで長期保存するようなケースに最適
• Amazon EMR
– 高度な分散処理フレームワークを簡単にコスト効率良く実行
– フレームワークやインスタンスおよびストレージのタイプの選択肢が広く、
分析要件に最適化した柔軟な構成が可能
– 機械学習、グラフ解析、データ変換などで非常に大きなデータを扱うようなケースに最適
• Amazon Athena
– サーバーの管理を行うことなく、S3のデータに対してアドホッククエリを
実行する最も簡単な方法を提供
– サイトの性能問題をトラブルシューティングするためにWebログに対して
一時的なクエリを実行するようなケースに最適

63. 62
Athenaをご利用中のお客様

64. 63
Gunosy データ・サイエンティスト 阿部洋介氏
“Amazon S3 上のデータを直接クエリ処理して
いるのに、これまで使用してきたシステムよりも
高速にクエリ結果を得られたことに大変感銘を
受けています。
当社はワークロードを積極的にAWSに移行し、
今後、Amazon Athena を当社の
分析プラットフォームの中核に据えるつもりです

65. 64
AWS Glueを発表
• データカタログの作成と、データの加工・ロード
(ETL)が実現可能なマネージドサービス
• データソースを自動で探索し、データフォーマットを
認識してスキーマや変換ロジックを提示
• S3, RDS, Redshift その他 JDBC対応データストアを
サポート
• Python, Spark, Git, 好みのIDEで変換ロジックを
編集したり、他のユーザーと共有することも可能
• ジョブにあわせてインフラを自動でスケーリング
• プリアナウンスサービス

66. 65
まとめ

67. 66
まとめ
• AWSへRDBを移行する目的
– 運用管理を楽に＆柔軟で強固なインフラへ
• セルフマネージ型(EC2) or マネージド型(RDS)？
– OLTP系はまずRDSを検討し、要件にフィットしない場合にRDB on EC2を検討
– DWH系はRedshiftを検討
• 手法とツール
– システム要件とダウンタイム許容時間によって適切な手法を選択
– DMS/SCTを活用して工数を削減

68. 67
Q&A
[導入に関しての問い合わせ]
https://aws.amazon.com/jp/database-migration/
[課金・請求内容、またはアカウントに関するお問い合わせ]
https://aws.amazon.com/jp/contact-us/

69. 68

70. 69
参考情報
• Migrating Your Databases to Amazon Aurora (英語）
– https://d0.awsstatic.com/whitepapers/RDS/Migrating%20your%20databases%20to%20Amazon%20Aurora.pdf
• Amazon Aurora DB クラスターへのデータの移行
– https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.Migrate.html
• AWS Database Migration Service 解説
– http://www.slideshare.net/AmazonWebServicesJapan/black-belt-online-seminar-aws-amazon-rds
• RDBのAWSへの移行方法（Oracleを例に）
– http://www.slideshare.net/AmazonWebServicesJapan/20150728-rd-bmigrationpublic
• Oracle RDSにおけるデータ移行（マニュアル）
– http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Oracle.Procedural.Importing.html
• Strategies for Migrating Oracle Database to AWS
– AWSのホワイトペーパー(PDF)。具体的な作業内容が記載されています
– http://d0.awsstatic.com/whitepapers/strategies-for-migrating-oracle-database-to-aws.pdf

71. 70
参考情報
• Amazon Athena
– https://aws.amazon.com/jp/athena/
– https://aws.amazon.com/jp/athena/faqs/
• Amazon Aurora PostgreSQL-Compatible Edition
– https://aws.amazon.com/jp/blogs/news/amazon-aurora-update-
postgresql-compatibility/
• AWS Glue
– https://aws.amazon.com/jp/glue/
• AWS QuickSight
– https://quicksight.aws/
70

72. 71
補足情報：AWS Database Migration Service
• ホームページ
• https://aws.amazon.com/jp/dms/
• マニュアル
• https://aws.amazon.com/documentation/dms/
• FAQ
• http://aws.amazon.com/jp/dms/faqs/
• フォーラム
• https://forums.aws.amazon.com/forum.jspa?forumID=216
• re:Invent 2015での解説セッション（30分の動画）
• https://www.youtube.com/watch?v=JuUE5HZb2gs

73. 72
補足情報：AWS Schema Conversion Tool
• ホームページ
• http://aws.amazon.com/jp/dms/sct/
• マニュアル
• https://aws.amazon.com/jp/documentation/SchemaConversionTool/
• ダウンロード
• （上記マニュアルの"Install and Updating"より）
• フォーラム
• https://forums.aws.amazon.com/forum.jspa?forumID=208