Amazon DOP-C02: イベント駆動アーキテクチャと自動化 — 学習ガイド

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

概要

イベント駆動型アーキテクチャは、プロデューサーとコンシューマーを疎結合化し、非同期通信を重視し、システムをスパイクや障害に対して回復力のあるものにします。その中核となる信条は、イベント/メッセージによる疎結合、コンシューマー主導のスケーリング、べき等なハンドラー、そして明示的な障害処理と可観測性です。AWSは、耐久性のあるキュー、pub/sub、イベントバス、ストリーム処理、オーケストレーション、および運用自動化のためのビルディングブロックを提供します。Amazon SQS、Amazon SNS、Amazon EventBridge、AWS Step Functions、Lambdaのイベントソースマッピング、AWS Systems Manager AutomationおよびOpsCenter、さらにKinesis Data StreamsとFirehoseの間の相互作用を習得することで、スケーラブルで耐障害性があり、監査可能な自動化およびデータパイプラインを構築できます。

メッセージングと取り込み: SQS、SNS、Kinesis、Firehose

Amazon SQSは、疎結合化のための耐久性がありスケーラブルなキューを提供します。標準キューは、少なくとも1回の配信とベストエフォートの順序付けを、事実上無制限のスループットで提供します。べき等キーや条件付き書き込みによって、重複したメッセージや順序がばらばらのメッセージを許容できる並列ワーカーに適しています。FIFOキューは、メッセージグループごとの順序付けられた配信と、重複排除（5分間のウィンドウ内）による厳密に1回の処理セマンティクスを強制します。順序と単一処理を保証しますが、絶対的なスループットはトレードオフになります。FIFO内で並列化するために複数のメッセージグループを使用するか、1秒あたり数千のメッセージに対応する高スループットFIFOを有効にします。キューごとまたはメッセージごとに可視性タイムアウトを最大処理時間を超えるように設定します。Lambdaコンシューマーを使用する場合、メッセージが再表示される前にリトライを許可するために、可視性タイムアウトを関数タイムアウトの少なくとも6倍に設定します。ロングポーリングを使用して、空の受信を減らします。デッドレターキュー（DLQ）は、メッセージがmaxReceiveCountを超えたときにポイズンメッセージをキャプチャします。後で修正を加えて再処理するために、DLQからソースキューにリドライブします。ApproximateAgeOfOldestMessageを監視してバックログを検出し、同時実行数やオートスケーリングの変更を推進します。

Amazon SNSは、マネージドで高スループットなpub/subを提供します。パブリッシャーは一度トピックにプッシュし、SNSは複数のサブスクリプション（SQS、Lambda、HTTP/S、Eメール、モバイル）にファンアウトします。サブスクリプションフィルターポリシーは、メッセージ属性を使用して、サブスクライバーごとに関連する通知のみをルーティングし、ダウンストリームのコストと負荷を削減します。完全一致、プレフィックス、数値範囲、anything-but、existsなどの述語を表現できます。ファンアウト、疎結合化された通知、モバイルプッシュにはSNSを使用します。リトライを有効にし、配信不能なメッセージのためにサブスクリプションごとのDLQを検討します。順序付けられたファンアウト要件には、SNS FIFOトピックとFIFO SQSサブスクリプションを使用して、順序付けと重複排除を強制します。

Kinesis Data Streamsは、リアルタイム分析とイベント処理のために、シャードレベルの並列性を備えた、順序付けられた低レイテンシのストリームを提供します。プロデューサーはパーティションキーを持つレコードをシャードに書き込み、コンシューマー（Lambda、KCL、拡張ファンアウトコンシューマー、Kinesis Data Analytics）はチェックポイントを設定しながらシャードごとに順序通りに読み取ります。予測不可能な負荷にはオンデマンドキャパシティを、予測可能なスループットにはリシャーディングを伴うプロビジョニング済みシャードを使用します。ホットシャードのバランスを取るためにパーティションキーを調整し、コンシューマーの遅延を監視するためにIteratorAgeをモニターします。拡張ファンアウトは、HTTP/2を介した低レイテンシのプッシュで、コンシューマーストリームごとに専用の2 MB/sのスループットを提供します。

Kinesis Data Firehoseは、S3、Amazon OpenSearch Service、Splunk、またはHTTPエンドポイントへのニアリアルタイムの取り込みのためのフルマネージド配信サービスであり、オプションでLambdaによる変換、バッファリング（サイズ/時間）、圧縮、暗号化が可能です。ソースは、直接のPutRecord/PutRecordBatch、Kinesis Data Streams、またはCloudWatch Logs/Eventsサブスクリプションです。変換とバッチ処理を伴うマネージド配信が必要で、コンシューマーコードを構築・運用する必要がない場合にFirehoseを使用します。動的パーティショニングにより、キーに基づいてレコードをS3プレフィックスにルーティングし、効率的なダウンストリーム処理が可能になります。

ルーティング、オーケストレーション、スケジューリング: EventBridgeとStep Functions

Amazon EventBridgeは、ルーティング、ガバナンス、アカウント間/イベントドメイン間の統合のための中央イベントバスです。AWSサービスイベントにはデフォルトバスを、ドメインをセグメント化して権限を適用するにはカスタムバスを、SaaS統合にはパートナーバスを使用します。ルールはコンテンツベースのパターンを介してイベントを照合し、200以上のAWSサービスをターゲットとします。入力トランスフォーマーを使用してペイロードを整形し、アーカイブ/リプレイを使用して、復旧時や新規コンシューマーのオンボーディング時に過去のイベントを再処理します。リソースポリシーにより、アカウント間のイベントルーティングが可能になり、プラットフォームアカウントでガバナンスを統合できます。EventBridge Pipesは、イベントソース（SQS、Kinesis、DynamoDB Streams、Amazon MSK上のセルフマネージドApache Kafkaなど）からターゲットへの、ポイントツーポイントで設定可能なフローを提供します。これには、組み込みのフィルタリング、バッチ処理、変換、およびLambdaやStep Functionsによるエンリッチメント機能が含まれており、完全なコンシューマーアプリケーションを管理したくないが、軽量な仲介が必要な場合に最適です。EventBridge Schedulerは、1回限りのスケジュールとcronスケジュールを提供し、実行ロール、タイムゾーンサポート、およびサンダリングハードを削減するためのオプションの柔軟な時間枠を使用してターゲットを呼び出します。

AWS Step Functionsは、Amazon States Languageで定義された分散ワークフローをオーケストレーションします。これには、Task、Choice、Parallel、Map（分散Mapを含む）、Wait、Pass、Succeed/Failのステートと、堅牢なRetry/Catchパターンが含まれます。詳細なサービス統合により、AWS APIを呼び出すためのグルーコードが不要になり、同期的な（.sync）パターンや、タスクトークンを使用したコールバックパターンもサポートされます。長時間実行され、監査要件が厳しいオーケストレーション向けで、厳密に1回のステート進行、最大1年の実行期間、ステート遷移ごとの料金体系が特徴のStandard Workflowsを選択してください。実行履歴は保持され、高い可視性と組み込みのX-Rayトレースが提供されます。高スループットで短時間（数秒から数分）のオーケストレーション向けで、リクエストごと+実行時間ごとの料金体系と、少なくとも1回の実行セマンティクスと引き換えに、大規模なスケールを実現できる場合はExpress Workflowsを選択してください。ストリーミング取り込みのエンリッチメント、イベントルーター、タスクをべき等にできるマイクロオーケストレーションに使用します。補償タスクを伴うSagaパターンや、一元化されたエラーハンドリングなどのパターンを適用します。ステートマシンでリトライ/タイムアウトを外部化し、タスクコードを簡素化します。

コンピュートトリガーとバックプレッシャー: Lambdaイベントソースマッピング

Lambdaイベントソースマッピング（ESM）は、ポーリングベースのソースをLambdaに接続し、同時実行、バッチ処理、エラーハンドリングを制御します。

SQS: Lambdaはキューをポーリングし、バッチ（最大10メッセージ、最大バッチウィンドウ300秒）で関数を呼び出すことで、水平にスケールします。標準キューでは、キューの深さとメッセージスループットに応じて積極的にスケーリングします。FIFOキューでは、Lambdaはメッセージグループごとの順序を維持し、グループごとに一度に1つのバッチを処理します。ESMで最大同時実行数を設定してワーカースケールの上限を定め、ダウンストリームシステムを保護します。予約済み/プロビジョニング済み同時実行数と組み合わせてキャパシティを保証します。部分的なバッチ応答を使用して、成功したレコードのみを確認応答し、失敗したレコードを再キューイングすることで、バッチ全体の再処理を回避します。キューの可視性タイムアウトは、最悪の場合の総リトライ時間を超えるように設定します。DLQと再試行ポリシーでポイズンメッセージを分離します。
Kinesis Data Streams: デフォルトではシャードごとに1つのLambda同時実行が起動され、シャードごとの順序が保証されます。サブシーケンス間の順序性が許容される場合は、ParallelizationFactorを最大10まで増やすことで、シャードごとに複数のバッチを並行して処理できます。バッチサイズは最大10,000レコード（6MB）、最大バッチウィンドウは5分で、コストを償却しスループットを向上させます。関数のエラー時にバッチ内の不正なレコードを二分探索するには「エラー発生時の二分岐」を使用し、処理不能なレコードを破棄またはルーティングするには、失敗時の送信先や最大リトライ回数/レコードの有効期間を使用します。IteratorAgeを監視してコンシューマーの遅延を検出し、それに応じてリシャーディングや並列化の増加を行います。
DynamoDB Streams: セマンティクスはKinesisに似ており、バッチサイズは最大1,000レコード（6MB）で、パーティションキーごとのシャードモデルです。コンシューマーは順序付けられたアイテムレベルの変更（INSERT、MODIFY、REMOVE）を受け取ります。同じ失敗処理（エラー発生時の二分岐、最大リトライ回数、レコードの有効期間）とフィルタリングを適用します。コンシューマーが必要とする属性を含むストリームビュータイプ（NewImage、OldImage、NewAndOldImages、またはKeysOnly）を使用して、ペイロードサイズを最適化します。

ESMのイベントフィルタリングは、ポーラーで関連性のないイベントを破棄することで、呼び出し回数を削減します。Lambdaでストリームのタンブリングウィンドウ集計を使用して、ミニバッチ処理パターンのためにレコードを時間単位で集計します。

運用の自動化と修復: Systems Manager AutomationとOpsCenter

AWS Systems Manager Automationは、JSON/YAMLで記述されたランブック（Automationタイプのドキュメント）を提供します。これには、aws:runCommand、aws:executeScript、aws:invokeLambda、aws:approve、aws:createStack、aws:executeAutomationなどのステップが含まれます。Automationはパラメータを受け取り、出力を生成し、変更履歴とともにバージョン管理されます。また、最小権限およびアカウント/リージョン間のオペレーションのために、専用のAutomationAssumeRoleで実行されます。フリート全体で同時実行数とエラーしきい値を制御し、承認やChange Calendarの期間を要求し、SNS経由で通知と統合します。Automationは、スケジュールに基づいて、EventBridgeルールから（AWS Health、CloudWatch、またはAPIイベントに対するほぼリアルタイムの修復のため）、ポリシーを適用するためのAWS Configの修復アクションから（例えば、EBSボリュームにデフォルトタグを適用したり、EC2インスタンスにデフォルトのインスタンスプロファイルをアタッチしたりする）、そしてOpsCenterから呼び出すことができます。

OpsCenterは、CloudWatchアラーム、AWS Config、Healthイベント、またはカスタムソースからの運用上の問題をOpsItemとして集約します。各OpsItemは、ステータス、優先度、重複排除、関連リソース、およびランブックのリンクを追跡します。標準的な修正のためにワンクリックで実行できるランブックを関連付け、OpsItemが作成されたり、一致する条件（例えば、SSHで0.0.0.0/0を許可しているセキュリティグループ、パッチコンプライアンスからの逸脱、またはバックアップの失敗など）に更新されたりしたときに、EventBridgeまたはConfigルールを連携させて特定のAutomationを開始することで、自動修復を有効にできます。Systems Manager Explorerを使用して、フリートの健全性を可視化し、アカウントやリージョンをまたいでオープンなOpsItemを確認します。この組み合わせ—永続的なレコードとしてのOpsItemと、コード化された修正としてのAutomationランブック—により、監査可能で一貫性のある運用を大規模に実現できます。

設計と運用のガイダンス

すべてのコンシューマーにわたってべき等性を考慮して設計します。これは、少なくとも1回の配信が一般的であるためです。低レイテンシーの並列リアクションには、SNSまたはEventBridgeルールによるイベント駆動のファンアウトが推奨されます。ワークロードをバッファリングし、コンシューマーの遅延からプロデューサーを保護するにはSQSが推奨されます。分析のためにシャードごとの厳密な順序性と再生可能なストリームが必要な場合は、Kinesisが推奨されます。カスタムのコンシューマーが過剰な場合にソースとターゲット間の軽量なマネージド統合を行うにはEventBridge Pipesを使用し、cronインフラストラクチャを維持せずに時間ベースのトリガーを実現するにはEventBridge Schedulerを使用します。

タイムアウトとリトライを適切なサイズに設定します。SQSの場合、可視性タイムアウトは最大処理時間とリトライ回数を合わせた時間を超える必要があります。ストリームの場合、リトライ回数に上限を設け、MaximumRecordAgeInSecondsを設定して、不正なレコードが際限なく再生されるのを防ぎます。DLQまたは失敗時の送信先を体系的に使用し、SQSのApproximateAgeOfOldestMessage、LambdaのConcurrentExecutions/Throttles/Errors、IteratorAge、Step FunctionsのExecutionFailed/TimedOut、およびEventBridgeのFailedInvocationsに関するダッシュボードとアラームを追加します。スパイク的なトラフィックが避けられない一方でレイテンシーSLAが厳しい場合は、Lambdaのプロビジョニングされた同時実行を使用してキャパシティを事前にウォーミングアップします。ガバナンスのためには、リソースポリシーを使用したアカウント間のルーティングと、コンシューマーの進化やインシデントリカバリーをサポートするためのアーカイブ/リプレイ機能を備えたEventBridgeが推奨されます。

実践的な問題シナリオ

Shopifyは、フラッシュセールイベントの注文処理を近代化すると同時に、下流サービスが遅延または失敗した場合のリアルタイム分析と自動修復機能を追加する必要があります。

注文イベントの取り込みとファンアウト

SNS FIFOトピックを使用して、チェックアウトからOrderPlacedイベントを発行し、OrderIdごとに順序付けされ、重複排除された通知を保証します。サブスクリプションには以下が含まれます：
- SQS FIFOキュー (Order-Workers)：フルフィルメント用。順序を維持します。
- EventBridgeカスタムイベントバス (CommerceBus)：ガバナンスと追加のルーティング用。
- Kinesis Data Firehose配信ストリーム：注文を分析用にGZIP圧縮してS3にほぼリアルタイムで配信します。なぜSNS FIFOか：パブリッシャーとコンシューマーを結合させることなく、複数のサブスクライバーへのスケーラブルなファンアウトとともに、順序付けされた厳密に1回のセマンティクスを提供するため。

フルフィルメントのバッファリングと処理

Lambdaは、バッチサイズ10、部分的なバッチレスポンスを有効にし、下流の倉庫APIを保護するために最大同時実行数に上限を設けたイベントソースマッピングを介して、SQS FIFOキューからメッセージを消費します。キューの可視性タイムアウトは、リトライに対応するためにLambdaのタイムアウトの6倍に設定されています。DLQはmaxReceiveCount=3でポイズンメッセージをキャプチャし、後のリドライブワークフローで修正されたメッセージを再処理します。なぜSQS FIFO + Lambda ESMか：注文ごとのシーケンスを強制し、バッファリングによって下流の遅延を分離し、きめ細かいエラーハンドリングを提供するため。

マルチステップのSagaをオーケストレーション

Step Functions Standardワークフローは、支払いキャプチャ、在庫予約、不正検知、出荷予約を、リトライ、タイムアウト、および失敗パスでの補償タスク（返金、在庫補充）とともにオーケストレーションします。最初のタスクは、SQSコンシューマーから呼び出されたLambdaによってトリガーされます。なぜStandardか：豊富なエラーハンドリングを備え、外部システムをまたいで、長期間実行され、監査可能で、厳密に1回の状態遷移を実現するため。

ドメインイベントを各機能へルーティング

CommerceBusは、プロデューサーサービスからのPutEventsとSNSサブスクリプションを介してOrder*イベントを受信します。EventBridgeのルール：
- OrderPlacedに一致する場合、マーケティング（Lambda）に通知し、高額顧客が注文した際にサポートケース（AWS Support API連携）を作成します。
- OrderFailedを、アカウント間のガバナンスのためにリソースポリシーを使用して、中央の運用アカウントのイベントバスに転送します。なぜEventBridgeか：一元的なルーティング、フィルタリング、アカウント間配信、そしてプロデューサーを変更することなく新しいコンシューマーを追加できるため。

パートナーフィードをエンリッチメントへパイプ

EventBridge Pipesは、パートナーのSQS Standardキュー（バックオーダーのSKU）をStep Functions Expressワークフローに接続します。このワークフローは、Lambda関数を介してアイテムをエンリッチし、結果を在庫補充用の内部SQSキューにプッシュします。なぜPipes + Expressか：高スループットかつ低コストで、軽量なエンリッチメントを伴う、マネージドで低オーバーヘッドな統合を実現するため。

リアルタイム分析と検索

Kinesis Data Streamがクリックストリームと運用イベントを収集します。Lambda（拡張ファンアウトコンシューマー）がセッション化を実行し、Kinesis Data AnalyticsがKPIを集計します。Firehoseは、変換された注文と分析データを、効率的なクエリのために日付/市場による動的パーティショニングを使用して、S3データレイクとAmazon OpenSearch Serviceに配信します。なぜStreams + Firehoseか：分析のための順序付けされた低レイテンシー処理と、ストレージおよび検索へのマネージドな配信と変換を提供するため。

時間ベースの自動化

EventBridge Schedulerは、毎分cronを実行してInventorySnapshotRequestedをCommerceBusに発行し、Step Functions Expressワークフローをトリガーします。このワークフローは、倉庫全体の在庫スナップショットをコンパイルし、ほぼリアルタイムの在庫精度を実現します。なぜSchedulerか：カスタムインフラストラクチャなしで、ネイティブで回復力のあるcron機能を提供するため。

自動修復と運用

AWS Configルールが、フルフィルメントVPC内のオープンなSSHやパブリックなS3 ACLを検出します。マネージドな修復アクションがSystems Manager Automationランブックを呼び出し、ドリフトを修正します。SQSのApproximateAgeOfOldestMessageとLambdaのIteratorAgeに関するCloudWatchアラームは、OpsCenterにOpsItemsを作成します。関連付けられたランブックは、特定のLambdaのプロビジョニングされた同時実行をスケールしたり、Step Functionsの予約済みキャパシティを増やしたり、一時的にバッチウィンドウを広げたりします。AWS HealthのEC2メンテナンスイベントに関するEventBridgeルールは、SSM Automationドキュメントをターゲットとし、メンテナンスウィンドウ中に影響を受けるインスタンスを正常に再起動します。なぜOpsCenter + Automationか：ワンクリックまたは自動で、アカウント/リージョンをまたいで安全に実行される最小権限の修復を備えた、一元的で監査可能な問題追跡を提供するため。

この設計は、バッファリングとファンアウトによってフラッシュセールのスパイクに対応し、オーケストレーションによってビジネス上の不変条件を維持し、数秒以内に分析を提供し、ポリシー駆動の自動修復によってループを完結させます。

← 高可用性、レジリエンス、災害復旧 · すべてのドメイン · ストレージ、データベース、データ管理 →

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