Amazon EventBridge アーカイブで、あのイベントをもういちど

クラウドソリューション部の荒木です。

今回は AWS のサービス Amazon EventBridge の「アーカイブ」と「再生」という機能に焦点を絞ってご紹介します。

概要：Amazon EventBridge とは

Amazon EventBridge は、イベント駆動型アーキテクチャを実現するサービスです。リソースで発生する「イベント」を取り込み、フィルタリングや変換を行い、後続のターゲットへ配信します。アプリケーションのコンポーネント間に Amazon EventBridge を挟んで疎結合な構成とすることで、俊敏性が高くスケーラブルなシステムを構築することができます。

Amazon EventBridge はいくつかの要素で成り立っており、まずは関連用語をご紹介します。

イベント

リソースの状態が変化することを指します。例として、 Amazon EC2 の作成から削除までの一連のライフサイクルを並べてみます。以下の各ステータスに状態が変化するタイミングで、イベントが生成されます。

保留中(pending)→実行中(running)→停止中(stopping)→停止(stopped)→削除中(shutting-down)→終了済み(terminated)

イベントバス

イベントを受信し、後続のターゲットへ配信するルータの役割を持ちます。

ルール、イベントパターン

イベントバスに紐づけてルールを作成することができます。ルールにはイベントパターンや、後述するターゲットの詳細を設定します。

イベントパターンとは、イベントを検出するための条件です。条件はカスタマイズが可能で、記述次第で『EC2』というような大まかな絞り込みもできますし、『タグ名がxxx（の）/ EC2（が）/ 停止』というような細かい絞り込みもできます。イベントバスを通過するイベントは「イベントパターンに一致するか、一致しないか」のいずれかに判定され、一致したイベントはターゲットにルーティングされます。

ターゲット

イベントパターンに一致したイベントの配信先となるリソースやエンドポイントです。ターゲットは、AWS Lambda や Amazon SNS 、AWS のパートナー SaaS など、多数の宛先から選択することができます。1 つのルールから、最大 5 つのターゲットにイベントをルーティングすることができます。

画像引用：Amazon EventBridge イベントバス

本題：Amazon EventBridge アーカイブとは

アーカイブ

イベントバスに紐づけて作成します。イベントパターンを設定し、一致したイベントを保存します。保存されたイベントは、 任意の期間保持されます（1 日～無期限）。

再生

アーカイブに保存されたイベントは「再生」することができ、後続のターゲットの動作検証などに利用することができます。一貫した条件のもとで何度も検証を行うことができる、というのがうれしいポイントです。

参考：Amazon EventBridge のアーカイブと再生

疑問：「再生」は同じ事象がもう一度発生するのか

「再生」の機能を知ったとき、これが「同じことがもう一度起こる」という意味を含むのか気になりました。リファレンスを読む限り、さすがに事象が再発するわけではなさそうだと解釈したのですが、うっかり言葉の解釈違いで「障害発生後、対策を練った後続アクションの検証のためにイベントを再生したら、ふたたび障害が発生してしまった」などとなれば一大事です。

そこで、こんなものを作ってみました。

検証の概要

このアーキテクチャで、以下の 2 点を実施します。Amazon EventBridge アーカイブを再生したあとの結果次第で、障害が再発生するかどうかを切り分けることができます。（それぞれの矢印の解説は長くなってしまうため、記事の末尾に記載します。）

• AWS Fault Injection Service （以降、AWS FIS）による実験を実行する
  • • • 想定される結果：赤矢印、緑矢印の両方が動作し、（4）と（D）の両方のメールが届く
• Amazon EventBridge アーカイブを再生する
  • • • 想定される結果：
        • 障害がもう一度発生するならば、（4）と（D）の両方のメールが届く
          （AWS FIS 実験の実行と同様に、赤矢印、緑矢印の両方が動作する）
        • 障害がもう一度発生しないのであれば、（D）のメールのみが届く
          （再生されたイベントによって（A）のルールが動作するが、（2）の Amazon CloudWatch アラームは動作しない）

AWS FIS とは、アーキテクチャのレジリエンス（回復力/耐障害性）実現のために、障害状況の注入を行うことができるサービスです。このサービスによって引き起こされるイベントは破壊的なアクションであり、対象のリソースで実際の再起動や停止が発生します。

AWS FIS による実験を実行する

AWS FIS では、実施した実験ごとにユニークな ID が割り当てられます。下記キャプチャの実験には、末尾 NPDC の ID が割り当てられています。

赤矢印を経由して届いた（4）のメールです。 Amazon CloudWatch アラームの状態が OK から ALARM になったことがわかります。

緑矢印を経由して届いた（D）のメールです。イベント本文に AWS FIS の実験 ID が含まれています。

Amazon EventBridge アーカイブを再生する

再生を開始します。再生したい期間や、命名などを指定します。

再生が終了したあと、（D）のメールが届きました。再生に設定した命名が含まれています。それ以外のイベント詳細については、AWS FIS の実験 ID やタイムスタンプなど（その他マスクした箇所も同様）が示されており、AWS FIS によって発生したものと同一のイベントが発行されたことがわかりました。

このあとしばらく待っても、（4）のメールは届きませんでした。

念のために Amazon CloudWatch アラーム画面で、Amazon EC2 インスタンスから Amazon EBS への到達可能性のメトリクス（StatusCheckFailed_AttachedEBS）の経過を確認しました。AWS FIS を複数回実行した時間帯ではメトリクスの変位が確認できましたが、アーカイブの再生の時間帯にはメトリクスの変位がありませんでした。このことから、Amazon EventBridge アーカイブの再生によって障害がふたたび発生するわけではない、と結論付けました。

 

結論：「再生」は「再現」ではなかった

ふたたび障害が起こることはないだろうと予想はしていたものの、実際に障害を起こすことができる AWS FIS のようなサービスもある（あと、筆者が思い込みや先入観の強い性格でもある）ため、きちんと検証して結論付けることができてよかったです。これで安心して使うことができます。

以下は、アーカイブと再生の機能を使ってみた所感や気づきです。

• 再生するには、過去にイベントが発生している必要がある
  • 当たり前の話ではあるのですが、再生の機能を利用するためにはそのイベントがアーカイブに保存されている必要があります。Amazon EventBridge の後続リソースの検証を行いたい場合は、アーカイブしたいイベントを発生させる方法を検討しましょう。
    また、アーカイブされたイベントは個別に確認することができません。イベントが適切にアーカイブされたか不安であれば、ルールで同様のイベントパターンを設定し、検出の有無を確認するとよいかと考えました。
• 効率的、省コストな運用のために上手にフィルタリングする
  • アーカイブや再生の機能は従量課金です。すべてのイベントを無期限にアーカイブするような設定にすると月額料金が膨らみ続けてしまうため、適切なイベントパターンで過不足なく保存することが望ましいです。
    とはいえ、予め障害が発生するであろうイベント条件を狙って網を張っておくことは困難ですので、「Amazon EventBridge の後続アクションのトリガーとなるサービスに絞る」「AWS マネージドサービスを含め、障害が発生するとクリティカルな影響を及ぼすサービスに絞る」といった設計段階での検討や、「広い範囲でイベントをアーカイブするが、保持期間を短くする」「重要なイベントの発生時は再生を実行し、長期保存用のアーカイブに保存しなおす」というような運用によるカバーが有効かと考えました。

おわりに

記事中でさらりとご紹介しましたが、 AWS FIS の実験では破壊的なアクションが実行されるため、リファレンスでも「本番環境前の環境で実験を実行すること」が強く推奨されています。ご利用の際にはその点にご留意ください。

（余談ですが、 AWS FIS の提供開始当初の名称は「AWS Fault Injection Simulator」だったと記憶していたのですが、いつの間にか「AWS Fault Injection Service」に変わったようです。前者のままだと、僕のような人が早合点して、シミュレーション＝疑似のつもりでとドカンと障害を発生させてしまうリスクがあったのかな…などと想像しました。）

この記事が、少しでもどなたかのお役に立ちましたら幸いです。以降は、記事中の構成図の解説になります。

 

補足：それぞれの矢印の解説

• 赤の矢印

（1）AWS FIS を実行して、Amazon EBS に障害を発生させます。

（2）Amazon CloudWatch アラームで、Amazon EC2 インスタンスから Amazon EBS への到達可能性のメトリクス（StatusCheckFailed_AttachedEBS）を監視します。AWS FIS によって発生した障害によりメトリクスが変位し、閾値を超過してアラーム状態になります。

（3）Amazon CloudWatch アラームは、アラーム状態に遷移したことを Amazon SNS へ通知します。

（4）Amazon SNS は、Amazon CloudWatch アラームから受け取った内容を E メールで送信します。

• 緑の矢印

（A）Amazon EC2 を検出するイベントパターンで、 Amazon EventBridge のルールを作成します。（「EC2 – EBS 間の到達可能性」に関するイベントは、EC2 のイベントとして発行されます。）

（B）Amazon EventBridge のアーカイブを作成し、イベントパターンは（A）と同じ内容で設定します。これにより、（A）のルールに一致したイベントはアーカイブにも保存される、という状況になります。そのため、一度ルールで検出されたイベントを再生すると、実際のリソース障害の有無にかかわらずルールによって検出され、後続のメール通知が動作します。

（C）ルールに一致したイベントはターゲットである Amazon SNS へ通知されます。

（D）Amazon SNS は、Amazon EventBridge から受け取った内容を E メールで送信します。