はじめに
以前、既存の連携基盤が抱えるファイルサイズ上限の課題に対して、Storage Transfer Service(STS)によるS3→GCS移行を選択肢の一つとして調査した話を書きました。その調査の過程で、STSの基本的な機能や、比較的新しく使えるようになった「イベント駆動転送」についても理解を深めたので、今回はSTSそのものの基礎知識として整理しておきます。
Storage Transfer Serviceとは
Storage Transfer Service(STS)は、Google Cloudが提供するマネージドのデータ転送サービスです。主な用途は以下のような、ストレージ間でのデータ移動です。
- Amazon S3やAzure Blob StorageなどのほかクラウドからCloud Storageへのデータ転送
- オンプレミスのファイルシステムからCloud Storageへのデータ転送(専用のエージェントを使用)
- Cloud Storageバケット間でのデータ転送・レプリケーション
自前でスクリプトを組んでAPI経由でファイルをコピーすることもできますが、STSを使うことで、スケジューリング・リトライ・進捗のモニタリングといった機能をマネージドサービスとして利用できるのがメリットです。
転送のトリガー方式:バッチとイベント駆動
STSの転送ジョブは、大きく分けて2つの起動方式があります。
バッチ転送(スケジュール実行)
従来からある方式で、決まった時刻・頻度で転送ジョブを実行する方式です。1回・毎日・毎週といった単位でスケジュールを組み、指定したタイミングで転送元と転送先の差分を確認しながらデータをコピーします。
大量のオブジェクトがあるバケットの場合、転送のたびに転送元・転送先の一覧を取得する「Discovery」処理に時間がかかることがあり、これがバッチ転送における一つの制約になります。
イベント駆動転送
比較的新しく使えるようになった方式で、転送元バケットでオブジェクトが作成・更新されたタイミングをトリガーとして、ほぼリアルタイムで転送を実行するというものです。
仕組みとしては、転送元のバケットにPub/Subの通知設定を行い、オブジェクトの変更があった際にPub/Subのトピックへメッセージが送られるようにします。STSはそのPub/Subのサブスクリプションを購読しており、通知を受け取ると自動的に該当オブジェクトの転送を実行します。
このイベント駆動方式には、以下のような特徴があります。
- 転送元の変更をトリガーにするため、バッチ転送のような「一覧取得(Discovery)」処理が不要になり、時間とコストを節約できる
- 変更検知から転送までがほぼリアルタイムで行われるため、データの鮮度が求められる用途(低RPOでのバックアップ、イベント駆動の分析基盤など)に向いている
- オブジェクトの作成・更新は検知できるが、削除は検知されない(転送元で削除しても、転送先のオブジェクトは削除されない)
- Cloud Storage間の転送だけでなく、S3を転送元とする場合にもイベント駆動の仕組みが利用できる(S3側はSQSの通知を使う)
どんな場面で使い分けるか
バッチ転送とイベント駆動転送は、用途によって向き不向きがあります。
- 定期的なバックアップや、大量データの一括移行:バッチ転送の方がシンプルで、スケジュールに沿った運用がしやすい
- データが発生するたびに、できるだけ早く反映させたい(例:分析基盤へのニアリアルタイム連携、災害対策用のレプリケーション):イベント駆動転送が向いている
イベント駆動転送は「変更があったら即座に転送する」という性質上、既存のバッチ処理を前提とした運用フローに組み込む場合は、削除が反映されない点や、Pub/Subまわりの権限設定が必要な点など、事前に押さえておくべき制約もあります。
まとめ
- Storage Transfer Serviceは、他クラウドやオンプレミス、Cloud Storageバケット間のデータ転送をマネージドで行うサービス
- 転送のトリガー方式には、スケジュールに沿って実行する「バッチ転送」と、変更をトリガーに実行する「イベント駆動転送」の2種類がある
- イベント駆動転送はPub/Sub通知を使い、S3を転送元とする場合にも利用できる。ただし削除は検知されないなどの制約もある
用途に応じてどちらの方式が適しているかを見極めることが、STSを使いこなす上でのポイントになりそうです。