Contenu connexe Similaire à Oracleからamazon auroraへの移行にむけて (20) 3. 3自己紹介
崔 陽一 (Yoichi SAI)
- AWS事業本部 コンサルティング部
- エキスパートソリューションアーキテクト
- 前職：
- DBエンジニア→インフラエンジニア→AWSエンジニア
- 大手証券システムのデータベースの開発・運用
- 好きなデータベース
- Oracle
- Amazon Aurora
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
34. 34AWS SCTとは
AWS Schema Conversion Tool
• WindowsやMacにインストールできるスタンドアロンアプリケーション。
• 64ビットOSのみサポート。
• 異なるDB間でのオブジェクトの変換を実施。
スキーマオブジェクトやコードオブジェクトを変換
移行対象 – 表、インデックス、トリガー、プロシージャ、制約、ビュー
• 評価レポートを自動で作成。
自動変換可能な割合や、変換不可の場合は、オブジェクト名やエラー内容をPDF出力
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
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への接続準備などが
必要。
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 空文字
Notes de l'éditeur システムのデータベース、Oracle RACを用いて
まずは最近の事例を見ていきたい ここで質問してみる
まずは最近の事例を見ていきたい 2019/10の記事
Amazon.comもDB移行を実施。
7500のデータベースを移行。75PBのデータベース。
コスト削減、60%
2019/4の記事
AWS Summitでも紹介された
理由はコストとのこと。ライセンス費用と移行コストを天秤にかけ3年でペイできる試算。
3ノードRACをAuroraへ移行。30秒程度のノード切替が許容できるので、AuroraでOK。
SCTによる自動変換率は62%
ランニングコストは83%低減。
せっかくなので質問したい
質問タイム？
移行元、移行先は何ですか？
・移行元 Oracle/SQL Serverの人？
・移行先 MySQL/PostgreSQLの人？
・もう実際に移行している人？
・PoCやってる人？
・これからやろうとしている、検討中の人？
こんな理由かな？
移行したい理由はなんですか？
・Oracleのライセンス費用や保守費用が高額。ランニングコストに占める割合が高い。
・ライセンス体系の変更が影響ある。SE1やSEを利用していたが、SE2になるとか
・Oracle RAC使っており、RDS Multi-AZへの移行はためらうが、Auroraなら問題ない。
・Oracle SEでRAC組んでる場合は、冗長化目的で2ノードRACを構成しているケースがあるが、
Oracle EEでも可用性要件を見極めれば、Auroraへの移行は十分あり
世の中の事情は？
商用データベースは、ライセンスやオプション、保守費用が高額になりがちである
しかし、ハイトランザクションが要求されるシステムであったり、もしくは、オプション機能を有効活用することで開発費用を抑えることができたり、
あるいは、ベンダーのサポートサービスを十分に活用している、などの場合は、その価格は十分に見合っていると考えられる。
Automatic Workload Repository
Oracle Databaseのバージョン11.2や12.1のExtend Support期間の終了が近づいている。
11.2は2020/12まで、12.1は2021/7までである。
期限を過ぎた後は、新規のバグ等が見つかってもパッチが提供されないSustaining Supportとなる。
引き続きサポートを受けるためには、バージョンアップが必要
しかし、検証や移行に金、時間、手間といったコストがかかるため、なかなかバージョンアップが進まない。
また、ライセンス体系の変更に悩まされている
SEやSE1から、SE2に変更すると、ライセンス費用や上限CPU数が今までと違ってくる。
また、パブリッククラウド上の課金体系が変更（コア係数が0.5から1.0に倍増）されたので、
RDS Oracleを使っている場合等、コストが想定の2倍になってた、なんてこともあるかと思います。
SE1が約70万（69万6000円) から210万と3倍に
SE2だと利用可能なソケット数が4から2に減る
AWSでのライセンス費用が最大2倍に値上がり
しかしながら、昨今、OSSデータベースも進化し、基本機能や性能が商用データベースと遜色ないものになってきた。
先述のケース以外で利用している場合は、OSSに切り替えることで、コスト面でのメリットを享受できる可能性があります。
また、同じOSSのDBの場合、RDS Multi-AZだけでなく、Amazon Auroraを使うことで機能面でも新たなメリットを享受できます。
- コスト高い
- ライセンスが高い。EEは単価高い
- オプション料金高い。
- 保守料金が高い。なぜか年々値上がっていく
- 旧バージョンのサポート切れ（EOS）
- Oracle Database 11g Release 2 (11.2.0.4) 2020/12/31 延長サポート終了
- バージョンアップ作業が必要になるけど、同じ検証作業必要なら、Auroraに移行したい
- ライセンス体系変わって、影響受けるから
- SE1,SEからSE2に変わるタイミングで値上がっちゃうよパターン
- 純粋にAWS上での利用ライセンスが2倍になったから（2017.2？）
例えば、小さな規模でOracleを惰性で利用していたり、
検証コストをかけたくないという理由で、パッチ適用やバージョンアップを実施してこなかった
Oracleの機能をあまりつかいこなしていない
そんな人たちは、Auroraへ移行しましょう。（ライセンス費用もったいないから
という問題や悩みがあるので、現在Oracleを利用しているユーザーには、
現状の運用の費用対効果が適切かどうかを判断した上で、Amazon Auroraへの移行をオススメします
移行できないケース
・移行の工数がライセンス費用と比べて割りに合わない。
・Oracleしかサポートしていないパッケージがある。
・OSS-DBエンジニアが確保できない。
・RACが最高！
RDS共通
バッファキャッシュをDBエンジンのレイヤーから切り離し、
クラッシュリカバリ発生時でもデータベース再起動後、すぐにキャッシュを継続して利用可能
OracleからMySQLやPostgreへの移行になりますので、異なるDBエンジンの移行です
OracleからMySQLやPostgreへの移行になりますので、異なるDBエンジンの移行です
OracleからMySQLやPostgreへの移行になりますので、異なるDBエンジンの移行です
オブジェクト移行のアセスメント、テーブル・プロシージャ移行の難易度を調査
オブジェクト移行のアセスメント、テーブル・プロシージャ移行の難易度を調査
トランザクションログ（REDOログ）
レイテンシーが高い場合は、ソースから変更をキャプチャするプロセスが遅れている
ターゲットに適用するプロセスが遅れていることを意味する
https://aws.amazon.com/jp/premiumsupport/knowledge-center/dms-high-target-latency/
トランザクションログ（REDOログ）
FreeableMemory/SwapUsage/FreeStorageSpace を見ておく
ソースDBの変更はメモリにキャッシュされる
たとえば、ロードに 24 時間かかり、1 時間あたり 2 GB のトランザクションが発生する場合は、
キャッシュされるトランザクションに対応するために 48 GB の空き領域があることを確認します。
DBと同じサイズのディスクが必要なのではなく、ロード時間と更新量の兼ね合いになります。 変更量が1時間あたり10GBから30GBの場合で、変更を早くレプリケートする場合も、Binary Reader
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は読み取りスケールアウトに焦点を当てているので、移行対象になりうる。
Recovery Time Objective どのくらいの時間でシステムを復旧させるかの目標値
Recovery Point Objective 過去のどの時点までのデータを保証して復旧させるかの目標値
Oracleの場合、空文字で insert するとNULLとして登録され、SELECTが返ってくるが、
Postgreの場合、空文字として登録されるので、NULLでは条件合致しない。
Where句を空文字に修正するか、(where val = ‘’)
insert文をNULLに修正する必要あり（VALUES (1, NULL); ）
シノニムは、ビューで代替する。
ファンクションは移行可能。
プロシージャはどうする？
型変換
Number型はdecimalやsmallint/bigint/integerなど
Date型はTimestampへ
アプリケーション移行。結果の不一致が発生していないか確認が必須。
アプリケーションの移行作業の作業量を多めに見積もることが大事。
アプリケーションの動作確認は必ず実施すること。
また、性能テストも大事。SQLの処理性能は事前の机上予測が困難
多めに見積もること
外部結合
シノニムは、ビューで代替する。
ファンクションは移行可能。
プロシージャはどうする？
型変換
Number型はdecimalやsmallint/bigint/integerなど
Date型はTimestampへ
アプリケーション移行。結果の不一致が発生していないか確認が必須。
アプリケーションの移行作業の作業量を多めに見積もることが大事。
アプリケーションの動作確認は必ず実施すること。
また、性能テストも大事。SQLの処理性能は事前の机上予測が困難
多めに見積もること
外部結合
