はじめに
この記事は、AWS Certified Data Engineer - Associate（DEA-C01）の学習ノートです。
Domain 3「Data Operations and Support（データ運用とサポート）」は、試験全体の**22%**を占める重要な分野です。データパイプラインを構築した後、それを「安定して動かし続ける」ための知識が問われます。
自分の学習用にまとめたものですが、同じくDEAを目指す方の参考になれば幸いです。
このドメインで学ぶこと
+------------------------------------------------------------------+
| データエンジニアリングの流れ |
+------------------------------------------------------------------+
| |
| [Domain 1] [Domain 2] [Domain 3] [Domain 4] |
| 取り込み → 保存・管理 → 運用・監視 → セキュリティ |
| 変換 分析・品質管理 |
| ↑ |
| 今回の範囲 |
+------------------------------------------------------------------+
4つのタスクステートメント
| タスク | 内容 | 重要ポイント |
|---|---|---|
| 3.1 | AWSサービスを使用したデータ処理の自動化 | オーケストレーション、スケジューリング |
| 3.2 | AWSサービスを使用したデータ分析 | SQL、可視化、データ操作 |
| 3.3 | データパイプラインの維持・監視 | ログ、メトリクス、トラブルシューティング |
| 3.4 | データ品質の確保 | 検証、プロファイリング、スキュー対策 |
タスク 3.1: AWSサービスを使用したデータ処理の自動化
なぜ自動化が必要なのか？
データパイプラインでは、同じ処理を毎日、毎時間、あるいはリアルタイムで繰り返し実行する必要があります。これを手動で行うと以下の問題が発生します：
- 人的ミス: 手順の漏れや誤操作
- スケーラビリティの限界: データ量が増えると対応できない
- 一貫性の欠如: 実行タイミングや方法がばらつく
そのため、Infrastructure as Code（IaC） とワークフローオーケストレーションを活用して、データパイプラインを自動化することが重要です。
インフラストラクチャの自動化
AWS CloudFormation
CloudFormationは、AWSリソースをテンプレートファイル（YAML/JSON） で定義し、自動的にデプロイするサービスです。
+------------------------------------------------------------------+
| CloudFormationによるパイプライン構築 |
+------------------------------------------------------------------+
| |
| テンプレートファイル (.yaml) |
| +---------------------------+ |
| | S3バケット | |
| | Lambda関数 | |
| | EventBridgeルール | |
| | Step Functionsステートマシン | |
| | SNSトピック | |
| +---------------------------+ |
| ↓ |
| CloudFormation |
| ↓ |
| +---------------------------+ |
| | 実際のAWSリソース | ← 自動的に作成・更新・削除 |
| +---------------------------+ |
+------------------------------------------------------------------+
CloudFormationを使うメリット：
- 再現性: 同じテンプレートで同じ環境を何度でも構築できる
- バージョン管理: テンプレートをGitで管理できる
- 一貫性: 開発・ステージング・本番環境を同じ構成にできる
CI/CDパイプライン（CodePipeline）
データパイプラインのコードも、アプリケーションと同様にCI/CD（継続的インテグレーション/継続的デリバリー）で管理します。
データパイプラインのオーケストレーション
「オーケストレーション」とは、複数の処理を決められた順序で、依存関係を考慮しながら実行することです。音楽のオーケストラで指揮者が各楽器の演奏を調整するように、データパイプラインでも「指揮者」が必要です。
Step Functions vs Amazon MWAA（Apache Airflow）の比較
| 観点 | Step Functions | Amazon MWAA |
|---|---|---|
| 分類 | サーバーレス | マネージドサービス |
| 定義方法 | JSON/YAML（状態機械言語） | Python（DAG定義） |
| 適したユースケース | AWSサービス連携中心 | 複雑なデータワークフロー |
| 学習コスト | 低い（視覚的エディタあり） | 高い（Airflowの知識必要） |
| 料金体系 | 状態遷移ごとに課金 | 環境の稼働時間で課金 |
| 特徴 | イベント駆動型、シンプル | コードベース、柔軟性高い |
Step Functions
Step Functionsは、ワークフローをステートマシン（状態機械） として定義します。各ステートで「何をするか」を定義し、条件分岐や並列実行も可能です。
+-------------------------------------------------------------------+
| Step Functionsのステートマシン例 |
+-------------------------------------------------------------------+
| |
| +-----------------+ |
| | ファイル受信 | |
| | (Lambda関数) | |
| +-----------------+ |
| ↓ |
| +-----------------+ |
| | ファイル種別判定 | |
| | (Choice) | |
| +-----------------+ |
| / \ |
| ↓ ↓ |
| +-------------+ +-------------+ |
| | CSV処理 | | JSON処理 | |
| | (Glueジョブ) | | (Lambda) | |
| +-------------+ +-------------+ |
| \ / |
| ↓ ↓ |
| +-----------------+ |
| | 処理完了 | |
| | (Success) | |
| +-----------------+ |
+-------------------------------------------------------------------+
Step Functionsの主要なステートタイプ：
| ステートタイプ | 用途 | 使用例 |
|---|---|---|
| Task | 実際の作業を実行 | Lambda呼び出し、Glueジョブ実行 |
| Choice | 条件分岐 | ファイル種別による処理分け |
| Parallel | 並列実行 | 複数データソースの同時処理 |
| Wait | 待機 | 一定時間後に次の処理へ |
| Fail/Succeed | 終了状態 | エラー処理、正常終了 |
Amazon MWAA（Managed Workflows for Apache Airflow）
Apache Airflowは、DAG（有向非巡回グラフ） を使ってワークフローを定義するオープンソースツールです。Amazon MWAAはこれをフルマネージドで提供します。
+------------------------------------------------------------------+
| DAGの概念図 |
+------------------------------------------------------------------+
| |
| タスクA ──→ タスクB ──→ タスクD |
| \ ↗ |
| └──→ タスクC ──┘ |
| |
| ※ 「有向」= 矢印に方向がある |
| ※ 「非巡回」= 循環しない（A→B→A のようなループがない） |
+------------------------------------------------------------------+
MWAAを使う場面：
- 既存のAirflowワークフローをAWSに移行したい
- Pythonでワークフローを柔軟に定義したい
- 複雑な依存関係を持つデータパイプラインを構築したい
MWAAのトラブルシューティング手順：
- CloudWatch Logsでエラーメッセージを確認
- Apache Airflowのログを確認
- IAMロールとアクセス許可を確認
- 依存関係とファイル参照を確認
- ワーカーノードのリソースをモニタリング
- ローカル環境でDAGをテスト
イベントとスケジューラの管理
データパイプラインは、時間ベースまたはイベントベースで起動します。
Amazon EventBridge
EventBridgeは、AWSサービスやSaaSアプリケーションからのイベントを検知し、適切なターゲットにルーティングするサービスです。
+--------------------------------------------------------------------+
| EventBridgeの動作イメージ |
+--------------------------------------------------------------------+
| |
| イベントソース EventBridge ターゲット |
| +----------+ +-----------+ +--------+ |
| | S3 | ──イベント──→ | | ──ルール──→ | Lambda | |
| +----------+ | | +--------+ |
| +----------+ | ルール | +--------+ |
| | CloudTrail| ──イベント──→ | 評価 | ──ルール──→ | Step | |
| +----------+ | | |Functions| |
| +----------+ | | +--------+ |
| |スケジュール| ──cron式──→ | | ──ルール──→ | Glue | |
| +----------+ +-----------+ +--------+ |
+--------------------------------------------------------------------+
EventBridgeの主要機能：
| 機能 | 説明 | 使用例 |
|---|---|---|
| イベントルール | イベントパターンに基づくルーティング | S3への新規ファイル到着時にLambdaを起動 |
| スケジュールルール | cron式や固定間隔での実行 | 毎日午前3時にETLジョブを実行 |
| イベントバス | イベントの集約・配信 | 複数アカウントからのイベント統合 |
スケジュール式の例：
# 毎日午前9時（UTC）に実行
cron(0 9 * * ? *)
# 5分ごとに実行
rate(5 minutes)
# 毎週月曜日の午前6時に実行
cron(0 6 ? * MON *)
AWS SDKとスクリプティング
AWSサービスをプログラムから操作するために、SDKやスクリプトを活用します。
AWS SDK
AWS SDKは、複数のプログラミング言語（Python、Java、JavaScript等）で利用でき、アプリケーションコードからAWSサービスを操作できます。
SDKの主な機能：
- 認証とリクエストの署名を自動処理
- レスポンスの解析
- リトライロジックの組み込み
- エラーハンドリング
Python（Boto3）の例：
import boto3
# S3クライアントの作成
s3 = boto3.client('s3')
# ファイルのアップロード
s3.upload_file('local_file.csv', 'my-bucket', 'data/file.csv')
# Glueジョブの起動
glue = boto3.client('glue')
response = glue.start_job_run(JobName='my-etl-job')
print(f"Job Run ID: {response['JobRunId']}")
スクリプトを受け付けるサービス
| サービス | スクリプト言語 | 用途 | 特徴 |
|---|---|---|---|
| Amazon EMR | Python, Scala, SQL | Spark/Hadoopジョブ | 大規模分散処理 |
| Amazon Redshift | SQL, Python（UDF） | データ変換、ストアドプロシージャ | DWH内処理 |
| AWS Glue | Python, Scala | ETLスクリプト | サーバーレスETL |
| Lambda | Python, Node.js, Java等 | イベント駆動処理 | サーバーレス |
Redshift ストアドプロシージャの例：
CREATE OR REPLACE PROCEDURE update_daily_summary()
AS $$
BEGIN
-- 日次サマリーテーブルを更新
DELETE FROM daily_summary WHERE date = CURRENT_DATE;
INSERT INTO daily_summary
SELECT CURRENT_DATE, category, SUM(amount)
FROM transactions
WHERE transaction_date = CURRENT_DATE
GROUP BY category;
END;
$$ LANGUAGE plpgsql;
-- スケジュール実行（クエリエディタv2で設定可能）
CALL update_daily_summary();
EMR Sparkジョブの例：
from pyspark.sql import SparkSession
spark = SparkSession.builder.appName("ETL Job").getOrCreate()
# S3からデータ読み込み
df = spark.read.parquet("s3://bucket/input/")
# 変換処理
df_transformed = df.filter(df.status == "active") \
.groupBy("category") \
.agg({"amount": "sum"})
# S3へ出力
df_transformed.write.parquet("s3://bucket/output/")
データAPIの管理
外部システムとデータをやり取りする際、APIを通じたデータの取得・送信が必要になります。
API Gateway + Lambda の構成
API管理のベストプラクティス：
| カテゴリ | ベストプラクティス | 使用サービス |
|---|---|---|
| モニタリング | リクエスト数、レイテンシー、エラー率の監視 | CloudWatch |
| スケーリング | 負荷に応じた自動スケーリング | Lambda、API Gateway |
| キャッシュ | 頻繁なリクエストのキャッシュ | API Gatewayキャッシュ、ElastiCache |
| レート制限 | 不正利用防止、リソース保護 | API Gatewayスロットリング |
| 認証 | APIアクセスの保護 | IAM、OAuth、Cognito |
| バージョニング | 後方互換性の維持 | API Gatewayステージ |
タスク 3.2: AWSサービスを使用したデータ分析
データ操作オペレーション
データ分析では、生データを意味のある情報に変換するための様々な操作が必要です。
主要なデータ操作
| 操作 | 説明 | 用途 | AWSサービス |
|---|---|---|---|
| 集約（Aggregation） | 複数レコードを単一の値に集約 | 合計、平均、件数の算出 | Redshift, Athena, OpenSearch |
| 移動平均（Moving Average） | 特定ウィンドウ内の値の平均を計算 | トレンド分析、異常検知 | Redshift, QuickSight |
| グループ化（Grouping） | 特定の属性でデータをまとめる | カテゴリ別集計 | Redshift, Athena, QuickSight |
| ピボット（Pivot） | 行を列に変換 | レポート用データ整形 | Redshift, QuickSight |
SQL集約関数の例
-- 基本的な集約
SELECT
category,
COUNT(*) as total_count,
SUM(amount) as total_amount,
AVG(amount) as avg_amount
FROM sales
GROUP BY category;
-- 移動平均（Redshift）
SELECT
date,
amount,
AVG(amount) OVER (
ORDER BY date
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
) as moving_avg_7days
FROM daily_sales;
-- ピボット（Redshift）
SELECT *
FROM (SELECT year, quarter, revenue FROM quarterly_sales)
PIVOT (SUM(revenue) FOR quarter IN ('Q1', 'Q2', 'Q3', 'Q4'));
データ分析に使用するAWSサービス
サービス比較マップ
+------------------------------------------------------------------+
| データ分析サービスの位置づけ |
+------------------------------------------------------------------+
| |
| インタラクティブ ←────────────────→ バッチ処理 |
| |
| +-------------+ +-------------+ +-------------+ |
| | QuickSight | | Athena | | Redshift | |
| | (可視化) | | (アドホック) | | (DWH) | |
| +-------------+ +-------------+ +-------------+ |
| |
| サーバーレス ←────────────────→ プロビジョンド |
| |
| +-------------+ +-------------+ +-------------+ |
| | Athena | | Redshift | | EMR | |
| | Lambda | | Serverless | | (クラスター) | |
| +-------------+ +-------------+ +-------------+ |
+------------------------------------------------------------------+
Amazon Athena
Athenaは、S3に保存されたデータに対してSQLで直接クエリを実行できるサーバーレスサービスです。
Athenaの特徴：
- サーバーレス: インフラ管理不要
- 従量課金: スキャンしたデータ量に応じた課金
- 即座に開始: セットアップなしでクエリ実行可能
Athenaが適しているユースケース：
- アドホック分析（その場限りの調査）
- S3データレイクの探索
- CloudTrailログの分析
- コスト削減が重要な場合
Athenaでのデータ分析例：
-- CloudTrailログからAPI呼び出しを分析
SELECT
eventsource,
eventname,
COUNT(*) as call_count
FROM cloudtrail_logs
WHERE eventtime >= '2024-01-01'
GROUP BY eventsource, eventname
ORDER BY call_count DESC
LIMIT 20;
Athenaビューの作成：
ビューは、複雑なクエリを簡略化し、データへのアクセスを制御するために使用します。
-- ビューの作成
CREATE OR REPLACE VIEW daily_sales_summary AS
SELECT
DATE(order_date) as sale_date,
product_category,
SUM(amount) as total_sales,
COUNT(*) as order_count
FROM orders
WHERE status = 'completed'
GROUP BY DATE(order_date), product_category;
-- ビューの使用
SELECT * FROM daily_sales_summary
WHERE sale_date >= DATE '2024-01-01';
ビューのユースケース：
| ユースケース | 説明 | 例 |
|---|---|---|
| 複雑なクエリの簡略化 | 頻繁に使うクエリを保存 | 集計ロジックのカプセル化 |
| データアクセス制御 | 特定カラムのみ公開 | 機密情報の非表示 |
| スキーマ変更の抽象化 | 基盤テーブル変更の影響を軽減 | カラム名変更の吸収 |
| QuickSight連携 | データソースとして利用 | ダッシュボード用データ準備 |
Athena + Sparkノートブック：
AthenaではApache Sparkを使ったノートブック環境も利用でき、より複雑なデータ探索が可能です。
Amazon QuickSight
QuickSightは、ビジネスインテリジェンス（BI） サービスで、インタラクティブなダッシュボードを作成できます。
+------------------------------------------------------------------+
| QuickSightのアーキテクチャ |
+------------------------------------------------------------------+
| |
| データソース SPICE ダッシュボード |
| +----------+ +--------+ +------------+ |
| | Athena |──────────→ | |──────────→ | | |
| +----------+ |インメモリ| | グラフ | |
| +----------+ |キャッシュ| | テーブル | |
| | Redshift |──────────→ | |──────────→ | フィルター | |
| +----------+ +--------+ +------------+ |
| +----------+ ↑ |
| | S3 |────────────────┘ |
| +----------+ 定期更新 |
+------------------------------------------------------------------+
SPICE（Super-fast, Parallel, In-memory Calculation Engine）：
- インメモリでデータを保持し、高速なクエリを実現
- データソースへの負荷を軽減
- 定期的にデータを更新（スケジュール設定可能）
QuickSightの使い分け：
| モード | 特徴 | 適したユースケース |
|---|---|---|
| SPICE | 高速、定期更新 | 日次レポート、コスト効率重視 |
| Direct Query | リアルタイム、常に最新 | リアルタイムダッシュボード |
Amazon OpenSearch Service
OpenSearchは、全文検索とリアルタイム分析に特化したサービスです。
OpenSearchが適しているユースケース：
- ログ分析とモニタリング
- 全文検索機能の実装
- リアルタイムダッシュボード（OpenSearch Dashboards）
- 時系列データの分析
AthenaとOpenSearchの使い分け：
| 観点 | Athena | OpenSearch |
|---|---|---|
| データ形式 | 構造化データ中心 | 非構造化・半構造化も得意 |
| クエリ言語 | SQL | DSL（ドメイン固有言語）、SQL |
| 検索タイプ | テーブルスキャン | 全文検索、転置インデックス |
| リアルタイム性 | バッチ向き | リアルタイム向き |
| 用途 | データレイク分析 | ログ分析、検索エンジン |
SQLクエリの実行環境
AWSには様々なSQLクエリ実行環境があります。
| サービス | 特徴 | SQLの種類 |
|---|---|---|
| Amazon RDS/Aurora | リレーショナルDB | 標準SQL |
| Amazon Redshift | データウェアハウス | PostgreSQL互換 |
| Amazon Athena | S3上のデータ | Presto/Trino |
| Amazon DynamoDB | NoSQL | PartiQL（SQL互換） |
| Amazon DocumentDB | ドキュメントDB | SQLライクなクエリ |
| AWS Glue | ETL処理 | Spark SQL |
PartiQL（DynamoDB）：
-- DynamoDBテーブルへのクエリ
SELECT * FROM Users WHERE userId = '12345';
-- 条件付き更新
UPDATE Users SET status = 'active' WHERE userId = '12345';
データの検証とクリーンアップ
分析結果の信頼性を確保するため、データの検証とクリーンアップが重要です。
| ツール | 用途 | 特徴 |
|---|---|---|
| Lambda | カスタムデータ検証 | 柔軟性、イベント駆動 |
| Athena | SQLベースの検証 | 大規模データ |
| QuickSight | 可視化による異常発見 | 直感的 |
| Jupyter Notebooks | 探索的データ分析 | 対話的 |
| SageMaker Data Wrangler | ML前処理 | GUI、自動化 |
データクレンジング技法
データクレンジングは、データパイプラインのどの段階で実施するかが重要です。
+------------------------------------------------------------------+
| データクレンジングの実施タイミング |
+------------------------------------------------------------------+
| |
| 取り込み時 変換時 ロード前 分析時 |
| +----------+ +--------+ +--------+ +--------+ |
| |スキーマ | |正規化 | |重複排除 | |フィルタ | |
| |検証 | |型変換 | |整合性 | |異常値 | |
| |フォーマット| |欠損値処理| |チェック | |除外 | |
| +----------+ +--------+ +--------+ +--------+ |
| ↓ ↓ ↓ ↓ |
| 早期発見 一括処理 品質保証 必要に応じて |
+------------------------------------------------------------------+
主要なクレンジング技法：
| 技法 | 説明 | 実装例 |
|---|---|---|
| 欠損値処理 | NULL/空値の対処 | デフォルト値設定、削除、補間 |
| 重複排除 | 重複レコードの除去 | DISTINCT、GROUP BY、FindMatches |
| 型変換 | データ型の統一 | 文字列→日付、数値型変換 |
| 正規化 | 値の標準化 | 大文字/小文字統一、スペース除去 |
| 外れ値処理 | 異常値の検出・対処 | 統計的手法、ドメイン知識 |
| フォーマット統一 | 形式の標準化 | 日付形式、電話番号形式 |
AWSサービスでのクレンジング実装：
-- Athena/Redshiftでの欠損値処理
SELECT
customer_id,
COALESCE(email, 'unknown@example.com') as email, -- NULL置換
NULLIF(phone, '') as phone, -- 空文字をNULLに
CASE
WHEN age < 0 OR age > 150 THEN NULL -- 異常値をNULLに
ELSE age
END as age
FROM customers;
-- 重複排除
SELECT DISTINCT *
FROM (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY updated_at DESC) as rn
FROM customers
) WHERE rn = 1;
AWS Glue DataBrewでのクレンジング：
- ノーコードで変換レシピを作成
- 250以上の組み込み変換機能
- プロファイリングによる品質問題の自動検出
タスク 3.3: データパイプラインの維持・監視
なぜ監視が重要なのか？
データパイプラインは、一度構築したら終わりではありません。以下のような問題が発生する可能性があります：
- パフォーマンス低下: データ量増加による処理時間の延長
- 障害発生: ネットワーク障害、サービス障害
- データ品質問題: 入力データの異常
- リソース不足: メモリ、CPU、ストレージの枯渇
これらを早期に検知し、対処するために監視が不可欠です。
オブザーバビリティの3本柱
+------------------------------------------------------------------+
| オブザーバビリティの3本柱 |
+------------------------------------------------------------------+
| |
| メトリクス ログ トレース |
| +----------+ +----------+ +----------+ |
| | 数値データ | | イベント | | リクエスト | |
| | CPU使用率 | | 記録 | | の流れ | |
| | レイテンシ | | エラー詳細| | 各サービス | |
| | スループット| | 処理内容 | | の関連 | |
| +----------+ +----------+ +----------+ |
| ↓ ↓ ↓ |
| CloudWatch CloudWatch X-Ray |
| Metrics Logs |
+------------------------------------------------------------------+
Amazon CloudWatch
CloudWatchは、AWSリソースとアプリケーションの監視サービスです。
CloudWatch Metrics（メトリクス）
+------------------------------------------------------------------+
| 主要なメトリクスカテゴリ |
+------------------------------------------------------------------+
| |
| システムメトリクス アプリケーションメトリクス |
| +------------------+ +------------------+ |
| | CPU使用率 | | リクエスト数 | |
| | メモリ使用量 | | エラー率 | |
| | ディスクI/O | | レイテンシー | |
| | ネットワーク帯域 | | スループット | |
| +------------------+ +------------------+ |
| |
| データパイプライン固有メトリクス |
| +--------------------------------------------------+ |
| | Glue: DPU使用率、ジョブ実行時間 | |
| | Kinesis: IteratorAgeMilliseconds、IncomingRecords| |
| | DMS: CDCLatencySource、CDCLatencyTarget | |
| | Redshift: クエリキュー長、ディスク使用率 | |
| +--------------------------------------------------+ |
+------------------------------------------------------------------+
重要なメトリクス一覧：
| サービス | メトリクス名 | 意味 | 対処法 |
|---|---|---|---|
| Kinesis | IteratorAgeMilliseconds | コンシューマーの処理遅延 | シャード追加、並列化 |
| Kinesis | WriteProvisionedThroughputExceeded | 書き込みスロットリング | シャード追加 |
| DMS | CDCLatencySource | ソース側のレプリケーション遅延 | ソースDB確認 |
| DMS | CDCLatencyTarget | ターゲット側の遅延 | ターゲット容量確認 |
| Glue | glue.driver.aggregate.numActiveExecutors | アクティブなエグゼキュータ数 | DPU調整 |
CloudWatch Logs
ログは、アプリケーションの動作を詳細に記録します。
ログの階層構造：
ロググループ（アプリケーション単位）
└── ログストリーム（インスタンス単位）
└── ログイベント（個々のログエントリ）
CloudWatch Logs Insights：
CloudWatch Logsに対してSQLライクなクエリを実行できます。
-- エラーログの検索
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 100
-- Lambda関数の実行時間分析
filter @type = "REPORT"
| stats avg(@duration), max(@duration), min(@duration) by bin(1h)
CloudWatch Logsの設定と自動化：
+------------------------------------------------------------------+
| CloudWatch Logs の構成オプション |
+------------------------------------------------------------------+
| |
| サブスクリプションフィルター |
| +------------------+ +------------------+ |
| | ログストリーム | --> | フィルターパターン | --> Lambda/ |
| | | | | Kinesis/ |
| | | | | Firehose |
| +------------------+ +------------------+ |
| |
| メトリクスフィルター |
| +------------------+ +------------------+ |
| | ログイベント | --> | パターンマッチ | --> CloudWatch |
| | | | | メトリクス |
| +------------------+ +------------------+ |
+------------------------------------------------------------------+
| 機能 | 用途 | 設定例 |
|---|---|---|
| サブスクリプションフィルター | ログをリアルタイムで他サービスへ転送 | エラーログをLambdaで処理してSlack通知 |
| メトリクスフィルター | ログからカスタムメトリクスを生成 | エラー発生回数をメトリクス化 |
| 保持期間設定 | ログの保存期間を管理 | 1日〜10年、または無期限 |
| エクスポート | S3への一括エクスポート | 長期保存、Athenaでの分析 |
ログの自動化パターン：
CloudWatch Alarms
メトリクスが閾値を超えた場合にアラートを発報します。
AWS CloudTrail
CloudTrailは、AWSアカウントで行われた全てのAPI呼び出しを記録します。
CloudTrailの用途：
- セキュリティ監査: 誰がいつ何をしたかの記録
- コンプライアンス: 規制要件への対応
- トラブルシューティング: 操作履歴の確認
CloudTrail Lake：
CloudTrail Lakeは、CloudTrailのイベントをSQLで直接クエリできる機能です。
-- 過去7日間のS3バケット作成イベント
SELECT eventTime, userIdentity.userName, requestParameters
FROM cloudtrail_events
WHERE eventName = 'CreateBucket'
AND eventTime > date_sub(current_date, 7)
CloudTrail Lake vs 証跡+Athena の比較：
| 観点 | CloudTrail Lake | 証跡+Athena |
|---|---|---|
| セットアップ | 簡単 | 設定が必要 |
| クエリ | SQLのみ | SQL |
| QuickSight連携 | 不可 | 可能 |
| コスト | 取り込み+クエリ | S3保存+クエリ |
| 用途 | セキュリティ調査 | 長期分析・可視化 |
トラブルシューティングのベストプラクティス
体系的アプローチ
+------------------------------------------------------------------+
| トラブルシューティングの手順 |
+------------------------------------------------------------------+
| |
| 1. AWS Health Dashboard確認 |
| └── AWSサービス自体の障害有無 |
| ↓ |
| 2. CloudWatchメトリクス確認 |
| └── ベースラインとの比較、異常値の特定 |
| ↓ |
| 3. ログ分析 |
| └── エラーメッセージ、例外、警告の確認 |
| ↓ |
| 4. サービス固有のログ確認 |
| └── Lambda、RDS、Glue等の個別ログ |
| ↓ |
| 5. 根本原因の特定と対策 |
+------------------------------------------------------------------+
サービス別トラブルシューティング
Kinesis Data Streams：
| 問題 | 考えられる原因 | 対処法 |
|---|---|---|
| 書き込み失敗 | スロットリング | シャード追加、再試行ロジック |
| 処理遅延 | コンシューマー性能不足 | 並列化係数増加、拡張ファンアウト |
| ホットシャード | パーティションキーの偏り | キー設計見直し |
AWS Glue：
| 問題 | 考えられる原因 | 対処法 |
|---|---|---|
| ジョブ失敗 | メモリ不足 | DPU増加、データ分割 |
| 実行時間長い | 非効率なコード | パーティション活用、フィルタ最適化 |
| ResourceNumberLimitExceededException | テーブルバージョン超過 | 古いバージョン削除 |
Amazon Redshift：
| 問題 | 考えられる原因 | 対処法 |
|---|---|---|
| クエリ遅延 | ワークロード管理 | WLMキュー設定調整 |
| ディスクフル | データ増加 | VACUUM、古いデータ削除 |
| ロック競合 | 同時更新 | トランザクション見直し |
Amazon Kinesis Data Firehose：
| 問題 | 考えられる原因 | 対処法 |
|---|---|---|
| 配信遅延 | バッファ設定 | バッファサイズ/間隔の調整 |
| データ欠損 | 変換エラー | Lambda変換のエラーハンドリング確認 |
| S3配信失敗 | IAM権限不足 | ロールのS3書き込み権限確認 |
| フォーマットエラー | スキーマ不一致 | データ形式の検証、変換ロジック修正 |
+------------------------------------------------------------------+
| Firehose トラブルシューティングフロー |
+------------------------------------------------------------------+
| |
| 1. CloudWatchメトリクス確認 |
| └── DeliveryToS3.Success、IncomingRecords |
| ↓ |
| 2. エラーログ確認 |
| └── S3のエラープレフィックス配下を確認 |
| ↓ |
| 3. バッファ設定の見直し |
| └── サイズ: 1-128 MB、間隔: 60-900秒 |
| ↓ |
| 4. Lambda変換のテスト |
| └── サンプルデータでの変換確認 |
+------------------------------------------------------------------+
Amazon Managed Service for Apache Flink（旧Kinesis Data Analytics）：
| 問題 | 考えられる原因 | 対処法 |
|---|---|---|
| アプリケーション停止 | リソース不足 | KPU（Kinesis Processing Unit）増加 |
| 処理遅延 | チェックポイント | チェックポイント間隔の調整 |
| データ損失 | 並列度設定 | 適切な並列度の設定 |
| 入力エラー | スキーマ不一致 | 入力スキーマの定義確認 |
Flink重要メトリクス：
| メトリクス | 意味 | 対処法 |
|---|---|---|
| downtime | アプリケーションダウン時間 | エラーログ確認、再起動 |
| fullRestarts | 完全再起動回数 | チェックポイント設定確認 |
| lastCheckpointDuration | チェックポイント所要時間 | 状態サイズ最適化 |
| currentInputWatermark | ウォーターマーク遅延 | イベントタイム処理の確認 |
パフォーマンスチューニングのベストプラクティス
データパイプラインのパフォーマンスを最適化するための主要なアプローチを解説します。
+------------------------------------------------------------------+
| パフォーマンスチューニングの観点 |
+------------------------------------------------------------------+
| |
| コンピューティング ストレージ ネットワーク |
| +-------------+ +-------------+ +-------------+ |
| | DPU調整 | | フォーマット | | 圧縮 | |
| | 並列度 | | パーティション| | リージョン | |
| | インスタンス | | インデックス | | 帯域 | |
| +-------------+ +-------------+ +-------------+ |
+------------------------------------------------------------------+
サービス別チューニングポイント：
| サービス | チューニング項目 | ベストプラクティス |
|---|---|---|
| Athena | クエリコスト | Parquet/ORC形式、パーティション活用、LIMIT句 |
| Athena | クエリ速度 | プロビジョンド容量、ワークグループ分離 |
| Glue | ジョブ実行時間 | DPU数調整、プッシュダウン述語、ブックマーク |
| Redshift | クエリ性能 | ソートキー、分散キー、VACUUM/ANALYZE |
| Kinesis | スループット | シャード数、バッチサイズ、拡張ファンアウト |
| EMR | クラスター効率 | インスタンスタイプ、スポットインスタンス、HDFS最適化 |
Athenaのプロビジョンド容量：
クエリのキューイング問題を解決するため、専用のコンピューティングリソースを確保します。
| 容量タイプ | 特徴 | ユースケース |
|---|---|---|
| オンデマンド | 従量課金、共有リソース | アドホッククエリ |
| プロビジョンド | 予約容量、優先実行 | 本番ワークロード、SLA要件 |
Glue DPUの最適化：
+------------------------------------------------------------------+
| Glue DPU設定の目安 |
+------------------------------------------------------------------+
| |
| データサイズ 推奨DPU 備考 |
| +-------------+ +-------+ +----------------------+ |
| | 〜10GB | | 2-10 | | 小規模、テスト用 | |
| | 10-100GB | | 10-50 | | 中規模バッチ | |
| | 100GB〜 | | 50+ | | 大規模処理、監視必須 | |
| +-------------+ +-------+ +----------------------+ |
| |
| ※ ジョブ実行モニタリングでDPU使用状況を確認し調整 |
+------------------------------------------------------------------+
ログ分析サービスの活用
CloudWatch Logs以外にも、EMRやOpenSearchを活用したログ分析が可能です。
ログ分析サービスの比較：
| サービス | 適したユースケース | 特徴 |
|---|---|---|
| CloudWatch Logs Insights | リアルタイム、シンプルなクエリ | サーバーレス、即座に利用可能 |
| Amazon OpenSearch | 全文検索、ダッシュボード | リッチな可視化、Kibana互換 |
| Amazon EMR + Spark | 大規模バッチ分析 | カスタムロジック、機械学習 |
| Amazon Athena | S3ログの構造化分析 | SQL、コスト効率 |
OpenSearchによるログ分析アーキテクチャ：
+------------------------------------------------------------------+
| OpenSearchログ分析パイプライン |
+------------------------------------------------------------------+
| |
| ログソース Firehose OpenSearch |
| +----------+ +--------+ +----------+ |
| |CloudWatch| --> |変換 | --> |インデックス| |
| |Logs | |バッファ | |作成 | |
| +----------+ +--------+ +----------+ |
| +--------+ ↓ |
| |アプリ | -------------------------→ +------------+ |
| |ログ | 直接取り込み | Dashboards | |
| +--------+ | (可視化) | |
| +------------+ |
+------------------------------------------------------------------+
その他の監視・セキュリティサービス
| サービス | 用途 | 特徴 |
|---|---|---|
| AWS X-Ray | 分散トレーシング | マイクロサービス |
| Amazon Macie | S3の機密データ検出 | セキュリティ |
| AWS Config | 設定変更の追跡 | コンプライアンス |
| VPC Flow Logs | ネットワークトラフィック監視 | セキュリティ |
| AWS Security Hub | セキュリティ統合ダッシュボード | 一元管理 |
タスク 3.4: データ品質の確保
データ品質の重要性
データ品質が低いと、以下の問題が発生します：
- 誤った意思決定: 不正確なデータに基づく判断
- 信頼性の喪失: ユーザーからの信頼低下
- コスト増大: データ修正にかかる時間とリソース
- コンプライアンス違反: 規制要件への不適合
「質の悪いデータを公開するくらいなら、公開しない方がまし」
データ検証の4つの観点
+------------------------------------------------------------------+
| データ品質の4つの観点 |
+------------------------------------------------------------------+
| |
| 完全性（Completeness） 一貫性（Consistency） |
| +------------------+ +------------------+ |
| | 欠損値がないか | | ルールに沿っているか | |
| | NULL値の有無 | | 形式の統一 | |
| | 必須フィールド | | データ間の整合性 | |
| +------------------+ +------------------+ |
| |
| 正確性（Accuracy） 整合性（Integrity） |
| +------------------+ +------------------------+ |
| | 値が正しいか | | ライフサイクル全体で | |
| | 範囲内か | | データが変更されていないか | |
| | 実態と一致するか | | 参照整合性 | |
| +------------------+ +------------------------+ |
+------------------------------------------------------------------+
データプロファイリング
データプロファイリングとは、データの特性を分析・調査して、構造、内容、品質に関するインサイトを得るプロセスです。
プロファイリングで確認する項目：
| 項目 | 説明 | 例 |
|---|---|---|
| カーディナリティ | ユニークな値の数 | 顧客ID：100万件 |
| NULL率 | NULL値の割合 | メールアドレス：5%がNULL |
| 分布 | 値の分布状況 | 年齢：20-30代が60% |
| パターン | データのフォーマット | 電話番号：XXX-XXXX-XXXX |
| 統計量 | 最小、最大、平均、中央値 | 売上：平均5,000円 |
データプロファイリングに使用するサービス：
| サービス | 特徴 | 適したユースケース |
|---|---|---|
| AWS Glue DataBrew | ノーコード、自動プロファイル | 迅速な分析 |
| Athena | SQLベース | 大規模データ |
| Amazon Redshift | DWH統合 | 既存Redshift環境 |
| Amazon EMR + Spark | カスタムスクリプト | 高度な分析 |
AWS Glue Data Quality
AWS Glue Data Qualityは、データ品質ルールを定義・実行するための機能です。
定義できるルールの例：
| ルールタイプ | 説明 | 例 |
|---|---|---|
| 完全性ルール | 欠損値・NULL値のチェック | ColumnValues "email" != NULL |
| 一意性ルール | 重複のチェック | IsUnique "customer_id" |
| 範囲ルール | 値の範囲チェック | ColumnValues "age" between 0 and 150 |
| 書式ルール | フォーマットチェック | ColumnValues "email" matches ".@." |
| 参照整合性 | 別テーブルとの整合性 | ReferentialIntegrity "orders.customer_id" = "customers.id" |
AWS Glue DataBrew
DataBrewは、ノーコードでデータの準備・クリーンアップができるビジュアルツールです。
+------------------------------------------------------------------+
| DataBrewのワークフロー |
+------------------------------------------------------------------+
| |
| 1. データセット作成 |
| └── S3、Redshift、Glue Data Catalog等からデータ読み込み |
| ↓ |
| 2. プロファイル作成 |
| └── データの統計情報を自動生成 |
| ↓ |
| 3. レシピ作成 |
| └── 変換ステップをビジュアルに定義 |
| ↓ |
| 4. ジョブ実行 |
| └── 変換を実行し結果を出力 |
+------------------------------------------------------------------+
DataBrewでできること：
- 空のフィールドの検出と置換
- データ型の変換
- 重複の削除
- カラムのマージ・分割
- 条件付き変換
データサンプリング
大規模データセットを全て処理するのは時間とコストがかかるため、サンプリングが有効です。
サンプリング手法：
| 手法 | 説明 | 用途 |
|---|---|---|
| ランダムサンプリング | 無作為に抽出 | 一般的な分析 |
| 層別サンプリング | グループごとに抽出 | 偏りを防ぐ |
| 系統的サンプリング | 一定間隔で抽出 | 時系列データ |
AWSでのサンプリング方法：
| サービス | 方法 |
|---|---|
| Amazon S3 Select | SQLライクなクエリでサブセット抽出 |
| Athena | TABLESAMPLE句、LIMIT句 |
| Redshift | LIMIT句、SAMPLE関数 |
| EMR + Spark | sample()メソッド |
| DataBrew | サンプリング変換 |
-- AthenaでのサンプリングSQL例
SELECT * FROM large_table
TABLESAMPLE BERNOULLI(10) -- 10%のランダムサンプル
-- または
SELECT * FROM large_table
LIMIT 10000; -- 最初の10,000行
データスキューへの対処
データスキューとは、パーティションやノード間でデータ分布が不均衡な状態です。これが発生すると、一部のノードに負荷が集中し、全体のパフォーマンスが低下します。
+-------------------------------------------------------------------+
| データスキューの例 |
+-------------------------------------------------------------------+
| |
| 理想的な分布 スキューした分布 |
| +----+----+----+----+ +----+----+----+----+ |
| | | | | | | | | | | |
| | | | | | | | | |####| |
| |####|####|####|####| | | |####|####| |
| |####|####|####|####| |# |## |####|####| |
| +----+----+----+----+ +----+----+----+----+ |
| Node1 Node2 Node3 Node4 Node1 Node2 Node3 Node4 |
| ↑ |
| 負荷集中！ |
+-------------------------------------------------------------------+
スキュー対策：
| 対策 | 説明 | 実装方法 |
|---|---|---|
| パーティションキー設計 | 均等に分散するキー選択 | ハッシュ関数の活用 |
| ソルティング | キーにランダム値を追加 | key + random_suffix |
| 再パーティション | 処理中にデータを再分配 | Spark repartition() |
| ブロードキャスト結合 | 小さいテーブルを全ノードに配布 | Spark broadcast() |
パーティショニング戦略：
+------------------------------------------------------------------+
| S3パーティショニングの例 |
+------------------------------------------------------------------+
| |
| s3://bucket/sales/ |
| ├── year=2024/ |
| │ ├── month=01/ |
| │ │ ├── day=01/ |
| │ │ │ └── data.parquet |
| │ │ └── day=02/ |
| │ │ └── data.parquet |
| │ └── month=02/ |
| │ └── ... |
| └── year=2023/ |
| └── ... |
| |
| → WHERE year=2024 AND month=01 でスキャン範囲を限定 |
+------------------------------------------------------------------+
バケット化（Bucketing）：
バケット化は、特定のカラムの値に基づいてデータをバケットに分割する手法です。
+------------------------------------------------------------------+
| パーティショニングとバケット化の違い |
+------------------------------------------------------------------+
| |
| パーティショニング バケット化 |
| +------------------+ +------------------+ |
| | ディレクトリ単位 | | ファイル単位 | |
| | year=2024/ | | bucket_0.parquet | |
| | カーディナリティ低 | | bucket_1.parquet | |
| | 日付、地域など | | カーディナリティ高 | |
| | | | user_id など | |
| +------------------+ +------------------+ |
+------------------------------------------------------------------+
重複データの防止（Upsert）
ETL処理で重複データが発生することを防ぐため、Upsert（Update + Insert） が有効です。
RedshiftでのMERGE例：
MERGE INTO target_table AS target
USING staging_table AS source
ON target.id = source.id
WHEN MATCHED THEN
UPDATE SET
name = source.name,
updated_at = CURRENT_TIMESTAMP
WHEN NOT MATCHED THEN
INSERT (id, name, created_at)
VALUES (source.id, source.name, CURRENT_TIMESTAMP);
まとめ
Domain 3では、データパイプラインを安定して運用するための知識が問われます。
+------------------------------------------------------------------------+
| Domain 3 の全体像 |
+------------------------------------------------------------------------+
| |
| 3.1 自動化 3.2 分析 3.3 監視 3.4 品質 |
| +---------+ +----------+ +----------+ +---------+ |
| |CloudForm| |Athena | |CloudWatch| |Data | |
| |Step Func| |QuickSight| |CloudTrail| |Quality | |
| |MWAA | |OpenSearch| |X-Ray | |DataBrew | |
| |EventBrdg| |Redshift | |Config | |Profiling| |
| +---------+ +----------+ +----------+ +---------+ |
| ↓ ↓ ↓ ↓ |
| +----------------------------------------------------------+ |
| | 信頼性の高いデータパイプライン | |
| +----------------------------------------------------------+ |
+------------------------------------------------------------------------+
試験では、単にサービスの機能を覚えるだけでなく、「どの場面でどのサービスを選ぶか」という判断力が求められます。各サービスの特徴と使い分けを理解し、実践的な問題解決能力を身につけましょう。
おわりに
Domain3はDEA試験の22%を占める重要なドメインです。データパイプラインの自動化から監視、品質管理まで、運用の実務に直結する内容が詰まっています。
特に押さえておきたいポイントは以下の3つです。
- オーケストレーション - Step FunctionsとMWAAの使い分け、EventBridgeでのスケジューリング
- 監視とトラブルシューティング - CloudWatchメトリクス/ログの活用、サービス別の障害対応
- データ品質 - Glue Data Quality、DataBrew、スキュー対策
この記事が、DEA試験を目指す方の参考になれば幸いです！