• DBレプリケーション
• Microsoft SQL Server
• MySQL
• Oracle Database
• PostgreSQL
• Qlik Replicate / Attunity Replicate
• 2022.06.24
• 峯岸 隆一

Qlik Replicate における導入前の PoC や設計の重要性

峯岸です。前回までの投稿では、Qlik ReplicateはGUIベースで構築/運用可能であり、ユーザーサイドでの構築/運用が容易な製品であることを紹介させていただきました。しかしながら、構築/運用自体は容易であっても導入前の PoC や設計を十分に行わないと思わぬ落とし穴にはまる可能性があります。PoCについて耳慣れない方もいらっしゃると思いますのでまずはPoCについて簡単にご説明いたします。

PoCとは

PoCとは日本語で「概念実証」や「コンセプト実証」と訳されるProof of Conceptの頭文字をとった略語で、新しい技術や概念、理論などが実現可能かどうかをデモンストレーションし、要望に沿った効果が得られるかを確認することを意味します。システム開発においても新たな技術を使用した製品などを導入する際に、製品に求める要件を満たしているかどうかを検証するために行います。PoCを実施しないとプロジェクトの途中で思わぬトラブルが起きたり、要件を満たせないため別の製品を検討しなければならないといったことになりかねません。トラブル解消や新たな製品の検討には当初予定していなかったコストも発生してしまいます。

Qlik Replicateのレプリケートにおける課題

一例ですが、Qlik Replicateにはロジカルレプリケーションであるがゆえに以下のような課題があります。

1. サポート対象外の機能などの制限が比較的多い
2. ソースとターゲットでデータが異なる状態になることがある
3. ソースと異なるSQLが流れることもあり同期遅延が発生しやすい

各課題について少し補足します。

サポート対象外の機能などの制限が比較的多い

マニュアルに記載のソースエンドポイントがOracle Databaseの場合、サポート対象外機能は以下になります。

サポート対象外機能一覧：

• VPD(Virtual Private Database)
• 遅延制約
• 仮想列
• 論理スタンバイ(Data Guard)
• 関数インデックス
• パーティション操作の結果により生じるデータの変更
• オーバーフローセグメントを持つ索引構成表
• キー圧縮を使用した索引構成表
• BIN$,DR$のオブジェクト
• ROWIDベースのマテリアライズドビュー
• DBMS_REDINIFITIONパッケージによる変更
• データ型(BFILE、ROWID、REF、UROWID、ANYDATA、SDO_GEOMETRY)

レプリケーション元で上記の一覧の機能等を使用していた場合には当該機能はサポートされませんので注意が必要です。

ソースとターゲットでデータが異なる状態になることがある

データベース製品ごとにテーブル列のデータ型が異なるため、Qlik Replicateでは一旦ソースから受け取ったデータをQlik Replicateの内部データ型のカラムに格納し、その後、ターゲットにデータを挿入します。ソースがOracle DatabaseのCHAR型のように末尾に半角スペースで埋めるような型の場合は半角スペースが削除された状態でターゲットに伝搬されるため、ソースとターゲットでデータの状態が異なってしまう可能性があります。

データ同期後にハッシュ値などで整合性チェックを行う環境では不一致として検知される可能性があります。

ソースと異なるSQLが流れることもあり同期遅延が発生しやすい

ロジカルレプリケーションではソースで流れたSQLがそのままターゲットで実行されないことがあります。DELETEやUPDATEはひとつのSQLで複数行の更新が可能ですが、REDOログには各行の更新として記録されるため、基本的にロジカルレプリケーションではターゲットでは行単位のSQLに分割され実行されます。

そのため、多くの行を更新するSQLが実行されるとソースよりターゲットの方が時間がかかります。

なお、ロジカルレプリケーションがどのようなステップを踏んでターゲットにSQLを実行するかは以下のエントリにて記載がありますのでよろしければご一読下さい。

ロジカルレプリケーションの動作の仕組みから見るOracleレプリケーション3製品のイチオシポイント

ここで同期遅延についてQlik Replicate側で対処できる方法としてタスクの分割による処理の並列化をご紹介いたします。

通常ソースとターゲットのデータベースが1:1の場合、作成するタスクは一つです。しかし、以下のタスク分割のパターンのようにまずソースDBからQlik Replicateサーバーに対して一つ作成し、Qlik ReplicateサーバーからターゲットDBに複数タスクを作成することでターゲットへの適用を並列化することが可能です。

ターゲット側のCPU数などにも依存しますが更新される行数が多ければ分割することによる効果は大きいです。
ただし、タスク分割については単純に取り入れることはできません。分割する処理の範囲を決めなければならず、適切に処理量を分けたタスク分割を行うためにはきちんと設計することが必要になります。

課題による影響

もし、上記のような動作を知らずに製品を導入すると後々設計の手戻りやチューニング等に労力を費やさなければならない状態になる可能性があります。そのため、導入してから意図した(要件を満たした)状態にならないことを避けるため、コーソルではPoCや同期のレイテンシを考慮した設計を実施することをお勧めしています。

コーソルの導入支援サービスで問題を解決！

上記で記載した事項については事前に PoC を行い、設計をしっかり実施することで回避できることばかりです。コーソルではQlik Replicateの導入支援サービスを設けており、製品に熟知したエンジニアが PoC や設計を支援します。コーソルのサービスメニューを簡単にご紹介します。

Qlik Replicate PoC支援サービス

Qlik Replicateは弊社にご相談いただくことによりPoC向けに評価ライセンスをQlik社より払い出すことが可能です。ただし、PoC評価ライセンスは1箇月と期間があまり長くありません。期間を最大限活かしたPoCを行うために製品を熟知したエンジニアが以下のサービス内容を提供します。

　　- お客様環境にあわせたPoC実施手順書の作成
　　- Qlik Replicate の手順説明および製品の操作レクチャー
　　- PoC結果報告書の作成と報告会の実施

Qlik Replicate導入支援コンサルティングサービス

Qlik Replicate を用いた異なるデータベース製品間のレプリケーションや移行設計において、お客様を支援するサービスです。具体的には以下のような内容について支援可能です。

　　- Qlik Replicateの技術的なレクチャー
　　- 各種設計書 / 手順書 / レクチャー資料など必要となる資料やドキュメントテンプレートの提供
　　- 定例会議開催
　　- QA対応
　　- その他応相談

こちらは柔軟に対応可能ですので、お気軽にお問い合わせいただければと思います。

いかがでしたでしょうか。ロジカルレプリケーションは自由度が高い反面、PoCや設計を十分に行わないと思わぬ落とし穴にはまる可能性があります。他のレプリケーション製品の取り扱いもありますのでレプリケーション製品をご検討の方は製品選定を含め是非コーソルにお声がけいただければ幸いです。