異種データベース間の疎結合システム

こんにちは。わたしはシステムのインフラを設計・構築することをミッションとしています。
技術分野はハードウェア～ミドルウェアをカバーしていて、フルスタックエンジニアとして活動中です。特に知見があるのはインフラ構築とデータベース(OracleとDb2の経験が多い)です。今回はデータベースについて、最近の動向を交えながら取り組みの実績などをご紹介します。

商用データベースでは、様々な自動化機能が増えてきていますが、最新バージョンでは、チューニングが不要になる自動化機能がリリースされています。
インフラがクラウドにシフトしていく中で、データベースエンジニアが手作業でチューニングするのではなく、状況に応じてデータベースが自動で最適化することが望まれているためです。
自動化が進むに従って技術者には最適な技術を組み合わせることができる能力が求められるようになりました。私の専門分野であるデータベースを用いたシステムを構築する場合にもさまざまな製品や技術の組み合わせで、お客様の要件を実現するケースが増えています。

企業の中には様々なデータベースが存在しており、データベースエンジンがシステムごとに異なるケースは多々あると思われます。昨今、蓄積したデータの活用が新たな価値を生むことから、異なるデータベースに散在するデータを如何に統合して活用するかが課題となっています。
一般的に、異種データベース間の連携は、データベースのオプション製品を購入するか、データベース連携用のミドルウェアを導入するケースが多いです。
また、オプション製品やミドルウェアを導入しない場合は、データをまとめてテキストファイルに抽出し、定期的に連携する方式をとることが多いです。
例えば、バッチ処理で以下のような実装をすることになります。

今回は、OracleとDb2という異種データベース間で、任意のタイミングにデータを取り込みたいという目的と、お客様のシステム構築志向でシステム間の疎結合を推進していることから、バッチ処理連携ではない方法で実装することを望まれていました。

ここでいう密結合、疎結合とは、以下のような意味です。

密結合：アプリケーション間のインターフェイスを個別に設計・実装し、アプリケーションの内部構造に手を加えるレベルで行うシステム間連携
疎結合：アプリケーションの内部構造に手を加えることない、システム間の連携

また、処理のタイミングとしては、定期的なバッチ処理(非同期)と任意のタイミングで行うオンライン処理(同期)があります。

連携のパターンを図示すると以下のようになります。

まとめると仕様の変更時にもアプリケーションを変更することなく素早く対応できることと、異なるデータベースに格納されたデータを透過的に活用可能とする高い同期性をもった「疎結合&同期」(上図、赤枠内)でのデータ連携がお客様の求めるものでした。

技術調査、基盤システム構成、データ連携の設計、それぞれの局面で問題が発生しましたが、すべて解決し、本番稼働をしています。以下に詳細を述べます。

1. 技術調査

そもそも、お客様の要件を満足できる実装が可能か調査を進めたところ、OracleとDb2の間では、OracleのOracle Database Gateway for ODBCとDb2のODBCドライバーを組み合わせることで実装できるのではないかという情報を得ました。
実装手順を一通り書いているような情報は、海外のブログ程度しか見つからなかったため、それらの情報を参考に、OracleとDb2のマニュアルを調べながら、テスト環境で試行錯誤を繰り返し、構築手順を確立しました。

構築中に、設定したが正しく動かない場合、問題がOracle側なのか、Db2側なのかを切り分け、エラーが発生する条件を特定して、サポートに問い合わせることになります。
トラブル調査の際に、OracleとDb2の両方に知見があったことがとても役に立ちました。片方の製品しか知らない場合、何をどこから調べればよいか見当がつきません。また、トラブル発生時の確認ポイントも想定がつかなくなります。

今回は複数の製品を組み合わせているため、各製品に特化しないエラーが出る場合もあります。その際にはOracleとDb2の両方の動作を確認し、対応する必要がありますが、この場合も両方の知見があったことが問題の早期解決にとても役立ちました。

2. 基盤システム構成

試行錯誤の末、構築手順は分かりましたが、実装に際して環境の制約がありました。
今回の連携先データベースはOracle社のExadata上に構築されていました。
Exadataはアプライアンスであるため、機能追加をした場合にサポートが受けられないとのことで、Exadataに対してOracle Database Gateway for ODBCを導入、設定することが出来ませんでした。
そのため、踏み台となるOracle環境を構築、そこにOracle Database Gateway for ODBCを導入・設定し、踏み台サーバから連携元となるDb2へ接続するという構成を考えました。

接続構成とデータの流れは図の通りです。

踏み台サーバとターゲットの間はOracle同士のため、データベースリンクで接続し、踏み台サーバとソースの間は異種データベースのため、Oracle Database Gateway for ODBCで接続する構成です。

ソースとなるDb2は開発環境、テスト環境、本番環境の3環境ありましたが、保守の容易性を考慮して、踏み台サーバはテスト環境に1台置く構成とし、1台から3つのデータベースへ接続するような構成にしました。
そのため、接続先をわかりやすくするためにシノニムを設定しました。例えば開発環境の場合はDEV.<テーブル名>、テスト環境の場合はTEST.<テーブル名>のように、環境を示す名称を先頭につけることで識別しやすくしました。
シノニムをつけることで、運用も効率的になりました。連携先で取得したい情報が追加になった場合、連携元のテーブルに関するシノニムを踏み台サーバで追加するだけで対応できます。そのため、少ない運用コストでの運用が可能になりました。(バッチ処理方式の場合は、取得したい情報が追加になるたびに追加開発が必要になります。)

3. データ連携の設計

異種データベース間のデータ連携を設計するにあたり、連携方式以外にも下記の点について考慮が必要になります。

（1）データベースの文字コード
（2）データ型の取り扱い

（1）データベースの文字コード

Oracleはサーバとクライアント間の文字コードが異なる場合、文字コードの自動変換が行われます。
今回は、連携元のDb2はUTF-8でデータを格納し、連携先のOracleはSJISデータを格納する設定となっていました。
SJISは1文字あたり1～2バイトのところ、UTF-8は1文字あたり1～3バイトとなるため、連携先のテーブル定義が連携元と同じではバイト数が不足し、データが格納しきれなくなります。
連携元のデータ定義であるSJISではASCII文字や半角カナと特殊記号は1byteで、漢字や仮名等の全角文字は2byteで表現しますが、UTF-8はASCII文字のみ1byte、特殊記号は2byte、漢字や仮名等は2～3byteで表現されるため、連携先のデータ定義長は、連携元のデータ定義長の2倍としました。

（2）データ型の取り扱い

連携元のDb2には実行したSQL文が保管されるカラムがあり、その列はCLOBで定義されていましたた。(CLOBとは可変長文字ストリングの型で、長いテキストデータを格納するための型)
このままではOracleからselectすることが出来ないため、Db2側に中間ビューを実装しました。
その中間ビューは、CLOBのカラムに含まれるテキストデータをキャストし、複数のVARCHAR固定長列に分割して格納するものです。
連携先からは実テーブルではなく中間ビューを参照しますが、シノニムをつけているため、連携先からは、参照先がテーブルなのかビューなのか意識する必要がありません。
今回はOracleとDb2であったため、データ型の扱いが異なるのはCLOB型のみでしたが、組み合わせるデータベースの種類によっては、データ型の取り扱いが異なる型の種類が複数あるため、事前に確認しておくべきです。

今回、異種データベース連携を疎結合で実現したことで、即時性と柔軟性を兼ね備えたデータ活用基盤が構築でき、お客様のデータ活用範囲が大きく広がったと自負しています。
自分の持つ経験と技術力を生かして、今まで考えてみなかった構成を実現できたこと、お客様に貢献できたことが、自分にとってもよい経験となりました。

今後、システム基盤は、稼働するシステムの要件に応じてクラウドとオンプレミスに分かれていくと思われます。
クラウドではクラウドの特色を生かした形で、オンプレミスはお客様の要望をできるだけ実装できるような形で、システムの提案、構築をしていきたいです。
今回紹介したような構成は、オンプレミスだからこそ実装できたものでした。
しかし、今後普及してくると思われるハイブリッドクラウド構成のデータ連携方法に関して参考になる情報が得られたと考えています。