Storage Transfer Service のイベントドリブン転送のパフォーマンスを測定してみた

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

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

https://dev.classmethod.jp/articles/storage-transfer-service-event-driven/

この機能を使うと、Amazon S3 へのファイルアップロードをトリガーに Storage Transfer Service の転送が実行され、Google Cloud Storage（GCS）へファイルを転送できます。

一方で、S3 にアップロードされてから GCS に転送されるまでの所要時間や、大量のファイルが一度にアップロードされた場合の遅延・取りこぼしの有無は確認しておきたいポイントです。

本記事では、これらを実際に測定します。

前提

• 本検証では、Storage Transfer Service のイベントドリブン転送を用いて、S3 から GCS への転送のパフォーマンスを測定する。
• 利用するリソースは、以下のブログと同一の構成を使用する。
  • Storage Transfer Service のイベントドリブン転送を試してみた
• 各検証では、S3 上の 100MB のオブジェクト 1500 個を GCS へ転送する。
• 遅延は「S3 にオブジェクトが作成されてから、GCS にオブジェクトが作成されるまでの時間」とし、以下の式で算出する。
  • 遅延 = GCS timeCreated − S3 LastModified
• 遅延は秒単位で算出し、ミリ秒は四捨五入する。
• 検証結果は、各オブジェクトの遅延の平均値・中央値・最小値・最大値で評価する。
• 各検証項目はそれぞれ 1 回ずつ実行する。
  • （複数回実施したかったけどファイルサイズが大きいせいでアウトバウンドの料金が...）

検証項目

1. aws s3 cp（直列実行）でオブジェクトをコピーし、イベントを発火させる
2. aws s3 cp --recursive でオブジェクトを一括コピーし、イベントを発火させる
3. クライアントライブラリの s3.copy_object でオブジェクトを短時間に大量コピーし、イベントを発火させる

検証結果

1. 直列コピーでイベントを発火

以下のコマンドで、aws s3 cp を直列に実行して検証用ファイルをコピーします。

BUCKET="cm-hanzawa-sts-src-bucket"
PREFIX="test1"
SRC="sample.csv" # 100MB

for i in $(seq -w 1 1500); do
  dst="s3://${BUCKET}/${PREFIX}/sample_${i}.csv"
  aws s3 cp "${SRC}" "${dst}"
done

件数確認（S3 / GCS）

# S3（転送元）
aws s3 ls s3://cm-hanzawa-sts-src-bucket/test1/ | wc -l
> 1500

# GCS（転送先）
gcloud storage ls gs://cm-hanzawa-sts-dst-bucket/test1/ | wc -l
> 1500

集計結果（平均値 / 中央値 / 最小値 / 最大値）

平均値：17 秒
中央値：17 秒

最小値：7 秒
最大値：2 分 14 秒

全体分布（X 軸：遅延、Y 軸：件数）

2. 並列コピーでイベントを発火

以下のコマンドで、aws s3 cp --recursive により検証用ファイルを並列にコピーします。

export AWS_MAX_CONCURRENCY=50

BUCKET="cm-hanzawa-sts-src-bucket"
FROM="test1"
TO="test2"

aws s3 cp "s3://${BUCKET}/${FROM}/" "s3://${BUCKET}/${TO}/" --recursive

件数確認（S3 / GCS）

# S3（転送元）
aws s3 ls s3://cm-hanzawa-sts-src-bucket/test2/ | wc -l
> 1500

# GCS（転送先）
gcloud storage ls gs://cm-hanzawa-sts-dst-bucket/test2/ | wc -l
> 1500

集計結果（平均値 / 中央値 / 最小値 / 最大値）

平均値：19 秒
中央値：19 秒

最小値：8 秒
最大値：1 分 16 秒

全体分布（X 軸：遅延、Y 軸：件数）

3. copy_object でイベントを短時間に大量発火

ここでは、S3 クライアントライブラリの copy_object を用いて、イベントを短時間に大量発生させた場合の挙動を確認します。
1500 ファイル分の処理リクエストを SQS キューに投入し、SQS をトリガーに起動した Lambda でコピーを実行します。

import json
import boto3
from botocore.config import Config

REGION = "ap-northeast-1"
BUCKET = "cm-hanzawa-sts-src-bucket"
SRC_KEY = "seed/sample.csv"

cfg = Config(retries={"max_attempts": 10, "mode": "standard"})
s3 = boto3.client("s3", region_name=REGION, config=cfg)

def handler(event, context):
    for r in event.get("Records", []):
        body = json.loads(r["body"])
        dst_key = body["dst_key"]

        s3.copy_object(
            Bucket=BUCKET,
            Key=dst_key,
            CopySource={"Bucket": BUCKET, "Key": SRC_KEY},
        )

    return {"processed": len(event.get("Records", []))}

件数確認（S3 / GCS）

# S3（転送元）
aws s3 ls s3://cm-hanzawa-sts-src-bucket/test3/ | wc -l
> 1500

# GCS（転送先）
gcloud storage ls gs://cm-hanzawa-sts-dst-bucket/test3/ | wc -l
> 1500

集計結果（平均値 / 中央値 / 最小値 / 最大値）

平均値：25 秒
中央値：21 秒

最小値：7 秒
最大値：2 分 3 秒

全体分布（X 軸：遅延、Y 軸：件数）

考察

• 試行回数は少ないが、3パターンとも S3/GCS の件数は一致しており、少なくとも 1500 件規模では未転送は確認できなかった。
• 平均・中央値はいずれも近い値で、パターンによる差は大きくなかった。この結果から、今回の条件では、ファイル作成の頻度によって遅延が大きく変わる可能性は低いと考えられる。
• 一方で最大遅延は 1〜2 分程度まで伸びるケースがあり、下流の処理は数分程度の遅延を許容する設計にしておくのが安全だと考えられる。

終わりに

本記事では、Storage Transfer Service のイベントドリブン転送のパフォーマンスを測定しました。
数秒単位のリアルタイム性が求められる用途には向かない可能性がありますが、1〜2 分程度の遅延を許容できるのであれば、有力な選択肢になりそうです。

参考になれば幸いです。