SAP Sybase ASE CDCに関する「自社開発（Build）対外部調達（Buy）」の技術ガイド: syslog、RepAgent、SAP Replication Server、トリガー、ログの飽和、リカバリ、およびリアルタイム化について解説します。
SAP Sybase ASEは、依然としてトランザクション負荷の高い金融、銀行、ERPのワークロードを実行しており、こうした分野では、基幹システムを置き換えるよりも、そのシステムを中核として統合する方がリスクが低い場合が多い。したがって、アーキテクチャ上の課題は、ASEをどのように移行するかではなく、本番データベースをデータ抽出エンジンに変えてしまうことなく、そのトランザクションデータをクラウドプラットフォーム、分析システム、および最新のアプリケーションに公開する方法にある。
AIコーディングアシスタントを活用すれば、ASEに接続してデータベースの変更を解析する概念実証（PoC）を迅速に進めることができる。本番環境でのCDCは、別の技術的課題となります。コネクタは、トランザクションログ内で永続的な位置を維持し、トランザクションを正しく再構築し、再起動に耐え、停止したリーダーを管理し、ログの保持がソースデータベースに影響を与えないようにする必要があります。
ASEでは、トランザクションの変更がsyslogに記録されるため、これらの懸念が特に具体的になります。一方、SAPのネイティブレプリケーションアーキテクチャでは、RepAgentを使用してトランザクションログをスキャンし、トランザクション情報をSAP Replication Serverに転送します。
迅速な意思決定の要約： 範囲が限定されたPoCであり、トランザクション量が管理可能で、手動によるリカバリが許容される場合は、カスタムSAP Sybase ASE CDCリーダーを構築する。ミッションクリティカルなERPのデカップリングにおいては、決定的な要件は、ソースへの影響の制御、リカバリ可能な位置情報の確保、ログ領域の保護、異種ターゲットへの対応、および運用上の可観測性であり、最初のコネクタをどれだけ迅速にコーディングできるかではない。
SAP Sybase ASE CDCアーキテクチャの理解
ASEは、変更を抽出するためのいくつかのアーキテクチャパスを提供しています。これらは、トランザクションログとの連携の密接さや、必要な運用インフラの規模において根本的に異なります。
戦略1：syslogからのログベースのキャプチャ
ASEにおけるすべてのログ記録された変更は、対応するデータベースの変更が行われる前に、syslogのトランザクションログに記録されます。このログにはトランザクションの境界や、ASEがリカバリに必要とする情報が含まれており、CDCにとって自然な低レベルのソースとなります。
ログベースのCDC実装では、ビジネステーブルを繰り返しクエリするのではなく、このトランザクション履歴を利用します。これにより、レプリケーションパスから反復的なテーブルスキャンが排除され、運用テーブルに対する追加のクエリが望ましくない高スループットの金融ワークロードにおいて特に有効です。
技術的な課題はライフサイクル管理です。コンシューマーの処理が停滞すると、トランザクションログの保持期間や利用可能なログセグメントの空き容量に悪影響を及ぼす可能性があります。ASEは、sp_spaceused syslogなどのメカニズムを通じてログ領域情報を公開していますが、SAPは、大規模なデータベースに対して専用のトランザクションログデバイスを推奨しており、空き領域のしきい値監視をサポートしています。
戦略2：RepAgentとSAP Replication Server
標準的なSAPレプリケーションスタックでは、RepAgentを使用します。これは、トランザクションログをスキャンし、トランザクション情報をSAP Replication Server (SRS)に送信するASEスレッドです。RepAgentは、特定のHADRシナリオ向けのストリームレプリケーションや、その他のレプリケーショントポロジー向けのLog Transfer Language（LTL）レプリケーションをサポートしています。
管理には、sp_config_rep_agent、sp_start_rep_agent、sp_stop_rep_agent、log transferの再開など、ASEおよびSRS固有のライフサイクル操作が含まれます。これにより、成熟したベンダーネイティブなレプリケーションパスが提供されますが、同時にSAP固有のインフラストラクチャ、運用知識、およびレプリケーションサーバーアーキテクチャへの結合も導入されることになります。
ASEを最新のNoSQL、ストリーミング、またはクラウドのターゲットから切り離そうとする企業にとって、その追加のレプリケーション層を維持し続けることが依然として正当化されるかどうかが問題となります。
戦略 3：トリガーベースまたはクエリベースの抽出
ログキャプチャの代替手段として、タイムスタンプによるポーリングやシャドウテーブルに加え、トリガーベースのキャプチャがあります。
これらのアプローチでは、CDC処理がアプリケーションの書き込みパスまたはクエリパス内に組み込まれます。トリガーはDMLに同期処理を追加し、通常は追加の書き込みを必要とします。一方、ポーリングは、syslogにすでに反映されている変更を再検出するために、CPU、I/O、およびクエリ処理能力を繰り返し消費します。
トリガーベースのキャプチャは書き込みパスに負荷を追加するため、そのオーバーヘッドは実際のワークロードで測定する必要があります。その代わり、SAP Replication Serverに依存せず、トリガーや変更テーブルを手作業ではなくレプリケーションプラットフォームによってインストール・保守される限り、管理しやすさを維持できます。
カスタムおよびAI生成のCDCコネクタが本番環境で失敗する理由
接続コードの生成自体は難しいことではありません。コネクタがデータベース、ネットワーク、インフラストラクチャの障害を乗り越えて継続的に動作しなければならない場合、ASE特有の障害モードが発生します。
- チェックポイントの非同期化。 リーダーは、トランザクションログの位置をダウンストリームへの配信と一貫性を保ちながら永続化する必要があります。状態の進めが早すぎるとデータ損失のリスクがあり、遅すぎるとリプレイや重複処理が発生する可能性があります。
- syslogの飽和。 レプリケーションパスが停滞すると、トランザクションログの容量が枯渇した際に可用性の問題となる可能性があります。ASEエラー1105は、ログセグメントが満杯の状態でsyslog用の領域を割り当てられないことを明示的に報告します。SAPはこの状態について、レプリケーションスレッドを停止させる可能性があると文書化しています。
- 長時間実行されるトランザクション。 オープン状態のままのトランザクションは、ログの切り捨てを複雑にし、新しい変更が引き続き到着する中で、CDCレイヤーがトランザクションの境界を維持することを必要とします。
- RepAgentおよびログ転送の中断。ネイティブ展開では、ASE側のRepAgentの障害と、接続障害やレプリケーションサーバーの障害とを区別する必要があります。RepAgentのエラーは9200～9299の範囲を占め、ASEエラーログに記録されます。
- スキーマのドリフト。ALTER TABLE、データ型の変更、およびDDLシーケンスにより、プロトタイプが想定しているマッピングが無効になる可能性があります。スキーマの処理は、単なる構文解析の詳細として扱うのではなく、下流との互換性を考慮して調整する必要があります。
- 長時間のストール後の回復。 リーダーを再起動しても、安全に処理を再開できるとは限りません。SAP独自のRepAgentの再起動動作はレプリケーションの状態に依存しています。つまり、最も古いトランザクションからスキャンを開始しますが、最後に処理された位置以降のレコードを送信します。一方、レプリケーション・サーバーは重複レコードを処理します。カスタム実装では、これと同等の状態管理が必要です。
GluesyncによるSAP Sybase ASEレプリケーションへのアプローチ
Gluesyncは、運用データベースと下流の統合ワークロードを分離することで、ASEの近代化に取り組みます。ASE上では、Gluesyncがトリガーをインストール・管理し、行識別子や変更メタデータをGluesyncが管理するCDCテーブルに書き込みます。下流システムは、ERPテーブルに対して独自の抽出クエリを実行する代わりに、増分変更を受け取ります。
初期のマテリアライゼーションにおいて、Gluesyncのスナップショット機能は、継続的なCDCが引き継ぐまでの間、マルチスレッド読み取り、ソースのパーティショニング、および書き込み同時実行数の制限をサポートします。ストリーミングが開始されると、Gluesyncはスループットとレイテンシをリアルタイムで追跡します。
運用管理機能には、レイテンシやパイプラインの停止を検知するSmart Alertsや、データセット間の整合性問題を特定するための行数のドリフト検出（開発者プレビュー）が含まれます。導入は、ソースデータベースがデータを必須のSaaSコントロールプレーンに公開することを要求されるのではなく、Kubernetes環境を含む企業が管理するインフラストラクチャ内で行うことができます。
ASE環境の場合、これにより、エンジニアリングの目標が、別の特注のログリーダーを維持することから、異種混在の宛先全体にわたって監視されたレプリケーションサービスを運用することへと変化します。
ASEエージェントはTRUNCATE操作を検知せず、一括ロードもサポートしていません。
「自社開発か外部調達か」の判断
ワークロードが範囲の限定されたPoCであり、関与するエンティティがごくわずか、スループットが低く、オペレーターが同期の失敗を手動で復旧できる場合、カスタムASEコネクタの採用は妥当です。AIを活用することで、その段階に到達するためのコストを大幅に削減できます。
しかし、ASEが決済、取引、会計、またはERPプロセスを支える場合、状況は一変します。その時点で、syslogの負荷、決定論的な復旧、ソースの保護、および可観測性は、データベースの可用性に関する懸念事項となります。
Gluesyncが注目されるのは、個別のレプリケーション実装を維持することなく、同一のASEトランザクションを異種のRDBMS、NoSQL、ストリーミング、またはクラウドシステムに到達させる必要がある場合です。したがって、この比較は単に「ソフトウェア対カスタムコード」という問題ではなく、組織がSAP Replication Serverスタイルのレプリケーションスタックを運用し続けるか、あるいはより広範なCDCプラットフォームを中心に統合を標準化したいかという点にも関わるものです。
よくある質問（FAQ)
GluesyncはSAP Sybase ASEからの変更をどのようにキャプチャしますか？
Gluesyncが自動的にインストールおよび管理するデータベーストリガーとCDCテーブルを通じて行われます。エージェントは、ソースまたはターゲットとして、ASE 15.7以降をサポートしています。
SAP Sybase ASEはログベースのCDCをサポートしていますか？
はい。ASEはトランザクションによる変更をsyslogに記録し、SAP独自のRepAgentアーキテクチャがトランザクションログをスキャンして、トランザクション情報をReplication Serverに送信します。
ログベースのCDCはASEに負荷を追加しますか？
アプリケーションテーブルに対する反復的な抽出クエリは回避できますが、文字通りコストがゼロというわけではありません。ログの消費、保持期間、ネットワークトラフィック、および停止したコンシューマーの挙動については、依然として設計と監視が必要です。
なぜASEのCDCにおいてチェックポイント設定が重要なのでしょうか？
チェックポイントは、下流への配信をトランザクション履歴内の既知の位置に紐付けます。永続的な状態がなければ、リカバリ時には以前に配信された変更を再実行するか、下流でコミットされなかった変更をスキップすることになります。
AIは本番環境対応のASE CDCコネクタを生成できるか？
AIは、プロトコルコード、データベース接続、および解析ロジックの開発を加速できます。しかし、トランザクションの復旧、syslogの容量保護、スキーマの進化、監視、高可用性（HA）、および安全なデプロイ手順を設計する必要性がなくなるわけではありません。
異種環境でのCDCを実現するために、SAP Replication Serverの枠を超えて
もし、主にASEデータを最新のプラットフォームへ移行させる必要があるという理由でSAP Replication Serverをアーキテクチャに残している場合は、そのレプリケーション層が、現在運用している宛先に依然として適合しているかどうかを評価してください。
Gluesyncは、共通のレプリケーションプラットフォームを通じて、レガシーRDBMSデータをNoSQL、ストリーミング、およびクラウドネイティブ環境と橋渡しするように設計されています。
RSSフィードを取得する
