この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、崔です。
4/11(木)にAWSJ主催のセミナー「商用データベースのクラウド移行」に参加しましたので、レポートします。
データベースのクラウド移行に関心のある方が多いのか、100名くらいの方が参加されていました。
主にOracleからのデータベース移行について、紹介されていました。
4つのセッションがありましたので、ポイントをかいつまんでレポートします。
データベースのクラウド化はなぜ重要か
アマゾンウェブサービスジャパン株式会社 プラットフォーム事業開発部 北川様
はじめに
AWSが提供するデータベースサービスを紹介した後に、データベース移行について述べられていました。
- データベース移行は生半可にできるものではない
- 先日、OracleからAurora PostgreSQLへの移行事例を発表したが、やはり移行コストがかかっている
- OracleやSQL ServerをPostgreSQLへ移行するには、クエリの書き直しや実行結果の確認に手間とコストが非常にかかる
- 前向きにOSSデータベースへの移行をするが、クエリの書き換えの手間がきついな、という場合には同一DBエンジンのRDSへの移行も有効な選択肢
- Oracle SE1/SE2はRDSのライセンス込モデルもある。ただし、EEはBYOLになる。EEからSE2へのダウンエディションが可能かどうかも検討して欲しい
- 重要なのは、どうして移行したいのか。移行コストがかかってもOSSに行きたいのか、どうか、等を明確にすること
事前アンケートの結果
次に事前アンケートの結果が共有されました
- 100名程度の回答者のうち、73％がデータベース移行に取り組んでいる
- すでに開始、準備している、PoCやってる、一部移行している等
- テスト的なものから実施している状況
- 移行元としては、Oracle64％、SQL Server 15%、合わせて80%
- 同じDBエンジンへの移行の場合、SQL Serverの割合が多くなる傾向
- 移行先としては、EC2よりRDSへの移行を検討している 67%
- 移行のための手段や選択肢はお客様によって、千差万別。一括りには出来ない。お客様の環境に応じ、個別検討が必要
データベースの移行には、2つの移行パターンがある
- Lift and shift
- 既存のアプリケーションをクラウドへ
- Quickly build
- 新しいアプリケーションをクラウド上で迅速に提供
- 2つの方法を検討する。どちらを選ぶかは、お客様の環境、方針次第。前者が圧倒的に多い
ペインポイント
- クラウド移行することで、次を解消したい
- ミドルウェアやハードウェアのライフサイクル切れ
- 商用データベースのサポート期限切れ
- アップグレード／ハードウェアからの脱却
- 高いコスト
- オーバーキャパシティからの脱却
- エディション変更
- OSSへの移行
- AWSのストレージが早くなっているので、Oracle EEのパーティショニングを使わなくなったケースもあった
- アプリケーションを書き直すコストと、ライセンス費用削減とのプラスマイナスを比較検討
- データベースの移行には手間がかかる
- Homogeneous Migration（同一DBエンジン間の移行） DataPumpなどの利用
- Heterogeneous Migration（異種DBエンジン間の移行） DMSやSCTの活用
AWSの考えるクラウドへの6つの移行戦略
- Re-Host ホスト変更
- サーバーやアプリケーションをオンプレミス環境からクラウドにそのまま持ってくる
- オンプレミスのApp/DBをそのままEC2に持ってくる
- Re-Platform プラットフォーム変更
- クラウド移行の一環としてプラットフォームのアップグレードを行う
- オンプレミスのApp/DBをEC2に構築しVup移行する
- Refactor 書き換え
- クラウド対応したライセンスまたはアプリケーションに買い換える
- オンプレのDBをライセンス込のRDSに買い換える
- Re-Purchase 買い換え
- クラウド環境で最適に動作するようにアプリケーションを書き換える
- オンプレミスの商用DBをAurora等のOSSのベースに変更する
- Retire 廃止
- サーバーやアプリケーションを廃止する
- 平行運用していた古いシステムをDB/Appごと、このタイミングで廃止する
- Retain 保持
- オンプレミス環境を引き続き使用する
- 旧Versionに依存しているアップグレードできないパッケージアプリケーションがある
移行先はどれにするのか
- 移行元と同じDBエンジンを使用
- 移行元とは違うDBエンジンを使用
移行にどれくらい時間をかけられるか
- 期間が短いなら、同一DBエンジンで
- 既存システムをEC2上に再構築
- マネージド型データベース（RDS）を使用
- 期間が長いなら、異種DBエンジン
- MySQLやPostgreSQLなどのOSSに変更を検討できる
- クラウド移行やDBエンジン移行は1年以上は見たほうがいい
感想
まず、データベースを移行する際には、その目的を明確化すること、
次にアプリケーションやシステムをどういった形で移行するのか、
また、移行先のデータベースエンジンを変えるのか変えないのか、などをしっかりと検討する事が大事。
また、RDSだけでなく、DynamoDBや他のデータベースサービス含め移行先を検討することが大事。
SQLアセスメント＆SQLマイグレーションを効率化 〜Insight Database Testing〜
株式会社インサイトテクノロジー 高橋／吉野様
DBマイグレーション傾向
- 以前は、OracleからOracleへの移行が多かったが、最近はOracleからAuroraのパターンが増えている
DBマイグレーションにおけるSQL問題
- DBA不足（スキル、人数）
- アプリケーションの開発ドキュメントがない
- SQL修正対象はどのくらいあるか？
- アプリケーション移行の実現性・工数・期間は？
- 本番環境で実行されているSQLを収集できない（動的な変数が入った状態のSQL）
Insight Database Testingの紹介
- 本番環境でアプリケーションが発行するSQLを自動でCapture（低負荷）
- 収集したSQLを移行先DBでテスト・評価
- SQLは正しく動くのか、パフォーマンスは劣化しないか、を確認可能
Go to AWS RDS
RDSへの移行ステップは次のとおり
- アセスメント
- スキーマ変換 SCT
- データ移行 DMS
- SQLテスト Database Testing
- マイグレーション
- SQL修正 SCT／Database Testing
- テスト Database Testing
デモ
Insight Database Testingを利用したデータベース移行のデモがありました。
- Oracle 12.1 から Aurora PostgreSQLへ
- ソースDBで実行されていたSQLをターゲットDBで動かす
- エラーとなったSQLをSCTでPostgreSQL向けに修正し、再度実行
感想
DMSやSCTを使うことで、データやオブジェクトの移行コストは下げることが可能でしたが、
データベース移行の工程で、アプリケーション・SQLの移行が大きなボトルネックになりがちです。
しかしながら、このInsight Database Testingを利用することで、SQLのテスト工数を下げることができそうです。
ライセンス費用の削減分をアプリケーション移行コストが食い潰すこともあったりしますが、このツールで移行コストの削減が期待できるのではないでしょうか。
どこかのタイミングで使ってみたいと感じました。
DBMS移行計画立案のベストプラクティス
株式会社アクアシステムズ 川上様
本日の主旨
- データベース移行への取り組み方のベストプラクティスの紹介
- 商用ライセンスへの対応
- DBMSマイグレーション
- クラウド環境への最適化
Oracleライセンスの制限
- SE/SE Oneの廃止でライセンス最低価格が69万（SE One）から210万（SE2）に
- サポート切れ
- 11.2.0.4が2020/12で、12.1.0.2が2021/7で切れる
- AWS/Azureでのライセンスカウントが変更され２倍になった
Oracleライセンス高騰の対応策
- 安価なDBへの移行
- EEからSE2への移行
- DB統合
- ライセンスインクルードの利用
どのDBMSに移行するか
- PostgreSQL
- Oracleとの互換性が比較的高い
- 他のDBへの移行しやすさは、移行元DBの中身による
- Auroraで非機能要件（可用性、信頼性、性能）を維持できる可能性がある
Auroraの非機能面の主な利点
- 安全性、可用性
- データが3つのアベイラビリティゾーンに6つのコピー
- 性能
- Multi-AZの性能劣化が非常に小さい
- 同時実行性能に優れる
- サポート一元化
事例
- Oracle ExadataからRDS for MySQLや、RDS for Oracle SE2へ移行
- 統合DBから適材適所へ
- 20個のDBを1台のExadataに統合していた
- Exadata登場当時は統合DBへの集約が合理的だったが、クラウドの登場で多用な選択肢が生まれた
- 個々のシステムの特性に合わせて、最適な技術を最適なコストで使いたい
段階的なアプローチとして
- 短期 1年以内
- RDSへ移行
- 短期で変換できるDBのみ移行
- その他をIAサーバー群へ移行
- RDS移行後、サーバ単位で停止できるように
- 中期 3年以内
- 段階的にクラウドの比重を高めていく
移行の計画をどう立てたか
- 統合基盤上の20のデータベースを３グループに分類
- 10% EE継続（EEへの依存度が高いもの）
- 30% RDS for Oracle SE2 （MySQLへの変換コストが高いもの）
- 60% RDS for MySQL
- コスト削減目標が高くややアグレッシブだったが、期間を取った段階移行でトラブルなく移行済み
- 性能を維持するための対策コスト
- 複雑なSQLほど対策が必要
- アプリケーションの変換コスト
- コスト削減効果
- DBサーバ全体の総保有コストが40%削減
- 運用改善の投資増を含む、管理コストは上がってしまう
感想
一度に全てを移行することは難しいので、今回のように段階的に移行することも有効ではないでしょうか。
異なるDBエンジンに変えることが出来るDBはRDS for MySQLに移行、変換コストが高いものはRDS for Oracle SE2に移行、また、EEへの依存度が高いものはIAサーバーに移行という形で、段階的に移行することで、Exadataを移行していたのは非常に参考になりました。
Oracle DatabaseをAWSに移行するための方法と注意すべきポイント
アマゾンウェブサービスジャパン株式会社 新久保様
Recap:Choosing between Amazon RDS and EC2
- RDSが適している場合
- 業務とアプリケーションに専念し、手間のかかるデータベース管理作業をAWSに任せたい場合
- 数クリックで構築可能な、Multi-AZ構成を使いたい場合
- 自前でのバックアップ管理を行いたくない場合
- パフォーマンスチューニングやスキーマ最適化に専念したい場合
- EC2が適している場合
- SYS/SYSTEMユーザーでデータベースを完全に制御する必要がある場合
- OSレベルでアクセスする必要がある場合
- RDSでサポートされていない機能やオプションを使用する場合
- RDSでサポートされていない特定バージョンが必要な場合
データベース移行のパターンとポイントの整理
- Lift:Homogeneous Migration
- ソースとターゲットが同一のデータベースエンジン
- Oracle(オンプレミス) → Oracle(RDS or EC2)
- Oracle(EC2) → RDS for Oracle
- Shift:Heterogeneous Migration
- ソースとターゲットが異なるデータベースエンジン
- Oracle → Aurora PostgreSQL など
移行パターンとポイントの整理
- 移行先のDBエンジンは同じか
- 十分な停止時間がとれるか、
- 取れる場合は、ダンプツールやCSVアンロード＆ロードで
- DB純正のレプリケーションが組めるか
- 組める場合はレプリケーションで
- 組めない場合はDMSで
Lift：Homogeneous Migration（同一DBエンジンへの移行）
- データベースエンジンが同一であることから、既存データベースエンジニアが持つ、データベーススキル、ナレッジを生かしてAWSへのデータベース移行を行うことが可能
- EC2上に移行する場合もサイジングは必要
- RDSに移行する場合、OSレイヤーにアクセスできないので通常のDataPumpでの移行に注意が必要
- 大量のデータコピー
- 全データが本当に必要か確認（一時データないか）
- オフラインでのデータ移行も検討
Shift：Heterogeneous Migration（異種DBエンジンへの移行）
- データベースのスキーマやSQLが、どの程度の難易度で移行可能か事前に調査が必要
- 調査後、スキーマ移行、データ移行を実施し、アプリケーションのテストが必要
- 移行にはSCTやDMSが有効
パターン１ Lift：Oracle Data Pump with S3 integration
- ソースDBを止められるケース
- expdbコマンドでデータをエクスポート
- 取得したダンプファイル（必要に応じて、クライアントにダウンロードが必要）
- RDSにダンプファイルをダウンロード
- データインポート
パターン2 Lift：Replicate using Materialized View
- ソースDBを止めたく無いケース
- オンプレミスへのDBLink作成
- RDS側にMaterialized Viewを作成
- 定期的にリフレッシュ
- つなぎ先の変更
パターン3 Shift：Oracle Database to Amazon Redshift
- SCTによるアセスメント
- SCTによるスキーマ、コード変換
- SCT Data Extractor Agent
- 既存のデータウェアハウスからデータを抽出してRedshiftへ移行
パターン4 Shift：Oracle Database to Amazon Aurora(PostgreSQL)
- SCTによるアセスメント
- プロシージャやアプリケーション内のSQLのアセスメント
- DMSを使った最小限のダウンタイムでのデータ移行
- 初期データ移行（Full Load）
- データ更新（CDC）
- データ更新（トランザクションログ）
パターン5 （応用）SCT/DMS/Snowballを使った大量データの移行
- DMS Agentを利用する
SCT/DMSによるデータ移行の注意点
- DMSのレプリケーションサイズを調整する
- Redoログの読み込み方法はLogMiner（デフォルト）とBinary Readerの２つが存在するので、ソース側へのリソース影響が異なるので、サポートされるバージョン等の制限事項を考慮しながら選択する
- ターゲット側のパフォーマンスを最大化させるために、FK/Trigger/Indexは無効にしておく
- FKを無効に出来ない場合、制約違反を回避するためフルロード時にロード順を明示的に指定
- シーケンスの値はDMSでは移行できない
- SCTで移行する
まとめ
- AWSへOracle Databaseを移行する際の移行先
- Amazon RDS for Oracle
- Amazon EC2
- Amazon Aurora / Amazon RDS（PostgreSQL/MySQL）
- Amazon Redshift
- AWSへOracle Databaseを移行する際の考え方
- データベースエンジンを変更しない（Lift）
- データベースエンジンを変更する（Shift）
- AWSへOracle Databaseを移行する際の方法
- データベースをLiftする場合は、既存のOracleスキルを活かした実績ある方法で
- ダウンタイムを最小限にしたい場合は、DMSも検討
- データベースをShiftする場合は、SCTによるアセスメントを実施する
- チェックした後に、SCTでのスキーマ変換、DMSでのデータ移行を計画
感想
Oracle Databaseを移行する場合において、DBエンジンを変更せずにEC2やRDSへ移行するケースや、異なるDBエンジンに移行する場合の大まかな流れが紹介されていました。
14
