データベース移行のベストプラクティス · 7/5/2017 ·...

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

July 5, 2017

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

John Winford, Sr. Technical Program Manager

アジェンダ

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

製品の概要

DMSとSCTとは何か

AWS Database Migration Service (DMS) は簡単かつセキュアにデータベースとデータウェアハウスを AWSへ移行およびレプリケーションします

AWS Schema Conversion Tool (SCT) は商用データベースとデータウェアハウスのスキーマをオープンソースのエンジンや、 AuroraやRedshiftのようなAWSネイティブサービス用に変換します

すでに3万データベースを移行し、さらに増え続けています……

DMSとSCTをいつ使うか

モダナイズ移行レプリケーション

SCTをいつ使うか

モダナイズ

データベース層のモダナイズ

既存データウェアハウスの

モダナイズと

Amazon Redshift への移行

Amazon Aurora

Amazon Redshift

DMS*をいつ使うか

移行

• ビジネスクリティカル

アプリケーションの移行

• クラッシック環境からVPCへの移行

• データウェアハウスの

Redshiftへの移行

• マイナーバージョンへの

アップグレード

• Auroraへの統合

• NoSQLからSQL、SQLからNoSQL、

NoSQLからNoSQLへの移行

Sources:

Targets:

Amazon Dynamo DB

Amazon Redshift

Amazon S3

Amazon Aurora

*DMSはHIPAA対応済み

DMSをいつ使うか

レプリケーション • クロスリージョンレプリカの作成

• クラウドでの分析実行

• 開発/テスト環境と本番環境の

同期の維持

移行手順

データベース移行 – 複数フェーズの手順

フェーズ内容自動化工数 (%)

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

ステップ0 – 担当者

深いデータベースの知識が必要

• 1つのエンジンだけでは不十分かも

深いネットワークの知識が必要

AWSの知識が必要

ソフトウェアアーキテクチャの知識が一般的には必要

ステップ1 – マニュアルを読む

ご利用開始にあたって

FAQ

ベストプラクティス

フォーラム

ブログ

手順書とデモ

ステップ2 – スケジュール計画

移行プロジェクトは数週間から数カ月を要する可能性がある

何度か繰り返す可能性がある

予想より遅くなる可能性がある

移行が完了すべき日程は厳しい？

計画は移行自体より長くなる可能性がある

ステップ3 – データベースを理解する

データベースの容量はいくつ？

いくつのスキーマとテーブルがある？

非常に大きなテーブルはいくつある？

トランザクション境界はどうなっている？

DMSがサポートしていないエンジン固有の機能を使っている？

テーブルにLOBは含まれている？それの大きさは？

LOBを含むテーブルにPKはついている？

ソースデータベースはどのように使われる？

ソースデータベースにはどのようなユーザー/ロール/権限がある？

いつデータベースをバキューム/コンパクト化した？

ステップ4 – ネットワークを理解する

どのようにデータベースにアクセスできる？（ファイアウォール、トンネル、VPN）

どのVPCを使うべき？

どのセキュリティグループを使うべき？

全データを移動するための十分な帯域はある？

ステップ5 – 要件を理解する

ダウンタイムは許容されるか？

移行後もソースDBをメンテナンスする必要があるか？

ターゲットDBのエンジンをそれに決めた理由は？

高可用性要件は？

全てのデータを移行する必要があるか？

全てを同じ場所に置く必要があるか？

RDSのメリットは理解しているか？（自動バックアップ、HA、等々）

RDSの制約は理解しているか？（ストレージ容量、管理者権限、等々）

関連アプリケーションへの影響を把握しているか？

万一の際の切り戻しのプランは出来ているか？

ステップ6 – ターゲットスキーマ

DMSはテーブルと主キーのみ作成する

SCT – Schema Conversion Tool （＝スキーマ変換ツール）

• 同一エンジン間ではほぼ全てのスキーマオブジェクトをコピー

• 異種エンジン間ではスキーマオブジェクトを変換

• オーケストレーションは現時点では非対応

• 同一エンジン間移行であれば標準のネイティブツールを使う手も

スキーマ変更は移行が終わってから行う

準備は良いですか？まずは小さなDBでテストしましょう

CloudWatchのログを確認することを怠らない

適切なインスタンスタイプを選択（ヒント：t2.microは選ばない）

ソースDB上で移行前に必要な設定は終わっていますか？

移行開始！

ある程度時間がかかります

稼働状況を監視

ログを確認

• エラー有無を確認

• 切り捨てられた行がないか確認

• 移行に注意が必要なデータ型がきちんと移行されているか確認

• キャラクタセットの関係で文字化けやデータ破損が発生していないか？

期待されることは？

移行時間に影響を与える要素

ソースDBのサイズと負荷

ターゲットDBのサイズ

利用可能なネットワーク帯域

レプリケーションインスタンスのサイズ

スキーマ構造（1つの巨大なテーブルと他の小さなテーブルで構成されているようなケースでは時間がかかる）

スキーマにラージオブジェクト(LOB)があるか？

大きなトランザクションの実行有無

タスクを適切に構成する

監視

CloudWatch Logsを活用

コンソール上でタスク監視とテーブル

統計をウォッチする

他のツール

ネイティブなレプリケーションが向くケース

ターゲットがネイティブなレプリケーション形式に対応できる

全てのデータを移行する

スキーマやデータの変換が必要ない

ターゲットが新しいDBである

ダンプ＆リストアが向くケース

DBサイズがさほど大きくない

ダウンタイムが許容可能（ダンプ＋転送＋リストア）

ソースDBの全てのデータを移行する

スキーマやデータ型の変換が必要ない

大きなDBの扱い

「大きい」とは？

• 全てのデータ移行が、許容される移行時間内に終わらない可能性がある

• 5TBが一つの目安だが、それより大きくてもDMSで十分移行できる場合もあれば、逆に小さくても多くの時間がかかるケースもある

大きなデータセット

使用中のデータウェアハウスからデータを抽出し、Amazon Redshiftへ移行

• ローカルマイグレーションエージェントを使って

データを抽出

• データはRedshift向けに最適化され、ローカル

ファイルとして保存される

• ファイルはAmazon S3バケットに保存し（ネット

ワーク or Snowball経由）、Redshiftにロードす

る

Amazon

Redshift AWS SCT S3 Bucket

まとめ

まとめ

データベース移行は複雑

AWSが提供するツール群で、約50%の作業は自動化可能

環境を知る（現在の環境と新環境）

必要な技術リソースが利用可能であることを確認

十分な（リーズナブルな）時間を確保する

作業に適したツールを選択する

あなたの移行プロジェクトがうまくいきますように！

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

July 6, 2017

Buzvill 事例から

Sangpill Kim, Solutions Architect AWS Korea

RDS から DynamoDB への移行における考慮点

アジェンダ

RDS から DynamoDB への移行

はいかにして RDS から DynamoDB に移行したか • テーブルデザイン

• チャレンジ

• テーブルデザインのリファクタリング

• Amazon DynamoDB を選択した理由

• 学びとポイント

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

https://www.slideshare.net/awskorea/aws-innovate-best-practices-for-migrating-to-amazon-dynamodb-sangpil-kim



























• 2012 年に設立された韓国のスタートアップ

• スマートフォンのロック画面に広告を配信

韓国や米国、日本、台湾を含む 6 ヵ国でサービス提供

• 2013年 Softbank Ventures より 40億ウォン ($3.4M) の投資を受け、130億ウォン ($11.05M)の投資を集めるまでに成長

• ユーザー数 1,200万

• 60 Buzzvillians

• ポイントシステム

– スワイプするとポイント

ポイントシステムの要件 01

34

● 必須

○ ポイントの追加

○ ポイントの利用

○ ポイントの残高

○ ポイントの履歴

● オプション

○ ポイントの履歴

○ N ヶ月以上利用されていな

いポイント

○ 特定のタイミングでのポイ

ント残高

Copyright ⓒ All Right Reserved by Buzzvil

● 様々なポイントのタイプ

○ 通常のポイント

○ 広告ポイント

○ 紹介ポイント

○ 購入をシェアすることで得られるポイント

○ オペレーターにより追加されるポイント

○ ...

ポイントテーブルデザイン 02

35 Copyright ⓒ All Right Reserved by Buzzvil

Impression point table user_id amount type title campaign_id date

1 2 landing xxx 123 2017-12-12

2 4 unlock xxx 333 2017-12-13

user_id amount type title related_user_id date

3 300 inviter xxx 2 2017-12-12

2 300 invitee xxx 3 2017-12-13

Invite point table

user_id amount title date

3 300 xxx 2017-12-12

2 300 xxx 2017-12-13

Manual point table ● N 個のテーブル

● N 個のテーブルにクエリを実行しユー

ザーのポイント獲得履歴を作成



point_sum table user_id deposit_sum withdraw_sum

1 10000 5000

2 20000 0

● point_sum table がユーザーごとのポイントを管理

● user_id はユニークキー

● current_point_sum

○ Deposit points の合計 = deposit_sum

○ Deduction points の合計 = withdraw_sum

○ Current_point_sum = deposit_sum - withdraw_sum

● 現時点でのポイント残高だけではなく、これまでに獲得した総

ポイントや利用した総ポイントを算出可能


37

● 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 + 300

where user_id = 22

○ commit



38

● チャレンジ

○ トランザクションにもかかわらず N point table と

point_sum table とのあいだで一貫性が維持されない

○ ポイントタイプごとにたくさんのテーブルがあり管理しにくい

○ 複数のテーブルを操作しなければならないためポイント履歴を

生成するクエリが遅い

○ 特定のタイミングでのポイント残高を算出することができない

○ ポイント利用における同時リクエストでポイントの赤字が発生

しうる


ポイントシステムのリファクタリング 03


General point table user_id amount title type sub_type refer_key date extra deposit_sum withdraw_sum

2 1000 xxx imp l 123 2017-12-12 {"abc": "def"} 1000 0

2 200 xxx action xxx 333 2017-12-13 1200 0

2 -300 xxx withdraw store1 2 2017-12-13 {"pid": 123} 1200 -300

2 100 xxx action 22 2 2017-12-14 1300 -300

2 100 xxx invite invitee 23 2017-12-14 1400 -300

● ポイントテーブルを一本化することで複数のテーブル管理を不要に

● Schema : user_id, amount, type, date,…, extra (JSON)

● point_sum table も統合

○ 通帳のような形で deposit_sum/withdraw_sum を管理

○ 特定の時点でのポイント残高を提示可能に



General point table

● 4 ポイント追加 ○ 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


user_id amount title type sub_type refer_key date extra deposit_sum withdraw_sum

2 1000 xxx imp l 123 2017-12-12 {"abc": "def"} 1000 0



General point table

●原子性

○ 特定のユーザーに対する同時ポイント追加が発生したら?

○ 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 になります

user_id amount title type sub_type refer_key date extra deposit_sum withdraw_sum

2 1000 xxx imp l 123 2017-12-12 {"abc": "def"} 1000 0



● 楽観的ロック

○ 同時更新を防止

○ バージョン列を追加し、変更ごとに 1 加算

○ 更新に際しては、バージョン列に 1 加算し、同じバー

ジョンが存在するかチェックした上で更新を実行

○ lock/unlock と比較して競合を処理するのが効率的

○ たとえば、共通のオブジェクトに対する複数の更新が発

生した場合、どちらかの更新は適用されないよう制御す

ることが可能



● 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


○ Run from the start when integrity exception error occurs in save()



General point table (Final)

user_id amount title type sub_type refer_key date extra deposit_sum withdraw_sum version

2 1000 xxx imp l 123 2017-12-12 {"abc": "def"} 1000 0 1

2 200 xxx action xxx 333 2017-12-13 1200 0 2

2 -300 xxx withdraw store1 2 2017-12-13 {"pid": 123} 1200 -300 3

2 100 xxx action 22 2 2017-12-14 1300 -300 4

2 100 xxx invite invitee 23 2017-12-14 1400 -300 5

● last_point item の次のバージョンとして new_point

item が作成されることを保証

AMAZON DYNAMODB 04


● DynamoDB を points table に採用

○ MySQL での実装も可能

○ スケーラビリティおよび容易な管理の観点で Amazon

DynamoDB の採用を決定

○ DynamoDB が提供するリニアなスケーラビリティ

○ パーティションキー、ソートキーおよび条件付き更新による楽観的

ロックの実装が可能

● 統計データ

○ DynamoDB ではアグリゲーションクエリが実行できない

○ 日付でソートされたグローバルセカンダリインデックスを追加し

Redshift に移動

○ DIY / Kinesis Firehose で S3 に書き出し Redshift にロード


● DynamoDB の利点

○ 完全なマネージドサービス

○ スケールアウトアーキテクチャ

○ 平均レスポンスタイムが 5ms 以内

○ Reserved Capacity によるコスト削減（最大 76％）

○ すべてのテーブルに Reserved Capacity を適用

容易な管理

● DynamoDB の考慮点

○ コストは利用方法によって異なる

○ パーティショニングの動作を理解していない場合、プロビジョ

ニングされたスループットキャパシティをうまく生かすことがで

きない

AMAZON DYNAMODB 04


● まとめ

○ Buzzvil は DynamoDB を積極的に利用しています

○ MySQL を 100％置き換えるものではありません。

大量のトラフィックや素早いレスポンスが必要とされる部分で

DynamoDB を利用しています。

AMAZON DYNAMODB 04

Thank you!

aws.amazon.com/dms

詳しくは…

データベース移行のベストプラクティス · 7/5/2017 ·...

Documents