企業のモダナイゼーションイニシアチブは、数十年前のIBM MQおよびTIBCOインフラストラクチャをApache KafkaおよびAWS EventBridgeと統合することをますます要求していますが、レガシーなCOBOLメインフレームを再コーディングすることなく、特に金融サービスは、重複実行が重大なリスクおよび規制違反と見なされるため、取引コマンドの一回ずつのセマンティクスを要求します。
レガシーメッセージバスは、ネイティブのアイデポテンシープリミティブを欠き、破壊的リードを伴う命令的FIFOオーダーに依存している一方、クラウドネイティブストリームは、オフセットベースの再プレイを伴う不変ログを好みます。プロトコルインピーダンスミスマッチ（固定幅のCOBOLコピー帳と自己記述的Avro）は、異種的な配信保証と相まって、アダプタのスケーリングイベントまたは一時的なネットワークパーティション中にメッセージロスまたは重複のベクトルを生み出します。
Apache CamelまたはSpring Cloud Streamを実行するステートレスプロトコルアダプタポッドをKubernetes内で展開し、システム間の調停を行います。処理されたメッセージUUIDをTTLの有効期限付きで追跡するために、RedisまたはAmazon DynamoDBを使用してアイデポテントコンシューマパターンを実装します。原子オフセットコミットとメッセージ生産を保証するために、読み取りコミット隔離レベルでKafkaトランザクションを活用します。Prometheus経由でエクスポートされたIBM MQのキュー深度メトリックに基づいてアダプタをKEDA（Kubernetes Event-driven Autoscaling）で自動的にスケーリングします。有毒メッセージを始末行ブロッキングを防ぐためにAmazon SQSまたはApache Pulsarで実装された**デッドレターキュー（DLQ）**に隔離します。
あるトップティアの投資銀行は、ダウンタイムなしにIBM MQを実行するz/OSメインフレームからAWS MSK（Kafka）へのリアルタイム取引実行フローの移行が必要でした。レガシーシステムは、売買注文を表すCOBOLコピー帳エンコードメッセージを発行し、最新のJavaマイクロサービスはAvroシリアライズイベントを消費しました。市場の変動中、メッセージレートは50,000 TPSに急増し、初期のブリッジ実装でメッセージがドロップされる原因となりました。
解決策1: 二重書き込みと調整。 このアプローチは、メインフレームを修正してIBM MQとApache Kafkaの両方に同時に書き込み、その後に不一致を修正するための夜間調整ジョブを行います。利点には、インフラストラクチャの変更が最小限で迅速な実装タイムラインが含まれます。欠点には、取引日における一回ずつのセマンティクスの違反、調整ラグが規制監査の問題を引き起こす、手動介入が必要な競合解決が自動化SLOに違反することが含まれます。
解決策2: ストアアンドフォワードとXAトランザクション。 WebSphere MQをX/Open XAリソースマネージャーとして実装し、2フェーズコミットの境界を越えてKafkaトランザクショナルプロデューサーと調整します。利点は、原子コミットプロトコル経由で強い整合性を提供します。欠点には、クロスリージョンのレプリケーション中にWANリンクを通じてミリ秒間ロックされ、100ms未満のレイテンシSLOに違反するブロッキング動作、管理されたKafka提供物（AWS MSKなど）とのXAドライバの互換性の欠如が含まれます。
解決策3: ステートレスプロトコルブリッジと外部化された重複排除。 KubernetesデプロイメントとしてApache Camelブリッジを展開し、動的JRecordパーサーを使用してCOBOLをAvroに変換し、プロデューサーがKafkaに送信する前にDynamoDBに対してユニークなUUIDチェックを行います。KEDAは、MQSCコマンドによって報告されたキュー深度に基づいてポッドをスケーリングします。利点には、ブロッキングなしの水平方向にスケーラブルなアーキテクチャと分散トランザクションではなくアイデポテンシーによる一回ずつの処理が含まれます。欠点には、DynamoDBのキャパシティ計画とCamelルートの監視に対する運用の成熟度が必要です。
レガシーMQがメッセージの重複排除を欠いており、Kafkaのコンシューマがオフセットコミットの失敗によりメッセージを再処理できる場合、一回ずつのセマンティクスをどのように維持しますか？ 候補者はしばしばKafkaのアイデポテントプロデューサーのみを提案しますが、これはMQ-to-Kafkaの境界を超える重複排除を解決するものではありません。正しいアプローチは、ソースシステムのアウトボックスパターンを組み合わせることです―メインフレームがメッセージをそのDB2データベース内のアウトボックステーブルにトランザクション的に書き込み、次にDebeziumのようなCDC（変更データキャプチャ）コネクタが変更をKafkaにストリームします―コンシューマ側における重複排除ストア（Redis SETNXまたはDynamoDB条件付き書き込み）と共に。コンシューマは、ローカルデータベーストランザクションを使用してビジネスロジックの実行と共にUUIDをストアに原子的に書き込み、コンシューマの再バランスやパーティションの再割り当て中でもアイデポテンシーを確保します。
プロトコルアダプターブリッジを再デプロイせずにCOBOLコピー帳スキーマの進化をどのように処理しますか？ ほとんどの候補者は、各スキーマの変更のための再デプロイが必要なCOBOLコピー帳からの静的コード生成を提案します。堅牢な解決策はランタイムスキーマ解決を使用します：コピー帳の定義をGitやAWS S3に保存し、メッセージヘッダー内のバージョンIDによって参照されます。Apache Camelルートは、ヘッダー指定のスキーマバージョンに基づいてメッセージを解析するためにJRecordを使用し、Kubernetes ConfigMapまたはAWS AppConfigのホットリロードと組み合わせて、ポッドの再起動なしでスキーマを更新します。これにより、メインフレームのリリースサイクルとクラウドのデプロイパイプラインが切り離されます。
レガシーMQキューがクラウドの宛先の長期的な停止中に最大深度に達するのをどのように防ぎますか？MQには有限のストレージがあります。 候補者はしばしば無限のバッファリングまたはMQディスク拡張を提案しますが、これは単に避けられないことを遅らせるだけです。正しい戦略はバックプレッシャーとオフローディングを実装します：IBM MQ アプリケーションメッセージルーティングまたはMQIPT（MQインターネットパススルー）を設定し、キュー深度が80％を超えたときにしきい値アラームをトリガーします。ブリッジは読み取りを停止し（バックプレッシャーを適用し）、入ってきたメッセージをAmazon S3またはAzure Blob Storageにシリアライズファイルとして書き込み、接続が復元されるとサイドカーコンテナがS3オブジェクトをKafkaに再生します。（AWS SDKマルチパートアップロードを使用）、バックログを排出し、MQディスクの枯渇やメッセージロスを防ぎます。