Amazon Web Services ブログ

農林中央金庫様、情報系システムをAmazon Auroraへ移行し、13年間で100億円以上削減へ（Part 2/3）

PART2：Oracle DatabaseからAmazon Auroraへの移行 -移行作業編-

PART1 では、農林中央金庫がコスト削減の重要なポイントである Amazon Aurora の採用に至った経緯や、ベンダーの NTTデータとどのような点を評価していったかを解説しました。

PART2 では、Amazon Aurora の採用に至った後、移行フェーズにおいて実際に Oracle Database から Amazon Aurora へ移行する際にどのような非互換対応を実施したのか、性能試験時に考慮したポイントについて、お客様の声をご紹介させていただきます。

非互換対応について

データベース選定時に実施した非互換調査では、いくつかの対応が必要な部分が存在することを認識していました。しかし、ロックの取得範囲の違いによる障害など、発生タイミングに依存して有無が変わる事象については、机上では影響範囲を網羅するのが難しい部分がありました。そのため、試験を通じて詳細な確認を行いました。非互換対応として実施したものの一部をご紹介します。

項番 概要 内容
1 暗黙の型変換 DB定義とSQLクエリでカラムのデータ型の不一致がある場合、Oracleは自動的にデータ型が変換され正常終了するが、PostgreSQLではエラーとなる
2 サブクエリやTBLの別名定義 OracleとPostgreSQLで、表の別名の使用ルールが異なる（OracleはFrom句のサブクエリに別名を使用しなくても良いが、PostgreSQLでは必須など）
3 集約関数のネスト 集約関数（avg、max、sumなど）をネストして使用する場合、Oracleは正常終了するがPostgreSQLではエラーとなる。

また、上記の他に対応に苦慮した非互換としては次のものがあり、それぞれ以下の表の通り対応を進めました。

項番 概要 内容
1 Database Link(異なるインスタンスを跨ぐ更新) 同一処理において複数のDBインスタンスに対して更新を行うような処理に対しては、Database Linkによる参照ではなく、「DB①に対する接続情報」、「DB②に対する接続情報」を定義し、これらを使い分けてDB更新するような対応が必要となり影響も大きかった。
2 PL/SQLのトランザクション制御（エラー制御の変更） 処理内のとあるSQLで一意制約が発生し、その後管理テーブルにSTSを書き込むといったような処理がある場合、トランザクションを分割させる必要がある。（同一トランザクションで処理しようとすると、後発のSQL（管理テーブルへの書き込み）が必ずエラーになる。）
3 空・Nullの扱いの差 PostgreSQLでは、NULLと空文字の違いが区別されるため、例えば「SELECT * FROM テーブル１ WHERE KEN_CD = ”」という構文においてOracleでは取得出来ていたレコードが取得できなくなってしまう。影響の大きかった非互換のひとつ。
これに対する対応として、移行時にDBデータを空文字⇒NULLに変換する対応と、AP（JAVA）-DB（SQL）間のオブジェクト変換時に空文字⇒NULLへのコンバータ処理を新たに作成して対応している。）

試験方法・方針について

本プロジェクトでは品質を最優先としており、本番データをマスク化した上で活用しながら、全機能の十分な試験を実施しました。本番データの活用によって、ほぼ全ての SQL について現行環境と新環境の比較を行うことができました。また、合わせて影響度合いに応じてチューニングを検討しました。さらにテスト効率の向上を目的として、テストデータの準備や現行・新環境の比較などの定型作業の自動化を図り、作業効率の向上に努めました。

試験時のポイント：

  • 全ての SQL について空振りがない形で現行・新環境の比較を実施し、機能単体の正当性を確認
  • 日々の全更新データを本番環境から流用し、データの網羅性を担保
  • 想定されるピーク時のワークロードをツールで再現し、性能試験を実施
  • 現行本番との比較確認やデータの準備を自動化・定型作業化することで効率化

また、試験においては製造・試験の生産性なども確認し、事前の想定から大きな乖離はありませんでした。さらに、NTT データに即時のチューニングが可能な体制を構築していただいたため、パフォーマンスが劣化する SQL があった場合も、業務要件上必須の性能が満たせるよう、迅速にチューニングを施すことで影響を最小限にしつつ対応する事ができました。

性能試験について

性能試験では、不適切な実行計画が選択されることによるパフォーマンス劣化が多くみられました。特に、数百万行以上の大規模テーブル同士の結合クエリでは、そうした傾向が顕著でした。そのため、ヒント句を活用して最適な実行計画を選択させる対応を行いました。また、アプリケーション側で大量の SQL を発行するような Loop 処理についても、1回あたりの通信時間の増加によって処理時間が伸びる傾向があったため、SQL 発行回数を減らすといった、アプリケーション側でのチューニングも実施する場面がありました。

Part 3 に続く。