[レポート] GPSTEC313: OracleからAurora PostgreSQLへの移行を促進するには #reinvent

re:Invent2018で行われたセッション「GPSTEC313 - Accelerate Oracle to Aurora PostgreSQL Migration」のレポートとなります。
2018.12.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

このページは、re:Invent2018で行われたセッション「GPSTEC313 - Accelerate Oracle to Aurora PostgreSQL Migration」のレポートとなります。

There is a lot of interest these days in migrating data from commercial relational databases to open-source relational databases. PostgreSQL is a great choice for migration, offering advanced features, high performance, rock-solid data integrity, and a flexible open-source license. PostgreSQL is compliant with ANSI SQL. It supports drivers for nearly all development languages, and it has a strong community of active committers and companies to provide support. In this talk, we demonstrate an overall approach for migrating an application from your current Oracle database to an Amazon Aurora PostgreSQL database.

最近、AWSではOracleからAuroraへの移行がなされたこともあり、製品を具体的に指定したアグレッシブなセッションとなりました。

レポート

アジェンダ

  • 異種データベース間の移行計画についての注意事項
  • Oralce から Aurora PostgreSQL 移行向けの DMSとSCTの使い方
  • 本番移行に向けたベストプラクティス

異種データベース間の移行計画

異種データベース間では、大文字小文字の取り扱いやストアドプロシージャの有無など細かな違いが沢山あり、そのまま移行できない。 分析、スキーマ変換、データ移行、アプリケーション修正、テストを何度もする必要がある。

分析と計画

全体の流れ

アセスメント > ワークロード測定 > 作業見積 > マスタ線表作成

ワークロード測定と作業見積

DBオブジェクト毎の物量に基づいた重みでワークロードを測定し、作業量の重みを判定していく。

スキーマ変換とデータ移行

  • AWS SCT を用いて、スキーマをコピー/変換する
  • データ移動は AWS DMS を用いる

Schema Convert Tool(SCT)

特徴

アセスメントレポート

移行のPlaybook サンプル: 実施内容と現状の対応内容が表示される

AWS Database Migration Service(DMS)

特徴

本番移行に向けたベストプラクティス

まずはKPIの設定が重要。

  • スケール
  • 稼働時間
  • バックアップ/リストア
  • メンテナンス
  • キャパシティ
  • リソース利用状況
  • パフォーマンス
  • スループット/TPS

スケールとパフォーマンス

  • インフラストラクチャ計画
    • ストレージ
    • CPUとメモリ ※ Aurora Storage Daemon はCPUを使用する
  • PostgreSQL db でスケールするために重要なパラメータ:
    • 例:DBキャッシュサイズの理解
    • 例:PostgreSQLのクエリ実行計画を理解する https://www.postgresql.org/docs/9.6/static/runtime-config-query.html
  • CloudWatch メトリクス
    • 同じ CloudWatch メトリクスでも Aurora向けのものは、従来の EBSストレージベースの Amazon RDS PostgresSQL インスタンスのものと異なるので注意
      • Commit throughput
      • Commit latency
    • 拡張監視
      • プロセス情報用の50のシステムメトリクス
      • 1秒単位まで詳細化可能
  • 保守
    • autovacuumをオフにしないこと!
      • PostgreSQLでは必須となる機能
      • Amazon RDS for PostgreSQLの事例も参考に
    • メンテナンス作業
      • メンテナンス作業の際は専用の作業員を置くようにすること
      • EBSボリュームの使用状況とパフォーマンスをローカルで監視
  • 可用性
    • 読み込み用と書き込み用のクラスタエンドポイントを使用して接続する
    • TCP keepalive を積極的に設定して、クエリが読み取りタイムアウトしない積極的にJava DNSキャッシュタイムアウトを設定する
    • JDBC接続タイムアウトは低めに設定する
    • しっかりとテストする

両プロダクトの基本的な違いをしっかりと把握する

DMS(Data Migration Service)タスクのトラブルシューティングにおけるベストプラクティス

カットオーバーとロールバックの計画

まとめ

  • 計画にあたっては適切なツールを使う
  • スキーマ変換とデータ移行にSCTとDMSを使う
  • 移行元と移行先のDBエンジンの違いを把握する
  • KPI、性能指標、可用性のを定義しておく
  • あらかじめめ本番化・運用計画を立てておく

さいごに

Oracle から Aurora PostgreSQL への移行について具体的に述べられたセッションでした。

特にRDBといえば「Oracle以外は知らない」といった方にとっては有用となる内容なのではないでしょうか。