DEAデータの取り込みと変換
ある金融機関は、Amazon MSKを使って複数のマイクロサービスからの取引イベントをKafkaトピックに集約しています。
送信側マイクロサービスのコード変更によって互換性のないスキーマ変更(フィールドの削除・型変更)が発生し、下流のAWS Glue Streamingジョブが繰り返し失敗するインシデントが起きています。
プロデューサーがトピックに書き込む際にスキーマの互換性を自動検証し、非互換なメッセージをプロデューサー側でブロックする仕組みを導入したい。
最も適切なアプローチはどれか。
AAWS Glue Streamingジョブにスキーマバリデーションロジックを追加し、非互換レコードをAmazon SQSのデッドレターキューに転送する
Glue Streamingジョブ内のスキーマバリデーションはコンシューマー側での検証です。非互換メッセージはすでにKafkaトピックへの書き込みが完了しており、プロデューサー側でブロックするという要件を根本的に満たすことができません。
BAWS Glue Schema RegistryをMSKと統合し、プロデューサーとコンシューマーにスキーマレジストリ対応のシリアライザー・デシリアライザーを設定する
✓ 正解
AWS Glue Schema Registryをプロデューサーに統合することで、メッセージ送信前にスキーマの互換性を自動検証し、非互換なメッセージをプロデューサー側でブロックできます。互換性モードの設定によりフィールド削除や型変更などの非互換変更を確実に防止できます。
CAmazon MSKのトピック設定でメッセージサイズの上限を定義し、スキーマ変更による異常なペイロードをCloudWatchアラームで検出する
MSKのメッセージサイズ制限はスキーマの互換性検証とは無関係です。フィールドの削除や型変更はペイロードサイズに影響しないケースもあり、スキーマ非互換の構造的変化を検出する手段として機能しません。
DAWS Lambda関数をMSKコンシューマーとして設定し、スキーマを検証してから下流のGlue StreamingジョブへSQSキュー経由で転送する
Lambda+SQSによるコンシューマー側のスキーマ検証は非互換メッセージを下流から守れますが、プロデューサーがKafkaトピックへの書き込みをブロックする要件は満たせません。また中間コンポーネントの追加により遅延と運用負荷が増大します。
解説
選択肢BのAWS Glue Schema Registryは、Avro・JSON Schema・Protobufのスキーマをバージョン管理し、互換性モード(BACKWARD・FORWARD・FULL等)を設定してスキーマ進化を制御できるマネージドサービスです。MSKと統合してプロデューサーアプリにGlueのシリアライザーを設定すると、メッセージ送信前にSchema Registryのスキーマと互換性を自動検証し、非互換なメッセージはプロデューサー側でブロックされます。これにより下流ジョブへの影響を根本から防げます。
選択肢AのGlue Streamingジョブ内でのバリデーションはコンシューマー側での検証であり、非互換メッセージはすでにKafkaトピックに書き込まれた後です。プロデューサー側でブロックするという要件を満たせず、下流ジョブへの影響も即座には防げません。
選択肢CのMSKのメッセージサイズ制限はスキーマの互換性検証機能ではありません。フィールドの削除や型変更はペイロードサイズに影響しないケースも多く、スキーマ非互換を検出する手段として不適切です。
選択肢DのLambda+SQS構成でコンシューマー側のスキーマ検証は可能ですが、プロデューサー側でのブロックは行えず、非互換メッセージはいったんKafkaトピックに到達してしまいます。中間レイヤー追加による遅延増大と運用コスト増加も生じます。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDEAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →