AWS Innovateのデータベース移行のオンラインセッションのメモ（2019年10/11月）

はじめに

2019年10月～11月のAWS Innovateのデータベース移行のオンラインセッションを見たのでまとめ。

• https://aws.amazon.com/jp/about-aws/events/aws-innovate/sessions/#db-migration

※このページはリンクが切れそう

オンラインで公開されていたのは以下の3つ。最初の一つは初心者向けなので割愛し、残り2つをまとめた。なお、セッションの資料はPDFでダウンロードできたのでそちらを参照した方が良い。

• 【データベース移行】データベースの移行で考えなければならないこと
• 【データベース移行】データベース移行アンチパターン その1
• 【データベース移行】データベース移行アンチパターン その2

【データベース移行】データベース移行アンチパターン その1

• 現行DB環境分析におけるアンチパターンとベストプラクティス

  • データベース移行のプロセス
    • 検討・設計・変換・移行・運用・最適化
    • 検討フェーズが本資料の対象（特に移行要件、移行方式の事前検討、性能分析等）
    • 検討フェーズは机上の検討、およびPoCをとおしてDB移行が妥当か検討
  • 移行判断の流れ
    • 机上検討・PoC＋工数見積もり・移行判断

• 現行DB環境分析におけるアンチパターンとベストプラクティス

  • アンチ：現行環境の性能分析をせずに既存のHWスペックをベースに検討している。
    • 移行元のCPUやメモリのリソースをそのまま移行先のDBのリソース値としている。
    • 現行DBのCPU使用率が20%程度なのに、そのときのCPU、メモリのリソースを移行先に適用しない。
    • なぜなら、オンプレミスのサイジングは容易に拡張できないなどの制約があり余裕を持たせがちなので
    • ベスト：現行のリソース分析を実施し、サイジングを実施する。
  • 現行環境の分析ポイント
    • CPU使用率
    • メモリ使用量
    • I/Oスループット
    • IOPS
    • ストレージ容量
  • 分析によって、AWSで適切なインスタンスタイプ・サイズが選択できる
  • よくある落とし穴
    • I/Oスループットでは、オンプレミスはバックアップ時にピークがくることがある。
    • クラウドならバックアップI/Oはスナップショットで取得できるので、除外して分析する。
    • それにより、必要なピークI/Oはオンプレミスに比べて低くなる。

• データ移行方式選定におけるアンチパターンとベストプラクティス

  • アンチパターン：移行に十分な停止時間があるのに、レプリケーション機能を用いて移行する。
  • レプリケーションは停止時間が取れない場合に利用する。停止時間が取れるなら同一DBエンジンならダンプツールで可。
  • ダンプツールとレプリケーションの比較
    • ダンプツールはシンプル
    • リスクが低く、移行コストが低い。

• AWS Database Migration Service(DMS)

  • 異なるデータベース間で最小限のダウンタイムで移行可能とするサービス
  • 低コストで利用可能
  • DMSを使ったデータ移行手順のイメージ
    • クラウド上にDMSインスタンスを作成
    • ソース・ターゲットのエンドポイントを作成
    • 移行タスクを作成・実行
      • 対向タイプ（Full, CDC）、対象テーブル、テーブル等のマッピング、その他
  • DMSを使用した最小限のダウンタイムの実現の手順
    • 初期データ移行（Full Load）
    • データ更新（CDC：差分）
    • データ移行
    • アプリケーション停止　※ここからダウン
    • 最終差分データ適用（CDC）
    • アプリケーション再開

【データベース移行】データベース移行アンチパターン その2

• DBエンジン選定におけるアンチパターンと指針

  • ワークロード特性にフィットしないDBエンジンを選定している
    • ショートトランザクションが多いなど
  • 現行ワークロード特性に適したDBエンジンの選定方法
    • 現行ワークロード分析
      • ワークロード（オンライン・夜間バッチ）・時間帯別にピーク時間を分析
      • OracleならAWR/Statspackレポートで分析
      • トランザクション量、Readsの多さなど
    • 移行先DB候補の各エンジンの特徴を知る
      • MySQL、PostgreSQLならOLTP性能が高い、RedshiftならOLAP性能が高いなど
      • 目標レスポンス時間、結合方法、インデックス、制約、移行元との文法互換性
    • 移行先DBエンジン候補選定
    • DDL・SQL移行難易度評価
      • Schema Conversion Tool(SCT)でDDL・SQLの移行難易度を評価し、工数を加味して選定
      • SCT
        • GUIアプリケーション
        • 異なるDBエンジン間のDDL・SQLを自動変換
        • アセスメント結果（移行難易度、自動変換率等）をレポート出力
        • 自動変換できない場合の修正の推定工数や修正方法も出力
        • ソースコードの自動変換もできる

• 性能検証におけるアンチパターンと指針

  • アンチ：移行先DBエンジンが性能要件を満たすか確認できていない
    • 現行本番ワークロード相当の処理で確認できていない
    • 現行との性能の比較ではなく、性能要件を確認する
  • 指針
    • 本番と同じデータ・ワークロードを再現するのがベスト
    • ミニマムで性能検証する場合のポイント
      • 現行ワークロードに占める割合の高いSQLを選定
      • 前提条件をあわせる
      • 性能要件を満たすか確認する
    • 現行ワークロードに占める割合の高いSQLを選定
      • ワークロード・時間帯別に選定
      • OracleならAWS/Statspack等で割合の高いSQLを選定
      • 時間が長いSQLは単体性能を計測
      • 実行回数が多いSQLは同等の並行度でレスポンス・スループットを計測
    • 前提条件をあわせる
      • 本番相当の構成を使用する（Multi-AZ、インスタンスタイプ、ノード数等）
      • オブジェクト
        • パーティションやインデックスも。統計情報取得
      • データ
        • データ量、値の種類、偏り
        • Where句の条件のバリエーション（例えばキャッシュヒット率があがらないように）
      • キャッシュ
        • ストレージ・OS/DBのキャッシュの状態をオンプレと合わせるのは不可能。移行後を想定して性能要件を満たすかを検証。
      • 前提条件があっているか確認観点例
        • 実行時間（Client）、実行時間（DB）、CPU時間、待機時間、IO量、実行計画・実行統計
        • 実行時間（DB）なら、OracleはElapsedTime、PostgreSQLならクエリログのduration
    • 性能要件を満たすか確認する
      • 1回の実行時間が長いSQL
        • 単体性能のレスポンス時間を計測
        • バッチ処理なら、バッチウィンドウから導出
      • 1回の実行時間が短いが並行度の高いSQL
        • 性能要件がないなら、平常時のレスポンス時間とピーク時のスループットから導出