各データ移動サービス・コンポーネントの動作とスケジューリングは、
開発環境、テスト環境、および実稼働環境におけるさまざまな必要を満たすように
構成できます。1 つのコンポーネントの構成を変更すると、そのコンポーネントに従属するその他のコンポーネントの動作に直接影響する可能性があります。
一般的に、2 つの依存関係があります。
- Capture コンポーネントは、定期的に Source Life Cycle コンポーネントを呼び出します。
Capture コンポーネントが実行されていない場合は、Source Life Cycle コンポーネントは
実行されません。Life Cycle コンポーネントの呼び出し間の遅延は構成可能です。
上の図では、Source Life Cycle コンポーネントは 3 つの時間単位ごとに呼び出され、いくつかのアクティビティーを実行してから Capture コンポーネントに制御を戻し、処理が継続されます。
- ETL コンポーネントと Target Life Cycle コンポーネントは、
データがソース・データベースからターゲット・データベースに正常に移動された後で、Apply コンポーネントによって
呼び出されます。ETL コンポーネントと Target Life Cycle コンポーネントは、
Apply コンポーネントが実行されている場合のみ呼び出されます。
従属コンポーネントは、それが従属するコンポーネントと
異なるスケジュールで作動する必要があるため、呼び出しが必ずしも
実行されるとは限りません。代わりに、それぞれの従属コンポーネントは、呼び出されたときに
そのスケジュールを確認し、まだタスクを実行する時間でない場合は呼び出し側コンポーネントに
制御を戻します。上記の例では、ETL コンポーネントと Target Life Cycle コンポーネントは、
両方のコンポーネントのスケジュールにより 5 つの時間単位ごとに複数回の呼び出しが禁止されている
場合のみ、2 回実行できます。
ETL コンポーネント (および Target Life Cycle コンポーネント) は T2 (および T3) で呼び出され、実行できます。
次の呼び出しは、T6 あたりで発生します。それらが前回実行されてから 5 未満の時間単位が
経過しているため、すぐに Apply コンポーネントに制御が
戻されます。T8 (および T9) あたりで発生する後続の呼び出しは、5 つの時間単位が既に経過しているため、実行できます。各コンポーネントは 1 つ以上のコンポーネントのインスタンスによってインプリメントされます。各インスタンスを別々に構成して、
より詳細な制御を実行できるようにすることができます。
注: 変更が行われると、特に注記されていない限り、それらは即時に反映されます。
Capture コンポーネントおよび Apply コンポーネントのデフォルト構成は、該当する制御テーブルの変更、または開始スクリプトでの
コマンド行パラメーターを使用した指定変更により、変更可能です。いずれかの制御テーブルを更新することにより、ETL コンポーネントおよび Life Cycle 制約コンポーネントを構成できます。
以下の手順を実行して、開発環境、テスト環境、および実稼働環境の要件を満たすように
データ移動サービス・コンポーネントをカスタマイズします。
(ソース) Capture コンポーネント・インスタンスの構成
Capture コンポーネント・インスタンスは、DB2® Capture レプリケーション・ユーティリティーと同等です。デフォルトで、このユーティリティーは継続的にソース・テーブルへの変更をキャプチャーし、それらの変更を内部の作業テーブルに記録するように構成されています。一般的に、Capture コンポーネント・インスタンスのデフォルト構成を変更する必要はありません。
- Capture コンポーネント・インスタンスの識別。
ビジネス指標モデルに関連したデータをキャプチャーするために、複数の Capture コンポーネント・インスタンス (つまりDB2 Capture ユーティリティー) が使用されます。
ビジネス指標モデルにサービスを提供するように割り当てられている Capture ユーティリティーを判別するには、以下を実行します。
- Capture ユーティリティー構成を変更する対象のデータ移動サービスを指定します。
- 状態データベース (状態データベースからランタイム・データベースへのデータ移動サービスの場合) またはランタイム・データベース (ランタイム・データベースからヒストリー・データベースへのデータ移動サービスの場合) の WBIRMADM.RMMETADATA メタデータ・テーブルを検査し、すべての Capture ユーティリティー名 (列 SRC_RM_CAP_SVR_NAME) を確認します。
例: クエリー「SELECT OM_NAME, SRC_TAB_NAME, SERVICE_NAME, SRC_RM_CAP_SVR_NAME FROM
WBIRMADM.RMMETADATA WHERE SERVICE_NAME='State to Runtime'」は、次のような結果になります。
上記の例では、Capture ユーティリティー CAPTURE_1 は、状態データベースのビジネス指標モデル STEW_S と関連付けられた 2 つの
ソース・テーブルに対するすべての変更をキャプチャーするように割り当てられています。
- Capture 作業テーブルの整理間隔の変更。
自動整理が使用可能 (autoprune パラメーターが「y」) な場合、Capture ユーティリティーは、300 秒 (prune_interval パラメーターのデフォルト) ごとに作業テーブルを自動的に整理します。それぞれの整理アクティビティーの結果、データベース・トリガーによってインプリメントされている Source Life Cycle コンポーネントのインスタンスが自動的に呼び出されます。Capture ユーティリティーの整理間隔パラメーターを変更すると、ソース・テーブルが Source Life Cycle コンポーネントによって
整理される頻度に直接影響します。以下の図は、Capture の整理間隔の変更が Source Life Cycle コンポーネントのインスタンスの呼び出しにどのような影響を与えるかを示します。
Capture インスタンスの prune_interval パラメーターを 2 つの
時間単位 (例えば 300 秒) から 3 つの時間単位 (例えば 450 秒) に増加させると、
次のようになります。
- Capture 作業テーブル内の行 (除去可能) が作業テーブル内により長く残存するようになるため、
潜在的なスペース所要量が増加します。
作業テーブルは大きくなりますが、システム負荷と偶発事故のリスクは低くなる可能性があります。
- ソース・テーブル内の行 (ライフ・サイクル保存ポリシーに基づいて除去可能) が、
ソース・テーブル内に予想以上に長く残存するようになります。
一般に、Capture の prune_interval パラメーターが Life Cycle コンポーネントの prune_interval パラメーターよりも大きい値に設定されている場合は、Capture のパラメーター設定が優先します。Capture ユーティリティーが実行されていない場合、またはその自動整理機能が使用不可の場合は、Source Life Cycle コンポーネントは実行されません。
Source Life Cycle コンポーネントの構成
それぞれのソース・データベース (状態データベースおよびランタイム・データベース) では、複数の Life Cycle コンポーネントのインスタンスが使用されています。トリガーによってインプリメントされているそれぞれのインスタンスは、そのデータ移動サービスのソース・データベースに配置された、制御テーブル WBIRMADM.RMPRUNECTRL で定義されている保存ポリシーを実行します。ライフ・サイクル保存ポリシーは、テーブルごとに指定されます。したがって、WBIRMADM.RMPRUNECTRL の 1 つの行が、整理を必要とする 1 つのテーブルに対応します。
- Source Life Cycle コンポーネント・インスタンスの識別。
特定の
ビジネス指標モデルに対する保存ポリシーを強制するために割り当てられているトリガーを判別するには、以下を実行する必要があります。
- ETL 構成を変更する対象のデータ移動サービスを確認します。
- 状態データベース (状態データベースからランタイム・データベースへのデータ移動サービスの場合) またはランタイム・データベース (ランタイム・データベースからヒストリー・データベースへのデータ移動サービスの場合) の WBIRMADM.RMMETADATA テーブルを検査し、列 SRC_RM_PRUNE_TRG_NAME の関連トリガー名を検索します。
例: クエリー「SELECT OM_NAME,
SRC_TAB_NAME, SERVICE_NAME, SRC_RM_PRUNE_TRG_NAME FROM WBIRMADM.RMMETADATA
WHERE SERVICE_NAME='State to Runtime'」は、次のような結果になります。
この例では、2 つのトリガー (WBIRMADM.MCPruneTrig_8 と WBIRMADM.MCPruneTrig_9) が、状態データベースの
ビジネス指標モデル STEW_S のソース・テーブルのライフ・サイクル保存ポリシーを強制しています。保存ポリシーはテーブルによって定義され、Life Cycle コンポーネントのインスタンス名によっては定義されないため、Life Cycle コンポーネントの動作を変更する場合は、列 SRC_TAB_NAME を追跡しておくようにします。
- Source Life Cycle コンポーネントのインスタンス構成の変更。
- Life Cycle コンポーネントのインスタンスの使用可能化および使用不可化:
整理は、ご使用のシステムの
パフォーマンスに大きな影響を与える可能性があります。整理が使用可能なときは、
トランザクション・サーバー (状態) およびレポート・サーバー (ランタイム) が対処する必要のある
情報量が削減されます。また、Life Cycle コンポーネントのパラメーターに応じて、
各呼び出し中にそれらの同じテーブルに対する負荷も
少し追加されます。整理が使用不可のときは、時間とともにソース・テーブルは大きくなり、
それによってパフォーマンスが低下する可能性もあります。
デフォルトでは、ライフ・サイクル保存ポリシーに従って、ソース・テーブルが自動的に整理されます。一時的に整理を使用不可にするには、
対応する WBIRMADM.RMPRUNECTRL エントリーを変更します。整理を使用可能にするには
列 PRUNE_ENABLED を 1 に、整理を使用不可にするにはその他の
任意の数値 (0 を推奨) に設定します。
次の構成が使用されている場合、ソース・テーブル wbi.CTX_TQ4MUFT42JOT5F6R3KSDQDE2UI から行がパージされますが、テーブル wbi.AI_BVSOYAP1DRWFD5HNQJR5HFQQQE からは行がパージされません。クエリー「SELECT TABLE_NAME, PRUNE_ENABLED FROM
WBIRMADM.RMPRUNECTRL」は、次のような結果になります。
- 保存ポリシーの変更:
保存時間ポリシーは、ランタイム・データベースにあるソース・テーブルに対してのみ変更できます。WBIRMADM.RMPRUNECTRL の設定にかかわらず、状態データベースに配置されるすべてのテーブルに対して保存期間 0 が強制されます。保存期間は、行が除去可能になるまでソース・テーブルに残存する必要がある最小時間として定義されています。ただし、以下の 2 つの条件を満たす必要があります。制御テーブルを使用して、2 つの条件のうち 1 つ (分単位で指定される保存時間) のみをカスタマイズ可能です。
削除の準備ができているとマークされており、少なくとも RETENTION_IN_MINUTES の期間ソース・テーブルに残存していた行は、除去可能になります。
ランタイム・データベースのソース・テーブルのデフォルト構成を使用すると、サーバーによって削除の準備ができているとマークされている行は、除去可能になるまでに 1 日 (1440 分) 保持される必要があります。クエリー「SELECT TABLE_NAME,
RETENTION_IN_MINUTES FROM WBIRMADM.RMPRUNECTRL」は、次のような結果になります。
WBIRMADM.RMPRUNECTRL 制御テーブルのエントリーに対する変更は、Source Life Cycle コンポーネントが呼び出されるたびに選出されます。
- ソース・データ整理のスケジューリング:
Capture 作業テーブルの整理間隔と Source Life Cycle コンポーネントの呼び出しとの間には依存関係があります。
以下の図に示すように、Source Life Cycle コンポーネントのインスタンスの呼び出し間に十分な時間が経過していない場合は、結果的に呼び出しが実行されるとは限りません。
Source Life Cycle コンポーネントが 4 つの時間単位ごとに実行されるようにスケジュールされているのに対し、Capture コンポーネントが 2 つの時間単位ごとに作業テーブルを整理するように構成されていると想定すると、T4 の時点での呼び出しは実行されません。
デフォルトのスケジュールを変更するには、WBIRMADM.RMPRUNECTRL の該当するエントリーを見つけ、実行間の最小遅延を分単位で表す PRUNE_INTERVAL の列値を変更します。
値を増加させると、実行の頻度は低くなります (ただし、呼び出し数は変更されません)。それぞれの実行で、ソース・テーブルの除去できる行を判別し、それらを除去します。
ソース・データベースを定期的にモニターし、これらの削除により引き起こされるロックの結果としての潜在的なパフォーマンス上の問題を識別し、除去します。
(ターゲット) Apply コンポーネントの構成
Apply コンポーネントのインスタンスは、DB2 Apply レプリケーション・ユーティリティーです。Capture ユーティリティーによってキャプチャーされた変更は、デフォルトで、ターゲット・データベースのステージング・テーブルに継続的に適用されます。デフォルトのユーティリティー構成パラ
メーターは、ほとんどの環境に対して十分であり、したがって変更する必要はありません。
- Apply コンポーネントのインスタンスの識別。
ビジネス指標モデルと関連付けられた内部のステージング・テーブルに対するデータの変更を適用するために、複数の Apply コンポーネントのインスタンス (DB2 Apply ユーティリティー) が使用されます。
ビジネス指標モデルにサービスを
提供するように割り当てられている Apply ユーティリティーを判別するには、次のようにします。
- Apply ユーティリティー構成を変更する対象のデータ移動サービスを確認します。
- ランタイム・データベース (状態データベースからランタイム・データベースへの
データ移動サービスの場合) またはヒストリー・データベース (ランタイム・データベースからヒストリー・データベースへの
データ移動サービスの場合) の WBIRMADM.RMMETADATA メタデータ・テーブルを検査し、すべての Apply ユーティリティー名
(列 TGT_RM_APP_SVR_NAME) を確認します。クエリー「SELECT OM_NAME, SRC_TAB_NAME,
SERVICE_NAME, TGT_RM_APP_SVR_NAME FROM WBIRMADM.RMMETADATA WHERE SERVICE_NAME='State
to Runtime'」は、次のような結果になります。
この例では、状態データベースにキャプチャーされたビジネス指標モデル STEW_S に対するデータの変更は、Apply ユーティリティー APPLY_4 によって、
ランタイム・データベースのステージング・テーブルに
適用されます。
Apply がそれまでに Capture ユーティリティーによって記録されたすべての (コミット済み) 変更の処理を完了するたびに、1 つ以上の ETL コンポーネントのインスタンスおよび Target Life Cycle コンポーネントのインスタンスが呼び出されます。
ETL コンポーネントの構成
ETL コンポーネントは、WebSphere® Business Monitor にデータベースのストアード・プロシージャーとしてインプリメントされています。これらのストアード・プロシージャーは、どのデータ移動サービスの場合でも常にターゲット・データベース上にあります。したがって、状態データベースからランタイム・データベースへのデータ移動サービスに割り当てられたすべての ETL ストアード・プロシージャーはランタイム・データベースに配置され、ランタイム・データベースからヒストリー・データベースへのデータ移動サービスに割り当てられた ETL ストアード・プロシージャーはヒストリー・データベースにあります。
- ETL コンポーネントのインスタンスの識別。
ビジネス指標モデルと
関連付けられた内部のステージング・テーブルに追加されたデータを処理するために、
複数の ETL コンポーネントのインスタンスが設定されます。
特定の
ビジネス指標モデルにサービスを提供するように割り当てられているストアード・プロシージャーを判別するには、以下を実行します。
- ETL 構成を変更する対象のデータ移動サービスを確認します。
- ランタイム・データベース (状態データベースからランタイム・データベースへの
データ移動サービスの場合) またはヒストリー・データベース (ランタイム・データベースから
ヒストリー・データベースへのデータ移動サービスの場合) の WBIRMADM.RMMETADATA メタデータ・テーブルを検査し、
すべての ETL ストアード・プロシージャー名 (列 TGT_RM_SPETL_NAME) を識別します。クエリー「SELECT
OM_NAME, SRC_TAB_NAME, TGT_TAB_NAME, SERVICE_NAME, TGT_RM_SPETL_NAME FROM
WBIRMADM.RMMETADATA WHERE SERVICE_NAME='State to Runtime'」は、次のような結果になります。
この例では、状態データベースでキャプチャーされ、ランタイム・データベースのステージング・テーブルに適用された、ビジネス指標モデル STEW_S のデータ変更は、WBIRMADM.WBIRMSP_10 および WBIRMADM.WBIRMSP_14 という名前のストアード・プロシージャーによって処理されます。正常に処理されたデータは、ランタイム・データベースのターゲット・テーブル (列 TGT_TAB_NAME によって示される) に保管されます。
- ETL コンポーネントのインスタンスの構成の変更。
ETL コンポーネントのインスタンスの構成は、WBIRMADM.RMCONTROL 制御テーブルに保管されます。
状態データベースからランタイム・データベースへのデータ移動サービスに割り当てられたインスタンスは、構成をランタイム・データベースに保持し、その他はすべてヒストリー・データベースに保持します。構成に対して行われた変更は、次の開始時にストアード・プロシージャーによって選出されます。制御テーブルを使用して構成可能な 3 つのオプションがあります。
- 2 つの ETL 実行間の最小経過時間 (ETLSCHEDMETHOD、ETL_0_MINUTES)
- ロギング出力の細分度 (LOGLEVEL)
- トランザクション期間 (COMMITINTERVAL)
このテーブルのそれぞれの行は、データを取り込む必要のあるちょうど 1 つのターゲット・テーブルに対応する 1 つの ETL コンポーネントのインスタンスに対応しています。次の構成例では、
構成に対する変更がどのようにインスタンスの動作に影響するかを
示します。
- ETL スケジュールの変更。
ETL コンポーネントのインスタンスは、Apply コンポーネントのインスタンスがサブスクリプション・セットの処理を完了するたびに呼び出されます。呼び出されると、ETL のインスタンスはそのスケジュールを確認し、処理を開始するか、または即時に Apply コンポーネントのインスタンスに制御を戻します。
このインスタンスは、制御テーブル WBIRMADM.RMCONTROL に保管されている情報を使用して、実行する必要があるかを判別します。下の図は、呼び出しと実行の違いを示しています。
スケジュールに従って、1 回目と 3 回目に ETL コンポーネントの
インスタンスが実行されています。2 回目の呼び出しはスケジュール外で発生したため、処理アクティビティーは実行されません。
状態データベースからランタイム・データベースへのデータ移動サービスおよびランタイム・データベースからヒストリー・データベースへのデータ移動サービスで ETL コンポーネントの
インスタンスが実行される頻度は、さまざまな要因によって決定されます。
- 使用可能: データがいつ、ターゲット・テーブルでアクセス可能になるかを意味します。
短い間隔を選択すると、データは早く使用可能になりますが、システム負荷も増加します。
- データ・ボリューム: レプリケーション・ユーティリティーは、それが ETL コンポーネントの
インスタンスによって処理されているかどうかにかかわらず、継続的に (または構成されたとおりに) ステージング・テーブルに
データを送信します。処理を必要とするデータが増加すると、使用されるデータベースのリソースが増加します。多くの場合、データを処理する頻度を増やすと、最大リソース使用量を削減できます。
- 処理時間: ETL プロセスは、ヒストリー・データベースのデータの処理よりも、ランタイム・データベースのデータの方が、時間がかかりません。それに応じて、スケジュールを計画します。使用する実行間の遅延を短くすると、スケジュールされた遅延よりも実行時間が長い場合には、良好なパフォーマンスを得られません。例えば、ETL コンポーネントのインスタンスが処理を完了させるために 60 秒かかるとすると、ETL コンポーネントのインスタンスは順次実行されるため、30 秒のスケジュール間隔は事実上少なくとも 60 秒のスケジュール間隔になります。
現在、2 つのスケジューリング・モードがサポートされています。
- ロギング・レベルの変更。
ストアード・プロシージャーによって 2 つのロギングのレベル、最小 (0) および最大 (1)、がサポートされます。最小のデフォルト設定を変更するには、ロギング・レベルを変更する必要のあるストアード・プロシージャー (TGT_RM_SPETL_NAME) における WBIRMADM.CONTROL の列 LOGLEVEL の値を変更します。すべてのロギング出力は WBIRMADM.RMLOG に追加されます。2 つの例のストアード・プロシージャー WBIRMADM.WBIRMSP_10 および WBIRMADM.WBIRMSP_14 は、
両方とも最小ロギングを実行します。
ログ・テーブルは自動的に整理されないため、定期的に DBA によってモニターされる必要があります。特に他の方法を指示されていない限り、ロギング出力は最小に保ってください。
- トランザクション期間の変更。
ストアード・プロシージャーによって正常に処理されたデータは、即時にターゲット・テーブルに書き込まれます。
ただし、ターゲット・テーブルへの更新は、コミット間隔設定 (WBIRMADM.RMCONTROL の列 COMMITINTERVAL) に応じて、指定された行数が処理されるまで、または処理する行がなくなるまで永続的にはなりません。COMMITINTERVAL の値を増加させると (例えば 1500 に)、ストアード・プロシージャーは、変更をコミットする前に、より多くのデータを処理するようになります。ターゲット・テーブルに対するロックがより長く保持され、同一のテーブルにアクセスしようとしているその他のコンポーネントに悪影響を与える可能性があります。
期間を減少させると (例えば 500 に)、ターゲット・テーブルで使用可能になる前に処理する必要のある行の数は少なくなり、より早くロックが解除されます。
Target Life Cycle コンポーネントの構成。
Apply コンポーネントのインスタンスによって、新規データまたは更新データが適用されている間は、ETL 作業テーブルは大きくなり続けます。ストアード・プロシージャーによってインプリメントされている 1 つの Target Life Cycle コンポーネントのインスタンスが、それぞれのターゲット (ランタイムおよびヒストリー) データベースの 1 つの作業テーブルに割り当てられます。各インスタンスは、制御テーブル WBIRMADM.RMPRUNECTRL で定義されている内部の保存ポリシーを強制します。ソース・テーブルの場合と同様に、ETL 作業テーブルのライフ・サイクル保存ポリシーは、テーブルごとに指定されます。したがって、WBIRMADM.RMPRUNECTRL の 1 つの行が、整理を必要とする 1 つのテーブルに対応します。
データ移動サービスの構成パラメーターの要約
次の表に、それぞれの data movement services コンポーネントで提供されているパラメーターのうち、最もよく使用されるものを要約します。構成パラメーターについての詳細は、「DB2 ユニバーサル・データベース レプリケーションの手引きおよび解説書」を
参照してください。
コンポーネント |
パラメーター名 |
デフォルト値 |
有効な値 |
パラメーター・ロケーション |
Capture |
autoprune |
Y |
|
|
Capture |
prune_interval (秒) |
300 |
|
|
ソース・ライフ・サイクル |
PRUNE_ENABLED |
1 |
0 - 使用不可
1 - 使用可能
|
データ移動サービスのソース DB: WBIRMADM.RMPRUNECTRL
|
ソース・ライフ・サイクル |
RETENTION_IN_MINUTES |
0 - 状態からランタイム
1440 - ランタイムからヒストリー
|
0 から BIGINT に対する DB2 の制限値まで |
データ移動サービスのソース DB: WBIRMADM.RMPRUNECTRL
|
ソース・ライフ・サイクル |
PRUNE_INTERVAL (分) |
5 |
0 から BIGINT に対する DB2 の制限値まで |
データ移動サービスのソース DB: WBIRMADM.RMPRUNECTRL
|
ETL |
ETLSCHEDMETHOD |
1 |
0 - フレキシブル・スケジューリング
1 - 厳密な間隔スケジューリング
その他 - ETL 使用不可
|
データ移動サービスのターゲット DB: WBIRMADM.RMCONTROL
|
ETL |
ETL_0_MINUTES |
5 - 状態からランタイム
1440 - ランタイムからヒストリー
|
0 から INTEGER に対する DB2 の制限値まで |
データ移動サービスのターゲット DB: WBIRMADM.RMCONTROL
|
ETL |
LOGLEVEL |
0 |
0 - 通常のロギングの場合
1 - トレース・ロギングの場合
|
データ移動サービスのターゲット DB: WBIRMADM.RMCONTROL
|
ETL |
COMMITINTERVAL (レコード数) |
1000 |
0 - 終了までコミット使用不可
1 - 各レコードをコミット
n - BIGINT に対する DB2 の制限値
|
データ移動サービスのターゲット DB: WBIRMADM.RMCONTROL
|
ターゲット・ライフ・サイクル |
PRUNE_ENABLED |
1 |
0 - 使用不可
1 - 使用可能
|
データ移動サービスのターゲット DB: WBIRMADM.RMPRUNECTRL
|
ターゲット・ライフ・サイクル |
RETENTION_IN_MINUTES |
0 |
0 から BIGINT に対する DB2 の制限値まで |
データ移動サービスのターゲット DB: WBIRMADM.RMPRUNECTRL
|
ターゲット・ライフ・サイクル |
PRUNE_INTERVAL (分) |
1440 |
0 から BIGINT に対する DB2 の制限値まで |
データ移動サービスのターゲット DB: WBIRMADM.RMPRUNECTRL
|
注: IBM® は、上記で参照されるデータベース・テーブルおよび列を
変更する権利を有します。
このため、後続のリリースでは一部のテーブルおよび列の変更、除去、または追加が行われる可能性があります。リリースにより異なる場合があるとして、ここで言及した内容または構造に依存する場合は、お客様自身の責任で行ってください。IBM は、そのような変更が発生した場合はそれを文書化します。