Amazon DEA-C01: データパイプラインの監視とトラブルシューティング — 学習ガイド

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

こちらの一部です： Amazon Data Engineer Associate DEA-C01 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

AWS全体でストリーミングデータとバッチデータをタイムリーかつ正確に配信するためには、データパイプラインのモニタリングとトラブルシューティングが不可欠です。この分野では、Kinesis、Firehose、Glue、DMS、Lambdaなどのサービスや、インシデント調査をサポートするAWS監査証跡に関するテレメトリ、アラート、診断技術を扱います。効果的なモニタリングは、コンシューマーの遅延、ジョブのリソース逼迫、配信レイテンシー、不正アクセスを可視化することで、平均検出時間/平均復旧時間（MTTD/MTTR）を短縮します。以下のセクションでは、本番環境のデータフローを運用および修復するための具体的なシグナル、CLI/コンソールパターン、および意思決定基準について説明します。

データサービスのためのCloudWatchメトリクスとアラーム

CloudWatchは主要なテレメトリプレーンです。主要なサービスメトリクスに対してメトリクスフィルター、ダッシュボード、アラームを作成し、アラームをSNS、EventBridge、またはSystems Managerと統合して自動修復を実現します。アラームをプログラムで作成するには aws cloudwatch put-metric-alarm を使用します。典型的なフラグには --metric-name、--namespace、--statistic (または --extended-stat)、--threshold、--evaluation-periods、--comparison-operator が含まれます。ダッシュボード用には、aws cloudwatch put-metric-data を使用して、「MyCompany/DataPipeline」のような名前空間でカスタムメトリクス（例：Glueジョブのメタデータから）をプッシュします。

以下のアクションにつながるメトリクスとパターンに注目してください：

Glue: BytesRead、BytesWritten、RecordsProcessed、DPUHrsを監視し、データ量の変化、スキュー、コストを検出します。アラーム：RecordsProcessedの急激な低下や、レコードあたりのDPUHrsの急増。
Kinesis: コンシューマーの遅延を検出するためにGetRecords.IteratorAgeMillisecondsを、ソース側の負荷を検出するためにIncomingBytes/IncomingRecordsを監視します。
Firehose: 配信レイテンシーやデータ損失を発見するためにDeliveryToS3.DataFreshnessとDeliveryToS3.Recordsを監視します。
DMS: レプリケーションの健全性を確認するためにFullLoadRows、CDCLatencyMilliseconds、AppliedChangesを監視します。

アラート設定の意思決定基準：

複合アラーム（CloudWatch composite alarms）を使用してノイズを削減します。例：IteratorAgeMilliseconds > Xが3データポイント継続、かつ、コンシューマーのエラーレート > Yを組み合わせる。
しきい値の選択には、7～14日間の履歴データからベースラインを導き出します。ワークロードに季節性がある場合は、異常検出モデル（PutAnomalyDetector）を使用して動的しきい値を設定します。

Glueジョブのモニタリングとエラーハンドリング

GlueはメトリクスをCloudWatchに出力し、ログを/aws-glue/jobs/output（ジョブ実行ログ）と/aws-glue/jobs/error（エラー）に書き込みます。CloudWatch Logs Insightsを使用してジョブの実行をクエリします。クエリはコンソールまたは aws logs start-query で実行でき、クエリ文字列の例は fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc | limit 20 のようになります。Glueジョブ実行メトリクスからBytesRead、BytesWritten、RecordsProcessed、DPUHrsを追跡します。DPUHrsはコストとジョブの並列性に直接相関します。

一般的なGlueの障害モードと修復方法：

OutOfMemory (OOM) または Executor のロスト：ワーカータイプ/DPU数を増やす、メモリ負荷が高い場合はG.2Xワーカータイプに切り替える、またはSparkのパーティショニング（repartition/coalesce）を最適化し、プッシュダウン述語を使用して入力データ量を削減する。
データスキューによるストラングラー（遅延タスク）の発生：パーティションキーを使用して再分散する、並列度を上げる、または必要に応じてGlue DynamicFrameのsplit/resolve choicesを使用する。
ジョブの停止または起動時間の長期化：ジョブブックマークを有効にし、Glue JobMetricsの「TimeWaitingForResources」を監視してキャパシティの競合を特定する。

意思決定のトレードオフ：

CPU/メモリがボトルネックで、実行時間の予測可能性が重要な場合はDPUを増やします。コストを抑制する必要がある場合は、コードの最適化（パーティショニング、必要な場合のみのキャッシュ）を優先します。
ほぼリアルタイムの変換にはGlueストリーミングを使用します。複雑なSpark変換や、スポットインスタンスに適した大規模なワークロードにはGlue ETLバッチを使用します。

KinesisとFirehoseのモニタリング

Kinesisコンシューマーの遅延：GetRecords.IteratorAgeMillisecondsを頼りに、コンシューマーがどれだけ遅れているかを検出します。IteratorAgeMillisecondsが一貫して高い場合：

シャード数を増やしてスケールする（リシャード/スケール）、または
バッチ処理、拡張ファンアウト（コンシューマーごとに最大2 MB/秒のスループット）、または改善されたチェックポイント処理を持つKinesis Client Library (KCL) v2を使用して、コンシューマーのパフォーマンスを向上させる。

シャード数を確認するには aws kinesis describe-stream を、IteratorAgeMillisecondsを取得するには aws cloudwatch get-metric-statistics を使用します。修復オプションを比較する際は、以下を考慮してください：

シャードの追加：取り込みと読み取りのスループットを向上させますが、リシャーディングと再分散が必要です。
拡張ファンアウト：共有読み取りスループットを回避しますが、コンシューマーあたりのコストが増加します。
コンシューマーの最適化：追加のシャードとコストの必要性を減らしますが、エンジニアリング工数が必要です。

Firehoseの配信メトリクス：DeliveryToS3.DataFreshnessは配信レイテンシーを定量化します。典型的な buffering_delay 設定は60～900秒で、bufferSize または bufferInterval のいずれかに達するまでレコードを保持します。DeliveryToS3.DataFreshnessが高い場合：

コンソールまたは aws firehose describe-delivery-stream を介して、Firehoseのバッファリングヒント（BufferIntervalInSeconds、BufferSizeInMBs）を確認します。
CloudWatch Errors（DeliveryToS3.RecordsFailed）とS3バケットのアクセス許可（暗号化されている場合はKMSエラー）を調査します。

Firehoseのバッファリングのセマンティクスを覚えておいてください。サービスは意図的にバッファ間隔まで遅延させます。レイテンシーを低減するにはバッファ間隔を短くしますが、その代償としてS3への書き込み頻度が増加します。

← データセキュリティ、ガバナンス、コンプライアンス · すべてのドメイン · データワークロードのコスト最適化 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →