Amazon Web Services ブログ
Amazon S3 Tables のレプリケーションサポートと Intelligent-Tiering の発表
2025 年 12 月 2 日、 Amazon S3 Tables の 2 つの新機能を発表しました。1 つは、アクセスパターンに基づいてコストを自動的に最適化する新しい Intelligent-Tiering ストレージクラスのサポート、もう 1 つは、手動同期なしで AWS リージョンやアカウント間で一貫性のある Apache Iceberg テーブルレプリカを自動的に維持するレプリケーションサポートです。
表形式のデータを扱う組織は、2 つの共通の課題に直面しています。まず、データセットが増大し、アクセスパターンが時間の経過とともに変化するにつれて、ストレージコストを手動で管理する必要があるということです。次に、リージョンやアカウント間で Iceberg テーブルのレプリカを管理する場合、更新の追跡、オブジェクトレプリケーションの管理、メタデータ変換の処理を行うための複雑なアーキテクチャを構築して維持する必要があるということです。
S3 Tables Intelligent-Tiering ストレージクラス
S3 Tables Intelligent-Tiering ストレージクラスでは、データはアクセスパターンに基づいて最も費用対効果の高いアクセスティアに自動的にティア化されます。データは、高頻度アクセス、低頻度アクセス (高頻度アクセスよりも 40% 低コスト) 、およびアーカイブインスタントアクセス (低頻度アクセスと比較して 68% 低コスト) の 3 つの低レイテンシーティアに保存されます。30 日間アクセスできない場合、データは低頻度アクセスに移動し、90 日後にアーカイブインスタントアクセスに移動します。これは、アプリケーションを変更したり、パフォーマンスに影響を与えたりすることなく行われます。
コンパクション、スナップショットの有効期限、未参照ファイルの削除などのテーブルメンテナンスアクティビティは、データのアクセスティアに影響を与えずに動作します。コンパクションは、高頻度アクセスティアのデータのみを自動的に処理し、頻繁にクエリされるデータのパフォーマンスを最適化すると同時に、低コストのティアではコールドファイルをスキップすることでメンテナンスコストを削減します。
デフォルトでは、既存のすべてのテーブルは標準ストレージクラスを使用します。新しいテーブルを作成するときは、ストレージクラスとして Intelligent-Tiering を指定することも、テーブルバケットレベルで設定されたデフォルトのストレージクラスを使用することもできます。Intelligent-Tiering をテーブルバケットのデフォルトストレージクラスとして設定すると、作成時にストレージクラスが指定されなかった場合に Intelligent-Tiering に自動的にテーブルを格納できます。
仕組みを見ていきましょう
AWS コマンドラインインターフェイス (AWS CLI)、put-table-bucket-storage-class コマンドと get-table-bucket-storage-class コマンドを使用して、S3 Tables バケットのストレージティアを変更または検証できます。
# ストレージクラスを変更
aws s3tables put-table-bucket-storage-class \
--table-bucket-arn $TABLE_BUCKET_ARN \
--storage-class-configuration storageClass=INTELLIGENT_TIERING
# ストレージクラスを検証
aws s3tables get-table-bucket-storage-class \
--table-bucket-arn $TABLE_BUCKET_ARN \
{ "storageClassConfiguration":
{
"storageClass": "INTELLIGENT_TIERING"
}
}S3 Tables レプリケーションサポート
新しい S3 Tables レプリケーションサポートにより、AWS リージョンやアカウント全体でテーブルのリードレプリカの一貫性を維持できます。宛先テーブルバケットを指定すると、サービスは読み取り専用のレプリカテーブルを作成します。親子スナップショットの関係を維持しながら、すべての更新を時系列で複製します。テーブルレプリケーションは、グローバルデータセットを構築して、地理的に分散したチームのクエリ待ち時間を最小限に抑え、コンプライアンス要件を満たし、データ保護を実現するのに役立ちます。
ソーステーブルと同様のクエリパフォーマンスを提供するレプリカテーブルを簡単に作成できるようになりました。レプリカテーブルはソーステーブルが更新されてから数分以内に更新され、ソーステーブルとは独立した暗号化および保持ポリシーをサポートします。レプリカテーブルは、Amazon SageMaker Unified Studio、または DuckDB、PyIceberg、Apache Spark、Trino などの任意の Iceberg 互換エンジンを使用してクエリできます。
AWS マネジメントコンソールまたは API と AWS SDK を使用して、テーブルのレプリカを作成および管理できます。ソーステーブルをレプリケートするデスティネーションテーブルバケットを 1 つ以上指定します。レプリケーションを有効にすると、S3 Tables はターゲットテーブルバケットに読み取り専用のレプリカテーブルを自動的に作成し、ソーステーブルの最新の状態でバックフィルし、レプリカの同期を維持するために新しい更新を継続的にモニタリングします。これにより、データの複数のレプリカを維持しながら、タイムトラベルや監査の要件を満たすことができます。
仕組みを見ていきましょう
その仕組みを説明するために、3 つのステップに分けて説明します。まず、S3 Tables バケットを作成し、Iceberg テーブルを作成し、データを入力します。次に、レプリケーションを設定します。次に、レプリケートされたテーブルに接続してデータをクエリし、変更がレプリケートされたことを示します。
このデモでは、S3 チームがすでにプロビジョニングされている Amazon EMR クラスターへのアクセスを提供してくれました。Amazon EMR のドキュメントに従って独自のクラスターを作成できます。また、レプリケーション元とレプリケーション先の 2 つの S3 Tables バケットも作成しました。繰り返しになりますが、S3 テーブルのドキュメントは始めるのに役立ちます。
2 つの S3 Tables バケットの Amazon リソースネーム (ARN) をメモしておきます。このデモでは、これらを環境変数 SOURCE_TABLE_ARN と DEST_TABLE_ARN と呼んでいます。
ステップ 1: ソースデータベースを準備する
ターミナルを起動し、EMR クラスターに接続し、Spark セッションを開始し、テーブルを作成し、データ行を挿入します。このデモで使用するコマンドは、「Amazon S3 Tables Iceberg REST エンドポイントを使用したテーブルへのアクセス」に記載されています。
sudo spark-shell \
--packages "org.apache.iceberg:iceberg-spark-runtime-3.5_2.12:1.4.1,software.amazon.awssdk:bundle:2.20.160,software.amazon.awssdk:url-connection-client:2.20.160" \
--master "local[*]" \
--conf "spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions" \
--conf "spark.sql.defaultCatalog=spark_catalog" \
--conf "spark.sql.catalog.spark_catalog=org.apache.iceberg.spark.SparkCatalog" \
--conf "spark.sql.catalog.spark_catalog.type=rest" \
--conf "spark.sql.catalog.spark_catalog.uri=https://s3tables.us-east-1.amazonaws.com/iceberg" \
--conf "spark.sql.catalog.spark_catalog.warehouse=arn:aws:s3tables:us-east-1:012345678901:bucket/aws-news-blog-test" \
--conf "spark.sql.catalog.spark_catalog.rest.sigv4-enabled=true" \
--conf "spark.sql.catalog.spark_catalog.rest.signing-name=s3tables" \
--conf "spark.sql.catalog.spark_catalog.rest.signing-region=us-east-1" \
--conf "spark.sql.catalog.spark_catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO" \
--conf "spark.hadoop.fs.s3a.aws.credentials.provider=org.apache.hadoop.fs.s3a.SimpleAWSCredentialProvider" \
--conf "spark.sql.catalog.spark_catalog.rest-metrics-reporting-enabled=false"
spark.sql("""
CREATE TABLE s3tablesbucket.test.aws_news_blog (
customer_id STRING,
address STRING
) USING iceberg
""")
spark.sql("INSERT INTO s3tablesbucket.test.aws_news_blog VALUES ('cust1', 'val1')")
spark.sql("SELECT * FROM s3tablesbucket.test.aws_news_blog LIMIT 10").show()
+-----------+-------+
|customer_id|address|
+-----------+-------+
| cust1| val1|
+-----------+-------+ここまでは順調です。
ステップ 2: S3 Tablesのレプリケーションを設定する
今は、ラップトップの CLI を使用して S3 Tables バケットレプリケーションを設定します。
その前に、AWS Identity and Access Management (IAM) ポリシーを作成して、レプリケーションサービスに S3 Tablesバケットと暗号化キーへのアクセスを許可します。詳細については、S3 Tables レプリケーションドキュメントを参照してください。このデモで使用した権限は次のとおりです。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*",
"s3tables:*",
"kms:DescribeKey",
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*"
}
]
}この IAM ポリシーを作成したら、レプリケーションを続行して設定できます。
aws s3tables-replication put-table-replication \
--table-arn ${SOURCE_TABLE_ARN} \
--configuration '{
"role": "arn:aws:iam::<MY_ACCOUNT_NUMBER>:role/S3TableReplicationManualTestingRole",
"rules":[
{
"destinations": [
{
"destinationTableBucketARN": "${DST_TABLE_ARN}"
}]
}
]
レプリケーションが自動的に開始されます。通常、更新は数分以内に複製されます。完了までにかかる時間は、ソーステーブルのデータ量によって異なります。
ステップ 3: レプリケートされたテーブルに接続してデータをクエリする
ここで、EMR クラスターに再接続し、2 つ目の Spark セッションを開始します。今回は、レプリケーション先テーブルを使用します。
レプリケーションが正常に動作することを確認するために、ソーステーブルに 2 行目のデータを挿入します。
spark.sql("INSERT INTO s3tablesbucket.test.aws_news_blog VALUES ('cust2', 'val2')")
レプリケーションがトリガーされるまで数分待ちます。get-table-replication-status コマンドを使用してレプリケーションのステータスを確認します。
aws s3tables-replication get-table-replication-status \
--table-arn ${SOURCE_TABLE_ARN} \
{
"sourceTableArn": "arn:aws:s3tables:us-east-1:012345678901:bucket/manual-test/table/e0fce724-b758-4ee6-85f7-ca8bce556b41",
"destinations": [
{
"replicationStatus": "pending",
"destinationTableBucketArn": "arn:aws:s3tables:us-east-1:012345678901:bucket/manual-test-dst",
"destinationTableArn": "arn:aws:s3tables:us-east-1:012345678901:bucket/manual-test-dst/table/5e3fb799-10dc-470d-a380-1a16d6716db0",
"lastSuccessfulReplicatedUpdate": {
"metadataLocation": "s3://e0fce724-b758-4ee6-8-i9tkzok34kum8fy6jpex5jn68cwf4use1b-s3alias/e0fce724-b758-4ee6-85f7-ca8bce556b41/metadata/00001-40a15eb3-d72d-43fe-a1cf-84b4b3934e4c.metadata.json",
"timestamp": "2025-11-14T12:58:18.140281+00:00"
}
}
]
}レプリケーションのステータスが ready と表示されたら、EMR クラスターに接続し、レプリケーション先テーブルにクエリを実行します。予想どおり、新しいデータ行が表示されました。
その他の情報
他にも注意すべき点がいくつかあります。
- S3 Tables のレプリケーションは、Apache Iceberg V2 と V3 の両方のテーブル形式をサポートしているため、テーブル形式を柔軟に選択できます。
- テーブルバケットレベルでレプリケーションを設定できるため、個々のテーブルを設定しなくても、そのバケット内のすべてのテーブルを簡単にレプリケートできます。
- レプリカテーブルでは、ターゲットテーブル用に選択したストレージクラスが維持されるため、特定のコストとパフォーマンスのニーズに合わせて最適化できます。
- Iceberg 互換のカタログであれば、追加の調整なしでレプリカテーブルを直接クエリできます。レプリカテーブルの場所を指定するだけで済みます。これにより、クエリエンジンとツールを柔軟に選択できます。
料金と利用可能なリージョン
AWS のコストと使用状況レポートと Amazon CloudWatch メトリクスを通じて、アクセスティアごとにストレージの使用状況を追跡できます。レプリケーションモニタリング用に、AWS CloudTrail ログはレプリケートされた各オブジェクトのイベントを提供します。
Intelligent-Tiering の設定に追加料金はかかりません。お支払いいただくのは、各ティアのストレージコストのみです。テーブルは引き続き以前と同じように機能し、アクセスパターンに基づいて自動的にコストが最適化されます。
S3 Tables レプリケーションでは、デスティネーションテーブルのストレージ、レプリケーション PUT リクエスト、テーブル更新 (コミット)、およびレプリケートされたデータのオブジェクトモニタリングの料金を S3 Tables に支払います。クロスリージョンテーブルレプリケーションの場合、Amazon S3 から宛先リージョンへのリージョン間データ転送の料金も、リージョンペアに基づいてお支払いいただきます。
通常どおり、詳細については Amazon S3 料金表ページを参照してください。
現在、どちらの機能も S3 Tables がサポートされているすべての AWS リージョンで利用できます。
これらの新機能の詳細については、Amazon S3 Tables ドキュメントを参照するか、 Amazon S3 コンソールで今すぐ試してみてください。Amazon S3 用 AWS re:Post を通じて、または AWS サポートの連絡先を通じてフィードバックを共有してください。
原文はこちらです。