Cloud Integration Hub のトピックのレコードのメンテナンスについて

この記事は [インフォマティカ Advent Calendar 2023](https://qiita.com/advent-calendar/2023/informatica) Day 8 の記事として書かれています。

# はじめに
Cloud Integration Hub (以下 CIH) では、パブリケーションによりトピックへ取り込んだデータを指定した期間保持した後、定期的にクリーンアップします。本文書ではクリーンアップに関連する設定と、どのようなタイミングでレコードがクリーンアップされるかをご紹介します。

# メンテナンスのジョブについて
メンテナンスのジョブは 1 日 1 回、23:00 UTC に実行されます。ジョブの実行時間帯や実行回数を変更することはできません。

メンテナンスのジョブはシステムイベントとして「イベント」ページに表示されます(雲のアイコンが表示されるものがシステムイベントです)。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2335778/ec177762-884e-358c-0da8-817af92fbcf5.png)

上記画面ショットのようにレコード右側にカーソルをあわせ「メンテナンスレポート」を選択すると、そのメンテナンスのジョブで、各トピック表内のどの期間のレコード(ファイルパブリケーションリポジトリの場合にはどの期間のファイル)が削除対象となったかを確認できる画面が表示されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2335778/82f6fe93-09c5-1326-3d63-520ac3dd4f0c.png)

# データ保持期間の設定
どの程度の期間データを保持するかはトピック表ごとに指定を行います。
下記が関連するプロパティです。

<dl>
    <dt>コンシュームされるデータの保持期間</dt>
    <dd>すべてのサブスクライバがデータをコンシュームした後いつまでデータを保持するかを指定します。保持期間は 1 日から 90 日までの間で指定します</dd>
    <dt>コンシュームされないデータの保持期間</dt>
    <dd>コンシュームされていないデータをいつまで保持するかを指定します。「コンシュームされるデータの保持期間」で指定した期間から 90 日までの間で指定します</dd>
</dl>

# データが削除されるタイミング
ここでは、プライベートパブリケーションリポジトリを使用している環境で、ひとつのトピックに対しひとつのパブリケーション/サブスクリプションが作成されているシンプルなケースを例に、どのようなタイミングでデータが削除されるかを見てみます。

## 下準備
2 つのトピック topic_retention_test と topic_retention_test2 を用意します。
両方とも「コンシュームされるデータの保持期間」は「1」、「コンシュームされないデータの保持期間」は「3」に設定します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2335778/8ae7232c-7219-bb87-0bf0-160fe08ac11a.png)
※ topic_retention_test2 も同じ設定です。

topic_retention_test と topic_retention_test2 にはそれぞれ日本時間 0:00 と 12:00 にスケジュール実行されるパブリケーションを作成します。
また、topic_retention_test2 にはサブスクリプションを作成し、パブリッシュ済みデータの準備ができている場合に実行するよう設定します。topic_retention_test にはサブスクリプションを作成しません。これにより、データがコンシュームされる場合とされない場合の違いを比較します。

topic_retention_test のトピック図
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2335778/d4541ed2-0c20-be83-bd6a-d79afbe1c4b0.png)

topic_retention_test2 のトピック図
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2335778/24a328b8-f3c5-649b-7d1b-dbea59691f0f.png)

## 削除対象の確認
上記設定を行いしばらくイベントを実行した環境で、2023/11/30 08:00 JST (2023/11/29 23:00 UTC) に実行されたメンテナンスイベントから、削除対象となるレコードの日にちを確認してみます。

(イベントページの情報)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2335778/c41395bb-e575-2d81-5313-b379be6b98a4.png)

(メンテナンスレポートから topic_retention_test と topic_retention_test2 の情報を抜粋したもの)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2335778/b5ede04a-d563-f33c-dd6d-1fb41a45af56.png)

(プライベートパブリケーションリポジトリの内容) ※データベースはタイムゾーンが JST の環境で動作しています
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2335778/531f8afd-a626-6d2b-ed5f-96cb6294573c.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2335778/abf53520-1f37-58a5-7975-72efdc34c997.png)

### サブスクリプションイベントが存在しない場合 (topic_retention_test)
topic_retentionn_test は **2023/11/26 00:00 UTC より前のレコード** が削除対象となっています。

パブリケーションイベントはあるがサブスクリプションイベントが存在しない場合には、メンテナンスジョブが実行された日にちから「コンシュームされないデータの保持期間」を引いた日にちが計算されます。
メンテナンスジョブを実行する 11/30 から「コンシュームされないデータの保持期間」を引いた日にちである **11/26** より前のレコードが削除対象となります。

### 全てのイベントのコンシュームステータスが「最終」になっている場合 (topic_retention_test2)
一方 topic_retention_test2 では **2023/11/27 00:00 UTC より前のレコード** が削除対象となっています。

topic_retention_test2 では全てのパブリケーションイベントがコンシュームされているため「コンシュームされるデータの保持期間」が考慮されますが、こちらはジョブ当日から単純に「コンシュームされるデータの保持期間」で指定された日を引いた日にちとはなりません。

対象期間は、メンテナンスジョブが実行された前日以前でコンシュームされた最新のパブリケーションイベントを基点に計算されます。メンテナンスジョブが実行されたのは 11/30 のため、その前日以前でコンシュームされた最新のパブリケーションを確認すると 11/29 のジョブになります(ID:1504048 のパブリケーションイベントが ID:1504051 のサブスクリプションイベントで処理されています)。11/29 から「コンシュームされるデータの保持期間」で指定された 1 日分データが保持されるため、**11/27** より前のレコードが削除対象となります。

# 終わりに
この記事ではデータがパブリッシュされたタイミングで実行・成功するシンプルなケースと、それとの比較のためにパブリッシュのみ実行してサブスクリプションイベントが存在しないケースを例としました。「サブスクリプションイベントはあるが実行されていない場合はどうなるのか」や「ひとつのトピックに対して複数のサブスクリプションが関連づいている場合はどうか」などについてはまたいずれ記事を分けてご紹介したいと思います。

トピックはデータの配信のハブとなる箇所で、永続的にデータを保持する用途のデータベースではありません。適切な間隔でレコードのメンテナンスが行われるよう保持期間を設定してご使用ください。