Oracleからamazon auroraへの移行にむけて
- 1. Oracle から Aurora への データベース移行 崔 陽一
- 3. 3自己紹介 崔 陽一 (Yoichi SAI) - AWS事業本部 コンサルティング部 - エキスパートソリューションアーキテクト - 前職： - DBエンジニア→インフラエンジニア→AWSエンジニア - 大手証券システムのデータベースの開発・運用 - 好きなデータベース - Oracle - Amazon Aurora
- 6. 6アジェンダ • データベース移行の背景 • Amazon Auroraとは • 移行の流れ • 移行時の注意点
- 8. 8Amazon.com DB移行を完了 https://aws.amazon.com/jp/blogs/news/migration-complete-amazons-consumer-business-just-turned-off-its-final-oracle-database/ Aurora, RDS, Dynamo DB, Redshif へ 7500データベース、75PBを移行。 コスト60%削減
- 10. 10皆さんへ質問 異なるデータベースへの移行について • 既に移行中/移行済みの方？ • PoC実施中の方？ • これからPoC/興味ありの方？
- 11. 11データベースエンジンの移行 データベースエンジンを移行したい理由は？ • ライセンスやオプション、保守のコストが高額 • 旧バージョンのサポート終了 • ライセンス体系変更の影響を受ける • OSSデータベースの進化
- 12. 12データベース移行の背景 1.ライセンスやオプション、保守のコスト • プロセッサーライセンス • Oracle EE：570万／Oracle SE2：210万 • パーティションやAWRには、オプション料金も発生。 • 保守コストも年々増加傾向。 但し、ハイトランザクションのシステムや、オプション機能を有効活用している場合、 また、サポートサービスを十分に活用していれば、価格に見合っているといえる。
- 13. 13データベース移行の背景 2.旧バージョンのサポート終了 • 11.2や12.1のExtend Support期間の終了が近い 11.2は2020/12まで 12.1は2021/7で終了 この後は、Sustaining Supportに変更となり、 新規のバグ等が見つかっても、パッチ未提供
- 15. 15データベース移行の背景 4.OSSデータベースの進化 • 基本機能や性能が商用DBと遜色ないものに • ライセンス料金不要、コスト面でのメリット • RDS Multi-AZ構成からAmazon Auroraへの進化
- 17. 17データベース移行の背景 移行を特にオススメするケース • 小さな規模でOracleを利用している • Oracle特有の機能をあまり使いこなしていない • バージョンアップをやってこなかった
- 18. 18データベース移行の背景 移行がマッチしないケース • 移行工数がライセンス費用の削減効果と比べて、割にあわない • Oracleしかサポートしていないパッケージがある • 書き込み処理の並列化のためにOracle RACが必要
- 19. 19 ではどこに移行するのか
- 20. 20 Amazon Aurora
- 21. 21Amazon Aurora Amazon Auroraとは？ • フルマネージド • 商用データベースのようなパフォーマンスと可用性 • OSSデータベースのようなコスト効果 • MySQLやPostgreSQLとの互換性
- 24. 24Amazon Aurora パフォーマンス RDS for MySQLやRDS for PostgreSQL と比較して3〜5倍のパ フォーマンスがベンチマークで計測されている Amazon Aurora MySQLのパフォーマンスベンチマークに関するガイド https://d1.awsstatic.com/product- marketing/Aurora/RDS_Aurora_Performance_Assessment_Benchmarking_v1-2.pdf Amazon Aurora PostgreSQLのパフォーマンスベンチマークに関するガイド https://d1.awsstatic.com/product- marketing/Aurora/RDS_Aurora_PostgreSQL_Performance_Assessment_Benchmarking_V1-0.pdf
- 25. 25Amazon Aurora コスト 初期費用やライセンス費用が不要 ストレージは使用量に応じて10GB単位で最大64TBまで自動拡張 初期構築時に将来的に必要とされるサイズを確保する必要がない
- 26. 26Amazon Aurora その他 • 過去72時間までのバックトラック(データ巻き戻し)が可能 • Cluster Cache Management による高速リカバリ • ストレージレイヤーでのリージョン間レプリケーション
- 28. 28Amazon Aurora まとめ • フルマネージド ストレージ拡張／バックアップ／フェイルオーバー／パッチ適用 • 耐障害性・可用性 ストレージは3AZに6つのコピーを保持 • パフォーマンス RDSに比べて、３〜５倍 • コスト
- 29. 29 移行の流れ
- 31. 31OracleからAuroraへの移行について 異なるDBエンジンへの移行（Oracle→PostgreSQL/MySQL） • オブジェクトをどう移行するのか DDL文はそのまま利用出来ない。 • データをどう移行するのか Data Pump、レプリケーションは出来ない。 ファイル出力、INSERT（切替時間が十分にあれば）
- 32. 32OracleからAuroraへの移行について 異なるDBエンジンへの移行（Oracle→PostgreSQL/MySQL） • オブジェクトをどう移行するのか DDL文はそのまま利用出来ない。 →AWS SCTによる自動変換 • データをどう移行するのか Data Pump、レプリケーションは出来ない。 CSVによるInsert（切替時間が十分にあれば） →AWS DMSによるデータ移行
- 33. Amazon Aurora への移行の流れ 33OracleからAuroraへの移行について ・オブジェクト移行のアセスメント ・オブジェクト移行 ・アプリケーション（SQL）移行 ・データ移行 ・テスト AWS Schema Conversion Tool AWS Database Migration Service
- 34. 34AWS SCTとは AWS Schema Conversion Tool • WindowsやMacにインストールできるスタンドアロンアプリケーション。 • 64ビットOSのみサポート。 • 異なるDB間でのオブジェクトの変換を実施。 スキーマオブジェクトやコードオブジェクトを変換 移行対象 – 表、インデックス、トリガー、プロシージャ、制約、ビュー • 評価レポートを自動で作成。 自動変換可能な割合や、変換不可の場合は、オブジェクト名やエラー内容をPDF出力
- 37. 37AWS SCT • ソースDBがOracleの場合、MySQLよりPostgreSQLの方が、変換 率が高いことが多い。 • 手動でDDL文を変換するは工数がかかるので、まずは自動変換可 能なSCTを使うこと • テーブルオブジェクト系は変換率高い • システム内で利用しているデータ型を集めたサンプルテーブルを 作成し、変換できるかどうかをまずやってみる
- 38. 38Migration Playbook https://aws.amazon.com/jp/dms/resources/ 移行プレイブックとステップバイステップガイド 異なるDBエンジンへの移行ガイド • Oracle to Aurora MySQL • Oracle to Aurora PostgreSQL • SQL Server to Aurora MySQL • SQL Server to Aurora PostgreSQL • Oracle to Redshift の5種類が提供されている。 データベース固有の機能と様々な データベースオブジェクトを網羅。
- 39. 39Migration Playbook https://d1.awsstatic.com/whitepapers/Migration/oracle-database-amazon-aurora-postgresql-migration-playbook.pdf Oracle to Amazon Aurora PostgreSQL Migration Playbook
- 40. 40Migration Playbook https://d1.awsstatic.com/whitepapers/Migration/oracle-database-amazon-aurora-postgresql-migration-playbook.pdf Oracle to Amazon Aurora PostgreSQL Migration Playbook
- 41. Amazon Aurora への移行の流れ 41OracleからAuroraへの移行について ・オブジェクト移行のアセスメント ・オブジェクト移行 ・アプリケーション（SQL）移行 ・データ移行 ・テスト AWS Schema Conversion Tool AWS Database Migration Service
- 42. 42AWS DMSとは AWS Database Migration Service • 簡単、安全にDBもしくはDWHをAWSへ移行 • ソースDB側のアプリケーションを稼働しながらマイグレーション
- 43. 43AWS DMSとは 1. DBへの接続情報を指定 エンドポイントの作成 2. レプリケーションインスタンスの作成 3. タスクの作成 移行するテーブルと変換ルールを指定 https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/Welcome.html
- 45. 45AWS DMSとは ソース対象 オンプレおよびEC2 • Oracle Enterprise, Standard, Standard One, Standard Two の 10.2以降、11gから12.2および18cまで • MS SQL Server Enterprise, Standard, Workgroup, Developer の 2005、2008、2008R2、2012、2014、および2016 • MySQL 5.5、5.6、5.7 • PostgreSQL 9.4以降、10.x、11.x などなど。 https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Introduction.Sources.html
- 46. 46AWS DMSとは ターゲット対象 Amazon RDS • Oracle Enterprise, Standard, Standard One, Standard Two の 11g(11.2.0.3v1以降)、12.2および18cまで • MS SQL Server Enterprise, Standard, Workgroup, Developer の 2008R2、2012、2014 • MySQL 5.5、5.6、5.7 • PostgreSQL 9.4以降、10.x、11.x Amazon Aurora 等 https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Introduction.Targets.html
- 47. 47AWS DMSとは レプリケーションインスタンス • 1つ以上のレプリケーションタスクをホ ストするインスタンス • Multi-AZを使用して、高可用性および フェイルオーバーサポートを提供 • 移行で大規模なトランザクションや大量 のデータ変更が発生する場合は、スト レージ割当を増やす必要 https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Introduction.Components.html
- 49. 49レプリケーションタスク：移行タイプ 1. 既存のデータを移行（FullLoad） 現時点でソースDBのすべてのデータをターゲットDBに移行 2. データ変更のみをレプリケート（Chanage Data Capture） ソースDB側のアプリケーションは稼働したまま移行可能 ソースDBに対する変更データをキャプチャし、ターゲットに適用 3. 既存のデータの移行および継続的な変更をレプリケート
- 50. 50移行タイプ：FullLoadの場合 1. レプリケーションインスタンスが、ソースDBから複数テーブル 複数行ずつSELECT （デフォルト8テーブル、10,000行） 2. 必要に応じてインスタンスがデータを変換し、ターゲットDBに INSERT メモリだけで処理できない場合は、EBSがスワップ領域として使われる
- 51. 51移行タイプ：FullLoadの場合 監視すべきメトリクス • CPUUtilization 高い場合は、大きいインスタンスに変更 • FreeableMemory/SwapUsage/FreeStorageSpace GB単位でスワップしている場合、大きいインスタンスに変更、もしくは、 並列度または読み取り行数を減らす • NetworkTransmitThroughput/NetworkReceiveThroughput タスクが多く、ネットワーク帯域が不足している場合は、インスタンスを追 加してタスクを分散
- 52. 52移行タイプ： CDCの場合 1. レプリケーションインスタンスがソースDBのトランザクション ログを5秒間隔でキャプチャ 2. レプリケーションインスタンスがキャプチャしたログを、SQL に変換し順にターゲットDBに実行 3. ターゲットDBに接続できない、遅い場合は、レプリケーション インスタンス内にキューイング
- 53. 53移行タイプ： CDCの場合 監視すべきメトリクス • CDCLatencySource ソースDBで実行された時間からDMSインスタンスがCommitをキャプチャ したまでの時間の平均秒 • CDCLatencyTarget DMSインスタンスがCommitをキャプチャした時間からターゲットDBに適 用したまでの時間の平均秒 https://d1.awsstatic.com/webinars/jp/pdf/services/20170919_AWS-BlackBelt-DMS.pdf
- 54. 54移行タイプ：FullLoadとCDCを組み合わせた場合 1. FullLoad中のソースへの更新をキャプチャ 2. FullLoadが完了したテーブルごとに、キューイングしていた更 新を適用 3. すべてのテーブルのFullLoad完了後は、単一のテーブルの更新 ではなく、トランザクションとして更新を適用
- 55. 55AWS DMS利用時の注意点 • インデックス、トリガー、参照整合性制約の使用 FullLoadの場合は、ロード中は一旦、削除しておく。ロード完了後に再設定 • DMSインスタンスのサイズ、メモリ・ディスクには注意 移行するDBのテーブル数、データ量、変更差分の量に応じて変わる ソースDBの変更はメモリにキャッシュされる 大きなテーブルに更新が入る場合は、キャッシュされるトランザクションの ためにディスクを増やす必要がある ストレージはDBのストレージサイズと同じにする必要はない
- 56. 56AWS DMS利用時の注意点 • CDCの場合、ソースDBがOracleの場合、ログ取得方法を選択可能 LogMiner もしくは Binary Reader https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Source.Oracle.html LogMiner Binary Reader DBが標準で用意しているREDOログの解析APIを利用 DBのディレクトリオブジェクトを経由して、Redo ログ（Archive ログ）をDMSのローカルに取得し、 DMS自身がREDO解析を実行 メリット 設定がシンプルで、設定項目も少ない メリット LogMinerと異なりDBサーバへの負荷が抑えられる 大量の変更を含む移行ではパフォーマンスが高い REDOログの変更量が30GB/時間を超える デメリット REDOログの解析がDBサーバ上で実行されるため、 ソースDBに解析負荷がかかる 複数のタスクを同じソースDBからレプリケートす る場合、効率が低下 デメリット ASMを利用している場合、ASMへの接続準備などが 必要。
- 57. 57 Auroraへの移行注意点
- 58. 58OracleからAuroraへの移行注意点 Oracle RAC環境からAuroraへの移行 スケーラビリティと高可用性の実現方法に違いがある Oracle RAC 複数の書き込み可能ノードが共有ディスクにアクセス Amazon Aurora 単一の書き込み可能ノードとレプリカノードのセット（Multi-Master除く） Oracle RACに高可用性と読み取りスケールアウトを求めている場合 は、Auroraが移行対象になりうる
- 59. 59OracleからAuroraへの移行注意点 RTOの再確認 Oracle RACを利用している場合の、要件を再確認する DBのRTOを数秒短くするために、いくらのコストをかけるか DB以外の障害もあるので、DBだけRTOが高くても仕方ない Oracle RAC の構成でノード障害時もゼロではない 数秒から30秒程度のフェイルオーバーが許容できるか
- 62. 62OracleからAuroraへの移行注意点 空文字の取り扱い Oracleの場合、空文字「’’」はNULLとして扱う PostgreSQLの場合、長さ０バイトの空文字として扱う NULLとは区別
- 63. 63OracleからAuroraへの移行注意点 空文字の取り扱い SQL> INSERT INTO tbl1 ( id , val ) VALUES ( 1 , ‘’ ) ; SQL> SELECT id FROM t1 WHERE val IS NULL; Oracleの場合、空文字で insert するとNULLとして登録され、 SELECTが返ってくるが、Postgreの場合、空文字として登録され るので、NULLでは条件合致しない。 Oracle PostgreSQL NULL 空文字
- 64. 64OracleからAuroraへの移行注意点 空文字の取り扱い SQL> INSERT INTO tbl1 ( id , val ) VALUES ( 1 , ‘’ ) ; SQL> SELECT id FROM t1 WHERE val IS NULL; Oracleの場合 SELECT結果も返ってくる id val 1 NULL
- 65. 65OracleからAuroraへの移行注意点 空文字の取り扱い SQL> INSERT INTO tbl1 ( id , val ) VALUES ( 1 , ‘’ ) ; SQL> SELECT id FROM t1 WHERE val IS NULL; PostgreSQLの場合 SELECT結果は条件一致しないので返ってこない。 id val 1 (空文字)
- 66. 66OracleからAuroraへの移行注意点 空文字の取り扱い SQL> INSERT INTO tbl1 ( id , val ) VALUES ( 1 , NULL ) ; SQL> SELECT id FROM t1 WHERE val IS NULL; PostgreSQLの場合 INSERT箇所を修正する。 （NULLとして登録したいのか、空文字として登録したいのか精査必要） id val 1 NULL
- 68. 68 まとめ
Editor's Notes
- #4: システムのデータベース、Oracle RACを用いて
- #5: まずは最近の事例を見ていきたい
- #6: ここで質問してみる
- #8: まずは最近の事例を見ていきたい
- #9: 2019/10の記事 Amazon.comもDB移行を実施。 7500のデータベースを移行。75PBのデータベース。 コスト削減、60%
- #10: 2019/4の記事 AWS Summitでも紹介された 理由はコストとのこと。ライセンス費用と移行コストを天秤にかけ3年でペイできる試算。 3ノードRACをAuroraへ移行。30秒程度のノード切替が許容できるので、AuroraでOK。 SCTによる自動変換率は62% ランニングコストは83%低減。
- #11: せっかくなので質問したい 質問タイム？ 移行元、移行先は何ですか？ ・移行元 Oracle/SQL Serverの人？ ・移行先 MySQL/PostgreSQLの人？ ・もう実際に移行している人？ ・PoCやってる人？ ・これからやろうとしている、検討中の人？
- #12: こんな理由かな？ 移行したい理由はなんですか？ ・Oracleのライセンス費用や保守費用が高額。ランニングコストに占める割合が高い。 ・ライセンス体系の変更が影響ある。SE1やSEを利用していたが、SE2になるとか ・Oracle RAC使っており、RDS Multi-AZへの移行はためらうが、Auroraなら問題ない。 ・Oracle SEでRAC組んでる場合は、冗長化目的で2ノードRACを構成しているケースがあるが、 Oracle EEでも可用性要件を見極めれば、Auroraへの移行は十分あり
- #13: 世の中の事情は？ 商用データベースは、ライセンスやオプション、保守費用が高額になりがちである しかし、ハイトランザクションが要求されるシステムであったり、もしくは、オプション機能を有効活用することで開発費用を抑えることができたり、 あるいは、ベンダーのサポートサービスを十分に活用している、などの場合は、その価格は十分に見合っていると考えられる。 Automatic Workload Repository
- #14: Oracle Databaseのバージョン11.2や12.1のExtend Support期間の終了が近づいている。 11.2は2020/12まで、12.1は2021/7までである。 期限を過ぎた後は、新規のバグ等が見つかってもパッチが提供されないSustaining Supportとなる。 引き続きサポートを受けるためには、バージョンアップが必要 しかし、検証や移行に金、時間、手間といったコストがかかるため、なかなかバージョンアップが進まない。
- #15: また、ライセンス体系の変更に悩まされている SEやSE1から、SE2に変更すると、ライセンス費用や上限CPU数が今までと違ってくる。 また、パブリッククラウド上の課金体系が変更（コア係数が0.5から1.0に倍増）されたので、 RDS Oracleを使っている場合等、コストが想定の2倍になってた、なんてこともあるかと思います。 SE1が約70万（69万6000円) から210万と3倍に SE2だと利用可能なソケット数が4から2に減る AWSでのライセンス費用が最大2倍に値上がり
- #16: しかしながら、昨今、OSSデータベースも進化し、基本機能や性能が商用データベースと遜色ないものになってきた。 先述のケース以外で利用している場合は、OSSに切り替えることで、コスト面でのメリットを享受できる可能性があります。 また、同じOSSのDBの場合、RDS Multi-AZだけでなく、Amazon Auroraを使うことで機能面でも新たなメリットを享受できます。
- #17: - コスト高い - ライセンスが高い。EEは単価高い - オプション料金高い。 - 保守料金が高い。なぜか年々値上がっていく - 旧バージョンのサポート切れ（EOS） - Oracle Database 11g Release 2 (11.2.0.4) 2020/12/31 延長サポート終了 - バージョンアップ作業が必要になるけど、同じ検証作業必要なら、Auroraに移行したい - ライセンス体系変わって、影響受けるから - SE1,SEからSE2に変わるタイミングで値上がっちゃうよパターン - 純粋にAWS上での利用ライセンスが2倍になったから（2017.2？）
- #18: 例えば、小さな規模でOracleを惰性で利用していたり、 検証コストをかけたくないという理由で、パッチ適用やバージョンアップを実施してこなかった Oracleの機能をあまりつかいこなしていない そんな人たちは、Auroraへ移行しましょう。（ライセンス費用もったいないから という問題や悩みがあるので、現在Oracleを利用しているユーザーには、 現状の運用の費用対効果が適切かどうかを判断した上で、Amazon Auroraへの移行をオススメします
- #19: 移行できないケース ・移行の工数がライセンス費用と比べて割りに合わない。 ・Oracleしかサポートしていないパッケージがある。 ・OSS-DBエンジニアが確保できない。 ・RACが最高！
- #23: RDS共通
- #27: バッファキャッシュをDBエンジンのレイヤーから切り離し、 クラッシュリカバリ発生時でもデータベース再起動後、すぐにキャッシュを継続して利用可能
- #31: OracleからMySQLやPostgreへの移行になりますので、異なるDBエンジンの移行です
- #32: OracleからMySQLやPostgreへの移行になりますので、異なるDBエンジンの移行です
- #33: OracleからMySQLやPostgreへの移行になりますので、異なるDBエンジンの移行です
- #34: オブジェクト移行のアセスメント、テーブル・プロシージャ移行の難易度を調査
- #42: オブジェクト移行のアセスメント、テーブル・プロシージャ移行の難易度を調査
- #53: トランザクションログ（REDOログ）
- #54: レイテンシーが高い場合は、ソースから変更をキャプチャするプロセスが遅れている ターゲットに適用するプロセスが遅れていることを意味する https://aws.amazon.com/jp/premiumsupport/knowledge-center/dms-high-target-latency/
- #55: トランザクションログ（REDOログ）
- #56: FreeableMemory/SwapUsage/FreeStorageSpace を見ておく ソースDBの変更はメモリにキャッシュされる たとえば、ロードに 24 時間かかり、1 時間あたり 2 GB のトランザクションが発生する場合は、 キャッシュされるトランザクションに対応するために 48 GB の空き領域があることを確認します。 DBと同じサイズのディスクが必要なのではなく、ロード時間と更新量の兼ね合いになります。
- #57: 変更量が1時間あたり10GBから30GBの場合で、変更を早くレプリケートする場合も、Binary Reader
- #59: Oracle RACは、他のRDBMSテクノロジーと比較した場合、Oracleデータベースの主要な差別化機能の一つです。 Oracle RACは、Oracleデータベースが高レベルの高可用性と大きなパフォーマンスの利点を提供できるテクノロジーです。 Oracle RACはアクティブ／アクティブのデータベースクラスターであり、複数のOracleデータベースサーバー（インメモリプロセスとキャッシュのコレクションであるOracle Databaseインスタンスを実行）が、単一のディスク永続データベースファイルのセットを含む共有ストレージデバイスにアクセスします。 Amazon AuroraとOracle RACとの間には、スケーラビリティと高可用性の向上を提供する方法に違いがある。 Oracle RACでは、複数の読み取り／書き込みクラスターノードが共有ディスクにアクセスする。 Auroraクラスターは、書き込み用の単一のプライマリーノードと、レプリカノードのセットがある。（Multi-Masterを除く） Oracle RACは読み取りと書き込みの両方をスケールアウトできますが、書き込みのスケーラビリティを求めているでしょうか。 そうではなく、高可用性と読み取りスケールアウトのためにOracle RACを利用している場合は、 Amazon Auroraは読み取りスケールアウトに焦点を当てているので、移行対象になりうる。
- #60: Recovery Time Objective どのくらいの時間でシステムを復旧させるかの目標値 Recovery Point Objective 過去のどの時点までのデータを保証して復旧させるかの目標値
- #65: Oracleの場合、空文字で insert するとNULLとして登録され、SELECTが返ってくるが、 Postgreの場合、空文字として登録されるので、NULLでは条件合致しない。
- #67: Where句を空文字に修正するか、(where val = ‘’) insert文をNULLに修正する必要あり（VALUES (1, NULL); ）
- #68: シノニムは、ビューで代替する。 ファンクションは移行可能。 プロシージャはどうする？ 型変換 Number型はdecimalやsmallint/bigint/integerなど Date型はTimestampへ アプリケーション移行。結果の不一致が発生していないか確認が必須。 アプリケーションの移行作業の作業量を多めに見積もることが大事。 アプリケーションの動作確認は必ず実施すること。 また、性能テストも大事。SQLの処理性能は事前の机上予測が困難 多めに見積もること 外部結合
- #70: シノニムは、ビューで代替する。 ファンクションは移行可能。 プロシージャはどうする？ 型変換 Number型はdecimalやsmallint/bigint/integerなど Date型はTimestampへ アプリケーション移行。結果の不一致が発生していないか確認が必須。 アプリケーションの移行作業の作業量を多めに見積もることが大事。 アプリケーションの動作確認は必ず実施すること。 また、性能テストも大事。SQLの処理性能は事前の机上予測が困難 多めに見積もること 外部結合