- はじめに
- 全体アーキテクチャ
- なぜ失敗通知の自動化が必要なのか？
- Step1：Lambda を作成
- Step2：EventBridge で Glue の失敗イベントを検知
- Step3：SNS 設定
- どっちを使うべき？
- Step4：Lambda 設定
- 検証
- よくあるハマりポイント
- まとめ
- 参照資料
はじめに
ゼネットシステム事業部の方です。
AWS Glue のジョブが失敗しても気づかず、パイプライン全体が止まってしまう…。 そんなトラブルを防ぐために、多くの現場で 「Glue失敗 → EventBridge → Lambda → SNS通知」という構成で自動アラートを飛ばす運用がよく使われています。
この記事では、この仕組みを AWS 初心者でも理解できるよう丁寧に解説します。
全体アーキテクチャ
Glue が FAILED 状態になった時、EventBridge がイベントを検知し、 Lambda がイベント情報を整理して SNS へ通知します。
なぜ失敗通知の自動化が必要なのか？
-
Glue は失敗しても、手動で確認しないと気づけない
-
リトライがある場合、標準では「最終失敗のみ通知」がされない
-
異常検知が遅れると、ETLパイプライン全体が止まる
-
業務系 ETL は「気づくのが遅れる＝影響が大きい」
パイプラインの信頼性を高めるために、失敗通知の自動化はほぼ必須です。
Step1：Lambda を作成
Glue の失敗イベントを受け取り、SNS に通知する Lambda を作成します。これにより、メール・Slack・Teams など任意のチャネルへ即時通知できます。
Lambda コード
import boto3
import traceback
# クライアント初期化
sns = boto3.client('sns')
# SNS トピック ARN
SNS_TOPIC_ARN = 'arn:aws:sns:ap-northeast-1:1234567890:glue-notification'
def lambda_handler(event, context):
try:
print(event)
# イベントから情報を取得
detail = event.get('detail', {})
job_name = detail.get('jobName', 'unknown-job')
job_run_id = detail.get('jobRunId', '')
job_state = detail.get('state', 'UNKNOWN')
error_message = detail.get('errorMessage', '（エラーメッセージなし）')
# 最終リトライ（_attempt_1）のジョブのみ通知 ※ジョブが複数リトライする場合は、適宜条件を調整してください。
if not job_run_id.endswith('_attempt_1'):
print(f"通知対象外の Retry ジョブ: {job_run_id}")
return
# SNS 送信メッセージ
message = (
f"【Glue ジョブ失敗通知】\n"
f"ジョブ名: {job_name}\n"
f"ジョブ実行 ID: {job_run_id}\n"
f"ステータス: {job_state}\n"
f"\n"
f"エラー内容:\n"
f"{error_message}\n"
f"\n"
f"AWS コンソールで詳細ログを確認してください。"
)
# SNS 発行
sns.publish(
TopicArn=SNS_TOPIC_ARN,
Subject=f"Glue ジョブ失敗通知: {job_name}",
Message=message
)
print("SNS 通知を送信しました。")
except Exception as e:
# Lambda 自体のエラー
error_message = (
f"Lambda 実行中に例外が発生しました。\n"
f"エラー: {str(e)}\n"
f"{traceback.format_exc()}"
)
sns.publish(
TopicArn=SNS_TOPIC_ARN,
Subject="Glue 失敗通知 Lambda エラー",
Message=error_message
)
print("SNS エラー通知を送信しました。")
Step2：EventBridge で Glue の失敗イベントを検知
今回はカスタムイベントを作成するため、イベントソース「その他」を選択し、イベントパターンをカスタム形式で入力します。
EventBridge で以下のイベントパターンを設定します。
{
"source": ["aws.glue"],
"detail-type": ["Glue Job State Change"],
"detail": {
"state": ["FAILED"]
}
}
このルールを作成することで、Glue ジョブが失敗したタイミングで、自動的に Lambda にイベントが渡されるようになります。
ターゲット選択画面で、ターゲットタイプをAWSのサービスに設定し、ターゲットをLambda関数に選択、使用する関数を選んで作成します。
Step3：SNS 設定
SNS トピックを作成し、通知先のメールアドレス（または Slack/Teams の Webhook）を設定します。
トピック名を入力し、暗号化やアクセスポリシーも設定できます。
プロトコールは「E メール」を選択し、メールアドレスを入力してサブスクリプションを作成します。
SNSサブスクリプション確認メールが届きます。「Confirm subscription」を押下して認証を完了してください。
SNS を利用することで、以下のようなチャンネルに通知できます。
- メール
- Slack（Webhook）
- Microsoft Teams（Webhook）
- Chatbot 経由で Slack
通知処理は単純で、SNS Publish API を呼ぶだけで完了します。
SNS Standard と SNS FIFO の違い
Glue 失敗通知の多くは SNS Standard を利用しますが、AWS にはもう1つ SNS FIFO があります。用途が異なるため、違いを理解して選ぶことが重要です。
◎ SNS Standard（標準）
-
高速通知（リアルタイム性が高い）
-
少なくとも1回（at-least-once）配信
-
順序保証なし
-
大規模配信など通知全般に向いている
👉 失敗通知のような「とにかくすぐ知らせたい」ケースに最適
◎ SNS FIFO
-
順序保証（FIFO）
-
重複なし
-
スループットが標準より低い
-
メッセージグループで厳密に制御
👉「順序が重要」「重複を絶対避けたい」システム間連携向け
どっちを使うべき？
Glue の失敗通知は リアルタイム性 > 順序保証 なので、
この記事で紹介している構成では SNS Standard がベスト です。
FIFO は厳密な順序制御が必要な金融・在庫管理・キューイング用途で使われることが多いです。
Step4：Lambda 設定
Lambda コードまたは環境変数にSNS トピック ARN を設定し、トリガーには Step2 の EventBridge ルールを指定します。
検証
Glue Job に以下のコードを入れると、失敗イベントを強制発生させられます：
# エラー
raise ValueError("error!")
Glue 側で FAILED となり、EventBridge → Lambda → SNS の流れで通知が届きます。
よくあるハマりポイント
-
EventBridge のイベントパターンは「1文字違うだけで」発火しない
-
Lambda の IAM 権限不足（logs:GetLogEvents, sns:Publish など）
-
SNS メールのサブスクリプション確認を忘れて通知が届かない
-
Glue の retry 設定により、想定外のタイミングで通知が来ない
-
Lambda のタイムアウトや VPC 内配置による SNS 送信失敗
特に EventBridge パターンのミスが一番多いです。
まとめ
本記事で紹介した構成は、AWS 実務で必須となる 監視・通知基盤 の基本パターンです。
Glue の失敗通知を自動化すると：
-
異常を早期に検知できる
-
MTTR を短縮できる（復旧が早い）
-
パイプライン運用の信頼性が上がる
確実に AWS 運用スキルが身につく構成なので、ぜひあなたの環境でも試してみてください。
なお、ゼネットでは、資格取得と実践的なハンズオンを組み合わせた研修を行っています。
