オンプレ DB をクラウド上の PostgreSQL へ～ DB移行時のSQLアセスメントを自動化・省力化するには？ ～State-of-the-Art Solution for Database Migration
DB・アプリ移行を促進するキーソリューション

株式会社インサイトテクノロジー
趙明春（チョウ メイシュン）
1アジェンダ•••••••

弊社事業・製品紹介
PostgreSQLへの取り組み
DB監査とPISO製品の概要
Insight Database Testing(IDT)の紹介
AWS Schema Conversion Tool(SCT)の紹介「IDT + SCT」移行ソリューション
• オンプレDBからクラウドPostgreSQLへのキーソリューション
• 移行モチベーションと移行時課題• 移行コスト評価プロセス
IDTの事例• テスト網羅性向上、テスト工数削減2インサイトテクノロジーの強み「データ × AI」から得た Insightで新しく豊かな社会を創造し続けます
データ活用からお客様が求める「本質」を得られる「インサイト・テクノロジー」の実現へ

3

製品群とPostgreSQL向け製品••

PISO: データベース監査ツール••

Insight Database Testing: 本セッションの主役、DB・アプリ移行アセスメント・テスト自動化ツール•

Insight Qube: 世界最速のデータベースマシンをコンセプトにしたプラットフォーム
企業でのデータ活用にフォーカス、マルチデータベースによる運用性、コストパフォーマンス、拡張性の向上を実現

Delphix: データベース仮想化ツール(Database as Code)
本番環境と同等のテスト用データを短時間で作成し、「テストサイクルの短縮」「効率的なバグ修正による品質向上」を支援

Qlik Replicate: マルチデータベース対応のリアルタイムレプリケーションツール
データ活用基盤の再構築において、既存システムに負荷をかけずに迅速で安全なデータ統合／移行を実現

4

PostgreSQLへの取り組み•

独自のPostgreSQL監査ロギング拡張機能を自社開発•

自社製品でデータ蓄積・管理に用いるデータベースをPostgreSQLへ移行•AWS PostgreSQLの監査ロギング拡張機能pgAuditのOSSコントリビュート

5

データベース監査ツール PISO•

メモリ参照型でDB性能を劣化させず、低負荷でアクセスログを取得•

特権ユーザーも含めたあらゆるアクセス経路のログを取得し、保全、警告、検索•

マルチデータベース、クラウドに対応•

データベース監査市場にて10年以上連続シェアNo.1、国内導入企業数は700社以上

6

Insight Database Testing(IDT)とは•データベース/アプリケーションの移行アセスメント・テスト自動化ツール•

マルチデータベースとクラウドサポート、移行の作業コスト削減を支援•

IDTの機能•SQL Capture•

SQL Test•

SQL 改修7

SQL Capture•

本番環境のSQLを自動的にキャプチャーし、重複するSQLをグループ化して要約表示•

弊社独自のDirect Memory Access機能によりDB性能にほとんど影響を与えない

8

SQL Test•

SQLを移行先の環境や設定変更後の環境で実行・評価•

SQLテストで実施できるテスト項目•••

SQL互換性テスト（実行 or パース）
パフォーマンス比較（実行時間比較）SQL修正結果の動作確認

9SQL改修•

実行エラーになったSQL、実行時間が遅くなったSQLを改修、テスト•

Test Reportで失敗SQLをドリルダウンし、GUI上でSQLを変更しそのまま実行しエラー修正

10ミッション: Oracle DatabaseをAWS上のPostgreSQLへ•

背景• オンプレDBをRDSやAuroraなどのマネージドデータベースへ移行したいと考えるお客様が非常に多くなってきている•

移行のモチベーション• クラウドへの移行• オンプレDBサーバーの稼働を自社管理するコストを削減• クラウドのセキュリティの方が安全という評価• 性能が足りなくなってきたときに容易にスケールアップ• DBエンジン変更• Oracle Databaseのライセンスコストの増加に対する備え• Oracle DatabaseからPostgreSQLへの移行事例が増えている•「IDT + SCT」を融合した移行ソリューション
• Insight Database Testing(IDT)• AWS Schema Conversion Tool (SCT)• AWS DBへの移行に伴うアプリケーション修正コストの評価を劇的に高速化
11クラウド移行のネックは？
•データベースの移行とは••••アプリケーションの移行がネック••

テーブルなどのスキーマ移行
テーブルに含まれるデータ移行それだけで十分でしょうか？
データベースを利用するアプリケーション移行こそがクラウド移行の鍵

アプリケーション移行の課題••••

DBにより使用できるSQLの方言が異なる• 特にOracle固有のSQLを多く使っているアプリケーションは修正コストが非常に大きい
アプリケーションで実行されるSQL全文そのものがソースコードに書かれていない• ORマッパー経由で実行されていたり、コードで文字列連結により組み立てられていたり• 複雑な場合、実際にどのようなSQL文となって実行されるか確認が難しい
アプリケーションが巨大すぎてどこからSQLが発行されているかわからない
SQLが把握できたとしても、そのSQLをPostgreSQLで実行できるかわからない12

アプリケーション移行コストの見積もりの課題•

非現実的な見積もりとなるケース• 実際に実行されているSQLがわからない• そのSQLがPostgreSQLで実行可能かわからない• アプリケーションコードに精通したエンジニアが工数をかけて調査が必要•

実際に発行されるSQLが特定できないと、• リスクヘッジを重ねた非現実的な見積もりベースのコストとなり• データベースのクラウド移行自体をあきらめた話も。。。

13

IDTを使ったアプリケーション移行評価の流れ
••
•••

•

ソースDBのSQLを取得［ SQL Capture機能 ］
評価SQLセットを作成
ターゲットDBで実行したいSQLセット
ターゲットDBを選択
テーブルなどオブジェクトが事前に用意されている前提※IDTでは行えません
アセスメントを実行
評価SQLセットをターゲットDBで実行［ SQL Test機能 ］
実行結果の確認
実行できたSQLの数、実行エラーになったSQL、遅くなったSQLを一覧で表示
SQLの詳細確認と実行
アセスメントサマリー画面からドリルダウンし、SQLの詳細画面に遷移、SQLの編集と実行、および実行したSQLを保存［ SQL 改修機能 ］
14

AWSスキーマ変換ツール(Schema Conversion Tool、SCT)•AWSより無償で提供されAWSへのDB移行を強力に後押し•

ソースDBのスキーマと大部分のカスタムコードを自動変換•

ビュー、ストアドプロシージャ、関数などをターゲットDBと互換性のある形式に自動変換•異種データベースを簡単に移行できる•IDTで実行されない部分にSCTを利用•

AWSへのDB移行に伴う、アプリケーション移行影響調査を劇的に省力化

15

IDTとSCTを融合したAWSへの移行評価プロセス•

手順1: 現行DBで実際実行されているSQLの収集•

手順2: (SCT)現行DB同様のテーブルなどオブジェクトを事前に移行先DBに用意•

手順3: 収集したSQLを移行先DBで評価•

手順4: 評価結果の確認•

手順5: (SCT)実行できなかったSQLをSCTで修正•

手順6: 修正したSQLを再実行

その結果：
•

多大な工数をかけてソースコードを分析し得ていた実行SQL情報を簡単取得
アプリケーション修正移行コストの見積もりを大幅省力化•

SQLの収集～SQLの評価～修正候補の確認を効率よく行うことが可能
AWSへのアプリケーション移行評価のプロセスをさらに省力化•

多くのアプリケーションを抱える企業でも、各アプリケーションの移行難易度の評価が行いやすくなる
16手順1: 現行DBで実際実行されているSQLの収集•実行されるSQLを把握困難な状況でも、移行にあたって考慮すべきSQLを効率よく収集可能17

手順2: (SCT)現行DB同様のスキーマを事前に移行先DBに用意•

IDTで収集したSQLを実行する前に、実行先DBにテーブルを用意しておく•

SCTのマウス操作のみで簡単にテーブル作成、自身でSQLスクリプトなどを手動作成不要

18手順3: 収集したSQLを移行先DBで評価•

収集SQLを移行先DBに対して実行•

IDTの実行モード•••「パース」モード
SQLの文法チェックのみ
でSQL文は実行しない
OracleとPostgreSQLの方言差異の文法チェックのみ行うケース「実行」モード
バインド変数を実際に適用したSQL文の実行などを確認・評価したい

実行モード以外にもいくつかのオプションを選択し実行可能

19

手順4: 評価結果の確認•

移行先DB(ターゲットDB)での評価結果をチャートなどで確認可能•収集したSQLのうち何割が実行できなかったかが一目瞭然•

結果をドリルダウンすることで実行できなかった
SQLを表示できる•

エラーになったSQLをエラーメッセージとともに確認可能

20

手順5: (SCT)実行できなかったSQLをSCTで修正•

SQLエラーが複雑で難しい場合、SCTで修正•

IDTには、エラーとなったSQLを、SCTで取り込みやすいファイル形式でダウンロードする機能が備えてある•

よって、IDTで収集し評価エラーとなった
SQL情報を簡単にSCTに反映可能

21

手順6: 修正したSQLを再実行•

SCTでの修正結果を、簡単にIDTへ取り込み可能•

再度IDTでアセスメント実行し、修正後のSQLに対し評価可能•IDTは、実行時間の目安情報を取得可能、実行速度が遅くなったか比較可能• 著しく実行速度が低下している場合、SQLを修正して再実行

22

「IDT + SCT」移行ソリューションの〇✕クイズ
1.

2.
3.

アプリケーションコードに書かれたSQLは全てIDTで取得できる
IDTのアセスメントに失敗したSQLは、全てSCTを使って修正できる
SQLがターゲットDBで実行成功したら、ソースDBと同じ結果となる••

更新クエリ(INSERT、UPDATE、DELETE)が同じ結果となる選択クエリ(SELECT)が同じレコード数・順番となる

[答え]
1.

2.
3.

✕ 実行されるSQLのみ取得。実行頻度の低いSQLの網羅性を高めるため、••

一週間～一か月など、ある程度のまとまった期間のSQLを収集週次・月次バッチで動作するSQL情報も取得する•••

ORDER BYのない選択クエリ
暗黙の型変換や有効桁数
空文字やnullの扱い✕ それでもエラーになるSQLは手動で修正する必要あり✕ 現在IDTでは実行結果の一致・不一致の確認手段を備えていない。
要確認の留意事項：

23

IDTの事例•

お客様要件(計3社)
オンプレOracleからAmazon PostgreSQLへの移行
移行におけるアセスメント及び移行コストの見積もり•

お客様はIDTに何を期待されているか？
••••

移行実施前の影響調査段階に、アセスメントツールとして使用したい非交換SQLの割合や種類を確認し、それに基づき移行コストを見積もりたい
移行前後の性能比較を行い、アプリケーション書き替えコスト評価の1つの指標にしたい

弊社から「IDT+SCT」併用ソリューションを提案••

変換できなかったSQLの割合から、アプリケーション書き換え負荷を判断
実行モードで取得されるSQL実行時間情報から、性能比較を実施

24

Insight Database Testing をおためしください•

AWS Marketplace上でIDT、PISOを提供開始、簡単に利用可能•

AWS Marketplace上の製品ページ• アプリケーションテストツール「Insight Database Testing」
https://aws.amazon.com/marketplace/pp/B08JQ8N5XG• マルチデータベースに対応した監査ツール「PISO」
https://aws.amazon.com/marketplace/pp/B08JQ93XX7•

IDTの対応環境

25

ご清聴ありがとうございました。

記載されている会社名、サービス名、製品名は、株式会社インサイトテクノロジーおよび各社の商標または登録商標です。
Copyright 2021 Insight Technology, Inc. All Rights Reserved.

26