Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
© 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万データベースを移行し、さらに増え続けています……
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対応済み
データベース移行 – 複数フェーズの手順
フェーズ 内容 自動化 工数 (%)
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
ステップ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)があるか?
大きなトランザクションの実行有無
タスクを適切に構成する
大きな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 個のテーブルにクエリを実行しユー
ザーのポイント獲得履歴を作成
ポイントテーブルデザイン 02
36 Copyright ⓒ All Right Reserved by Buzzvil
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
● 現時点でのポイント残高だけではなく、これまでに獲得した総
ポイントや利用した総ポイントを算出可能
ポイントテーブルデザイン 02
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
Copyright ⓒ All Right Reserved by Buzzvil
ポイントテーブルデザイン 02
38
● チャレンジ
○ トランザクションにもかかわらず N point table と
point_sum table とのあいだで 一貫性 が維持されない
○ ポイントタイプごとにたくさんのテーブルがあり管理しにくい
○ 複数のテーブルを操作しなければならないためポイント履歴を
生成するクエリが遅い
○ 特定のタイミングでのポイント残高を算出することができない
○ ポイント利用における同時リクエストでポイントの赤字が発生
しうる
Copyright ⓒ All Right Reserved by Buzzvil
ポイントシステムのリファクタリング 03
39 Copyright ⓒ All Right Reserved by Buzzvil
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 を管理
○ 特定の時点でのポイント残高を提示可能に
ポイントシステムのリファクタリング 03
40 Copyright ⓒ All Right Reserved by Buzzvil
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
○ new_point.save()
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
ポイントシステムのリファクタリング 03
41 Copyright ⓒ All Right Reserved by Buzzvil
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
ポイントシステムのリファクタリング 03
42 Copyright ⓒ All Right Reserved by Buzzvil
● 楽観的ロック
○ 同時更新を防止
○ バージョン列を追加し、変更ごとに 1 加算
○ 更新に際しては、バージョン列に 1 加算し、同じバー
ジョンが存在するかチェックした上で更新を実行
○ lock/unlock と比較して競合を処理するのが効率的
○ たとえば、共通のオブジェクトに対する複数の更新が発
生した場合、どちらかの更新は適用されないよう制御す
ることが可能
ポイントシステムのリファクタリング 03
43 Copyright ⓒ All Right Reserved by Buzzvil
● 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()
ポイントシステムのリファクタリング 03
44 Copyright ⓒ All Right Reserved by Buzzvil
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
45 Copyright ⓒ All Right Reserved by Buzzvil
● DynamoDB を points table に採用
○ MySQL での実装も可能
○ スケーラビリティおよび容易な管理の観点で Amazon
DynamoDB の採用を決定
○ DynamoDB が提供するリニアなスケーラビリティ
○ パーティションキー、ソートキーおよび条件付き更新による楽観的
ロックの実装が可能
● 統計データ
○ DynamoDB ではアグリゲーションクエリが実行できない
○ 日付でソートされたグローバルセカンダリインデックスを追加し
Redshift に移動
○ DIY / Kinesis Firehose で S3 に書き出し Redshift にロード
46 Copyright ⓒ All Right Reserved by Buzzvil
● DynamoDB の利点
○ 完全なマネージドサービス
○ スケールアウト アーキテクチャ
○ 平均レスポンスタイムが 5ms 以内
○ Reserved Capacity によるコスト削減(最大 76%)
○ すべてのテーブルに Reserved Capacity を適用
容易な管理
● DynamoDB の考慮点
○ コストは利用方法によって異なる
○ パーティショニングの動作を理解していない場合、プロビジョ
ニングされたスループットキャパシティをうまく生かすことがで
きない
AMAZON DYNAMODB 04
47 Copyright ⓒ All Right Reserved by Buzzvil
● まとめ
○ Buzzvil は DynamoDB を積極的に利用しています
○ MySQL を 100% 置き換えるものではありません。
大量のトラフィックや素早いレスポンスが必要とされる部分で
DynamoDB を利用しています。
AMAZON DYNAMODB 04