基幹データベースをPostgreSQLに移行!?その意外な理由とは? －富士通の技術者に聞く！PostgreSQLの技術－
PostgreSQLインサイド

企業システムで運用する商用データベース製品をオープンソースソフトウェア（以降、OSS）に置き換えることで、企業はさまざまなメリットを享受できる。コスト削減はもちろんのこと、コミュニティーで実装される最新技術をいち早く活用して、新たなシステムを立ち上げることも可能だ。しかし既に稼働しているデータベースを別のデータベースにリプレースするためには、リスクも伴う。そのため、OSSのメリットは十分認識しつつも、導入に躊躇して現状のデータベースをやむなく使い続ける企業も少なくない。そのような企業に対して、富士通は「富士通版PostgreSQL」へのデータベース移行をお勧めしている。ベンダーが独自に提供するデータベースをOSSベースのデータベースに移行することで、何が起きるのか？その真相に迫る。

今回は移行について伺います。データベースというと、ベンダーが独自に提供する製品が根強いという印象がありますが、OSSへの移行の要件は多いのでしょうか

山本
そうですね。近年、増加しています。当社では特にPostgreSQLの採用が目立ち、昨年の同時期と比較すると5倍に伸びています。とはいえ、既に長年安定稼働しているシステムのデータベースを異なる製品にリプレースするとなると、これまでと同様の性能や運用を維持できるかというリスクが生じます。また、データベース製品ごとにSQLの仕様も若干異なりますから、それを利用するアプリケーションの改修やテストも必要になるでしょう。こうしたことから、なかなかPostgreSQLへの移行に踏み切れない企業も多いようです。

移行をする、または移行に注目する企業に何か共通の傾向はありますか？

山本
以前はコスト削減のため、単体で稼働しているシステムやパッケージソフトウェアに組み込まれているデータベースをPostgreSQLに置き換えたいという要望が多かったのですが、最近は新しい業務にPostgreSQLを適用することが増えていて、その新規システムと既存システムの連携性をよくしてビジネスを活性化させたいという要望から、業務システム全体のデータベース基盤を見直したいという相談も受けるようになりました。業務システムを構成する複数のデータベースを順次PostgreSQLに置き換えていき、最終的にはデータベース基盤すべてをPostgreSQLで構成したいというニーズが増えてきているように感じます。

移行への注目は大きくなっているのですね。しかし、移行するということは簡単ではないとも思います。何かノウハウはあるのでしょうか。

渡邉
以前より、他のデータベース製品から当社の「Symfoware Server」への移行支援を実施してきていますが、そこで培った移行ノウハウで移行支援メニューを体系化して、アセスメント方法や移行ツール、移行ドキュメントを整備してきました。PostgreSQLへの移行には、このSymfoware Serverで蓄積してきた豊富な移行ノウハウを活用して、同様の支援メニューを用意しています。そして、そこで得たノウハウはPGECons（注1）などの外部コミュニティーに参画することで、PostgreSQLの技術情報蓄積にも貢献してきています。

• 注1
  「PostgreSQL Enterprise Consortium」の略で日本語表記は「PostgreSQL エンタープライズ・コンソーシアム」。PostgreSQLがエンタープライズの業務システムに適用できるようにするため、PostgreSQL本体および各種ツールの情報収集と提供、整備などの活動を通じて、ミッションクリティカル性の高いエンタープライズ領域へのPostgreSQLの普及を推進することを目的として設立された団体。

ノウハウがツールやガイドの形になっているのですね。ところで移行というと、互換機能を提供するという考え方もあると思いますが、互換機能は提供していないのでしょうか。

渡邉
富士通版PostgreSQLにも、他社データベースとの互換機能が備わっています。これを利用すれば、確かに商用データベースからの移行工数を最小限に抑えることができるでしょう。ただし私たちは、必ずしもこれが常にベストな方法だとは限らないと考えています。

と言いますと？

山本
確かに互換機能を使えば、データベース移行に伴うアプリケーションの修正作業は最小限で済みます。しかし結果的にそのアプリケーションは、依然として元々使用していた商用データベースの仕様に縛られ続けることになります。せっかくPostgreSQLを導入しても、アプリケーションが商用データベースの仕様に縛られたままでは、OSSのメリットも半減してしまいます。

「オープンソースならでは」「PostgreSQLならでは」のメリットは、確かにこの方法では手に入れることができませんね。

山本
商用データベースとの互換性を保つためにベンダーが独自に実装した部分は、ブラックボックスになるので、オープン性は損なわれると考えるべきでしょう。その結果、商用データベース製品のベンダーロックインから脱出するためにPostgreSQLへ移行したはずなのに、結局はまた別のベンダーにロックインされてしまうような羽目に陥りかねません。そうした事態を避けるためにも、私たちは可能な限りお客様の資産をPostgreSQLベースに修正して移行することを提案しています。

修正箇所が多岐に渡る場合には、ある程度コストがかかるかもしれませんね。

山本
そうですね。互換機能をフル活用した場合と比べると、やはりコストは多くかかるかもしれません。しかし先ほどお話ししたとおり、たとえオープンソース製品に移行したとしても、オープン性が失われてしまってはそもそもの導入目的は達成できません。PostgreSQLのオープン性がもたらす将来のイノベーションを考えての移行であれば、多少のコストがかかったとしても、これを機にPostgreSQLへの対応を一通り済ませておくことが望ましいと考えます。

その際のハードルを可能な限り低くすることが、データベース移行支援の目的なのですね。

山本
そのとおりです。ただ、お客様が抱える事情によっては、もともと使っていた商用データベースとの互換性を維持した方がいいケースもあります。従って「ここはオープンで」「ここは互換性維持で」といったように、ケースバイケースで柔軟に対応することも多いですね。

次に、移行アセスメントについて教えてください。

渡邉
移行アセスメントは、お客様が現在保有しているデータベース資産の情報をいただいた上でその内容を分析・評価して、富士通版PostgreSQLへの移行にどの程度の工数がかかるか、あるいはどんな技術的な課題が存在するかを洗い出すサービスです。この結果を基に、移行に踏み切るかどうかをお客様に判断していただきます。

「データベース資産の情報」とは、具体的にどのようなものを指すのでしょうか？

渡邉
現行のデータベースのDDL定義や独自のプロシジャのSQL、あるいはアプリケーションのソースコードなどの情報です。お客様からこれら情報をいただき、それを富士通の技術者が分析し、富士通版PostgreSQLへの移行に要する作業工数を見積もります。この「アセスメント」が移行の第一歩としてとても重要な役割を果たします。アセスメントの結果をまとめた報告書には全体の工数だけでなく、修正作業が必要な箇所1つ1つにつき、その詳細な内容や難易度、そして「移行ツールを使った場合の工数」と「移行ツールを使わなかった場合の工数」をそれぞれ算出して提示しています。

図：アセスメント結果のイメージ

工数やコストの概算から判断できるのですね。アセスメントが完了した後には、どのような作業を行うのでしょうか？

渡邉
アセスメント結果を基に、お客様がご自身で移行作業を行う場合もありますが、当社が移行作業を「移行サービス」として請け負う場合もあります。お客様の状況に応じたサービスを用意しています。

予算やリソース、時間的な制約などの都合に応じて、柔軟に支援の範囲を選択できるというわけですね。

渡邉
はい。お客様がご自身で行う場合は移行ツールや移行ガイドを提供いたします。さらにテクニカルデスクという形での支援もあります。

図：移行サービスの体系

移行ツールにはどのようなものがあるのでしょうか。

渡邉
例えば、オープンソースでは他社データベースからスキーマやデータを抽出し、PostgreSQL用に変換するツールがあるので、データの移行はそのツールを使用してできます。当社からは、アプリケーションの移行ツールを提供しています。このツールを使用すると、ソースコードなどの記述を単純に置き換えるだけで対応できる作業は、自動的に処理できます。そのため、ほとんど移行工数が掛かりません。ただ、ツールによる自動置き換えだけでは対応しきれないものもあり、中には富士通版PostgreSQLに対応する機能がないために、個別にプログラム開発などで対応しなくてはならないケースもあります。

移行ツールですべて置き換えるということは、やはり難しいのでしょうか。

渡邉
そうですね。アプリケーションは一つひとつ違いますから、それぞれの処理を考慮して移行しなければなりません。ですから、すべてを一括置換することは現実的に難しいです。この問題を少しでも解消するために、移行ツールにかけた際に自動置き換えできない部分には具体的なヒントを記載し、効率的に修正できるようにしています。

移行する企業の傾向として、単体の移行から基盤全体を移行するという要件が出てきていると伺いましたが、このようなケースでは、移行の難易度は高くなるのでしょうか？

山本
確かに、複数のシステムで構成された大規模な業務システムの場合、やはりデータベース製品の置き換えは一筋縄ではいきません。すべてを一括して置き換えられればいいのですが、それではあまりにもリスクが高すぎます。かといって、1台ずつPostgreSQLに入れ替えていけばいいかというと、それはそれでさまざまな課題に直面することになります。その最たるものが、データベース間の連携にまつわる問題です。

具体的には、どんなところが問題になるのでしょうか？

山本
複数のシステムから構成される業務システムでは、多くの場合、それぞれのデータベースが密接に連携しています。例えば、よく利用されているのが「マテリアライズド・ビュー・レプリケーション」という機能です。これはある商用データベースの機能なのですが、テーブルのようにクエリの結果をキャッシュしておける「マテリアライズドビュー」に、外部データベースから取得したデータを保持しておくことができます。外部データを参照する際に、毎回、外部データベースにアクセスしなくてよいため、効率よくデータを参照できます。このような場合、片方のデータベースをPostgreSQLに移行した際にも、移行前と同様にもう一方のデータベースのデータを参照できるようにする必要があります。

一部のデータベースをPostgreSQLに移行した場合も、業務の運用には影響を与えないようにするということですね。PostgreSQLに移行しても連携できるのでしょうか。

山本
PostgreSQLの場合、Foreign Data Wrapper（以降、FDW）を使用すると、外部の異種データベースと連携できます。ただし、FDWは外部データを参照するたびに、外部データベースにアクセスするため、それだけでは外部データの参照効率が低下してしまいます。PostgreSQLの場合もマテリアライズドビューと組み合わせることで、データを効率的に参照することができます。ただ、マテリアライズド・ビュー・レプリケーションが差分データのみを反映することでデータベースやネットワークに負荷をかけずに効率的に更新できる一方で、FDWとマテリアライズドビューの組合せの場合、すべてのデータを入れ換えることしかできません。

例えば、大量のデータを連携させる場合、データベースやネットワークに負荷がかかり性能に影響がでる、ということでしょうか。

山本
そのリスクは否めません。FDWはOSSなので、差分反映できるように開発するという手段もありますが、富士通では「Linkexpress Replication option」というデータ連携製品を活用して、この問題を解消しています。これを使えば、マテリアライズド・ビュー・レプリケーションと同様に、データの差分反映が可能になります。データ量が多い場合や頻繁に更新をかける場合は、この方法が有効です。

状況に応じて手段を選択することで、PostgreSQLに移行した後も、移行前と同じ業務を実現できるのですね

山本
はい。特に移行の場合、移行前の性能や運用を維持することは、移行決定を左右する重要な要因になります。FDWやマテリアライズドビュー、Linkexpress Replication optionなどを業務に合わせて選択していくことで、段階的な移行を実現しています。

図：データベース間の連携

データやアプリケーションが移行できるだけでなく、移行前の性能や運用などをどう維持できるかということも含めて「移行できる」ということが重要なのですね。今後、さらに移行支援策を拡充していく予定などはありますか？

渡邉
移行にかかる工数をさらに圧縮するためには、移行テストの作業をもっと効率化する必要があると考えています。そのために、移行テストを自動化できるツールや、効率的なテストを行うためのガイドなどを提供していく予定です。既にオープンソースでアプリケーションテストを自動化できるツールなどが出回っていますから、そういったものをうまく活用する方法なども提案できると思います。移行作業全体の中でテストが占める割合はかなり大きいので、これを大幅に効率化できれば移行のハードルもさらに低くできるはずです。

移行へのさまざまな不安が払拭されるお話でした。ありがとうございました。

2017年2月3日掲載