進化の速度でも経済性でも業界トップクラスにある「Microsoft SQL Server」――。このところ、業務パッケージソフトウェアのデータベースとしてSQL Serverを選択する独立系ソフトウェアベンダーが増えている。その理由は「業務パッケージの高付加価値化」「Microsoft Azureとの親和性」「コストメリット」の3点。アセスメントを提供するコンサルタントの存在や、日本マイクロソフトによる支援施策の効果も大きい。
あまり知られていないことだが、データベース製品は市販の業務パッケージソフトウェアにも使われている。業務アプリケーションのスクラッチ開発専用ではないのだ。
「私の知る限り、国内だけでもこの半年で8本の業務パッケージが新規にSQL Serverに対応・移行していただきました」(図1)
こう語るのは、日本マイクロソフトの青木卓氏(データ&AIプラットフォームマーケティング部 エグゼクティブプロダクトマネージャー)だ。業務パッケージにおけるデータベースの使い方は用途によってさまざまだが、最も多いのはERP(Enterprise Resources Planning)や業務アプリケーションのデータ格納用だ。ビジネス分析(Business Intelligence:BI)を行うためのデータウェアハウス(DWH)としてデータベースを使っている業務パッケージも多い。
なぜ今、業務パッケージの世界でSQL Serverの人気が高まっているのか――。その最大の要因は「業務パッケージの価値を高められること」にある、と青木氏は説明する。
例えば、セキュリティだ。暗号化機能を高額の有償オプションとしているデータベースが多い中、常時データ暗号化機能「Always Encrypted」を標準機能として提供するSQL Serverをベースに業務パッケージを開発すれば、製品価格を抑えたままで個人情報保護などの高度なセキュリティ機能を組み込むことができる。パッケージ製品はStandard Editionで開発されていることが多いが、SQL Serverの場合はこうした高度な暗号化機能がSQL Server 2016 SP1からStandard Editionでも標準機能として提供され、追加コストなしで使用できるようになった。パッケージベンダーはこの点を評価し、採用を検討しているケースも多いようだ。
また、レポート/グラフ/ダッシュボードといったデータ可視化機能も、SQL Server標準の帳票作成ツールの「SQL Server Reporting Services(SSRS)」とデータ分析の「Power BI」で実現が可能だ。最新のSQL Server 2017に搭載されたグラフデータベース機能「SQL Server Graph Database」を活用すれば、ERPの売り上げデータから循環取引を発見するといった統制機能も低コストで実装することができる。
第2の要因として挙げられるSQL Serverの特徴は、「Microsoft Azureとの親和性が高い」ということ。
「現在のSQL Serverはハイブリッド型のデータベースです。さまざまな新機能も、まずはMicrosoft AzureのPaaS(Platform as a Service)向けのサービスとして開発、実装された後、オンプレミス版の方に搭載されるようになっています」と、青木氏。
データベースとしての仕様はオンプレミス版もAzure PaaS版もほぼ同じなので、オンプレミス用に開発した業務パッケージをAzure上で動くようにすることも簡単であると付け加える。その結果、「今はオンプレミス版やAzure IaaSで十分だが、今後のパッケージのサービス化を見据えて、Azure PaaS版のAzure SQL Databaseを活用したい」というユーザーニーズにも応えられるようになる。
第3の要因として青木氏が挙げるのは「コスト」だ。
“All in One Service”を掲げるSQL Serverでは、業務パッケージでよく使われる機能が標準構成に含まれている。外部からデータをインポートする際の抽出/変換/書き出し(ETL)には「SQL Server Integration Service(SSIS)」、帳票作成やデータ可視化にはSSRSを利用できるといった具合だ。また、SQL Server 2016 SP1より、全てのエディションで主要なエンタープライズクラスの機能が使用できるようになった。これにより、使用予定のデータベースのエディションごとにコードを分ける必要がなくなり、1つのコードベースを維持するだけでよくなったこともISVによっては大きな利点となる。
もちろん、データベースのコストを最優先するのなら“無料”で使えるオープンソースソフトウェア(OSS)のデータベースといいう選択肢も考えられる。しかし、OSSの保守サポートはソフトウェア製品として提供されるデータベースと大きく異なるため、業務アプリケーションに求められる高品質かつ長期の保守サポートを提供するのには向いているといえないだろう。
SQL Serverの採用には大きなメリットがあることを理解し、納得できたとしても、全ての独立系ソフトウェアベンダー(ISV)がすぐにデータベースを切り替えられるわけではない。SQL Serverに対応するには、業務パッケージのソースコードを書き換えなければならない場合も多く、保守サポート要員の再教育も必要になるからだ。
そこで、今、データベースの移行に関わるコンサルティングと対応支援を提供するコンサルタントの需要が非常に高くなっているのである。
「最近、Oracle Database対応の業務パッケージを開発、販売しているISVの方々から『Oracle DatabaseとSQL Serverのマルチデータベース対応にしたい』『うちの製品がSQL Serverに対応できるかどうかを調べてほしい』といった依頼を受けることが増えてきています」と語るのは、国内では数少ないデータベースコンサルタント企業、インサイトテクノロジーの内山義夫氏(コンサルティング事業部 シニアコンサルタント)だ。Oracle Databaseについては詳しいが、その他のデータベースはあまり知らない、というISVはかなり多いと明かす。
内山氏の説明によれば、同じSQL規格に準拠したデータベース同士であっても、業務パッケージでの使い方によっては、マルチデータベース化やデータベース移行が難しい場合があるのだという。
「ポイントは、Oracle Database特有の機能をどれだけ使っているか、ということです」と、内山氏。よく知られているように、Oracle DatabaseのSQL言語である「PL/SQL」には独特の“方言”も多い。「Transact-SQL(T-SQL)」を採用しているSQL Serverでは、PL/SQLと完全に互換性があるわけではなく、例えばコレクション型をプロシージャの引数に指定している場合、T-SQLでは同等の書き方ができないため、仕様変更が必要な場合もあるのだという。
もう1つのハードルは、プロシージャやパッケージの本数だ。PL/SQLからT-SQLへの書き換えが変換ツールや手作業で行えるとしても、「仮にプログラムが1万本もあったとすると、相当に難しくなります」と、内山氏。業務パッケージでは収益性も重視されるので、マルチデータベース化やデータベース移行の作業にあまりにも大きな工数や費用がかかると見込まれる場合は断念せざるを得ないこともあるという。
マルチデータベース化/データベース移行の実際の進め方はケースバイケースで異なるものの、典型的なSQL Server対応/移行プロセスは以下の図2のようになる。なお、プロセスのでは、各ステップにおいてMicrosoftからさまざまな支援施策も提供される(詳細は後述)。
SQL Serverへの対応/移行プロセスで最も重要な部分は、前半(図2の1〜3)で行われる「移行プロセスとSQL Serverの理解」「コスト/難易度試算」「POC(Proof Of Concept:コンセプト検証)/トライアル」といった“技術的な課題の可視化”と“作業工数/コストの見積もり”だ。
内山氏が所属するインサイトテクノロジーでは、「コスト/難易度試算」のステップで実施する技術的な課題の洗い出しには、Microsoftが無償で提供しているアセスメントツール「Microsoft SQL Server Migration Assistant for Oracle(SSMA for Oracle)」を利用しているとのことだ(図3)。
「Oracle Database用のプロシージャやパッケージをSSMA for Oracleで分析すると、そのまま移行できる部分と、できない部分をレポートとして可視化できます。その結果を基にデータベースコンサルタントがさらに分析を行い、SSMA for Oracleで移行できない部分についての対応方法を提示します」と、内山氏は説明する。
また、マルチデータベース化やデータベース移行のプロジェクトを進めるかどうかは、クエリや更新などの処理をどの程度の性能で行えるかが重要な判断材料になる。従来のOracle Database対応版と同等以上の性能を発揮できなければ、商品として開発する意味がなくなってしまうからだ。
この性能検証は、SSMAなどのアセスメントツールではなく、実機でのPOCで確かめるのが筋である。ただし、マルチデータベース化/データベース移行に当たって書き換えなければならないソースコード量が多いと、完全な形での検証は不可能だ。その場合は、実機でのトライアルは最もクリティカルな部分だけとし、他の部分はシミュレーションや机上計算で済ませることも往々にしてある。
SQL Server対応/移行プロセスの後半(前出の図2の4〜6)で行う「移行作業」「検証」「アップグレードパス」の各ステップは、基本的には通常の新規開発/メンテナンスの場合と変わらない。ソースコードの書き換え量が多くなる場合はプログラマーを増員したり、オフショア開発に出したりといった対処も必要だ。また、データベースの違いによる性能問題が発生した場合は、SQL Serverのエキスパートにスキルトランスファー(技術移転)を頼むことも考えるべきだろう。
一方、日本マイクロソフトも、業務パッケージのSQL Server対応を進めるISVに向けて、支援施策を幾つか提供している(前出の図2参照)。
技術面でのポイントとなるのが、移行アセスメントとPL/SQLからT-SQLへの変換を行うSSMAツールの改良だ。「他社データベースからSQL Serverへ、あるいはMicrosoft Azure Data Servicesへの移行/対応に対しては、Microsoft本社も投資を増やしています。SSMAについても2カ月ごとにアップデートを実施しており、変換効率も向上し続けています」と、青木氏。「過去のSSMAで思わしい結果が出なくて移行を断念したことがあるISVの方々も、最新版のSSMAでもう一度試してみてはいかがでしょうか」と勧める。
また、より直接的な支援施策として、業務パッケージをMicrosoftのデータプラットフォームに対応/移行させようとするISVには、以下のようなプログラムやツール、技術支援を提供している。
青木氏によれば、「この施策に投じられた件数は、過去1年で約30件」。今期も十分な予算を確保しているとのことだが、申し込みはなるべく早く済ませた方がよいだろう。
さらなるISV支援施策としては、以下のようなセールス&マーケティング協業も用意されている。
この他、SQL Serverそのものについて短時間で学ぶには、毎月開催されている「<SQL Server Day> SQL Server丸わかり1日セミナー」がピッタリだ。セッション最後には質疑応答タイムもあるので、直接相談する機会としても活用できるだろう。SQL Serverに関する一般的な問い合わせは、SQL Server案件支援コールセンター「SQL Direct」(0120-055-496)でも受け付けている。
Copyright © ITmedia, Inc. All Rights Reserved.
提供:日本マイクロソフト株式会社
アイティメディア営業企画/制作:@IT 編集部/掲載内容有効期限:2017年12月14日