Database Performance Analyzer (DPA) 2025.4のリリース

投稿日: 2025年12月9日 作成者: climb
Database Performance Analyzer (旧Ignite)

Database Performance Analyzer (DPA) 2025.4の一般提供がリリースされました。本リリースでは、Oracle向けAIクエリアシスト、DPA Centralの大幅な拡張、追加のSQL Serverメトリクスをご利用いただけます。さらにDPAは初めてDockerコンテナとしても提供されます。

Oracle向けAIクエリアシスト

DPAはAIクエリアシストを拡張し、Oracle対象に対するインテリジェントなクエリ書き換えを提供します。Oracle向けAIクエリアシストはSQL Server向けAIクエリアシストと同様のUIフローを採用しています。基本的に、この機能は実行計画を持つあらゆるDMLクエリのクエリ詳細ページで利用可能です。クエリと計画はSolarWinds AIに送信される前に個人識別情報（PII）がマスクされ、AIが最適化を目的としてクエリを書き換えます。

対象となるクエリでは、チューニングタブにAIスパークルアイコンが表示され、クエリが書き換え最適化のために送信可能（または送信済み）であることを示します。アイコンをクリックすると、クエリ詳細ページのAIクエリアシスト機能に移動します。

PA Central – マイ・エステートを表示

複数のDPAサーバーを運用する組織向けに、DPA Centralは監視対象となる全ターゲットの高価値監視シグナルを一元的に可視化します。データベース環境全体を一元管理する「ワン・ペイン・オブ・グラス」を実現。新DPA Centralでは、エンタープライズ規模のデータベース環境全体をより迅速に把握できます。

本リリースでは、マイDBインスタンスを導入。これはDPA Centralの新タブで、サインインしたユーザーが閲覧権限を持つ全ターゲットを一覧表示します。以前のバージョンではアクティブなアラームが1つ以上あるターゲットのみが表示されていましたが、今回の更新により、登録済みデータベースの完全かつパーソナライズされたインベントリが提供されます。

超大規模環境向けに設計されたDPA Centralは、数千のデータベースインスタンスを擁する環境をサポートするため、スケーラビリティを最適化しています。実際のスケールは、「中央」DPAサーバーに割り当てられたコンピューティングリソースによって異なります。

主な機能:

ページネーション: 大規模な資産を表示するために必須。

SAMLログインサポート：DPA CentralがSAML認証をサポート。SAML経由でDPAにログインしたユーザーは、DPA Centralで自身の可視対象環境を確認可能。

グループ化された環境ビュー：DPAスタイルのホーム画面でターゲットを整理し、迅速なトリアージを実現。

カスタムプロパティの可視化：監視対象各々のカスタムプロパティを一目で確認可能。DPAで既に利用可能なカスタムプロパティ機能を活用し、各ターゲットの使用目的を記述するプロパティをタグ付けできます。

拡張されたフィルタリング: カスタムプロパティによるフィルタリングを含む、より豊富な検索・フィルタオプションで関心のあるデータベースを素早く特定。例: 「環境」カスタムプロパティを設定すれば、「本番環境」データベースのみを表示可能。

柔軟な列設定: 基本列とカスタムプロパティ列の表示/非表示を切り替え、資産ビューをカスタマイズ。

SQL Server および Azure SQL DB のメトリック

Azure SQL DB は、同じ Azure クラウド インスタンス内で他のデータベースと並行して動作する単一のデータベースを公開する、人気のあるデータベース プラットフォームです。DPA では、Azure SQL DB のパフォーマンスを示す拡張されたメトリック セットが新たに追加され、CPU、ディスク、メモリ、セッション、および tempDB のメトリック カテゴリをカバーしています。

さらに、すべての SQL Server エディション向けに、tempDB の空き領域率と tempDB サイズの 2 つの tempDB メトリックが収集されるようになりました。

empDBのリアルタイムセッション

SQL Server tempDB メトリクスの収集（上記参照）に加え、DPA はセッションレベルでの tempDB スペース使用量を公開するようになりました。SQL Server 2016 以降では、リアルタイム セッション ページに以下の列が表示されます：

tempdb_int_obj_mb: 各セッションの内部オブジェクトに対する tempDB スペース使用量

tempdb_user_obj_mb: 各セッションのユーザー オブジェクトに対する tempDB スペース使用量

タグ: , , , ,

2025年のデータベース管理者（DBA)の現状：燃え尽き症候群、AI、そしてバランスをめぐる戦い

投稿日: 2025年12月7日 作成者: climb
Database Performance Analyzer (旧Ignite) データベース

データベースは現代ビジネスの心臓部である。その中心にいるのがデータベース管理者（DBA）だ! それはデータシステムの安全性とパフォーマンス、信頼性を確保する専門家たちです。

DBAは日々、ますます複雑化するインフラを管理し、絶え間ないアラートに対応し、問題の消火活動に追われています。多くのDBAには、より積極的で戦略的な業務へ移行するための時間、ツール、トレーニングが単純に不足しています。

しかし、とある調査会社の「データベースの現状レポート」によれば、この責任がストレスと疲労の原因となっています。DBAの3分の1以上が、自らの職務を離れることを真剣に検討している。問題は目的の欠如ではなく、プレッシャーにあります。

518名のDBAと503名のIT幹部を含む1,000人以上のITプロフェッショナルを対象とした今年のこの調査は、明確な現実を浮き彫りにしています：DBAの役割は進化したが、ほとんどの組織がそれに追いついていません。

複雑性は高まる一方だが、対応能力は追いつかない

現代のDBAはかつてないほど多くのシステムを管理している。オンプレミス、プライベートクラウド、パブリッククラウド環境を横断し、リレーショナル、NoSQL、インメモリ、さらにはベクトルデータベースまで、増え続ける多様なデータベースの責任を負っています。

この複雑さがチームを限界まで追い詰めている。監視ツールが完全に統合されていると回答したDBAはわずか40%であるのに対し、IT幹部の半数は既に統合済みと認識しています。この認識のギャップは、多くのリーダーが自社のデータベース環境が実際にどれほど断片化しているかを過小評価していることを示しています。

DBAにとってこの断片化は、ダッシュボード間の行き来、矛盾するアラートの調整、不完全な可視性での稼働時間維持を意味します。その結果は？ ダウンタイムの増加、対応の遅延、そして高まるフラストレーションです。

消火活動トラップ：緊急が重要を押し出すとき

調査によると、DBAは週平均27時間（労働時間の半分以上）を、チケット対応、バックアップ・復元、システムパッチ適用といった反応的なタスクに費やしています。

これらは重要だが反復的な作業であり、DBAを絶え間ない消火活動のサイクルに閉じ込め、パフォーマンス最適化、自動化、AI導入といった先を見据えた作業に充てる時間をほとんど残しません。

DBAの約75%がアラート疲労を報告し、半数近くがその優先順位付けや対応能力に「非常に大きな」または「深刻な」影響を与えていると述べています。疲労は単なる士気の問題ではなく、ビジネスリスクです。インシデント対応を遅らせ、人的ミスの可能性を高め、信頼性に影響を与えます。

DBAが消火活動に費やす1時間は、システム最適化、新ツールのトレーニング、イノベーション推進に充てられない1時間なのです。

経営陣とDBA：リスクを招く認識のズレ

このレポートで最も注目すべき発見の一つは、経営陣とDBAの認識のズレである。リーダーは自チームに必要なリソースが確保されていると信じがちだが、現場の実態は異なる。

例えば、クラウドコストとパフォーマンス問題が主要な懸念事項である点では双方が一致している。しかしDBAは、スキーマの非効率性、レプリケーション遅延、旧式アーキテクチャといった根本原因を特定する傾向が強い。これらは経営陣のレーダーに捉えられない問題です。

この認識のズレは単なる意思疎通の摩擦にとどまらない。リスクを増大させる。経営陣がチームの直面する技術的課題を過小評価すると、パフォーマンスと信頼性が低下し、離職率が上昇します。

DBAは単なる対応者ではない——早期警戒システムである。彼らの知見を無視することは、後々予防可能な問題の代償を支払うことを意味する。

AIと自動化：機会と格差

人工知能（AI）と自動化はデータベース環境を変革しているが、その影響は均等ではありません。

調査対象のDBAのうち：

  • 65%がジェネレーティブAIを活用したチューニングまたは診断を実施
  • 53%がジェネレーティブAIを記述・コーディング・研究に活用
  • 44%が機械学習モデルの実験中
  • 66%がTerraformやPulumiなどのインフラストラクチャ・アズ・コードツールを使用

しかし成熟度が全てを左右する。完全に統合された環境で働くDBAは、はるかに高い成功率を報告しています：診断の高速化、信頼性の高い自動化、戦略的プロジェクトへの時間確保。サイロ化された環境や部分的に統合された環境では、AIイニシアチブの推進よりも、問題対応に多くの時間を費やしている。AIは壊れたワークフローを修復できない。統合された可視性、高品質なデータ、適切なトレーニングがなければ、高度なツールでさえその可能性を発揮できていません。

エンパワーメント：DBA成功に欠けている要素

技術が進歩する中でも、大半のDBAは最小限のトレーニングしか受けていません。

  • 38%は月にわずか1～2時間
  • 31%は四半期に1～5時間
  • 月に丸1日以上の体系的な学習時間を確保できているのはわずか29%

このエンパワーメント不足は離職率に直接影響します。月に1日以上の研修を受けるDBAは、離職を検討する可能性が9ポイント低くなります。

一方で多くのDBAは自己成長に投資している——61%が年間1,000ドルまでの私費を専門能力開発に充てています。この自己投資は、献身と同時に不満の表れでもあります。

消防士から建築家へ：進化するDBAの役割

日々の課題にもかかわらず、DBAは変化に備えています。彼らは保守モードから戦略的リーダーシップへの転換を望んでいる——パフォーマンスの推進、インフラの拡張、そしてAIを中核業務に統合することです。。

将来の優先事項について尋ねたところ、DBAは以下の目標を最上位に挙げています：

  • 自動化とAIイニシアチブの主導
  • スケーラビリティとパフォーマンス最適化の推進
  • アーキテクチャと設計計画への参画

また、コミュニケーション、コラボレーション、戦略的思考といったソフトスキルの重要性が増していることも認識しています。これらの能力は、技術的な複雑さとビジネス成果の間のギャップを埋めるのに役立ます。

課題は？ほとんどの組織では、DBAがこうした新たな高影響力のある役割へ成長するための余地をまだ作っていないことです。

より良いDBAの未来を築く3つのステップ

『データベースの現状レポート』では、DBAの能力強化とバーンアウト防止を目指す組織に向けたシンプルなロードマップを提示しています：

1. 監視と可視化の統合 監視ツールを単一プラットフォームに統合し、パフォーマンス・依存関係・稼働時間に対する包括的な可視性を提供します。統合システムはアラート疲労を軽減し、チームの迅速な対応を支援します。

2. AIと活用トレーニングへの投資AIと自動化はDBAの生産性を高めますが、チームが活用方法を理解している場合に限ります。すべてのAI導入には体系的な能力開発と実践学習の時間を組み合わせてください。

3. 戦略的業務のための時間確保DBAがアーキテクチャ、最適化、イノベーションに集中できる余裕を与えましょう。成功は消火した火災の数ではなく、そもそも発生する火災の少なさで測るべきです。

結論：エンパワーメントは疲労に勝る

2025年データベース現状レポートが明らかにした重大な真実：現代のDBAは不可欠であると同時に過重負担に直面しています。

燃え尽き症候群、アラート疲労、時代遅れのツールが人材をこの職業から遠ざけている——しかし、ストレスの原因となる同じ要因が変革の原動力にもなり得ます。統合化、AI対応、トレーニングに投資する組織は、運用を改善するだけでなく、データ基盤の将来性を確保し、最も熟練した技術人材を維持しています。

データは明確です。次の行動はあなた、DBA次第です。

タグ: ,

Gluesync ConductorモジュールによるWeb UIからのコンテナデプロイとアップデート

投稿日: 2025年12月2日 作成者: climb
GlueSync MOLO17

Gluesyncでは2.1.7よりConductorと呼ばれるモジュールが追加され、Core Hub UIからDB接続エージェントコンテナのデプロイやアップデートが実施できるようになりました。

手間のかかるymlファイルの更新を実施することなく実施できるため、非常に便利な機能となります。

DB接続エージェントのデプロイ

旧バージョンでは、あらかじめdocker-compose.ymlファイルに定義されたDB接続エージェントのみが読み込まれ、複数DB接続が必要なケースでは手動での書き込みが必要でしたが、Gluesync 2.1.7以降では追加ボタンが追加されています。

追加ボタンをクリックすると、現在利用しているGluesyncバージョンでサポートされる接続エージェント一覧がリストされ、選択することで画面右側の領域に表示されます。
この時、ニックネーム項目は自動で文字列が入力されますが、この文字列でログフォルダが生成されるため、認識しやすい文字列(例えばsource-db-oracleなど)を入れることを推奨しています。

入力が完了したら右下の検証して進むをクリックすることで、DB接続エージェントコンテナがデプロイされます。

docker-compose.ymlファイルを確認してみると、末尾にデプロイしたDB接続エージェントコンテナが記録されていることがわかります。
旧バージョンでは、この記載を手動構成する必要があったため、コンテナそのものに関する知識を要求されましたが、Conductorモジュールの登場によって自動化されたことによりDB接続追加のハードルが低くなりました。

なお、デプロイされたコンテナはタイムゾーンが指定されておらず、デフォルトでUTCタイムゾーンとして動作します。
このため、こちらのブログを確認してタイムゾーンを変更することが推奨されます。

タイムゾーンを変更し、当該DB接続エージェントコンテナのログファイルを確認すると、意図したタイムゾーンで動作していることが確認できます。


コンテナのアップデート

旧バージョンでは、Gluesyncコンテナのアップデート操作はこのブログで紹介されているコマンドベースでの対応となっていました。

Conductorモジュールが導入されているGluesync環境では、Core Hub UI左のタブにてモジュールマネージャーと呼ばれるアイコンが表示されており、この画面からアップデート操作が実施できます。

モジュールマネージャーを開くと、自動的に開発元が公開しているDockerリポジトリを参照し現在利用しているバージョンより新しいバージョンが存在するか確認します。
利用可能なバージョンが公開されている場合、更新が利用可能であるポップアップが表示されます。

ただあくまでも新しいバージョンが公開されていることの通知のみとなり、実際のアップデート操作は画面右上の更新ボタンをクリックし、

改めて出力されたポップアップ画面にて更新ボタンをクリックすることで開始されます。
※自動的にコンテナ再起動が実施されるため、Core Hub UIから一時的にログアウトされます。

制限事項

本日(2025/12/2)時点では、ConductorモジュールはLinux版のGluesyncにて先行実装されており、Windows版は今後実装される予定となります。

このため、DB接続エージェント追加希望の場合には、弊社サポートチームにお問い合わせください。
併せて、Windows版でのアップデート操作は旧バージョンと同様にコマンドベースでの対応となります。

タグ: , , , , ,

Gluesync 2.1.8 のリリース

投稿日: 2025年11月15日 作成者: climb
GlueSync MOLO17

Gluesync 2.1.8 がリリースされました。最新バージョンリアルタイムデータ統合プラットフォームが登場です。本リリースでは、v2.1.7 で初めて導入されたオーケストレーター機能を、Web GUI 経由のプラットフォーム内アップデートを通じて拡張。新たな Cassandra ターゲットエージェントを導入し、Snowflake パイプラインのパフォーマンスを大幅に向上させました。

UIを離れることなくGluesyncを更新

バージョン2.1.8では、管理者がGluesync Core Hubインターフェース内で直接モジュールと更新を管理できるようになりました。

新たなモジュールマネージャーにより、チームはワンクリックで以下にアクセス可能：

  • インストール済みモジュールとそのステータスの確認
  • 利用可能な更新の自動チェック（新バージョンが利用可能になるとプラットフォームが通知）
  • UIから単一操作で手動更新を実行
  • 設定メニューから直接MOLO17サポートへログをアップロードし、チケット解決を迅速化。

この機能はv2.1.7でリリースされたConductorモジュールを基盤とし、Linuxベースのデプロイメントが手動CLI操作なしで更新を処理できるようにします。ブラウザ内で更新自動化を実現することで、Gluesyncはメンテナンス時間を削減し、大規模データファブリック環境におけるシームレスなライフサイクル管理を保証します。

Cassandraターゲットエージェントのご紹介

Apache CassandraサポートがGluesync 2.1.8に正式搭載され、プラットフォームのNoSQLポートフォリオを拡充し、ハイブリッドデータ統合エコシステムを強化します。

この新エージェントにより、組織はサポート対象ソースからCassandraターゲットへリアルタイムでデータを複製でき、データベースの高可用性と分散アーキテクチャを活用できます。

主な利点：

  • リレーショナル／NoSQLソースからCassandraへのリアルタイムCDC（変更データキャプチャ）フロー
  • 大規模データロード向け最適化された一括書き込みとバッチ処理
  • Core Hub UI内での自動スキーママッピングと型処理
  • マルチノード展開における透過的なスケーリング

Snowflake バルク書き込みサポート

Gluesync 2.1.8 では、Snowflake 向けバルク書き込みが導入され、クラウドネイティブデータウェアハウスをターゲットとするパイプラインのパフォーマンスが大幅に向上しました。

バッチ挿入機能により、Snowflake へのデータ複製はより高速かつリソース効率が向上し、大容量の ETL、CDC、分析ワークロードに最適です。

これにより、大規模スナップショットや継続的更新における取り込み速度が最大5倍高速化され、書き込み操作時のレイテンシが低減。さらに最適化されたクエリ実行計画により、コンピューティングコストも削減されます。

この強化は、バージョン2.1.6で導入されたAWS S3およびParquetフォーマット向け最適化に続き、クラウドストレージターゲット向けのパフォーマンスエンジニアリングに注力するGluesyncの姿勢を継承するものです。

追加のUIおよびエージェント改善

主要機能に加え、Gluesync 2.1.8では数多くのQoL（生活の質）向上の更新を提供します：

  • ターゲットテーブル作成前のフィールドエディタにおけるカスタム精度・スケール編集機能
  • リアルタイム監視UX向上のための通知レート制限の改善
  • NoSQL ターゲット列編集の修正、および可読性向上のためのマイナーな UI 強化。

タグ: , ,

Gluesyncの評価手順（Windows版：2025/11/13現在)

投稿日: 2025年11月13日 作成者: climb
GlueSync MOLO17

Gluesyncの評価を申請すると下記の様なメールが届きます。Download Gluesyncのリンクを開きます。

下記ページにて、Windows環境へインストールする場合はWindowsタブを選択します。そして、評価用のキットごとにIDが割り当てられているため、それを控えて起きます（インストール時や他のツール利用時などにも利用します。）。

そして、 Windows Server 2019または2022へのインストールであり、Docker等が構成されていない場合、Automated setupの手順に従ってDocker含めインストールが可能です。

Dockerが、すでに構築済みである場合やPodman へデプロイする場合には、トライアルキットをダウンロードし、構築済みの環境にデプロイします。

今回はAutomated setupでDocker含めWindows Server 2022へインストールしてみます。インストーラのPowerShellスクリプトをダウンロードし実行します。管理者としてPowerShellコンソールを実行します。

Invoke-WebRequest -Uri "https://molo17.com/gs-content/utils/docker-installer-windows.ps1" -OutFile "gluesync-installer.ps1"
.\gluesync-installer.ps1

スクリプトが起動したら、yesを入力し、Enterを押します。

Windowsコンテナ方式をDockerで使用するための構成が実施され、再起動が要求されますので、yesを入力し、Enterを押し、即座に再起動し、再起動後にインストールを継続することを許可します。

再起動後にアクセスすると自動でPowerShellが起動し、インストールは継続されます。Dockerのインストールまで完了したら、Gluesyncのセットアップを続行するためにyを入力しEnter、キットIDを入力しEnter

Gluesyncのインストールも完了し、即座に起動する場合はyを入力し、Enterでdockerリポジトリから各イメージがpullされ、コンテナが起動します。

※利用しているTraefik reverse proxyがDocker 29における最小APIバージョンの引き上げでエラーとなり、Web UIにアクセスできなくなることがあります。この場合、下記URLで紹介されているように、”C:\ProgramData\docker\config\daemon.json”で最小APIバージョンを従来の1.24へ変更し、Docker Engineサービスを再起動します。
https://www.docker.com/blog/docker-engine-version-29/

上記でインストールされたGluesyncのdocker-compose.ymlなどはC:\Program Files\Gluesyncに配置されており、各コンテナで保持するデータはC:\Program Files\Gluesync\dataに配置されています。

サーバ再起動後などは上記に移動するか、-fオプション付きでdocker-compose.ymlを指定してdocker-composeコマンドからコンテナを起動できます。

PS C:\Users\Administrator> cd "C:\Program Files\Gluesync"
PS C:\Program Files\Gluesync> docker-compose up -d

コンテナが正常に起動したらWeb UI（https://<IPアドレス>/）にアクセスし、デフォルトのユーザ/パスワード(admin/admin)でログインすると、パスワードの変更が求められるため、変更します。

Windows環境の場合、Web UIからの接続エージェント追加にはまだ対応していません。評価申請時に指定した、接続エージェントがdocker-compose.ymlで事前定義されていますのでそれを使用します。

接続エージェントを追加する場合は下記URLのように、docker-compose.ymlに追記します。https://docs.molo17.com/gluesync/v2.1/deploy-and-run/add-new-agent-in-docker-compose.html

使用できる接続エージェントのイメージは下記のDockerリポジトリを参照してください。https://hub.docker.com/u/molo17

Web UIから接続エージェントの追加が行えない以外はLinux版と同様ですので、残りは下記をご参照ください。

Gluesyncの評価手順（Linux版：2025/11/7現在)
コメントする -->

Gluesyncの評価手順（Linux版：2025/11/13現在)

投稿日: 2025年11月13日 作成者: climb
GlueSync MOLO17

Gluesyncの評価を申請すると下記の様なメールが届きます。Download Gluesyncのリンクを開きます。

下記ページにて、Linux環境へインストールする場合はLinuxタブを選択します。そして、評価用のキットごとにIDが割り当てられているため、それを控えて起きます（インストール時や他のツール利用時などにも利用します。）。

そして、Linux ディストリビューション (Fedora, Ubuntu, Debian, CentOS, Red Hat, Amazon Linux)へのインストールであり、Docker等が構成されていない場合、Automated setupの手順に従ってDocker含めインストールが可能です。

Dockerが、すでに構築済みである場合やKubernetesへデプロイする場合には、トライアルキットをダウンロードし、構築済みの環境にデプロイします。

今回はAutomated setupでDocker含めインストールしてみます。インストーラのshスクリプトをLinuxにダウンロードし、実行します。実行する際にはsudo/rootアクセスが必要です。

wget -O gluesync-installer.sh "https://molo17.com/gs-content/utils/docker-installer.sh" 
 sudo chmod +x ./gluesync-installer.sh
 sudo ./gluesync-installer.sh

スクリプトは以下を実行します。

  •  十分な権限があるか確認 (root/sudo が必要です)
  • Linux ディストリビューションを検出
  • Docker Engine と Docker Compose をインストール
  • ディスク容量の問題を防ぐためにログを構成
  • Dockerのインストールを確認
  • Gluesync をインストール(この際にキットのID入力を求められます)

下記はDebian環境での実行例です。

Enterでインストールを続行

Dockerのインストールまで完了し、Gluesyncのセットアップを続行するためにyを入力しEnter、キットIDを入力しEnter

Gluesyncのインストールも完了し、即座に起動する場合はyを入力

起動まで完了すると、Web UIへのURLとデフォルトのパスワードが表示されます。

※利用しているTraefik reverse proxyがDocker 29における最小APIバージョンの引き上げでエラーとなり、Web UIにアクセスできなくなることがあります。この場合、下記URLで紹介されているように、/etc/docker/daemon.jsonで最小APIバージョンを従来の1.24へ変更し、Docker Engineサービスを再起動(systemctl restart docker)します。

"min-api-version": "1.24"

上記でインストールされたGluesyncのdocker-compose.ymlなどは/opt/gluesync/に配置されており、各コンテナで保持するデータは/opt/gluesync/dataに配置されています。

Web UIにアクセスし、デフォルトのパスワードでログインすると、パスワードの変更が求められるため、変更します。

変更したパスワードでログインし、「新規パイプラインの作成」からデータベースなどに接続するためのエージェントの構成等を実施していきます。

「ソースを追加」を開き、ソースの接続エージェントを構成していきますが、デフォルトの構成では、エージェントのコンテナ自体がデプロイされていません。そのため、ドロップダウンリストから「追加＋」をクリックします。

使用したいエージェントを左側のリストから選択し、「＞」をクリックします。「検証して進む」クリックすると開発元のリポジトリからエージェントのイメージがダウンロードされ、自動的にデプロイされます。接続エージェントの設定を変更する場合には「エージェントの設定（CPUやRAM割り当てなど）を自分でカスタマイズしたい」にチェックを入れて構成できます。

デプロイが完了したら、その接続エージェントに対してデータベースへの接続情報などを設定します。

ターゲット接続に関しても同様です。

その後はエンティティ（同期するテーブルのマッピング）を構成できます。この時点ですべてのマッピングを構成する必要はなく後から追加も可能です。

最後に設定内容を確認し、完了します。

これで構成は完了です。作成したエンティティの同期を開始できます。

コメントする -->

Gluesync 2.1.7 リリース: Conductor がエージェントオーケストレーションと新たな Kubernetes サポートを実現

投稿日: 2025年10月31日 作成者: climb
GlueSync MOLO17

プラットフォームのオーケストレーションとデプロイの柔軟性を大きく前進させるGlueSyncの新バージョン 2.1.7のリリースを発表いたします。

バージョン2.1.5で強化されたスキーマ処理と2.1.6で導入された強力なテーブル作成機能を基盤とし、今回のアップデートではコンテナ化されたエージェントを管理しインフラ運用を効率化する新モジュールGluesync Conductorを初公開します。

これに加え、バージョン2.1.7では刷新されたKubernetes実装、強化されたDocker Composeキット、プラットフォーム全体の使いやすさと信頼性に関する数々の改善が提供されます。

Gluesync Conductor：Docker環境向け自動エージェントオーケストレーション

本リリースのハイライトは間違いなくGluesync Conductorです。これはコンテナ環境内でのGluesyncエージェントのデプロイ、管理、更新を簡素化するよう設計された新モジュールです。

ConductorはGluesyncのオーケストレーション層として機能し、RESTful APIを提供するとともにCore Hub UIと深く統合されます。

Conductorにより、Dockerベースのデプロイメントはよりスマートで自動化された運用方法を獲得します：

  • UIから直接新規エージェントを追加可能（手動でのYAMLやCompose編集不要）
  • コンテナのライフサイクルとステータスをリアルタイムで監視
  • 自動バージョン追跡と更新を活用できます。
  • 複数のエージェントに対して一貫性のある集中管理された設定を維持できます。

Node.jsで構築されたConductorは、DockerインフラストラクチャとGluesyncコントロールプレーンにシームレスに接続する、モダンなコンテナ管理レイヤーを導入します。

リリース時点では、ConductorはLinuxユーザー向けに利用可能で、後日Windows環境へ拡張予定です。

Gluesync UIから直接エージェントを追加

今回初めて、ユーザーはGluesync Webインターフェースから直接新しいソースまたはターゲットエージェントを追加できるようになりました。

ConductorとCore Hubの統合により、新しいエージェントのデプロイに手動のコマンドライン操作は不要です。代わりに、パイプライン作成ウィザードを通じてプロセスを開始できます：

  1. Core Hub UIからパイプラインの設定ウィザードを開きます。
  2. エージェントを追加をクリックしてデプロイフローを開始します。
  3. リストから目的のソースまたはターゲットエージェントを選択します。
  4. リソース（CPU、RAM、SSLオプション）を設定します。
  5. 確認して続行をクリックすると、数秒で新しいエージェントがデプロイされます。

この機能により、新しいパイプラインの設定時間が短縮され、チームはコンテナ管理ではなく設定とデータフローに集中できるようになります。

刷新されたKubernetesサポート

Gluesync 2.1.7では、Kubernetesデプロイモデルの主要な刷新も導入されました。

新たに設計されたHelmチャートは完全に再構築され、より豊富で標準化されたデプロイ体験を標準で提供します。

主な改善点は以下の通りです：

  • プロキシ、Chronosスケジューラ、Prometheus、Grafanaの組み込みサポート
  • GKE、EKS、AKS環境との互換性
  • ローカルKubernetesデプロイモードにより、テストやハイブリッド環境の構築が容易に
  • 簡素化された設定構造とメンテナンス性の向上

新しいKubernetesデプロイメントガイドが公開され、DevOpsチームが多様なインフラ構成でGluesyncを自信を持って展開できるよう支援します。

強化されたDocker Composeキット

GluesyncのDocker Composeキットは、ファイルとログの直感的な構造で再設計され、環境管理が大幅に改善されました。

ポート 9443 で公開される Portainer と、専用エンドポイントからアクセス可能な監視ツール（/grafana で利用可能な Grafana、/prometheus で利用可能な Prometheus）が含まれています。

Linux ユーザーの場合、Conductor がキットにデフォルトでバンドルされているため、追加のインストールを必要とせずに、新しいオーケストレーション機能にすぐにアクセスできます。

これらの改善により、データ統合環境のデプロイと監視のための、より透明性が高く、保守性の高いコンテナスタックが実現します。

コメントする -->

異種データベース間でもテーブルをサクッと作成 【Gluesync 2.1.6】

投稿日: 2025年10月27日 作成者: climb
GlueSync MOLO17

データベース移行や連携を進める上で、負担になりがちな作業の一つにターゲットテーブルの用意が挙げられます。

連携元と連携先が同じデータベース種であればテーブル定義のエクスポート/インポートも容易となりますが、これが異種データベースの場合は単純なエクスポート/インポートは基本的に利用できず、連携先データベースのルールに応じてカラム型やサイズ、クエリ本文の修正が必要となります。

さらには、連携先テーブルでカラムを増やし更新日時や削除等のフラグを入力したい、連携不要なカラムは予めテーブルから除外しておきたいなど、要件によってはより複雑性が増していきます。

このような声を受けて、Gluesyncでは2.1.6よりターゲットテーブル作成機能を追加しました。
同機能によって、Gluesync UI上でエンティティ(レプリケーションジョブ)を作成する過程で連携先のターゲットテーブルも作成できるようになります。

今回は実施兄ソースをIBM i (AS/400)、ターゲットをMicrosoft SQL Serverとして構成してみました。

前提条件

パイプラインで指定されたターゲットデータベース接続に利用するユーザにはDDL操作権限が付与されており、テーブル作成が許可されている必要があります。

テーブル作成操作

まず、ソース側のIBM i (AS/400)のIIOライブラリには4つのテーブルが存在し、この内EMPLOYEE2をレプリケーション対象とします。

ターゲット側のMicrosoft SQL Serverを確認すると、EMPLOYEE2というテーブルは存在していないことがわかります。

ソーステーブルにチェックを入れることで、どのスキーマに含まれるテーブルへレプリケーションするか指定します。

Table項目をクリックすることで、スキーマ内に含まれるテーブルが自動的に出力されますが、存在しないためリストには出力されません。

Table項目で、ターゲットスキーマ内には存在しない、作成したいテーブル名を入力すると、Table テーブル名 not found. Create テーブル名と出力され、クリックすることで追加のポップアップが出力されます。

フィールドエディタ画面左がソーステーブル、右がターゲットテーブルを示しています。
この時、カラム型や主キー、インデックス制約といったソーステーブル構造をGluesyncが読み取り、ターゲット側のデータベース種に合わせて自動変換しています。

この画面より、必要に応じてカラム名やデータ型変更、カラムのチェックを外しテーブル作成に含めないなどUI上で更新も可能です。
今回は、3つのカラムのみチェックを入れて作成していきます。

保存ボタンをクリックすると発行されるCREATE SQLクエリのレビューが可能であり、同画面では手動入力も可能なため必要に応じてより細かく調整が可能です。
コード・スニペットをコピーするをクリックすると、生成したCREATE SQLクエリ文のコピーも可能です。

テーブルの作成をクリックすると、実際にターゲット側でCREATE SQLクエリが発行されます。

ターゲット側のMicrosoft SQL Serverを改めて確認すると、先ほどは存在しなかったEMPLOYEE2が生成されており、カラム数もGluesync UI上で選択した3つのみとなっていることがわかります。

あとはGluesync UI上で画面を進めることで、テーブル作成と合わせてエンティティ(レプリケーションジョブ)作成も完了します。

制限事項・考慮事項

Gluesync公式ドキュメントに記載されておりますように、Gluesyncではソーステーブル定義を読み取り自動変換を実施しますが、ユーザ独自で定義されたデータ型等は変換ができず手動での調整が必要になる場合があります。
また、外部キー制約も自動読み取り、変換がサポートされないため、このようなテーブルも手動での調整が必要になります。

タグ: , , , , ,

Parquetで連携し、より効率的なデータ分析を簡単に実現【Gluesync】

投稿日: 2025年10月21日 作成者: climb
GlueSync MOLO17

既存のデータベース上にあるデータをクラウド上で分析する際に、コネクタなどで直接参照するといった方法もありますが、セキュリティなどの観点から直接の参照はむずかしい、データをマスクやフィルタリングする必要があるなど、手間がかかります。

Amazon Athena

Azure Data Factory

BigQuery

このような際に、Gluesyncを使用して、データを基盤となるAWS S3やAzure Data Lake Gen 2、Google Cloud Storageに連携しておくことで簡単に分析が行えます。

そして、GluesyncはAWS S3、Azure Data Lake Gen 2、Google Cloud Storageでの連携において、JSON形式のみでなく、最新版2.1.6にてParquetファイルをサポートしました。

Parquetファイルとは何かといった点に関しては、下記のブログなどが参考になるかと思います。簡単に言えば、CSV等とは異なり、バイナリでデータを保持することでサイズを削減し、列指向データ形式により、Amazon AthenaやAzure Data FactoryなどのBigQuery、データ分析パフォーマンスを大幅に向上できます。

既存データベース上のテーブルをCSVでエクスポートすることは簡単でも、Parquetでエクスポートすることは難しい場合が多く、追加での変換などが必要になるケースが多いですが、Gluesyncであれば、そのような手間なく、Parquetファイルで以下のようなデータのカスタマイズ、リアルタイム同期まで実現できます。

  • 必要なテーブル/カラムのみ連携
  • レコードの値でフォルタリング
  • UDF（ユーザ定義関数）で変換やマスキング
  • 全件同期のスナップショット
  • 差分同期のCDC

今回は実際にソースをPostgreSQL、ターゲットをAmazon S3として、この同期を構成してみました。

パイプラインの作成

コンテナでCoreHubやPostgreSQL/AWS S3との接続エージェントを起動しておき、Web UIからパイプライン（データプラットフォームとの接続）を作成していきます。

新規パイプラインの作成をクリック

    ソースを追加をクリック

    PostgreSQLを接続のエージェントとして選択して、接続情報を入力、テストして続行をクリックして次へ

    ターゲットを追加をクリック

    AWS S3 & S3-likeを接続のエージェントとして選択して接続情報（エンドポイントのURL、ポート、バケット名、アクセスキー、シークレットキー、リージョン）を入力、テストして続行をクリックして次へ

    エンティティの設定

    対象となるソーステーブルを選択

    ターゲットの接続が表示されますが、S3の場合は適当なスコープとコレクションを指定します。ここで指定したスコープとコレクションはS3上のディレクトリ名に影響します。

    フィールドの編集からカラムのマッピングやUDFの指定が行えます。

    今回はsalaryとpercentage_salaryを対象外にします（デフォルトで同名でマッピングされています）。

    UDFも構成し、削除操作の際にnameカラムをマスクという値へ置き換えています。

    設定では各種追加の設定が行えます。

    今回は受信データのフィルタリングでmanageカラムがNullでない場合のみ同期させるようにフィルタを設定しました。また、Use JSON files instead of Parquet(default)のトグルをオンにするとParquetファイル形式ではなくJSONファイル形式でS3へ同期するように変更できます。

    最終的な設定を確認し、保存して完了をクリック

    これで同期設定は完了です。

    同期を開始する前に、テーブル構成として下記のように簡単なサンプルデータが入ってます。

    "id","name","job","manager","hiredate","salary","percentage_salary","department_number"
"10","大竹","営業",NULL,"1970-11-13 00:00:00","240002","195126","10"
"11","田中","営業","10","2026-01-20 00:00:00","244413","8559","10"
"12","渡部","PM",NULL,"1969-03-11 00:00:00","253960","225","10"
"13","藤田","PM",NULL,"2005-10-06 00:00:00","259866","26066","10"
"14","鈴木","SE","12","2012-12-21 00:00:00","263442","23123","10"
"15","高橋","SE","12","2010-09-06 00:00:00","247375","8095","10"
"16","秋葉","SE","13","1973-06-25 00:00:00","240462","999846","10"
"17","辻本","インフラ","12","2030-06-10 00:00:00","242318","422677","10"
"18","津田","インフラ","13","1943-12-18 00:00:00","251237","100463","10"
"19","角田","セキュリティ","13","2027-02-14 00:00:00","259018","57974","10"

    ターゲットとなるバケットは空の状態です。

    同期を開始します。今回はCDC（差分同期）＋初期スナップショット（全件同期：Insert

    モード）で実行するように指示しています。

    同期し、初期スナップショットが完了すると下記のようにS3の階層化にJSONとParquetが配置されます。階層構造としては以下のようになっています。

    - raw
  - snapshot
    - <スコープ名>_<コレクション名>
      - year=<同期した年>
        - month=<同期した月>
          - <同期した日時>.json
          - <同期した日時>.parquet

    そしてJSONファイルには、実データではなく、どのような同期が行われたかを示すメタデータが保存されます。下記は、7レコードがInsertされたことを示しています。

    {
  "rowCount": 7,
  "timestamp": "2025-10-20T08:41:43.645221375",
  "operations": [
    {
      "type": "Insert"
    },
    1
  ],
  "schemaVersion": 1
}

    そして実データとなるParquetファイルをS3 Selectで参照してみると、下記のようにデータがは入っています。

    10,2012-12-21T00:00:00,14,SE,12,鈴木,I
10,2026-01-20T00:00:00,11,営業,10,田中,I
10,2010-09-06T00:00:00,15,SE,12,高橋,I
10,1973-06-25T00:00:00,16,SE,13,秋葉,I
10,2030-06-10T00:00:00,17,インフラ,12,辻本,I
10,1943-12-18T00:00:00,18,インフラ,13,津田,I
10,2027-02-14T00:00:00,19,セキュリティ,13,角田,I

    並び順が変わっているため少々分かりづらいですが、設定した通り、salaryとpercentage_salaryカラムは連携されず、managerがnullのレコードもフィルタリングされ、必要なデータのみが同期されていることを確認できます。

    また、どのような操作で連携されたか示す符号（I：Insert、U：Update、D：Delete）が追加されます。上記はInsertモードでのスナップショット同期のため、IのInsertが追加されています。

    次に、ソーステーブルに変更（Insert/Update/Delete）を行い変更をCDCで同期させてみます。

    CDCで同期されたファイルは下記のように異なる階層に配置されます。

    - raw
  - changes
    - <スコープ名>_<コレクション名>
      - year=<同期した年>
        - month=<同期した月>
          - <同期した日時>.json
          - <同期した日時>.parquet

    今回は各操作を実施しているため、同期されたレコード数は合計3件、各操作ごとに1件ずつであることを示すJSONも合わせて保存されています。

    {
  "rowCount": 3,
  "timestamp": "2025-10-20T08:49:39.699363299",
  "operations": [
    {
      "type": "Update"
    },
    1,
    {
      "type": "Delete"
    },
    1,
    {
      "type": "Insert"
    },
    1
  ],
  "schemaVersion": 1
}

    ParquetファイルをS3 Selectで参照してみると、下記のようにデータがは入っています。

    10.0,2012-12-21T00:00:00,14.0,SE,12.0,アップデート,U
10.0,2010-09-06T00:00:00,15.0,SE,12.0,マスク,D
20.0,2026-01-11T00:00:00,20.0,SE,12.0,インサート,I

    同様に符号（I：Insert、U：Update、D：Delete）が追加されており、削除操作に関してはUDFにより、マスクへ変換され同期されていることを確認できます。

    このように簡単に構成でき、既存データが必要なデータのみを、データ分析の基盤となるストレージへ、効率の良いParquet形式で同期できます。

    スケジュール、同期間隔について

    また、上記のようにスナップショット:snapshotとCDC:changesに分かれて保持されますが、同期の設定（エンティティ）は、スケジュールで実行を制御できるため、例えば定期的な全件（スナップショット）同期のみを行い、CDCは実行しないといった設定も可能です。

    Gluesyncによる同期をスケジュール管理：クロノススケジューラ

    加えてエンティティのオプション設定にてポーリングインターバル(ms)を変更することで、CDCで同期される間隔を調整できます。

    リアルタイム性を高めるためデフォルトは100ms間隔でソースの変更を検知し、変更があれば同期するため、常に変更が発生しているテーブルの場合、changesに大量のParquetファイルが作成されることになります。

    このような場合、この間隔を延ばして、5分おき（300000ms）に同期させるように変更するなどの対応も可能です。

    タグ: , , , , ,

    Azure SQL Database のリストア

    投稿日: 2025年9月26日 作成者: climb
    SQL Server データベース

    Azure SQL Database のバックアップと復元に関する制限事項

    Azure SQL Database はバックアップと復元機能を提供していますが、バックアップ戦略を計画する際には考慮すべき制限事項があります。これらの制限事項はG2プラットフォームから引用したものです:

    • ポイントインタイム復元 (PITR) の保持期間: PITRの最大保持期間は35日間です。より長い保持期間が必要な場合、ユーザーは長期保持 (LTR) ポリシーを設定する必要があります。
    • テーブル単位の復元不可: Azure SQL Databaseは個々のテーブルの復元をサポートしていません。データを復旧するにはデータベース全体を復元する必要があり、より多くの時間とリソースを消費する可能性があります。
    • バックアップ間隔の制限: トランザクション ログ バックアップの頻度は5～10分ごとであり、より厳格なリカバリ ポイント目標(RPO)を必要とするシナリオには適さない場合があります。
    • 復元時間とリソース: 大規模データベースの復元には時間がかかり、リソースを大量に消費するため、復旧プロセス中のパフォーマンスに影響を与える可能性があります。
    • 地理的に冗長化されたストレージへの依存: バックアップは地理的に冗長化されたストレージに保存されますが、レプリケーションに最大1時間の遅延が生じる可能性があるため、地理的にレプリケートされたバックアップからの復旧には遅延が発生する可能性があります。
    • サーバー削除時のバックアップ失敗: SQLサーバーが削除されると、関連するすべてのバックアップが失われ復元不可能となり、データ損失につながる可能性があります。
    • Azure SQL Databaseのバックアップはサービス管理型: これは、追加の保護を実装しない限り、Azureのデフォルトバックアップ頻度（週次フル、数時間ごとの差分、5～10分ごとのトランザクションログ）に縛られることを意味し、より厳格なRPO要件に適合しない場合があります。

    Azure SQL Databaseにおける信頼性の高い復元のためのベストプラクティス

    組織は、Azure SQL Databaseを使用する際の復元を成功させるために、以下のプラクティスを検討すべきです。

    1. 地理的冗長ストレージの実装

    地理的冗長ストレージ（GRS）は、バックアップをプライマリロケーションから離れたセカンダリAzureリージョンに複製することでデータ保護を強化します。リージョン障害や災害が発生した場合でも、復旧のための直近のバックアップへのアクセスを維持し、重大なインシデントにおけるビジネス継続性を確保します。GRS はデータベース作成時または後からサービス階層の設定で簡単に有効化できます。

    地理的冗長性の選択にはコストがかかりますが、リスク軽減のメリットは、エンタープライズワークロードやコンプライアンス重視の業界にとって投資を正当化するものです。自動レプリケーションにより、管理者はバックアップが単に保存されるだけでなく地理的に分散されていることを確信でき、単一ロケーションに影響を与える地域障害やサービス障害によるデータ損失のリスクを低減します。

    2. 復元プロセスの文書化と自動化

    復元手順を文書化することで、チームは様々な復旧シナリオにおける手順を把握でき、インシデント発生時の混乱やミスを軽減します。PITR、地理的復元、削除済みデータベース、LTRを含む全ての復元オプションについて、前提条件、正確なコマンド、必要な権限、復元後のタスクを網羅した明確でアクセスしやすい形式で文書化すべきです。

    主要な Azure 変更やプロセス変更のたびに、参照用ドキュメントを見直し更新する必要があります。自動化により復旧アクションを標準化し、重大なイベント時の手動入力依存度を低減することで、リスクをさらに最小化します。自動化スクリプトやAzure Runbooksは、復元開始、復旧テスト、完了/エラー通知システムの統合を実行できます。

    3. 復元手順の定期的なテスト

    復元の信頼性は、一貫した定期的な検証に依存します。定期的にスケジュールされたテスト復元により、バックアップの完全性と、復元ドキュメントおよび自動化スクリプトの正確性が検証されます。これらのテストでは、データベースの代表的なサンプルを使用し、ポイントインタイムリカバリから災害地域ジオリストアまで、様々な復元シナリオを網羅する必要があります。

    テストを実施しない場合、組織は本番環境でのインシデント発生時にのみ問題を発見するリスクがあり、ダウンタイムやデータ損失が拡大する可能性があります。テストはまた、手順のドリフト、構成の不一致、Azureのバックアップまたは復元ポリシーにおける予期せぬ変更を特定します。各テストの結果を文書化し、不一致に対処し、必要に応じてランブックやスクリプトを適応させてください。

    4. 大規模データベース復元の計画

    Azure SQL Database における大規模データベースの復元は、処理・転送されるデータ量の増加により、大幅に時間がかかる場合があります。管理者は、復元時間がデータベースのサイズ、ネットワークスループット、選択した復元方法に比例することを理解する必要があります。

    重要なデータベースについては、テスト復元に基づいて復元時間を事前に計算し、現実的な復旧時間目標 (RTO) を設定し、必要に応じて長時間のダウンタイムに備えることが不可欠です。可能な場合は、複数の大規模データベースを復元する際に復元操作を時差で実施するか、重要なワークロードを優先してください。追加のボトルネックを回避するため、ソース環境とターゲット環境の両方で十分なコンピューティングリソースとIOPSリソースを確保してください。

    5. バックアップ失敗に対するアラートの活用

    Azureは、Azure MonitorとSQLメトリクスを使用してバックアップ失敗のアラートを作成するツールを提供しています。自動通知を設定することで、スケジュールされたバックアップが正常に完了しなかった場合に、適切な担当者が即座に通知を受け取ることができます。早期警告により、管理者はデータ復元可能性やコンプライアンスを脅かす前に問題を調査・解決できます。

    バックアップの完全な失敗だけでなく、異常な遅延、スケジュールの未実行、バックアップサイズや頻度の変更に対してもアラートを設定してください。環境の変化や新たなリスクの特定に伴い、定期的にアラート基準を見直し、改善してください。

    Azure SQL Databaseにおける信頼性の高い復元のためのベストプラクティス

    組織は、Azure SQL Databaseを使用する際の復元を成功させるために、以下のプラクティスを検討すべきです。

    1. 地理的冗長ストレージの実装

    地理的冗長ストレージ（GRS）は、バックアップをプライマリロケーションから離れたセカンダリAzureリージョンに複製することでデータ保護を強化します。リージョン障害や災害が発生した場合でも、復旧のための直近のバックアップへのアクセスを維持し、重大なインシデントにおけるビジネス継続性を確保します。GRS はデータベース作成時または後からサービス階層の設定で簡単に有効化できます。

    地理的冗長性の選択にはコストがかかりますが、リスク軽減のメリットは、エンタープライズワークロードやコンプライアンス重視の業界にとって投資を正当化するものです。自動レプリケーションにより、管理者はバックアップが単に保存されるだけでなく地理的に分散されていることを確信でき、単一ロケーションに影響を与える地域障害やサービス障害によるデータ損失のリスクを低減します。

    2. 復元プロセスの文書化と自動化

    復元手順を文書化することで、チームは様々な復旧シナリオにおける手順を把握でき、インシデント発生時の混乱やミスを軽減します。PITR、地理的復元、削除済みデータベース、LTRを含む全ての復元オプションについて、前提条件、正確なコマンド、必要な権限、復元後のタスクを網羅した明確でアクセスしやすい形式で文書化すべきです。

    主要な Azure 変更やプロセス変更のたびに、参照用ドキュメントを見直し更新する必要があります。自動化により復旧アクションを標準化し、重大なイベント時の手動入力依存度を低減することで、リスクをさらに最小化します。自動化スクリプトやAzure Runbooksは、復元開始、復旧テスト、完了/エラー通知システムの統合を実行できます。

    3. 復元手順の定期的なテスト

    復元の信頼性は、一貫した定期的な検証に依存します。定期的にスケジュールされたテスト復元により、バックアップの完全性と、復元ドキュメントおよび自動化スクリプトの正確性が検証されます。これらのテストでは、データベースの代表的なサンプルを使用し、ポイントインタイムリカバリから災害地域ジオリストアまで、様々な復元シナリオを網羅する必要があります。

    テストを実施しない場合、組織は本番環境でのインシデント発生時にのみ問題を発見するリスクがあり、ダウンタイムやデータ損失が拡大する可能性があります。テストはまた、手順のドリフト、構成の不一致、Azureのバックアップまたは復元ポリシーにおける予期せぬ変更を特定します。各テストの結果を文書化し、不一致に対処し、必要に応じてランブックやスクリプトを適応させてください。

    4. 大規模データベース復元の計画

    Azure SQL Database における大規模データベースの復元は、処理・転送されるデータ量の増加により、大幅に時間がかかる場合があります。管理者は、復元時間がデータベースのサイズ、ネットワークスループット、選択した復元方法に比例することを理解する必要があります。

    重要なデータベースについては、テスト復元に基づいて復元時間を事前に計算し、現実的な復旧時間目標 (RTO) を設定し、必要に応じて長時間のダウンタイムに備えることが不可欠です。可能な場合は、複数の大規模データベースを復元する際に復元操作を時差で実施するか、重要なワークロードを優先してください。追加のボトルネックを回避するため、ソース環境とターゲット環境の両方で十分なコンピューティングリソースとIOPSリソースを確保してください。

    5. バックアップ失敗に対するアラートの活用

    Azureは、Azure MonitorとSQLメトリクスを使用してバックアップ失敗のアラートを作成するツールを提供しています。自動通知を設定することで、スケジュールされたバックアップが正常に完了しなかった場合に、適切な担当者が即座に通知を受け取ることができます。早期警告により、管理者はデータ復元可能性やコンプライアンスを脅かす前に問題を調査・解決できます。

    バックアップの完全な失敗だけでなく、異常な遅延、スケジュールの未実行、バックアップサイズや頻度の変更に対してもアラートを設定してください。環境の変化や新たなリスクの特定に伴い、定期的にアラート基準を見直し、改善してください。

    N2WSによるAzure SQL Databaseバックアップの最適化

    Azureの組み込みバックアップおよび復元ツールがあっても、多くの組織では次のような課題に直面しています：

    • 復元はAzureの保持期間内でのみ機能します。
    • PITR（ポイント・イン・タイム・リカバリ）の「インプレース」復元は不可能です。
    • サーバーが削除されると、すべてのバックアップが消失します。
    • クロスリージョンまたはクロスクラウドの復元ワークフローはネイティブで提供されていません。

    そこでN2WSが活躍します。N2WSを利用すると以下のことが可能になります：

    • Azureの制限を超えた保持期間の延長：Microsoftの保持ポリシーだけに依存することなく、Azure SQLバックアップを数年間、さらには数十年間にわたりアーカイブできます。
    • マルチリソース復元の一元管理：SQLデータベース、VM、ネットワーク構成など、環境全体を必要な順序で正確に復元。
    • 誤削除からの保護：削除権限のない「クリーン」なDRアカウントに不変バックアップを保管し、真のエアギャップを実現。
    • ストレージコスト削減：アクセス頻度の低いバックアップを自動的に低コストストレージ階層にアーカイブ。必要な時は即座に復元可能。さらにAzure Backupと異なり、VMのサイズに関わらず定額料金です。

    N2WSはセキュアなAPI呼び出しでクラウドアカウント内で動作するため、データは常に管理下に留まります。復旧オプションもAzureポータルをはるかに超えて拡張されます。

    タグ: , , , ,

    [Gluesync 2.1.4] WindowsネイティブビルドのGluesyncコンテナサポート！

    投稿日: 2025年9月26日 作成者: climb
    GlueSync MOLO17 データベース

    Gluesyncでは、バージョン2.1.4.0よりWindows環境においてもWSLを利用することなくGluesyncコンテナをデプロイ/起動しレプリケーションを実行することが可能となりました。

    Linuxビルド、Windowsビルドによって提供される機能に違いはなく、社内ルール上Windows OSしか構成できない、Linuxの操作には不安があるといった場合でも、利用者のニーズに応じてコンテナランタイムが実行されるホストOSを選定可能です。

    実際にクライムテスト環境のWindows Server Core 2022上で、WindowsネイティブビルドのGluesyncをテストしてみました。

    Windows環境の事前準備

    Windows Server 2022以降に対して、開発元ドキュメントに記載されている手順にてDocker Engineのインストール、Docker Composeの設定を行います。

    Gluesyncトライアルキットについて

    バージョン2.1.4より、Gluesyncトライアルキット内に「gluesync-docker-windows」というフォルダが追加され、このフォルダ内にWindowsネイティブビルド用の構成ファイルが用意されています。

    Docker構成が完了したWindowsへトライアルキットをコピーし、コマンドラインより「gluesync-docker-windows」フォルダへ移動します。

        ディレクトリ: C:\Users\Administrator\molo17


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        2025/09/18      9:14                gluesync-docker
d-----        2025/09/18      9:14                gluesync-docker-windows
d-----        2025/09/18      9:14                gluesync-kubernetes
d-----        2025/09/18      9:14                utilities
-a----        2025/09/18      9:14          33525 gluesync-preflight.ps1
-a----        2025/09/18      9:14          12933 gluesync-preflight.sh
-a----        2025/09/18      9:14           3899 README.md
-a----        2025/09/18      9:14          84252 trial-agreement.pdf


PS C:\Users\Administrator\molo17> cd .\gluesync-docker-windows\
PS C:\Users\Administrator\molo17\gluesync-docker-windows> ls


    ディレクトリ: C:\Users\Administrator\molo17\gluesync-docker-windows


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        2025/09/18      9:14                chronos-config
d-----        2025/09/18     18:57                chronos-data
d-----        2025/09/18     18:49                gluesync-core-hub
d-----        2025/09/26      0:00                gluesync-core-hub-logs
d-----        2025/09/18     18:49                gluesync-source
d-----        2025/09/26      0:00                gluesync-source-logs
d-----        2025/09/18     18:49                gluesync-target
d-----        2025/09/26      0:00                gluesync-target-logs
d-----        2025/09/17     10:38                grafana
d-----        2025/09/17     10:38                prometheus
d-----        2025/09/17     10:38                proxy
-a----        2025/09/18      9:14           7425 docker-compose.yml


PS C:\Users\Administrator\molo17\gluesync-docker-windows>

    Gluesyncコンテナの取得

    docker-compose pullコマンドを実行することで、トライアルキットに含まれるdocker-compose.ymlファイルで定義されたGluesyncコンテナのダウンロードが開始されます。

    PS C:\Users\Administrator\molo17\gluesync-docker-windows> docker-compose pull
[+] Pulling 78/82
 ✔ grafana Pulled                                                                                                                            1.7s
 ✔ reverse-proxy Pulled                                                                                                                      1.7s
 ✔ gluesync-ibm-iseries-source Pulled                                                                                                      197.6s
 - gluesync-chronos [⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿] 2.252GB / 2.252GB Pulling                                                                         313.6s
 ✔ portainer Pulled                                                                                                                          1.7s
 ✔ prometheus Pulled                                                                                                                         1.7s
 ✔ gluesync-core-hub Pulled                                                                                                                 50.5s
 - gluesync-mssql-ct-target [⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣀⣿⣿⣿⣿] 436.9MB / 479.8MB Pulling                                                                 313.6s

    Gluesyncコンテナのダウンロードが正常に完了すると、すべてのステータスがPulled表記となります。

    PS C:\Users\Administrator\molo17\gluesync-docker-windows> docker-compose pull
[+] Pulling 82/82
 ✔ grafana Pulled                                                                                                                            1.7s
 ✔ reverse-proxy Pulled                                                                                                                      1.7s
 ✔ gluesync-ibm-iseries-source Pulled                                                                                                      197.6s
 ✔ gluesync-chronos Pulled                                                                                                                 343.6s
 ✔ portainer Pulled                                                                                                                          1.7s
 ✔ prometheus Pulled                                                                                                                         1.7s
 ✔ gluesync-core-hub Pulled                                                                                                                 50.5s
 ✔ gluesync-mssql-ct-target Pulled                                                                                                         864.2s

    Gluesyncコンテナの実行

    ダウンロードが完了したら、docker-compose up -dと入力しGluesyncコンテナを起動します。

    PS C:\Users\Administrator\molo17\gluesync-docker-windows> docker-compose up -d
[+] Running 9/9
 ✔ Network gluesync-windows_default                          Created                                                                         0.1s
 ✔ Container portainer                                       Started                                                                         4.2s
 ✔ Container gluesync-windows-grafana-1                      Started                                                                         4.1s
 ✔ Container gluesync-windows-reverse-proxy-1                Started                                                                         3.9s
 ✔ Container gluesync-windows-gluesync-core-hub-1            Started                                                                         4.9s
 ✔ Container gluesync-windows-gluesync-ibm-iseries-source-1  Started                                                                         7.0s
 ✔ Container gluesync-windows-prometheus-1                   Started                                                                         7.0s
 ✔ Container gluesync-windows-gluesync-chronos-1             Started                                                                         8.5s
 ✔ Container gluesync-windows-gluesync-mssql-ct-target-1     Started                                                                         8.0s
PS C:\Users\Administrator\molo17\gluesync-docker-windows>

    docker-compose psコマンドより、各種プロセスが起動しているか確認可能です。
    ※タグ名や実行ファイル名よりWindows上で動作していることがわかります。

    PS C:\Users\Administrator\molo17\gluesync-docker-windows> docker-compose ps
NAME                                             IMAGE                                                 COMMAND                     SERVICE                       CREATED          STATUS          PORTS
gluesync-windows-gluesync-chronos-1              molo17/gluesync-chronos:latest-windows                "entrypoint.bat"            gluesync-chronos              47 seconds ago   Up 39 seconds   1717/tcp
gluesync-windows-gluesync-core-hub-1             molo17/gluesync-core-hub:latest-windows               "C:\\Windows\\System32…"   gluesync-core-hub             48 seconds ago   Up 42 seconds
gluesync-windows-gluesync-ibm-iseries-source-1   molo17/gluesync-ibm-iseries:latest-windows            "C:\\Windows\\System32…"   gluesync-ibm-iseries-source   47 seconds ago   Up 40 seconds
gluesync-windows-gluesync-mssql-ct-target-1      molo17/gluesync-mssql-ct:latest-windows               "C:\\Windows\\System32…"   gluesync-mssql-ct-target      47 seconds ago   Up 39 seconds
gluesync-windows-grafana-1                       molo17/grafana:latest                                 "grafana-server.exe"        grafana                       48 seconds ago   Up 43 seconds   0.0.0.0:6001->3000/tcp
gluesync-windows-prometheus-1                    molo17/prometheus:latest                              "C:\\bin\\prometheus.e…"   prometheus                    47 seconds ago   Up 40 seconds   9090/tcp
gluesync-windows-reverse-proxy-1                 traefik:nanoserver-ltsc2022                           "/traefik --api.inse…"     reverse-proxy                 48 seconds ago   Up 43 seconds   0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp
portainer                                        portainer/portainer-ce:2.33.0-windowsltsc2022-amd64   "/portainer.exe --ad…"     portainer                     48 seconds ago   Up 43 seconds   0.0.0.0:8000->8000/tcp, 0.0.0.0:9443->9443/tcp, 9000/tcp
PS C:\Users\Administrator\molo17\gluesync-docker-windows>


    以降の操作は、Linuxビルドと同様にWeb GUIへアクセスし、レプリケーション対象DBと接続を行います。
    ※LinuxビルドとWindowsビルドによって、Web GUI上の操作が異なることはございません。

    このように、WindowsにおいてもGluesyncコンテナ実行が正式にサポートされましたので、これまでLinux環境での利用に抵抗があったユーザ様にも安心してお使いいただけるものとなります。
    Gluesync評価ご希望の場合は、弊社お問い合わせフォームよりご連絡ください。

    この時「ご質問、ご要望」欄にてレプリケーションしたいDB構成をご記入いただくと、スムーズにご案内が可能です。

    タグ: , , , , , , ,

    Database Performance Analyzer (DPA) 2025.3リリース

    投稿日: 2025年9月25日 作成者: climb
    Database Performance Analyzer (旧Ignite) データベース

    Database Performance Analyzer (DPA) 2025.3の一般提供（GA）リリースは主にメンテナンスリリースですが、いくつかの新機能も含まれています。詳細は以下をご覧ください。

    新しいTeams Webhookサポート

    Teams統合において、Microsoftは従来のコネクタベースのWebhook URLのサポートを終了し、WebフローベースのWebhook URLを採用します。Microsoftは新しいコネクタベースのWebhookに対する暫定サポートを提供していますが、これは2025年末に終了すると発表しています。

    DPAは現在、暫定コネクタベースのWebhookと新しいWebフローベースのWebhookの両方をサポートしており、暫定WebhookまたはレガシーWebhookのいずれかで連絡先を設定している場合、製品内メッセージを提供します。DPAのREST APIも更新され、連絡先にレガシーWebhookを割り当てようとした場合にエラーを返すようになりました。

    信頼された証明書管理

    DPAにはキーストア管理ページが追加され、カスタムの暗号化SSL証明書を使用してDPAに接続できるようになりました。オプションページでは、管理者が「信頼された証明書管理」リンクを使用し、カスタム証明書の保存場所と、DPAがそれにアクセスするための認証情報を指定できます。

    タグ: , , ,

    Gluesyncによる同期をスケジュール管理：クロノススケジューラ

    投稿日: 2025年9月22日 作成者: climb
    GlueSync MOLO17

    GluesyncではChronos Schedulerというコンポーネントを用いて、CDC（変更データキャプチャ）の一時停止や有効化、スナップショットの実行などをスケジュール管理できます。

    Chronos Schedulerはオープンソースプロジェクトであり、別途構成することも可能ですが、Gluesyncの評価キットにも含まれていますので、評価キットからデプロイしていればすぐにご利用いただけます。

    GluesyncのWeb UIの左側にあるカレンダーと時計が合わさったアイコンをクリックすると、設定画面に移動できます。

    ここから以下の様な設定が可能です。

    スケジュールモード

    スケジュールは以下の2種類のモードで設定でき、週次、日次の簡単な繰り返しなら週次モード、複雑なスケジュールならCRONモードを使用できます。

    週次

    実行する曜日と指定したアクションを実行する時間を指定するのみの簡単なスケジュール設定です。

    CRON

    Linuxのスケジューラとしてよく使用されるcron形式でスケジュールを設定可能です。

    cron形式では以下のように各項目で実行するタイミングを値として指定します。
    ※一部動作が一般的なcronと異なる場合があります。

    ┌───────────── 分 (0 - 59)
│ ┌───────────── 時 (0 - 23)
│ │ ┌───────────── 月の日 (1 - 31)
│ │ │ ┌───────────── 月 (1 - 12)
│ │ │ │ ┌───────────── 曜日 (0 - 6) (日曜から土曜)
│ │ │ │ │
│ │ │ │ │
* * * * *

    数字以外にも以下のような記号を使用できます。

    *任意の値
    ,値の区切り文字
    –値の範囲を指定※小さい値から大きい値のみ
    /ステップ値※月の日以外で使用可能

    例：

    15,45 * * * * 毎時で15分と45分に実行
    0 18-23/2 * * *19時から23時間の間、2時間おきで0分に実行
    0 0 1-7 * 0 値の範囲を指定※小さい値から大きい値の毎月1から7日（第1週）の日曜日の0時0分に実行
    ※一般的なcronと異なり月の日と曜日はAND条件で処理されます。
    0 0 * * 1,6 毎週月曜と土曜の0時0分に実行

    スケジュール対象の指定

    スケジュールは個別のエンティティ（テーブル単位の同期設定）、グループ（同一パイプライン内で作成できるエンティティを複数まとめた設定）、パイプライン（データベース接続の組み合わせ）単位で設定できます。

    実行できるアクション

    以下のアクションを設定したスケジュールで実行可能です。

    • 一時停止：実行されているエンティティを一時停止し、同期を停止
    • CDC：変更データキャプチャによるリアルタイムな差分同期を開始
    • TRUNCATEを使用したスナップショット：ターゲットテーブル上のレコードを全件削除後にINSERTにより高速に全件同期を実施
    • TRUNCATEなしでスナップショット：ターゲットテーブル上のレコードを削除せずに、UPSERT（異なる部分をUPDATE、不足部分はINSERT）により全件同期

    スケジュールの実行状況

    スケジュールの実行状況は簡易的には一覧画面で確認できます。ラストランのステータスをクリックすると、実行した日時と次回実行日時を確認可能です。

    また、スケジュールのステータスでチェックを外すことで、削除しなくともスケジュール設定を無効化できます。

    加えてスケジュール実行のみではありませんが、エンティティに対するアクションは個別エンティティのダッシュボード下部の履歴ログや、通知ハブでエンティティ等を絞り込んで確認可能です。

    コメントする -->

    Gluesync 2.1.4 リリース：ネイティブ Windows コンテナサポートとパフォーマンス向上を実現

    投稿日: 2025年9月19日 作成者: climb
    GlueSync MOLO17

    リアルタイムデータ統合プラットフォーム「Gluesync」のWindowsユーザ向け変革的なアップグレードとなるバージョン2.1.4のリリースされました。このアップデートは、完全なWindowsネイティブコンテナサポートと大幅なパフォーマンス向上に焦点を当てています。IBM Db2およびAzure Data Lakeとの統合によりエンタープライズ接続性を拡大したバージョン2.1.3に続き、本バージョンではネイティブWindowsコンテナ技術を提供し、従来存在していたOS間のパフォーマンス格差を解消します。

    Gluesync 2.1.4 の主な機能

    Windows ネイティブ コンテナ技術：フルスピード統合

    このリリースにおける顕著な進歩は、Windows Server Core 2022 を基盤とした Windows ネイティブ コンテナの一般提供開始 です。この追加により、Windows ユーザーは以下の利点を得られます：

    • 仮想化のオーバーヘッドなしでのネイティブ コンテナ実行
    • 従来のコンテナ実装と比較したパフォーマンス向上
    • Windows Server 環境との互換性
    • オペレーティングシステムを横断した一貫したデプロイ体験

    この開発により、Windows インフラストラクチャを持つ組織は、既存の環境で Gluesync をより効率的に実行できるようになります。

    パフォーマンスの改善

    このリリースには、システム全体のパフォーマンスを向上させるために設計された、いくつかのコアエンジンの最適化が含まれています。

    • スレッド管理の改善
    • より効率的なリソース利用
    • 内部処理の合理化

    これらの技術的な改良により、オペレーティングシステムや統合タイプに関係なく、すべてのデプロイメントシナリオでパフォーマンスが向上します。

    Chronosスケジューラの Windowsサポート

    ChronosスケジューラモジュールはWindowsネイティブビルドをサポートし、スケジュールされた操作においてWindowsとLinuxデプロイメント間の機能の均一性を確保します。

    Windowsコンテナ実装

    WindowsネイティブコンテナでGluesyncを実装するチーム向けに、詳細なインストール手順をWindowsコンテナ設定ガイドで提供しています。このドキュメントでは以下の全プロセスを解説します：

    1. Windowsコンテナ用Docker Engineのインストール
    2. Docker Composeの設定
    3. サービスの自動起動設定
    4. Windowsネイティブコンテナイメージでのデプロイ

    ガイドには、スムーズな実装プロセスを確保するための具体的なPowerShellコマンドと設定手順が含まれています。

    注：Chronos schedulerは、Twitterが開発したオープンソースのジョブスケジューラです。

    主な特徴

    柔軟なスケジューリング: 特定の時間に実行するだけでなく、インターバルベースのジョブや、ファイルシステムの変更をトリガーとするジョブなど、柔軟なスケジューリングオプションを提供します。

    ジョブの実行: Chronosは、定期的に実行されるジョブ（Cronジョブ）や、一度だけ実行されるジョブ、依存関係を持つジョブなど、様々な種類のジョブを定義して実行できます。

    高可用性: Apache Mesosと連携することで、ノード障害が発生してもジョブを再スケジュールし、システムの高可用性を確保します。

    RESTful API: 開発者がプログラムでジョブを管理できるように、RESTful APIを提供しています。これにより、自動化されたジョブ管理が可能になります。

    分散処理のサポート: ジョブを複数のノードに分散させて並行処理を行うことができ、大規模な計算タスクに適しています。

    タグ:

    Gluesync 2.1.3 リリース：IBM Db2サポート、Azure Data Lake 統合、グループスケジューリング機能を追加

    投稿日: 2025年9月18日 作成者: climb
    GlueSync MOLO17

    Gluesync 2.1.3の新機能

    IBM Db2 LUWサポート：エンタープライズデータベース統合

    更新されたIBM Db2 LUWトリガーベースエージェントはGluesync 2を完全にサポートし、企業に以下の機能を提供します：

    • IBM Db2 LUWとその他のサポート対象プラットフォーム間のデータ同期
    • 効率的なトリガーベースのアプローチによるDb2データベースからの変更の取得
    • 複数ソースからのデータ統合先としてDb2 LUWを指定可能。

    本機能追加によりGluesyncのエンタープライズデータベース対応範囲が拡大。メインフレームやミッドレンジシステムを利用する組織に対し、現代的なデータ統合のための信頼性の高い経路を提供します。

    Azure Data Lake Storage Gen2コネクタ

    新登場のAzure Data Lake Storage Gen2エージェント（ターゲット専用）により、組織は以下のことが可能になります：

    • リアルタイムのデータ変更をAzure Data Lake Storageへ直接ストリーミング；
    • 継続的に更新されるデータを用いたスケーラブルなデータレイクアーキテクチャの構築；
    • ビッグデータ分析と機械学習ワークフローのサポート。

    このコネクタは運用システムとクラウドベースの分析プラットフォームを連携させ、企業データからのタイムリーなインサイト獲得を可能にします。

    強化されたグループスケジューリング

    Gluesync 2.1.3はグループベースのタスクスケジューリング機能により運用効率を向上：

    • 個々のエンティティ設定ではなくグループ単位でのタスクスケジューリング
    • 関連データエンティティ全体への一貫したスケジューリングポリシー適用
    • 複雑なデータ環境における管理オーバーヘッドの削減

    条件付きスナップショット前削除

    新機能「スナップショット実行前の条件付き削除」により、対象データに対する前例のない制御を実現：

    • スナップショット実行前にカスタムフィルター条件を定義し対象データを選択的に削除；
    • 同期中に複雑なデータ保持ポリシーを実装；
    • 増分データ更新シナリオをより高精度でサポート。

    エンタープライズ対応データ統合プラットフォーム

    Gluesync 2.1.3は、エンタープライズデータ統合技術における新たな重要な進歩です。接続オプションの拡充と運用効率の向上により、本リリースは組織が複雑なデータ環境をより柔軟かつ制御性高く管理することを支援します。

    IBM Db2 LUWサポートの導入は重要なエンタープライズ統合ニーズに対応し、Azure Data Lake Storageコネクタはクラウドベース分析への道筋を提供します。強化されたグループスケジューリングと条件付きデータ制御と組み合わせることで、Gluesyncは要求の厳しいデータ統合課題に対する包括的ソリューションとして進化を続けています。

    追伸：Gluesync 2.1.4について：

    Gluesync2.1.4ではMicrosoft Windowsオペレーティングシステム専用のGluesyncイメージをリリースしました。これにより、企業はWSL（Windows Subsystem for Linux）の使用が不要となり、Windows環境でのGluesyncインストールが大幅に簡素化されます。LinuxシステムへのGluesyncインストールを希望されないお客様向けの優れた解決策が実現しました。

    タグ: , , , , , , ,