😺
AWS学びなおし(+TF)_EventBridge

2025/02/27に公開
EventBridgeは、AWSのサーバーレスイベントバスサービスです。アプリケーション、SaaSアプリケーション、AWSサービスからのイベントを受信し、設定したルールに基づいてターゲットにルーティングします。イベント駆動型アーキテクチャを容易に実現するための重要なコンポーネントであり、疎結合なシステム構築、リアルタイム処理、様々なサービス連携を可能にします。
EventBridgeの主要なコンポーネント

イベントバス (Event Bus): イベントを受信するパイプラインです。デフォルトの「デフォルトイベントバス」、カスタムイベントを送信するための「カスタムイベントバス」、SaaSプロバイダーからのイベントを受信する「パートナーイベントバス」の3種類があります。

イベント (Event):  システム内で発生した状態の変化を示すデータです。JSON形式で表現され、「source (イベントの発生源)」「detail-type (イベントの種類)」「detail (イベントの詳細情報)」などの属性を持ちます。

ルール (Rule): イベントバスに届いたイベントを評価し、特定のイベントパターンに一致した場合にターゲットを起動する条件を定義します。イベントパターンはJSON形式で記述し、イベントの属性に基づいてフィルタリングを行います。

ターゲット (Target): ルールに一致したイベントがルーティングされる先です。Lambda関数、SQSキュー、SNSトピック、Step Functionsステートマシン、Kinesis Streamsなど、様々なAWSサービスやHTTPエンドポイントを指定できます。
EventBridgeのメリット

疎結合: イベントソースとイベント処理を分離し、システム全体の疎結合性を高めます。これにより、各コンポーネントの独立性が向上し、変更や拡張が容易になります。

リアルタイム処理: イベント発生に即座に反応し、リアルタイムに近い処理を実現できます。

様々なサービス連携: AWSサービスだけでなく、SaaSアプリケーションやカスタムアプリケーションとも連携できます。

サーバーレス: サーバーの管理が不要で、イベント量に応じて自動的にスケールします。

イベントドリブンアーキテクチャの容易な実現: イベントバスを中心にシステムを構築することで、イベントドリブンなアーキテクチャを容易に実現できます。

標準化されたイベント形式: CloudWatch Eventsから進化し、CloudEvents仕様にも対応しており、イベント形式の標準化が進んでいます。
EventBridgeのデメリット

イベント設計の複雑さ: イベント駆動型アーキテクチャでは、イベントの設計が重要になります。イベントの粒度、スキーマ、バージョン管理などを適切に行う必要があります。

イベント順序の保証: デフォルトではイベントの順序は保証されません。順序保証が必要な場合は、SQS FIFOキューなどをターゲットとして利用する必要があります。

エラーハンドリング: イベント処理でエラーが発生した場合のリカバリ処理を適切に設計する必要があります。デッドレターキュー (DLQ) の設定やリトライポリシーなどを検討する必要があります。

監視: イベントの流れを監視し、問題発生時に迅速に対応するための仕組みが必要です。CloudWatch LogsやCloudWatch Metricsなどを活用する必要があります。

料金: イベントの取り込み量、ルール数、ターゲットへの配信回数などに応じて料金が発生します。料金体系を理解し、コスト最適化を検討する必要があります。
ユースケース例

マイクロサービス連携: マイクロサービス間でイベントを介して非同期に連携し、疎結合なシステムを構築します。

SaaS連携: Zendesk、SalesforceなどのSaaSアプリケーションからのイベントを受信し、社内システムと連携します。

運用自動化: EC2インスタンスの起動・停止、Auto Scalingイベント、CloudTrailログなどのAWSサービスイベントをトリガーに、Lambda関数を実行して運用タスクを自動化します。

セキュリティ監視: GuardDuty、Security Hubなどのセキュリティサービスのイベントを監視し、異常検知時に通知や自動対応を行います。

データ分析: S3へのデータアップロードイベントをトリガーに、データ処理パイプラインを起動し、リアルタイム分析を行います。

アプリケーション監視: カスタムアプリケーションからメトリクスやログイベントを送信し、監視ダッシュボードに表示したり、異常検知アラートを発行したりします。
他のメッセージングサービス (SNS, SQS) との違い

SNS (Simple Notification Service): パブリッシュ/サブスクライブ型のメッセージングサービスで、主に通知やブロードキャスト用途に適しています。メッセージのフィルタリング機能はEventBridgeほど高度ではありません。

SQS (Simple Queue Service): メッセージキューサービスで、メッセージの永続化や順序保証、デッドレターキューなどの機能を提供します。主にアプリケーション間の非同期処理やバックグラウンドジョブ処理に適しています。

EventBridge: イベントバスサービスであり、イベントのルーティングとフィルタリングに特化しています。様々なイベントソースからのイベントを集約し、柔軟なルールに基づいてターゲットに配信できます。アプリケーション統合、SaaS連携、運用自動化など、より広範なユースケースに対応できます。
EventBridgeは、これらのメッセージングサービスと比較して、より高度なイベントルーティングと統合機能を提供し、イベント駆動型アーキテクチャの中核として機能します。
【実務レベルの内容と重要事項】
EventBridgeを実務で利用する上で重要な事項は多岐にわたりますが、特に以下の点が重要です。
1. イベント設計

イベントスキーマの定義: イベントの構造を明確に定義し、スキーマとして管理することが重要です。スキーマを定義することで、イベントの整合性を保ち、イベント処理のロジックを簡素化できます。JSON Schemaなどの標準的なスキーマ定義言語を利用することを推奨します。

イベントの粒度: イベントの粒度を適切に設計する必要があります。細かすぎるイベントは処理負荷を高め、粗すぎるイベントは必要な情報が不足する可能性があります。ユースケースに合わせて最適な粒度を検討する必要があります。

イベントソースの明確化: イベントの発生源を source 属性で明確に区別することが重要です。これにより、イベントのルーティングや処理を柔軟に行うことができます。

イベントバージョニング: イベントスキーマを変更する場合、互換性を考慮したバージョニングを行う必要があります。旧バージョンのイベントも処理できるように、ルールやターゲットの設計を工夫する必要があります。
2. ルール設計

イベントパターンの最適化: イベントパターンは、イベントフィルタリングの効率に影響します。複雑すぎるパターンは処理負荷を高める可能性があります。シンプルなパターンで必要なイベントを効率的に絞り込めるように設計する必要があります。

イベント変換: ターゲットにイベントを渡す前に、必要なデータだけを抽出したり、形式を変換したりするイベント変換機能を活用することで、ターゲット側の処理を簡素化できます。入力トランスフォーマーを利用してJSONパスで必要な属性を抽出したり、定数を追加したりできます。

ルールの優先順位: 複数のルールが同じイベントにマッチした場合の動作を理解しておく必要があります。デフォルトでは、ルールは並列に評価され、全てのアクションが実行されます。特定のルールを優先的に実行したい場合は、ルールグループや優先順位付けの仕組みを検討する必要があります。（EventBridgeには明示的な優先順位付け機能はありませんが、ルール設計で実現する必要があります。）
3. ターゲット設計

適切なターゲットの選定: ユースケースに最適なターゲットを選択することが重要です。Lambda関数、SQS、SNS、Step Functionsなど、各ターゲットの特徴を理解し、適切なものを選択する必要があります。

エラーハンドリング: ターゲットでの処理が失敗した場合のエラーハンドリングを適切に行う必要があります。デッドレターキュー (DLQ) を設定し、エラーが発生したイベントを収集・分析できるようにすることが重要です。

リトライポリシー: ターゲットへの配信が一時的に失敗した場合のリトライポリシーを設定することで、一時的なエラーから回復できます。指数バックオフなどのリトライ戦略を検討する必要があります。

冪等性: ターゲット側の処理は冪等性を考慮して設計する必要があります。同じイベントが複数回配信された場合でも、意図しない副作用が発生しないようにする必要があります。
4. セキュリティ

IAMポリシー: EventBridgeへのアクセス制御、ルールやターゲットの操作権限、イベントソースからのイベント送信権限などをIAMポリシーで適切に制御する必要があります。最小権限の原則に従い、必要な権限のみを付与するようにします。

暗号化: イベントバス、ルール、ターゲット間のデータ転送を暗号化することで、セキュリティを強化できます。HTTPSエンドポイントの利用や、必要に応じてイベントペイロードの暗号化を検討します。

VPCエンドポイント: EventBridgeをVPC内で利用する場合、VPCエンドポイントを作成することで、インターネットを経由せずにAWSサービスと通信できます。
5. 監視とロギング

CloudWatch Logs: EventBridgeのログをCloudWatch Logsに出力し、イベントの配信状況やエラー発生状況などを監視できるようにします。ルールの実行ログ、ターゲットへの配信ログなどを確認できます。

CloudWatch Metrics: EventBridgeのメトリクスをCloudWatch Metricsで監視し、イベントのスループット、エラー率、遅延時間などを把握できるようにします。異常検知アラートを設定することもできます。

トレーシング: AWS X-Rayなどのトレーシングツールを利用して、イベントの追跡を行い、システム全体のパフォーマンスボトルネックを特定できるようにします。
6. パフォーマンスとスケーラビリティ

スループット: EventBridgeは高いスループットに対応できますが、ターゲット側の処理能力がボトルネックになることがあります。ターゲット側のスケーラビリティも考慮した設計が必要です。

レイテンシ: イベントの発生からターゲットでの処理完了までのレイテンシを把握し、要件を満たすように設計する必要があります。

同時実行数: ターゲットがLambda関数の場合、同時実行数制限に注意する必要があります。必要に応じて同時実行数制限の緩和を検討します。
7. 費用対効果

料金体系の理解: EventBridgeの料金体系を理解し、コスト見積もりを行うことが重要です。イベントの取り込み量、ルール数、ターゲットへの配信回数などを考慮して、費用対効果を評価します。

コスト最適化: 不要なルールやイベントバスを削除したり、イベントパターンを最適化したりすることで、コストを削減できます。
これらの重要事項を考慮することで、EventBridgeを実務で効果的に活用し、信頼性の高いイベント駆動型システムを構築できます。
【実務でどの程度使用されるのか】
EventBridgeは、実務で非常に広く使用されています。特に、以下のようなケースで利用頻度が高いです。

大規模システム、マイクロサービス: 多くの企業がマイクロサービスアーキテクチャを採用しており、サービス間の連携にEventBridgeが活用されています。疎結合なシステム構築、柔軟な拡張性、リアルタイム処理能力が求められる大規模システムにおいて、EventBridgeは重要な役割を果たします。

SaaS連携: 多くの企業がSaaSアプリケーションを利用しており、SaaSアプリケーションと社内システムを連携させるニーズが高まっています。EventBridgeは、Zendesk、Salesforce、PagerDutyなど、多くのSaaSプロバイダーとの連携をサポートしており、SaaS連携基盤として広く利用されています。

運用自動化: クラウド環境の運用自動化は、効率的なシステム運用に不可欠です。EventBridgeは、AWSサービスイベントをトリガーに、様々な運用タスクを自動化するために広く利用されています。例えば、EC2インスタンスの自動バックアップ、セキュリティインシデントへの自動対応、ログ分析基盤の構築などに活用されています。

リアルタイムデータ処理: リアルタイムデータ分析、リアルタイムレコメンデーション、リアルタイム監視など、リアルタイム処理が求められるシステムにおいて、EventBridgeはイベントストリーム基盤として利用されています。Kinesis Streamsなどのストリーム処理サービスと連携し、大量のイベントデータをリアルタイムに処理するシステムを構築できます。

イベント駆動型アプリケーション: イベント駆動型アーキテクチャは、現代的なアプリケーション開発において重要なパラダイムです。EventBridgeは、イベント駆動型アプリケーションの中核となるイベントバスとして、様々な業界の企業で利用されています。
業界別の利用例

ECサイト: 注文イベント、決済イベント、在庫変動イベントなどをEventBridgeで処理し、在庫管理システム、配送システム、レコメンデーションシステムなどと連携します。

金融機関: 取引イベント、不正検知イベント、アラートイベントなどをEventBridgeで処理し、リスク管理システム、監視システム、顧客管理システムなどと連携します。

メディア: コンテンツ公開イベント、ユーザー行動イベント、広告配信イベントなどをEventBridgeで処理し、コンテンツ配信システム、分析システム、パーソナライズシステムなどと連携します。

ゲーム: ゲームイベント、課金イベント、ユーザー行動イベントなどをEventBridgeで処理し、ゲームサーバー、分析システム、マーケティングシステムなどと連携します。
利用規模感
EventBridgeは、小規模なシステムから大規模なシステムまで、幅広い規模のシステムで利用されています。

小規模システム: バックエンド処理の自動化、SaaS連携、簡単な運用自動化など、比較的小規模なシステムでもEventBridgeのメリットを享受できます。

中規模システム: マイクロサービス連携、リアルタイムデータ処理、複雑な運用自動化など、中規模以上のシステムではEventBridgeの高度な機能がより効果的に活用されます。

大規模システム: 大規模な分散システム、グローバル展開しているシステムなど、非常に大規模なシステムでもEventBridgeは高いスケーラビリティと信頼性を発揮します。
EventBridgeは、AWS環境におけるイベント駆動型アーキテクチャのデファクトスタンダードとなりつつあり、今後も利用シーンは拡大していくと予想されます。特にサーバーレスアーキテクチャ、マイクロサービスアーキテクチャの普及に伴い、EventBridgeの重要性はますます高まっています。
【terraformのコードで記述する場合の基本的内容と実務レベルの内容】
TerraformでEventBridgeリソースを記述する場合、主に以下のリソースタイプを使用します。

aws_cloudwatch_event_bus: カスタムイベントバスを作成します。

aws_cloudwatch_event_rule: イベントルールを作成します。

aws_cloudwatch_event_target: イベントルールのターゲットを設定します。

aws_iam_role, aws_iam_policy, aws_iam_policy_attachment: EventBridgeがターゲットにアクセスするためのIAMロールとポリシーを設定します。
基本的な記述内容
resource "aws_cloudwatch_event_bus" "example" {
  name = "example-event-bus"
}

resource "aws_cloudwatch_event_rule" "example" {
  name          = "example-rule"
  event_bus_name = aws_cloudwatch_event_bus.example.name
  event_pattern = jsonencode({
    source      = ["aws.ec2"]
    detail-type = ["EC2 Instance State-change Notification"]
  })
}

resource "aws_cloudwatch_event_target" "example" {
  rule             = aws_cloudwatch_event_rule.example.name
  event_bus_name   = aws_cloudwatch_event_bus.example.name
  target_id        = "example-target"
  arn              = aws_lambda_function.example.arn  # 例：Lambda関数をターゲットとする場合
  function_arn     = aws_lambda_function.example.arn  # Lambda関数をターゲットとする場合 (必須)

  # 必要に応じて入力トランスフォーマーを設定
  input_transformer {
    input_paths = {
      instance_id = "$.detail.instance-id"
      state       = "$.detail.state"
    }
    input_template = jsonencode({
      message = "EC2 Instance <instance_id> state changed to <state>"
    })
  }
}

resource "aws_lambda_permission" "allow_eventbridge" {
  statement_id  = "AllowExecutionFromCloudWatch"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.example.function_name
  principal     = "events.amazonaws.com"
  source_arn    = aws_cloudwatch_event_rule.example.arn
}
実務レベルの記述内容
実務レベルでは、上記の基本的な記述内容に加えて、以下の点を考慮する必要があります。
1. モジュール化と再利用性
EventBridgeの設定をモジュール化することで、コードの再利用性を高め、管理を容易にすることができます。例えば、イベントバス、ルール、ターゲットの設定をそれぞれモジュール化し、必要に応じて組み合わせるようにします。
module "event_bus" {
  source = "./modules/event_bus"
  name   = "example-event-bus"
}

module "event_rule" {
  source         = "./modules/event_rule"
  event_bus_name = module.event_bus.name
  name           = "example-rule"
  event_pattern  = jsonencode({
    source      = ["aws.ec2"]
    detail-type = ["EC2 Instance State-change Notification"]
  })
  targets = [
    {
      target_id  = "example-target"
      arn        = aws_lambda_function.example.arn
      function_arn = aws_lambda_function.example.arn
      input_transformer = {
        input_paths = {
          instance_id = "$.detail.instance-id"
          state       = "$.detail.state"
        }
        input_template = jsonencode({
          message = "EC2 Instance <instance_id> state changed to <state>"
        })
      }
    }
  ]
}
2. 変数とoutputsの活用
変数を使用して設定値を外部から渡せるようにすることで、柔軟性を高め、環境ごとの差異を吸収できます。outputsを使用して、作成したリソースの情報を外部に公開することで、他のリソースから参照できるようにします。
variable "event_bus_name" {
  type    = string
  default = "example-event-bus"
}

variable "lambda_function_arn" {
  type = string
}

resource "aws_cloudwatch_event_bus" "example" {
  name = var.event_bus_name
}

resource "aws_cloudwatch_event_rule" "example" {
  name          = "example-rule"
  event_bus_name = aws_cloudwatch_event_bus.example.name
  event_pattern = jsonencode({
    source      = ["aws.ec2"]
    detail-type = ["EC2 Instance State-change Notification"]
  })
}

resource "aws_cloudwatch_event_target" "example" {
  rule             = aws_cloudwatch_event_rule.example.name
  event_bus_name   = aws_cloudwatch_event_bus.example.name
  target_id        = "example-target"
  arn              = var.lambda_function_arn
  function_arn     = var.lambda_function_arn
}

output "event_bus_arn" {
  value = aws_cloudwatch_event_bus.example.arn
}
3. 環境分離
開発環境、検証環境、本番環境など、環境ごとにEventBridgeの設定を分離することが重要です。Terraformワークスペースやモジュール、変数などを活用して、環境ごとの設定を管理します。
4. IAMロールとポリシー
EventBridgeがターゲットにアクセスするためのIAMロールとポリシーは、最小権限の原則に従って設定する必要があります。必要なアクションのみを許可し、リソースを限定するようにします。
resource "aws_iam_role" "eventbridge_target_role" {
  name = "eventbridge-target-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Principal = {
          Service = "events.amazonaws.com"
        }
        Effect = "Allow"
      },
    ]
  })
}

resource "aws_iam_policy" "eventbridge_target_policy" {
  name = "eventbridge-target-policy"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = [
          "lambda:InvokeFunction", # 例：Lambda関数をターゲットとする場合
        ]
        Effect   = "Allow"
        Resource = [
          aws_lambda_function.example.arn, # 例：Lambda関数をターゲットとする場合
        ]
      },
    ]
  })
}

resource "aws_iam_policy_attachment" "eventbridge_target_policy_attachment" {
  name       = "eventbridge-target-policy-attachment"
  roles      = [aws_iam_role.eventbridge_target_role.name]
  policy_arn = aws_iam_policy.eventbridge_target_policy.arn
}

resource "aws_cloudwatch_event_target" "example" {
  # ... (省略) ...
  role_arn = aws_iam_role.eventbridge_target_role.arn # IAMロールを指定
}
5. デッドレターキュー (DLQ)
ターゲットへの配信に失敗した場合に備えて、デッドレターキュー (DLQ) を設定することを推奨します。DLQにイベントを送信することで、エラーが発生したイベントを後から分析し、リカバリ処理を行うことができます。
resource "aws_sqs_queue" "dlq" {
  name = "eventbridge-dlq"
}

resource "aws_cloudwatch_event_target" "example" {
  # ... (省略) ...
  dead_letter_config {
    arn = aws_sqs_queue.dlq.arn
  }
}
6. リトライポリシー
ターゲットへの配信が一時的に失敗した場合に、リトライポリシーを設定することで、自動的にリトライを試行できます。指数バックオフなどのリトライ戦略を検討します。
resource "aws_cloudwatch_event_target" "example" {
  # ... (省略) ...
  retry_policy {
    maximum_event_age_in_seconds = 3600 # 最大リトライ時間 (秒)
    maximum_retries              = 5    # 最大リトライ回数
  }
}
7. 監視設定
CloudWatch Logsへのログ出力、CloudWatch Metricsでのメトリクス監視など、EventBridgeの監視設定もTerraformでコード化することで、インフラ全体の一貫性を保ち、管理を容易にすることができます。
これらの実務レベルの内容を考慮することで、TerraformでEventBridgeをより効果的に管理し、信頼性の高いイベント駆動型システムを構築できます。
Discussion
