メインフレームデータを にレプリケートするためのユースケース AWS クラウド - AWS 規範ガイダンス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

メインフレームデータを にレプリケートするためのユースケース AWS クラウド

このセクションでは、 へのメインフレームデータレプリケーションの主要な候補として浮上したいくつかの一般的なユースケースについて説明します AWS クラウド。これらのユースケースは、さまざまな業界や運用要件にまたがり、それぞれに固有の課題と機会があります。これらのシナリオでは、データレプリケーションはビジネスのイノベーション、俊敏性、回復性を推進する上で重要な役割を果たします。

ユースケース 1: データキャプチャを変更する

変更データキャプチャ (CDC) は、ほぼリアルタイムのデータレプリケーションが必要なシナリオに最適です。メインフレームから に変更したデータのみをキャプチャしてレプリケートします AWS クラウド。これにより、レプリケーションのオーバーヘッドとレイテンシーが最小限に抑えられます。

選択基準
  • リアルタイムまたはほぼリアルタイムのデータレプリケーション要件

  • レイテンシーの許容度が低い高頻度のデータ更新

  • ネットワーク帯域幅とリソースを効率的に使用する必要性

利点
  • レプリケーションのオーバーヘッドとネットワーク帯域幅使用率の削減

  • レイテンシーを最小限に抑えることで、更新されたデータをより早く利用できるようになります。

  • 変更されたデータの選択的レプリケーションによるリソースの効率的な使用

欠点
  • CDC メカニズムの実装と管理の複雑さ

  • 変更のキャプチャによるメインフレームシステムのリソース使用率の向上の可能性

  • CDC ツールとプロセスの信頼性とパフォーマンスへの依存

方針
  • メインフレームデータベースおよび と互換性のある CDC ツールを選択する AWS のサービス

  • 関連するデータ変更のみをキャプチャしてレプリケートするように CDC ツールを設定する

  • モニタリングと検証のメカニズムを実装して、データの一貫性と信頼性を維持する

  • 継続的な可用性とデータ整合性を促進するフェイルオーバーメカニズムの実装を検討する

ユースケース 2: リアルタイムレポートとダッシュボード

即時の視覚化と分析のために、リアルタイムレポートとダッシュボードには、メインフレームシステムから への継続的なデータレプリケーションが必要です AWS クラウド。このユースケースは、銀行、保険、小売、医療、製造などの意思決定にリアルタイムのインサイトが重要な業界で一般的です。

選択基準
  • 分析と視覚化のために更新されたデータにすぐにアクセスする必要がある

  • ビジネスメトリクスと主要業績評価指標 (KPIs) のリアルタイムモニタリングの要件

  • 意思決定プロセスにおける俊敏性と応答性に対する高い需要

利点
  • リアルタイムの分析と意思決定のために、更新されたデータへの即時アクセスを提供します

  • ビジネスパフォーマンスとタイムリーな介入のプロアクティブモニタリングを可能にします

  • ステークホルダーのデータの動的でインタラクティブな視覚化を促進します

欠点
  • リアルタイムの更新を実現するために、データのレプリケーションと処理が複雑化する

  • 継続的なレプリケーションによるリソース消費とインフラストラクチャコストの増加

  • データの鮮度と信頼性を検証するための堅牢なモニタリングとアラートメカニズムへの依存

方針
  • リアルタイムデータレプリケーション用の CDC またはメッセージングプロトコルを実装する

  • Amazon Kinesis Data Streams AWS のサービスなどの を使用して、リアルタイムのデータストリーミングと処理を行う

  • でリアルタイムレポートとダッシュボードソリューションを設計してデプロイ AWS クラウド し、更新されたデータにすぐにアクセスできるようにします。

  • モニタリングとアラートのメカニズムを実装して、データレプリケーションの問題を迅速に検出して対処する

ユースケース 3: メッセージングプロトコル

Apache Kafka や などのメッセージングプロトコルとシステムはIBM MQ、メインフレームと 間の非同期通信とデータ転送を容易にします AWS クラウド。分離されたスケーラブルなデータ統合を必要とするシナリオに適しています。

選択基準
  • 非同期データ転送要件

  • スケーラブルで分離されたデータ統合アーキテクチャの必要性

  • 低レイテンシーでのリアルタイムまたはほぼリアルタイムのデータレプリケーションのサポート

利点
  • 柔軟なデータ統合を可能にする、分離されたスケーラブルなアーキテクチャ

  • 低レイテンシーでのリアルタイムまたはほぼリアルタイムのデータレプリケーションのサポート

  • 信頼性、メッセージキューイング、耐障害性のための組み込み機能

欠点
  • メッセージングインフラストラクチャの設定と管理の複雑さ

  • リソースの消費量と運用オーバーヘッドが増加する可能性

  • メッセージングプラットフォームの信頼性とパフォーマンスへの依存

方針
  • メインフレームと の両方と互換性のある IBM MQApache Kafkaや などのメッセージングシステムを選択します。 AWS クラウド

  • データ転送とレプリケーションを容易にするメッセージングトピックまたはキューを設計する

  • データを交換するために、メインフレームとクラウドにメッセージプロデューサーとコンシューマーを実装する

  • モニタリングとアラートのメカニズムを設定して、メッセージ処理とレプリケーションの信頼性を検証する

ユースケース 4: 新しいチャネルとインターフェイス

メインフレームチャネルは、メインフレームコンピュータとの間でデータを移動する接続です。チャネルはチャネルサブシステムの一部です。すぐに公開して消費するには、新しいチャネルとインターフェイスにメインフレームシステムからクラウドへの継続的なデータレプリケーションが必要です。

選択基準
  • 新しいチャネルの更新データにすぐにアクセスする必要がある

  • 新しいインターフェイスを使用したメインフレームデータへのアクセス

  • 新しいチャネルの需要が高い

  • さまざまなシステム、プラットフォーム、またはクラウド環境との統合

利点
  • 新しいチャネルがメインフレームデータを消費できるようにしてメインフレームデータアクセスをロック解除する

  • さまざまなシステム、プラットフォーム、クラウド環境との統合を容易にする

  • さまざまなインフラストラクチャ間でより柔軟で効率的なデータ移動を可能にする

欠点
  • データレプリケーション用の新しいインターフェイスまたはチャネルを導入するには、データを保護し、規制に準拠するための追加のセキュリティ対策が必要になる場合があります。

  • 新しいインターフェイスを既存のシステムやワークフローと統合するのは、特に複雑な環境やレガシー環境では難しい場合があります。

方針
  • リアルタイムデータレプリケーション用の CDC またはメッセージングプロトコルを実装する

  • Kinesis Data Streams AWS のサービスなどの をリアルタイムのデータストリーミングと処理に使用する

  • モニタリングとアラートのメカニズムを実装して、データレプリケーションの問題を迅速に検出して対処する

ユースケース 5: 規制コンプライアンスとデータアーカイブ

規制コンプライアンスとデータアーカイブには、メインフレームデータをクラウドにレプリケートして長期保存することが含まれます。データ保持ポリシーと規制を遵守することが重要です。このユースケースは、銀行、医療、医薬品などの規制対象業界で一般的です。

選択基準
  • 規制コンプライアンスまたは法的要件のために履歴データの長期保存が必要

  • アーカイブされたデータの安全でスケーラブルなストレージソリューションの要件

  • データプライバシー規制およびデータ保持とアーカイブに関する業界固有の義務の遵守

利点
  • データ保持に関する規制要件と業界固有の義務の遵守

  • 履歴データの長期アーカイブのためのスケーラブルで費用対効果の高いストレージソリューション

  • 監査または法的目的でのアーカイブデータへの効率的な取得とアクセス

欠点
  • アーカイブされたデータの管理と整理が複雑で、効率的な取得とアクセスが可能

  • 大量のデータの長期保持に関連するストレージコストの増加の可能性

  • アーカイブされたデータを不正アクセスから保護するための堅牢なデータ暗号化とアクセスコントロールへの依存

方針
  • データライフサイクルポリシーを実装して、履歴データのアーカイブと保持を自動化する

  • Amazon S3 Glacier や Amazon S3 Glacier AWS ストレージクラスなどのストレージサービスを使用して、コスト効率の高い長期ストレージを実現する Amazon S3

  • 保管中のアーカイブデータを暗号化し、不正アクセスの防止に役立つアクセスコントロールを実装する

  • アーカイブされたデータへのアクセスを追跡し、規制要件に準拠する監査証跡とログ記録メカニズムを確立する

ユースケース 6: オフロード処理とバッチレプリケーション

オフロード処理とバッチレプリケーションでは、メインフレームからデータを抽出して にロードする定期的なバッチジョブをスケジュールします AWS クラウド。リアルタイムレプリケーションが不要で、バッチ処理が許容されるシナリオに適しています。

選択基準
  • リアルタイムデータレプリケーションは不要

  • バッチ処理はデータ更新に許容されます

  • レイテンシーに対する許容度が中程度のデータ更新の頻度が低い

利点
  • データ変換、圧縮、暗号化などのコンピューティング負荷の高いオペレーションをプライマリメインフレームシステムからオフロードすると、システム全体のパフォーマンスが向上し、ボトルネックが軽減されます。

  • 予測可能なリソース使用率とメインフレームシステムへの影響の軽減

  • ビジネス要件に基づいてレプリケーションジョブをスケジュールする柔軟性

欠点
  • リアルタイムまたはほぼリアルタイムのレプリケーションと比較して、データ可用性のレイテンシーが長くなる

  • 定期的な更新によるメインフレームとクラウド間のデータ不整合の可能性

  • 更新されたデータへのタイムリーなアクセスを必要とするシナリオへの適合性が限られている

方針
  • メインフレームから にデータを抽出してロードするバッチレプリケーションジョブを開発する AWS クラウド

  • ビジネス要件とデータ更新頻度に基づいてレプリケーションジョブをスケジュールする

  • チェックを実装してデータの整合性と整合性を検証する

  • レイテンシーとリソースの消費を減らすためにバッチレプリケーションプロセスを最適化することを検討する