Oracle Database@AWS でのゼロ ETL 統合の管理 - Oracle Database@AWS
ゼロ ETL 統合の変更ゼロ ETL 統合の削除ベストプラクティス

Oracle Database@AWS でのゼロ ETL 統合の管理

ゼロ ETL 統合を作成した後、統合の変更や削除など、さまざまな管理オペレーションを実行できます。このセクションでは、ゼロ ETL 統合の継続的な管理について説明します。

ゼロ ETL 統合の変更

サポートされるデータウェアハウスとのゼロ ETL 統合では、名前、説明、データフィルタリングオプションのみを変更できます。統合の暗号化に使用される AWS Key Management Service キー、ソースデータベースまたはターゲットデータベースは変更できません。

統合を変更するための前提条件

ゼロ ETL 統合を変更する前に、以下があることを確認してください。

  • 必要なアクセス許可 – IAM ユーザーまたはロールには、標準の odb:UpdateOutboundIntegration アクセス許可に加えて、AWS Glue アクセス許可が必要です。

  • アクティブ状態の統合 – 統合は CREATING、MODIFYING、DELETING または FAILED ではなく、ACTIVE 状態である必要があります。

  • 有効なデータフィルター構文 – 新しいデータフィルターは、サポートされている包含/除外パターン構文に従う必要があります。

データフィルターの変更

データフィルターを変更することで、レプリケートされるテーブルまたはスキーマを変更できます。これにより、統合全体を再作成することなく、レプリケーションからデータベースオブジェクトを追加または削除できます。

統合のデータフィルターを変更するには、modify-integration コマンドを使用します。

aws glue modify-integration \
  --integration-identifier integration-id \
  --data-filter "include: pdb1.new_schema.*"

統合名と説明を同時に変更することもできます。次の例では、pdb1 の 2 つのスキーマの統合名、説明、フィルターを変更します。

aws glue modify-integration \
  --integration-identifier integration-id \
  --data-filter "include: pdb1.schema1.*, pdb1.schema2.*" \
  --integration-name "Updated Integration Name" \
  --description "Updated integration description"
重要

データフィルターを変更すると、統合は modifying 状態になり、データの再同期を実行します。統合はレプリケーションを停止し、新しいフィルター設定を適用し、再ロードターゲットオペレーションでレプリケーションを再開します。統合ステータスをモニタリングして、変更が正常に完了したことを確認します。

ゼロ ETL 統合へのデータフィルターの変更に関する考慮事項

データフィルターを変更するときは、次の点を考慮してください。

  • 単一の PDB の制限 – 統合ごとに指定できるプラガブルデータベース (PDB) は 1 つだけです。include: pdb1.*.*, include: pdb2.*.* のようなデータフィルターはサポートされていません

  • レプリケーションの中断 – 変更プロセス中はデータレプリケーションが停止し、新しいフィルターが適用された後に再開されます。

  • データの再ロード – 統合は、新しいフィルター条件に一致するデータの完全な再ロードを実行します。

  • パフォーマンスへの影響 – データフィルターの変更が大きいと、完了までにかなりの時間がかかり、再ロード中にソースデータベースのパフォーマンスに影響を及ぼす可能性があります。

ゼロ ETL 統合設定の変更に関する制限事項

ゼロ ETL 統合を作成した後、次の設定を変更することはできません。

  • シークレット ARN – データベース認証情報を含む AWS Secrets Manager シークレット

  • KMS キー: 暗号化に使用されるカスタマーマネージドキー。

  • ソース ARN – Oracle Database@AWS VM クラスター

  • ターゲット ARN – Amazon Redshift クラスターまたは名前空間

これらの設定を変更するには、既存のゼロ ETL 統合を削除し、新しい統合を作成します。

ゼロ ETL 統合の削除

ゼロ ETL 統合が不要になった場合は、それを削除してレプリケーションを停止し、関連するリソースをクリーンアップできます。

AWS Glue を使用した削除

AWS Glue API を使用してゼロ ETL 統合を削除できます。

aws glue delete-integration \
  --integration-identifier integration-id

統合は、次の状態で削除できます。

  • アクティブ

  • needs_attention

  • 「失敗」

  • syncing

削除の影響

ゼロ ETL 統合を削除するときは、次の効果を考慮してください。

レプリケーションが停止します。

Oracle Database@AWS は、Amazon Redshift からの新しい変更をレプリケートしません。

既存のデータは保持されます。

Amazon Redshift に既にレプリケートされているデータは引き続き使用できます。

ターゲットデータベースは残ります。

統合から作成された Amazon Redshift データベースは自動的に削除されません。

重要

削除は元に戻せません。削除後にレプリケーションを再開する必要がある場合は、完全な初期ロードを実行する新しい統合を作成します。

ゼロ ETL 管理のベストプラクティス

これらのベストプラクティスに従って、ゼロ ETL 統合のパフォーマンス、セキュリティ、コスト効率を最適化します。

運用のベストプラクティス

これらの運用プラクティスは、信頼性が高く効率的なゼロ ETL 統合を維持するのに役立ちます。

定期的なモニタリング

CloudWatch アラームを設定して、統合のヘルスメトリクスとパフォーマンスメトリクスをモニタリングします。

認証情報のローテーション

データベースパスワードを定期的に更新し、AWS Secrets Manager で更新します。

バックアップの検証

Oracle データベースのバックアップにディザスタリカバリに必要なコンポーネントが含まれていることを定期的に確認します。

パフォーマンステスト

特にピーク使用期間中に、ゼロ ETL 統合が Oracle データベースのパフォーマンスに与える影響をテストします。

スキーマ変更計画

スキーマの変更を本番環境に適用する前に、開発環境で計画およびテストします。

セキュリティのベストプラクティス

これらのセキュリティ対策を実装して、ゼロ ETL 統合とデータを保護します。

最小特権アクセス

レプリケーションユーザーと AWS IAM ロールに必要最小限のアクセス許可のみを付与します。

ネットワークセキュリティ

セキュリティグループと NACL を使用して、必要なポートとソースのみにネットワークアクセスを制限します。

保管中の暗号化

Oracle データベースと Amazon Redshift クラスターの両方が保管時の暗号化を使用していることを確認します。

監査ログ

Oracle と Amazon Redshift の両方で監査ログ記録を有効にして、データアクセスと変更を追跡します。

シークレットの管理

可能な場合は AWS Secrets Manager の自動ローテーション機能を使用します。

コスト最適化

これらの戦略を適用して、効果的なゼロ ETL 統合パフォーマンスを維持しながらコストを最適化します。

データのフィルタリング

正確なデータフィルターを使用して、必要なデータのみをレプリケートし、ストレージとコンピューティングのコストを削減します。

Amazon Redshift の最適化

適切な Amazon Redshift ノードタイプを使用し、データ圧縮を実装してコストを最適化します。

使用状況のモニタリング

AWS Cost Explorer を使用して、ゼロ ETL 統合の使用状況とコストを定期的に確認します。

未使用の統合をクリーンアップする

継続的な料金を回避するために不要になった統合を削除します。