Deck Guidelines

Size: px

Start display at page:

Download "Deck Guidelines"

てるえしどり
5 years ago
Views:

データベース移行のベストプラクティス AWS Database Migration

Technical Program Manager July 5, 2017 2017,

2 アジェンダ製品の概要移行手順とユースケース予想されることその他のツール

3 製品の概要

Conversion Tool (SCT) は商用データベースとデータウェアハウスのスキーマをオープンソースのエンジンや

4 DMS と SCT とは何か AWS Database Migration Service (DMS) は簡単かつセキュアにデータベースとデータウェアハウスを AWS へ移行およびレプリケーションします AWS Schema Conversion Tool (SCT) は商用データベースとデータウェアハウスのスキーマをオープンソースのエンジンや Aurora や Redshift のような AWS ネイティブサービス用に変換しますすでに 3 万データベースを移行しさらに増え続けています

5 DMS と SCT をいつ使うかモダナイズ移行レプリケーション

6 SCT をいつ使うかデータベース層のモダナイズ Amazon Aurora モダナイズ既存データウェアハウスのモダナイズと Amazon Redshift への移行 Amazon Redshift

7 DMS* をいつ使うか Sources: 移行ビジネスクリティカルアプリケーションの移行クラッシック環境からVPCへの移行データウェアハウスの Redshiftへの移行マイナーバージョンへのアップグレード Auroraへの統合 NoSQLからSQL SQLからNoSQL NoSQLからNoSQLへの移行 Targets: Amazon S3 Amazon Redshift Amazon Dynamo DB *DMS は HIPAA 対応済み Amazon Aurora

8 DMS をいつ使うかレプリケーションクロスリージョンレプリカの作成クラウドでの分析実行開発 / テスト環境と本番環境の同期の維持

9 移行手順

10 データベース移行複数フェーズの手順フェーズ内容自動化工数 (%) 1 アセスメント SCT 2 2 データベーススキーマの変換 SCT/DMS 14 3 アプリケーションの変換 / 調整 SCT 25 4 スクリプトの変換 SCT 7 5 サードパーティアプリケーションの統合 3 6 データの移行 DMS 4 7 システム全体の機能テスト 29 8 パフォーマンスチューニング SCT 2 9 統合とデプロイ 7 10 トレーニングと知識 2 11 文書化とバージョン管理 2 12 カットオーバー後の運用支援 3

11 ステップ 0 担当者深いデータベースの知識が必要 1つのエンジンだけでは不十分かも深いネットワークの知識が必要 AWSの知識が必要ソフトウェアアーキテクチャの知識が一般的には必要

12 ステップ 1 マニュアルを読むご利用開始にあたって FAQ ベストプラクティスフォーラムブログ手順書とデモ

13 ステップ 2 スケジュール計画移行プロジェクトは数週間から数カ月を要する可能性がある何度か繰り返す可能性がある予想より遅くなる可能性がある移行が完了すべき日程は厳しい? 計画は移行自体より長くなる可能性がある

14 ステップ 3 データベースを理解するデータベースの容量はいくつ? いくつのスキーマとテーブルがある? 非常に大きなテーブルはいくつある? トランザクション境界はどうなっている? DMSがサポートしていないエンジン固有の機能を使っている? テーブルにLOBは含まれている? それの大きさは? LOBを含むテーブルにPKはついている? ソースデータベースはどのように使われる? ソースデータベースにはどのようなユーザー / ロール / 権限がある? いつデータベースをバキューム / コンパクト化した?

15 ステップ 4 ネットワークを理解するどのようにデータベースにアクセスできる? ( ファイアウォールトンネル VPN) どの VPC を使うべき? どのセキュリティグループを使うべき? 全データを移動するための十分な帯域はある?

16 ステップ 5 要件を理解するダウンタイムは許容されるか? 移行後もソースDBをメンテナンスする必要があるか? ターゲットDBのエンジンをそれに決めた理由は? 高可用性要件は? 全てのデータを移行する必要があるか? 全てを同じ場所に置く必要があるか? RDSのメリットは理解しているか? ( 自動バックアップ HA 等々) RDSの制約は理解しているか? ( ストレージ容量管理者権限等々 ) 関連アプリケーションへの影響を把握しているか? 万一の際の切り戻しのプランは出来ているか?

17 ステップ 6 ターゲットスキーマ DMSはテーブルと主キーのみ作成する SCT Schema Conversion Tool (=スキーマ変換ツール) 同一エンジン間ではほぼ全てのスキーマオブジェクトをコピー異種エンジン間ではスキーマオブジェクトを変換オーケストレーションは現時点では非対応同一エンジン間移行であれば標準のネイティブツールを使う手もスキーマ変更は移行が終わってから行う

18 準備は良いですか? まずは小さな DB でテストしましょう CloudWatchのログを確認することを怠らない適切なインスタンスタイプを選択 ( ヒント :t2.microは選ばない) ソースDB 上で移行前に必要な設定は終わっていますか?

19 移行開始! ある程度時間がかかります稼働状況を監視ログを確認エラー有無を確認切り捨てられた行がないか確認移行に注意が必要なデータ型がきちんと移行されているか確認キャラクタセットの関係で文字化けやデータ破損が発生していないか?

20 期待されることは?

21 移行時間に影響を与える要素ソース DB のサイズと負荷ターゲット DB のサイズ利用可能なネットワーク帯域レプリケーションインスタンスのサイズスキーマ構造 (1 つの巨大なテーブルと他の小さなテーブルで構成されているようなケースでは時間がかかる ) スキーマにラージオブジェクト (LOB) があるか? 大きなトランザクションの実行有無タスクを適切に構成する

22 監視 CloudWatch Logs を活用コンソール上でタスク監視とテーブル統計をウォッチする

23 他のツール

24 ネイティブなレプリケーションが向くケースターゲットがネイティブなレプリケーション形式に対応できる全てのデータを移行するスキーマやデータの変換が必要ないターゲットが新しいDBである

25 ダンプ & リストアが向くケース DBサイズがさほど大きくないダウンタイムが許容可能 ( ダンプ+ 転送 +リストア ) ソースDBの全てのデータを移行するスキーマやデータ型の変換が必要ない

26 大きな DB の扱い大きいとは? 全てのデータ移行が許容される移行時間内に終わらない可能性がある 5TB が一つの目安だがそれより大きくても DMS で十分移行できる場合もあれば逆に小さくても多くの時間がかかるケースもある

27 大きなデータセット使用中のデータウェアハウスからデータを抽出し Amazon Redshift へ移行ローカルマイグレーションエージェントを使ってデータを抽出データはRedshift 向けに最適化されローカルファイルとして保存されるファイルは Amazon S3 バケットに保存し ( ネットワーク or Snowball 経由 ) Redshift にロードす AWS SCT S3 Bucket Amazon Redshift る

28 まとめ

29 まとめデータベース移行は複雑 AWSが提供するツール群で約 50% の作業は自動化可能環境を知る ( 現在の環境と新環境 ) 必要な技術リソースが利用可能であることを確認十分な ( リーズナブルな ) 時間を確保する作業に適したツールを選択するあなたの移行プロジェクトがうまくいきますように!

31 アジェンダ RDS から DynamoDB への移行はいかにして RDS から DynamoDB に移行したかテーブルデザインチャレンジテーブルデザインのリファクタリング Amazon DynamoDB を選択した理由学びとポイント

32 RDS から DynamoDB への移行 1. 計画非定型データを格納しているテーブルは移行の有力な候補例 : Entity-Attribute-Value, Logging tables 2. データの分析 3. データモデリングテーブル / プライマリーキー / セカンダリインデックストランザクションやロックはどうする? 4. テスト 5. 移行 S3 にエクスポートし DynamoDB にインポートする最新の AWS Database Migration Service ではターゲットとして DynamoDB をサポート AWS Innovate: Best Practices for Migrating to Amazon DynamoDB - Sangpil Kim

33 2012 年に設立された韓国のスタートアップスマートフォンのロック画面に広告を配信韓国や米国日本台湾を含む 6 ヵ国でサービス提供 2013 年 Softbank Ventures より 40 億ウォン ($3.4M) の投資を受け 130 億ウォン ($11.05M) の投資を集めるまでに成長ユーザー数 1,200 万 60 Buzzvillians ポイントシステムスワイプするとポイント

34 01 ポイントシステムの要件必須様々なポイントのタイプポイントの追加通常のポイントポイントの利用広告ポイントポイントの残高紹介ポイントポイントの履歴購入をシェアすることで得られるポイントオプションオペレーターにより追加されるポイントポイントの履歴... N ヶ月以上利用されていないポイント特定のタイミングでのポイント残高 Copyright c All Right Reserved by Buzzvil 34

35 02 ポイントテーブルデザイン Impression point table user_id amount type title campaign_id date 1 2 landing xxx unlock xxx Invite point table user_id amount type title related_user_id date inviter xxx invitee xxx Manual point table user_id amount title date xxx xxx N 個のテーブル N 個のテーブルにクエリを実行しユーザーのポイント獲得履歴を作成 Copyright c All Right Reserved by Buzzvil 35

36 02 ポイントテーブルデザイン point_sum table user_id deposit_sum withdraw_sum point_sum table がユーザーごとのポイントを管理 user_id はユニークキー current_point_sum Deposit points の合計 = deposit_sum Deduction points の合計 = withdraw_sum Current_point_sum = deposit_sum - withdraw_sum 現時点でのポイント残高だけではなくこれまでに獲得した総ポイントや利用した総ポイントを算出可能 Copyright c All Right Reserved by Buzzvil 36

37 02 ポイントテーブルデザイン No. 22 ユーザーに 10 ポイント追加 begin transaction insert into imp_point (user_id, amount) values (22, 10) update point_sum set deposit_sum = deposit_sum + 10 where user_id = 22 commit No. 22 ユーザーが 300 ポイント利用 begin transaction insert into withdraw_point (user_id, amount) values (22, 300) update point_sum set withdraw_sum = withdraw_sum where user_id = 22 commit Copyright c All Right Reserved by Buzzvil 37

38 02 ポイントテーブルデザインチャレンジトランザクションにもかかわらず N point table と point_sum table とのあいだで一貫性が維持されないポイントタイプごとにたくさんのテーブルがあり管理しにくい複数のテーブルを操作しなければならないためポイント履歴を生成するクエリが遅い特定のタイミングでのポイント残高を算出することができないポイント利用における同時リクエストでポイントの赤字が発生しうる Copyright c All Right Reserved by Buzzvil 38

39 03 ポイントシステムのリファクタリング General point table user_id amount title type sub_type refer_key date extra deposit_sum withdraw_sum xxx imp l {"abc": "def"} xxx action xxx xxx withdraw store {"pid": 123} xxx action xxx invite invitee ポイントテーブルを一本化することで複数のテーブル管理を不要に Schema : user_id, amount, type, date,, extra (JSON) point_sum table も統合通帳のような形で deposit_sum/withdraw_sum を管理特定の時点でのポイント残高を提示可能に Copyright c All Right Reserved by Buzzvil 39

40 03 ポイントシステムのリファクタリング General point table user_id amount title type sub_type refer_key date extra deposit_sum withdraw_sum xxx imp l {"abc": "def"} ポイント追加 new_point.amount = 4 new_point.deposit_sum = last_point.deposit_sum + new_point.amount new_point.withdraw_sum = last_point.withdraw_sum new_point.save() 10 ポイント利用 new_point.amount = -10 new_point.deposit_sum = last_point.deposit_sum new_point.withdraw_sum = last_point.withdraw_sum + new_point.amount if new_point.deposit_sum + last_point.withdraw_sum < 0 then raise exception new_point.save() Copyright c All Right Reserved by Buzzvil 40

41 03 ポイントシステムのリファクタリング General point table user_id amount title type sub_type refer_key date extra deposit_sum withdraw_sum xxx imp l {"abc": "def"} 原子性特定のユーザーに対する同時ポイント追加が発生したら? last_point.deposit_sum = 10 とします new_point_1.deposit_sum = last_point.deposit_sum + 4 new_point_2.deposit_sum = last_point.deposit_sum + 2 deposit_sum は 16 であるべきですが new_point_1 および new_point_2 の実行タイミングによっては 14 や 12 になります Copyright c All Right Reserved by Buzzvil 41

42 03 ポイントシステムのリファクタリング楽観的ロック同時更新を防止バージョン列を追加し変更ごとに 1 加算更新に際してはバージョン列に 1 加算し同じバージョンが存在するかチェックした上で更新を実行 lock/unlock と比較して競合を処理するのが効率的たとえば共通のオブジェクトに対する複数の更新が発生した場合どちらかの更新は適用されないよう制御することが可能 Copyright c All Right Reserved by Buzzvil 42

43 03 ポイントシステムのリファクタリング POINT SYSTEM プライマリーキーとして user_id/version を試用することでユーザー間で同じバージョン番号が発生することを防止ポイントを保存する際にバージョン番号に 1 加算 Pseudo code last_point = Point.objects.filter(user_id=123).last() new_point.user_id = 123 new_point.amount = 10 new_point.deposit_sum = last_point.deposit_sum + 10 new_point.withdraw_sum = last_point.withdraw_sum new_point.version = last_point.version + 1 new_point.save() Run from the start when integrity exception error occurs in save() Copyright c All Right Reserved by Buzzvil 43

44 03 ポイントシステムのリファクタリング General point table (Final) user_id amount title type sub_type refer_key date extra deposit_sum withdraw_sum version xxx imp l {"abc": "def"} xxx action xxx xxx withdraw store {"pid": 123} xxx action xxx invite invitee last_point item の次のバージョンとして new_point item が作成されることを保証 Copyright c All Right Reserved by Buzzvil 44

45 04 AMAZON DYNAMODB DynamoDB を points table に採用 MySQL での実装も可能スケーラビリティおよび容易な管理の観点で Amazon DynamoDB の採用を決定 DynamoDB が提供するリニアなスケーラビリティパーティションキーソートキーおよび条件付き更新による楽観的ロックの実装が可能統計データ DynamoDB ではアグリゲーションクエリが実行できない日付でソートされたグローバルセカンダリインデックスを追加し Redshift に移動 DIY / Kinesis Firehose で S3 に書き出し Redshift にロード Copyright c All Right Reserved by Buzzvil 45

46 04 AMAZON DYNAMODB DynamoDB の利点完全なマネージドサービススケールアウトアーキテクチャ平均レスポンスタイムが 5ms 以内 Reserved Capacity によるコスト削減 ( 最大 76%) すべてのテーブルに Reserved Capacity を適用容易な管理 DynamoDB の考慮点コストは利用方法によって異なるパーティショニングの動作を理解していない場合プロビジョニングされたスループットキャパシティをうまく生かすことができない Copyright c All Right Reserved by Buzzvil 46

48 詳しくは aws.amazon.com/dms Thank you!

データベースの近代化：シンプルなクロスプラットフォーム、最小のダウンタイムで実現するクラウド移行

データベースの近代化：シンプルなクロスプラットフォーム、最小のダウンタイムで実現するクラウド移行 AWS Database Migration Service ダウンタイムを最小限に抑えたデータベースモダナイゼーション John Winford Sr. Technical Program Manager May 31, 2017 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved. アジェンダクラウドはどのように役立つか?