(レポート) DAT302: 商用DBエンジンからAmazon AuroraまたはPostgreSQLへの移行ベストプラクティス #reinvent

はじめに

本記事はAWS re:Invent 2016のセッション「DAT302 - Best Practices for Migrating from Commercial Database Engines to Amazon Aurora or PostgreSQL」のレポートです。

スピーカーはAWSのGreg KhairallahさんとJohn Winfordさん、FINRAのAaron Carrerasさん。

レポート

• コマーシャルなライセンスは時間が経てば経つほどコストがかさむ。
• 最高水準まで行ったらあとはどのように下げるかが課題になる。そん時どんなISVアプリケーションがコアになるか？
• Amazon RDS。
  • 商用DBエンジンはOracleとMSSQLServer。
  • オープンソースがMySQLとPostgreSQL、MariaDB。
  • Amazonが開発したDBエンジンがAurora。
  • 商用DBエンジンのライセンスはRDS利用費にインクルードしている。
• DBAの時間の過ごし方。
  • 1/3はアプリケーション最適化。
  • 1/3はインストールやアップグレード、パッチ当て。
  • 1/3はその他の作業、バックアップやリカバリ、トレーニング、セキュリティ、ライセンス問題の解決...
• RDSのKey Feature。
  • 6分で起動する。
  • 簡単に冗長性を確保。
  • 短時間のタウンタイムでスケール、パッチ当てもダウンタイムは最小。
  • リードレプリカも数クリックで作成。
  • シングルクリックで暗号化、データをセキュアに保存。
• Amazon Aurora。
  • 高速で高い可用性があるハイエンドな商用DB。
  • シンプルでコストエフェクティブなオープンソースDB。
  • その二つの良いところをコンパチにしたDBエンジン。
  • ログとキャッシュのストレージを切り離しS3に保管。
• Auroraのストレージはデフォルトで高い可用性を確保。
  • シームレスにスケール、最大64TB。
• クラッシュリカバリ。
  • トラディショナルなDBでは最後のチェックポイントに対してリカバリする。
  • Auroraはパラレルに複数のチェックポイントを持つ。
  • Multi-AZなストレージを共有することでマルチプルなフェイルオーバーでデータロス無し。
• Amazon Performance Insights for RDS。
  • シンプルなモニタリングViewをAWS管理コンソールに用意済み。
• エンタープライズに対応できるグレードでオープンソース並の利用料金。
  • シンプルな料金モデル。
• マイグレーションについて。AWS DMSとAWS SCT。
  • あなたがテクニカル企業だとして、データベースを移行する場合、どのように行いますか？
  • マイグレーションは決してイージーな作業ではない。
  • ダウンタイムの考慮も必要。
  • もっとシンプルに早くマイグレーションしたいですよね。
• マイグレーションのオプション。
  • SQL Server→bakファイルのインポート。
  • MySQL→リードレプリカ。
  • Oracle→Data pump、Export/Import。
  • PostgreSQL→pg_dump。
  • SAP ACE→bcp。
  • どれもダウンタイムが必要。
• どのようにクラウドにマイグレーションするか？
  • AWS Database Migration Service。
    • 簡単にセキュアに小さなダウンタイムでデータをクラウドに移行。
    • 商用DBにもオープンソースDBにも対応。
  • AWS Schema Conversion Tool。
    • 自動で色々なデータベースのスキーマや文字コードをコンバート。
    • これまでは多くのエンジニアが異なるDBのコンバートに時間をかけていた。
    • SCTによって簡単にDBコンバートが可能。
    • 既存データウェアハウスからRedshiftへの移行にも使える。
• データベースのマイグレーションステップ。
  • 1stステップ。ソースDBからSCTを使ってターゲットDBにスキーマを移行。
  • 2ndステップ。ソース DBからDMSを使ってターゲットDBにデータを移行。
• アプリケーションを止めずに移行する方法。
  • アプリケーションとAWS環境をVPNで接続。
  • DMSでソースDBの対象テーブルやスキーマを選択。あるいはDB丸ごと。
  • DMSで新DBにテーブルやスキーマを作成。
  • VPNを通ってデータを移行。
  • DNSレコードを書き換えて、ユーザーのアプリケーションへのアクセスをAWS環境に切り替える。
•  Change data capture(CDC)とデータの適用。
  • ソースDBでデータがアップデートされると、変更をターゲットDBに反映させる。
• 複数のソースDBを1つのターゲットDBにまとめる場合。
  • DBeaverでのデモ。
• FINRAの事例について。
  • FINRAは毎日75ビリオンのイベントが発生する。
  • FINRAのクラウド移行。最初にビッグデータアプリケーションを移行した。
    • EMR、HBase、Herd、Splunkを使用。
    • HerdはFINRAが作成したオープンソースツール。
  • 次のステップ。
    • RDBを使ったアプリケーションをAWSに移行。
    • データセンターのDBをRDS for PostgreSQLに移行した。
  • まずはデータセンターで、複数のDBがマルチにリンクしていたが、HUBとなるDBを作成。
    • HUB DBとその他DBがポイントトゥポイントで接続するようにした。
  • 次にAWS上にHUBとなるDBを作成。
    • HUB DBとその他DBとのリンクはDMSで実施。
    • 100を超えるDBの同期は大変。
    • データセンターとAWSをDirectConnectで接続。
    • データセンターのHUB DBとAWSのHUB DBをDMSでリンク。
    • DMSのAPIをラップしたツールを作り、DMS以外の処理を統合。
  • 今後の期待。
    • DMSのより良いスケールサポート。
    • PostgreSQLのMViewのサポート。
    • DMSのイベントを見られるように。
    • RDSのリードレプリカやMulti-AZサポート。
    • データベースのパフォーマンス管理。
  • Amazon Aurora PostgreSQL-compatibleについて。
    • 私たちのHUB DBのワークロードは非常に重い。
    • Auroraによって素早くリカバリできる。
    • Survivable cacheやFault injection queriesの恩恵が受けられる。

さいごに

SCTやDMSが活用された良い事例だと思います。OracleからRDS for PostgreSQLへの移行事例ですが、Amazon Aurora PostgreSQL-compatibleがリリースされたことで、今後より一層Auroraの活用が進みそうですね。