[Aws]database migration seminar_20191008

Page.1©IPG inc. All Rights Reserved.
株式会社IPG 開発部 TPMチーム兼ITチームチームリーダー⽊村徹
AWS DMSを活⽤した異種データベース間の
継続的レプリケーション

CHAPTER 0 / ⾃⼰紹介
⽊村徹 Toru Kimura
• 株式会社IPG
• 2006年からIPGに参画
• Technical Program Manager
• 番組情報基幹システム(minds)および機械学習
プロジェクトの開発チームリーダー
• ⾮エンジニア

CHAPTER 0 / アジェンダ
AGENDA
1. IPGについて
2. AWS DMSを選んだ理由
3. AWS DMSを使ってみる
4. AWS DMSを導⼊する
5. まとめ
6. 今後の改善
※ AWS Database Migration Service 以降資料上では、AWS DMS、DMSと略させて頂きます。

CHAPTER 1
IPGについて

CHAPTER 1 / IPGについて
Gガイド受信機（TV／レコーダー／セットトップBOX）
放送型Gガイド
AD
シンジケーテッドGガイド
メーカースマホ/タブレット向け対応アプリ
3キャリア標準プリイン
通信型Gガイド
株式会社IPG
設⽴：1999年4⽉22⽇主要株主：電通、TiVo Corporation、東京ニュース通信社
電⼦番組表（EPG）サービス「Gガイド」のサービス企画、開発、運⽤

⾒る・聴く・楽しむコンテンツと⼈々との最適な
コミュニケーションを担うインフラになる

mindsの仕組み
minds
ウェブ
モバイル
テレビ
コンテンツ
全国放送局
番組情報

mindsで取り扱うデータ
番組情報
250,000番組/⽇
放送局
200局 1,000ch
プラットフォーマー
10社
バッチプログラム
40本
オペレーションUI
10本
APIサービス
40本
テレビ
56,000,000台
モバイル
2,000,000MAU
ウェブサービス
140,000,000PV

minds構成図
• データベースエンジンには、Oracleを
採⽤
• システム連携、ユーザ⼊⼒など、⼊り
組んだ構成となっている
• オンプレの構成そのままAWS化

1. システムが密結合となっていて変更に対
する影響範囲が⼤きい
2. 社内にOracleに精通しているエンジニア
が少ない
現状の課題

CHAPTER 2
AWS DMSを選んだ理由

CHAPTER 2 / AWS DMSを選んだ理由
1. トライ&エラーのできる新たな環境
2. Oracleからの脱却
3. 既存のシステムは、安定的に維持
要件の整理

• 同種のデータベース間での移⾏
• データベースの異種間移⾏
• 開発とテスト
• データベースの統合
• 継続的なデータレプリケーション
DMSとの出会い
DMS活⽤にあたってのポイント
CHAPTER 2 / AWS DMSを選んだ理由

CHAPTER 3
AWS DMSを使ってみる

• AWS Summitへの参加
• ソリューションアーキテクトへの構成相談
• ハンズオンの活⽤
• AWS Cloud Formation を使って環境を⾃動⽣成
• AWS Schema Conversion Tool（SCT）を使ったスキーマ変換
• DMSのセットアップと実⾏
Ø AWS アカウントを持っていれば1時間程度で習得可能
DMSの理解を深める
AWSイベントの活⽤
CHAPTER 3 / AWS DMSを使ってみる

ターゲットデータベースを決める
AWS Schema Conversion Toolによる検証
• Oracle からの移⾏先として、
機能互換性の観点から⼀般的には
PostgreSQL が選ばれるケースが
多い
• ⼀⽅で、社内でよく利⽤していたデー
タベースエンジンは、MySQL
• 移⾏対象の Oracle データベースを
AWS Schema Conversion Tool
（SCT）でチェック
• それぞれのエンジンの互換性を確認

ステージングシステムで試してみたところ、以下の問題が顕在化しました。
A) フルロード時にソースデータベース(Oracle) の負荷が上がること
で業務影響が発⽣
B) フルロードが、10時間を経過しても終わらない
実際に試す
ステージング環境を使って、DMSを実施

A) フルロード時にソースデータベース(Oracle) の負荷が上がることで業務影
響が発⽣
Ø 原因として、ソースデータベースの Read Throughput が上がったことで、
Network 帯域の上限に達し影響を及ぼしたことが判明
B) フルロードが、10時間を経過しても終わらない
Ø 原因としては、以下の3点が影響していることが判明
I. テーブルマッピングを明⽰的に指定しなかったため、テンポラリのテーブルなども⾃動
で作成されターゲットテーブルでエラーになっていた
II. AWS SCTで⾃動作成されるスキーマは、外部キーやインデックスが設定されたままのた
め、フルロードの⻑時間化を引き起こしていた
III. ターゲットデータベースのインスタンスサイズが、⼩さかったため書き込みにかかる処
理速度に影響を与えた

ステージングで問題が顕在化したことで、改めて以下整理の上、導⼊構成の検討
1. 既存の Oracle 環境は、システム停⽌や構成変更が容易には⾏えないため、Oracle 環境
には最低限の影響で実⾏ができる必要がある
2. フルロードの時間が短くすることは、障害復旧におけるRTO（Recovery Time
Objective）を短くし、サービスレベルを向上させる
3. インフラは、ダブルコストになる。新しい環境は、できる限り最低限のインフラ構成
でランニングコストを抑える
DMS導⼊にあたって
問題の整理

CHAPTER 4
AWS DMSを導⼊する

1. 移⾏テーブルの明⽰化
2. ターゲットデータベースでの外部キーとインデック
スの調整
3. ソース/レプリケーション/ターゲットのそれぞれの
インスタンスサイズの調整
CHAPTER 4 / AWS DMSを導⼊する
DMS導⼊にあたって
アクションの決定

データ量調整所要時間
無し 12 時間
有り 7 時間
アクション.1
移⾏テーブルの明⽰化
• ソースデータベースのデータ量としては、約 500 テーブル/ 約 15 億⾏のデー
タが存在
• サービス利⽤に必要なテーブルを選別することで、約 160 テーブル/ 約 3.5 億
⾏に削減
• 移⾏タスクに設定する Mapping rule で、すべてのテーブルに対してルールを
作成し、各テーブルの “rule-action” に "include"（移⾏する） or "exclude"
（移⾏しない）を明⽰的に設定
データ調整有/無時のフルロード時間

実⾏⽅法所要時間
インデックスを付けたままのフルロード 12時間
実⾏⽅法所要時間
インデックスをすべて外してフルロード 5 時間
インデックスをすべてに付与（8プロセス並列） 13 時間
アクション.2
ターゲットデータベースでの外部キーとインデックスの調整
• フルロード時間を約半分以下に削減したが、フルロード後に外部キー制約及びイ
ンデックスを付け直すための時間に、フルロードにかかる時間以上にかかった
• 1テーブルあたりの⾏数が少ないケースでは有⽤かもしれない。
• 今回は外部キー制約及びインデックスを付けたままフルロードを実施

アクション.3
ソース/レプリケーション/ターゲットのそれぞれの
インスタンスサイズの調整
• フルロード時は、⼤きなインスタンスサイズでフルロードにか
かる時間を短縮
• 差分適⽤であるCDC（Change Data Capture）では、必要最⼩
限のインスタンスサイズで構成
※ ただし、本番 Oracle環境のインスタンスの停⽌も構成変更もできない

① フルロード専⽤インスタンスの⽴ち上げ
② フルロード専⽤インスタンスからフルロード
③ インスタンスサイズの変更
④ CDCタスクの実⾏

① 本番 Oracle から Snapshot を取得してフルロード専⽤ Oracleインスタンスと
して復元
ü Snapshotの作成時刻を記録する（コンソールから確認）
ü 復元したフルロード専⽤ Oracleインスタンスは、既存業務系に接続しない
ü フルロード専⽤ oracleインスタンスのインスタンスサイズは⼤きなサイズ
で復元する

② フルロード専⽤ Oracle インスタンスをソースデータベースとしてフル
ロードタスクを実⾏
ü レプリケーション/ターゲットデータベースインスタンスのインス
タンスサイズは⼤きなサイズを選択する
ü タスク設定の移⾏タイプ（Migration type）は、既存のデータを
移⾏する（Migrate existing data）を指定する

③ フルロード完了後、インスタンスサイズの変更
ü フルロード専⽤ Oracle インスタンスは削除
ü レプリケーション/ターゲットデータベースインスタンスの
インスタンスサイズをスケールダウン

④ 本番 Oracle をソースデータベースとして、CDCタスクを実⾏
ü ①で取得したSnapshot作成時刻から、SCN（System Change
Number）を割り出す
ü CDC開始モード（CDC Start mode）に、ログシーケンス番号の指定
（Specify log sequence number）を選択し、 SCN をセットする
ex)
SELECT timestamp_to_scn(to_timestamp('16/04/2019 13:46:51','DD/MM/YYYY HH24:MI:SS')) as scn from dual;
SCN
------------
12345678

インスタンスサイズ所要時間
ソースデータベース:
レプリケーションインスタンス:
ターゲットデータベース:
large
large
large
7時間36分
2xlarge
2xlarge
2xlarge
2時間30分
4xlarge
4xlarge
4xlarge
1時間46分
各インスタンスサイズとフルロード時間

継続的に運⾏する
トラブルに強くするには？
l ソースデータベース
• REDOログのサイズ調整
• オンラインREDOログ ※ REDOログサイズの調整⽅法はこちら
• アーカイブログ ※ アーカイブログ期間の調整⽅法はこちら
l 監視メトリクス
• DMSタスクログのエラー監視
• CDCレイテンシーソース
• CDCレイテンシーターゲット
• DMSタスクの稼働状態
l マルチAZ
• 通常運⾏時は、ソース／レプリケーション／ターゲットを同ゾーンで運⾏
ex)
aws dms describe-replication-tasks --filters "Name=replication-task-arn,Values=${taskarn}" --query "ReplicationTasks[0].{Status: Status}"
{
"Status": "running"
}

CHAPTER 5
まとめ

ü 既存環境にフルロード時の負荷を与えない。
ü フルロード時に、インスタンスのリソースを多く取り、フル
ロードタスクを短い時間で実⾏することで、RTOを短くする
ü CDC時には、最低限のインスタンスサイズに変更することで、
ランニングコストを最⼩限に抑える
CHAPTER 5 / まとめ
まとめ

CHAPTER 5 / まとめ
minds構成図

CHAPTER 6
改善に向けて

u CDCのスタートポイントが曖昧
Ø CDC の開始位置は SCN で指定することが可能です。
現状は Oracle データベースの Snapshot を取得したタイミングの
SCN を特定することができません。
そのため、Snapshot の取得時間から、 SCN を特定しているのですが、
秒オーダーの精度なので、そのタイミングでの発⽣した更新の状態が
不定になり、データの消失やデータ重複が発⽣し得ます。
CHAPTER 6 / 今後の改善
改善ポイント

募集職種
機械学習.アプリ.インフラ. etc…
わたしたちが求める⼈材
• ⽣涯エンジニアを希望している⼈。
• 何事も「変化すること」を前提に、変化を受け⼊れ、柔
軟に物事を進める事ができる⼈。
• 常に新しい技術分野にチャレンジし、良い物はチームや
世間に広げたい⼈。
• ユーザーファーストで物事を思考している⼈。
• チームワークを⼤事にしている⼈。
• 効率化のために何でも⾃動化したくなる⼈。
気軽にオフィスに遊びに来てください！
ご連絡はこちら（https://ipg.co.jp/recruit/）まで
IPGでは、エンジニアを募集しています

[Aws]database migration seminar_20191008

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a [Aws]database migration seminar_20191008

Similar a [Aws]database migration seminar_20191008 (20)

Último

Último (8)

[Aws]database migration seminar_20191008