DEAデータオペレーションとサポート
あるデータエンジニアリングチームは、複数のマイクロサービスからAmazon MSK(Managed Streaming for Apache Kafka)経由でAmazon S3にデータを取り込んでいます。マイクロサービスのリリースによってKafkaトピックのメッセージスキーマが変更(新フィールド追加・型変更)されることがあり、コンシューマー側のGlue ETLジョブがスキーマ不一致で失敗するインシデントが繰り返し発生しています。スキーマの進化を安全に管理し、下位互換性のない変更がデプロイされる前に検出する仕組みを構築したい。最も適切なアーキテクチャはどれですか?
AAmazon S3にJSONスキーマファイルをバージョン管理し、Glue ETLジョブ起動時にスキーマファイルを読み込んでPySparkでバリデーションを実施する
S3でのJSONスキーマ管理とPySparkバリデーションはGlue ETLジョブ内でのデータ検証には有効ですが、プロデューサーが非互換なスキーマ変更をKafkaにパブリッシュする前にブロックする仕組みがなく、スキーマ不一致インシデントの根本防止にはなりません。
BAmazon MSKのブローカーログをAmazon CloudWatch Logsに転送し、Logs Insightsクエリでメッセージサイズの異常を定期検知してスキーマ変更を推測する
MSKブローカーログのメッセージサイズ異常からスキーマ変更を推測するアプローチは、スキーマの構造的な互換性(型変更・必須フィールド削除など)を直接検証できず、検出も事後的かつ不確実です。根本的なスキーマ管理の代替にはなりません。
CAWS Glue Schema Registryにスキーマを登録して互換性モード(BACKWARD/FORWARD/FULL_ALL等)を設定し、プロデューサーとコンシューマーの双方にSchema Registry SDKを組み込む
✓ 正解
Glue Schema Registryは互換性モード(BACKWARD/FORWARD/FULL_ALL等)を設定することで、プロデューサーが非互換なスキーマを登録しようとした時点で自動的にブロックできます。MSKおよびGlue ETLの双方と統合でき、スキーマの進化を安全に管理するためのベストプラクティスです。
DAWS Glue Crawlerをスケジュール実行してKafkaトピックのデータを定期的にスキャンし、スキーマ変更を自動検出してGlue Data Catalogのテーブル定義を更新する
Glue CrawlerはS3・RDS等のデータソースのスキーマを定期スキャンするサービスであり、Kafkaトピックのライブメッセージに対してリアルタイムでスキーマ互換性を検証・ブロックする機能はありません。変更の事前防止ではなく事後検出にとどまります。
解説
AWS Glue Schema RegistryはApache Avro・JSON Schema・Protobuf形式のスキーマを一元管理するマネージドサービスです。主な機能として以下があります:
・スキーマのバージョン管理と変更履歴の保持
・互換性チェックモードの設定(BACKWARD・FORWARD・FULL・NONE等)
・プロデューサーが新スキーマを登録しようとした際に互換性違反を自動検出してブロック
・コンシューマーがメッセージ受信時にスキーマを自動解決
プロデューサー側にSDKを組み込むことで、下位互換性のないスキーマ変更がKafkaトピックにパブリッシュされる前に検出・ブロックされます。Amazon MSKとの統合もサポートされており、Glue ETLジョブとの連携も容易です。
選択肢AのS3スキーマファイル管理はバージョン管理自体は可能ですが、プロデューサーが非互換な変更をデプロイする前にブロックする仕組みがなく、インシデントの根本的な防止になりません。
選択肢BのMSKブローカーログ分析はメッセージサイズの変化を検出できますが、スキーマの構造的な互換性を検証する手段がなく、検出も事後的かつ不確実です。
選択肢DのGlue Crawlerは主にS3・RDS等のデータソースのスキーマをスキャンするサービスであり、Kafkaのライブトピックのスキーマ変更を事前にブロックする機能はありません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDEAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →