無限ノック › DEA 練習問題一覧 › 問題
DEAデータの取り込みと変換

ある金融機関は、Amazon MSKを使って複数のマイクロサービスからの取引イベントをKafkaトピックに集約しています。 送信側マイクロサービスのコード変更によって互換性のないスキーマ変更(フィールドの削除・型変更)が発生し、下流のAWS Glue Streamingジョブが繰り返し失敗するインシデントが起きています。 プロデューサーがトピックに書き込む際にスキーマの互換性を自動検証し、非互換なメッセージをプロデューサー側でブロックする仕組みを導入したい。 最も適切なアプローチはどれか。

A
AWS Glue Streamingジョブにスキーマバリデーションロジックを追加し、非互換レコードをAmazon SQSのデッドレターキューに転送する
Glue Streamingジョブ内のスキーマバリデーションはコンシューマー側での検証です。非互換メッセージはすでにKafkaトピックへの書き込みが完了しており、プロデューサー側でブロックするという要件を根本的に満たすことができません。
B
AWS Glue Schema RegistryをMSKと統合し、プロデューサーとコンシューマーにスキーマレジストリ対応のシリアライザー・デシリアライザーを設定する
✓ 正解
AWS Glue Schema Registryをプロデューサーに統合することで、メッセージ送信前にスキーマの互換性を自動検証し、非互換なメッセージをプロデューサー側でブロックできます。互換性モードの設定によりフィールド削除や型変更などの非互換変更を確実に防止できます。
C
Amazon MSKのトピック設定でメッセージサイズの上限を定義し、スキーマ変更による異常なペイロードをCloudWatchアラームで検出する
MSKのメッセージサイズ制限はスキーマの互換性検証とは無関係です。フィールドの削除や型変更はペイロードサイズに影響しないケースもあり、スキーマ非互換の構造的変化を検出する手段として機能しません。
D
AWS 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生成のオリジナル問題。

無料で演習を始める →
← DEA の問題一覧に戻る