Storage Transfer Service のイベントドリブン転送を試してみた

データ事業本部のはんざわです。

Google Cloud には、Amazon S3 や Azure Blob Storage などの他社クラウドや Google Cloud Storage 間でファイルを転送できる「Storage Transfer Service（STS）」というサービスがあります。

STS はマネージドかつサーバレスなサービスで、転送ジョブ自体の利用料は無料です。（他クラウドからの転送の場合、転送元でのアウトバウンド通信費や、GCS 側でのオペレーション費用等は別途発生します。）

STS の転送パターンには、「定期転送」と「イベントドリブン転送」の 2 つの方法が存在します。

今回のブログでは、「イベントドリブン転送」の設定方法と挙動を試してみたいと思います。

イベントドリブン転送とは？

https://docs.cloud.google.com/storage-transfer/docs/event-driven-transfers?hl=ja

イベントドリブン転送では、ソースとなるバケットでのファイル配置（作成や更新）イベントを検知し、その変更をトリガーとして自動的に転送を実行します。
そのため、ニアリアルタイムなデータ連携が必要なシーンで有効な機能です。

投稿日時点で、イベントドリブン転送に対応している転送元オブジェクトストレージは以下の 2 つです。

• Google Cloud Storage（Pub/Sub を利用）
• Amazon S3（Amazon SQS を利用）

STS がこれらのメッセージキュー（Pub/Sub や SQS）を監視し、新しいイベントを受け取ると転送ジョブが走る仕組みです。

試してみる

https://docs.cloud.google.com/storage-transfer/docs/event-driven-aws?hl=ja

さっそく上記ドキュメントを参考に、実際に試してみたいと思います。

1. AWS 側の準備

1.1. Amazon S3 バケットの作成

まずは、転送元となる S3 バケットを作成します。
設定項目と設定内容は以下の表のとおりです。これ以外の項目はデフォルトのまま作成しました。

1.2. SQS キューの作成

次に、S3 からのイベント通知を受け取る SQS キューを作成します。

{
  "Version": "2012-10-17",
  "Id": "S3-Notification",
  "Statement": [
    {
      "Sid": "Allow-S3-SendMessage",
      "Effect": "Allow",
      "Principal": {
        "Service": "s3.amazonaws.com"
      },
      "Action": "SQS:SendMessage",
      "Resource": "arn:aws:sqs:ap-northeast-1:<AWS_ACCOUNT_ID>:cm-hanzawa-sts-queue",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "<AWS_ACCOUNT_ID>"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:s3:::cm-hanzawa-sts-src-bucket"
        }
      }
    }
  ]
}

1.3. S3 バケットの通知を有効化

1.1 で作成した S3 バケットに対して、イベント通知の設定を行います。

1.4. IAM ポリシーの作成

続いて、IAM ロールに付与する IAM ポリシーを作成します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sqs:DeleteMessage",
                "sqs:ChangeMessageVisibility",
                "sqs:ReceiveMessage",
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::cm-hanzawa-sts-src-bucket",
                "arn:aws:s3:::cm-hanzawa-sts-src-bucket/*",
                "arn:aws:sqs:ap-northeast-1:<AWS_ACCOUNT_ID>:cm-hanzawa-sts-queue"
            ]
        }
    ]
}

1.5. IAM ロールの作成

最後に、STS が利用する IAM ロールを作成します。

STS が AWS にアクセスする際の認証方法は、大きく分けて以下の 2 つがあります。

1. アクセスキーとシークレットキーを使用する方法（IAM ユーザー）
2. Identity Federation を使用する方法（IAM ロール）

今回は、アクセスキーの管理が不要で、よりセキュアな方式 2 を採用します。

事前準備：Google Service Account の Subject ID 確認

IAM ロールの信頼ポリシー設定に必要な SUBJECT_ID を取得します。
以下の API リファレンスページにある「Try this method」パネルから Google Cloud のプロジェクト ID を入力し、Execute をクリックして確認できます。

https://docs.cloud.google.com/storage-transfer/docs/reference/rest/v1/googleServiceAccounts/get

レスポンス内の subjectId の値を控えておきます。

IAM ロールの設定

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "accounts.google.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "accounts.google.com:sub": "<SUBJECT_ID>"
        }
      }
    }
  ]
}

2. Google Cloud 側の準備

AWS 側の設定が完了したら Google Cloud 側の設定に移ります。

2.1. Google Cloud Storage バケットの作成

まずは、転送先となる GCS バケットを作成します。

2.2. Storage Transfer Service の作成

いよいよ STS の転送ジョブを以下の内容で作成します。

3. 実際に動かしみてる

設定が完了したので、実際に動かしてみます。
試しに、転送元の S3 バケットにファイルを 4 つアップロードしてみます。

アップロード後、STS のコンソールを確認すると、イベントを検知してすぐに転送ジョブが開始されました。
しばらく待つと、ステータスが「完了」になりました。

最後に、転送先の Cloud Storage バケットを確認してみます。
期待通り、S3 にアップロードした 4 つのファイルが転送されていることが確認できました。

終わりに

今回のブログでは、Storage Transfer Service のイベントドリブン転送を試してみました。

定期転送の場合、最短でも 1 時間に 1 回の頻度でしか実行することができません。これよりも短い頻度で実行したい場合やニアリアルタイム性が求められる場合は有用な機能だと思います。

また、以下のような課題の解決策としても有効です。

S3 転送の時間ベースのフィルタは、AWS の「最終更新日時」の定義（オブジェクトのアップロードが開始された時刻）に依存します。オブジェクトはアップロードが完了するまで使用できないため、最終更新日時がフィルタ条件を満たしているにもかかわらず、まだアップロード中のオブジェクトが見つかることがあります。これらのオブジェクトは転送ジョブに含まれません。問題を回避するため、次のことをおすすめします。

• 時間ベースのフィルタの代わりに、イベント ドリブン転送を使用して、オブジェクトが使用可能になったときに転送します。
• 定期的な転送でオブジェクトが欠落しないようにするには、「最終更新日時」のルックバック ウィンドウを定期的なスケジュールよりも長くする必要があります。たとえば、1 時間ごとに実行されるジョブの場合、2 時間のルックバック ウィンドウでバッファが提供されます。

参考：転送オプション

本ブログが参考になれば幸いです。