AS400基幹システムのGoogle Cloudマイグレーション：レガシーDB2 for i からPostgreSQLへの一貫支援

レガシーDB2 for i と PostgreSQL の仕様差異が大きく、マイグレーション方針が立てられない

IBM i上のDB2 for iには、オープンDB標準とは異なる固有仕様が数多く存在します。オブジェクト名の大文字小文字の扱い、ストアドプロシージャの構文差異、独立コミット（autonomous）処理の制約、シーケンス値取得の差異、ROW_NUMBER等のSQL挙動差異、エラーメッセージの文字化けなど、PostgreSQLとの仕様ギャップは多岐にわたります。
加えて、周辺アプリケーションが発行するSQLの特性まで踏まえた命名ルールの設計が必要であり、「DDLを変換すれば完了」という単純なマイグレーションは成立しません。本開発に進む前に、こうした仕様差異をどう吸収するかの方式設計が定まっておらず、脱AS400に踏み切れない状況にありました。

脱AS400を阻む三重の壁：データマイグレーション・バッチ移行・クラウド運用まで不確実な論点が山積

DB仕様の差異以外にも、レガシーシステムからのマイグレーション全体を通じて不確実な論点が複数重なっていました。データ移行においては、IBM i 特有の文字コードや桁数の扱い、NULL・空文字の不統一、BLOBを含むテーブルの移送方法など、標準的なエクスポート・インポートでは吸収しきれないデータ品質上のリスクが潜んでおり、マイグレーション本番での事故が懸念されていました。バッチ・RPG処理についても、夜間バッチや画面起点のファイル取込がAS400固有の実行環境と密結合しており、脱AS400後にどのような実行基盤へ再設計するかの方針が定まっていませんでした。さらに、マイグレーション後の運用体制も課題でした。クラウド環境での保守接続・バックアップ・リカバリ・障害時のネットワーク切替・DR対応まで、移行プロジェクトと並行して運用設計を一から整備する必要があり、システム刷新後に「運用できない」状態に陥るリスクを抱えていました。

大規模DBオブジェクトのマイグレーションを高品質・属人化なく完遂

テーブル1,262件・プロシージャ358件・ファンクション35件・トリガー5件を含む大規模レガシーDBオブジェクトを対象に、変換ルールの方式化・進捗管理表・多層テスト戦略を組み合わせてマイグレーションを完遂しました。自動変換だけに頼らず、ラッパープロシージャの実装・変換スクリプトの個別調整・エラー再確認まで対応。変換結果の品質を担当者の属人的なスキルに依存せず、方式として再現可能な形で進めました。

バッチ性能リスクをマイグレーション本番前に特定・切り分け

バッチ処理時間を事前調査段階で実測した結果、PostgreSQLへのマイグレーション後に処理時間が増大するケースを早期に特定。問題なく高速化できる処理と追加対策が必要な処理を明確に切り分け、残課題として次工程に引き継ぎました。「マイグレーションできそうか」を楽観視せず、実測に基づく判断で本番後のトラブルを事前に潰すアプローチを採用しました。

システム刷新・マイグレーション完了と同時に「運用できる」状態まで構築

マイグレーションプロジェクト完了時点で、8種のシステム管理マニュアル（DBリカバリ・GCEリカバリ・ネットワーク切替・環境切替・アラート確認・IAP接続・パッチ適用・証明書更新）を整備。東京リージョン（本番）/ 大阪リージョン（DR）の2リージョン構成・接続冗長化・PITR・切替手順まで含め、事業継続性を確保した安定運用基盤をシステム刷新と同時に整備。モダナイゼーション・DX推進の基盤として、移行後すぐに本番稼働できる体制を実現しました。