無限ノック › DEA 練習問題一覧 › 問題DEA データオペレーションとサポート
あるデータエンジニアリングチームは、Amazon MSK（Managed Streaming for Apache Kafka）クラスターを使用したリアルタイムデータパイプラインを運用しています。
ピーク時にコンシューマーがメッセージ処理に追いつかず、データ遅延が発生することがあります。
チームはコンシューマーラグを早期に検出し、Amazon ECSで動作するコンシューマーアプリケーションを自動スケールアウトしたいと考えています。
最も適切なアプローチはどれですか？
A Amazon MSKのオープンモニタリング（Prometheus JMX Exporter）を有効にし、Amazon Managed GrafanaでKafkaコンシューマーラグのアラートとECS Auto Scalingを設定する
Prometheus+Grafanaによるモニタリングも有効ですが、セットアップが複雑で、メトリクス収集・可視化インフラの構築・運用コストが高くなります。
B Amazon CloudWatchのEstimatedMaxTimeLagメトリクスにアラームを設定し、しきい値超過時にApplication Auto ScalingによってECSサービスのタスク数を増加させる
✓ 正解
MSKはCloudWatchネイティブメトリクス（EstimatedMaxTimeLagなど）を提供でき、CloudWatchアラーム設定＋ Application Auto Scalingで追加ツール不要にシンプルに自動スケールが実現できます。
C Amazon Data FirehoseをMSKのデータソースとして設定し、Firehoseのバッファリング遅延でコンシューマーラグを間接的に検出する
Amazon Data Firehoseはデータストリーミング配信に使用でき、MSKからのデータ取り込みも可能ですが、コンシューマーラグ監視やECSスケールトリガーには利用できません。
D AWS LambdaをMSKイベントソースとして設定してメッセージを処理し、CloudWatch LogsにオフセットをログしてアラームでECSスケールを制御する
LambdaイベントソースでメッセージオフセットをCloudWatch Logsにログし、ログでアラーム検知する方式はラグ検出に時間がかかり、即時性と精度が劣り、ECSスケール統合も複雑です。
解説 MSKはEstimatedMaxTimeLag（コンシューマーラグ）などのメトリクスをCloudWatchにネイティブ提供します。CloudWatchアラームとApplication Auto Scalingを組み合わせることで、追加ツール不要でラグ検出から自動スケールまでをシンプルに実現できます。
AのPrometheus+Grafanaも有効ですが、構成が複雑でコストも高くなります。
CのAmazon Data FirehoseはMSKからのデータ取り込みには使えますが、コンシューマーラグの監視やECSスケールには利用できません。
DのLambdaによるオフセットログはラグ検出の精度と即時性に欠け、ECSスケールとの統合も複雑です。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDEAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →