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インストールを希望されないお客様向けの優れた解決策が実現しました。

タグ: , , , , , , ,

データベースが抱える最近の4つの課題とその解決方法

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

今日の急速に変化するデジタル環境において、データベース管理者はかつてないレベルの複雑さに直面しています。最も差し迫った4つのデータベース課題に焦点を当て、堅牢なデータベース可視・観測性が運用をどのように変革できるかを探りましょう。

マルチデータベース環境の複雑性

現代の企業は、それぞれ固有の特性と要件を持つ様々なデータベースを管理することが多いです。MySQLやPostgreSQLのようなリレーショナルデータベースから、MongoDBやCassandraなどのNoSQLデータベースまで、その多様性は圧倒的です。さらに問題が複雑化するのは、これらのデータベースがオンプレミスとクラウドプラットフォームに分散している場合です。各プラットフォームには、しばしば異なる時代に開発されたツールや監視ソリューションが存在します。このような多様なエコシステムを管理する運用上の負担は甚大です。データベース管理者やITチームは複数の監視ツールを使い分けなければならず、各ツールはシステム全体の断片的なビューしか提供せず、完全な可視化と制御が得られません。

マルチデータベース環境では、1つのデータベースにおける単一障害点がシステム全体に連鎖的な影響を及ぼす可能性があります。これはパフォーマンスと信頼性に影響を及ぼします。こうした課題に対処するため、組織はデータベース可観測性ソリューションへの移行を加速させています。これらのツールは全データベースの包括的な可視化を提供し、チームは一元的に監視・管理が可能になります。オンプレミスとクラウド環境の両方と連携することで、可視・観測性ソリューションは最適なデータベースパフォーマンスを維持するために必要な包括的な可視化を実現します。運用負担とSLA未達の削減、問題の迅速な診断・解決が実現します。

データベース低速化問題の診断

データベースが極端に遅くなった場合、診断には長い時間がかかることがあります。1秒たりとも無駄にできません。データベースチームにとっての課題は、問題の特定とその正確な原因の究明にあります。複雑な現代のマルチデータベース環境はこの問題をさらに悪化させます。パフォーマンスのボトルネックは、非効率なクエリからネットワーク遅延まで、多くの要因から発生する可能性があります。データベース低速化診断における主要な障壁の一つは、ITエコシステム全体に対する可視化の欠如です。 ここでフルスタック可観測性がDBAにとっての単一の情報源として機能します。統合されたITビューは複数のソースからのデータを統合し、従来の監視を超越します。データベース可観測性は、データベースと他のシステムコンポーネントとの相互作用に関する深い洞察を提供します。データベーステレメトリの相関分析により、チームは遅延の根本原因を迅速に特定し修正できます。また、診断時間の短縮はパフォーマンス向上、SLA達成、顧客満足度の向上につながります。

遅延した問題解決によるSLA未達

この複雑性は問題のバックログを招き、各問題の診断・解決に要する時間が長期化。最終的にSLA未達につながります。問題解決の遅延が引き起こす波及効果は、SLA未達、顧客信頼の喪失、運用上の健全性の損なわれを招きます。タイムリーに解決されない問題は広範な影響を及ぼします。顧客は一貫したパフォーマンスと信頼性を期待しており、サービスの遅れはブランド信頼を損ないます。これは金融、医療、eコマースなど、SLAがサービス契約の基盤となる業界では特に重要です。具体的な解決策は以下の通りです：

  • 定型監視とアラートを自動化し時間を確保
  • AI搭載データベース分析による異常検知
  • 定期的なパフォーマンスレビューとキャパシティプランニングによる潜在的なボトルネックの特定

データベースのパフォーマンスに焦点を当て、チームが着実に向上できる戦略を採用することが不可欠です。これは修正を急ぐことではなく、緊急性と徹底性を両立させる体系的なアプローチを採用することを意味します。

過重労働のチーム

データベース管理の絶え間ない要求に対応しきれず、過重労働に苦しむチームは燃え尽き症候群に陥る可能性があります。問題を迅速に解決しデータベースのパフォーマンスを維持するという絶え間ないプレッシャーは、長時間労働、高いストレス、士気の著しい低下につながります。マルチデータベース環境では、各システムが固有の課題とパフォーマンス指標を持つため、DBAが複数のシステムを同時に管理する必要があり、複雑さが増します。データベース可観測性は、この負担を軽減する最も効果的な方法の一つであり、チームが以下を実現することを可能にします：

  • アラートをキャッチして重大な問題や時間外対応を回避
  • データベース運用に関するリアルタイムの洞察を得る（高度な監視ツールを使用）
  • SLA違反を防止し戦略的業務に集中

Database Performance Analyzerは包括的なデータベースの可視化を提供し、診断プロセスを効率化します。ログを精査したり手動で問題を追跡したりする代わりに、DBAは自動アラートと詳細レポートを活用してパフォーマンスボトルネックの根本原因を特定できます。この効率化によりデータベース性能が向上し、チームの健全なワークライフバランス維持に貢献します。

 

タグ: , , , , ,

DBaaSとは何か

投稿日: 2025年8月12日 作成者: climb
Syniti (旧DBMoto) データベース

DBaaSの仕組み、利点、課題、ユースケースや考慮事項を簡潔に網羅したDBaaSまるわかりガイド

すべての業界のありとあらゆるシステムは、結局データベースが基本です。金融機関も医療機関も小売業界でも、およそシステムと名がつくものは結局、データをどのように処理して保存し、保存したデータをどのように取り出して表示するかをユーザー向けにいろいろと工夫したものを指します。極端な話、ユーザーがデータベースを直接使いこなせてデータを処理できるのなら、システムはデータベースそのものでもかまいません。

データベースとは、そのくらい、すべての企業にとって重要なものであり、企業はデータベースの設定、保全、管理に相当なコストと時間とリソースをかけています。

このコストと時間とリソースを軽減するために考え出されたのが、Database as a Service（DBaaS）です。

DBaaSとは？

Database as a Service（DBaaS）とは、ユーザーが独自のハードウェアを構築、設定、管理することなく、クラウド上でデータベースを使用できるようにする、マネージド クラウド サービスです。DBaaSでは、デプロイメントとコンフィギュレーション、その後の管理、保全、スケーリングなどの諸々の作業をユーザーが行う必要はなく、すべてサービスプロバイダが対応します。

DBaaSの使用例

DBaaSには、以下のような使用方法が考えられます。

1. アプリケーション開発／テスト ― DBaaSを利用することで、開発者はデータベースを迅速にプロビジョニングでき、デプロイメントと設定の手間と時間を節約できます。この用途では、たとえば、MongoDB Atlas、Google Cloud SQL、 PlanetScaleなどの利用が適しています。

2. 在庫管理 ― 簡単にスケーリングできるDBaaSの柔軟性は、ボリュームの変化が激しい在庫管理システムに有効です。この用途では、たとえば、Amazon RDS、Azure SQL、CockroachDB Cloudなどの利用が適しています。

3. 物流管理 ― 配送パッケージや車輛の配車状況をリアルタイムで追跡するシステムの利便性は、データベースのレスポンスに大きく左右されます。DBaaSでは、大量データの入出力を低レイテンシで行えるので、レスポンスの迅速さが求められるシステムに適しています。たとえば、Amazon DynamoDB、Redis Enterprise Cloudなどを活用すると効果的です。

4. IoT ― 柔軟なスケーリングによる大量データへの対応は、IoTにも理想的です。IoTの管理システムでは、数百万のデバイスからデータストリームを収集し続け、トラッキングすることが求められます。このような用途では、InfluxDB Cloud、Timescale、Firestoreなどを利用できます。

DBaaSの仕組み

DBaaSのデータベースは、プロバイダが管理するクラウド インフラストラクチャ上で実行されます。ユーザーはウェブUIかAPIでデータベースにアクセスできます。アップデート、バックアップ、モニタリング、パフォーマンスの最適化などの管理・保守作業はプロバイダが行います。

DBaaSのカテゴリー

DBaaSのサービスプロバイダは、主に次の2種類に分けられます。

パブリッククラウド プロバイダ

AWS（Amazon RDS、DynamoDB、Aurora）、Google Cloud（Cloud SQL、Firestore）、Microsoft Azure（SQL Datastore、Cosmos DB）などのクラウドベンダーが、そのエコシステム内で直接DBaaSを提供しています。このようなパブリッククラウド サービスをすでに使用しているユーザーにとっては、DBaaSも同サービス内のものを使用するのが便利で理にかなっています。

プロプライエタリ クラウドベンダー

一方、MongoDB Atlas、Snowflake、PlanetScale、Neon、Fireboltなどは、独自のクラウド プラットフォームを提供しています。ユーザーは、データベースの使用量とその基盤となるクラウドサービスの料金を払うことになります。つまり、データベースとインフラストラクチャはベンダーによって提供されますが、実際のサーバーとストレージはパブリッククラウドによってホストされています。

では、この2種類のDBaaS、それぞれのメリットとデメリットを比べてみましょう。

パブリッククラウド プロバイダプロプライエタリ クラウドベンダー
利点既存のクラウドアカウントによる統一されたデプロイメントと支払い単一ベンダーを通じて一貫したデプロイメントと支払い
クラウドプロバイダの選択肢が豊富クラウドプロバイダの選択肢が豊富
採用したパブリッククラウドで提供される他のサービスも統合環境で利用可能アナリティクス用または特定ユースケース向けに最適化されていることが多い
欠点ベンダーロックイン（特定ベンダーに縛られる）ベンダーロックイン
単一クラウド環境に依存サーバーの費用はベンダーとプロバイダ間の取り決め次第（ユーザには多少高くつく可能性も）
ワークロードをハイブリッド／マルチクラウド環境で移行できない（できても簡単ではない）アプリケーションがクラウド限定の可能性

DBaaSを利用するメリット

パブリッククラウド プロバイダを使用するにせよ、プロプライエタリ クラウドベンダーを使用するにせよ、オンプレミスのサーバーでデータベースをホストせずにDBaaSを利用することには、さまざまな利点が期待できます。一般的な利点については冒頭でふれたので、ここでは、より具体的なメリットをいくつか紹介します。

● 総所有コスト（TCO）の削減 ― DBaaSを使用することで、オンプレミスで必要となるはずのハードウェアとソフトウェアへの初期投資が節約でき、大幅なコスト削減となります。DBaaSの費用はサブスクリプション ベースなので、運営コストとして計上でき、データベース管理に専任チームを置かなくて済むので、人件費も節約されます。

● 柔軟なスケーリング ― DBaaSでは、インフラストラクチャをその時その時のビジネスニーズに合わせて簡単にスケールアップ／スケールダウンできます。データベースの許容量が現行のビジネスニーズに常に合致した状態に保ち、最高レベルのコスト効率を維持できる可能性があります。

● 高可用性（HA）― DBaaSを提供するクラウドプロバイダのサービスには通常、高可用性が含まれているので、データベースはいつでも利用でき、緊急時でもダウンタイムが最小限に抑えられます。

● セキュリティの強化 ― DBaaSのプロバイダは概してセキュリティに力を入れており、保存データも移行中のデータも確実に保護する仕組みが整っています。また、プロバイダは業界の規制にも敏感なので、DBaaSを使用することで自社のコンプライアンス要件も満たしやすくなります。

● データベース管理の簡素化 ― DBaaSでは、クラウドプロバイダがアップデート、バックアップ、セキュリティパッチなどのメンテナンス作業を行うので、社内のITチームはよりビジネスニーズに即した重要な業務に集中できます。これは、データベース管理のオーバーヘッドを削減できるだけでなく、常に最新バージョンで運用できるなど、セキュリティ上も大きな利点となります。

● 迅速なプロビジョニング ― DBaaSでは、プロビジョニングとコンフィギュレーションが迅速化されるので、アプリケーションの開発者はすぐに開発プロセスに取り掛かることができます。つまり、アプリケーションのスピーディーな実用化によってビジネスニーズへのリアルタイムな対応が可能になります。

DBaaSの課題

このように、DBaaSの活用は企業に数々の効果をもたらしますが、良いことづくめというわけではありません。DBaaSを導入する前に潜在的な問題をあらかじめ検証できるよう、以下にDBaaSの課題または想定される問題点を挙げておきます。

● 透明性の欠如 ― オンプレミスでデータベースを導入するのと比べ、初期投資が圧倒的に低く抑えられますが、料金体系の透明性は完全ではありません。他のクラウドサービス同様に隠れたコストがあり、特にそれがワークロード関連で発生する場合が多く、思わぬ費用の増加につながる可能性もあります。

● 管理範囲の制限 ― マネージドサービスにおいては、自社ITスタッフがすべての機能に自由にアクセスできるわけではありません。基盤となるサーバー機能の一部はプロバイダによって抽象化されており、ユーザーはプロバイダのインフラストラクチャ管理に依存することになります。

● ネットワークへの依存 ― DBaaSの利点である大量データの処理能力や低レイテンシは、ネットワーク パフォーマンスに依存します。ユーザーのインターネットアクセスに不具合が生じたり、停電発生時などには、DBaaSのせっかくの利点も発揮できなくなります。

● セキュリティ上の懸念 ― 一般的にパブリッククラウド プロバイダのセキュリティはとても強固ですが、プラットフォームやインフラストラクチャのセキュリティを自分で直接管理せずにセキュリティをベンダーに依存することの不安は否定できません。

DBaaSに何を求めるのか

DBaaSプロバイダを選択するとき、DBaaSに何を求めるのかをあらかじめ明確にすることが重要です。費用の詳細を明確にするのはその一例ですが、費用以外にも以下の点を事前に検討する必要があります。

DBaaSデプロイメントの選択肢と制約

DBaaSプロバイダのサービスには、ストレージを単一のクラウド内に限定しているものもあります。これは、クラウド間の移行を制限し、コスト効率の高いクラウドオプションの選択を難しくします。また、オンプレミスのアナリティクスやKubernetes環境へのデプロイメントをサポートしていないDBaaSもあります。ベンダーを選択する際には、制限事項をよく確認し、要件に合ったものを慎重に選択する必要があります。

ライセンスの柔軟性

データベース ソリューションのライセンスが、マルチクラウドやオンプレミスの移行をサポートしているかどうかは重要です。開発、テスト、バックアップ、本番環境など、異なる環境でどのような費用が発生するのか、隠れた費用はないかなども事前に確認しておく必要があります。

キャンセルの容易さ

サービスプロバイダの選択が最適解となるのが理想的ですが、途中で変更しなければならない可能性もゼロではありません。ベンダーロックインのリスクを軽減するためにも、たとえば、APIやデータベース エンジン、自動化ツールなどがベンダー独自の知的所有権に属するのか、業界の標準ツールなのかは確認しておく必要があります。他のサービスに移行する際に、プログラミング修正が必要になったり、キャンセル料が発生したりしないか、データの移行は容易か、などの確認も重要です。

最適化の可能性

DBaaSのよっては、運用されるコンピューティング パッケージが制限され、データベース ワークロードに別個に対処しているサービスもあります。ノードベースのスケーリング（一般ノードを需要の増加に合わせて追加していく形態）に依存しているデータベース ソリューションは、将来的にコストとパフォーマンスの最適化を制限する可能性があります。データベースに特化されたノードのサポート、時間のかかるクエリのファインチューニングなどのサポートを確認することは、コスト効率の観点からも、とても重要になります。

アナリティクスの深度

基本的なアナリティクスに加え、時系列に沿った分析や地域別の分析をサポートしているDBaaSが便利です。ビジネスニーズによっては、予測モデルにもとづくアナリティクスをサポートしていることも必要になってくるかもしれません。組織の将来的なニーズの拡大に備え、幅広いユースケースに対応可能なアナリティクス サポートを視野に入れておく必要があります。

最適なDBaaSソリューションの選択方法

データベース管理を強化しながら、拡張性、信頼性、高パフォーマンスを確保するには、適正なDBaaSソリューションを選択することが不可欠です。最適な選択を決定するには、データベースのタイプ、スケーラビリティ、セキュリティ、パフォーマンス、ベンダーサポートなどの主な決定要因を慎重に評価していく必要があります。

以下、DBaaSを選択するうえで考慮すべき点を順に見ていきます。

1. 要件を定義する ― まず、処理するデータ量を見積もり、パフォーマンス要件、データベース要件を把握する必要があります。このような基本的な要因によっても、対応可能なDBaaSはある程度絞られます。

2. サービス内容を評価する ― 使用できるデータベースのタイプ（リレーショナル データベース、NoSQLなど）を特定し、スケーリング、バックアップの手順や利用できるセキュリティ機能を確認します。データベースは、技術要件を満たすものを選択しなければなりません。

3. パフォーマンスと高可用性 ― DBaaSプロバイダがインフラストラクチャの安定性、高可用性をどのくらい保証するのかを確認します。パフォーマンスの履歴を調べて、なるべくダウンタイム歴の少ないサービスを選ぶのが得策です。

4. セキュリティとコンプライアンス ― データの暗号化、アクセス制御など、重要なセキュリティ機能を提供するかどうかを確認します。業界で必要とされる一般的な規制への対応もあらかじめ確認しておく必要があります。

5. サポートとSLA ― サポートサービス内容、サービスレベルアグリーメント（SLA）を把握し、問題発生時の対応やタイムフレームがビジネスニーズに合っているかどうかを確認します。

6. 顧客フィードバック ― DBaaSプロバイダに対する顧客の口コミ評価やフィードバックも参考になります。

ユースケースごとの最適DBaaSソリューション

ユースケース 推奨DBaaS 
一般的な用途でのSQL利用 Amazon RDS、Google Cloud SQL
大規模なPostgreSQL Neon、Timescale、CockroachDB Cloud
MySQLでのブランチ多用／開発特化PlanetScale
ドキュメントベースのNoSQL MongoDB Atlas、Firestore
リアルタイム アナリティクスSingleStore、ClickHouse Cloud
時系列データ処理InfluxDB Cloud、Timescale
IoT、ストリーム処理Redis Enterprise Cloud、DynamoDB
モバイルアプリ／ウェブアプリ（BaaS） Firebase（NoSQL）、Supabase （PostgreSQL)

DBaaSとPaaSの違い

DBaaSとPaaSは、どちらもクラウドコンピューティングを簡素化するためのプラットフォームですが、サービスの目的が異なります。PaaS（Platform as a Service）はインフラストラクチャ プラットフォームそのものを提供し、ユーザーはそこでデータベースだけでなく、さまざまなアプリケーションを実行できます。PaaSでは、ユーザーがすぐに使えるデータベースは提供されないので、データベースのデプロイメント、コンフィギュレーション、メンテナンスはユーザーの責任で行います。その代わり、PaaSのほうがDBaaSより安価で、用途に柔軟性があります。

DBaaSとDBMSの違い

DBaaSは基本的にクラウドサービスですが、DBMS（データベース管理システム）はローカルサーバーやシステムにインストールして使用するソフトウェアです。したがって、DBaaSと異なり、DBMSのデータベース管理、メンテナンス、スケーリング、さらには、それを実行させるインフラストラクチャも、すべて社内ITチームの責任となります。そのぶん、データベースのカスタマイズやインフラストラクチャの選択などが柔軟にでき、よりニーズに沿った自由な管理が可能になります。

まとめ

DBaaSは、データベースのデプロイメント、コンフィギュレーション、メンテナンスをすべてサービスプロバイダに任せ、高可用性に優れたクラウドでデータベースを迅速かつ柔軟に実用化できるサービスです。オンプレミスでデータベースを管理する複雑さを回避し、物理的／人的リソースを節約したい、中小規模のITチームには特に適したサービスと言えます。

しかし、DBaaSソリューションも多種多様であり、導入時には、パフォーマンス、セキュリティ、サポート内容を吟味し、ビジネスニーズに最適なサービスを慎重に選択する必要があります。特に、費用面の詳細は事前によく確認し、また将来のビジネスの成長をサポートするスケーラビリティとコスト効率も重視すべきです。

DBaaSは、賢い選択さえすれば、企業がオーバーヘッドを最小限に抑えながら、最新のデータベース機能を柔軟に活用できる最適ソリューション モデルです。

タグ:

データウェアハウスとは何なのか？

投稿日: 2025年8月5日 作成者: climb
データベース

データウェアハウス導入の手引き

ビジネスを運営すれば、日々データが増え続けます。業種や事業規模によっては、天文学的に増える可能性だってあります。昨今では、データをきちんと整理し、しっかり管理して、その状況を十分に把握しておくことが、健全なビジネス運営に欠かせない条件となっています。そして、その実現に必要となるのが、データウェアハウスです。

本稿では、そもそもデータウェアハウスとは何なのか、どのように機能するのか、を説明し、それをサポートするアーキテクチャモデルについて、さらに実用上の利点と課題についても紹介していきます。

データウェアハウスとは何なのか？

データウェアハウス（Data Warehouse）とは、さまざまな媒体から集められる多種多様なデータを単一の組織化されたデータベースにまとめ、ビジネス上の意思決定をデータ主導で行えるように整理するためのシステムです。これは、特にビジネスインテリジェンス（BI）において威力を発揮します。BIは、履歴データと現行データの両方への迅速かつ構造化されたアクセスを必要とするので、データウェアハウスの質がBIの意思決定効果を大きく左右します。

データウェアハウスを構築するには、通常、以下の2つのアプローチがとられます。

トップダウン ― データウェアハウスの全体的な設計から始めて、部門ごとのニーズに合わせたデータマートの構築へと細分化していくアプローチです。

ボトムアップ ― まず部門に特化したデータマートを作成し、それらを統合して、より大規模なデータウェアハウスを構成していくアプローチです。

企業がデータウェアハウス構築時にどちらのアプローチを取るかは、ビジネスのニーズ、利用可能なリソース、プロジェクトのスコープなど、さまざまな要因によって決まります。

データウェアハウスを構成する要素

データウェアハウスは、主に4つのレイヤーから成り、それぞれのレイヤーがデータ処理パイプラインを構成するうえで重要な独自の役割を担っています。

データソースレイヤー

データソースレイヤーは、とれたての生の情報が集められた、データウェアハウスの基盤となるレイヤーです。これは、ビジネスの目的に応じ、従来型のシステム向けにはリレーショナル データベースのような構造化されたデータ群であったり、より最新型のシステム向けには、JSONファイルのような半構造化データや、画像、音声、センサーデータなどの非構造化データであったりします。

データステージングレイヤー

データステージングレイヤーは、ソースシステムから収集された生データの一時的な格納庫の役割を果たします。この段階では、データはまだ検証も標準化もされてなく、クリーンな状態ではありません。ステージングレイヤーが、生データをより精製されたデータレイヤーに移行する前のバッファーとなり、重複排除、フォーマット化、エラーの修正などを行える場を提供します。

データストレージ（ウェアハウス）レイヤー

データウェアハウスの中核となるレイヤーで、構造化され、統合されたフォーマットのデータが永続的に保存されます。前段階のステージングレイヤーで処理されたデータがここで整理整頓され、長期的な使用目的で格納されます。時系列に則ったデータの一貫性がここで確立され、いつでも分析可能な状態となります。

データアナリティクス（プレゼンテーション）レイヤー

構造化されたデータをユーザーが分析やレポートに利用できるようにする最終段階のレイヤーです。ダッシュボードやレポーティングツール、その他のユーザーインターフェースとここで統合され、ビジネスユーザーがストレージシステムを直接処理しなくてもデータを可視化して理解できる場を提供します。

データウェアハウス アーキテクチャの種類

データウェアハウスのアーキテクチャには単純なものから複雑なものまでいろいろあり、組織の規模、ビジネス目標、技術的ニーズなどに応じて、多種多様なアプローチでアーキテクチャが実装されます。ここでは、もっとも一般的なアーキテクチャ モデルを紹介します。

単一ティア アーキテクチャ

複数のレイヤーが論理的に（多くのケースでは物理的にも）単一のティアに統合され、実装されます。データの冗長性を排除できる利点がある反面、さほど高度な拡張性と柔軟性は期待できず、パフォーマンスのボトルネックを生じさせるリスクがあります。

2ティア アーキテクチャ

データソース／データステージング レイヤーとデータウェアハウス／プレゼンテーション レイヤーを論理的にも物理的にも切り離して実装するアーキテクチャです。中小規模のビジネスに広く採用されており、データとストレージの管理力により優れています。スケーラビリティと大規模データの処理面では多少の制約がともないます。

3ティア アーキテクチャ

データソース、ステージング、ストレージ、プレゼンテーションのすべての主要レイヤーを物理的、論理的に区別して実装する、もっとも一般的で安定したアプローチです。レイヤーを切り離すことで、拡張性、柔軟性、パフォーマンスのすべてを高次元で実現することができます。

最新のデータウェアハウス アーキテクチャ事情

最新のデータウェアハウスは、近年のITトレンドを敏感に取り入れたものが主流で、一般的に以下の特長を備えています。

クラウドネイティブ アーキテクチャ ― オンプレミスの制約を取り払い、簡易スケーリング、あるいはスケーリング オンデマンドを可能にします。料金は使用分だけを払うことができるので、初期投資を大幅削減できる「サーバレス」アーキテクチャとしての利点があります。また、すべてのデータをAWS S3やAzure Blobなどのストレージを使用する「データレイク」に保管できる点でも、コスト効率に長けています。

リアルタイム プロセシング ― 最新のデータウェアハウス アーキテクチャはContinuous Data Ingestion（継続的なデータ取り込み）を可能にすることで、オンデマンドの即時分析を実現しています。

AIとMLの統合 ― 大規模言語（LLM）モデルとの統合が進み、アナリティクスが機能的にも速度的にも強化され、より的確なビジネスの意思決定が可能になっています。

典型的なアーキテクチャには、データソース、ステージング、ストレージ、プレゼンテーションのレイヤーが含まれますが、設定方法によっては、レイヤーを部分的に組み合わせたり、逆に複数システムに分散させたりするバリエーションがあります。

的確なデータウェアハウス アーキテクチャ設計がもたらす効果

データウェアハウスを正しく設計、構造化することで、企業は確かなデータにもとづく迅速かつ的確な意思決定が可能になり、そのビジネス効果は計り知れません。データウェアハウスは、企業にとって、ビジネス戦略上の重要な資産となるものです。適正に設計されたデータウェアハウスには、以下の効果が期待できます。

パフォーマンスの改善 ― 必要なデータを必要な形で迅速に引き出せるので、レポーティングとアナリティクスの即応性と正確性が向上します。

データ品質の向上 ― データの質が上がれば、それにもとづいて動くビジネスの質も上がります。

スケーラビリティ ― データウェアハウスが正しく設計されていれば、将来のスケーリングが保証され、ビジネスの成長をサポートできます。

最新アナリティクスの統合 ― LLMモデルを活用した最新のデータアナリティクスで、ビジネスの意思決定がいっそう研ぎ澄まされます。

課題および検討事項

データウェアハウスの導入は、企業にとって非常に大きな一歩となります。そこから得られる効果も絶大であると同時に、思わぬ壁に直面する可能性もあり、入念な計画が求められます。実装方法によって直面しうる課題は異なりますが、すべての実装方法に共通した典型的な課題もあり、あらかじめ検証しておく必要があります。たとえば、以下の課題が挙げられます。

データ統合の複雑化 ― システムが拡大していくにつれ、新しいデータタイプやデータソースが追加されることは珍しくなく、データウェアハウスには継続的な調整が必要になります。明確な統合戦略をあらかじめ策定しておかないと、データのサイロ化やミスマッチが生じ、問題が複雑化は避けられません。

データ品質 ― データは人的な入力ミスであったり、部門ごとの定義の不統一であったり、旧式システムの併用などによって、簡単に品質が損なわれてしまいます。データの品質を保つには、データがシステムに入る段階でクリーニングや整合性の検証などを確実に実施する強力なガバナンスが求められます。

スケーラビリティとパフォーマンス ― データウェアハウスの設計に不備があると、パフォーマンスのボトルネックとなり、スケーラビリティを阻害して将来の成長の足かせになりかねません。適切な最適化が行われないと、データクエリの速度が低下し、ストレージ費用が増し、システムの反応も劣化します。データウェアハウスの導入時には、準備段階から将来を見据えた戦略的な設計が必要になります。

ビジネスの変化への適応 ― ビジネスが進化するとデータ要件も変わってきます。事業の合併や新製品の導入、レポーティング ニーズや顧客動向の変化など、データ要件に影響しうる要因は多く、すべての企業にとって、将来的にデータウェアハウスの調整が必要になるリスクは低くありません。

適正なアーキテクチャ設計とは

では、データウェアハウスのアーキテクチャを的確に設計するにはどうすればよいでしょうか。ここでは、設計段階で検討しておくべき重要事項を5つ紹介します。

1. ビジネス目標を明確に定義する ― データウェアハウスに何を求めているのか、データウェアハウスでどのような問題を解決したいのかを、あらかじめ明確にする必要があります。まず、自社のデータを十分に理解し、それがビジネスインテリジェンスにどのように活用できるのかを整理することが先決です。

2. データを監査する ― データソース、フォーマット、ボリュームについて詳細を記録し、データをいつでも監査できるように目録を準備しておく必要があります。データは企業にとって重要な資産であり、財産目録が必要になるのは当然と言えます。

3. デプロイメント モデルを選択する ― 利用可能なツールやプラットフォームを調べ、オンプレミス環境に実装するのか、完全にクラウド化するのか、両方にまたがるハイブリッド アプローチを採用すのかを決定します。

4. スケーラビリティを考慮する ― 潜在的なボトルネックを特定し、克服方法を事前に確認しておく必要があります。

5. 安定した自動プロセスを設計する ― 自動化された信頼できるExtract（抽出）、Transform（変換）、Load（ロード）またはExtract、Load、Transform（つまりETLまたはELT）パイプラインを設計することが、データを常に利用可能な状態に保つためには不可欠です。

代表的なデータウェアハウス ソリューション

Amazon Redshift ― すでにAWSを活用している企業にとっては有効な選択肢となります。

Google BigQuery ― 大規模なアナリティクス ワークロードに適しています。

Snowflake ― パフォーマンスとマルチクラウド サポートで高い評価を得ています。

Databricks  ― ML／AIワークロードと非構造化データの処理に強いという評価が定着しています。

Azure Synapse Analytics ― すでにSQLとSparkを活用しているユーザーに適しています。

まとめ

最新のデータウェアハウスは、単なる情報リポジトリにとどまらず、データドリブンが求められる現代のビジネス環境で企業戦略を支える重要なアセットとなるものです。正しく準備され、考え抜かれたアーキテクチャ設計が、適切なテクノロジーとプラクティスでサポートされれば、データウェアハウスは組織全体に価値をもたらすビジネスの強力な武器になります。逆に言えば、準備が不十分だと、効果を発揮できないリスクがあります。データウェアハウスを導入するからには、ビジネス目標に合致した的確なアーキテクチャを設計し、データ品質を維持し、スケーラブルなソリューションを確立してビジネスへの効果を最大限に高めましょう。

データウェアハウスのためのコスト効率とパフォーマンスに優れたストレージ ソリューションをお探しの場合は、お気軽にクライムにご相談ください。たとえば、StarWind Virtual SAN（VSAN）は、Hyper-V、vSphere、KVMクラスタ向けに高可用性（HA）に優れた共有ストレージを実現します。StarWind VSANでは、ハイパーバイザーホストのローカルストレージを利用して、仮想マシン（VM）向けに共有HAストレージを確保できるので、抜群の費用対効果が期待できます。詳しくは、クライムサポートまで。

 

 

コメントする -->

[Gluesync 2.1.1] Allowed Operation機能によるTruncate操作のサポート対応追加について

投稿日: 2025年7月29日 作成者: climb
GlueSync MOLO17

先日リリースされたGluesync 2.1.1にて、「Allowed Operation」と呼ばれる機能が追加されました。

この新機能は、ソースおよびターゲット間でレプリケーション対象とするデータベース操作を制御することができ、ユーザのニーズに応じたレプリケーションが実現できます。

スナップショット(全件レプリケーション)処理、CDC(差分レプリケーション)処理それぞれ設定箇所や対応が異なるため、それぞれ紹介します。

スナップショットの場合

従来のGluesyncでは、スナップショットモードとしてUpsertモードおよびInsertモードが提供されており、高速に処理できるInsertモードはターゲット側にレコードが存在しないケースで利用する機能となっていました。


このため、予めターゲット側でTruncateを実行するなどしてレコードがクリアされている状態でない場合、重複レコードエラーとなっていましたが、Gluesync 2.1.1では仕様変更があり、Insertモード利用実行時には自動的にターゲット側でTruncateクエリによってレコードをクリアされるようになりました。
これに伴い、Insertモード選択時の文言もアップデートされ、Truncateが実行される記載が追加されています。


ただ複数テーブルを1つのテーブルへ集約する(N対1構成)など、ターゲット側でのTruncateが運用上許可されない特定のケースでは、このTruncateによって必要なレコードが全消去されてしまいます。
この場合は、パイプライン(DB接続設定)の編集画面を開き、ターゲットセットアップの詳細設定 > カスタムプロパティ項目にて、”Disable truncate on target before snapshot inserts“というパラメータをドロップダウンリストから選択し有効化することで、スナップショット実行時にもターゲット側へのTruncateを実行しないように制御可能です。

CDCの場合

Gluesyncでは、ソーステーブルに対して実行された下記操作がターゲットテーブルへCDC(差分レプリケーション)されます。
・Insert
・Update
・Delete
・Truncate

GluesyncのCDCでは、エンティティ(レプリケーションジョブ)単位で許可する操作を制御可能です。
エンティティの編集画面を開き、設定 > オプション設定と調整 > 許可された操作をクリックすることで、CDCでレプリケーションする操作を指定します。

このように、Gluesyncの「Allowed Operation」機能を利用することで、ニーズに応じたレプリケーションを簡単に構成可能です。

タグ: , ,

Gluesyncのバージョンアップ方法

投稿日: 2025年7月25日 作成者: climb
GlueSync MOLO17

Gluesyncのバージョンアップ方法を紹介します。
現在利用中のGluesyncバージョンは、Webコンソール左上より確認可能です。
以下の例では、2.1.0 – build 9が利用されています。

バージョンアップは、Gluesync構成時に実行したdocker composeコマンドより実行します。
まず、現在動作しているGluesyncコンテナをdocker compose downコマンドにて停止します。

[root@asahi-gluesync gluesync-docker]# docker compose down
[+] Running 13/13
 ✔ Container gluesync-docker-gluesync-mssql-ct-target-1       Removed                                                                                                                                     2.2s 
 ✔ Container gluesync-docker-reverse-proxy-1                  Removed                                                                                                                                     8.5s 
 ✔ Container gluesync-docker-gluesync-mssql-ct-target-3-1     Removed                                                                                                                                     2.3s 
 ✔ Container gluesync-docker-gluesync-ibm-iseries-source-3-1  Removed                                                                                                                                     2.3s 
 ✔ Container gluesync-docker-gluesync-ibm-iseries-source-2-1  Removed                                                                                                                                     2.3s 
 ✔ Container gluesync-docker-gluesync-chronos-1               Removed                                                                                                                                     0.7s 
 ✔ Container gluesync-docker-gluesync-ibm-iseries-source-1    Removed                                                                                                                                     2.3s 
 ✔ Container gluesync-docker-grafana-1                        Removed                                                                                                                                     0.3s 
 ✔ Container gluesync-docker-portainer-1                      Removed                                                                                                                                     0.2s 
 ✔ Container gluesync-docker-gluesync-mssql-ct-target-2-1     Removed                                                                                                                                     2.3s 
 ✔ Container gluesync-docker-prometheus-1                     Removed                                                                                                                                     0.2s 
 ✔ Container gluesync-docker-gluesync-core-hub-1              Removed                                                                                                                                     2.1s 
 ✔ Network gluesync-docker_default                            Removed

docker compose pullコマンドを実行し、DockerリポジトリよりGluesyncの最新イメージをPull(ダウンロードします。

[root@asahi-gluesync gluesync-docker]# docker compose pull
[+] Pulling 31/58
 ✔ gluesync-mssql-ct-target-2 Skipped - Image is already being pulled by gluesync-mssql-ct-target                                                                                                         0.0s 
 ✔ gluesync-mssql-ct-target-3 Skipped - Image is already being pulled by gluesync-mssql-ct-target                                                                                                         0.0s 
 ✔ gluesync-ibm-iseries-source-3 Skipped - Image is already being pulled by gluesync-ibm-iseries-source                                                                                                   0.0s 
 ✔ gluesync-ibm-iseries-source-2 Skipped - Image is already being pulled by gluesync-ibm-iseries-source                                                                                                   0.0s 
 ⠋ gluesync-mssql-ct-target [⣤⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀] Pulling                                                                                                                                                        12.1s 
 ✔ reverse-proxy Pulled                                                                                                                                                                                   1.7s 
 ✔ prometheus Pulled                                                                                                                                                                                      1.8s 
 ⠋ grafana [⣿⣿⣿⣿⣿⣿⣤⡀⣿⣿] 91.26MB / 197.6MB Pulling                                                                                                                                                        12.1s 
 ✔ portainer Pulled                                                                                                                                                                                       1.7s 
 ⠋ gluesync-ibm-iseries-source [⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀] Pulling                                                                                                                                                     12.1s 
 ✔ gluesync-chronos Pulled                                                                                                                                                                                1.8s 
 ✔ gluesync-core-hub Pulled

docker compose up -dコマンドを実行し、Gluesyncコンテナを起動します。

[root@asahi-gluesync gluesync-docker]# docker compose up -d
[+] Running 13/13
 ✔ Network gluesync-docker_default                            Created                                                                                                                                     0.1s 
 ✔ Container gluesync-docker-portainer-1                      Started                                                                                                                                     0.9s 
 ✔ Container gluesync-docker-gluesync-core-hub-1              Started                                                                                                                                     0.8s 
 ✔ Container gluesync-docker-reverse-proxy-1                  Started                                                                                                                                     0.8s 
 ✔ Container gluesync-docker-gluesync-mssql-ct-target-2-1     Started                                                                                                                                     0.6s 
 ✔ Container gluesync-docker-gluesync-mssql-ct-target-1       Started                                                                                                                                     0.9s 
 ✔ Container gluesync-docker-prometheus-1                     Started                                                                                                                                     0.7s 
 ✔ Container gluesync-docker-gluesync-chronos-1               Started                                                                                                                                     0.8s 
 ✔ Container gluesync-docker-gluesync-mssql-ct-target-3-1     Started                                                                                                                                     0.7s 
 ✔ Container gluesync-docker-gluesync-ibm-iseries-source-2-1  Started                                                                                                                                     0.8s 
 ✔ Container gluesync-docker-gluesync-ibm-iseries-source-3-1  Started                                                                                                                                     0.7s 
 ✔ Container gluesync-docker-gluesync-ibm-iseries-source-1    Started                                                                                                                                     0.8s 
 ✔ Container gluesync-docker-grafana-1                        Started                                                                                                                                     1.1s 
[root@asahi-gluesync gluesync-docker]#

Gluesync Webコンソールへログインし、画面左上を確認しバージョンアップされていることを確認します。

タグ: , ,

オフライン環境のDockerでGluesyncを実行

投稿日: 2025年7月24日 作成者: climb
GlueSync MOLO17

Gluesyncは評価用に事前構成されたdocker-compose.ymlを提供しています。

そのため、これをDocker composeが使用できる環境に配置してdocker compose up -dを実行すれば下記のように自動的にインターネット上のリポジトリからイメージをpull（ダウンロード）してきます。

しかし、当然ことながらこれはオフライン環境では下記のようにエラーで失敗します。

climb@offlinetest:~/gluesync-docker$ docker compose up -d
[+] Running 7/7
 ! grafana                         Interrupted      0.0s 
 ✘ prometheus Error                Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:40746->[::1]:53: read: connection refused  0.0s 
 ! gluesync-chronos                Interrupted      0.0s 
 ! gluesync-core-hub               Interrupted      0.0s 
 ! reverse-proxy                   Interrupted      0.0s 
 ! gluesync-postgresql-cdc-target  Interrupted      0.0s 
 ! gluesync-ibm-iseries-source     Interrupted      0.0s 
Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:40746->[::1]:53: read: connection refused

このため、オフライン環境で使用する場合、事前にコンテナのイメージを配置しておく必要があります。今回はdocker saveとdocker loadコマンドを使用してこれを実施する方法を紹介します。

オンライン環境でのイメージ取得

オンライン環境のDockerにて評価キットから展開したgluesync-dockerディレクトリへ移動し、docker compose pullを実行し、イメージを取得します。

climb@step:~$ cd gluesync-docker/
climb@step:~/gluesync-docker$ docker compose pull
[+] Pulling 57/57
 ✔ gluesync-ibm-iseries-source Pulled         28.4s 
 ✔ gluesync-chronos Pulled                    31.4s 
 ✔ gluesync-postgresql-cdc-target Pulled      37.1s 
 ✔ prometheus Pulled                           1.9s 
 ✔ grafana Pulled                              1.9s 
 ✔ reverse-proxy Pulled                       22.3s 
 ✔ gluesync-core-hub Pulled                    1.9s

問題なく取得できていればdocker image lsでイメージを確認できます。

climb@step:~/gluesync-docker$ docker image ls
REPOSITORY                       TAG       IMAGE ID       CREATED        SIZE
molo17/gluesync-core-hub         latest    d75160f6137f   31 hours ago   499MB
molo17/gluesync-ibm-iseries      latest    a683d17a7de0   31 hours ago   488MB
molo17/gluesync-postgresql-cdc   latest    60addcb8cba6   31 hours ago   483MB
molo17/gluesync-chronos          latest    cf964252e130   38 hours ago   633MB
grafana/grafana                  latest    75006c93b887   5 days ago     722MB
prom/prometheus                  latest    a3bc50fcb50f   9 days ago     313MB
traefik                          v3.3      ff8877338069   2 months ago   224MB

イメージはdocker saveコマンドで保存できますが、複数あるため、今回は下記のbulksave.shスクリプトでsavesフォルダにまとめて保存するようにします。

#!/bin/sh
set -e
mkdir -p saves
docker images --format "{{.Repository}}:{{.Tag}} {{.Repository}}_{{.Tag}}" | while read image
do
  image_id=`echo $image | cut -d ' ' -f1`
  image_name=`echo $image | cut -d ' ' -f2 | tr -d "/"`

  docker save $image_id > ./saves/${image_name}.tar
done

スクリプトを実行するとsavesフォルダにまとめて保存されています。このスクリプトでは存在しているすべてのイメージを保存しますので、必要に応じてdocker imagesコマンドに–filterオプションを追加し、不要なイメージは除外するように変更してください。

climb@step:~/gluesync-docker$ chmod 755 bulksave.sh 
climb@step:~/gluesync-docker$ ./bulksave.sh
climb@step:~/gluesync-docker$ ls saves
grafanagrafana_latest.tar  molo17gluesync-chronos_latest.tar  molo17gluesync-core-hub_latest.tar  molo17gluesync-ibm-iseries_latest.tar  molo17gluesync-postgresql-cdc_latest.tar  promprometheus_latest.tar  traefik_v3.3.tar

この保存したイメージも含めてオフライン環境にgluesync-dockerディレクトリごとコピーします。

climb@step:~/gluesync-docker$ scp -r ../gluesync-docker climb@192.168.77.77:/home/climb/
climb@192.168.77.77's password: 
core-hub-metrics.json                      100%   38KB  13.2MB/s   00:00
dashboard.yml                              100%  291   383.3KB/s   00:00
datasource.yml                             100%  180   321.3KB/s   00:00
gluesync.com.jks                           100% 3068     3.5MB/s   00:00
gs-license.dat                             100%  868   953.1KB/s   00:00
bootstrap-core-hub.json                    100%   76   111.3KB/s   00:00
prometheus.yml                             100%  401   646.5KB/s   00:00
molo17gluesync-core-hub_latest.tar         100%  481MB 186.1MB/s   00:02
molo17gluesync-postgresql-cdc_latest.tar   100%  466MB 186.4MB/s   00:02
traefik_v3.3.tar                           100%  214MB 149.5MB/s   00:01
promprometheus_latest.tar                  100%  300MB 225.8MB/s   00:01
grafanagrafana_latest.tar                  100%  698MB 176.2MB/s   00:03
molo17gluesync-chronos_latest.tar          100%  617MB 229.2MB/s   00:02
molo17gluesync-ibm-iseries_latest.tar      100%  471MB 155.6MB/s   00:03
certs.yml                                  100%  151    96.1KB/s   00:00
traefik.yml                                100%  342   177.1KB/s   00:00
logback.xml                                100% 1267   757.4KB/s   00:00
gluesync-cert.pem                          100% 1974     1.5MB/s   00:00
grafanagrafana_latest.tar                  100%  698MB 166.9MB/s   00:04
security-config.json                       100%  293   244.0KB/s   00:00
docker-compose.yml                         100% 8878     6.7MB/s   00:00
gluesync-key.pem                           100% 1849     1.2MB/s   00:00
bulksave.sh                                100%  284   483.6KB/s   00:00

オフライン環境でのイメージのロード

コピーしたgluesync-dockerディレクトリに移動します。

climb@step:~/gluesync-docker$ ssh 192.168.77.77
climb@192.168.77.77's password: 
Linux offlinetest 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Jul 24 10:50:55 2025 from 192.168.77.79
climb@offlinetest:~$ cd gluesync-docker/

一つずつ保存したイメージのtarをdocker loadコマンドで読み込むこともできますがここでは下記のスクリプトでまとめて読み込んでします。

climb@offlinetest:~/gluesync-docker$ cat bulkload.sh 
#!/bin/sh
for file in saves/*.tar; do
  docker load -i "$file"
done
climb@offlinetest:~/gluesync-docker$ chmod 755 bulkload.sh 
climb@offlinetest:~/gluesync-docker$ ./bulkload.sh 
08000c18d16d: Loading layer [==================================================>]  8.121MB/8.121MB
a79fd921bc73: Loading layer [==================================================>]   2.56kB/2.56kB
9cc7b6091a3e: Loading layer [==================================================>]   8.67MB/8.67MB
97b6092cb34c: Loading layer [==================================================>]  26.55MB/26.55MB
47ef72cb0b55: Loading layer [==================================================>]  223.2kB/223.2kB
41cfb2f3b7e1: Loading layer [==================================================>]  111.1kB/111.1kB
e1b6356de126: Loading layer [==================================================>]  394.2MB/394.2MB
0e16bb8c20c8: Loading layer [==================================================>]  294.1MB/294.1MB
4d1cec8ac292: Loading layer [==================================================>]  37.89kB/37.89kB
c27dd65cf52a: Loading layer [==================================================>]   5.12kB/5.12kB
Loaded image: grafana/grafana:latest
7cc7fe68eff6: Loading layer [==================================================>]  77.88MB/77.88MB
0a00f6ce5fb7: Loading layer [==================================================>]  9.561MB/9.561MB
943faa7467a0: Loading layer [==================================================>]  47.51MB/47.51MB
d22cc68b10d7: Loading layer [==================================================>]   5.12kB/5.12kB
5a0f38a32659: Loading layer [==================================================>]  1.536kB/1.536kB
07ba18ad0976: Loading layer [==================================================>]  13.83MB/13.83MB
124b774a0b12: Loading layer [==================================================>]  4.096kB/4.096kB
15583e9073b8: Loading layer [==================================================>]  9.728kB/9.728kB
1b460b1eb790: Loading layer [==================================================>]  39.42kB/39.42kB
25873ba4bfe3: Loading layer [==================================================>]  175.6kB/175.6kB
21f0912ce811: Loading layer [==================================================>]   2.56kB/2.56kB
2ffe43ddab52: Loading layer [==================================================>]  4.608kB/4.608kB
18a78bb070bd: Loading layer [==================================================>]  4.096kB/4.096kB
7dba9bb060c8: Loading layer [==================================================>]  19.97kB/19.97kB
a91e752ef628: Loading layer [==================================================>]    255kB/255kB
6b46174d5e90: Loading layer [==================================================>]  9.216kB/9.216kB
f43d597bacf0: Loading layer [==================================================>]  25.09kB/25.09kB
5f70bf18a086: Loading layer [==================================================>]  1.024kB/1.024kB
74877e0efd6a: Loading layer [==================================================>]  57.21MB/57.21MB
189e5c7c2d81: Loading layer [==================================================>]  384.1MB/384.1MB
0e358b9565d7: Loading layer [==================================================>]  69.63kB/69.63kB
46c609cd3326: Loading layer [==================================================>]   56.7MB/56.7MB
Loaded image: molo17/gluesync-chronos:latest
8d853c8add5d: Loading layer [==================================================>]  77.83MB/77.83MB
bec6e6f75d3a: Loading layer [==================================================>]  350.6MB/350.6MB
64833d7e8df2: Loading layer [==================================================>]   20.9MB/20.9MB
6fa85aa38ed6: Loading layer [==================================================>]  489.5kB/489.5kB
5721c53402cb: Loading layer [==================================================>]  6.774MB/6.774MB
14e212539af1: Loading layer [==================================================>]  24.06kB/24.06kB
d71eb2cc9fff: Loading layer [==================================================>]  2.048kB/2.048kB
805690ba64f0: Loading layer [==================================================>]  3.072kB/3.072kB
91fe7aa6c83a: Loading layer [==================================================>]  3.072kB/3.072kB
21556ecc8350: Loading layer [==================================================>]  3.584kB/3.584kB
db18493ecfca: Loading layer [==================================================>]  3.584kB/3.584kB
b0dd230dcb86: Loading layer [==================================================>]  47.64MB/47.64MB
5f70bf18a086: Loading layer [==================================================>]  1.024kB/1.024kB
c82aaef265b1: Loading layer [==================================================>]  3.584kB/3.584kB
Loaded image: molo17/gluesync-core-hub:latest
fb4a92957d0c: Loading layer [==================================================>]   20.9MB/20.9MB
41f27d21f926: Loading layer [==================================================>]  489.5kB/489.5kB
eb69e4939385: Loading layer [==================================================>]  6.774MB/6.774MB
3162aeb41db4: Loading layer [==================================================>]  24.06kB/24.06kB
8bc5a96ce609: Loading layer [==================================================>]  2.048kB/2.048kB
c534fb8b0541: Loading layer [==================================================>]  3.072kB/3.072kB
8d45e791d0a1: Loading layer [==================================================>]  3.072kB/3.072kB
367c68a25e66: Loading layer [==================================================>]  3.584kB/3.584kB
3fcc70161be9: Loading layer [==================================================>]  3.584kB/3.584kB
76a88d2ac879: Loading layer [==================================================>]  36.75MB/36.75MB
5f70bf18a086: Loading layer [==================================================>]  1.024kB/1.024kB
dc765fd0e258: Loading layer [==================================================>]  3.584kB/3.584kB
Loaded image: molo17/gluesync-ibm-iseries:latest
8c10cec765ff: Loading layer [==================================================>]   20.9MB/20.9MB
27e5aab6aead: Loading layer [==================================================>]  489.5kB/489.5kB
8f647a62c02e: Loading layer [==================================================>]  6.774MB/6.774MB
7cb9b54cf4e6: Loading layer [==================================================>]  24.06kB/24.06kB
e1c67e777fed: Loading layer [==================================================>]  2.048kB/2.048kB
6746c71279b3: Loading layer [==================================================>]  3.072kB/3.072kB
835b1bee674f: Loading layer [==================================================>]  3.072kB/3.072kB
76ba3ab2a760: Loading layer [==================================================>]  3.584kB/3.584kB
8b5bb6db1f76: Loading layer [==================================================>]  3.584kB/3.584kB
0addd6c13f8f: Loading layer [==================================================>]   31.8MB/31.8MB
5f70bf18a086: Loading layer [==================================================>]  1.024kB/1.024kB
49ad86643221: Loading layer [==================================================>]  3.584kB/3.584kB
Loaded image: molo17/gluesync-postgresql-cdc:latest
1e604deea57d: Loading layer [==================================================>]  1.458MB/1.458MB
6b83872188a9: Loading layer [==================================================>]  2.455MB/2.455MB
51058541ddde: Loading layer [==================================================>]  159.4MB/159.4MB
aced3db9898b: Loading layer [==================================================>]  150.7MB/150.7MB
735c0da4fd32: Loading layer [==================================================>]  4.096kB/4.096kB
349de0ee3a82: Loading layer [==================================================>]  13.31kB/13.31kB
f19ace59c2b4: Loading layer [==================================================>]  5.632kB/5.632kB
5797eee2097b: Loading layer [==================================================>]  62.46kB/62.46kB
bd712c1df0b0: Loading layer [==================================================>]  1.536kB/1.536kB
83608e9fa217: Loading layer [==================================================>]  5.632kB/5.632kB
Loaded image: prom/prometheus:latest
31b41022049d: Loading layer [==================================================>]  1.688MB/1.688MB
3eae8a7fbd15: Loading layer [==================================================>]  215.1MB/215.1MB
3fc935bcee95: Loading layer [==================================================>]  2.048kB/2.048kB                                                                                                                
climb@offlinetest:~/gluesync-docker$

loadが完了すると下記のようにイメージが読み込まれていることがわかります。

climb@offlinetest:~/gluesync-docker$ docker image ls
REPOSITORY                       TAG       IMAGE ID       CREATED        SIZE
molo17/gluesync-core-hub         latest    d75160f6137f   32 hours ago   499MB
molo17/gluesync-ibm-iseries      latest    a683d17a7de0   32 hours ago   488MB
molo17/gluesync-postgresql-cdc   latest    60addcb8cba6   32 hours ago   483MB
molo17/gluesync-chronos          latest    cf964252e130   39 hours ago   633MB
grafana/grafana                  latest    75006c93b887   5 days ago     722MB
prom/prometheus                  latest    a3bc50fcb50f   9 days ago     313MB
traefik                          v3.3      ff8877338069   2 months ago   224MB

この状態であれば、インターネットから取得しなくとも、これらのイメージがすでに利用できますのでdocker compose up -dでコンテナを起動できます。

climb@offlinetest:~/gluesync-docker$ docker compose up -d
[+] Running 8/8
 ✔ Network gluesync-docker_default                             Created   0.1s 
 ✔ Container gluesync-docker-gluesync-core-hub-1               Started   0.4s 
 ✔ Container gluesync-docker-reverse-proxy-1                   Started   0.5s 
 ✔ Container gluesync-docker-prometheus-1                      Started   0.8s 
 ✔ Container gluesync-docker-gluesync-postgresql-cdc-target-1  Started   0.8s 
 ✔ Container gluesync-docker-gluesync-chronos-1                Started   1.0s 
 ✔ Container gluesync-docker-gluesync-ibm-iseries-source-1     Started   0.9s 
 ✔ Container gluesync-docker-grafana-1                         Started   1.2s
コメントする -->

Gluesyncの技術お問い合わせに必要な情報

投稿日: 2025年7月23日 作成者: climb
GlueSync MOLO17

評価版・製品版のGluesyncをご使用時に技術的なお問合せをしていただく際は、下記の情報のご提供をお願いいたします。

Gluesyncバージョン

Gluesync Webコンソールへログインし、左上メニューから確認可能です。

Gluesync通知ハブのスクリーンショット

Gluesync Webコンソール右上の鐘アイコン > 通知ハブの詳細を表示をクリックすることで、

エラー全文か確認できるため、スクリーンショットを取得します。

エンティティ(レプリケーションジョブ)のスクリーンショット

パフォーマンスに関して調査したい場合、対象エンティティをクリックすることでパフォーマンスに関するダッシュボードが表示されます。
この画面をスクリーンショットします。

Gluesyncログファイル

以下コマンドを実行し、Gluesyncのログをzip形式で出力します。
docker compose logs > gluesync-logs.txt && zip gluesync-logs.zip gluesync-logs.txt && rm gluesync-logs.txt

[オプション] 追加のGluesyncログファイル

※本手順は、クライムサポートより要求された場合に出力します。
Gluesyncの追加ログファイルは、デフォルト設定ではdocker-compose.ymlで定義されたDB接続エージェントおよびCore Hubごとに、logback.xmlの保持ルールに従って「gluesync-xxx-logs」フォルダへ保存されます。
例えば、以下の例ではdocker-compose.yml内で6つのDB接続エージェントと1つのCore Hubが定義されており、それぞれログが出力されています。

下記コマンドを実行して、logsと名のついたログフォルダが選択されていることを確認し、

ls -d *logs*/

以下のコマンドより、各logsフォルダを圧縮しlog.zipとしてエクスポートし、ご提供お願いします。

zip -r log.zip *logs*/

 

タグ: , , , ,

[Gluesyncブログ] タイムゾーン変更方法

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

Gluesyncは、Gluesyncコンテナが動作するコンテナランタイム(dockerなど)やOSのタイムゾーン設定に関わらず、デフォルト設定でUTCタイムゾーンで動作します。

ただこのタイムゾーンは変更可能であり、本ブログでは対応方法を紹介します。
まず、Gluesyncのツールキットが構成されたディレクトリへ移動し、docker-compose.ymlファイルを見つけます。
念のため、編集前のdocker-compose.ymlファイルはコピーし別名保存(cpコマンドなど)しておくことを推奨します。

cp docker-compose.yml old_docker-compose.yml

次に、vimやnanoなどのエディタを利用してdocker-compose.ymlを開きます。

vim docker-compose.yml

このファイル内では、Gluesyncの各種DB接続エージェントやCore HubといったGluesyncサービスが定義されており、それぞれenvironment:内でタイムゾーンを指定します。
例えば、以下の例ではgluesync-oracle-triggers-sourceというサービス内にて、environment:のパラメータとしてタイムゾーン(TZ)はコメントアウトされており、デフォルト値のUTCで動作していることがわかります。

gluesync-oracle-triggers-source:
image: molo17/gluesync-oracle-triggers:latest
# deploy:
# resources:
# limits:
# cpus: "2.0"
# memory: 2.0G
environment:
- type=source
- ssl_enabled=true # set to true if you want to activate TLS encryption
- LOG_CONFIG_FILE=/opt/gluesync/data/logback.xml
# Time zone: defaults to UTC, you can change it to match yours (https://docs.diladele.com/docker/timezones.html)
# - TZ: "Etc/UTC"

日本のタイムゾーンへ変更する場合は、コメントアウトを解除し以下のように更新します。

gluesync-oracle-triggers-source:
image: molo17/gluesync-oracle-triggers:latest
# deploy:
# resources:
# limits:
# cpus: "2.0"
# memory: 2.0G
environment:
- type=source
- ssl_enabled=true # set to true if you want to activate TLS encryption
- LOG_CONFIG_FILE=/opt/gluesync/data/logback.xml
- TZ=Asia/Tokyo

変更後は、docker-compose up -dコマンドを実行することで、タイムゾーンが更新された状態でGluesyncコンテナが起動し、指定したタイムゾーンとしてログ上でも表記されます。

2025-07-17T09:34:05.659 c.m.g.Ktor DEBUG 200 OK: GET - /metrics in 2ms
2025-07-17T09:34:10.659 c.m.g.Ktor DEBUG 200 OK: GET - /metrics in 2ms
2025-07-17T09:34:15.660 c.m.g.Ktor DEBUG 200 OK: GET - /metrics in 2ms
2025-07-17T09:34:20.660 c.m.g.Ktor DEBUG 200 OK: GET - /metrics in 2ms
2025-07-17T09:34:23.793 c.m.g.i INFO Stats: {"os":{"family":"Debian GNU/Linux","manufacturer":"GNU/Linux","version":"12","codeName":"bookworm","buildNumber":"5.14.0-570.23.1.el9_6.x86_64","systemUptime":75883,"systemBootTime":1752636578},"cpu":{"cpuVendor":"GenuineIntel","cpuName":"Intel(R) Xeon(R) D-2146NT CPU @ 2.30GHz","cpuFamily":"6","cpuModel":"85","physicalProcessorCount":6,"logicalProcessorCount":6,"processorCpuLoad":[0.02,0.010101010101010102,0.020202020202020204,0.0297029702970297,0.0297029702970297,0.01],"systemCpuLoad":0.018333333333333333,"interrupts":167592579,"systemCpuTicks":[5696850,18140,2315770,445202690,7300,671240,715640,0]},"ram":{"total":11700,"available":7506},"jvmRam":{"total":2926,"totalFree":2887,"allocated":64,"allocatedFree":25,"used":38},"networkIfs":[{"name":"eth0","iPv4address":["172.18.0.3"],"speedInMegabits":9536,"megabytesReceived":234,"megabytesSent":682}]}
[root@asahi-minikube gluesync-core-hub-logs]#

タグ: , , , , , , ,

【2025/6/25オンライン開催セミナー録画】Gluesyncで実現するAerospike・RDB連携〜ミリ秒レスポンスを支える仕組みと導入事例〜

投稿日: 2025年7月8日 作成者: climb
GlueSync MOLO17

【主な内容】

・NoSQL市場が伸びている背景
・NoSQLとRDBの比較 – ユースケース
・Gluesyncによるノンコーディングでのデータ連携


【このような方におすすめ】

RDBで限界を感じており、NoSQLを一部導入したい
RDBとNoSQLのデータ連携を自前でやっていて辛い
データ転送や変換処理に時間がかかりすぎている


▼ご登録はこちら

タグ: ,

Gluesync 2: Oracle 19cとPostgreSQL 16.4間でのリアルタイムデータ統合

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

レガシーのOracle 19cからPostgreSQL 16.4へ数分で移行可能ですか？はい。

🔥🔥このデモでは、GluesyncがOracleマルチテナントDB（Xstream経由）とPostgreSQLの間でリアルタイムデータレプリケーションを迅速に設定する方法を示します。カスタムコードは不要です。手順解説動画をご覧ください 👇

タグ: , ,

YugabyteDB agent for Gluesync: 分散型SQLによるリアルタイムデータ統合を実現

投稿日: 2025年6月16日 作成者: climb
Syniti (旧DBMoto)

yugabytedb agent for gluesyncYugabyteDB agent for Gluesync が利用可能になりました。これにより、YugabyteDB 分散型 SQL データベースとのシームレスな統合が実現します。この新しいエージェントは、双方向統合と完全な変更データキャプチャ（CDC）機能をサポートし、企業はリアルタイムでデータの同期とレプリケーションを行うことができます。オンプレミス環境またはクラウド環境で YugabyteDB を使用する場合でも、YugabyteDB Agent for Gluesync は安全かつ効率的なデータ統合を保証します。

YugabyteDB：現代的な分散型SQLデータベース

YugabyteDBは、ミッションクリティカルなアプリケーション向けに設計された高性能なクラウドネイティブ分散型SQLデータベースです。PostgreSQL互換性、高可用性、水平スケーラビリティを組み合わせた独自のアーキテクチャにより、データインフラストラクチャの現代化を目指す組織から採用が進んでいます。新しいYugabyteDB agent for Gluesyncは、この強力なデータベースに高度なデータ統合機能を追加し、エンタープライズデータエコシステムへの組み込みを容易にします。

Gluesyncとの統合：スマートな接続性と信頼性

YugabyteDBエージェントを活用することで、Gluesync 2.0はYugabyteDBと他のシステム間のリアルタイムデータパイプラインを構築可能です。エージェントはソースとターゲットの両方の構成をサポートし、データ移行、ハイブリッドクラウドアーキテクチャ、リアルタイム同期など、多様なユースケースに対応する柔軟性を提供します。

エージェントは、YugabyteDBの組み込みJDBCスマートドライバー経由でYugabyteDBに接続し、クラスター認識やロードバランシングなどの機能を活用します。これにより、複雑な分散環境でも最適な接続性を確保します。

YugabyteDBエージェントの主要な機能

YugabyteDB Agent for Gluesyncには、データ統合を簡素化・強化するための複数の機能が搭載されています:

  • 変更データキャプチャ (CDC): エージェントはYugabyteDBのレプリケーションスロット技術を活用し、変更をリアルタイムでキャプチャしてレプリケートします。これにより、データベースのパフォーマンスに影響を与えることなく、システム間でのデータ一貫性が確保されます。
  • 広範な互換性: YugabyteDBバージョン2.0以降に対応しています。
  • スマートドライバー統合: クラスター認識機能を備えた組み込みのJDBCスマートドライバーを使用して、YugabyteDBとのシームレスな接続を確立します。
  • 自動ロードバランシング: クラスターノード間で接続負荷を分散し、最適なパフォーマンスを実現します。
  • ソースとターゲットのサポート: エージェントはYugabyteDBをデータソースとターゲットの両方として機能させ、双方向の統合機能を提供します。

YugabyteDBコネクタの構成

YugabyteDBエージェントの設定は簡単で、Gluesyncの直感的なウェブインターフェースまたはAPIを通じて完了できます。主要な設定項目は以下の通りです：

  • JDBC接続：エージェントはネイティブJDBCスマートドライバー経由でYugabyteDBに接続します。
  • CDC設定：ソース設定の場合、エージェントはレプリケーションスロットを自動的に設定し管理します。

YugabyteDBをGluesyncと組み合わせて使用するメリット

YugabyteDBエージェントは、データ運用を最適化する企業に数多くのメリットを提供します。CDC機能により、組織は変更をリアルタイムで捕捉し、システム間でのデータ一貫性を保証します。エージェントはYugabyteDBの分散アーキテクチャに特化して設計されており、YugabyteDBインスタンスが水平スケールする際にクラスター構成をスムーズに処理します。

シームレスなハイブリッドクラウド統合を実現し、オンプレミスのYugabyteDBインスタンスとクラウドサービスをつなげたり、マルチクラウド展開のYugabyteDBを連携させることができます。複雑なデータ統合シナリオを簡素化することで、企業はインフラ管理ではなくインサイト抽出に集中できます。

一般的な利用ケース

YugabyteDBエージェントは多様な利用ケースに対応します。組織は、データベースのモダン化イニシアチブの一環としてYugabyteDBへのデータ移行をシームレスに実行したり、分析プラットフォームへの変更をリアルタイムで反映させながらACID準拠を維持できます。

YugabyteDBを複数のクラウドやオンプレミス環境の他のデータベースと同期し、災害復旧のためのレプリケーション機能を提供し、YugabyteDBをバックエンドとするマイクロサービスとアプリケーションエコシステムの他のコンポーネントを接続します。

なぜGluesyncを選ぶべきか?

Gluesync は、複雑なデータ同期タスクを簡素化するリアルタイムデータ統合プラットフォームです。将来対応型のアーキテクチャと、YugabyteDBを含む幅広いデータベースのサポートにより、Gluesyncは企業がデータワークフローを最適化するための信頼性が高くスケーラブルなソリューションを提供します。リレーショナルデータベース、NoSQLシステム、分散型SQL、クラウドネイティブプラットフォームのいずれを使用する場合でも、Gluesyncはすべての統合ニーズに対応するソリューションを提供します。

YugabyteDB Agent for Gluesyncが利用可能に：（Gluesync 2.0.10と互換性あり）これにより、企業はYugabyteDBデータベースの真のポテンシャルを解放できます。データ移行、ハイブリッドシステムの同期、リアルタイムパイプラインの構築など、あらゆるシナリオで成功するためのツールが揃っています。

タグ: , ,

Gluesync for Google BigQuery: Google BigQueryとのシームレスなデータ同期を実現する最速のソリューション

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

Gluesync for Google BigQuery

Gluesync for Google BigQuery

Google BigQueryへのデータ統合は、高速で効率的かつコスト効果が高いべきです。しかし、多くの伝統的なデータ同期ツールはサードパーティのJDBCドライバーに依存しており、不要な複雑さを導入し、パフォーマンスを低下させ、回避可能なライセンスコストを追加します。Gluesyncは、ネイティブのGoogle BigQuery SDKを活用する異なるアプローチを採用し、高速なデータ移動、コスト削減、リアルタイム効率を実現します。

JDBC不要のGoogle BigQueryデータ同期のスマートなアプローチ

Google BigQueryは、大規模な高速分析向けに設計された強力なサーバーレスデータウェアハウスです。しかし、ボトルネックなしでデータを効率的にBigQueryに投入するには、堅牢で最適化された同期ソリューションが必要です。

Gluesyncは、JDBCベースのソリューションのオーバーヘッドなしに、高速なデータ転送を処理するように設計されたシームレスでリアルタイムなデータ同期ソリューションです。多くの伝統的なETLツールは、BigQueryとの接続にサードパーティのJDBCドライバーに依存していますが、このアプローチは本質的に非効率的です。JDBCドライバーは追加の翻訳レイヤーを導入し、データ取り込みを遅らせ、処理遅延を増大させます。さらに、これらのドライバーの多くは高額なライセンス料金を必要とし、組織が回避できるコストを追加します。

Gluesyncはこの問題を完全に解消します。Google BigQuery SDKを使用することで、BigQueryのAPIとの直接通信を可能にし、データ取り込みの高速化、遅延の低減、サードパーティドライバーへの依存ゼロを実現します。これにより、大規模なデータオペレーションを管理する企業にとって、より信頼性が高くコスト効果の高いソリューションが提供されます。

JDBCを超えて：SDKベースの統合が重要な理由

多くのデータ統合ソリューションは、データベース接続の標準化された方法としてJDBCドライバーに依存しています。しかし、BigQueryのような現代のクラウドベースアーキテクチャでは、この方法は最適化されていません。JDBCベースの統合の制限には以下の点が挙げられます：

  • パフォーマンスのボトルネック：JDBCは追加の処理ステップを必要とし、データ転送を遅延させます。
  • コストの増加：多くのJDBCドライバーは商用ライセンスを必要とし、不要な費用が発生します。
  • 最適化の制限：JDBCは汎用の接続レイヤーであり、BigQueryの強力なネイティブ機能を十分に活用できません。

一方、Gluesyncの直接SDK統合は、データがより高速かつ効率的に移動することを保証します。JDBCの制限がないため、GluesyncはBigQueryのネイティブ機能を完全に活用し、リアルタイムストリーミングとバッチインジェストを容易に処理できます。Oracle、MySQL、PostgreSQL、MongoDB、Couchbase、DynamoDB、またはその他の対応ソースから同期する場合でも、GluesyncはデータをBigQueryに迅速かつ信頼性高く送信します。

追加コストなしで、比類ないパフォーマンス

組織がBigQueryとの統合時に直面する最大の課題の一つは、過剰なコストをかけずに高速なデータ取り込みを実現することです。多くの企業は、基本的な接続を可能にするため、第三者のJDBCライセンス料金に数千ドルを費やしています。

Gluesyncはこれらの追加コストを排除しつつ、優れたパフォーマンスを提供します。BigQueryのAPIと直接通信するため、遅延を削減しスループットを最大化し、データが可能な限り迅速にクエリ可能になるようにします。リアルタイムストリーミングやバッチインジェストのいずれを必要とするビジネスでも、Gluesyncは両方のシナリオを比類ない効率で処理するように設計されています。

JDBCが導入するミドルウェアのオーバーヘッドを排除することで、Gluesyncは組織がBigQueryのネイティブ機能を完全に活用できるようにします。これにより、秒単位の速度が求められる高速データ環境で事業を展開する企業にとって、理想的なソリューションとなります。

Google BigQueryの真のポテンシャルを解き放つGluesync

Google BigQuery用のGluesyncを使用すれば、サードパーティのJDBCドライバーの制限なしに、より高速で効率的なデータ同期を実現できます。パフォーマンスのボトルネックや不要なライセンス料金から解放され、ビジネスの速度に合わせてデータを移動させましょう。JDBCなしでGoogle BigQueryのデータ同期を体験しましょう！

タグ: , , , , ,