Amazon.com における Oracle データベースの移行 · 2020-05-07 ·...

© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.

Amazon.comにおけるOracle データベースの移行髙橋敏⾏アマゾンウェブサービスジャパンパートナー技術本部パートナーソリューションアーキテクト

Twitterハッシュタグ #AWSInnovate


本セッションについて

セッションの対象者• オンプレミスで Oracle データベースを利⽤されている⽅• データベースのクラウド移⾏に関する事例を知りたい⽅

セッションのゴール• Amazon.com の事例を通して、データベース移⾏の課題と解決のポイントを知ることが出来る

今回扱う課題リスト• データベース移⾏を検討したいが、何を⾏えば良いか分からない• データベース移⾏に関する事例を知りたい

【ご連絡事項】本セッション内容について確認するためのクイズおよび簡単なアンケートがセッションの最後にあります。なおクイズの回答はアンケートとあわせて表⽰されます。


アジェンダ• イントロダクション︓

• Amazon のレガシーデータベース基盤

• データベースにおける課題と解決策

• データベースを移⾏した理由

• Amazon の移⾏戦略と効果

• まとめ

• クイズ



はじめに


インターネット

Oracle database

Apps/Web server

配送センター

Single Server

システムの変遷



Oracle database

Apps/Web server

配送センター銀⾏クレジットカード処理

Single Server



Single Server


Oracle database

Apps/Web server

配送センター銀⾏クレジットカード処理



Internet

Oracle databaseOrdering

配送センター

銀⾏

クレジットカード処理 Oracle

database

Oracle database



データベースのスケーラビリティの課題

Application Database



Application Database#1

スケールアップ

Database#2





Database#2





Database#2 Database#3



データベースシャーディング

Application

DatabaseShard 1

DatabaseShard 2

Shard_id Customer_id

1 1

1 2

2 3

2 4

Customer_id Invoice_id

1 200

2 500

Customer_id Invoice_id

3 100

4 600


2017年時点のデータベース基盤OLTP データベース• 総データ量 75PB • 約 7,500 OLTP データベース• 100 以上のチームが数千のアプリケーション

で利⽤• 世界中で数百万の受発注、決済等の処理


2017年時点のデータベース基盤OLTP データベース• 総データ量 75PB • 約 7,500 OLTP データベース• 100 以上のチームが数千のアプリケーション

で利⽤• 世界中で数百万の受発注、決済等の処理

Data Warehouse データベース• 総データ量 50PB• テーブル数 75,000 • 600,000 分析ジョブ /⽇• 1,800 チームがデータを公開 /⽇• 3,300 チームがデータを利⽤ /⽇

Oracle RAC

27 クラスタ635 ノード

109,000 以上のディスク


データベースにおける課題


スケールし続けるシステムの管理• プライムデーに対応するためシステム拡張作業に60 週間かかるチーム

もあった• ⼿厚いベンダーサポートを受けてもスケール時の障害リスクが⾼かった• 顧客に優しくない懲罰的なライセンス戦略

トランザクションレートビジネスの拡⼤につれて

増え続けるトランザクシヨン


プライムデーでさらなるスケーラビリティが必要プライムデーによりピークは1年に1回から半年に• 1回のシステム拡張で許容される時間は半分に

プライムデー⾃体の規模の拡⼤• 2015年 9カ国で3,440万点の注⽂• 2019年 18カ国で1億7500万点の注⽂ (Amazonの歴史上、最⼤のイベント)


レイテンシーの改善と運⽤管理コスト• Amazon のビジネスの成⻑スピードに負けない応答スピードの確保が

困難だった

• 指数関数的に増え続けるデータの管理にコストが⾮常にかかっていた

レイテンシー急激に増え続ける膨⼤なデータに対するレイテンシーの向上


HW / SW コストのリスク• HWの価格と可⽤性とのバランスを取ることが難しく、ビジネスのピー

クとHWの調達のタイミングを合わせづらい• SWの価格設定とベンダーの戦略への対応はコストが⾼く管理が困難

リニューアル、HWによって変わる、仮想化に対するライセンス、キャパシティプランニング・・・

CAPEX

HW/SW コスト

Software

ライセンス管理


可⽤性と運⽤管理のリスク• データベースは拡張と縮退、両⽅必要• レガシーシステムの拡張/縮退、運⽤管理に数百⼈• オペレーションは確実・予測可能・計測可能であること• データは常にアクセスできること• データは常に⼀貫性を保つこと

可⽤性と運⽤HW プロビジョニングと

運⽤管理


データベース移⾏を決めた理由1. データ量の増⼤とグローバル市場の拡⼤による

スケーラビリティのリスク2. データ量とトランザクションの増⼤によるレイテンシーのリスク3. HW / SW コストのリスク4. レガシーなコード / アーキテクチャによる可⽤性のリスク5. HWをプロビジョニング・管理する事による運⽤管理のリスク


Amazon の移⾏戦略


移⾏⽅針AWS CloudCorporate

data center

AWS purpose-built データベースOracle データベース

Amazon Aurora Amazon DynamoDB

Amazon Redshift

AWS Database Migration Service

Amazon RDS

Amazon ElastiCache

Corporate data center

AWS Cloud

75PB


移⾏要件

サービス可⽤性100%に近い可⽤性

と必要に応じてスケール出来ること

データ可⽤性すべてのデータが常に利⽤可能で

⼀貫性があること

移⾏時間移⾏期間でも

ダウンタイムなし、もしくは

わずかなダウンタイムで完了すること


戦略#1 可視性の向上 (1/3)適切な KPI や成功の評価基準の設定による移⾏の進捗管理

• 現在の Oracle データベースの数• 新たに実装された Oracle

データベースの数• 移⾏された(廃⽌された)

Oracle データベースの数• データベースの管理者名


戦略#1 可視性の向上 (1/3)適切な KPI や成功の評価基準の設定による移⾏の進捗管理

• 現在の Oracle データベースの数• 新たに実装された Oracle

データベースの数• 移⾏された(廃⽌された)

Oracle データベースの数• データベースの管理者名


戦略#1 可視性の向上 (2/3)データベーススキーマに関するより詳細な情報• Oracle データベースの

インベントリ情報• データベースモジュールの

依存関係• CRUD レポート• データベースオブジェクトの

Owner/Type• DW ジョブと DB 接続情報• Advanced Search 機能• DB 移⾏のバーンダウンチャート• プロジェクトステータス• データベース移⾏のステータス


戦略#1 可視性の向上 (2/3)データベーススキーマに関するより詳細な情報• Oracle データベースの

インベントリ情報• データベースモジュールの

依存関係• CRUD レポート• データベースオブジェクトの

Owner/Type• DW ジョブと DB 接続情報• Advanced Search 機能• DB 移⾏のバーンダウンチャート• プロジェクトステータス• データベース移⾏のステータス


戦略#1 可視性の向上 (3/3)

SQL Tracker

• 実⾏された全てのSQL⽂をトラックし分析するためのJavaライブラリ

• java.sql.Connection / javax.sql.DataSourceインスタンスのWrapper


戦略#1 可視性の向上 (3/3)

SQL Tracker

• 実⾏された全てのSQL⽂をトラックし分析するためのJavaライブラリ

• java.sql.Connection / javax.sql.DataSourceインスタンスのWrapper

Amazon Simple Storage Service

Amazon Elasticsearch Service

Service APIs

Service A Service B Service C

Amazon Kinesis

Amazon Simple Storage Service

Explain PlanMonitoring

Amazon Elasticsearch Service


戦略#2 FUD と実際の技術的課題に対処• 社内 Oracle DBA からの反発• 移⾏に対する疑念や恐れを表明⇔ 実際の技術的課題とは違う

• 移⾏することによって得られるメリットを考える

• 20 年以上もの間、データベースの移⾏は⾏われてこなかった

• 適応するためには時間が必要なことを理解する

vs

実際の技術的課題

Fear Uncertainly Doubt(恐れ不確実性疑念)


Oracle DBA からの⽀援を得るOracle DBA からの⽀援を得ることで、リスクの緩和、移⾏における依存関係を明確にすることが可能

Oracle DBA に新たなキャリアパスとトレーニングの機会を提供• データベースエンジニア• ソリューションアーキテクト• システム開発エンジニア• DB移⾏スペシャリスト• AWS認定資格者

…

Oracle DBA


Oracle DBA からの⽀援を得るOracle DBA からの⽀援を得ることで、リスクの緩和、移⾏における依存関係を明確にすることが可能

Oracle DBA に新たなキャリアパスとトレーニングの機会を提供• データベースエンジニア• ソリューションアーキテクト• システム開発エンジニア• DB移⾏スペシャリスト• AWS認定資格者

…

Oracle DBA Oracle DBMigrations


戦略#3 フォースマルチプライヤー• フォースマルチプライヤー• 情報共有する事により、スキルを

持ったエンジニアを増やしていく

• AWSの定期的な勉強会の実施• Aurora/RDS, Redshift, DynamoDB, DMS,

…

• リファレンスアーキテクチャ、ベストプラクティス、デザインパターン、Tips の共有


戦略#3 フォースマルチプライヤー• フォースマルチプライヤー• 情報共有する事により、スキルを

持ったエンジニアを増やしていく

• AWSの定期的な勉強会の実施• Aurora/RDS, Redshift, DynamoDB, DMS,

…

• リファレンスアーキテクチャ、ベストプラクティス、デザインパターン、Tips の共有


Oracle から Amazon RDS/Aurora PostgreSQL へ移⾏Corporate data center

Oracle database

AWS Direct Connect

AWS Cloud

Amazon CloudWatch


Amazon AuroraPostgreSQL


Amazon RDSOracle

Amazon CloudWatch

Data Validation

Migration Dashboards

Not yet migrated

Service calls

Migrated

Service calls



Oracle database

AWS Direct Connect

AWS Cloud



Data Validation

Not yet migrated

Service calls

Migrated

Service calls



Oracle database

AWS Direct Connect

AWS Cloud

Amazon CloudWatch




Amazon RDSOracle

Amazon CloudWatch

Data Validation

Migration Dashboards

Not yet migrated

Service calls

Migrated

Service calls


Oracle から PostgreSQL の移⾏における⼀般的課題AWS Blog : 技術的解決⽅法を記載• ソースからデータを抽出しているときに

発⽣する ORA-01555• データ型変換の問題• PostgreSQL の空⽩⽂字と null• 複合⼀意インデックスの null 動作• PostgreSQL の numeric データ型の選択

(numeric と BIGINT の⽐較)• PostgreSQL の SEQUENCE

キャッシュ動作• PostgreSQL でのプレーンテキスト検索

のパフォーマンス上の問題

https://aws.amazon.com/jp/blogs/news/how-to-solve-some-common-challenges-faced-while-migrating-from-oracle-to-postgresql/



Oracle から PostgreSQL の移⾏における⼀般的課題AWS Blog : 技術的解決⽅法を記載• ソースからデータを抽出しているときに

発⽣する ORA-01555• データ型変換の問題• PostgreSQL の空⽩⽂字と null• 複合⼀意インデックスの null 動作• PostgreSQL の numeric データ型の選択

(numeric と BIGINT の⽐較)• PostgreSQL の SEQUENCE

キャッシュ動作• PostgreSQL でのプレーンテキスト検索

のパフォーマンス上の問題




PostgreSQL の空白文字と null

== PostgreSQL:Empty string != null


AWS のデータベース移⾏サービスデータベースエンジンが異なる移⾏の場合、スキーマ(テーブルのデータ型、インデックス、制約など)、SQL (個別の SQL ⽂やストアドプロシージャーなど) がどの程度の難易度で移⾏可能か事前に調査が必要

Assessment

• Schema Conversion Tool (SCT)

Schema conversion

Code conversion

Data migration Validation



• Database Migration Service (DMS)


• Snowball integration

• Database Migration Service (DMS) Data Validation

• スキーマ、SQL移⾏の難易度を調査

• スキーマの移⾏ • SQL、プロシージャーの移⾏

• データの移⾏ • データ移⾏の正常性をテスト


AWS Database Migration Service (DMS) 既存のデータベースをマイグレーションするサービス

同種に加え異種プラットフォームの移⾏にも対応

⼀括移⾏に加えCDC (レプリケーション)も対応

オンプレミスDB

DB on EC2

RDS

オンプレミスDB

DB on EC2

RDS

※オンプレミス to オンプレミスは⾮対応

DMS

S3


AWS Schema Conversion Tool (SCT)

ソース DB のスキーマ、DML などの⼤部分を⾃動的にターゲット DB 互換フォーマットに変換できる無償のデスクトップアプリケーション

• ⼿動変換の補助• 評価レポートの作成• アプリケーション SQL の変換に対応• 多数の対応データベース


ホワイトペーパー : Database Migration Playbook

DB オブジェクトごとにどのように移⾏すれば良いかが記載された移⾏のベストプラクティス集

• Oracle to Amazon Aurora PostgreSQL• Oracle to Amazon Aurora MySQL• Oracle to Amazon Redshift• SQL Server to Aurora MySQL• SQL Server to Aurora PostgreSQL

https://aws.amazon.com/jp/dms/resources/

https://aws.amazon.com/jp/dms/resources/


移⾏の効果


移⾏の結果と効果• 約 7,500 のデータベースを Oracle から Amazon RDS / Aurora に移⾏• 303 以上のビジネスクリティカルなサービスを DynamoDB に移⾏• 運⽤管理コストを削減• レイテンシーの向上とイノベーションを実現• プライムデーなどのイベントにおけるシステム拡張作業⼯数の削減


移⾏の効果Purpose-built データベースにより適材適所の選択が可能にü 万能のデータベースは存在しない

コスト削減

運⽤管理コストは40%〜90% の削減

パフォーマンス向上

処理量が 2倍〜4倍に増加しレイテンシーは 40% 削減

スケーリング時の作業⼯数削減

AWSのマネージドデータベースを利⽤する事でピーク時の

スケーリング作業⼯数が 1/10 に


まとめ


Amazon 事例における移⾏プロジェクトのポイント• オンプレミスにおけるデータベースの課題を、クラウド移⾏により解決• データベースの適材適所な選択• Purpose-built データベースとマネージドデータベース

• トレーニング ( ⾃習ベース / 集合形式 ) とキャリアパス• リファレンスアーキテクチャーやナレッジの共有

AWS Innovators – Amazon.comHow Amazon is Achieving Database Freedom Using AWS


ご参考 : Amazon.com 事例コンテンツ

https://pages.awscloud.com/AWS-Innovators-Amazon.html

https://pages.awscloud.com/AWS-Innovators-Amazon.html



クイズ

Q: データベースの移⾏において、アプリケーション毎の段階的な移⾏は重要な要素になります。今回ご紹介した Amazon.com でも、ダウンタイムを減らして、段階移⾏が出来るようにアーキテクチャーの⼯夫を⾏っています。具体的には、アプリケーション毎にデータベースエンジンを選んで接続できるようにしています。どのようなアーキテクチャーを採⽤してるでしょうか︖

Thank you!


髙橋敏⾏Twitter: @YukkiTakahashi

Date post:	09-Jul-2020
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

Amazon.com における Oracle データベースの移行 · 2020-05-07 ·...

Documents