Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DBワークロードのAWS化とデータベースサービス関連最新情報

1,706 views

Published on

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

Published in: Data & Analytics
  • Hello! High Quality And Affordable Essays For You. Starting at $4.99 per page - Check our website! https://vk.cc/82gJD2
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

DBワークロードのAWS化とデータベースサービス関連最新情報

  1. 1. 0 DBワークロードのAWS化と データベースサービス関連最新情報 2017年2月23日 アマゾン ウェブ サービス ジャパン株式会社 事業開発本部 プラットフォーム事業開発部 部長 大久保 順
  2. 2. 1 本日の内容 • 既存RDBMSをアマゾン ウェブ サービス(AWS)上の EC2(仮想マシン/セルフマネージド)、あるいは RDS/Redshift(マネージド型DBサービス)に移行する メリットやその手法 • AWSのマネージド型DBサービスについての最新情報
  3. 3. 2 アジェンダ • RDB移行の背景 • セルフマネージ型 or マネージド型? • 移行のための手法とツール • AWSデータベースサービス最新情報 • まとめ
  4. 4. 3 RDB移行の背景
  5. 5. 4 クラウドへ移行する理由 • 理由はシステムによってそれぞれですが... 変更に時間 が掛かりす ぎる HWの保守 が大変 ソフトウェアの ライセンスや保 守が高い 低い可用性をな んとかしたい インフラコ ストが高い
  6. 6. 5 RDBにおける課題 • サイズアップへのタイムリーな対応 – 最初に設計した時より、利用アプリもサイズも増えていく • 運用の負荷が大きい – 日々のバックアップ、モニタリング、パッチ当て ... • 高い可用性を求められる – 障害を起こすと多くのシステムに影響がある
  7. 7. 6 RDBにおける課題をAWSクラウドで解決する • サイズアップへのタイムリーな対応 ⇒ いつでもスケールアップ・スケールアウトが出来る環境 • 運用の負荷が大きい ⇒ハードウェアやネットワークの保守対応が不要に ⇒マネージド・サービスによる運用負荷低減 • 高い可用性を求められる ⇒単体のハードウェア障害についてはAWSが実施 ⇒マルチAZによる高い可用性 柔軟なインフラ 運用負荷低減 可用性向上
  8. 8. 7 事例:Retty様 • ビジネスの急激な拡大に伴い、VPSから AWSへ移行 • 急激に増加するユーザーに対して短時間 で負荷分散を実現するため、「自前での マシンセットアップは極力行わない、運 用コストをとにかく下げる」という方針 • 「特にマネージドサービスの選択が大き いです。インフラ専任を置かずにひたす らスケールをさせて、利用開始時から ユーザー数は 10 倍以上になりましたが、 マネージドサービスをフルに利用する事 で安定してサービスを稼働させる事が出 来ています」 柔軟なインフラ 運用負荷低減
  9. 9. 8 • 2011年の大震災を機に事業運 営の安定化のインフラとして AWSを選択 • ECシステムはRDS+EC2に移 行(2011年) • SAPシステムはDB on EC2に 移行(2012年) 事例:ケンコーコム様 https://aws.amazon.com/jp/solutions/case-studies/kenkocom/ 可用性向上
  10. 10. 9 事例:Sogeti様(DRサイト) • DRサイトとしてAWS を活用 • オンプレミスの ExadataからData GuardでAWS上の Oracle+EC2にレプリ ケーション https://aws.amazon.com/jp/solutions/case-studies/sogeti/ 可用性向上
  11. 11. 10 課題:RDBは設計・導入だけでなく運用の負荷が高い • 運用前(設計・導入) – サイジング – 導入作業 – 可用性設計 – バックアップ設計 • 運用開始後 – バックアップの自動実行 – リストア – モニタリング – サイズ調整(ディスク追加等) – SQLチューニング – 統計情報の更新 – フラグメンテーションの解消
  12. 12. 11 課題:RDBは設計・導入だけでなく運用の負荷が高い • 運用前(設計・導入) – サイジング – 導入作業 – 可用性設計 – バックアップ設計 • 運用開始後 – バックアップの自動実行 – リストア – モニタリング – サイズ調整(ディスク追加等) – SQLチューニング – 統計情報の更新 – フラグメンテーションの解消 クラウド化で楽になる部分 変わらず残る部分
  13. 13. 12 クラウドへ移行することで解決できる部分とそうでない部分 サイジングと導入が大幅に軽減 • 数クリックでサーバ起動 • 後からCPUやメモリ、台数を調整可能 • IOPSを保証できるディスク環境 • 運用前(設計・導入) – サーバサイジング – ストレージサイジング – 導入作業 – 可用性設計 – バックアップ設計 • 運用開始後 – バックアップ&リストア – パッチのテストと適用 – モニタリング – サイズ調整(ディスク追加等) – SQLチューニング – 統計情報の更新 – フラグメンテーションの解消
  14. 14. 13 クラウドへ移行することで解決できる部分とそうでない部分 • 運用前(設計・導入) – サーバサイジング – ストレージサイジング – 導入作業 – 可用性設計 – バックアップ設計 • 運用開始後 – バックアップ&リストア – パッチのテストと適用 – モニタリング – サイズ調整(ディスク追加等) – SQLチューニング – 統計情報の更新 – フラグメンテーションの解消 可用性、バックアップ&リストア、 モニタリングといった、基本要件が 設計済みのマネージドDBを利用することで 解消され、サイズ調整が極めて容易に
  15. 15. 14 自動 バックアップ スナップ ショット パッチ更新 AZ-a AZ-b • フルマネージドのRDBMSサービス – MySQL、Oracle、SQLServer、PostgreSQL、MariaDB、Auroraから選択可能 • バックアップやフェイルオーバーに対応したDBを数クリックで利用可能 • メンテナンスコストを大幅に削減(パッチ当てやバックアップの自動化) Amazon RDS (Relational Database Service) 別AZにデータを同期 自動的にフェイルオーバー 負荷分散のための「読み取 り用レプリカ」を作成可能
  16. 16. 15 簡単にデータベースを作成・起動 • 数クリックでDBが起動 – DBエンジン – インスタンスクラス – ディスクの種類とサイズ 等を選ぶだけ • 構成は後から変更可能 • 必須の運用管理機能が実装済み – バックアップ(スナップショット) – マルチAZ構成による可用性向上 – 監視 (CloudWatch) • OSへのログイン、常駐アプリの追加 等はできない
  17. 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. 18. 17 高可用性構成もワンクリックで実現 • ワンクリックで耐障害性を向上可能なソリューション – 高い技術力を持つDBAが行っていた設計をそのままサービス化 – AWS内部の仕組みで同期レプリケーションを実現(※Data Guardではない) • 同期レプリケーション+自動フェイルオーバー – アプリ側での対処は必要なし(エンドポイントは変わらない) – スタンバイ状態のDBはアクセス不可 • フェイルオーバーの実施タイミング – インスタンスやハードウェア障害 – パッチ適用などのメンテナンス時間 – 手動リブート時に強制フェイルオーバー指定 http://aws.amazon.com/jp/rds/details/multi-az/ Region Multi-AZ Availability zone Availability zone
  19. 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. 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. 21. 20 クラウドへ移行することで解決できる部分とそうでない部分 残念ながら全ての運用が無くなるわけ ではありません… • 運用前(設計・導入) – サーバサイジング – ストレージサイジング – 導入作業 – 可用性設計 – バックアップ設計 • 運用開始後 – バックアップ&リストア – パッチのテストと適用 – モニタリング – サイズ調整(ディスク追加等) – SQLチューニング – 統計情報の更新 – フラグメンテーションの解消
  22. 22. 21 セルフマネージ型 or マネージド型?
  23. 23. 22 EC2で動かすか? RDS/Redshiftを使うか? マネージド型DBサービスを使うことは、 導入&運用面でメリットが多い – ソフトウェアの導入・構成作業が不要、パッチ適用も自動 – バックアップ&リストアがビルトイン – 高可用性構成(マルチAZ構成)の設定が容易 – リードオンリーの読み取り専用レプリカのセットアップが容易 – RDSではライセンス込みで、OracleやSQL Server等の商用データベースを 1時間単位で利用できる まずはRDS/Redshiftで検討し、適合しない場合にEC2
  24. 24. 23 データベースをEC2に構築する理由① RDSで用意されたリソースとニーズが合わないケース • RDSが対応していないRDBやバージョンを選択したい場 合 • RDSの最大CPU数やメモリサイズでは不足する場合 • RDSの最大ストレージ量より大きいディスクが必要な場 合 – ストレージ領域の最大サイズは6TB (SQL Serverのみ最大4TB) • メンテナンス時間を完全にユーザがコントロールしたい 場合
  25. 25. 24 データベースをEC2に構築する理由② チューニングの幅が広い • OS側のパラメータ調整、常駐プログラム – データベースと同じOS上で常駐プログラムを実行可能 – シェルログインでの作業が必要な場合 – OS(カーネル)に何か特殊な設定が必要な場合 • RDSでは変更に対応していないDBパラ メータの変更 • ストレージ領域構成の自由度が高い – 多くのボリュームをOSにマウントし高速化 – REDOログやUNDO表領域のみ別のボリュームに分離 – 一部の表領域に専用のボリュームを割り当て
  26. 26. 25 商用DBワークロードをAWS化する際の選択肢 検討すべき 方針 柔軟度 実現したい こと 現行環境 Oracle/SQL Server オンプレミス クラウド化したい アプリケーション 書き換え可能 Aurora or Redshift アプリケーションは 変えたくない Oracle/SQL Server (RDS or EC2) 商用DBを変えたい Aurora or Redshift
  27. 27. 26 移行のための手法とツール
  28. 28. 27 DB移行の手法 - その前に確認すべきこと • 移行データサイズ • 許容可能なダウンタイム • AWSとのネットワーク速度 • 通信経路暗号化の必要性 – SCP、VPN、専用線 – ZIPファイルの暗号化… サイズと時間。サイズが小 さく、時間が長い方が、移 行方法の選択肢が多くなる 移行元-AWS間通信中の 暗号化方法
  29. 29. 28 移行の考え方①ワンステップ移行(ダウンタイム有り) • 抽出~ファイル転送~ロードまでを一度に実施するシンプルな方法 • 完了までDBは停止。1~3日間程度DBが使えない時間が許容される前提 • 小規模DBに向く ターゲットDB ソース DB イントラネット Data Data インターネット ①データ抽出 ②ファイル転送 ③データロード
  30. 30. 29 移行の考え方②2ステップ移行(ダウンタイム有りだが、 それを小さく抑える) • 初期データのロードと、最新データのロードの二段階に分けた方法 • サービス停止時間を短くしたい中~大規模向け • 差分抽出の仕組みが必要 ソース DB Data Data ①-1 データ抽出し、 サービス再開 ①-2 初期データ の転送とロード Data ②-1 前回からの 差分を抽出 Data ターゲットDB ②-2 差分データ の転送とロード
  31. 31. 30 移行の考え方③ダウンタイム(ほぼ)無しで移行 • 大規模、もしくはダウンタイムがほとんど取れないシステム向け • ソースDBから更新データを継続的にターゲットDBに転送し、更新内 容を反映することでソースとターゲットを常に同じ内容に保つ ソース DB Data Data ①-1 データ抽出し、 サービス再開 ①-2 初期データ の転送とロード ターゲットDB ② 表が更新されるたびに、継続的に更新データが伝搬、反映される 更新 DMS等 更新
  32. 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. 33. 32 AWS Schema Conversion Tool(SCT) • 異なるRDB間での各種オブジェクトの移行(変換)を補助 するツール • Windows, Mac, Linux にダウンロードして利用 • 稼動OSは64bit版のみサポート • ODBCで接続。SSLサポートあり • ソースコード内のSQL分析に対応 • 移行対象: • 表、インデックス、トリガー、プロシージャ、制約、ビュー
  34. 34. 33 【参考】Schema Conversion Toolスクリーンショット 調査対象のDBを指定 オブジェクトを調査し、 変換可能な量を表示
  35. 35. 34 【参考】Schema Conversion Toolスクリーンショット(続き) 変換前(Oracle PL/SQL) 変換後 (Aurora/MySQL Function)
  36. 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. 37. 36 埋め込みSQLの変換支援 • ソースコードをスキャンして、埋め込 みSQL(DML)を発見し、変換(右表 の対応) • C++,Java,C#に対応 • 事前にスキーマ(DDL)の変換が必要
  38. 38. 37 Schema Conversion Tool(SCT)のまとめ • SCTでDDLを移行し、DMSでデータを移行する • SCTはDML移行を補助するツール • SCTの変換が最適な形とは限らない • 自動変換できないオブジェクトもある • SCTで大まかな変換と、自動変換できない部分を抽出し... • 生成されたDDLの最適化 • 自動変換出来なかった部分の修正 移行担当者の作業
  39. 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. 40. 39 移行対象 • 表定義 • プライマリキー • データ DMSが移行するもの 移行しないもの • ビュー • プロシージャ • トリガー • シノニム • 制約(参照制約やユニーク制 約) • 等
  41. 41. 40 DMSのCDC機能によるゼロ・ダウンタイム移行 CDC=ソースDBの変更をキャプチャし、ターゲットDBに継続的に反映しつづけ る仕組み。異機種RDB間でも利用可能 処理の流れ • DMSインスタンスを作成し、通信経路を確保する • ターゲットDBに初期データをロードする(DMSの機能で、もしくは外部ツールで) • DMSでCDCタスクを起動し、ソースDBから読み取ったトランザクションログを継続し て反映し続ける ソースDB DMS ターゲットDB オンプレミスDC VPN Gateway Customer Gateway VPN
  42. 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. 43. 42 データベース移行の手順:SCTとDMSの位置づけ (SCT) (DMS) DDL・スキーマの移行 +プロシージャ等 データの移行
  44. 44. 43 AWS re:Invent 2016で発表された DB関連の新サービス・機能の紹介
  45. 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. 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. 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. 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. 49. 48 • pgbench (TPC-B-Like) でRDS PostgreSQLの2倍の 最大スループットを実現 • 料金はMySQL互換のAuroraと同様 Amazon Aurora PostgreSQL-Compatible Edition パフォーマンスと料金
  50. 50. 49 RDS向けのチューニング機能を発表 • DBの知識を持ったエンジニアが いなくとも、クエリパフォーマンス の評価やDBの状態チェックを可能に する機能 • Aurora PostgreSQL-Compatible Editionには組み込み済みの状態で リリースされる • 他のデータベースエンジンにも 順次展開予定
  51. 51. 50 Aurora MySQLの新機能
  52. 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. 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. 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. 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. 56. 55 Database Cloning ストレージコストを増やすことなく データベースのコピーを作成 • データをコピーするわけではないため、 クローンの作成はほぼ即座に完了 • データのコピーはオリジナルボリュームと コピー先のボリュームのデータが異なる 場合の書き込み時のみ発生 ユースケース • プロダクションデータを使用したテスト • データベースの再構成 • プロダクションシステムに影響を及ばさずに 分析目的で特定の時点での スナップショットを保存 Production database Clone Clone Clone Dev/test applications Benchmarks Production applications Production applications
  57. 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. 58. 57
  59. 59. 58 Amazon Athenaを発表 • Amazon S3に置いたデータをインタラクティブに SQLで直接クエリできるマネージドサービス • データをS3から取り込む手間はない • ペタバイト級のデータに対するクエリをサポート • 標準のANSI-SQLでクエリを表現でき、JOINや ウィンドウ関数もサポート • バージニア、オレゴンのリージョンで利用可能
  60. 60. 59 これまでのデータ処理フロー 複数のソースから S3にデータを アップロード Amazon EMR を 使用してETL ETLされた データを S3に保存 データを Redshiftに ロード QuickSight で 分析
  61. 61. 60 Athenaも加えたデータ処理フロー 複数のソースから S3にデータを アップロード Amazon EMR を 使用してETL ETLされた データを S3に保存 データを Redshiftに ロード QuickSight で 分析 SQLを使用して生データに アドホックアクセス 集計したデータを クエリすることも可能
  62. 62. 61 他のBig Dataサービスとの使い分け • Amazon Redshift – 多くの結合や副問合せを含む非常に複雑なSQLで最も高速なパフォーマンスを提供 – 様々なデータソースからのデータを共通フォーマットで長期保存するようなケースに最適 • Amazon EMR – 高度な分散処理フレームワークを簡単にコスト効率良く実行 – フレームワークやインスタンスおよびストレージのタイプの選択肢が広く、 分析要件に最適化した柔軟な構成が可能 – 機械学習、グラフ解析、データ変換などで非常に大きなデータを扱うようなケースに最適 • Amazon Athena – サーバーの管理を行うことなく、S3のデータに対してアドホッククエリを 実行する最も簡単な方法を提供 – サイトの性能問題をトラブルシューティングするためにWebログに対して 一時的なクエリを実行するようなケースに最適
  63. 63. 62 Athenaをご利用中のお客様
  64. 64. 63 Gunosy データ・サイエンティスト 阿部洋介氏 “Amazon S3 上のデータを直接クエリ処理して いるのに、これまで使用してきたシステムよりも 高速にクエリ結果を得られたことに大変感銘を 受けています。 当社はワークロードを積極的にAWSに移行し、 今後、Amazon Athena を当社の 分析プラットフォームの中核に据えるつもりです
  65. 65. 64 AWS Glueを発表 • データカタログの作成と、データの加工・ロード (ETL)が実現可能なマネージドサービス • データソースを自動で探索し、データフォーマットを 認識してスキーマや変換ロジックを提示 • S3, RDS, Redshift その他 JDBC対応データストアを サポート • Python, Spark, Git, 好みのIDEで変換ロジックを 編集したり、他のユーザーと共有することも可能 • ジョブにあわせてインフラを自動でスケーリング • プリアナウンスサービス
  66. 66. 65 まとめ
  67. 67. 66 まとめ • AWSへRDBを移行する目的 – 運用管理を楽に&柔軟で強固なインフラへ • セルフマネージ型(EC2) or マネージド型(RDS)? – OLTP系はまずRDSを検討し、要件にフィットしない場合にRDB on EC2を検討 – DWH系はRedshiftを検討 • 手法とツール – システム要件とダウンタイム許容時間によって適切な手法を選択 – DMS/SCTを活用して工数を削減
  68. 68. 67 Q&A [導入に関しての問い合わせ] https://aws.amazon.com/jp/database-migration/ [課金・請求内容、またはアカウントに関するお問い合わせ] https://aws.amazon.com/jp/contact-us/
  69. 69. 68
  70. 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. 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. 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. 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

×