あるデータエンジニアリングチームは、Amazon EMR クラスター上で Apache Spark を使用した日次バッチ変換ジョブを運用しています。最近、特定のジョブが通常の3倍以上の実行時間を要するようになりました。原因を特定するために、最も直接的で効果的なアプローチはどれですか？
正解： B. EMR クラスターのマスターノードで Spark History Server を参照し、完了したジョブのステージ・タスクごとの実行時間、シャッフルデータ量、GC（ガベージコレクション）時間を分析する。 Spark History Server は完了した Spark ジョブの詳細な実行メトリクスを提供する最も直接的なパフォーマンス診断ツールです。ステージ・タスクレベルの実行時間分布、シャッフル読み書き量、GC 時間を確認することで、データスキューやシャッフル過多などのボトルネックを正確に特定できます。 選択肢Aは CloudWatch の EMR メトリクスはクラスター全体のリソース状況を把握するには有効ですが、特定のジョブのどのステージで遅延が生じているかというタスクレベルの分析には不十分です。 選択肢Cは CloudTrail はAPIコール（クラスター作成・変更等）の監査ログです。ジョブのパフォーマンス内部情報（タスク実行時間、シャッフル量等）は記録されないため、今回の目的には不適切です。 選択肢Dは ブートストラップアクションログはクラスター初期化時のエラー調査に使用するものです。クラスターが正常起動した後に発生するジョブのパフォーマンス問題の特定には使用できません。