【ITニュース解説】DataSync EventBridge Automation Checklist for S3 Transfers

ITシステムにおいて、ある場所から別の場所へデータを転送する作業は頻繁に行われる。例えば、社内のファイルサーバーからクラウドストレージであるAmazon S3へ、夜間にまとめてデータをコピーするような場合だ。しかし、このデータ転送が何らかの原因で途中で止まってしまったとしても、その失敗に誰も気づかないまま、後続のシステムで使うデータが空っぽになるまで問題が発覚しない、という事態が起こりうる。このような「サイレントな失敗」を防ぎ、データ転送を確実に自動化するための方法が、AWSのDataSyncとEventBridgeを連携させるアプローチである。

DataSyncは、オンプレミス環境にあるファイルサーバーや、異なるクラウドサービス間など、様々な場所にある大量のデータを安全かつ効率的に転送するためのAWSのサービスである。一方、EventBridgeは、AWSの様々なサービスやカスタムアプリケーションから発生する「イベント」（特定の出来事）をリアルタイムで監視し、そのイベントに応じて他のサービスを自動的に起動したり、通知を送ったりするサービスだ。この二つのサービスを組み合わせることで、データ転送の開始から完了、あるいは失敗までの一連の流れを自動化し、その状況を監視できるようになる。

この自動化の仕組みは、大きく三つの段階で構成される。一つ目は「トリガー（Trigger）」で、DataSyncのデータ転送タスクをいつ、どのように開始するかを決定する部分だ。二つ目は「監視（Observe）」で、DataSyncタスクが実行されている間に、そのタスクの状態がどのように変化しているかをEventBridgeを使って確認する。そして三つ目は「反応（React）」で、タスクの成功や失敗といった状態変化に応じて、適切な次のアクションを自動的に実行することである。例えば、タスクが成功したら次のデータ処理を開始し、失敗したら担当者にアラートを送信するといった対応が含まれる。特に、この「監視」の仕組みを導入するだけでも、データ転送が静かに失敗して誰にも気づかれないという、非常に危険な盲点を解消できる。

具体的な設定手順を見ていこう。まず、DataSyncタスクの開始方法について、DataSync自体にもタスクを定期実行する機能があるが、EventBridge Schedulerを使う方がより柔軟なスケジュール設定が可能だ。Schedulerでは、特定のタイムゾーンを考慮したスケジュール設定や、より詳細な実行期間の指定ができるため、多くの場合で優れた選択肢となる。SchedulerがDataSyncタスクを起動する際には、AWSのサービスが他のサービスにアクセスするための権限を付与する仕組みであるIAMロールを使用する。このロールには、特定のDataSyncタスクを実行する権限のみを与えるべきで、必要以上の広範な権限は付与しない。もしタスクの起動が何らかの理由で失敗した場合に備えて、処理できなかったメッセージを一時的に保管する「デッドレターキュー」（SQSキュー）を設定することも可能だ。EventBridge SchedulerからAWS SDKの機能を使ってDataSyncタスクを直接開始できるため、タスクを起動するためだけにLambda関数のような追加のコンピューティングリソースを用意する必要はない。

次に、データ転送先のAmazon S3バケットにオブジェクトが格納されたり、変更されたりした際にEventBridgeでイベントを受け取るには、そのS3バケットでEventBridgeへのイベント配信を有効にする必要がある。これは、S3バケットがデフォルトではオブジェクトの変更イベントをEventBridgeに送らないためだ。

最も重要なのは、データ転送タスクが失敗した場合の対応である。まずは「失敗ルール」を作成する。これは、DataSyncタスクの実行状態が「ERROR」（エラー）になった場合に反応するEventBridgeのルールだ。このルールが検知されたら、Amazon SNS（テキストメッセージやメールなどを送るサービス）やチャットツール、社内のインシデント管理ツールなどにアラートを自動的に送信するように設定する。これにより、タスクが失敗した場合に担当者がすぐに気づき、迅速に対応できるようになる。

失敗ルールを設定したら、次に「成功ルール」を作成する。これは、DataSyncタスクが成功裏に完了した場合に反応するルールだ。この成功ルールを使って、転送後のデータに対して検証処理、カタログ情報の更新、あるいは後続のデータ処理システムを起動するといった作業を自動的に開始できる。S3にオブジェクトが格納されたことをトリガーに後続処理を行う場合は、無関係なファイルのアップロードによって処理が誤って起動しないよう、特定のバケット名やキープレフィックス（S3内の仮想的なフォルダのようなもの）でイベントを厳密にフィルタリングすることが重要だ。

DataSyncタスクの動作状況や詳細なログを確認するためには、CloudWatch Logsを有効にすることが推奨される。ログレベルを設定することで、通常の実行では必要最低限のログ、問題発生時には詳細なログといった具合に、必要な詳細度でログを収集できる。また、どのファイルが転送され、どのファイルがスキップされ、あるいは失敗したかといった、ファイルごとの証拠が必要な場合は、DataSyncのタスクレポート機能を有効にして、そのレポートをS3の特定の場所に自動的に出力するように設定できる。

EventBridgeのルールやSchedulerから起動されるターゲット（例えばLambda関数など）が、何らかの理由でイベントを処理できなかった場合も考慮する必要がある。デッドレターキューとリトライポリシーは、イベントがターゲットに到達できなかった場合に役立つが、Lambda関数などの内部で発生したエラーは別の対応が必要だ。Lambdaの場合は、関数レベルのデッドレターキューや、処理失敗時の通知先設定を構成し、処理エラーがサイレントに無視されないようにする。

このような自動化設定を行う上で、いくつか見落とされがちな点がある。 S3バケットでEventBridgeへのイベント配信を有効にするAPI呼び出しは、既存のバケット通知設定を上書きしてしまう可能性がある。もしLambdaやSQSへの通知が既に設定されているS3バケットでEventBridgeの設定だけを追加すると、それらの既存設定が削除されてしまうことがあるため、事前に現在の設定を読み込み、EventBridgeの設定とマージしてから新しい設定を書き戻す必要がある。

また、イベントループの発生にも注意が必要だ。例えば、S3バケットにオブジェクトが書き込まれたことをトリガーに処理が起動し、その処理が同じバケットの同じプレフィックスに新たなオブジェクトを書き込むと、その書き込みが再びイベントを発生させ、無限に処理が繰り返される可能性がある。これを避けるためには、入力と出力のプレフィックスを分けるか、異なるバケットを使用し、EventBridgeルールのフィルタリングを厳密に行うべきだ。

DataSyncタスクが「成功」と報告されても、必ずしも全てのデータが期待通りに転送されたとは限らない場合もある。DataSyncのフィルタ設定やオプションによっては、一部のファイルがスキップされていてもタスクは成功とみなされることがあるからだ。本当に重要な場合は、タスクレポートでファイル数を比較するなど、別途データ検証を行う必要がある。

DataSyncのデータ転送タスクは通常、一度に一つの実行しかできない。もし前の実行が終わる前に、次の実行が開始された場合、その挙動はAWSのドキュメントで確認すべきである。また、DataSyncが転送先S3バケットにヘルパーファイルやメタデータファイルなどの補助的なオブジェクトを書き込むことがある。これらの補助オブジェクトが誤って後続処理をトリガーしないよう、S3オブジェクトイベントのルールで除外することを検討する。

S3のストレージクラスの選択も重要だ。データ転送後すぐにデータが処理されるにもかかわらず、アーカイブ用のストレージクラスに直接書き込むと、最低保存期間の料金が発生し、標準クラスに保存してライフサイクルルールで移行するよりも高額になる可能性がある。

異なるAWSアカウント間での転送や、AWS Key Management Service（KMS）で暗号化されたS3バケットを使用する場合、DataSyncのロケーションロールに適切な権限が付与されていることを確認し、S3バケットポリシーとKMSキーポリシーの両方でアクセスを許可する必要がある。

EventBridgeのルールは、イベントが発生したリージョン（AWSのデータセンターが位置する地域）でなければイベントを検知できない。もしアラートを一元化したい場合は、イベントを他のリージョンのイベントバスに転送することも可能だが、まずはイベントが発生するリージョンにルールを配置する必要がある。

このような基本が確立されれば、さらに便利な自動化を追加できる。 例えば、後続の処理をタイマーではなく、前のDataSyncタスクの成功イベントをトリガーとして開始するよう変更すると、転送完了を待つ不確実な時間差をなくせる。複数のステップからなる複雑な後続処理には、AWS Step Functionsをターゲットとして利用するのが効果的だ。

また、DataSyncのStartTaskExecution APIは、転送対象のファイルやオプションを上書きして実行できる機能がある。これを利用して、通常の夜間転送とは別に、特定のプレフィックス（例えば当日分のデータのみ）だけを転送するようなアドホックなスケジュールを設定することも可能だ。ただし、同じタスクの実行が重複しないよう、スケジュールの時間をずらす必要がある。

最後に、データ転送タスクが失敗した場合はアラートで検知できるが、そもそもタスクが全く開始されなかった場合はどうだろうか。これを検知するために「鮮度チェック」を導入することが有効だ。DataSyncの成功ルールからCloudWatchカスタムメトリクスを発行し、そのメトリクスが一定期間発行されなかった場合にアラートを発するように設定する。これにより、スケジュールが無効になった、Schedulerの権限に問題があった、エージェントがオフラインになった、といったタスク未開始の状況を検知できる。

これらの設定は全て、TerraformやCloudFormationといった「Infrastructure as Code」（コードによるインフラ管理）ツールを使って定義することが望ましい。これにより、設定変更時に意図しない上書きが発生するのを防ぎ、設定の単一オーナーシップを確保できる。

特に、最初に失敗ルールと鮮度チェックを設定することが重要である。これらを組み合わせることで、データ転送が失敗した場合、あるいは全く開始されなかった場合の二つの主要な問題を見逃さずに検知できるようになる。