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

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

はじめに

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

IMG_0193

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

IMG_0192

レポート

  • コマーシャルなライセンスは時間が経てば経つほどコストがかさむ。
  • 最高水準まで行ったらあとはどのように下げるかが課題になる。そん時どんな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にまとめる場合。
  • 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の活用が進みそうですね。