はじめに

この記事の内容

1. DataSpiderとは

DataSpider Servista(以降、DataSpider)は異なるシステムの様々なデータやアプリケーションを、豊富な接続アダプタを使ってノーコードでつなぐことが可能な、データ連携ツール(EAIソフトウェア)です。例えば、データベースのテーブル情報をファイル形式に変換し、ストレージに保存するといった連携を行うことが可能です。
今回はDataSpiderでAmazon Relational Database Service(以降、RDS)から取得したテーブル情報をファイル形式(CSV)に変換し、Amazon Simple Storage Service(以降、S3)のバケットへ保存するデータ連携システムを冗長化します。

また、今回はDataSpiderの接続先として2つのデータベースとS3を利用します。

2. HAクラスター構成

今回はDataSpiderのミラーディスク型HAクラスターを構築します。HAクラスター構成はAWS仮想IPリソースを用いた「VIP制御によるHAクラスター」を構築します。
DataSpiderのクライアントとなるStudioをインストールした操作用インスタンスは、HAクラスターを構成するインスタンスと同じVPC内に配置します。

3. HAクラスター構築手順

3.1 VIP制御によるHAクラスターの作成

DataSpiderを冗長化する際のベースとなる「VIP制御によるHAクラスター」を作成します。
VPCおよびCLUSTERPROの構成は下記のとおりです。CLUSTERPROのフェールオーバーグループには「AWS仮想IPリソース」と「ミラーディスクリソース」のみを登録します。

フェールオーバーグループにAWS仮想IPリソースとミラーディスクリソースを登録したら、各インスタンスでフェールオーバーグループが正常に起動できることを確認します。

3.2 RDS DBインスタンスとS3バケットの作成

DataSpiderのデータ連携先として、RDSのDBインスタンスとS3のバケットを作成します。
RDSのDBインスタンス内に、事前にサンプルテーブル（例：sample_table）を作成しておきます。

RDSのDBインスタンスはHAクラスターを構成するインスタンスと同じVPC内に作成します。また、HAクラスターを構成するインスタンスからRDSにアクセスするため、ネットワーク、セキュリティグループを設定します。
S3のバケットはHAクラスターを構成するインスタンスと同じリージョン内に作成します。また、HAクラスターを構成するインスタンスからS3のバケットにアクセスするためにネットワーク、セキュリティグループを設定します。別途、バケットにアクセスするためのアクセスキー、シークレットキーを作成します。

3.3 リポジトリDBのインストール

3.3.1 データベースクラスターの作成

今回は、リポジトリDBにPostgreSQLを使用します。まず両サーバーにAdministrator権限でログオンし、PostgreSQLをローカルディスクにインストールします。インストール時の設定は基本的にデフォルトを選択します。
インストール後、[スタート]→[Windows 管理ツール]→[サービス]を開き、PostgreSQLのサービス(今回の検証では「postgresql-x64-17」)が追加されていることを確認し、サービスを停止・無効化します。

次に、現用系サーバーでPostgreSQLの設定を行います。データパーティション配下にインストールユーザーでデータベースを格納するディレクトリを作成します(今回の検証では「M:¥data」)。作成したデータベースディレクトリ配下にデータベースクラスターを作成します。 管理者権限でコマンドプロンプトを起動し、以下のコマンドを実施します。なお、文字コード(-Eパラメータ)の情報などは、環境に合わせて指定してください。

3.3.2 データベースサーバーの設定

データベースクラスター作成後、postgresql.confファイル／pg_hba.confファイルを編集し、データベースサーバーの設定を変更します。両ファイルは、データベースディレクトリの直下にあります(今回の検証では「M:¥data」)。
postgresql.confファイルでは、接続の監視に使用するIPインタフェースの設定やPostgreSQLが使用するポート番号の設定を行います。クライアントからの接続の監視に使用するIPインタフェースの設定を、利用可能なすべてのIPインタフェースに対応するように設定します。また、PostgreSQLが使用するポート番号を設定します。
pg_hba.confファイルでは、クライアント認証の設定を行います。以下は変更例です。環境に応じて接続を許可・禁止するクライアントの設定を行ってください。

3.3.3 PostgreSQL用サービスの設定

NETWORK SERVICEアカウントを実行ユーザーとして、PostgreSQL用サービスを作成します。[Windows 管理ツール]の[サービス]のウィンドウを開いている場合は、閉じてください。管理者権限でコマンドプロンプトを起動し、以下のコマンドを実施します。

コマンドを実施したら、[スタート]→[Windows 管理ツール]→[サービス]を開き、設定が変更されたことを確認します。 [pgsql-17]サービスのプロパティより、「全般」タブを開きます。[実行ファイルのパス]と[スタートアップの種類]が以下の値になっていることを確認します。

3.3.4 データベースディレクトリへのユーザー権限の設定

続いて、作成したデータベースディレクトリにアクセスできるように、フォルダの権限を設定します(今回の検証では「M:¥data」)。エクスプローラでデータベースディレクトリ(data)を右クリックし、[プロパティ]を選択します。[セキュリティ]タブで[編集]を選択し、[data のアクセス許可]画面の[追加]からNETWORK SERVICEアカウントを追加します。[data のアクセス許可]画面で追加したNETWORK SERVICEアカウントを選択し、フルコントロール権限を与えます。

3.3.5 データベースの作成

最後に、pgsql-17サービスを起動し、createdbコマンドでデータベースを作成します。
※データベース名(任意)：db1

データベース作成後、pgsql-17サービスを停止します。
これで現用系サーバーでのPostgreSQL設定は終了です。

次に、フェールオーバーグループを待機系インスタンス(server2)へ移動し、同様に「3.3.3 PostgreSQL用サービスの設定」、「3.3.4 データベースディレクトリへのユーザー権限の設定」と同じ操作を実施します。

実施後、[スタート]→[Windows 管理ツール]→[サービス]でpgsql-17サービスを起動し、psqlユーティリティを使用して、現用系サーバーで作成したデータベース(今回の検証ではdb1)に接続できることを確認します。

確認ができたら、[スタート]→[Windows 管理ツール]→[サービス]を開きpgsql-17サービスを停止してください。

3.4 DataSpiderのインストールと設定

3.4.1 DataSpiderのインストール

インストールが完了したら、DataSpiderのサービスのスタートアップの種類を手動に設定します。
サービスが停止状態であることを確認し、サービスのスタートアップの種類を「自動」から「手動」に変更します。

3.4.2 DataSpiderの設定

各インスタンスでDataSpiderのインストールが完了したら、DataSpiderの「死活確認用スクリプト」の作成を行います。
DataSpiderでは、外部アプリケーションからスクリプトを実行するためのScriptRunnerという機能があります。ScriptRunnerで「死活確認用スクリプト」を実行することで、Windowsサービスの実行状況やネットワーク疎通確認に加え、DataSpiderの実行状況の観点でも死活確認を実施することができます。
作成した「死活確認用スクリプト」をCLUSTERPROから実行することによりDataSpiderを監視します。

現用系インスタンス(server1)でCLUSTERPROのフェールオーバーグループを起動し、DataSpiderとリポジトリDBのサービスも手動で起動します。

Studioから「ホスト名/IPアドレス」にVIPを指定してDataSpiderに接続します。
Studioの「新規プロジェクト」アイコンより「プロジェクト作成ウィザード」を開きます。プロジェクト名、スクリプト名に任意の名称を入力し、プロジェクト、スクリプトを作成します。
  例)
      プロジェクト名：死活確認プロジェクト
      スクリプト名 ：死活確認スクリプト

「デザイナ」ツールより、スクリプトの処理内容を作成します。今回は[Start]から[End]までフローを引きます。
フローを引いたら、Studio上部の「メニュー」から[スクリプトの実行]を選択し、スクリプトの実行が成功することを確認します。

Studio上部の「メニュー」から[ファイル]-[プロジェクトをサービスとして登録]を選択して、「死活確認用スクリプト」をサービスに登録します。

「死活確認用スクリプト」をサービスに登録したら、ScriptRunnerの設定を行います。
ScriptRunnerから死活確認スクリプトを実行するために起動設定ファイルを作成します。

ScriptRunnerの設定方法の詳細については、DataSpiderのオンラインヘルプ[ScriptRunner]の項をご参照ください。
作成する起動設定ファイルのサンプルは下記の通りです。

起動設定ファイルの格納先：M:\Program Files\DataSpiderServista\server\bin
起動設定ファイル名 ：sample.xml

※本起動設定ファイルはサンプルであり動作を保証するものではありません。
※パスワード(xxxxxxxxxx)はDataSpiderインストール時に設定したパスワードに書き換えてください

ScriptRunnerの設定が完了したら、DataSpiderとリポジトリDBのサービスを手動で停止します。

3.5 DataSpiderのHAクラスターへの組み込み

CLUSTERPROによるDataSpiderの起動・停止制御はCLUSTERPROのサービスリソースにより実現します。

■ サービスリソース(service_DataSpider)の設定
フェールオーバーグループに「サービスリソース」を追加し、サービス名には「DataSpider Servista」を選択してください。

■ サービス監視リソース(servicew_DataSpider)の設定
次に、監視リソースを登録します。
サービス監視リソースの設定を変更し、また、カスタム監視リソースを追加します。
監視リソースの回復動作は「最終動作のみ実行」を選択し、最終動作は「クラスタサービス停止とOS再起動」を選択します。
まず、サービス監視リソースの回復動作を変更します。

■ カスタム監視リソース(dataspiderw)の設定
次にDataSpiderを監視するリソースを登録します。モニタリソースのタイプは「カスタム監視」を選択します。
監視開始待ち時間にはDataSpiderのサービスが実行中になってから実際に動作を始めるまでの時間を入力してください。また、監視タイミングは「活性時」を選択し、対象リソースにはDataSpiderの制御を行うサービスリソースを設定します。

監視(固有)タブにおいて、「編集」を選択し、監視スクリプトを登録します。

監視スクリプトのサンプルは下記です。監視はDataSpiderのScriptRunnerで行います。
ScriptRunner.exeの引数に、ScriptRunnerの設定で作成したxmlファイル(今回の検証では、M:\Program Files\DataSpiderServista\server\bin\sample.xml)を指定して、実行します。

※本スクリプトはサンプルであり動作を保証するものではありません。
回復動作タブにおいて、回復動作に「最終動作のみ実行」を選択し、最終動作は「クラスタサービス停止とOS再起動」を選択します。

■ サービスリソース(service_pgsql)の設定
続いて、フェールオーバーグループに「サービスリソース」を追加してください。「サービス名」にはリポジトリDBに使用するデータベースサーバーを選択してください。

■ サービス監視リソース(servicew_pgsql)の設定
サービスリソースを追加すると、サービス監視リソースも追加されます。サービス監視リソースはデータベースサーバーが起動しているかを監視します。

リソースの追加が完了したら、設定の反映を行い、追加したサービスリソースを起動します。

4. 動作確認

Studio上部の「メニュー」から[スクリプトの実行]を選択して、スクリプトを実行します。
スクリプトの実行が成功するとその旨を伝えるダイアログが表示されます。

RDSのDBインスタンスから取得したテーブル情報がS3のバケットにCSVファイルとして保存されていれば成功です。
スクリプトの実行が確認できたら、DBインスタンスのテーブル情報を更新しコミットします。また、CLUSTERPROで現用系インスタンス(server1)から待機系インスタンス(server2)へフェールオーバーグループを手動で移動します。
フェールオーバーグループの移動が完了したら、Studioに再ログインします。Studioに再ログイン後、旧現用系インスタンス(server1)で作成したデータの連携用のスクリプトを再度実行します。
S3のバケットに保存されているCSVファイルが更新されていれば、フェールオーバー先でのスクリプトの実行も成功です。

また、リポジトリDBを利用した構成では、ユーザー情報が正しく引き継がれていることを確認します。リポジトリDBの動作確認前にCLUSTERPROでフェールバックしておきます。
今回は、Studioで新たに2名のユーザー(testuser1、testuser2)を作成します。

ユーザー名やパスワードなど必要な情報を入力し、ユーザーを追加します。

2人目のユーザーについても同様の手順で追加し、新たに2名のユーザーが正しく登録されていることを確認します。

続いて、作成したユーザー(testuser1)でStudioにログインします。Studioの「新規プロジェクト」アイコンより「プロジェクト作成ウィザード」を開きます。プロジェクト名、スクリプト名に任意の名称を入力し、プロジェクト、スクリプトを作成します。
  例)
      プロジェクト名：リポジトリDB確認プロジェクト
      スクリプト名 ：リポジトリDB確認スクリプト

スクリプトの実行が確認できたら、プロジェクトの権限を編集します。「マイプロジェクト」タブから「リポジトリDB確認プロジェクト」を選択し、「選択中のプロジェクトを共有する」からtestuser2に読み取り権限を付与します。

その後、testuser1でログアウトし、testuser2でStudioにログインします。「リポジトリDB確認プロジェクト」が表示されていること、および書き込み操作はできないことを確認します。

次に、CLUSTERPROで現用系インスタンス(server1)から待機系インスタンス(server2)へフェールオーバーグループを手動で移動します。
フェールオーバーグループの移動が完了したら、旧待機系インスタンス(server2)上でStudioの「リポジトリDB確認プロジェクト」において、testuser1では読み取り・書き込みができ、testuser2では読み取りのみ可能で書き込みができないことをそれぞれ確認します。
このように、フェールオーバーの前後でプロジェクトやユーザー情報、アクセス権限が正しく引き継がれることを確認できました。

まとめ

今回はDataSpider Servista 5.0.0およびCLUSTERPRO X 5.3を用いて、AWS上でDataSpiderを冗長化する手順をご紹介しました。
DataSpiderの冗長化構成、またリポジトリDBを用いた大規模・本番運用向けの構成を構築したい場合は、本手順を参考にHAクラスターを構築してください。

利用製品

本記事の環境を構築する際に利用した製品です。

お問い合わせ