PostgreSQLエンタープライズ利用の指針が続々公開へ：Database Watch（2013年5月版）（2/2 ページ）

[加山恵美，＠IT]

設計運用WG：ほかのRDBMSからPostgreSQLへの移行フレームワーク

　設計運用WGの研究テーマは異種RDBMSからPostgreSQLへの移行についてです。PGECが会員へアンケートしたところによると、現在利用しているRDBで最も多いのはOracle Database、次いでPostgreSQL。

　実際「現在はOracle Databaseを運用しているが、PostgreSQLへの移行が気になる。しかし、移行作業の進め方やコストが不明なので情報収集したい」と考えている会員は少なくありません。そうした声に応えるべく、WGは移行時に留意すべき事項、難易度の判断、調査方法などを報告書にまとめました。

Oracle DatabaseからPostgreSQLへの移行プロセスの見積もり指針も公開

　発表を行ったのはTISの中西剛紀氏（写真）。中西氏はPostgreSQL移行で成功と言えるのは「当初見積もりと実作業の差が小さいこと」だと明言。かけた時間やコストではなく、見積もり通りに作業が進んだかどうかということです。これは商用もオープンソースも関係なく、移行プロジェクト全般に通じる鉄則ですね。

　となると見積もり段階で調査を徹底し、正確な見積もりを出すことが鍵となります。言い換えればアセスメントの精度を高めること。そのために移行元・移行先のシステム要件と機能差異を正しく把握することが肝要となります。ただし、完ぺきな見積もりを出したはずでも予定外の作業が発生することは避けられず、ある程度の作業量増加は見越しておく必要があります。

　今回発表された報告書には移行作業のフレームワークから、各段階における作業内容や手順などが細かく具体的に記されています。まさに会員らが知りたかった内容だったのではないでしょうか。興味のあるかたはダウンロードして確認してみてください。

移行フレームワーク

　WGが実際にアプリケーション移行を実施したのは、Commander4J（リンク）というバーコードを作成するためのアプリケーションです。アプリケーション側が公式に対応しているデータベースにPostgreSQLがないことがこのアプリケーションを選択した理由です。

　SQL変更部分の抽出にはdb_syntax_diff（リンク）を使用します。

　db_syntac_diffはOracle DatabaseからPostgreSQLへアプリケーションを移行する場合に、修正が必要となる部分を検出するツールです。

　移行時に活用できるツール類が多数提供されていることから、実際の移行では、多くの工程を自動化でき、工程全体の90％はテストに充てられたということです。

　2013年度はこの活動を「移行WG」と名称を改め、移行時のガイドをさらに詳細化するように研究を継続し、費用見積もりのベースとなる成果物を目指すそうです。加えて「設計運用WG」を新設し、可用性・性能監視・バックアップなどからテーマを選定して設計や運用により焦点を当てた研究を目指していくようです。

時間の確保に苦労しつつも、コミュニティならではの新発見が

　活動を振り返り、参加者が苦労したことは「ミーティングや調査に時間を確保するのが大変だった」と、参加者おのおのが別業務を抱える中で作業時間を捻出することだったようです。一方、技術者同士で交流する機会が得られたことや、実践的なノウハウが得られたのは収穫として挙げられていました。なかにはPostgreSQLノウハウだけではなく、報告書をまとめる経緯でドキュメンテーション技術が参考になったという声もあったとか。

　一般的にオープンソースで集う場というと「ギーク」な方をよく見かけますが、このPGECはエンタープライズへの導入を掲げていることもあり「スーツ族」が圧倒的多数です。人数も決して少なくありません。長らく商用データベース製品と関わり実績を積んだ方々が本腰を入れてPostgreSQLに取り組む様子を見ると、今後エンタープライズへのPostgreSQL導入は着実に進むという気がしてきます。

　5月下旬にはカナダでPostgreSQLのグローバルなイベント「PGCon 2013」（リンク）が開催されます。今回のWG活動報告をグローバルな場でも発表することになるそうです。参加者は「PostgreSQLのチームジャパン」と自らを称し、意気揚々でした。日本はもとからPostgreSQLの活動が活発ですから、世界を圧倒できるかもしれませんね。