Db2 for z/OS連携の全体像｜DRDAとQレプリケーション（IIDR）

1. はじめに：オープン系システムとメインフレームDBの連携

オープン系のシステム開発に携わる中で、企業の基幹データを格納するメインフレーム、特にz/OS上で稼働するDb2との連携が必要になる場面は少なくありません。しかし、その連携方法にはDRDAやQレプリケーションといった専門用語が登場し、それぞれの違いや全体像を掴むのは容易ではないでしょう。

本記事では、その複雑に見えるDb2 for z/OSとの連携技術を体系的に整理し、関連用語の役割を解説していきます。

3回にわたるシリーズの初回として、まずは連携における2つの主要なアプローチの全体像を掴んでいきましょう。

本稿は、Db2 for z/OSとの連携をテーマにした3部構成のシリーズ記事の初回となります。

• 第1回：本記事
• 第2回： Db2 Connectの役割とは？DRDA、JDBC/ODBCとの関係を徹底解説
• 第3回： Qレプリケーションとは？DB2、IIDR、IRS、MQなど関連用語も合わせて体系的に整理

2. Db2 for z/OS連携における2つの主要アプローチ

z/OS上のDb2とオープン系システムを連携させるアーキテクチャは、その目的とデータの扱い方によって、大きく2つのアプローチに分類して考えることができます。

一つは、アプリケーションがネットワーク越しにDb2 for z/OSへ直接接続し、リアルタイムにデータを読み書きする 「DB接続型アプローチ」 です。

もう一つは、z/OS上のDb2で発生したデータの変更を別のサーバー上のデータベースに複製・同期し、その複製データを活用する 「DB複製型アプローチ」 です。

これら2つの方式は、それぞれ異なる技術要素で構成されており、得意とする領域も異なります。以降の章で、それぞれのアーキテクチャについて詳しく見ていきましょう。

3. DB接続型アプローチ：DRDAによる直接アクセス

目的と概要

まず一つ目の「DB接続型アプローチ」は、オープン系のアプリケーションがz/OS上で稼働するDb2に接続、ネットワーク越しに直接SQLを発行し、リアルタイムにデータを更新できるアプローチです。この方式は、データの最新性が厳格に求められるオンライン取引処理（OLTP）システムなどで中心的な役割を果たします。

アーキテクチャの主な特徴：双方向のデータ更新

このアプローチは、オープン系のアプリケーションからz/OS上のDb2に対して、データの参照（SELECT）だけでなく、更新（INSERT/UPDATE/DELETE）も直接実行できる点にあります。データの流れは双方向であり、アプリケーション開発者は、物理的な場所やプラットフォームの違いを意識することなく、あたかもローカルに存在するデータベースを操作するかのようにz/OS上のデータにアクセスできます。このアーキテクチャでは、z/OS上のDb2がマスターデータになります。

主要な関連用語と役割

このアプローチは、以下のコンポーネントが連携して動作しています。

• DRDA (Distributed Relational Database Architecture)
  異なるプラットフォーム上で稼働するDb2ファミリー（z/OS, Linux/Windowsなど）がやり取りするための「通信プロトコル（ルール）」です。SQLコマンド、データ型、エラーコード、トランザクション制御など、データベース間の円滑なやり取りに必要なすべての手順やデータ形式を定義しています。

• Db2 Connect
  オープン系サーバーとz/OSという異なる世界を繋ぐ、「ゲートウェイ製品」です。z/OSへの接続ライセンスを管理するという役割に加え、プロトコルの細かな仕様の差異を吸収したり、接続をあらかじめ確立・保持（プール）しておき複数の要求で再利用することで、全体のパフォーマンスを最適化する仲介役を担います。

• JDBC/ODBCドライバ
  JavaやPython, C++, .NETといった様々な言語で記述されたアプリケーションが、データベースと対話するための「標準API」を実装したソフトウェアです。開発者はこの標準化された手順に従ってコードを記述し、JDBC/ODBCドライバがその要求を解釈して、DRDAプロトコルという具体的な通信形式に変換します。

• DDF (Distributed Data Facility)
  z/OS側Db2の「受付窓口」です。これは専用のコンポーネント（Started Task、略してSTC）であり、ネットワークからのDRDA接続要求を待ち受けます。STCは、LinuxにおけるデーモンやWindowsにおけるサービスのように、システム起動時からバックグラウンドで常時稼働するプログラムを指します。DDFは正規のアクセスであることを確認した上で、Db2の本体（エンジン）へとリクエストを引き渡す役割を担います。

特徴のまとめ

• メリット： トランザクションの単位でリアルタイムなデータ一貫性が保証され、z/OS上のマスターデータを直接、安全に更新できます。
• 考慮点： アプリケーションの応答性能はネットワークの遅延や安定性に直結します。また、発行されるSQLはz/OS本体のCPUやメモリといったリソースを直接消費するため、パフォーマンスへの配慮が不可欠です。

この方式を構成する各コンポーネントの、より詳細な役割と関係性については、本シリーズの第2回で深く掘り下げていきます。

4. DB複製型アプローチ：Qレプリケーションによるデータ複製

目的と概要

次にもう一つの「DB複製型アプローチ」は、z/OS上の本番データベースに直接的な負荷をかけることなく、データの複製（レプリカ）をオープン系のサーバー上に作成するためのソリューションです。

この方式の主な目的は、「メインフレーム上の重要なデータを直接操作することなく、オープン系のモダンなアプリケーションから安全かつ高速にデータを参照できるようにする」 ことにあります。その結果として、災害対策（DR）環境の構築、データウェアハウス（DWH）へのデータ連携、参照処理の負荷分散といった、様々な活用シナリオが実現可能となります。

アーキテクチャの主な特徴：一方向のデータ反映と参照専用

こちらの方式では、データの流れが原則としてz/OSからオープン系への一方向になります。

オープン系のサーバー上に作成された複製データベースは、原則として参照専用（Read-Only） として扱われます。複製先でデータを更新してしまうと、マスターであるz/OS上のデータベースとの整合性が失われてしまうからです。このアーキテクチャは、本番システムへの影響を完全に分離した上で、オープン系の技術スタックから自由にデータを活用したいというニーズに的確に応えます。

主要な関連用語と役割

このアプローチは、以下の要素によって実現されます。

• Qレプリケーション
  データ複製技術の名称です。後述するQキャプチャーやQアプライといったプログラムと、IBM MQを組み合わせて実現されます。

• IIDR (IBM InfoSphere Data Replication) / IRS
  IIDRは、Qレプリケーションを実装したIBMのソフトウェア製品群（製品ファミリー）の総称です。その中で、z/OS上に導入され、Qキャプチャー・プログラムを含むのがIRS (IBM Data Replication for Db2 for z/OS) というz/OS専用のソフトウェアです。

• Qキャプチャー (Q Capture) と Qアプライ (Q Apply)
  これらはQレプリケーションの中核をなす一対のプログラムです。

  • Qキャプチャー: ソース側（z/OS）で稼働し、Db2のデータ変更を検知する「送信役」のプログラムです。IRSに含まれており、z/OS上ではSTCとして動作します。
  • Qアプライ: ターゲット側（オープン系）で稼働し、送られてきた変更データをデータベースに適用する「受信役」のプログラムです。

• CDC (Change Data Capture)
  これは技術概念の総称であり、Qキャプチャーが使用している技術です。データベースへの変更を、変更を加えたSQL文からではなく、トランザクションログから識別・取得する手法を指します。

• IBM MQ
  Qキャプチャーが取得した変更データを、Qアプライまで届けるための高信頼な**メッセージング基盤（プラットフォーム）**です。MQは内部的に「キュー」というメッセージの一時保管場所を持ちますが、その真価は、ネットワークが不安定でもメッセージを失うことなく、確実に相手に送り届けることを保証する、堅牢な通信インフラとしての機能にあります。

特徴のまとめ

• メリット： ソースDB（z/OS）への負荷が比較的低いこと、オープン系技術でのデータ活用が容易になること、参照処理の負荷を分散できることなどが挙げられます。
• 考慮点： データ反映にはわずかな遅延が発生します。また、複製先のデータベースは原則として更新できません。

このQレプリケーションを構成する各要素のより詳細な仕組みについては、本シリーズの第3回で解説します。

5. まとめ：目的がアーキテクチャを決める

ここまで、Db2 for z/OSとオープン系システムを連携させるための2つの主要なアプローチ、「DB接続型（DRDA）」と「DB複製型（Qレプリケーション）」について概要を解説してきました。

両者の特徴を整理すると、以下のようになります。

• DB接続型アプローチ（DRDAによる直接アクセス）

  • 目的: オープン系システムからの更新処理
  • z/OSへの影響: 直接的な負荷あり
  • データの更新方向: 双方向（Read/Write）
  • 主な用途: オンライン取引処理

• DB複製型型アプローチ（Qレプリケーションによるデータ複製）

  • 目的: オープン系システムからの参照
  • z/OSへの影響: 負荷は比較的少ない
  • データの更新方向: 一方向（Read-Only）
  • 主な用途: 災害対策、DWH連携、参照負荷分散

どちらの技術が優れているかという議論ではなく、「何をしたいのか？」という目的が、採用すべきアーキテクチャを決定します。「z/OS上のマスターデータを直接更新したい」のであればDB接続型を、「本番環境に影響を与えずにデータを安全に参照・活用したい」のであればDB複製型が、それぞれ最適な選択肢となるでしょう。

次回は、DB接続型アプローチの中核をなす「Db2 Connectの役割とは？DRDA、JDBC/ODBCとの関係を徹底解説」 と題し、各コンポーネントの役割をさらに深く掘り下げていきます。