1,000km以上離れた
OracleとPostgreSQLを
確実に双方向同期させたい
異機種DBを安全につなぐ
HULFTとHULFT Script

背景

ある案件での出来事でした。依頼主は東京に技術本部がある製造業のお客様で、遠方に生産工場があります。そのお客様は設備管理の効率化を狙っており、各工場の保全記録を東京の技術本部に収集し、分析、そして各工場へフィードバックすることで設備の稼働率向上と現場の作業負荷低減(ムリ・ムダ・ムラ解消)を目論んでおりました。およそ1年の構想期間を経て、東京側の設備管理DBと生産工場側の設備管理DBをそれぞれ改修し、互いに同期させることで、リアルタイムに設備管理状況を吸い上げることが決まり、各システムベンダがすでにアプリケーションとDBの改修に取り組んでおりました。

そして事件が起こります。

境界線を超えた瞬間にボールが落ちてしまう。よくあることです。そしてご相談を頂きました。 環境と要件をざっくりまとめると以下になります。

• OracleとPostgreSQLの双方向同期(同期間隔は1分)
• DB同士の物理的な距離が1,000km以上離れている
• 生産工場と東京技術本部はインターネットVPNで結ばれている。帯域は100Mbps(ベストエフォート型)。それが故に時々切れる。
• サービスインまで1ヶ月を切っている。
• 確実に同期可能で、かつ構築費用も残予算の中で収まる範囲で。

5番は特に念押しされたポイントでした。(笑)

DB同期手法を整理

パッと思いつく手法はマテリアライズドビューやDBリンク、DB固有のレプリケーション機能ではないでしょうか。

ただ、思い出してみてください。今回は「OracleとPostgreSQL」という異機種のDB同士を連携させる点。同機種のDB同士であれば、DB側の機能で同期可能ですが、異機種になった瞬間に取りうる手法が限られてしまいます。

その案件で採用した方法とは？

最終的に「ファイルに出力して転送する」が選択されました。実は当初、同期ツールを利用する方式を模索していたのですが、ネットワークが帯域を圧迫する、またネットワークが瞬断した際に同期処理に失敗するケースがあり、それらを根本的に解消するにはネットワーク品質を向上させる必要がありました。サービスインまで1ヶ月を切っている状況では、インフラの増備を間に合わせるのは難しく、必然的に転送品質をソフトウェアでコントロールする必要が必須要件に加わりました。HULFTの出番がやってきました。

ファイルに出力して転送する、つまりHULFTはソフトウェア側でネットワーク瞬断時のリトライや帯域を圧迫せずに転送する機能が備わっています。

いざ構築してみる

これまでの要件と検証結果から、以下のような連携概要となりました。シンプルにDBテーブルにフラグが立っているデータをファイルに出力し、HULFTの転送結果が正常であれば、フラグを下ろす。仮に転送異常が発生した場合、フラグはそのまま。次回同期タイミングで再実行する流れとなりました。各システムの責任分界点は「ファイルが届いたか否か」です。

そしてまたしても、事件が起きてしまいます。

細かな要件ですが、休日はマスタ更新用の連携があるのですが、そのマスタが更新されない事象が発生しました。

原因はすぐに特定されました。バッチです。バッチの中で休日判定をしているのですが、工場の稼働日に合わせた休日処理ができていませんでした。

日付の判定はバッチの中でできないことはないですが、バグを生みやすいポイントの一つではないでしょうか？

さて、ここでの選択肢は2つです。バッチを改修するか、スケジューラを導入するか。今後のメンテナンス性(休日が増えたり減ったり)を想像すると、やはりスケジューラに勝るものはないのではないでしょうか。

時間がない。テンプレートを活用して構築をスピーディに、品質最大限に

すでに色々と紆余曲折しているので、残された時間はありません。そこで一つの提案を行います。「テンプレートを活用したらいかがでしょうか？」

工場の稼働日に合わせた休日処理やエラーハンドリングをすべて、テンプレート化したツールがあります。それがHULFT Scriptです。

ご存知でない方は以下をご参照ください。

[HULFT Script 技術コラム9] 転送タイミングの制御も簡単！テンプレートで「待ち合わせ」処理

最終的なシステム構成は以下に落ち着きました。

HULFT Scriptでスケジューラ機能及び休日判定を行い、必要なバッチを呼び出す。同期対象データが生成され、転送する。一連をトランザクションとして制御を行い、何らかの問題が発生したら、ロールバック及びエラー通知します。このすべてをテンプレートから部品を呼び出し、設定を行うことで実装が完了しました。

まとめ

ファイルはシンプルでわかりやすい

システムテスト時の出来事です。あれ？おかしいぞ、想定と違う。となって事象の切り分けを行いますが、そこにファイルがありますか？ありませんか？原始的ですが、わかりやすいデバックが可能でした。最初の切り分けのポイントがはっきりしています。今回のような物理的な距離が離れているケースやマルチベンダでプロジェクトを推進しているケースでは特に「シンプルでわかりやすいは正義」に感じます。

テンプレートをうまく活用することで構築期間と費用を最小化できる

今回のプロジェクトでの要は実はHULFT Scriptであったと評価しています。休日判定、トランザクション制御、エラーハンドリング。これらは一般によくある基本要件ですが、フレームワークなくイチから実装しようとすると骨が折れます。この一連をテンプレートとして品質が保証されたモノがあるケースでは活用すべきです。構築期間を最小化しながら、品質を最大限に高める近道です。