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 サポートの連絡先を通じてフィードバックを共有してください。 — seb 原文は こちら です。

Amazon Web Services (AWS) が Savings Plans を導入して以来、お客様はアカウント、リソースタイプ、 AWS リージョン にわたる使用量を柔軟に管理しながら、持続的なワークロードを実行するコストを削減できるようになりました。2025 年 12 月 2 日、この柔軟な価格モデルを AWS マネージドデータベースサービスにも拡大し、Database Savings Plans を開始しました。これにより、お客様は 1 年間 にわたって一定の使用量 (USD/1 時間) を維持することで、データベースコストを最大 35% 削減できます。割引額は、サポートされているデータベースサービスの対象となる使用量に 1 時間ごとに自動的に適用され、コミットメントを超える追加使用分はオンデマンド料金で請求されます。 組織がデータ主導型アプリケーションや AI アプリケーションを構築および管理する際、進化するビジネスニーズを満たすために、インスタンスベースやサーバーレスオプションなど、さまざまなデータベースサービス、エンジン、デプロイタイプを使用することがよくあります。データベース Savings Plansでは、コスト効率を維持しながらワークロードの実行方法を柔軟に選択できます。お客様が移行またはモダナイズの取り組みを行っている最中であれば、継続的なコスト最適化の一環として、データベースエンジンを切り替えたり、デプロイタイプをプロビジョニング型からサーバーレス型に調整したりできます。また、引き続き割引料金が適用されます。お客様のビジネスがグローバルに拡大した場合でも、AWS リージョン間で利用をシフトし、同じ取り組みから引き続き恩恵を受けることができます。一貫した時間単位のコミットメントを適用することで、顧客は使用パターンが変化しても予測可能な支出を維持し、使い慣れたコスト管理ツールを使用して対象範囲と使用率を分析できます。 新しい Savings Plans 各プランでは、価格の適用範囲、利用可能な割引の範囲、サポートされるデータベースエンジン、インスタンスファミリー、サイズ、デプロイオプション、AWS リージョン全体で提供される柔軟性のレベルが定義されています。 時間単位のコミットメントは、リージョンに関係なく、すべての対象となる使用量に自動的に適用されます。対象サービスには、 Amazon Aurora 、 Amazon Relational Database Service (Amazon RDS) 、 Amazon DynamoDB 、 Amazon ElastiCache 、 Amazon DocumentDB (MongoDB 互換) 、 Amazon Neptune 、 Amazon Keyspaces (Apache Cassandra 向け) 、 Amazon Timestream 、および AWS Database Migration Service (AWS DMS) が含まれます。対象となる新しいデータベースサービス、インスタンスタイプ、またはリージョンが利用可能になると、Savings Plans が自動的にその使用量に適用されます。 割引はデプロイモデルとサービスタイプによって異なります。サーバーレスデプロイメントは、オンデマンド料金と比較して最大 35% 節約できます。サポートされているデータベースサービス全体でインスタンスをプロビジョニングすると、最大 20% の節約になります。Amazon DynamoDB と Amazon キースペースでは、オンデマンドのスループットワークロードが最大 18% 節約され、プロビジョニングされたキャパシティーでは最大 12% 節約できます。これらの削減効果を組み合わせることで、お客様はデータベースの使用範囲を一定に保ちながらコストを最適化できます。価格と対象となる使用方法の詳細については、 データベース Savings Plans の料金ページ をご覧ください。 データベース Savings Plans の購入 AWS Billing and Cost Management コンソール は、Savings Plans の選択を支援し、購入プロセスをガイドします。 AWS マネジメントコンソール または AWS コマンドラインインターフェイス (AWS CLI) から SimSpace Weaver の使用を開始できます。データベース Savings Plans の購入を評価するには、[推奨事項] ビューとPurchase Analyzerの 2 つの方法があります。 推奨事項 — 最近のオンデマンド使用状況から自動的に生成されます。 Billing and Cost Management コンソール の [推奨事項] ビューにアクセスするには、ナビゲーションペインで [節約とコミットメント] 、 [Savings Plans] 、および [推奨事項] を選択します。 [推奨事項] ビューで、 [データベース Savings Plans] を選択し、 推奨事項オプション を設定します。AWS Savings Plans の推奨事項では、過去のオンデマンド使用量を分析して、全体的に最も節約できる時間単位のコミットメントを特定します。 Purchase Analyzer — カスタムコミットメントレベルをモデル化するために設計されています。 [Purchase Analyzer] ページの推奨コミットメントとは異なる金額を購入する場合は、 [データベース Savings Plans] を選択し、 [ルックバック期間] と [時間単位のコミットメント] を設定して代替コミットメントレベルをシミュレートし、 [コスト] 、 [カバレッジ] 、 [使用率] に対して予測される影響を確認します。 この方法は、購入戦略で時間が経つにつれてより小規模で段階的なコミットメントが含まれる場合や、将来の使用量の変化が理想的な購入金額に影響することが予想される場合に適しています。 [Savings Plans の推奨事項] または [Savings Plans Purchase Analyzer] で推奨事項を確認するか、シミュレーションを実行した後、 [カートに追加] を選択して選択したコミットメントを続行します。直接購入したい場合は、 [Savings Plans を購入] ページに移動することもできます。コンソールでは、各設定を調整すると推定割引率と補償範囲がリアルタイムで更新されるため、注文を完了する前に影響を評価できます。 データベース Saving Plans を選択して購入する方法の詳細については、「 Savings Plans ユーザーガイド 」のドキュメントをご覧ください。 今すぐご利用いただけます データベースの Savings Plans は、中国以外のすべての AWS リージョンで利用できます。ぜひ試してみて、より柔軟でコストも予測可能なデータベース戦略の構築を始めましょう。 – Betty 原文は こちら です。

本記事は、2025 年 10 月 14 日に公開された “ Fine-tuning player latency with Amazon GameLift Servers ” を翻訳したものです。翻訳は Technical Account Manager の西岡美穂が担当しました。 マルチプレイヤーオンラインゲームをローンチしたことがある方なら、レイテンシーに関するフォーラムでの苦情ほどイライラさせられる（そしておそらく避けられない）ものはないことをご存知でしょう。運営側が影響を与えることができる問題（サーバーの近接性やコードの最適化）と、コントロールできない問題（プレイヤー側のハードウェアの性能不足やネットワークの問題）を切り分けることは困難です。 本記事では、 Amazon GameLift Servers の機能を活用したゲームタイトルのレイテンシーの測定と改善方法について説明します。Amazon GameLift Servers は、クラウド上にセッションベースのマルチプレイヤーゲーム専用の低コストサーバーをデプロイ、運用、およびスケールするために使用されます。 シミュレートされたプレイヤーのトラフィックパターンと異なるリージョンの デプロイ設定 の分析を通じて、プレイヤーのゲーム体験を最適化するための実用的なソリューションを示します。 成功したゲームローンチ あなたのゲームは開発後、ついにリリースされ急速な成長を遂げています : インストールベースは予想を超え、同時接続ユーザ数（CCU）は常に 300,000 を超えてピークに達しています。しかし、一部のプレイヤーはレイテンシーと応答性の問題を報告しています。これには、プレイヤーのローカルなインターネット環境、広範なインターネットの問題、最適化されていないサーバーコードなど、いくつかの異なる原因が考えられます。 原因がコントロール可能なものか否かをどのように判断し、プレイヤーが可能な限り最高の体験を得られるためには何をする必要があるでしょうか? 最初のステップは、ゲームサーバーのロケーションに対するプレイヤーのレイテンシーを測定することです。これには Amazon GameLift Servers の UDP ping ビーコン が役立ちます。Amazon GameLift Servers のビーコンエンドポイントは、Amazon Web Services（AWS）のグローバルリージョンおよびローカルゾーン全てで利用可能です。ゲームサーバーがどこにデプロイされていても、プレイヤーからサーバーまでのレイテンシーを正確に測定できます。多くのレイテンシーに敏感なゲームは UDP プロトコルを使用するため、UDP ping ビーコンは現実的なレイテンシー測定を提供します。 ベストプラクティスとサンプルコード を使用すると、実装は簡単です。これらのビーコンからの正確なレイテンシーデータを利用することで、より公平なマッチメイキング体験を作成したり、プレイヤーの接続不良が発生するインスタンスを減らすことができます。リージョンへの ping が 150 ミリ秒のプレイヤーが、30 ミリ秒で ping しているプレイヤーと同じゲームに入れられるのは、フラストレーションとなるでしょう。正確なレイテンシー測定は、このようなシナリオを回避するための鍵となります。 注釈：現在運用していないロケーションへのレイテンシーを測定することも有用です。これは、プレイヤーのレイテンシーを改善する可能性のある追加のロケーションを特定するのに役立ち、プレイヤーベースの満足度を高めることを可能にします。 リージョンの選択 ゲームセッションに最適なリージョンを選択することはサーバー管理において重要ですが、トレードオフを慎重に検討する必要があります。Amazon GameLift Servers は、32 のリージョンとローカルゾーンへのアクセスを提供しており（この数は増え続けています）、より多くのプレイヤーに低レイテンシーのエクスペリエンスを提供します。しかし、プレイヤーを最速のロケーションにターゲティングするために必要以上に多くのロケーションで運用すると、マッチメイキングプールが断片化され、マッチ時間が長くなる可能性があります。 例えば、単一のリージョンから 10 の均等に分散されたリージョンに移行すると、各リージョンでマッチを検索するプレイヤー数が 10% になります。これにより、希望するゲームモード、スキルの均等性、ゲームを成立させるのに十分なプレイヤー数などの必要なプロパティを満たすことが難しくなる可能性があります。さらに、ゲームセッションを近隣のロケーションでまとめて統合するのではなく、使用頻度の低い複数のロケーションに分散させると、アイドル状態のサーバーを過剰に保持する可能性があります。 では、ゲームサーバーを実行するためにいくつのリージョンを使用すべきでしょうか？ これを検証するために、5 対 5 で 300,000 CCU のゲームのマッチメイキングをシミュレートしてみましょう。プレイヤーの位置情報と各サーバーリージョンへのレイテンシー測定をシミュレートできます。低レイテンシーのリージョンのいずれかにプレイヤーを配置し、マッチさせる必要があります。 図 1 は、リージョン数を変更した時に各種レイテンシー測定値のプレイヤーの割合がどう変化するか示しています。50 ミリ秒のレイテンシーをゴールにすると、リージョンが 1 つの時は 30% のプレイヤーがこの閾値を達成するのに対し、リージョン設定が 3 つの時は 63% が達成します。注目すべき点の 1 つは、リージョンを追加することにより得られるプレイヤーのエクスペリエンスの向上がある時点からは減少していることです。9 番目のリージョンを追加すると、50 ミリ秒（またはそれ以下）のレイテンシーを達成するプレイヤーが 5% 増加しますが、それを超えると改善は最小限となり、プレイヤーにとっての改善効果は少なくなります。 図 1: 異なるリージョン数でのレイテンシーのパーセンタイル（大規模なゲーム） もう 1 つ注意すべき点は、7 番目または 8 番目のリージョンを追加するのは、そのローカルリージョンでゲームを成立させるのに十分なプレイヤーがいる場合のみ有効だということです。これは、あなたが決断をする必要がある項目です。ゲームのレイテンシーを向上させるために、プレイヤーのマッチ時間が長くなることを受け入れられるのか、レイテンシーにセンシティブなゲームなのか、プレイヤーの規模はどれほどか、などの要因に基づいて判断する必要があります。 比較のため、図 2 では同じ設定を、はるかに小規模な 3,000 CCU のゲームでシミュレートしています。データは、リージョンの数が少ないうちは類似したレイテンシー曲線を示していますが、リージョンを追加しても、300,000 CCU の場合に見られたようなレイテンシーの改善には到達できていません。これは、プレイヤーの参加率がゲームを成立させるのに十分な速さではなく、プレイヤーをあまり望ましくないリージョンに配置せざるを得なくなるためです。重要な点は、両方のテストで同じレイテンシーを達成することは可能ですが、3,000 CCU のケースでは、小規模なリージョンでは最大 100 倍もの時間マッチを待つ必要があるということです。 図 2: 異なるリージョン数でのレイテンシーのパーセンタイル （小規模なゲーム） 最後に、どのリージョンを選択すべきかという問題があります。 説明した例では、リージョンの選択順序は、プレイヤーのシミュレートされたレイテンシーデータの分析に基づいてい決定されていますが、実際の運用では、いくつかの主要な地理的ゾーンにサーバーを配置することから始め、その後、プレイヤーのレイテンシーデータ（UDP Ping ビーコンで測定）の分析に基づいて拡張したいと思うでしょう。 お客様向けに 数百のゲームをホスティングしてきた 10 年の経験に基づいて、出発点として一般的なガイダンスを以下に示します： 3 つまたは 4 つのリージョンが、ほとんどのゲームに適した基本構成です 以下の各エリアから 1 つずつ選択することが、お客様にとって効果的でした： 北米（例：us-east-2 または us-west-2） ヨーロッパ（例：eu-central-1 または eu-west-2） アジア太平洋（例：ap-northeast-1 または ap-northeast-2） さらにリージョンを追加する場合： データがプレイヤー体験に有益なレイテンシー改善を示している場合 ゲームのプレイヤー人口が、断片化の問題を回避できるほど十分に大きい場合 上記で示しているように、プレイヤーベースが大きいと、より多くのリージョンの追加を真剣に検討することになります。これは、既存のリージョンがプレイヤーにとって最速の N リージョンではないケースがどの程度一般的かで評価できます。ここでの N は、ゲームのレイテンシー要件（レイテンシーがクリティカルなゲームではより低く、レイテンシーが許容されるゲームではより高く）によって決定されます。例えば、3 つのリージョンで運用しており、プレイヤーの 60% にとって最速の 2～3 リージョンに既存のリージョンが含まれていないことが判明した場合、改善の余地があると言えます。その場合、そのカバーできていない 60% のプレイヤーに最も近いリージョンへの拡張を優先することになります。 注意点として、同じゲーム人口であっても、すべての人にとって唯一の最適解が存在するわけではありません。プレイヤー数が少ないゲーム（PvP対戦ゲーム）では、一般的でないリージョンでもマッチメイキングが比較的早く成立します。一方、南米で特に人気が高い場合は、その地域にサーバーを配置することが不可欠である可能性があります。 広範囲に及ぶ問題の特定 UDP ping ビーコン を使用することで、すべてのプレイヤーの正確なレイテンシー測定値を受信でき、このデータを使用して世界中のゲームサーバーを合理的かつ最適に配置することができます。これは素晴らしいスタートです。可能な限り、プレイヤーを近くのゲームサーバーに配置することで、ポジティブな体験ができる可能性を最大限に高めます。それが不可能な場合でも、プレイヤーがゲームプレイ中にレイテンシーの問題を経験する可能性が高い状況を特定することができます。 しかし、ゲームプレイの不具合がサーバーサイドの問題なのか、プレイヤーサイドの問題なのか判断できない場合はどうでしょうか。さらにコントロールが難しいケースとして、広範囲にわたるインターネットの問題がゲームに影響を与えている場合はどうでしょうか。サーバー側の視点ではすべてが正常に応答しているように見えるのに、プレイヤーからの苦情が続くのは非常にフラストレーションが溜まる状況です。 プレイヤー固有のレイテンシーに関する苦情を調査する時の出発点は、そのプレイヤーがゲームセッションのリージョンに対してどのようなレイテンシー測定値を示していたかを確認することです。 Amazon GameLift Servers キュー を使用している場合は、配置 ID とプレイヤー ID から開始し、 describe-game-session-placement API を使用してレイテンシーを迅速に検索できます。 以下は、特定のプレースメントリクエストを行うために使用される、プレイヤーのレイテンシーを抽出できる Python スクリプトです： #!/usr/bin/env python3 import boto3 import csv import sys from collections import defaultdict client = boto3.client('gamelift') placement_data = client.describe_game_session_placement(PlacementId=sys.argv[1]) players = defaultdict(dict) regions = set() for p in placement_data['GameSessionPlacement']['PlayerLatencies']: players[p['PlayerId']][p['RegionIdentifier']] = p['LatencyInMilliseconds'] regions.add(p['RegionIdentifier']) regions = sorted(regions) writer = csv.writer(sys.stdout) writer.writerow(['PlayerId'] + regions) for pid, latencies in players.items(): writer.writerow([pid] + [latencies.get(r, '') for r in regions]) このスクリプトを実行すると、次のような出力が得られます： &gt; python3 parse_latencies.py 4484032d-f3ca-4496-b663-31f842f0123d PlayerId,ap-northeast-1,eu-central-1,eu-west-2,us-east-2,us-west-2 player-312,42.0,74.0,65.0,113.0,70.0 player-441,94.0,98.0,113.0,144.0,122.0 出力結果から、そのゲームセッションに参加している各プレイヤーの各リージョンへのレイテンシー（各リージョンのミリ秒単位）を確認できます。最初に確認すべきは、ゲームセッションをホストしているリージョンです。サンプル出力に基づくと、ap-northeast-1 が最も低い平均レイテンシーを示しているようです。また 2 人のプレイヤー間でレイテンシーにかなりの差があります。マッチメイキングにおいてレイテンシーの均等性を優先することは対処する価値があるかもしれません。また、player-441 は、どのリージョンがゲームセッションをホストしても、比較的高いレイテンシーを経験することになることがわかります。もしこのプレイヤーが苦情を申し立てている場合、その体験を改善できる範囲には限界があるかもしれません。 もう 1 つ確認すべき点は、現在サーバーを稼働させていないリージョンが最適なリージョンとなりうるかどうかです。これが一般的なパターンであれば、リージョン拡張の有力な候補を特定できたことになります。最後に、単一のプレイヤーやゲームセッションの範囲を超える問題については、プレイヤーのレイテンシーデータを分析ソリューションに入力して、より詳細な分析を行うことができます（ AWSのGuidance for Game Analytics Pipeline を推奨します）。 Amazon GameLift Servers が提供するもう 1 つのソリューションは、 Amazon CloudWatch Internet Monitor です。Internet Monitor は、広範囲にわたるインターネットのパフォーマンスと、それがゲームに与える影響を測定できます。その結果、Internet Monitor は、より広範なインターネット上の問題を特定できるだけでなく、プレイヤーに大幅なレイテンシー改善をもたらす可能性のある追加または代替のリージョンを提案することもできます。Internet Monitor はデフォルトでは無効になっていますが、Amazon GameLift Servers はお客様と協力してそれを有効にし、ゲームの地理的カバレッジの改善を提案することができます。 図 3 の例は、お客様のレイテンシーを改善する可能性のあるいくつかの提案を示しています。これはレイテンシーを TTFB（Time to First Byte：最初のバイト到達時間）として測定しており、総トラフィック量でソートされているため、最も多くのプレイヤーに影響を与える変更に焦点を当てることができます。他のロケーションでもわずかに多くのトラフィックを最適化できる可能性がありますが、フロリダ州クレストビュー地域のプレイヤーは、eu-central-1 ではなく us-east-1 に誘導することで、大幅な改善（139 ミリ秒から 36 ミリ秒への短縮）を実現できる可能性があります。 図 3: Internet Monitor によるレイテンシー削減の提案 Internet Monitor は、広範囲にわたるインターネットの健全性に影響を与える問題を特定するためにも使用できます。これは、プレイヤー体験が悪い場合のトラブルシューティングや、問題がコントロールできるか否かを検証する際に有用です。図 4 は、イタリアのお客様に影響を与えている現在発生している問題の例です。この時期に複数のプレイヤーからゲームプレイに関する苦情があった場合、影響を確認し、プレイヤーに伝えるために必要な情報を得ることができます。このようなオープンなコミュニケーションは、運用を効果的に管理していることをプレイヤーに示すことができ、長期的なロイヤルティを築くのに役立ちます。 図 4: Internet Monitorによる主要なインターネット障害のマップ まとめ Amazon GameLift Servers を使用してゲームのレイテンシー問題を効果的にトラブルシューティングし、対処する方法を説明しました。UDP ping ビーコン は、すべての AWS グローバルリージョンとローカルゾーンにわたるプレイヤーからサーバーへのレイテンシーを測定するために不可欠であり、サーバー配置とマッチメイキングに関するデータ主導の意思決定を支援することを示しました。 ここでは、運用するリージョン数がプレイヤー体験にどのように影響するか、リージョンを追加するとリターンがどのように減少するか、この決定には CCU とマッチメイキング要件とのバランスを取る必要があることを説明しました。シミュレーションを通じて、大規模（300,000 CCU）と小規模（ 3,000 CCU）の両方のプレイヤー集団に対して、異なるリージョン構成が与える影響を可視化しました。 また、Amazon CloudWatch Internet Monitor を活用して、広範囲にわたるインターネットの問題を特定し、プレイヤーにとって最適なリージョン構成を提案する方法についても説明しました。これにより、コミュニティとの透明性を維持し、可能な限り最高のゲーム体験を提供することができます。 UDP ping ビーコン を活用して、ゲームのリージョン展開とプレイヤー体験を最適化における次のステップを踏み出しましょう。 AWSの担当者に連絡して 、ゲームのパフォーマンス最適化をどのようにサポートできるかを確認し、Amazon GameLift Servers での Internet Monitor の導入についてお問い合わせください。 参考資料 Updated Game Analytics Pipeline Getting started with Amazon GameLift Servers Amazon GameLift Servers service locations <!-- '"` --> Brian Schuster Brian Schuster は AWS Amazon GameLift の Principal Engineer で、サービスの技術的方向性の策定に携わっています。彼は、大規模ゲームの最も厳しい要件をサポートするため、可用性とスケーラビリティの分野における改善の推進に深く注力しています。

本記事は 2024 年 12 月 4 日 に公開された「 Use open table format libraries on AWS Glue 5.0 for Apache Spark 」を翻訳したものです。 オープンテーブルフォーマットは、急速に進化するビッグデータ管理の領域で台頭しており、データストレージと分析の状況を根本的に変えています。Apache Iceberg、Apache Hudi、Delta Lake に代表されるこれらのフォーマットは、柔軟性、パフォーマンス、ガバナンス機能の高度な組み合わせを提供することで、従来のデータレイク構造における永続的な課題に対処しています。データ表現の標準化されたフレームワークを提供することで、オープンテーブルフォーマットはデータサイロを解消し、データ品質を向上させ、大規模な分析を加速します。 組織が指数関数的なデータ増加とますます複雑化する分析要件に取り組む中、これらのフォーマットはオプションの拡張機能から競争力のあるデータ戦略の必須コンポーネントへと移行しています。データの一貫性、クエリ効率、ガバナンスなどの重要な問題を解決する能力により、データ駆動型組織にとって不可欠なものとなっています。オープンテーブルフォーマットの採用は、データ管理プラクティスを最適化し、データから最大の価値を引き出そうとする組織にとって重要な検討事項です。 以前の投稿 では、AWS Glue 5.0 for Apache Spark について説明しました。この投稿では、AWS Glue 5.0 における Iceberg、Hudi、Delta Lake の注目すべきアップデートを紹介します。 Apache Iceberg のハイライト AWS Glue 5.0 は Iceberg 1.7.1 をサポートしています。このセクションでは、注目すべきアップデートを紹介します。詳細については、 Iceberg Release 1.7.1 を参照してください。 ブランチ ブランチ は、各系統のヘッドを指すスナップショット履歴の独立した系統です。これらは柔軟なデータライフサイクル管理に役立ちます。Iceberg テーブルのメタデータは、各トランザクションで更新されるスナップショットの履歴を保存します。Iceberg は、これらのスナップショットの系統を通じてテーブルのバージョン管理や同時実行制御などの機能を実装しています。Iceberg テーブルのライフサイクル管理を拡張するために、他のブランチから派生するブランチを定義できます。各ブランチには独立したスナップショットライフサイクルがあり、個別の参照と更新が可能です。 Iceberg テーブルが作成されると、暗黙的に作成される main ブランチのみが存在します。すべてのトランザクションは最初にこのブランチに書き込まれます。audit ブランチなどの追加ブランチを作成し、エンジンがそれらに書き込むように設定できます。あるブランチの変更は、Spark の fast_forward プロシージャを使用して別のブランチにファストフォワードできます。 次の図は、このセットアップを示しています。 新しいブランチを作成するには、次のクエリを使用します。 ALTER TABLE glue_catalog.&lt;database_name&gt;.&lt;table_name&gt; CREATE BRANCH &lt;branch_name&gt;; ブランチを作成した後、 branch_ &lt;branch_name&gt; を指定することで、ブランチ内のデータに対してクエリを実行できます。特定のブランチにデータを書き込むには、次のクエリを使用します。 INSERT INTO glue_catalog.&lt;database_name&gt;.&lt;table_name&gt;.branch_&lt;branch_name&gt; VALUES (1, 'a'), (2, 'b'); 特定のブランチをクエリするには、次のクエリを使用します。 SELECT * FROM glue_catalog.&lt;database_name&gt;.&lt;table_name&gt;.branch_&lt;branch_name&gt;; 次のクエリを使用して fast_forward プロシージャを実行し、サンプルテーブルデータを audit ブランチから main ブランチに公開できます。 CALL glue_catalog.system.fast_forward( table =&gt; 'db.table', branch =&gt; 'main', to =&gt; 'audit') タグ タグ は、特定のスナップショット ID への論理的なポインタであり、ビジネス目的で重要な履歴スナップショットを管理するのに役立ちます。Iceberg テーブルでは、各トランザクションで新しいスナップショットが作成され、スナップショット ID またはタイムスタンプを指定してタイムトラベルクエリを使用して履歴スナップショットをクエリできます。ただし、スナップショットはすべてのトランザクションで作成されるため、重要なものを区別することが困難な場合があります。タグは、任意の名前で特定のスナップショットを指すことができるため、この問題に対処するのに役立ちます。 例えば、次のコードでスナップショット 2 に event タグを設定できます。 ALTER TABLE glue_catalog.db.sample CREATE TAG `event` AS OF VERSION 2 次のコードを使用して、タグ付けされたスナップショットをクエリできます。 SELECT * FROM glue_catalog.&lt;database_name&gt;.&lt;table_name&gt;.tag_&lt;tagname&gt;; ブランチとタグによるライフサイクル管理 ブランチとタグは、独立したスナップショットライフサイクル管理設定による柔軟なテーブルメンテナンスに役立ちます。Iceberg テーブルでデータが変更されると、各変更は新しいスナップショットとして保存されます。時間の経過とともに、変更が蓄積されるにつれて、複数のデータファイルとメタデータファイルが作成されます。これらのファイルはタイムトラベルクエリなどの Iceberg 機能に不可欠ですが、スナップショットが多すぎるとストレージコストが増加する可能性があります。さらに、大量のメタデータを処理するオーバーヘッドにより、クエリパフォーマンスに影響を与える可能性があります。そのため、組織は不要になったスナップショットの定期的な削除を計画する必要があります。 AWS Glue Data Catalog は、マネージドストレージ最適化機能を通じてこれらの課題に対処します。その最適化ジョブは、保持するスナップショットの数とスナップショットを保持する最大日数という 2 つの設定可能なパラメータに基づいてスナップショットを自動的に削除します。重要なのは、ブランチとタグ付きスナップショットの両方に独立したライフサイクルポリシーを設定できることです。 ブランチについては、スナップショットを保持する最大日数と、最大保持期間を超えても保持する必要があるスナップショットの最小数を制御できます。この設定は各ブランチで独立しています。 例えば、スナップショットを 7 日間保持し、少なくとも 10 個のスナップショットを保持するには、次のクエリを実行します。 ALTER TABLE glue_catalog.db.sample CREATE BRANCH audit WITH SNAPSHOT RETENTION 7 DAYS 10 SNAPSHOTS タグは、データの特定のスナップショットへの永続的な参照として機能します。有効期限を設定しないと、タグ付きスナップショットは無期限に保持され、最適化ジョブが関連するデータファイルをクリーンアップするのを防ぎます。参照を作成するときに、保持する期間の制限を設定できます。 例えば、 event でタグ付けされたスナップショットを 360 日間保持するには、次のクエリを実行します。 ALTER TABLE glue_catalog.db.sample CREATE TAG event RETAIN 360 DAYS このブランチとタグ機能の組み合わせにより、さまざまなビジネス要件とユースケースに対応できる柔軟なスナップショットライフサイクル管理が可能になります。Data Catalog の自動ストレージ最適化機能の詳細については、 The AWS Glue Data Catalog now supports storage optimization of Apache Iceberg tables を参照してください。 変更ログビュー create_changelog_view Spark プロシージャは、包括的な変更履歴ビューを生成することで、テーブルの変更を追跡するのに役立ちます。挿入から更新、削除まで、すべてのデータ変更をキャプチャします。これにより、データがどのように進化したかを分析し、時間の経過とともに変更を監査することが簡単になります。 create_changelog_view プロシージャによって作成された変更ログビューには、変更されたレコードの内容、実行された操作の種類、変更の順序、変更がコミットされたスナップショット ID など、変更に関するすべての情報が含まれています。さらに、指定されたキー列を渡すことで、レコードの元のバージョンと変更されたバージョンを表示できます。これらの選択された列は通常、各レコードを一意に識別する個別の識別子または主キーとして機能します。次のコードを参照してください。 CALL glue_catalog.system.create_changelog_view( table =&gt; 'db.test', identifier_columns =&gt; array('id') ) プロシージャを実行すると、変更ログビュー test_changes が作成されます。 SELECT * FROM test_changes を使用して変更ログビューをクエリすると、Iceberg テーブル内のレコード変更の履歴を含む次の出力を取得できます。 create_changelog_view プロシージャは、データの変更を監視し理解するのに役立ちます。この機能は、変更データキャプチャ (CDC)、監査レコードの監視、ライブ分析など、多くのユースケースで価値があります。 ストレージパーティション結合 ストレージパーティション結合は、Iceberg が提供する結合最適化技術であり、読み取りと書き込みの両方のパフォーマンスを向上させます。この機能は、既存のストレージレイアウトを使用してコストのかかるデータシャッフルを排除し、互換性のあるパーティショニングスキームを共有する大規模なデータセットを結合する際のクエリパフォーマンスを大幅に向上させます。ディスク上のデータの物理的な構成を活用して動作します。両方のデータセットが互換性のあるレイアウトを使用してパーティション化されている場合、Spark は一致するパーティションを直接読み取ることで結合操作をローカルで実行でき、データシャッフルの必要性を完全に回避できます。 ストレージパーティション結合を有効にして最適化するには、 SparkConf または AWS Glue ジョブパラメータを通じて次の Spark 設定プロパティを設定する必要があります。次のコードは、Spark 設定のプロパティを示しています。 spark.sql.sources.v2.bucketing.enabled=true spark.sql.sources.v2.bucketing.pushPartValues.enabled=true spark.sql.requireAllClusterKeysForCoPartition=false spark.sql.adaptive.enabled=false spark.sql.adaptive.autoBroadcastJoinThreshold=-1 spark.sql.iceberg.planning.preserve-data-grouping=true AWS Glue ジョブパラメータを使用するには、次のように設定します。 キー: --conf 値: spark.sql.sources.v2.bucketing.enabled=true --conf spark.sql.sources.v2.bucketing.pushPartValues.enabled=true --conf spark.sql.requireAllClusterKeysForCoPartition=false --conf spark.sql.adaptive.enabled=false --conf spark.sql.adaptive.autoBroadcastJoinThreshold=-1 --conf spark.sql.iceberg.planning.preserve-data-grouping=true 次の例では、ストレージパーティション結合の有無による EXPLAIN クエリで取得したサンプル物理プランを比較しています。これらのプランでは、 product_review と customer の両方のテーブルが review_year や product_id などの同じバケットパーティションキーを持っています。ストレージパーティション結合が有効な場合、Spark はシャッフル操作なしで 2 つのテーブルを結合します。 以下は、ストレージパーティション結合なしの物理プランです。 == Physical Plan == AdaptiveSparkPlan isFinalPlan=false +- Project [review_year#915L, product_id#920] +- SortMergeJoin [review_year#915L, product_id#906], [review_year#929L, product_id#920], Inner :- Sort [review_year#915L ASC NULLS FIRST, product_id#906 ASC NULLS FIRST], false, 0 : +- Exchange hashpartitioning(review_year#915L, product_id#906, 16), ENSURE_REQUIREMENTS, [plan_id=359] : +- BatchScan glue_catalog.db.product_review[...] +- Sort [review_year#929L ASC NULLS FIRST, product_id#920 ASC NULLS FIRST], false, 0 +- Exchange hashpartitioning(review_year#929L, product_id#920, 16), ENSURE_REQUIREMENTS, [plan_id=360] +- BatchScan glue_catalog.db.customer[...] 以下は、ストレージパーティション結合ありの物理プランです。 == Physical Plan == (3) Project [review_year#1301L, product_id#1306] +- (3) SortMergeJoin [review_year#1301L, product_id#1292], [review_year#1315L, product_id#1306], Inner :- (1) Sort [review_year#1301L ASC NULLS FIRST, product_id#1292 ASC NULLS FIRST], false, 0 : +- (1) ColumnarToRow : +- BatchScan glue_catalog.db.product_review[...] +- (2) Sort [review_year#1315L ASC NULLS FIRST, product_id#1306 ASC NULLS FIRST], false, 0 +- (2) ColumnarToRow +- BatchScan glue_catalog.db.customer[...] この物理プランでは、ストレージパーティション結合なしの物理プランに存在する Exchange 操作が見られません。これは、シャッフル操作が実行されないことを示しています。 Delta Lake のハイライト AWS Glue 5.0 は Delta Lake 3.3.0 をサポートしています。このセクションでは、注目すべきアップデートを紹介します。詳細については、 Delta Lake Release 3.3.0 を参照してください。 削除ベクトル 削除ベクトルは、Delta Lake の機能で、従来のコピーオンライト (CoW) アプローチの代替として、マージオンリード (MoR) パラダイムを実装しています。この機能は、Delta Lake テーブルでの DELETE、UPDATE、MERGE 操作の処理方法を根本的に変更します。CoW パラダイムでは、1 行を変更するだけでも Parquet ファイル全体を書き換える必要があります。削除ベクトルを使用すると、変更はソフト削除として記録され、論理的な一貫性を維持しながら元のデータファイルはそのまま残ります。このアプローチにより、書き込みパフォーマンスが向上します。 削除ベクトルが有効な場合、書き込み操作中に変更は圧縮されたビットマップ形式でソフト削除として記録されます。読み取り操作中に、これらの変更はベースデータとマージされます。さらに、削除ベクトルによって記録された変更は、 REORG コマンドを使用してファイルを書き換えることで、ソフト削除されたデータを物理的に適用できます。 削除ベクトルを有効にするには、テーブルパラメータを delta.enableDeletionVectors = 'true' に設定します。 削除ベクトルが有効な場合、削除ベクトルファイルが作成されていることを確認できます。ファイルは次のスクリーンショットでハイライトされています。 削除ベクトルを使用した MoR は、頻繁な更新があり、データが複数のファイルに分散しているテーブルへの効率的な書き込み操作が必要なシナリオで特に役立ちます。ただし、これらのファイルをマージするために必要な読み取りオーバーヘッドを考慮する必要があります。詳細については、 What are deletion vectors? を参照してください。 最適化された書き込み Delta Lake の最適化された書き込み機能は、データレイクでよくあるパフォーマンスの課題であるスモールファイル問題に対処します。この問題は通常、分散操作を通じて多数の小さなファイルが作成されるときに発生します。データを読み取る際、多くの小さなファイルを処理すると、広範なメタデータ管理とファイル処理により大きなオーバーヘッドが発生します。 最適化された書き込み機能は、複数の小さな書き込みをディスクに書き込む前に、より大きく効率的なファイルに結合することでこの問題を解決します。このプロセスは、書き込み前にエグゼキューター間でデータを再分散し、同じパーティション内に類似のデータを配置します。 spark.databricks.delta.optimizeWrite.binSize パラメータを使用してターゲットファイルサイズを制御でき、デフォルトは 512 MB です。最適化された書き込みが有効な場合、出力ファイル数を制御するための従来の coalesce(n) や repartition(n) の使用は不要になります。ファイルサイズの最適化は自動的に処理されるためです。 最適化された書き込みを有効にするには、テーブルパラメータを delta.autoOptimize.optimizeWrite = 'true' に設定します。 最適化された書き込み機能はデフォルトでは有効になっておらず、ファイルがテーブルに書き込まれる前のデータシャッフルにより、書き込みレイテンシが高くなる可能性があることに注意してください。場合によっては、これを自動コンパクションと組み合わせることで、スモールファイルの問題に効果的に対処できます。詳細については、 Optimizations を参照してください。 UniForm Delta Lake Universal Format (UniForm) は、Iceberg と Hudi を通じて Delta Lake テーブルへのシームレスなアクセスを可能にすることで、データレイクの相互運用性へのアプローチを導入しています。これらのフォーマットは主にメタデータレイヤーで異なりますが、Delta Lake UniForm は、単一のデータコピーを参照しながら、Delta Lake と並行して各フォーマット用の互換性のあるメタデータを自動的に生成することでこのギャップを埋めます。UniForm が有効な Delta Lake テーブルに書き込むと、UniForm は他のフォーマット用のメタデータを自動的かつ非同期的に生成します。 Delta UniForm により、組織は単一の Delta Lake ベースのデータソースで操作しながら、各データワークロードに最適なツールを使用できます。UniForm は Iceberg と Hudi の観点からは読み取り専用であり、各フォーマットの一部の機能は利用できません。制限事項の詳細については、 Limitations を参照してください。AWS での UniForm の使用方法については、 Expand data access through Apache Iceberg using Delta Lake UniForm on AWS をご覧ください。 Apache Hudi のハイライト AWS Glue 5.0 は Hudi 0.15.0 をサポートしています。このセクションでは、注目すべきアップデートを紹介します。詳細については、 Hudi Release 0.15.0 を参照してください。 レコードレベルインデックス Hudi は、レコードキーを対応するファイルの場所にマッピングするインデックスメカニズムを提供し、効率的なデータ操作を可能にします。これらのインデックスを使用するには、まずテーブルパラメータで hoodie.metadata.enable=true を設定して MoR を使用するメタデータテーブルを有効にする必要があります。Hudi のマルチモーダルインデックス機能により、さまざまな種類のインデックスを保存できます。これらのインデックスにより、ニーズの進化に応じてさまざまなインデックスタイプを追加する柔軟性が得られます。 レコードレベルインデックスは、レコードキーと対応するファイルの場所との間の正確なマッピングを維持することで、書き込みと読み取りの両方の操作を強化します。このマッピングにより、レコードの場所を迅速に特定でき、データ取得時にスキャンする必要があるファイルの数を削減できます。 書き込みワークフローでは、新しいレコードが到着すると、レコードレベルインデックスは、いずれかのファイルグループに存在する場合、各レコードに場所情報をタグ付けします。このタグ付けプロセスにより、書き込みレイテンシを直接削減して効率的な更新操作を実現します。読み取りワークフローでは、レコードレベルインデックスにより、ライターが特定のデータを含むファイルを迅速に見つけることができるため、すべてのファイルをスキャンする必要がなくなります。どのファイルにどのレコードが含まれているかを追跡することで、レコードレベルインデックスは、特にレコードキー列での完全一致を実行する際にクエリを高速化します。 レコードレベルインデックスを有効にするには、次のテーブルパラメータを設定します。 hoodie.metadata.enable = 'true' hoodie.metadata.record.index.enable = 'true' hoodie.index.type = 'RECORD_INDEX' レコードレベルインデックスが有効な場合、次のスクリーンショットに示すように、インデックスを保存するメタデータテーブルに record_index パーティションが作成されます。 詳細については、 Record Level Index: Hudi’s blazing fast indexing for large-scale datasets on Hudi’s blog を参照してください。 自動生成キー 従来、Hudi ではすべてのテーブルに主キーの明示的な設定が必要でした。ユーザーは hoodie.datasource.write.recordkey.field 設定を使用してレコードキーフィールドを指定する必要がありました。この要件は、ログ取り込みシナリオなど、自然な一意の識別子がないデータセットでは課題となることがありました。 自動生成主キーにより、Hudi は主キーを明示的に設定せずにテーブルを作成する柔軟性を提供するようになりました。 hoodie.datasource.write.recordkey.field 設定を省略すると、Hudi は一意性要件を維持しながら、計算、ストレージ、読み取り操作を最適化する効率的な主キーを自動的に生成します。詳細については、 Key Generation を参照してください。 CDC クエリ ストリーミング取り込みなどの一部のユースケースでは、単一のコミットに属するレコードのすべての変更を追跡することが重要です。Hudi は、開始と終了のコミット時間の間に変更されたレコードのセットを取得できる増分クエリを提供していますが、レコードの変更前後のイメージは含まれていません。代わりに、Hudi の CDC クエリを使用すると、挿入、更新、削除を含むすべての変更操作をキャプチャして処理でき、時間の経過に伴うデータの完全な進化を追跡できます。 CDC クエリを有効にするには、テーブルパラメータを hoodie.table.cdc.enabled = 'true' に設定します。 CDC クエリを実行するには、次のクエリオプションを設定します。 cdc_read_options = { 'hoodie.datasource.query.incremental.format': 'cdc', 'hoodie.datasource.query.type': 'incremental', 'hoodie.datasource.read.begin.instanttime': 0 } spark.read.format("hudi"). \ options(**cdc_read_options). \ load(basePath).show() 次のスクリーンショットは、CDC クエリからのサンプル出力を示しています。op 列では、各レコードに対してどの操作が実行されたかを確認できます。出力には、変更されたレコードの変更前後のイメージも表示されます。 この機能は現在 CoW テーブルで利用可能です。MoR テーブルは執筆時点ではまだサポートされていません。詳細については、 Change Data Capture Query を参照してください。 まとめ この投稿では、AWS Glue 5.0 における Iceberg、Delta Lake、Hudi の主要なアップグレードについて説明しました。新しいジョブを作成し、現在のジョブを移行することで、強化された機能をすぐに活用できます。 著者について Sotaro Hikita アナリティクスソリューションアーキテクトです。幅広い業界のお客様が分析プラットフォームをより効果的に構築・運用できるよう支援しています。特にビッグデータ技術とオープンソースソフトウェアに情熱を持っています。 Noritaka Sekiyama AWS Glue チームのプリンシパルビッグデータアーキテクトです。東京を拠点に活動しています。お客様を支援するためのソフトウェアアーティファクトの構築を担当しています。余暇にはロードバイクでサイクリングを楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

本記事は 2024 年 12 月 3 日 に公開された「 Introducing AWS Glue Data Catalog automation for table statistics collection for improved query performance on Amazon Redshift and Amazon Athena 」を翻訳したものです。 AWS Glue Data Catalog で、新しいテーブルの統計情報を自動的に生成できるようになりました。これらの統計情報は Amazon Redshift Spectrum と Amazon Athena のコストベースオプティマイザー (CBO) と統合され、クエリパフォーマンスの向上とコスト削減につながります。 大規模なデータセットに対するクエリは、大量のデータを読み取り、複数のデータセット間で複雑な結合操作を実行することがよくあります。Redshift Spectrum や Athena などのクエリエンジンがクエリを処理する際、CBO はテーブル統計を使用してクエリを最適化します。例えば、CBO がテーブル列の個別値の数を把握していれば、最適な結合順序と戦略を選択できます。これらの統計情報は事前に収集し、最新のデータ状態を反映するように更新し続ける必要があります。 これまで、Data Catalog は Parquet、ORC、JSON、ION、CSV、XML 形式のテーブルに対して、Redshift Spectrum と Athena の CBO で使用されるテーブル統計の収集をサポートしてきました。この機能とそのパフォーマンス上のメリットについては、 Enhance query performance using AWS Glue Data Catalog column-level statistics で紹介しています。また、Data Catalog は Apache Iceberg テーブルもサポートしています。これについては Accelerate query performance with Apache Iceberg statistics on the AWS Glue Data Catalog で詳しく説明しています。 これまで、Data Catalog で Iceberg テーブルの統計を作成するには、テーブルの設定を継続的に監視および更新する必要がありました。以下のような差別化につながらない重労働が必要でした: 特定のデータテーブル形式 (Parquet、JSON、CSV、XML、ORC、ION など) や Iceberg などのトランザクショナルデータテーブル形式を持つ新しいテーブルと、それぞれのバケットパスを検出する スキャン戦略 (サンプリング率とスケジュール) に基づいてコンピューティングタスクを決定し、セットアップする 特定のタスクに対して AWS Identity and Access Management (IAM) と AWS Lake Formation のロールを設定し、特定の Amazon Simple Storage Service (Amazon S3) アクセス、 Amazon CloudWatch ログ、CloudWatch 暗号化用の AWS Key Management Service (AWS KMS) キー、信頼ポリシーを提供する データレイクの変更を把握するためのイベント通知システムをセットアップする オプティマイザー設定に基づくクエリパフォーマンスとストレージ改善戦略をセットアップする スケジューラーをセットアップするか、セットアップとティアダウンを含む独自のイベントベースのコンピューティングタスクを構築する 今回、Data Catalog では、1 回限りのカタログ設定で、更新および作成されたテーブルの統計を自動的に生成できるようになりました。Lake Formation コンソールでデフォルトカタログを選択し、テーブル最適化設定タブでテーブル統計を有効にすることで開始できます。新しいテーブルが作成されると、Iceberg テーブルでは個別値の数 (NDV) が収集され、Parquet などの他のファイル形式では null の数、最大値、最小値、平均長などの追加統計が収集されます。Redshift Spectrum と Athena は、更新された統計を使用して、最適な結合順序やコストベースの集計プッシュダウンなどの最適化を行い、クエリを最適化できます。AWS Glue コンソールでは、更新された統計と統計生成の実行状況を確認できます。 データレイク管理者は、カタログ内のすべてのデータベースとテーブルに対して週次の統計収集を設定できるようになりました。自動化を有効にすると、Data Catalog はテーブル内のすべての列のカラム統計を週次で生成および更新します。このジョブはテーブル内のレコードの 20% を分析して統計を計算します。これらの統計は、Redshift Spectrum と Athena の CBO がクエリを最適化するために使用できます。 さらに、この新機能では、テーブルレベルで自動化設定とスケジュールされた収集設定を柔軟に構成できます。個々のデータオーナーは、特定の要件に基づいてカタログレベルの自動化設定を上書きできます。データオーナーは、自動化を有効にするかどうか、収集頻度、対象列、サンプリング率など、個々のテーブルの設定をカスタマイズできます。この柔軟性により、管理者はプラットフォーム全体を最適化しながら、データオーナーが個々のテーブルの統計を微調整できます。 この記事では、Data Catalog がテーブル統計収集を自動化する方法と、それを使用してデータプラットフォームの効率を向上させる方法について説明します。 カタログレベルの統計収集を有効にする データレイク管理者は、Lake Formation コンソールでカタログレベルの統計収集を有効にできます。以下の手順を実行します: Lake Formation コンソールで、ナビゲーションペインの Catalogs を選択します。 設定するカタログを選択し、 Actions メニューから Edit を選択します。 Enable automatic statistics generation for the tables of the catalog を選択し、IAM ロールを選択します。必要な権限については、 カラム統計を生成するための前提条件 を参照してください。 Submit を選択します。 AWS Command Line Interface (AWS CLI) を使用してカタログレベルの統計収集を有効にすることもできます: aws glue update-catalog --cli-input-json '{ "name": "123456789012", "catalogInput": { "description": "Updating root catalog with role arn", "catalogProperties": { "customProperties": { "ColumnStatistics.RoleArn": "arn:aws:iam::123456789012:role/service-role/AWSGlueServiceRole", "ColumnStatistics.Enabled": "true" } } } }' このコマンドは AWS Glue の UpdateCatalog API を呼び出し、カタログレベルの統計に対して以下のキーと値のペアを期待する CatalogProperties 構造体を受け取ります: ColumnStatistics.RoleArn – カタログレベルの統計のためにトリガーされるすべてのジョブに使用される IAM ロールの Amazon リソースネーム (ARN) ColumnStatistics.Enabled – カタログレベルの設定が有効か無効かを示すブール値 UpdateCatalog の呼び出し元は、 UpdateCatalog IAM 権限を持ち、Lake Formation 権限を使用している場合はルートカタログに対する ALTER on CATALOG 権限が付与されている必要があります。 GetCatalog API を呼び出して、カタログプロパティに設定されているプロパティを確認できます。渡されるロールに必要な権限については、 カラム統計を生成するための前提条件 を参照してください。 これらの手順に従うことで、カタログレベルの統計収集が有効になります。AWS Glue は、週次で各テーブルのすべての列の統計を自動的に更新し、レコードの 20% をサンプリングします。これにより、データレイク管理者はデータプラットフォームのパフォーマンスとコスト効率を効果的に管理できます。 自動化されたテーブルレベルの設定を確認する カタログレベルの統計収集が有効になっている場合、AWS Glue コンソール、AWS SDK、または AWS Glue クローラーを通じて AWS Glue の CreateTable または UpdateTable API を使用して Apache Hive テーブルまたは Iceberg テーブルが作成または更新されると、そのテーブルに対応するテーブルレベルの設定が作成されます。 自動統計生成が有効なテーブルは、以下のいずれかのプロパティに従う必要があります: Parquet、Avro、ORC、JSON、ION、CSV、XML などの HIVE テーブル形式 Apache Iceberg テーブル形式 テーブルが作成または更新された後、AWS Glue コンソールでテーブルの説明を確認することで、統計収集設定が設定されていることを確認できます。設定には Schedule プロパティが Auto に、 Statistics configuration が Inherited from catalog に設定されているはずです。以下の設定を持つテーブル設定は、AWS Glue によって内部的に自動的にトリガーされます。 以下は、カタログレベルの統計収集が適用され、統計が収集された Hive テーブルの画像です: 以下は、カタログレベルの統計収集が適用され、統計が収集された Iceberg テーブルの画像です: テーブルレベルの統計収集を設定する データオーナーは、特定のニーズに合わせてテーブルレベルで統計収集をカスタマイズできます。頻繁に更新されるテーブルでは、週次よりも頻繁に統計を更新できます。また、最も頻繁にクエリされる列に焦点を当てるために、対象列を指定することもできます。 さらに、統計を計算する際に使用するテーブルレコードの割合を設定できます。そのため、より正確な統計が必要なテーブルではこの割合を増やし、小さなサンプルで十分なテーブルではコストと統計生成パフォーマンスを最適化するために減らすことができます。 これらのテーブルレベルの設定は、前述のカタログレベルの設定を上書きできます。 AWS Glue コンソールでテーブルレベルの統計収集を設定するには、以下の手順を実行します: AWS Glue コンソールで、ナビゲーションペインの Data Catalog の下にある Databases を選択します。 データベースを選択して、利用可能なすべてのテーブルを表示します (例: optimization_test )。 設定するテーブルを選択します (例: catalog_returns )。 Column statistics に移動し、 Generate on schedule を選択します。 Schedule セクションで、 Hourly 、 Daily 、 Weekly 、 Monthly 、 Custom (cron 式) から頻度を選択します。この例では、 Frequency で Daily を選択します。 Start time に、UTC で 06:43 と入力します。 Column options で、 All columns を選択します。 IAM role で、既存のロールを選択するか、新しいロールを作成します。必要な権限については、 カラム統計を生成するための前提条件 を参照してください。 Advanced configuration の下で、 Security configuration で、オプションでセキュリティ設定を選択して、CloudWatch にプッシュされるログの保存時の暗号化を有効にします。 Sample rows に、サンプリングする行の割合として 100 と入力します。 Generate statistics を選択します。 AWS Glue コンソールのテーブルの説明で、指定した日時に統計収集ジョブがスケジュールされていることを確認できます。 これらの手順に従うことで、テーブルレベルの統計収集を設定できました。これにより、データオーナーは特定の要件に基づいてテーブル統計を管理できます。これをデータレイク管理者によるカタログレベルの設定と組み合わせることで、データプラットフォーム全体を最適化するためのベースラインを確保しながら、個々のテーブルの要件に柔軟に対応できます。 AWS CLI を使用してカラム統計生成スケジュールを作成することもできます: aws glue create-column-statistics-task-settings \ --database-name 'database_name' \ --table-name table_name \ --role 'arn:aws:iam::123456789012:role/stats-role' \ --schedule 'cron(8 0-5 14 * * ?)' \ --column-name-list 'col-1' \ --catalog-id '123456789012' \ --sample-size '10.0' \ --security-configuration 'test-security' 必須パラメータは database-name 、 table-name 、 role です。 schedule 、 column-name-list 、 catalog-id 、 sample-size 、 security-configuration などのオプションパラメータも含めることができます。詳細については、 スケジュールに基づくカラム統計の生成 を参照してください。 まとめ この記事では、カタログレベルで自動統計収集を有効にし、テーブルごとに柔軟な制御を可能にする Data Catalog の新機能を紹介しました。組織は、最新のカラムレベルの統計を効果的に管理および維持できます。これらの統計を組み込むことで、Redshift Spectrum と Athena の両方の CBO がクエリ処理とコスト効率を最適化できます。 ぜひこの機能をお試しいただき、コメントでフィードバックをお聞かせください。 著者について Sotaro Hikita は、Analytics Solutions Architect です。幅広い業界のお客様が分析プラットフォームをより効果的に構築・運用できるよう支援しています。特にビッグデータ技術とオープンソースソフトウェアに情熱を持っています。 Noritaka Sekiyama は、AWS Glue チームの Principal Big Data Architect です。東京を拠点に活動しています。お客様を支援するためのソフトウェアアーティファクトの構築を担当しています。余暇にはロードバイクでサイクリングを楽しんでいます。 Kyle Duong は、AWS Glue および AWS Lake Formation チームの Senior Software Development Engineer です。ビッグデータ技術と分散システムの構築に情熱を持っています。 Sandeep Adwankar は、AWS の Senior Product Manager です。カリフォルニア州ベイエリアを拠点に、世界中のお客様と協力して、ビジネスおよび技術要件を、お客様がデータの管理、セキュリティ、アクセス方法を改善できる製品に変換しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

本記事は 2024 年 7 月 9 日 に公開された「 Accelerate query performance with Apache Iceberg statistics on the AWS Glue Data Catalog 」を翻訳したものです。 2024 年 8 月: この記事は Amazon Athena のサポートについて更新されました。 本日、 AWS Glue Data Catalog の新機能として、Apache Iceberg テーブルのカラムレベル集計統計情報を生成してクエリを高速化する機能を発表いたします。これらの統計情報は Amazon Redshift Spectrum と Amazon Athena のコストベースオプティマイザ (CBO) で活用され、クエリパフォーマンスの向上とコスト削減につながります。 Apache Iceberg は、データレイク上で ACID トランザクションを実現するオープンテーブルフォーマットです。大規模な分析データセットの処理に適しており、小さな行レベルの操作でも効率的に動作します。また、タイムトラベル、スキーマエボリューション、隠しパーティショニングなどの便利な機能も提供しています。 AWS はお客様のフィードバックに基づき、Iceberg ワークロードを実現するためのサービス統合に投資してきました。その一例が AWS Glue Data Catalog です。Data Catalog は組織のデータセットに関するメタデータを保存する一元的なリポジトリであり、ユーザーがデータを可視化、検索、クエリできるようにします。 Data Catalog は Iceberg テーブルをサポート しており、テーブルの現在のメタデータを追跡します。また、トランザクション書き込みごとに生成される個々の小さなファイルを、読み取りとスキャン操作を高速化するために少数の大きなファイルに 自動コンパクション することもできます。 2023 年、Data Catalog は 非 Iceberg テーブルのカラムレベル統計情報 のサポートを発表しました。この機能はクエリエンジンの CBO で使用されるテーブル統計情報を収集します。今回、Data Catalog はこのサポートを Iceberg テーブルにも拡張しました。Data Catalog が生成する Iceberg テーブルのカラム統計情報は Puffin Spec に基づいており、他のテーブルデータとともに Amazon Simple Storage Service (Amazon S3) に保存されます。これにより、Iceberg をサポートするさまざまなエンジンがこれらを活用し、更新できます。 この記事では、Iceberg テーブルのカラムレベル統計情報が Redshift Spectrum と Amazon Athena でどのように機能するかを説明します。さらに、TPC-DS データセットを使用して Iceberg カラム統計情報のパフォーマンス上のメリットを紹介します。 Iceberg テーブルのカラム統計情報の仕組み AWS Glue Data Catalog は、 Apache DataSketches の Theta Sketch アルゴリズム を使用してテーブルカラム統計情報を生成し、個別値の数 (NDV) を推定して Puffin ファイルに保存します。 SQL プランナーにとって、NDV はクエリプランニングを最適化するための重要な統計情報です。NDV 統計情報がクエリパフォーマンスを最適化できるシナリオがいくつかあります。例えば、2 つのテーブルをカラムで結合する場合、オプティマイザは NDV を使用して結合の選択性を推定できます。一方のテーブルの結合カラムの NDV が他方のテーブルと比較して低い場合、オプティマイザはシャッフル結合の代わりにブロードキャスト結合を選択し、データ移動を削減してクエリパフォーマンスを向上させることができます。さらに、3 つ以上のテーブルを結合する場合、オプティマイザは各結合の出力サイズを推定し、効率的な結合順序を計画できます。また、NDV は group by、distinct、count クエリなどのさまざまな最適化にも使用できます。 ただし、100% の精度で NDV を継続的に計算するには O(N) の空間計算量が必要です。代わりに、Theta Sketch はすべての個別値をメモリやストレージに保存することなく、データセット内の NDV を推定できる効率的なアルゴリズムです。Theta Sketch の主なアイデアは、データを 0〜1 の範囲にハッシュし、しきい値 (θ で表される) に基づいてハッシュ値の一部のみを選択することです。この小さなデータのサブセットを分析することで、Theta Sketch アルゴリズムは元のデータセットの NDV の正確な推定値を提供できます。 Iceberg の Puffin ファイルは、インデックスや統計情報などの情報を blob タイプとして保存するように設計されています。保存できる代表的な blob タイプの 1 つは apache-datasketches-theta-v1 で、これは Theta Sketch アルゴリズムを使用して NDV を推定するためのシリアライズされた値です。Puffin ファイルは Iceberg のメタデータの snapshot-id にリンクされており、クエリエンジンの CBO がクエリプランを最適化するために使用します。 Amazon Redshift を通じて Iceberg カラム統計情報を活用する この機能のパフォーマンス上のメリットを実証するために、業界標準の TPC-DS 3 TB データセットを使用します。Redshift Spectrum と Amazon Athena でクエリを実行し、Iceberg カラム統計情報の有無によるクエリパフォーマンスを比較します。この記事で使用するクエリを含めていますので、ワークフローに従って独自のクエリを試すことをお勧めします。 全体的な手順は以下のとおりです: パブリック Amazon S3 バケットから TPS-DS データセットを抽出し、S3 バケットに Iceberg テーブルとして保存する AWS Glue ジョブ を実行します。 AWS Glue Data Catalog はこれらのテーブルのメタデータの場所を保存します。Amazon Redshift Spectrum と Amazon Athena を使用してこれらのテーブルをクエリします。 カラム統計情報を生成: AWS Glue Data Catalog の拡張機能を使用して、各テーブルのカラム統計情報を生成します。Theta Sketch を保存する Puffin ファイルが生成されます。 Amazon Redshift Spectrum と Amazon Athena でクエリ: Amazon Redshift Spectrum と Amazon Athena を使用してデータセットに対してクエリを実行し、カラム統計情報がクエリパフォーマンスに与えるメリットを評価します。 以下の図はアーキテクチャを示しています。 この新機能を試すには、以下の手順を完了します: AWS CloudFormation でリソースをセットアップします。 AWS Glue ジョブ を実行して、S3 バケットに 3TB TPC-DS データセットの Iceberg テーブルを作成します。Data Catalog はこれらのテーブルのメタデータの場所を保存します。 Redshift Spectrum と Amazon Athena でクエリを実行し、クエリ時間を記録します。 Data Catalog テーブルの Iceberg カラム統計情報を生成します。 Redshift Spectrum と Amazon Athena でクエリを実行し、前回の実行とクエリ時間を比較します。 オプションで、 AWS Lambda と Amazon EventBridge を使用して AWS Glue カラム統計情報ジョブをスケジュールします。 AWS CloudFormation でリソースをセットアップする この記事には、クイックセットアップ用の CloudFormation テンプレートが含まれています。必要に応じてレビューしてカスタマイズできます。 注意 : この CloudFormation テンプレートには、少なくとも 3 つのアベイラビリティーゾーンを持つリージョンが必要です。テンプレートは以下のリソースを生成します: 仮想プライベートクラウド (VPC)、パブリックサブネット、プライベートサブネット、ルートテーブル Amazon Redshift Serverless ワークグループと名前空間 TPC-DS データセット、カラム統計情報、ジョブスクリプトなどを保存する S3 バケット Data Catalog データベース パブリック S3 バケットから TPS-DS データセットを抽出し、S3 バケットに Iceberg テーブルとしてデータを保存する AWS Glue ジョブ AWS Identity and Access Management (IAM) ロールとポリシー AWS Glue カラム統計情報をスケジュールで実行するための Lambda 関数と EventBridge スケジュール CloudFormation スタックを起動するには、以下の手順を完了します: AWS CloudFormation コンソールにサインインします。 Launch Stack を選択します。 Next を選択します。 パラメータをデフォルトのままにするか、要件に基づいて適切に変更し、 Next を選択します。 最終ページで詳細を確認し、 I acknowledge that AWS CloudFormation might create IAM resources を選択します。 Create を選択します。 このスタックの完了には約 10 分かかります。完了後、AWS CloudFormation コンソールでデプロイされたスタックを確認できます。 AWS Glue ジョブを実行して 3TB TPC-DS データセットの Iceberg テーブルを作成する CloudFormation スタックの作成が完了したら、AWS Glue ジョブを実行して TPC-DS データセットの Iceberg テーブルを作成します。この AWS Glue ジョブは、パブリック S3 バケットから TPC-DS データセットを抽出し、データを Iceberg テーブルに変換します。これらのテーブルは S3 バケットにロードされ、Data Catalog に登録されます。 AWS Glue ジョブを実行するには、以下の手順を完了します: AWS Glue コンソールで、ナビゲーションペインの ETL jobs を選択します。 InitialDataLoadJob-&lt;your-stack-name&gt; を選択します。 Run を選択します。 この AWS Glue ジョブの完了には約 30 分かかります。ジョブ処理ステータスが Succeeded と表示されたら、プロセスは完了です。 AWS Glue ジョブは、TPC-DS データセットを保存するテーブルを 2 つの同一のデータベース ( tpcdsdbnostats と tpcdsdbwithstats ) に作成します。 tpcdsdbnostats のテーブルには統計情報が生成されず、参照として使用します。 tpcdsdbwithstats のテーブルに統計情報を生成します。AWS Glue コンソールでこれら 2 つのデータベースと基盤となるテーブルの作成を確認します。この時点では、これらのデータベースは同じデータを保持しており、テーブルに統計情報は生成されていません。 統計情報なしで Redshift Spectrum でクエリを実行する 前の手順で、指定された RPU (デフォルトは 128) で Redshift Serverless ワークグループをセットアップし、S3 バケットに TPC-DS 3TB データセットを準備し、Iceberg テーブル (現時点では統計情報なし) を作成しました。 Amazon Redshift でクエリを実行するには、以下の手順を完了します: Amazon Redshift クエリをダウンロード します。 Redshift クエリエディタ v2 で、ダウンロードしたファイル redshift-tpcds-sample.sql の Redshift Query for tables without column statistics セクションに記載されているクエリを実行します。 各クエリの実行時間を記録します。 統計情報なしで Amazon Athena でクエリを実行する Amazon Athena からも TPC-DS テーブル (現時点では統計情報なし) をクエリしてみましょう。Amazon Athena でクエリを実行するには、以下の手順を完了します: Amazon Athena クエリをダウンロード します。 Athena クエリエディタ で、ダウンロードしたファイル athena-tpcds-sample.sql の Athena Query for tables without column statistics セクションに記載されているクエリを実行します。 各クエリの実行時間を記録します。 Iceberg カラム統計情報を生成する Data Catalog テーブルの統計情報を生成するには、以下の手順を完了します: AWS Glue コンソールで、ナビゲーションペインの Data Catalog の下にある Databases を選択します。 tpcdsdbwithstats データベースを選択して、利用可能なすべてのテーブルを表示します。 これらのテーブルのいずれか (例: call_center ) を選択します。 Column statistics – new に移動し、 Generate statistics を選択します。 デフォルトオプションを維持します: Choose columns で、 Table (All columns) を選択します。 Row sampling options で、 All rows を選択します。 IAM role で、 AWSGluestats-blog-&lt;your-stack-name&gt; を選択します。 Generate statistics を選択します。 以下のスクリーンショットに示すように、統計情報生成の実行ステータスを確認できます。 Iceberg テーブルのカラム統計情報を生成した後、そのテーブルの詳細なカラム統計情報を確認できます。 詳細プロパティセクションに、テーブルプロパティ use_iceberg_statistics=true があります。このパラメータは Glue Column Statistics ジョブによって追加されます。Amazon Athena は、これが true に設定されている場合にのみカラム統計情報を利用しようとします。一方、Amazon Redshift は、このパラメータに関係なく、統計情報が利用可能であればデフォルトで利用します。 統計情報の生成後、Amazon S3 の AWS Glue テーブルの基盤となるデータの場所に &lt;id&gt;.stat ファイルがあります。このファイルは Theta Sketch データ構造を保存する Puffin ファイルです。クエリエンジンはこの Theta Sketch アルゴリズムを使用して、テーブルを操作する際に NDV を効率的に推定でき、クエリパフォーマンスの最適化に役立ちます。 前の手順を繰り返して、 catalog_sales 、 catalog_returns 、 warehouse 、 item 、 date_dim 、 store_sales 、 customer 、 customer_address 、 web_sales 、 time_dim 、 ship_mode 、 web_site 、 web_returns などのすべてのテーブルの統計情報を生成します。または、AWS Glue にすべてのテーブルのカラム統計情報を生成するよう指示する Lambda 関数を手動で実行することもできます。この関数の詳細については、この記事の後半で説明します。 すべてのテーブルの統計情報を生成した後、各クエリのクエリパフォーマンスを評価できます。 統計情報ありで Redshift Spectrum でクエリを実行する 前の手順で、指定された RPU (デフォルトは 128) で Redshift Serverless ワークグループをセットアップし、S3 バケットに TPC-DS 3TB データセットを準備し、カラム統計情報付きの Iceberg テーブルを作成しました。 統計情報テーブルで Redshift Spectrum を使用して提供されたクエリを実行するには、以下の手順を完了します: Redshift クエリエディタ v2 で、ダウンロードしたファイル redshift-tpcds-sample.sql の Redshift Query for tables with column statistics セクションに記載されているクエリを実行します。 各クエリの実行時間を記録します。 Redshift Serverless 128 RPU と TPC-DS 3TB データセットを使用して、NDV 情報が有益であると予想される 10 個の選択された TPC-DS クエリのサンプル実行を行いました。各クエリを 10 回実行しました。以下の表に示す結果は、カラム統計情報を使用したクエリのパフォーマンス改善率でソートされています。 TPC-DS 3T クエリ カラム統計情報なし カラム統計情報あり パフォーマンス改善率 (%) Query 16 305.0284 51.7807 83.0 Query 75 398.0643 110.8366 72.2 Query 78 169.8358 52.8951 68.9 Query 95 35.2996 11.1047 68.5 Query 94 160.52 57.0321 64.5 Query 68 14.6517 7.4745 49.0 Query 4 217.8954 121.996 44.0 Query 72 123.8698 76.215 38.5 Query 29 22.0769 14.8697 32.6 Query 25 43.2164 32.8602 24.0 結果は 24.0〜83.0% の明確なパフォーマンス改善を示しました。 詳しく見るために、最も高いパフォーマンス改善を示した Query 16 を調べてみましょう: TPC-DS Query 16: select count(distinct cs_order_number) as "order count" ,sum(cs_ext_ship_cost) as "total shipping cost" ,sum(cs_net_profit) as "total net profit" from "awsdatacatalog"."tpcdsdbwithstats"."catalog_sales" cs1 ,"awsdatacatalog"."tpcdsdbwithstats"."date_dim" ,"awsdatacatalog"."tpcdsdbwithstats"."customer_address" ,"awsdatacatalog"."tpcdsdbwithstats"."call_center" where d_date between '2000-2-01' and dateadd(day, 60, cast('2000-2-01' as date)) and cs1.cs_ship_date_sk = d_date_sk and cs1.cs_ship_addr_sk = ca_address_sk and ca_state = 'AL' and cs1.cs_call_center_sk = cc_call_center_sk and cc_county in ('Dauphin County','Levy County','Luce County','Jackson County', 'Daviess County') and exists (select * from "awsdatacatalog"."tpcdsdbwithstats"."catalog_sales" cs2 where cs1.cs_order_number = cs2.cs_order_number and cs1.cs_warehouse_sk &lt;&gt; cs2.cs_warehouse_sk) and not exists(select * from "awsdatacatalog"."tpcdsdbwithstats"."catalog_returns" cr1 where cs1.cs_order_number = cr1.cr_order_number) order by count(distinct cs_order_number) limit 100; ANALYZE クエリを使用して、カラム統計情報の有無によるクエリプランの違いを比較できます。 以下のスクリーンショットは、カラム統計情報なしの結果を示しています。 以下のスクリーンショットは、カラム統計情報ありの結果を示しています。 カラム統計情報を使用した結果、いくつかの顕著な違いが観察できます。高レベルでは、クエリの全体的な推定コストが 20633217995813352.00 から 331727324110.36 に大幅に削減されています。 2 つのクエリプランは異なる結合戦略を選択しました。 以下は、カラム統計情報なしのクエリプランに含まれる 1 行です: XN Hash Join DS_DIST_BOTH (cost45365031.50 rows=10764790749 width=44) " Outer Dist Key: ""outer"".cs_order_number" Inner Dist Key: volt_tt_61c54ae740984.cs_order_number " Hash Cond: ((""outer"".cs_order_number = ""inner"".cs_order_number) AND (""outer"".cs_warehouse_sk = ""inner"".cs_warehouse_sk))" 以下は、カラム統計情報ありのクエリプランの対応する行です: XN Hash Join DS_BCAST_INNER (cost=307193250965.64..327130154786.68 rows=17509398 width=32) " Hash Cond: ((""outer"".cs_order_number = ""inner"".cs_order_number) AND (""outer"".cs_warehouse_sk = ""inner"".cs_warehouse_sk))" カラム統計情報なしのテーブルのクエリプランは、大きなテーブルを結合する際に DS_DIST_BOTH を使用しましたが、カラム統計情報ありのテーブルのクエリプランは DS_BCAST_INNER を選択しました。結合順序もカラム統計情報に基づいて変更されています。これらの結合戦略と結合順序の変更は、主にカラム統計情報によって可能になったより正確な結合カーディナリティの推定によって駆動され、より最適化されたクエリプランにつながります。 統計情報ありで Amazon Athena でクエリを実行する Iceberg の統計情報が Amazon Athena のパフォーマンスにどのように影響するかも調べてみましょう。 統計情報テーブルで Amazon Athena を使用して提供されたクエリを実行するには、以下の手順を完了します: Athena クエリエディタで、ダウンロードしたファイル athena-tpcds-sample.sql の Athena Query for tables with column statistics セクションに記載されているクエリを実行します。 各クエリの実行時間を記録します。 Amazon Athena と TPC-DS 3TB データセットを使用して、NDV 情報が有益であると予想される 10 個の選択された TPC-DS クエリのサンプル実行を行いました。各クエリを 10 回実行しました。以下の表に示す結果は、カラム統計情報を使用したクエリのパフォーマンス改善率でソートされています。 TPC-DS 3T クエリ カラム統計情報なし カラム統計情報あり パフォーマンス改善率 (%) Query 70 65.831 22.075 66.47 Query 95 24.231 8.334 65.56 Query 36 41.497 17.073 58.86 Query 94 17.787 6.122 58.6 Query 35 44.749 19.05 57.43 Query 16 18.609 8.696 53.27 Query 18 10.487 5.965 43.12 Query 2 32.823 18.788 42.76 Query 59 39.496 24.15 38.85 Query 11 58.844 39.224 33.34 結果は 33.34〜66.47% の明確なパフォーマンス改善を示しました。 詳しく見るために、最も高いパフォーマンス改善を示した Query 70 を調べてみましょう: TPC-DS Query 70: select sum(ss_net_profit) total_sum ,s_state ,s_county ,(grouping (s_state) + grouping (s_county)) lochierarchy ,rank() over (partition by (grouping (s_state) + grouping (s_county)) ,(case when (grouping (s_county) = 0) then s_state end) order by sum(ss_net_profit) desc) rank_within_parent from tpcdsdbnostats.store_sales ,tpcdsdbnostats.date_dim d1 ,tpcdsdbnostats.store where (d1.d_month_seq between 1200 and (1200 + 11)) and (d1.d_date_sk = ss_sold_date_sk) and (s_store_sk = ss_store_sk) and (s_state in ( select s_state from ( select s_state s_state ,rank() over (partition by s_state order by sum(ss_net_profit) desc) ranking from tpcdsdbnostats.store_sales ,tpcdsdbnostats.store ,tpcdsdbnostats.date_dim where (d_month_seq between 1200 and (1200 + 11)) and (d_date_sk = ss_sold_date_sk) and (s_store_sk = ss_store_sk) group by s_state ) tmp1 where (ranking &lt;= 5) )) group by rollup (s_state, s_county) order by lochierarchy desc, (case when (lochierarchy = 0) then s_state end) asc, rank_within_parent asc limit 100; EXPLAIN クエリを使用して、カラム統計情報の有無によるクエリプランの違いを比較できます。 以下のスクリーンショットは、カラム統計情報なしの結果を示しています。 以下のスクリーンショットは、カラム統計情報ありの結果を示しています。 カラム統計情報の使用により、いくつかの重要な違いが明らかになります。 統計情報なしでは、スキャンするレコード数や CPU コストの多くの推定値が「?」ですが、統計情報ありでは具体的な数値が提供されます。 以下は、カラム統計情報なしのクエリプランに含まれる行です: Project[projectLocality = LOCAL, protectedBarrier = NONE] │ Layout: [s_state$gid_92:varchar, expr_98:varchar, s_county$gid:varchar, expr_95:integer, rank_97:bigint, sum_93:decimal(38,2)] │ Estimates: {rows: ? (?), cpu: ?, memory: 0B, network: 0B} 以下は、カラム統計情報ありのクエリプランの行です: Project[projectLocality = LOCAL, protectedBarrier = NONE] │ Layout: [s_state$gid_92:varchar, expr_98:varchar, s_county$gid:varchar, expr_95:integer, rank_97:bigint, sum_93:decimal(38,2)] │ Estimates: {rows: 1447198784 (264.17GB), cpu: 264.17G, memory: 0B, network: 0B} CBO はこれらの具体的な推定値を持つことで、より効率的なプランを生成できます。 例えば、2 つのクエリプランは異なる結合戦略を選択しました。 以下は、カラム統計情報なしのクエリプランに含まれる 1 行です: InnerJoin[criteria = ("s_state" = "s_state_53"), hash = [$hashvalue_105, $hashvalue_126], distribution = PARTITIONED] 以下は、カラム統計情報ありのクエリプランの対応する行です: InnerJoin[criteria = ("ss_store_sk" = "s_store_sk"), hash = [$hashvalue_109, $hashvalue_110], distribution = REPLICATED] 統計情報なしでは、オプティマイザは PARTITIONED 分散を選択し、ノード間で大量のデータ移動が必要になります。統計情報ありでは、適切な場合に REPLICATED 分散を選択し、小さなテーブルをすべてのノードにブロードキャストできます。これにより、ネットワークトラフィックが削減され、並列処理の効率が向上します。 AWS Glue カラム統計情報の実行をスケジュールする 最適なクエリパフォーマンスを維持するには、カラム統計情報を最新の状態に保つことが重要です。このセクションでは、Lambda と EventBridge Scheduler を使用して Iceberg テーブルのカラム統計情報の生成を自動化する方法を説明します。この自動化により、手動介入なしでカラム統計情報を最新の状態に保つことができます。 必要な Lambda 関数と EventBridge スケジュールは、CloudFormation テンプレートを通じてすでに作成されています。Lambda 関数は AWS Glue カラム統計情報の実行を呼び出すために使用されます。まず、以下の手順を完了して、Lambda 関数がどのように設定されているかを確認します: Lambda コンソールで、ナビゲーションペインの Functions を選択します。 関数 GlueTableStatisticsFunctionv1 を開きます。 Lambda 関数をより明確に理解するために、 Code セクションのコードを確認し、 Configuration の環境変数を調べることをお勧めします。 以下のコードスニペットに示すように、Lambda 関数は AWS SDK for Python (Boto3) ライブラリを通じて start_column_statistics_task_run API を呼び出します。 次に、以下の手順を完了して、EventBridge スケジュールがどのように設定されているかを確認します: EventBridge コンソールで、ナビゲーションペインの Scheduler の下にある Schedules を選択します。 CloudFormation コンソールで作成されたスケジュールを見つけます。 このページでは、イベントのスケジュールを管理および設定します。以下のスクリーンショットに示すように、スケジュールは毎日特定の時刻 (この場合は UTC 午後 8:27) に Lambda 関数を呼び出すように設定されています。これにより、AWS Glue カラム統計情報が定期的かつ予測可能に実行されます。 クリーンアップ 上記のすべての手順を完了したら、AWS CloudFormation を使用して作成したすべての AWS リソースをクリーンアップすることを忘れないでください: CloudFormation スタックを削除します。 TPC-DS データセットの Iceberg テーブルと AWS Glue ジョブスクリプトを保存している S3 バケットを削除します。 まとめ この記事では、Iceberg テーブルのカラムレベル統計情報を作成できる Data Catalog の新機能を紹介しました。Iceberg テーブルは、Puffin ファイルに NDV を効率的に推定するために使用できる Theta Sketch を保存します。Redshift Spectrum の CBO はこれを使用してクエリプランを最適化し、クエリパフォーマンスの向上とコスト削減につながります。 Data Catalog のこの新機能を試して、カラムレベル統計情報を生成し、クエリパフォーマンスを向上させてください。コメントセクションでフィードバックをお聞かせください。詳細については、 AWS Glue Catalog ドキュメント をご覧ください。 著者について Sotaro Hikita ソリューションアーキテクトとして、幅広い業界、特に金融業界のお客様がより良いソリューションを構築できるよう支援しています。特にビッグデータ技術とオープンソースソフトウェアに情熱を持っています。 Noritaka Sekiyama AWS Glue チームのプリンシパルビッグデータアーキテクトです。お客様を支援するためのソフトウェアアーティファクトの構築を担当しています。余暇には新しいロードバイクでサイクリングを楽しんでいます。 Kyle Duong AWS Glue および AWS Lake Formation チームのシニアソフトウェア開発エンジニアです。ビッグデータ技術と分散システムの構築に情熱を持っています。 Kalaiselvi Kamaraj Amazon のシニアソフトウェア開発エンジニアです。Amazon Redshift クエリ処理チーム内のいくつかのプロジェクトに携わり、現在は Redshift データレイクのパフォーマンス関連プロジェクトに注力しています。 Sandeep Adwankar AWS のシニアプロダクトマネージャーです。カリフォルニアのベイエリアを拠点に、世界中のお客様と協力して、ビジネスおよび技術要件を、お客様がデータの管理、セキュリティ、アクセス方法を改善できる製品に変換しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

本記事は 2025 年 12 月 9 日 に公開された「 Introducing Apache Iceberg materialized views in AWS Glue Data Catalog 」を翻訳したものです。 数十万のお客様が AWS 上で人工知能と機械学習 (AI/ML) およびアナリティクスアプリケーションを構築しており、クエリパフォーマンスを向上させるために、生データから処理済みデータセット、最終的な分析テーブルまで、複数のステージを経てデータを変換しています。データエンジニアは、ベーステーブルで変更されたデータの検出、変換ロジックの作成と保守、依存関係を考慮したワークフローのスケジューリングとオーケストレーション、コンピューティングインフラストラクチャのプロビジョニングと管理、パイプラインの健全性を監視しながらの障害のトラブルシューティングなど、複雑な問題を解決する必要があります。 例えば、E コマース企業での分析ユースケースで、データエンジニアがクリックストリームログと注文データを継続的にマージする必要がある状況を考えてみましょう。各変換には、堅牢な変更検出メカニズムの構築、複雑な結合と集計の作成、複数のワークフローステップの調整、コンピューティングリソースの適切なスケーリング、運用の監視が必要です。これらすべてを、データ品質とパイプラインの信頼性をサポートしながら行う必要があります。この複雑さには数か月の専任エンジニアリング作業と継続的なメンテナンスが必要であり、データから洞察を得ようとする組織にとって、データ変換はコストと時間がかかるものとなっています。 これらの課題に対処するため、AWS は AWS Glue Data Catalog の Apache Iceberg テーブル向けの新しいマテリアライズドビュー機能を発表しました。この新しいマテリアライズドビュー機能は、データパイプラインを簡素化し、データレイクのクエリパフォーマンスを向上させます。マテリアライズドビューは、AWS Glue Data Catalog 内のマネージドテーブルであり、クエリの事前計算結果を Iceberg 形式で保存し、基盤となるデータセットの変更を反映するために増分更新されます。これにより、変換されたデータセットを生成してクエリパフォーマンスを向上させるための複雑なデータパイプラインの構築と保守が不要になります。 Amazon Athena 、 Amazon EMR 、 AWS Glue の Apache Spark エンジンは、新しいマテリアライズドビューをサポートし、パフォーマンスを向上させながらコンピューティングコストを削減するマテリアライズドビューを使用するようにクエリをインテリジェントに書き換えます。 この記事では、Iceberg マテリアライズドビューの仕組みと使い始め方を紹介します。 Iceberg マテリアライズドビューの仕組み Iceberg マテリアライズドビューは、使い慣れた SQL 構文に基づいたシンプルなマネージドソリューションを提供します。複雑なパイプラインを構築する代わりに、Spark から標準の SQL クエリを使用してマテリアライズドビューを作成し、カスタムデータパイプラインを作成することなく、集計、フィルター、結合でデータを変換できます。変更検出、増分更新、ソーステーブルの監視は AWS Glue Data Catalog で自動的に処理され、新しいデータが到着するとマテリアライズドビューが更新されるため、手動でのパイプラインオーケストレーションが不要になります。データ変換はフルマネージドのコンピューティングインフラストラクチャで実行されるため、サーバーのプロビジョニング、スケーリング、メンテナンスの負担がなくなります。 結果として得られる事前計算データは、お客様のアカウント内の Amazon Simple Storage Service (Amazon S3) 汎用バケット、または Amazon S3 Tables バケット に Iceberg テーブルとして保存され、変換されたデータは Athena、 Amazon Redshift 、AWS 最適化 Spark ランタイムなど、複数のクエリエンジンからすぐにアクセスできます。Athena、Amazon EMR、AWS Glue の Spark エンジンは、マテリアライズドビューをインテリジェントに使用する自動クエリ書き換え機能をサポートしており、データ処理ジョブやインタラクティブなノートブッククエリのパフォーマンスを自動的に向上させます。 以下のセクションでは、マテリアライズドビューの作成、クエリ、更新の手順を説明します。 前提条件 この記事に沿って進めるには、 AWS アカウント が必要です。 Amazon EMR で手順を実行するには、以下のステップを完了してクラスターを設定します。 Amazon EMR クラスター 7.12.0 以上を起動します。 Amazon EMR クラスターのプライマリノードに SSH ログインし、以下のコマンドを実行して必要な設定で Spark アプリケーションを起動します。 spark-sql \ &nbsp;--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions \ &nbsp;&nbsp;--conf spark.sql.catalog.glue_catalog=org.apache.iceberg.spark.SparkCatalog \ &nbsp;&nbsp;--conf spark.sql.catalog.glue_catalog.type=glue \ &nbsp;&nbsp;--conf spark.sql.catalog.glue_catalog.warehouse=s3://amzn-s3-demo-bucket/warehouse \ &nbsp;&nbsp;--conf spark.sql.catalog.glue_catalog.glue.region=us-east-1 \ &nbsp;&nbsp;--conf spark.sql.catalog.glue_catalog.glue.id=123456789012 \ --conf spark.sql.catalog.glue_catalog.glue.account-id=123456789012 \ --conf spark.sql.catalog.glue_catalog.client.region=us-east-1 \ --conf spark.sql.catalog.glue_catalog.glue.lakeformation-enabled=true \ &nbsp;&nbsp;--conf spark.sql.optimizer.answerQueriesWithMVs.enabled=true \ &nbsp;&nbsp;--conf spark.sql.defaultCatalog=glue_catalog &nbsp;&nbsp; AWS Glue for Spark で手順を実行するには、以下のステップを完了してジョブを設定します。 AWS Glue バージョン 5.1 以上のジョブを作成します。 ジョブパラメータを設定します。 キー: --conf 値: spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions 以下のスクリプトでジョブを設定します。 from pyspark.sql import SparkSession spark = ( &nbsp;&nbsp; &nbsp;SparkSession.builder \ &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;.config("spark.sql.extensions", "org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions") &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;.config("spark.sql.catalog.glue_catalog", "org.apache.iceberg.spark.SparkCatalog") &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;.config("spark.sql.catalog.glue_catalog.type", "glue") &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;.config("spark.sql.catalog.glue_catalog.warehouse", "s3://amzn- -demo-bucket/warehouse") &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;.config("spark.sql.catalog.glue_catalog.glue.region", "us-east-1") &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;.config("spark.sql.catalog.glue_catalog.glue.id", "123456789012") &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;.config("spark.sql.catalog.glue_catalog.glue.account-id", "123456789012") .config("spark.sql.catalog.glue_catalog.client.region", "us-east-1") &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;.config("spark.sql.catalog.glue_catalog.glue.lakeformation-enabled", "true") &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;.config("spark.sql.optimizer.answerQueriesWithMVs.enabled",&nbsp;"true") &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;.config("spark.sql.defaultCatalog",&nbsp;"glue_catalog") &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;.getOrCreate() ) 以下のクエリを Spark SQL で実行してベーステーブルをセットアップします。AWS Glue では、 spark.sql("QUERY STATEMENT") を通じて実行できます。 CREATE DATABASE IF NOT EXIST iceberg_mv; USE iceberg_mv; CREATE TABLE IF NOT EXISTS&nbsp;base_tbl ( &nbsp;&nbsp; &nbsp;id INT, &nbsp;&nbsp; &nbsp;customer_name STRING, &nbsp;&nbsp; &nbsp;amount INT, &nbsp;&nbsp; &nbsp;order_date DATE); &nbsp;&nbsp; &nbsp; INSERT INTO base_tbl VALUES (1, 'John Doe', 150, DATE('2025-12-01')), (2, 'Jane Smith', 200, DATE('2025-12-02')), (3, 'Bob Johnson', 75, DATE('2025-12-03')); SELECT * FROM base_tbl; 以降のセクションでは、このベーステーブルを使用してマテリアライズドビューを作成します。 マテリアライズドビューを汎用 Amazon S3 バケットではなく Amazon S3 Tables に保存する場合は、この記事の最後にある 付録 1 で設定の詳細を参照してください。 マテリアライズドビューの作成 マテリアライズドビューを作成するには、以下のコマンドを実行します。 CREATE MATERIALIZED VIEW mv AS SELECT &nbsp; &nbsp; customer_name, &nbsp;&nbsp;&nbsp;&nbsp;COUNT(*) as mv_order_count, &nbsp;&nbsp;&nbsp;&nbsp;SUM(amount) as mv_total_amount FROM glue_catalog.iceberg_mv.base_tbl GROUP BY customer_name; マテリアライズドビューを作成した後、Spark のインメモリメタデータキャッシュが新しいマテリアライズドビューの情報を反映するまで時間がかかります。このキャッシュ構築期間中、ベーステーブルに対するクエリはマテリアライズドビューを使用せずに通常どおり実行されます。キャッシュが完全に構築された後 (通常は数十秒以内)、Spark はクエリにマテリアライズドビューが適用できることを自動的に検出し、事前計算されたマテリアライズドビューを使用するようにクエリを書き換えて、パフォーマンスを向上させます。 この動作を確認するには、マテリアライズドビューを作成した直後に以下の EXPLAIN コマンドを実行します。 EXPLAIN EXTENDED SELECT customer_name, COUNT(*) as mv_order_count, SUM(amount) as mv_total_amount FROM base_tbl GROUP BY customer_name; 以下の出力は、キャッシュ構築前の初期結果を示しています。 == Parsed Logical Plan == 'Aggregate ['customer_name], ['customer_name, 'COUNT(1) AS mv_order_count#0, 'SUM('amount) AS mv_total_amount#1] +- 'UnresolvedRelation [base_tbl] , [], false == Analyzed Logical Plan == customer_name: string, mv_order_count: bigint, mv_total_amount: bigint Aggregate [customer_name#8], [customer_name#8, count(1) AS mv_order_count#0L, sum(amount#9) AS mv_total_amount#1L] +- SubqueryAlias glue_catalog.iceberg_mv.base_tbl +- RelationV2[id#7, customer_name#8, amount#9, order_date#10] glue_catalog.iceberg_mv.base_tbl glue_catalog.iceberg_mv.base_tbl == Optimized Logical Plan == Aggregate [customer_name#8], [customer_name#8, count(1) AS mv_order_count#0L, sum(amount#9) AS mv_total_amount#1L] +- RelationV2[customer_name#8, amount#9] glue_catalog.iceberg_mv.base_tbl == Physical Plan == AdaptiveSparkPlan isFinalPlan=false +- HashAggregate(keys=[customer_name#8], functions=[count(1), sum(amount#9)], output=[customer_name#8, mv_order_count#0L, mv_total_amount#1L], schema specialized) +- Exchange hashpartitioning(customer_name#8, 1000), ENSURE_REQUIREMENTS, [plan_id=19] +- HashAggregate(keys=[customer_name#8], functions=[partial_count(1), partial_sum(amount#9)], output=[customer_name#8, count#27L, sum#29L], schema specialized) +- BatchScan glue_catalog.iceberg_mv.base_tbl[customer_name#8, amount#9] glue_catalog.iceberg_mv.base_tbl (branch=null) [filters=, groupedBy=, pushedLimit=None] RuntimeFilters: [] この初期実行プランでは、Spark は base_tbl を直接スキャン ( BatchScan glue_catalog.iceberg_mv.base_tbl ) し、生データに対して集計 ( COUNT と SUM ) を実行しています。これはマテリアライズドビューのメタデータキャッシュが構築される前の動作です。 メタデータキャッシュの構築のために約数十秒待った後、同じ EXPLAIN コマンドを再度実行します。以下の出力は、キャッシュ構築後のクエリ最適化プランの主な違いを示しています。 == Optimized Logical Plan == Aggregate [customer_name#97], [customer_name#97, coalesce(sum(mv_order_count#98L), 0) AS mv_order_count#72L, sum(mv_total_amount#99L) AS mv_total_amount#73L] +- RelationV2[customer_name#97, mv_order_count#98L, mv_total_amount#99L] glue_catalog.iceberg_mv.mv == Physical Plan == AdaptiveSparkPlan isFinalPlan=false +- HashAggregate(keys=[customer_name#97], functions=[sum(mv_order_count#98L), sum(mv_total_amount#99L)], output=[customer_name#97, mv_order_count#72L, mv_total_amount#73L], schema specialized) +- Exchange hashpartitioning(customer_name#97, 1000), ENSURE_REQUIREMENTS, [plan_id=51] +- HashAggregate(keys=[customer_name#97], functions=[partial_sum(mv_order_count#98L), partial_sum(mv_total_amount#99L)], output=[customer_name#97, sum#113L, sum#115L], schema specialized) +- BatchScan glue_catalog.iceberg_mv.mv[customer_name#97, mv_order_count#98L, mv_total_amount#99L] glue_catalog.iceberg_mv.mv (branch=null) [filters=, groupedBy=, pushedLimit=None] RuntimeFilters: [] キャッシュが構築された後、Spark はベーステーブルではなくマテリアライズドビュー ( BatchScan glue_catalog.iceberg_mv.mv ) をスキャンするようになりました。クエリは、マテリアライズドビュー内の事前計算された集計データから読み取るように自動的に書き換えられています。出力では、集計関数が生データから COUNT と SUM を再計算するのではなく、事前計算された値を単純に合計 ( sum(mv_order_count) と sum(mv_total_amount) ) していることがわかります。 自動更新スケジュール付きのマテリアライズドビューの作成 デフォルトでは、新しく作成されたマテリアライズドビューには初期クエリ結果が含まれています。基盤となるベーステーブルのデータが変更されても自動的には更新されません。マテリアライズドビューをベーステーブルのデータと同期させるには、自動更新スケジュールを設定できます。自動更新を有効にするには、マテリアライズドビューを作成するときに REFRESH EVERY 句を使用します。この句は時間間隔と単位を受け入れるため、マテリアライズドビューが更新される頻度を指定できます。 以下の例では、24 時間ごとに自動更新されるマテリアライズドビューを作成します。 CREATE MATERIALIZED VIEW mv REFRESH EVERY 24 HOURS AS SELECT &nbsp;&nbsp; &nbsp;customer_name, &nbsp;&nbsp; &nbsp;COUNT(*) as mv_order_count, &nbsp;&nbsp; &nbsp;SUM(amount) as mv_total_amount FROM glue_catalog.iceberg_mv.base_tbl GROUP BY customer_name; 更新間隔は、 SECONDS 、 MINUTES 、 HOURS 、 DAYS のいずれかの時間単位を使用して設定できます。データの鮮度要件とクエリパターンに基づいて適切な間隔を選択してください。 マテリアライズドビューの更新タイミングをより細かく制御したい場合や、スケジュールされた間隔外で更新する必要がある場合は、いつでも手動更新をトリガーできます。フル更新と増分更新を含む手動更新オプションの詳細な手順は、この記事の後半で説明します。 マテリアライズドビューへのクエリ Amazon EMR クラスターでマテリアライズドビューをクエリして集計データを取得するには、標準の SELECT ステートメントを使用できます。 SELECT * FROM mv; このクエリは、マテリアライズドビューからすべての行を取得します。出力には、集計された顧客の注文数と合計金額が表示されます。結果には、3 人の顧客とそれぞれのメトリクスが表示されます。 -- Result Jane Smith 1 200 Bob Johnson 1 75 John Doe 1 150 さらに、Athena SQL から同じマテリアライズドビューをクエリできます。以下のスクリーンショットは、Athena で実行された同じクエリと結果の出力を示しています。 マテリアライズドビューの更新 マテリアライズドビューは、 フル更新 または 増分更新 の 2 つの更新タイプを使用して更新できます。フル更新は、すべてのベーステーブルデータからマテリアライズドビュー全体を再計算します。増分更新は、前回の更新以降の変更のみを処理します。フル更新は、一貫性が必要な場合や大幅なデータ変更後に最適です。増分更新は、即時更新が必要な場合に適しています。以下の例では、両方の更新タイプを示します。 フル更新 を使用するには、以下のステップを完了します。 新しいデータの到着をシミュレートするために、ベーステーブルに 3 つの新しいレコードを挿入します。 INSERT INTO base_tbl VALUES (4, 'Jane Smith', 350, DATE('2025-11-29')), (5, 'Bob Johnson', 100, DATE('2025-11-30')), (6, 'Kwaku Mensah', 40, DATE('2025-12-01')); マテリアライズドビューをクエリして、まだ古い集計値が表示されることを確認します。 SELECT * FROM mv; --&nbsp;Result Jane Smith &nbsp; &nbsp;1 &nbsp; &nbsp;200 Bob Johnson &nbsp; &nbsp;1 &nbsp; &nbsp;75 John Doe &nbsp; &nbsp;1 &nbsp; &nbsp;150 以下のコマンドを使用してマテリアライズドビューのフル更新を実行します。 REFRESH MATERIALIZED VIEW mv FULL; マテリアライズドビューを再度クエリして、集計値に新しいレコードが含まれていることを確認します。 SELECT * FROM mv; --&nbsp;Result Jane Smith 2 550 // Updated Bob Johnson 2 175 // Updated John Doe 1 150 Kwaku Mensah 1 40 // Added 増分更新 を使用するには、以下のステップを完了します。 Spark 設定プロパティを設定して増分更新を有効にします。 SET spark.sql.optimizer.incrementalMVRefresh.enabled=true; ベーステーブルに 2 つの追加レコードを挿入します。 INSERT INTO base_tbl VALUES (7, 'Jane Smith', 120, DATE('2025-11-28')), (8, 'Kwaku Mensah', 90, DATE('2025-12-02')); FULL 句なしで REFRESH コマンドを使用して増分更新を実行します。増分更新が有効になっているかどうかを確認するには、この記事の最後にある 付録 2 を参照してください。 REFRESH MATERIALIZED VIEW mv; マテリアライズドビューをクエリして、増分変更が集計結果に反映されていることを確認します。 SELECT *&nbsp;FROM mv; --Result Jane Smith 3 670 3 3 // Updated Bob Johnson 2 175 2 2 John Doe 1 150 1 1 Kwaku Mensah 2 130 2 2 // Updated Spark SQL を使用する以外に、スケジュールされた間隔外で更新が必要な場合は、AWS Glue API を通じて手動更新をトリガーすることもできます。以下の AWS CLI コマンドを実行します。 $ aws glue start-materialized-view-refresh-task-run \ --catalog-id &lt;ACCOUNT_ID&gt; \ --database-name &lt;DATABASE_NAME&gt; \ --table-name &lt;MV_TABLE_NAME&gt; AWS Lake Formation コンソールには、API でトリガーされた更新の更新履歴が表示されます。マテリアライズドビューを開くと、更新タイプ ( INCREMENTAL または FULL )、開始時刻と終了時刻、ステータスなどを確認できます。 Iceberg マテリアライズドビューを使用して効率的なデータ処理とクエリを行う方法を学びました。Amazon EMR 上の Spark を使用してマテリアライズドビューを作成し、Amazon EMR と Athena の両方からクエリを実行し、フル更新と増分更新の 2 つの更新メカニズムを使用しました。Iceberg マテリアライズドビューは、データパイプラインを簡単に変換および最適化するのに役立ちます。 考慮事項 この機能を最適に使用するために考慮すべき重要な点があります。 マテリアライズドビューを管理するための新しい SQL コマンドは、AWS によって最適化された Spark ランタイムエンジンでのみ動作します。これらは、Athena、Amazon EMR、AWS Glue の Spark バージョン 3.5.6 以上で利用できます。オープンソースの Spark はサポートされていません。 マテリアライズドビューは、ベーステーブルと結果整合性があります。ソーステーブルが変更されると、マテリアライズドビューは、作成時に更新スケジュールでユーザーが定義したバックグラウンド更新プロセスを通じて更新されます。更新ウィンドウ中、マテリアライズドビューに直接アクセスするクエリは古いデータを参照する可能性があります。ただし、最新のデータセットにすぐにアクセスする必要があるお客様は、シンプルな REFRESH MATERIALIZED VIEW SQL コマンドで手動更新を実行できます。 クリーンアップ 今後の料金が発生しないように、このウォークスルーで作成したリソースをクリーンアップします。 以下のコマンドを実行して、マテリアライズドビューとテーブルを削除します。 DROP TABLE mv PURGE; -- Or, DROP MATERIALIZED VIEW mv; DROP TABLE base_tbl PURGE; -- If necessary, delete the database by DROP DATABASE iceberg_mv; Amazon EMR の場合は、Amazon EMR クラスターを終了します。 AWS Glue の場合は、AWS Glue ジョブを削除します。 まとめ この記事では、Iceberg マテリアライズドビューが AWS 上で効率的なデータレイク操作をどのように促進するかを示しました。新しいマテリアライズドビュー機能は、データパイプラインを簡素化し、ベーステーブルの変更に応じて自動的に更新される事前計算結果を保存することでクエリパフォーマンスを向上させます。使い慣れた SQL 構文を使用してマテリアライズドビューを作成し、フル更新と増分更新の両方のメカニズムを使用してデータの一貫性を維持できます。このソリューションは、Athena、Amazon EMR、AWS Glue などの AWS サービスとのシームレスな統合を提供しながら、複雑なパイプラインのメンテナンスを不要にします。自動クエリ書き換え機能は、該当する場合にマテリアライズドビューをインテリジェントに活用することでパフォーマンスをさらに最適化し、データ変換ワークフローを合理化してクエリパフォーマンスを向上させたい組織にとって強力なツールとなっています。 付録 1: Apache Iceberg マテリアライズドビューを保存するための Amazon S3 Tables を使用する Spark 設定 この記事で前述したように、マテリアライズドビューはお客様のアカウント内の Amazon S3 Tables バケットに Iceberg テーブルとして保存されます。汎用 Amazon S3 バケットではなく Amazon S3 Tables をマテリアライズドビューの保存場所として使用する場合は、Amazon S3 Tables カタログで Spark を設定する必要があります。 前提条件セクションで示した標準の AWS Glue Data Catalog 設定との違いは、 glue.id パラメータの形式です。Amazon S3 Tables の場合は、アカウント ID だけでなく、 &lt;account-id&gt;:s3tablescatalog/&lt;s3-tables-bucket-name&gt; の形式を使用します。 spark-sql \ &nbsp;&nbsp;--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions \ &nbsp;&nbsp;--conf spark.sql.catalog.s3t_catalog=org.apache.iceberg.spark.SparkCatalog \ &nbsp;&nbsp;--conf spark.sql.catalog.s3t_catalog.type=glue \ &nbsp;&nbsp;--conf spark.sql.catalog.s3t_catalog.warehouse="s3://amzn-s3-demo-bucket/warehouse" \ &nbsp;&nbsp;--conf spark.sql.catalog.s3t_catalog.glue.region="us-east-1" \ &nbsp;&nbsp;--conf spark.sql.catalog.s3t_catalog.glue.id="123456789012:s3tablescatalog/amzn-s3-demo-table-bucket" \ --conf spark.sql.catalog.s3t_catalog.glue.account-id=123456789012 \ --conf spark.sql.catalog.s3t_catalog.client.region="us-east-1" \ --conf spark.sql.catalog.s3t_catalog.glue.lakeformation-enabled=true \ &nbsp;&nbsp;--conf spark.sql.optimizer.answerQueriesWithMVs.enabled=true \ &nbsp;&nbsp;--conf spark.sql.defaultCatalog=s3t_catalog これらの設定で Spark を設定した後、この記事で示したのと同じ SQL コマンドを使用してマテリアライズドビューを作成および管理でき、マテリアライズドビューは Amazon S3 Tables バケットに保存されます。 付録 2: Spark SQL でマテリアライズドビューの更新を確認する Spark SQL で SHOW TBLPROPERTIES を実行して、どの更新方法が使用されたかを確認します。 +-------------------------------+----------------------------------------------------------------------------------------------------------------------------------+ |key |value | +-------------------------------+----------------------------------------------------------------------------------------------------------------------------------+ |IMV_ansiEnabled |false | |IMV_catalogInfo |[{"catalogId":"123456789012","catalogName":"glue_catalog"}] | |IMV_mvCatalogID |123456789012 | |IMV_mvNamespace |iceberg_mv | |IMV_region |us-east-1 | |IMV_sparkVersion |3.5.6-amzn-1 | |current-snapshot-id |5750703934418352571 | |format |iceberg/parquet | |format-version |2 | |isMaterializedView |true | |lastRefreshType |INCREMENTAL | |subObjects |[{"Version":"4887707562550190856","DatabaseName":"iceberg_mv","Region":"us-east-1","CatalogId":"123456789012","Name":"base_tbl"}] | |tableVersionToken |*********(redacted) | |viewOriginalText |SELECT\ncustomer_name, \nCOUNT(*) as mv_order_count, \nSUM(amount) as mv_total_amount \nFROM base_tbl\nGROUP BY customer_name | |viewVersionId |5750703934418352571 | |viewVersionToken |*********(redacted) | |write.parquet.compression-codec|zstd | +-------------------------------+----------------------------------------------------------------------------------------------------------------------------------+ 著者について Tomohiro Tanaka AWS の Senior Cloud Support Engineer です。AWS 上のデータレイクで Apache Iceberg を使用するお客様を支援することに情熱を注いでいます。余暇には、同僚とのコーヒーブレイクや自宅でのコーヒー作りを楽しんでいます。 Leon Lin AWS の Software Development Engineer で、Open Data Analytics Engines チームで Apache Iceberg と Apache Spark の開発に注力しています。オープンソースの Apache Iceberg プロジェクトへのアクティブなコントリビューターでもあります。 Noritaka Sekiyama AWS Analytics サービスの Principal Big Data Architect です。お客様を支援するためのソフトウェアアーティファクトの構築を担当しています。余暇には、ロードバイクでのサイクリングを楽しんでいます。 Mahesh Mishra AWS Analytics チームの Principal Product Manager です。AWS の多くの大規模なお客様と新興テクノロジーのニーズについて協力し、トランザクショナルデータレイクの強力なサポートを含む、AWS 内のいくつかのデータおよびアナリティクスイニシアチブをリードしています。 Layth Yassin AWS Glue チームの Software Development Engineer です。大規模で困難な問題に取り組み、分野の限界を押し広げる製品を構築することに情熱を注いでいます。仕事以外では、バスケットボールをプレイしたり観戦したり、友人や家族と過ごすことを楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

信じられますか? 2025 年がもうすぐ終わろうとしています。今年もすばらしい 1 年でした! re:Invent のまとめイベントから、AWS Summit、AWS Innovate、AWS re:Inforce、Community Day、DevDay、そして有終の美を飾る最近の re:Invent 2025 まで、この 1 年も新しい近代的な世界を形作り続けるエキサイティングな瞬間とテクノロジーの進歩でいっぱいでした。 re:Invent といえば、すべての新しいリリースや発表をまだご覧になっていなければ (あらゆる分野でエキサイティングなリリースがたくさんありました)、 AWS re:Invent 2025 での注目の発表 を取り上げた厳選記事をぜひお読みください。主要リリースのすべてをわかりやすいカテゴリー別にまとめて、関心を持った事柄をさらに深く掘り下げることができるようにリンクを記載しています。 2025 年は終わりに近づいているかもしれませんが、私たちのチームは今も、お客様からリクエストされた事柄や、お客様の生活を楽にするために私たちがプロアクティブに作成している事柄における作業で大忙しです。先週もいつものように興味深いリリースが多数行われました。皆さんの役に立つと思われるものをいくつか選んだので、一緒に見ていきましょう。 2025 年12 月 8 日週のリリース Amazon WorkSpaces Secure Browser がウェブコンテンツフィルタリングを導入 – 組織は、25 個以上の事前定義済みカテゴリー全体でのカテゴリーベースのフィルタリング、きめ細かな URL ポリシー、統合されたコンプライアンスロギングを通じてウェブアクセスを制御できるようになりました。既存の Chrome ポリシーと連動し、モニタリングを強化するためのセッションロガーと統合するこの機能は、WorkSpaces Secure Browser が従量制料金で提供される 10 個の AWS リージョンでご利用いただけ、追加料金はかかりません。 Amazon Aurora DSQL が数秒間のクラスター作成のサポートを開始 &nbsp;– 開発者は、数分から数秒に短縮されたセットアップ時間で Aurora DSQL を瞬時に作成できるようになりました。これは、統合された AWS コンソールクエリエディタ、または Aurora DSQL モデルコンテキストプロトコルサーバー経由での AI 駆動開発を通じたラピッドプロトタイピングを可能にします。Aurora DSQL が提供されているすべての AWS リージョンで利用でき、追加料金はかかりません。AWS 無料利用枠も利用できます。 Amazon Aurora PostgreSQL が Kiro power との統合のサポートを開始 – 開発者は、事前にパケージ化されたモデルコンテキストプロトコルサーバーのリポジトリである Kiro power を用いた AI 支援のコーディングを使用して、Aurora PostgreSQL アプリケーション開発を迅速化できるようになりました。Aurora PostgreSQL 統合は、クエリ、スキーマ管理、クラスター操作のための直接的なデータベース接続を提供し、開発者が作業すると同時に関連するコンテキストを動的にロードします。すべての AWS リージョンで、Kiro IDE にワンクリックでインストールできます。 Amazon ECS が AWS Fargate でのカスタムコンテナ停止シグナルのサポートを開始 &nbsp;– Fargate タスクがコンテナイメージ内に設定された停止シグナルに従うようになりました。そのため、デフォルトの SIGTERM ではなく、SIGQUIT や SIGINT といったシグナルに依存するコンテナの正常シャットダウンが可能になります。ECS コンテナエージェントは OCI 準拠のイメージから STOPSIGNAL 命令を読み取り、タスク終了中に適切なシグナルを送信します。すべての AWS リージョンでご利用いただけ、追加料金はかかりません。 Amazon CloudWatch SDK が最適化された JSON プロトコルと CBOR プロトコルをサポート &nbsp;– CloudWatch SDK が JSON プロトコルと CBOR プロトコルをデフォルトとし、従来の AWS クエリプロトコルよりも低いレイテンシー、小さいペイロードサイズ、少ないクライアント側 CPU およびメモリ使用量を実現するようになりました。すべての AWS リージョンと SDK 言語バリアントでご利用いただけ、追加料金はかかりません。 Amazon Cognito アイデンティティプールが AWS PrivateLink とのプライベート接続のサポートを開始 – 組織は、一次的な AWS 認証情報用のフェデレーティッドアイデンティティをプライベート VPC 接続経由でセキュアに交換できるようになり、認証トラフィックをパブリックインターネット経由でルーティングする必要がなくなりました。Cognito アイデンティティプールがサポートされているすべての AWS リージョン (AWS 中国 (北京) リージョンと AWS GovCloud (米国) リージョンを除く) でご利用いただけます。 AWS Application Migration Service が IPv6 をサポート &nbsp;– 組織は、IPv4 通信と IPv6 通信の両方をサポートするデュアルスタックサービスエンドポイント経由で、IPv6 アドレッシングを使用したアプリケーションの移行を行えるようになりました。レプリケーション、テスト、カットオーバーの各フェーズ中に IPv4、IPv6、またはデュアルスタック構成を使用して、ターゲット環境でサーバーを起動できます。MGN および EC2 デュアルスタックエンドポイントをサポートするすべての AWS リージョンでご利用いただけ、追加料金はかかりません。 AWS News Blog Weekly Roundup は、12 月 15 日週だけでなく、2025 年でも最後の回になります! 少しの間お休みをいただきますが、1 月から再び AWS の最新リリースとアップデートをお届けしていきます。 2025 年の締めくくりに 1 年を振り返り、年の初めからどれだけ変化してきたかを見るのは実にすばらしいものです。AWS は、画期的な AI 機能から革新的なインフラストラクチャイノベーションまで、クラウドの可能性を再形成する数々のリリースで驚くべき 1 年を実現してきました。その間ずっと、AWS ニュースブログは Weekly Roundup シリーズでニュースを毎週お届けすることで、皆さんが常に最新情報を把握し、新たな機会が訪れるとともにそれらを活用できるようにしてきました。この旅に参加してくださった皆さんに感謝しています。2026 年 1 月からも最新の AWS イノベーションを引き続き皆さんにお届けしていくのが待ちきれません。 2026 年がこれまで以上にエキサイティングな 1 年になりますように! ハッピービルディング! Matheus Guimaraes | @codingmatheus 原文は こちら です。

2024 年 6 月に MLflow を搭載した Amazon SageMaker AI を発表 して以来、弊社のお客様は MLflow トラッキングサーバーを使用して 機械学習 (ML) と AI 実験のワークフローを管理してきました。この基盤を基に、MLflow のエクスペリエンスを進化させて、実験をさらに利用しやすくしています。 2025 年 12 月 2 日、 MLflow を搭載した Amazon SageMaker AI に、インフラストラクチャ管理が不要なサーバーレス機能が含まれるようになったことを発表できたことを嬉しく思います。この新しい MLflow 機能により、キャパシティプランニングが不要になる自動スケーリングにより、実験の追跡を即時のオンデマンドエクスペリエンスに変換できます。 ゼロインフラストラクチャ管理への移行は、チームの AI 実験へのアプローチ方法を根本的に変えます。インフラストラクチャを計画しなくてもアイデアをすぐにテストできるため、より反復的で探索的な開発ワークフローが可能になります。 Amazon SageMaker AI および MLflow の開始方法 最初のサーバーレス MLflow インスタンスを作成する手順を説明します。 Amazon SageMaker AI Studio コンソール に移動して MLFlow アプリケーションを選択します。 MLflow アプリ という用語は、以前の MLflow 追跡サーバー の用語に代わるもので、単純化されたアプリケーション重視のアプローチを反映しています。 ここで、デフォルトの MLflow アプリケーションがすでに作成されていることがわかります。このように単純化された MLflow エクスペリエンスにより、実験を始めるのがより簡単になりました。 [MLflow アプリを作成] を選択し、名前を入力します。ここでは、 AWS Identity and Access Management (IAM) ロール と Amazon Simple Storage Service (Amazon S3) バケットの両方がすでに設定されています。必要な場合にのみ、 詳細設定 で変更する必要があります。 ここで、最初の大きな改善点が明らかになります。作成プロセスは約 2 分で完了します。この即時可用性により、インフラストラクチャ計画の遅延なしに迅速な実験が可能になり、以前は実験ワークフローを中断していた待ち時間がなくなります。 作成後、ノートブックから接続するための MLflow Amazon リソースネーム (ARN) が届きます。管理がシンプルなため、サーバのサイジングの決定やキャパシティプランニングが不要になります。異なる構成を選択したり、インフラストラクチャの容量を管理したりする必要がなくなったため、実験に完全に集中できます。MLFlow SDK の使用方法については、 「Amazon SageMaker デベロッパーガイド」の「MLFlow をお客様の環境と統合する」 を参照してください。 MLflow 3.4 のサポートにより、 生成 AI 開発の新しい機能にアクセスできるようになりました。MLflow Tracing は、開発ライフサイクル全体にわたって詳細な実行パス、入力、出力、メタデータをキャプチャし、分散型 AI システム全体で効率的なデバッグを可能にします。 この新機能では、 AWS Resource Access Manager (AWS RAM) 共有によるクロスドメインアクセスとクロスアカウントアクセスも導入されています。このコラボレーションの強化により、異なる AWS ドメインやアカウントのチームが MLflow インスタンスを安全に共有できるようになり、組織のサイロ化が解消されます。 連携のメリット: パイプライン統合 Amazon SageMaker Pipelines は MLFlow と統合されています。SageMaker Pipelines は、 機械学習オペレーション (MLOps) と大規模言語モデルオペレーション (LLMOP) の自動化を目的として構築されたサーバーレスワークフローオーケストレーションサービスです。これは、本番稼働環境での ML および LLM モデルの展開、モニタリング、管理の実践です。直感的なドラッグアンドドロップ UI または Python SDK を使用して、反復可能なエンドツーエンドの AI ワークフローを簡単に構築、実行、モニタリングできます。 パイプラインから、デフォルトの MLflow アプリがまだ存在しない場合は作成されます。テスト名を定義すると、コードの定義に従ってメトリクス、パラメーター、アーティファクトが MLflow アプリに記録されます。MLflow を搭載した SageMaker AI は、 SageMaker AI JumpStart や Model Registry などの使い慣れた SageMaker AI モデル開発機能とも統合されているため、データ準備からモデルのファインチューニングまで、エンドツーエンドのワークフロー自動化が可能になります。 知っておくべきこと 留意点は以下のとおりです。 価格 — 新しいサーバーレス MLflow 機能は追加費用なしで提供されます。サービス制限が適用されることに注意してください。 可用性 – この機能は現在、米国東部 (バージニア北部、オハイオ)、米国西部 (カリフォルニア北部、オレゴン)、アジアパシフィック(ムンバイ、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、パリ、ストックホルム)、南米 (サンパウロ) の AWS リージョンでご利用いただけます。 自動アップグレード: MLflow インプレースバージョンアップグレードは自動的に行われるため、手動での移行作業や互換性の懸念なしに最新の機能にアクセスできます。このサービスは現在 MLflow 3.4 をサポートしており、強化されたトレース機能を含む最新機能にアクセスできます。 移行サポート — mlflow-export-import で利用できるオープンソースの MLflow エクスポート/インポートツールを使用すると、既存のトラッキングサーバーから SageMaker AI、セルフホスト、その他の方法でサーバーレス MLflow (MLflow アプリ) に移行できます。 Amazon SageMaker AI Studio にアクセスして初めての MLflow アプリケーションを作成し、サーバーレス MLFlow を使い始めまることができます。SageMaker Unified Studio ではサーバーレス MLflow もサポートされているため、ワークフローの柔軟性が高まります。 よい実験を! – Donnie 原文は こちら です。

2025 年 12 月 2 日、 Amazon Simple Storage Service (Amazon S3) を使用して、 Amazon FSx for NetApp ONTAP 内のデータにアクセスできるようになったことを発表しました。この機能により、企業内のファイルデータを活用して、 検索拡張生成 (RAG) 用 Amazon Bedrock のナレッジベース による生成 AI アプリケーションの拡張、 Amazon SageMaker を用いた 機械学習 (ML) モデルのトレーニング、Amazon S3 と統合されたサードパーティサービスによるインサイト生成、 Amazon Quick Suite などの AI 搭載ビジネスインテリジェンス (BI) ツールでの包括的なリサーチ、さらに Amazon S3 を基盤としたクラウドネイティブアプリケーションによる分析を実行できます。これらすべてを、ファイルデータを FSx for NetApp ONTAP ファイルシステム内に保持したまま行うことが可能です。 Amazon FSx for NetApp ONTAP は、データの管理方法を変更することなく、NetApp ONTAP やその他の ネットワークアタッチドストレージ (NAS) アプライアンスに依存するオンプレミスアプリケーションを AWS に移行できる、クラウド初の完全 AWS マネージド型 NetApp ONTAP ファイルシステムです。FSx for NetApp ONTAP は、ONTAP ファイルシステムの一般的な機能、高パフォーマンス、データ管理 API に加えて、管理の簡素化、オンデマンドのスケーリング、他の AWS サービスとのシームレスな統合など、AWS クラウドの利点も提供します。 長年にわたり、AWS は Amazon S3 のデータを扱う業界をリードする AI、ML、分析サービスとアプリケーションを幅広く開発してきました。これらのサービスやアプリケーションを使用することで、組織はより迅速にイノベーションを起こし、新しいインサイトを発見し、より優れたデータ主導型の意思決定を行うことができます。ただし、NetApp ONTAP やその他の NAS アプライアンスに保存されているエンタープライズファイルデータでこれらのサービスを利用したいと考える組織もあります。 開始方法 S3 Access Point は、 Amazon FSx コンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して作成し、FSx for ONTAP ファイルシステムにアタッチできます。 ONTAP ファイルシステムの demo-create-s3access 用既存の FSx があります。これは FSx for ONTAP ドキュメントの「ファイルシステムの作成」 の手順に従って作成しました。Amazon FSx コンソールを使用して、ファイルシステム ID fs-0c45b011a7f071d70 を選択して、ファイルシステムのすべての詳細にアクセスできるようになりました。 アクセスポイントをファイルシステムのボリュームに接続します。ボリューム vol1 を選択し、 [アクション] ドロップダウンメニューから [S3 Access Point を作成] を選択します。 アクセスポイント名 、 ファイルシステムユーザ ID のタイプ 、 ネットワーク設定 などの詳細を入力し、 [s3 Access Point を作成] を選択してプロセスを終了します。 作成が完了すると、アクセスポイント my-s3-accesspoint を使用して、Amazon S3 から自分のファイルシステム demo-create-s3access に保存されているファイルデータにアクセスできるようになります。 Amazon アクセスポイント は、Amazon FSx ボリュームにアタッチして Amazon S3 オブジェクトオペレーションを実行するために使用できる S3 エンドポイントです。 これで、ファイルシステム demo-create-s3access に保存されている所有データを Amazon S3 に持ち込んで、Amazon S3 と連携するアプリケーションで使用できるようになりました。ただし、ファイルデータはアクセスポイント my-s3-accessspoint を使用して FSx for NetApp ONTAP ファイルシステムに引き続き格納されます (このデータにはファイルプロトコルを通じて引き続きアクセスできます)。 この記事のウォークスルーでは Quick Suite と統合します。 何十年にもわたるエンタープライズファイルデータを、AWS 上の AI を活用した最新の BI ツールと統合 Quick Suite Console の左側のナビゲーションペインで [接続] を選択し、 [統合] を選択します。開始する前に、Amazon S3 AWS リソースに対する正しいアクセス権限があることを確認します。Quick Suiteが アクセスできる AWS リソースは、「 Amazon Quick Suite ユーザーガイド 」に従って管理できます。 Amazon S3 統合 を選択したら、 S3 バケット URL として Amazon S3 Access Point のエイリアスを入力し、残りの情報はデフォルトのままにして、 [作成して続行] を選択します。 ナレッジベースの 名前 と 説明 を入力してプロセスを終了し、 [作成] を選択します。 ナレッジベースが作成されると、自動的に同期され、インタラクションが可能になります。 AWS European Sovereign Cloud について詳しく知りたいので、このトピックに関する AWS ホワイトペーパーでファイルシステム (S3 Access Point my-s3-accesspoin-iyytkgz83djdjj7abn3u711supfgkuse1b-ext-s3alias ) を更新しました。Amazon Quick Suite のチャットで、最初の質問「 欧州のソブリンクラウドに関する文書はありますか? 」を始めます。私の質問に答えるために、 チャットエージェントは、私が使用権限を持っているさまざまなタイプのデータソースにアクセスして分析します 。その中には、現在の会話でアップロードされたファイル、アクセスできるスペース、統合のナレッジベースがあります。 ソースを確認すると、ファイルシステムにアップロードしたドキュメントがソースの 1 つとしてリストされていることがわかります。 Amazon FSx for NetApp ONTAP 用 Amazon S3 Access Points のその他のユースケース 先ほど、組織独自のファイルデータを Amazon Quick Suite に接続して高度なビジネスインテリジェンスを実現するなどのユースケースについて説明しました。さらに、Amazon FSx for NetApp ONTAP の Amazon S3 Access Points を使用すると、エンタープライズファイルデータを、 サーバーレス SQL クエリ用の Amazon Athena や ETL 処理用の AWS Glue などの包括的な分析サービスとシームレスに統合できます。 Amazon FSx for NetApp ONTAP の Amazon S3 Access Points は、設定ファイル、参照データ、コンテンツライブラリ、モデルアーティファクト、アプリケーション資産などの共有エンタープライズデータセットへの柔軟なアクセスを必要とする、コンテナ化されたマイクロサービスを備えたクラウドネイティブな サーバレス コンピューティングワークロードからのデータアクセスにも適しています。 今すぐご利用いただけます Amazon FSx for NetApp ONTAP ファイルシステムへの Amazon S3 Access Points のアタッチは、Amazon FSx コンソール、AWS CLI、または AWS SDK を使用して今すぐ開始できます。この機能が利用できる AWS リージョン は、アフリカ (ケープタウン)、アジアパシフィック (香港、ハイデラバード、ジャカルタ、メルボルン、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)、カナダ (セントラル、カルガリー)、欧州 (フランクフルト、アイルランド、ロンドン、ミラノ、パリ、スペイン、ストックホルム、チューリッヒ)、イスラエル (テルアビブ)、中東 (バーレーン、UAE)、南米 (サンパウロ) 、米国東部 (バージニア北部、オハイオ) 、および米国西部 (カリフォルニア北部、オレゴン) です。Amazon FSx の標準料金に加えて、S3 Access Points 経由のリクエストとデータ転送に対する Amazon S3 料金が請求されます。詳細については、 Amazon FSx for NetApp ONTAP の料金ページ をご覧ください。 追記: AWS でのブログ記事の執筆は、常にチームとしての取り組みです。これは、記事のタイトルの下に 1 人の名前しか表示されない場合でも同様です。今回は、テクニカルガイダンスでの専門知識と惜しみない援助を提供してくれた Luke Miller に感謝の意を述べたいと思います。この包括的な概要をまとめることができたのは同氏のおかげです。 – Veliswa Boya 。 原文は こちら です。

アマゾン ウェブ サービス ジャパン（以下、AWS）は 2025 年 11 月 11 日に、「【EdTech Meetup】 AI 時代の EdTech ～プロダクト・開発・運用の変革と EdTech の未来～」を AWS Startup Loft Tokyo にて開催しました。 AI 技術の急速な発展により大きな変革期を迎えている教育テクノロジー（EdTech）分野について、ユニファ株式会社、スタディポケット株式会社、ビズメイツ株式会社からのライトニングトークとパネルディスカッションを通じて議論を深めました。 EdTech スタートアップ、教育関係者、テクノロジー企業など、多様な参加者が70名以上集まり、知見の共有と交流を深める場となりました。本ブログではそのレポートをお届けします。 オープニング AWS パブリックセクター 教育・研究事業本部 事業本部長 白石 智良 「一年前の EdTech Meetup では『生成 AI という言葉が当たり前になってきました』と言っていましたが、もうそれから一年経ち、完全に日常に生成 AI が入っています。教育業界における生成 AI と人間の関係性、学習の個別最適化、導入時の障壁や運用コストの最適化など、重要なテーマについて、進的に取り組んでいる企業の CxO から様々な事例や取り組みをご紹介いただき、懇親会で皆様と意見交換できればと思います。」と挨拶しました。 ライトニングトーク① : ユニファ株式会社 ユニファ株式会社 執行役員 CPO プロダクトデベロップメント本部 本部長 兼 AI 開発推進部 部長 山口 隆広 氏 ユニファ株式会社は、ICT・IoTを活用した業務負荷削減と、ドキュメンテーションによる振り返り支援の観点から、こどもともっと向き合う豊かな環境を整える保育施設向け総合 ICT サービス「ルクミー」を展開しています。 「保育 AI」の取り組みでは、「保育士さんの業務負担の軽減だけが問題ではなく、こどもの安全や成長のサポートも重要」と強調。具体的な AI 活用事例として以下を挙げました： 若手保育士の育成支援: 連絡帳の誤字脱字チェックに AI を活用することで、本質的な保育の指導に時間を使えるようになった。 写真管理の効率化: 保育園の多くは一回のイベントで約1000〜2000枚の写真を撮影するが、AI を使ってこどもの顔認識や不適切な写真のフィルタリング、こどもごとの枚数のバランス調整などを効率化できるようになりつつある。 記録の活用: 従来は紙のファイルに保存されていた保育記録をデータ化し、AI 経由で他の先生が参照できるようにすることで、引き継ぎなどに役立てられるようになった。 山口氏は、AI の導入には当初反発もあったことを振り返り、「保育士の先生だからできる大事なところはたくさんあります。ただ、誤字脱字や文章の修正など、先生が頑張るべきことではない部分は AI に任せましょう。」という考え方で理解を得てきたと説明しました。また、国や自治体が AI の活用を推進する姿勢を示すことが、現場での導入を促進する上で重要だと指摘しました。 ライトニングトーク② : スタディポケット株式会社 スタディポケット株式会社 代表取締役 CPO 鶴田 浩之 氏 スタディポケット株式会社は、学校・教育機関向けに、セキュアな環境で簡単に導入できる生成 AI サービスを提供しています。 鶴田氏は、「答えを教えない AI 」というコンセプトでハッカソンに参加したところ、学校現場からの反響を受けて、スタディポケットが誕生したという経緯を紹介しました。 「スタディポケットが提供するソリューションの特徴は、教員向けのソリューションとこどもたちの学習をサポートするソリューションの二つが表裏一体になっていることです。生成 AI としては、Amazon Bedrock で Anthropic の Claude モデルなどを利用しています。それにより、先生たちはセキュアな環境で、こどもたちは安心安全に使えるガードレールを整備した環境で生成 AI を利用できています。」 「教員向けソリューションで特に反響が大きかったのは、学校の先生特有のプロンプトのテンプレートを40～50種類用意し、プロンプトエンジニアリングの知識がなくても直感的に AI を使えるようにしたこと。また13歳未満の利用についてのルールを早期に定めました。」 「答えを直接教えないという、考えに伴走していくというコンセプト」を初期から打ち出していたことが、AI を用いたサービスが受け入れられた要因だと分析しています。学校の伴奏支援も必要で、「ただ導入しただけだと全然使わない」という課題に対しては、ワーキンググループを作るなど、きめ細やかなサポートの重要性を強調しました。 ライトニングトーク③ : ビズメイツ株式会社 ビズメイツ株式会社 IT本部 本部長 兼 CTO 林 哲也 氏 ビズメイツ株式会社は、「もっと多くのビジネスパーソンが世界で活躍するために」というミッションのもと、ビジネス特化型オンライン英会話サービス「Bizmates」を主力として、ビジネス日本語教育やグローバル人材マッチングなど複数のサービスを提供しています。 ビズメイツは、「日常会話を幅広く学ぶより、使用シーンが限られるビジネス英語に特化することは学習の近道になる」という考えのもと、創業以来ビジネスに特化した英語教育を提供しています。現在では、AI によって「受講生の業種、職種、状況に特化した最適な英語教材を生成」「受講生のオンライン英会話レッスン音声の AI データ解析を基にした英語学習コーチングを提供」と更に学習体験のパーソナライズ化が進んでいます。 ハイブリッド型英語学習の特長として、アプリでの自習（インプット）、人間のコーチによる伴走・動機づけ、対人のオンライン英会話でのアウトプット、AI と人それぞれの強みを組み合わせていることを挙げ、この中での AI 活用例として業種・職種・シーン別に学習者ごとに最適化したロールプレイの生成、発音評価、レッスン音声の分析などを紹介しました。 開発面では、要件定義から実装、テストまでの開発ライフサイクル全体で AI を活用し始めていると説明しました。FuelPHP から Laravel への移行や Vue.js のバージョンアップなどの領域で、生成 AI を搭載した会話型アシスタント Amazon Q Developer などを活用しており、サービス提供と開発の両面で AI が活用できることを強調しました。 「AI によって個別最適な学習体験を提供する一方で、自走支援には人間による動機づけやコーチングも重要」とし、開発においても「AI は標準的な開発の生産性を上げ、人間は変革をする企画やレビューを行う。人間が AI と一緒になりながら、より良いサービスを開発していきたい」と今後の展望を示しました。 ライトニングトーク④ : AWS AWS パブリックセクター 技術統括本部 教育・研究技術本部 本部長 松井 佑馬 「AWS の AI ポートフォリオは、インフラ層（GPU等）、基盤モデル層（Amazon Bedrock等）、アプリケーション層の3つのレイヤーに分かれています。今日は、アプリケーション層の新しいサービスである『Amazon QuickSuite』について詳しく説明します。Amazon QuickSuite は、AI エージェントと一緒に働くことが普通になる中で、業務データを把握し素早く答えを出し、アクションにつなげられる AI エージェントを提供するサービスです。2025年10月に一般提供が開始されたばかりで、ダッシュボード作成サービスである Amazon QuickSite に AI 機能を追加した発展版です。」 デモにて、チャットによるデータ探索、ドメインやチームごとの権限管理、タスクの自動化ワークフロー、複数データソースを参照したリサーチ機能をお見せしました。ユースケースの例として、営業担当者が商談の議事録から日報を作成し、Slack に投稿するという一連の流れを AI に自動化させる例を紹介。このサービスはデベロッパー向けではなく、ビジネスユーザーが自然言語で定義できることが特徴だと強調しました。 パネルディスカッション ＜モデレーター＞ AWS パブリックセクター 教育・研究事業本部 アカウントマネージャー 尾島 菜穂 ＜パネリスト＞ スタディポケット株式会社 代表取締役 CPO 鶴田 浩之 氏 ビズメイツ株式会社 IT本部 本部長 兼 CTO 林 哲也 氏 ユニファ株式会社 執行役員CPO プロダクトデベロップメント本部 本部長 兼 AI開発推進部 部長 山口 隆広 氏 AWS パブリックセクター 技術統括本部 教育・研究技術本部 本部長 松井 佑馬 AI と人間の最適な役割分担 山口氏（ユニファ）：「保育の専門性は AI に持たせない」という方針。こどもの表情一つをとっても、笑顔の裏に嫌なことがあって笑う癖がある子もいるなど、AI では判断できない専門性が存在するからです。そのため、AI の役割は「先生が活かせるデータを簡単に集めること」に限定。若手保育士の育成においても、AI が生成した情報を「正解だと思い込んでしまう」リスクを避けるため、あえて使わない判断をしています。 鶴田氏（スタディポケット）：教員へのアプローチとして「働き方改革」よりも「授業の質が高められる」という点を強調すると興味を持ってもらえます。教師の役割は変わっても無くならず、教室の「コミュニティマネージャー」のような存在になっていくと予測しています。また、こどもたちが AI を使うことで、自分で応用問題に挑戦したり、苦手な単元をキャッチアップできるようになり、結果的に「こどもたちが使った方が先生の働き方改革になる」という効果も生まれています。 林氏（ビズメイツ）：AI によって「何を覚えるべきか」が変わってきています。翻訳ツールにより「英語を覚えなくても会議ができる」時代になりつつあるが、最終的には「人間として人間に伝える」ことが重要であり、「英語を教えるのではなく、グローバルで活躍できるビジネスのやり方を教える」という人間の役割を重視しています。 AI のコスト課題と工夫 鶴田氏（スタディポケット）：一般企業に比べて、教育業界の予算が少ないことに驚きました。公立学校向けには、月額ではなく年間2,000〜3,000円を切る価格設定が必要です。高性能なモデルを初期に提供し、モデルの価格が下がるのを見越した戦略を取り、必要に応じてモデルを切り替えたり、キャッシュ技術を活用するなどのコスト最適化の工夫をしています。 林氏（ビズメイツ）：AI を使って顧客の利便性を高め、「その利便性に見合う付加価値」としてオプション価格をいただく形でコストを回収しています。コーチングサービスやモバイルアプリなど、新たな付加価値の中に AI のコストを含める形を取っています。 山口氏（ユニファ）：保育領域は予算が限られているところも多いので、テキスト処理などは無料で提供し、画像処理など負荷の重い処理は課金する形を取っています。写真販売などのビジネスモデルでマージンが増えるような AI 機能は無料で提供するなど、「間接的にいただく」工夫もしています。さらに、期待値をコントロールすることで価格を抑えたモデルでも満足してもらえるようにしていています。 松井（AWS）からは、技術的観点から、最適なモデルの使い分けやトークン節約のためのキャッシュ活用、コンテキスト圧縮などの工夫を紹介しました。 開発・運用での AI 活用 林氏（ビズメイツ）：フィリピンの子会社でも AI を導入しており、フィリピンのメンバーも「AI に発注して、作らせて、納品されたものをチェックする」という役割に変わりつつあります。そのためコードを書くエンジニアから要件定義や QA を担当する役割へのシフトが起きています。また、グローバルでは英語の情報が豊富なため、日本よりも AI 活用が進んでいる面もあります。 山口氏（ユニファ）：インフラ面では Amazon Q を活用している一方、アプリケーション開発ではエンジニアによって AI 活用度に大きな差があります。特に非エンジニア職種（QA エンジニアやデザイナー）の方がむしろ AI を積極的に活用し、「エンジニアに聞きづらかったことを AI に聞く」ことで成果を出している傾向があります。 鶴田氏（スタディポケット）：コードの8割が AI コーディングベースになっています。プルリクエストのコードレビューには複数の LLM を同時に走らせ、様々な観点からレビュー。また、私自身も AI と共にプロトタイピングを行うことで「2日で新機能を見せる」といった高速開発が可能になっています。 教育現場での導入障壁と克服策 鶴田氏（スタディポケット）：「活用する人としない人の差」が生まれることが課題。特に契約する主体（教育委員会など）と実際に使う主体（先生やこどもたち）が異なる中で、いかに満遍なく使ってもらうかが重要です。 山口氏（ユニファ）：保護者からの視線が障壁になることがあります。「保育士がスマホで連絡帳をチェックしていると、遊んでいると思われる」といった誤解が生まれうるため、「こどもの育ちをより分析し、保護者に伝えるために AI を使っている」というストーリー作りが重要です。 会場からの質問 質問「AI がジュニアエンジニアを代替しているという傾向は実感するか」 山口氏（ユニファ）：AI 活用に対してネガティブな人はエンジニア採用において「減点」になりつつあります。一方で「自分の方が優秀だから使わない」という人もいるが、それは現時点での能力なので、「インターネットと同様に使ってほしい」と考えています。 鶴田氏（スタディポケット）：むしろジュニアの方が AI を活用・吸収していて、「シニアでアンラーニングできない方がリスク」。20代前半の若手が AI で自己拡張している姿に「危機感を感じる」。 林氏（ビズメイツ）：AI が生成したものをレビューできるスキルが重要になるが、それができるシニアエンジニアの採用は簡単ではないため、「ジュニアエンジニアを採用して育てていく」ことが会社の使命だと思います。 質問「高校向けサービスで様々なアプリに AI が組み込まれ、ユーザーが混乱するのではないか」 鶴田氏（スタディポケット）：「AI は様々なものに大前提で入ってくる」、「インターネットのように空気のような存在になっていく」と予測しており、時間とともに情報リテラシーが育ち、成熟していくと思います。 質問「英語学習の AI 活用がコモディティ化している中での差別化」 林氏（ビズメイツ）：ビズメイツは「ハイブリッド学習」として、アプリでのインプット、人間のコーチによる伴走と動機づけ、オンライン英会話でのアウトプットを組み合わせることで、単なる AI 英会話ツールとは異なる価値を提供しています。 3年後のビジョン 山口氏（ユニファ）：「保育園・幼稚園などのデータを小学校に、小学校のデータを中学校に持っていけるようになれば、こどもの人生をもっと良くできる」ので、AI に合った法律整備に期待しています。 鶴田氏（スタディポケット）：スタディポケットは、ドラえもんのように、のび太に寄り添い、時に怒り、時に優しいサービスを目指しています。不登校だった生徒がスタディポケットを使って自分で勉強し、志望校に合格しています。多様な社会の中で、AI が幅広く機会を作り、黒子としてサポートできる存在になりたいです。 林氏（ビズメイツ）：3年後、今は人間がやらなければいけないと思われていることが AI でできるようになります。スピードがもっと上がることで、何を覚えるべきか、何を AI に任せるかの境目が変わると予想しています。 松井（AWS）：個人的見解だが、AI による社会変化は避けられないので、「AI に使われる人ではなく、AI を使いこなす人を育てる」という教育の役割が、ますます重要になると思います。 クロージング 最後は会場で懇親会が行われ、参加者同士の交流や登壇者との質疑応答など、活発な意見交換が行われ、AI 時代の教育について議論を深める貴重な機会となりました。 過去の EdTech Meetup に関しては、以下のブログをご参照ください： 【Edtech Meetup】教育×AI ～生成系 AI によって教育はどう変わるのか～【開催報告】 【Edtech Meetup】Edtech スタートアップがグローバルに活躍するには？【開催報告】 【Edtech Meetup】急成長サービスの秘訣と実践戦略【開催報告】 AWS パブリックセクターは今後も、EdTech がイノベーションを加速させるための、さまざまなテクニカル・ビジネスセッションやコミュニティ活動を実施予定です。ご関心をお持ちの方は、お気軽に お問い合わせ ください。教育のイノベーションに取り組まれる皆様のご参加をお待ちしております。 このブログは、 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター ソリューションアーキテクト 伊達幸希が執筆しました。

本ブログは、NetApp Japan が主催する Amazon FSx for NetApp ONTAP Advent Calendar 2025 の 19 日目の記事です。 皆様は Amazon FSx シリーズと聞くと、ファイルストレージサービスを想起するのではないでしょうか？私もそんな一人です。しかし、FSx シリーズの 1 つである Amazon FSx for NetApp ONTAP (FSx for ONTAP) はブロックストレージとしても利用できます。 FSx for ONTAP は高性能なブロックストレージであるとともに、マルチ AZ やマルチリージョンの構成を容易に実現できます。本ブログでは FSx for ONTAP について振り返りながら、FSx for ONTAP のブロックストレージとしての特徴を確かめてみたいと思います。 FSx for ONTAP の特徴 利用できるプロトコル FSx for ONTAP では、第 1 世代のファイルシステムと第 2 世代のファイルシステムがあります。後者については、 こちら のブログを参照してください。 図 1: 利用できるプロトコル そのほか、Amazon S3 Access Point を利用した、HTTPS アクセスも東京と大阪リージョンの FSx for ONTAP でご利用いただけます。NetApp Japan の小寺さんが作成した本アドベントカレンダーの ブログ もご参照ください。 マルチ AZ とマルチリージョン FSx for ONTAP は、シングル AZ 構成でもマルチ AZ 構成でも同様に 2 台のファイルシステムから成る冗長構成を採用しています。また、どちらの構成においても NFS や SMB で指定する接続先の IP アドレスは、フェイルオーバーの前後で変わりません。一方で、iSCSI や NVMe-over-TCP アクセス先の IP アドレスは ENI ごとに存在します。そのため、FSx for ONTAP でフェイルオーバーが発生した場合には、クライアント側で接続先のパスを切り替える必要があります。 なお、ENI が存在する VPC 外部からマルチ AZ 構成の FSx for ONTAP へと NFS や SMB でアクセスする場合、AWS Transit Gateway が必要となります。詳しくは こちら のリンクをご参照ください。 図 2 FSx for ONTAP の構成。上がシングル AZ、下がマルチ AZ。 マルチリージョン構成を採用する場合、 SnapMirror を活用できます。SnapMirror を用いると、プライマリリージョンにある FSx for ONTAP のストレージボリュームからセカンダリリージョンのストレージボリュームへと、スナップショット単位でデータをレプリケーションすることができます。災害復旧やバックアップ、データ保護の目的で広く活用されており、ビジネス継続性の確保に重要な役割を果たします。初回は全データをコピーし、その後は差分のみを転送することで、ネットワーク帯域の効率的な利用を実現しています。 ストレージ容量の効率化 FSx for ONTAP は、次の 3 つの方法で、データ容量を効率化します。マネジメントコンソールでボリュームを作成する際に、一括で設定することができます。 重複排除 圧縮 コンパクション 図 3 マネジメントコンソール上でのストレージ容量の効率化設定 ストレージの階層化 FSx for ONTAP ではアクセス頻度に応じて、ブロック単位でパフォーマンス重視の SSD ストレージ階層から低コストのキャパシティプール層へとデータを移動します。 FSx for ONTAP でブロックストレージを構成 今回は東京リージョンにシングル AZ の FSx for ONTAP を構築し、同じ VPC 内の Amazon EC2 から NVMe-over-TCP でアクセスします。NVMe-over-TCP は第 2 世代のファイルシステムのみ利用可能ですので、マネジメントコンソールでは「シングル AZ 2」を選択します。 図 4 マネジメントコンソール上での設定 ファイルシステムが作成されたら、FSx for ONTAP のファイルシステムへと接続し、NVMe-over-TCP プロトコルを用いて、Amazon EC2 からマウントします。詳細な手順は こちら のドキュメントに従います。なお、FSx for ONTAP 側での準備が完了すると、次の図のように NVMe-over-TCP に対応したネットワークインタフェースが 2 つ表示されます。これらの IP アドレスは、 ストレージ仮想マシン （SVM）の iSCSI IP アドレスに対応しています。 図 5 FSx for ONTAP において、NVMe-over-TCP プロトコルを使用するネットワークインターフェース 第 2 世代のFSx for ONTAP では、スループットと IOPS はそれぞれ 6 GBps と 200,000 IOPS まで設定することができ、高いパフォーマンスが必要なワークロードにも利用できます。スループットと IOPS 以外にも、細かいファイル操作が必要なワークロードではレイテンシが重要となるケースがあります。そこで、本ブログではレイテンシを fio というツールを用いて検証してみました。 今回は単純なコマンドのみ実行します。書き込みブロックサイズは 4 KB または 16 KB とします。1 GB のファイルを、ランダムリードとランダムライトで処理を行った時のレイテンシを測定します。なお、今回はレイテンシの測定が目的なため、ジョブの並列度は 1 としました。4 KB のブロックサイズで 1 GB のファイルをランダムリードしたときのサンプルコマンドを記載します。 fio --name=test --ioengine=libaio --rw=randread --bs=4k --direct=1 --size=1G --numjobs=1 --runtime=60 --group_reporting --filename=/fsx/ontap/example1.dat また、本ブログでは性能の検証が目的ではないので厳密な議論は行いませんが、レイテンシが低いことが分かります。 図 6 レイテンシの測定結果。RR、RW はそれぞれランダムリード、ランダムライトの略。clat_p50/clat_p95/clat_p99 はそれぞれ、Completion Latency における 50/95/99 パーセンタイル。 マルチリージョン構成 東京リージョンと大阪リージョンでシステム構成を統一する場合には、iSCSI を用いたブロックアクセスも有効です。iSCSI の設定方法は こちら をご覧ください。 まずは東京リージョンで作成したボリュームに対して、iSCSI でクライアントからアクセスします。そして、iSCSI でブロックアクセスしたボリューム上に、「Hello world!」と記載した hello.txt を作成します。このファイルは後ほど大阪リージョンのボリュームへと転送し、大阪リージョンのクライアントからアクセスできることを確認します。 次に、東京リージョンの FSx for ONTAP のボリュームから、大阪リージョンの FSx for ONTAP のボリュームへと SnapMirror でデータをレプリケーションします。 図 7 マルチリージョン構成 SnapMirror を転送する流れは、次の通りです。詳細は こちら のドキュメントを参照してください。 送信元と送信先の FSx for ONTAP のファイルシステム間でピアリング関係を構築 送信元と送信先の SVM 間でピアリング関係を構築 SnapMirror 関係を構築 SnapMirror でデータをレプリケーション SnapMirror で全てのデータの転送が完了した後、snapshot show コマンドを実行すると、大阪リージョンのファイルシステムに「snapmirror」というスナップショットが転送されていることが分かります。これは東京リージョンのファイルシステムから転送されたスナップショットで、上記の「hello.txt」を含んでいるはずです。 図 8 スナップショットの確認 この後、SnapMirror 関係を停止します。そして、大阪リージョンの FSx for ONTAP のボリュームに対して、iSCSI でクライアントからマウントすることで、ボリューム中のファイルへとアクセスすることができます。例えば、東京リージョンの FSx for ONTAP のボリュームに作成した hello.txt ファイルは大阪リージョンのボリュームへも転送され、下図のようにアクセスすることができます。 図 9 大阪リージョンのボリューム中のファイルへとアクセス FSx for ONTAP は、SnapMirror によってネイティブにマルチリージョンレプリケーションを実現できます。これにより、通常の AWS ブロックストレージで必要な AWS Elastic Disaster Recovery やアプリケーション層での実装が不要となり、シンプルな構成でリージョン間レプリケーションが可能です。 まとめ FSx for ONTAP はファイルストレージだけでなく、ブロックストレージとしても活用することができます。NVMe-over-TCP を利用することで、低レイテンシかつ高い可用性が要求されるシステムにも対応することができます。また、東京リージョンと大阪リージョンで同様の構成を採用したい場合には、iSCSI をプロトコルに採用した上で、SnapMirror によるレプリケーションで実現できます。 本ブログが皆様のお役に立てれば幸いです。 佐藤真也 アマゾンウェブサービスジャパン合同会社 フィナンシャルサービス技術本部 ソリューションアーキテクト AWS のストレージサービス全般が好きで、AWS Black Belt オンラインセミナーなどのイベントへの登壇にも力を入れています。

本ブログは 株式会社 Nint 様 と Amazon Web Services Japan 合同会社 が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの森です。 デジタル市場の急速な変化に伴い、多くの企業が新しいプラットフォームやサービスへの対応を迫られています。特に SaaS 事業者にとって、市場の変化に迅速に対応しながら、既存システムの運用負荷を抑制することは重要な経営課題となっています。 従来の仮想マシンベースのインフラでは、サーバー管理やスケーリング対応に多くの工数を要し、開発チームが本来注力すべきビジネスロジックの実装に集中することが困難となります。また、新しいサービスの立ち上げの度に、インフラ構築から始める必要があり、市場投入までの時間が長期化してしまうという問題もあります。さらに、既存システムの技術的負債が蓄積し、属人化が進むことで、将来的な拡張性や保守性に不安を抱える企業も少なくありません。 今回ご紹介するのは、EC データ分析サービスを提供する株式会社 Nint 様が、AWS のマネージドサービスを活用したモダンなアーキテクチャを採用し、新しい EC プラットフォーム対応 SaaS を わずか 2 か月で開発、さらに運用工数を 70% 削減した事例です。 Nint 様の状況と課題 株式会社 Nint 様 は、データ分析サービスを提供している企業です。10 年以上前から AWS を活用してサービスを展開してきましたが、当時は現在ほど多様なマネージドサービスは提供されておらず、Amazon EC2 を中心としたインフラ構成で運用していました。そのような中で、近年急成長した EC プラットフォームである TikTok Shop への対応が急務となり、以下のような課題に直面していました： 既存環境の運用負荷 Amazon EC2 で構築された既存環境は、追加開発や日々のメンテナンスにおける負荷が高く属人化していた サーバー管理、スケーリング、リソース最適化などの運用作業に多くの工数を要していた 将来性への懸念 将来的に既存環境を刷新する計画もあり、保守性の高いアーキテクチャを採用した新環境での開発を検討していた グローバル展開を見据え、各国への展開が容易なアーキテクチャが求められていた スケーラビリティと保守性を両立できるアーキテクチャが求められていた これらの課題を解決するため、Nint 様は AWS のマネージドサービスを活用した新しいアーキテクチャでの開発に着手しました。 ※ 画面は実際のお客様データではなく、デモ用のサンプルデータを使用しております。 ソリューション Nint 様は、AWSのマネージドサービスを最大限活用し、以下のようなモダンなアーキテクチャを採用しました： 独立したネットワーク環境の構築 既存環境とは異なる Amazon VPC 上で新サービスを開発 既存環境とは VPC Peering で接続し、連携が可能なアーキテクチャを採用 コンテナ化とマネージドサービスの活用 フロントエンドおよびバックエンドの両方を AWS Fargate 上でコンテナ化し運用 Infrastructure as Code（IaC）の実装 AWS Cloud Development Kit (CDK)により、インフラのコード化（Infrastructure as Code : IaC）を実現 GitHub Actions を活用した CI/CD パイプラインにより、デプロイメントプロセスを自動化 10 通り以上のアーキテクチャパターンを比較検討し、最終的に拡張性と運用効率を両立できる最適な構成を選定しました。また、AWS CDK を活用した IaC 化により開発効率を向上させ、環境の再現性を容易にしました。さらに IDE の支援機能やバージョン管理システムとの連携により、複数の開発者が安心してインフラの変更を行える体制を構築しています。 導入効果 AWSのマネージドサービスを活用した新アーキテクチャの導入により、以下の効果が得られました： AWS のマネージドサービスを活用することで、わずか 2 か月という短期間で新サービスをリリースし、開発チームがインフラ構築ではなくビジネスロジックの実装に集中できる環境を実現 サーバー管理やスケーリング、リソース最適化といったメンテナンス作業が不要となり、AWS Fargate の自動スケーリング機能によるトラフィック変動への自動対応により、従来比で運用負荷を70%軽減 AWS CDK による IaC 化と GitHub Actions への移行により、環境構築・更新にかかる時間を最大 90%削減し、手離れの良い運用と新機能開発のスピードアップを達成 モダンなアーキテクチャの採用と属人化の解消により、将来の機能拡張や他のプラットフォーム対応への基盤を構築し、Amazon Bedrock を活用した生成 AI 機能によりデータ分析サービスに新たな価値を提供 お客様の声 AWS Fargate と AWS CDK の組み合わせにより、従来の EC2 ベースの環境では考えられなかった開発・運用の効率化を実現できました。特に、サーバー管理から解放されたことで、開発チームがプロダクトの価値向上に集中できるようになったことが最大の成果です。また、AWS CDK による IaC 化により、環境の再現性が格段に向上し、複数の開発者が安心してインフラの変更を行えるようになりました。TikTok Shop という新しい市場への迅速な対応が求められる中で、AWS のマネージドサービスの力を借りて短期間でのサービス立ち上げを実現できたことは、ビジネスの競争力向上に大きく貢献しています。 まとめ 本事例は、従来の EC2 ベースの環境から AWS のマネージドサービスを活用したモダンなアーキテクチャへの移行により、開発速度と運用効率を大幅に向上させた優れた事例です。AWS Fargate、AWS CDK などのサービスを組み合わせることで、短期間でのサービス開発と大幅な運用工数削減を同時に実現しました。特に注目すべきは、単なる技術的な改善だけでなく、急速に変化する市場への迅速な対応を可能にし、ビジネスの競争力向上に直接貢献している点です。また、将来的な環境刷新への布石としても機能しており、持続可能な成長基盤の構築に成功しています。コンテナ化や IaC を活用したモダンなアーキテクチャの導入、AWS が提供する様々なマネージドサービスの活用にご興味をお持ちの方は、お気軽にお問い合わせください。 株式会社 Nint（左から）： 姚 舒威様 河野 康裕様 真鍋 颯一朗様 矢後 志明様 横沢 裕大様 &nbsp; Amazon Web Services Japan : アカウントマネージャー 新井 豪（左端） ソリューションアーキテクト 森 瞭輔（右端） ソリューションアーキテクト 森

2025 年 11 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon Elastic VMware Service の概要 Amazon EVS は、オンプレミスの VMware ワークロードを AWS へ移行、モダナイゼーションする選択肢の1つで、リロケートに位置づけられているサービスです。本セミナーでは、Amazon EVS の特徴、技術的な概要についてご説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 オンプレミスの VMware 環境から AWS へ移行を検討している方 ダウンタイム最小化や IP アドレス維持など、移行における課題を抱えている方 既存の VMware スキルやノウハウを活用しつつクラウドのメリットを得たい方 本 BlackBelt で学習できること Amazon EVS の概要 Amazon EVS のビルディングブロック Amazon EVS の展開前の準備 Amazon EVS の料金 スピーカー 増田　雄紀 ソリューションアーキテクト 今更聞けない Amazon EC2 インスタンスの選択肢 Amazon EC2 インスタンスの新しい EC2 インスタンスの情報や、CPU、GPU の選択肢についてと、インスタンス選択で大切なことをお話しします。(2025 年 11 月時点の内容です) 資料（ PDF ） | 動画（ YouTube ） 対象者 EC2 インスタンスを選ぶとき、いつも同じインスタンスタイプを選んでいる方 オンプレミスからの移行でサイジングに悩んでいる方 最近の新しいインスタンスの特性をキャッチアップしたい方 本 BlackBelt で学習できること Flex、Fractional GPU インスタンスを含めた Amazon EC2 インスタンス選択の最新情報や、パフォーマンス分析やキャパシティ戦略など EC2 インスタンス選択で大切なことを学習できます。 スピーカー 寺部 祐菜 ソリューションアーキテクト AWS Security Hub CSPM AWS Security Hub CSPM AWS が提供する CSPM サービスである AWS Security Hub CSPM の概要と機能、活用法についてご紹介しています 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS Security Hub CSPM の利用を考えている方 AWS Security Hub CSPM がどのようなサービスか知りたい方 AWS Security Hub CSPM の各機能や運用方法について知りたい方 本 BlackBelt で学習できること AWS Security Hub CSPM の概要と各種機能について理解する AWS Security Hub CSPM の一般的な運用のプラクティスについて知る スピーカー 喜多 望 ソリューションアーキテクト Amazon Connect Salesforce 連携 (CTI Adapter で実現する CRM 連携のご紹介 ) Amazon Connect と Salesforce の連携を実現する Amazon Connect Salesforce CTI Adapter について、機能と活用方法をご紹介します。本コンテンツでは、CTI Adapter の基本機能から具体的なユースケース、さらには Lambda Package を活用した機能拡張まで、導入ポイントを解説します。 資料（ PDF ） 対象者 Amazon Connect ご利用中のエンドユーザー/パートナーの方 これから Amazon Connect のご利用を検討されている方 コンタクトセンターにおける CTI 連携にご関心をお持ちの方 Amazon Connect と Salesforce の CTI 連携を実現しようとされている方 本 BlackBelt で学習できること Amazon Connect Salesforce CTI Adapter と Lambda Package の実践的な活用方法を学んでいただけます。CTI 連携による顧客情報の一元管理、効率的なコールハンドリングの実現方法など、実務に直結する知識を習得できます。また、実装時の設定のポイントもご紹介します。 スピーカー 梅田 裕義 シニア Connect スペシャリストソリューションアーキテクト &nbsp;

本記事は自治体向けシステムを展開する株式会社アイネスの運用本部管理部 田中翔氏、根岸亮太氏から寄稿いただいたものです。 背景 株式会社アイネスでは、自治体様の多岐にわたる業務を網羅する、豊富なラインナップを揃えた基幹業務パッケージシステム「WebRings」を全国の自治体様に提供しています。 自治体システムのガバメントクラウド移行を進める中で、私たちクラウド保守グループは 100 を超える膨大な数のアカウントを管理する必要性に迫られました。 しかし、アラームを人手で確認・調査する従来の仕組みでは、1 件あたりの対応に時間を要し、かつ経験者でないと調査が難しいため、これほど多くのアカウントを運用していくための人的リソースが非常に不足していました。 さらに、これらのシステムは同一のパッケージ及び、クラウド構成となっており、 アプリケーションの潜在的なバグやインフラ設定の不備により、複数の環境で同時に問題が起こる可能性が高いというリスクを抱えていました。 そのため、障害発生時に必要となる対応要員数が膨大になることが予測され、安定的な運用を維持することが困難でした。 これらの課題を根本的に解消し、限られたリソースで高品質な運用を維持するためには、運用の効率化が不可欠であり、生成 AI の活用を検討することとしました。 構築：Amazon Bedrock Agents を活用した AI エージェントの実装による障害分析 課題解決のため、私たちは AWS が公開していた「 FA2（Failure Analysis Assistant） 」を参考に、独自の障害原因自動分析機能「FA3（Failure Analysis Assistant Agent）」を実装しました。これは、エージェント版 FA2 を意味する社内での呼称です。 私たちは以前からガバメントクラウド上の環境を集約して管理する「共通運用アカウント」を構築・運用していました。FA3 は、この共通運用アカウントに集約されるデータを活用することで、効率的に障害分析を行える仕組みとしています。 FA3 の実装には Amazon Bedrock Agents を採用しました。これにより、複雑な実装は不要となり、プロンプトの調整などによるメンテナンスの容易さを確保しました。 さらに、マルチエージェント機能を利用することで、分析精度の向上、コスト削減、そして将来的な機能拡張性を実現しました。 エージェント構成 FA3 は、分析全体を統括する「分析エージェント」と、特定の情報収集を担当する複数の「収集エージェント」で構成されています。 分析エージェントは、障害の状況に応じて必要な調査タスクを自律的に計画し、配下の収集エージェント（Configuration, Log, Metrics）へ指示を行います。その後、各エージェントから返却された情報を分析し、障害の根本原因を特定します。 収集エージェントは、以下のとおり役割ごとに Action を定義し、 AWS Lambda と連携させています。 ConfigurationAgent（サービスの詳細情報収集） /describe_service 指定された AWS リソース（ Amazon Elastic Compute Cloud（Amazon EC2） 、 Amazon Relational Database Service（Amazon RDS） 等）の詳細情報を収集します。 LogAgent（ログ情報収集） /describe_service 指定された AWS リソース（ロググループ）の詳細情報を収集します。 /get_logsqueryresult CloudWatch Logs Insights クエリを実行し、そのクエリ結果を収集します。 /get_athenaqueryresult Amazon Athena でクエリを実行し、そのクエリ結果を収集します。 MetricsAgent（メトリクス情報収集） /list_metrics 指定された名前空間やメトリクス名から取得可能な Amazon CloudWatch メトリクスの一覧を特定します。 /get_metric_data 開始・終了時間やクエリを指定し、実際のメトリクスデータを収集します。 また、あらかじめ環境構成やログの格納方法といったアカウント毎の情報を Amazon DynamoDB に登録しておくことで、運用担当者の操作を不要としました。CloudWatch アラームから送られてくる JSON 形式のアラームデータのみをインプットとして、FA3 が自動で障害分析を実行します。分析が完了すると、その結果はメールで関係者に通知されます。 これにより、運用担当者はアラーム発生と同時にそのアラームに対する分析結果を受け取れるようになりました。 ガバメントクラウド外の生成 AI を利用する仕組み 本ソリューションは、ガバメントクラウド環境から事業者側で用意した AWS アカウントの Amazon Bedrock を利用する構成となっています。 ガバメントクラウド環境では国内に通信が完結する LLM の利用が認められています。同様のセキュリティ水準を遵守することを前提に、事業者側で用意したガバメントクラウド外の AWS アカウントで生成 AI サービスを利用することとし、以下のようなアーキテクチャを採用しました。 セキュリティ設定 生成 AI（FA3）専用のアカウント（FA3 アカウント）には、デジタル庁から提供される必須適用テンプレートをコピーし、ガバメントクラウド環境と同等のセキュリティレベルを確保しました。 データ分離 FA3 アカウントには、実際に通知されたアラームのデータのみを配置する構成とし、リソースを参照するための Role や Lambda はすべてガバメントクラウド環境の「共通運用アカウント」に設定することで、明確にデータと権限を分離しました。 本ソリューションによる障害分析の流れ FA3 によるアラーム発生から分析結果通知までの障害分析の処理の流れは以下の通りです。 アラーム発生 自治体アカウントで発生した障害を検知し、CloudWatch アラームを発報します。 FA3 へアラームを連携 共通運用アカウントにてアラームを処理し、FA3 アカウントの Amazon Simple Queue Service（Amazon SQS） へ通知を行います。Amazon SQS は Amazon Bedrock Agents 呼び出し用の Lambda をトリガーします。 プロンプト生成 呼び出された Lambda が、DynamoDB から該当アカウントの情報を取得し、受け取ったアラーム情報と組み合わせて、Amazon Bedrock Agents へのプロンプトを生成します。 障害調査 プロンプトを受け取った分析エージェントが、障害内容に合わせて必要な情報の取得を収集エージェント群に指示します。 各収集エージェントがそれぞれの担当領域（メトリクス、ログ、サービス情報など）の調査・情報収集を行います。分析エージェントは、収集エージェントから集約したデータを基に、障害の根本原因を分析します。 情報収集は以下のアーキテクチャにて実装しています。 収集エージェントは、アクションとして定義された Lambda を実行します。 実行された Lambda は、共通運用アカウントに保管されているデータが必要な場合、共通運用アカウントへ AssumeRole を行い情報を収集します。 自治体アカウント内の情報（サービスの状態など）が必要な場合は、共通運用アカウントの Lambda を同期的に呼び出し、その Lambda が自治体アカウントへ AssumeRole を行い情報を収集します。 ※処理の長時間化や複雑化が発生した場合には、リトライ処理や分岐などの管理を容易にするため AWS Step Functions を検討 結果通知 分析した結果をメールにて運用担当者へ通知します。 AIの思考過程の記録 分析時に AI がどのような思考で調査を行ったのか、そのプロセスを DynamoDB に記録します。これにより、分析内容の妥当性を確認することが可能です。 検証結果 エージェント（FA3）の導入効果を検証するため、エンジニアによる調査結果と FA3 が報告した障害原因を照合し、その的中率を測定しました。 検証の結果、以下の通り全体で約9割、特にクラウド設定に関しては 100 %という高い信頼性が確認されました。 被疑箇所 アラームサンプル数 的中数 的中率 クラウド設定 27 27 100% OS内 56 47 83.90% 全体 83 74 89.20% 実現効果 アラーム確認のオペレーションを「FA3 の報告を確認し、その妥当性を判断する」というフローへ変更した結果、多数のアラーム調査が 10 分未満で完了するようになっています。 従来、事象推定からデータ確認までの初動調査には 1～2 時間を要していたため、調査時間は約 10 分の 1 にまで短縮されました。 事象の特定が困難である OS 内が起因のアラームであっても、被疑箇所の絞り込みを FA3 が行ってくれるため、初動調査に要する時間は短縮されました。 対応フロー 平均初動調査時間 従来 105分 FA3活用（クラウド設定起因） 7.5分 FA3活用（OS内起因） 15分 また、障害調査には AWS や業務システムに関する知見と経験を要するため、対応できるエンジニアが限られてしまうという課題がありましたが、FA3 が調査の大部分をサポートしてくれることで、経験の浅いエンジニアでも迅速かつ的確な対応が可能となりました。これにより、当初の課題であった人的リソースの不足が解消し、安定的な運用を維持することができるようになりました。 Why AWS？ 私たちクラウド保守グループは、AWS のシステム運用を強みとしており、今回のガバメントクラウド移行 におけるシステム構築でも AWS を利用してきました。そのため、AWS の生成 AI サービスである Amazon Bedrock を利用することは、既存環境との親和性、シームレスな連携、そして私たちが持つノウハウを最大限に活かす上で、最適な選択でした。 また、今回参考にした「FA2」が AWS 環境での実行を前提としていたことも、Amazon Bedrock を採用する後押しとなりました。 コスト 生成 AI へのリクエスト費用は、1回あたり 75 円程度です。 マルチエージェントではエージェント毎にモデルを設定できますので、例えば、高度な分析を行う「分析エージェント」には高性能なモデルを使用し、比較的単純な情報収集を行う「収集エージェント」には低コストなモデルを使用する、といった柔軟な選択肢も可能です。 以下の対策を組み合わせることで、コストの最適化も可能です。 分析対象の絞り込み： ディスク使用率低下など、AI 分析の効果が薄いアラームを除外する。 入力トークンの最適化： 調査対象とするメトリクスを厳選することや、取得データを加工してから AI に渡すことで、AI への入力データ量を抑制する。 今後の構想 FA3 のさらなる進化に向けて、以下の構想を描いています。 分析精度の向上 AWS X-Ray の情報や、AWS の障害情報といった、より多様な情報ソースを収集・分析対象に加えることで、原因分析の精度をさらに高めていきます。 対話型インターフェースの実装 現在は分析結果を一方的にメールで通知する形式ですが、受けた通知を元に AI と対話しながら現在のシステムの状態をより深く探れるような機能を、 Kiro や Amazon Q Developer といったサービスも活用しながら実装することを目指します。 複数アカウントにまたがる分析 同一パッケージシステムを利用している環境では、あるアカウントで発生した障害が他アカウントでも発生するリスクが高いです。そのため、単一アカウントの分析にとどまらず、特定した障害原因が他アカウントにも潜在していないかを横断的に分析できる機能を実装し、障害の未然防止につなげます。 著者について 田中 翔（たなか かける） データセンターのオンプレミス・プライベートクラウドからパブリッククラウドにフィールドを移しながらインフラ構築と運用監視をメイン領域として担当。最近ではパブリッククラウド向け MSP ビジネスの推進やガバメントクラウド保守チームのマネジメントを行っています。（写真右） 根岸 亮太（ねぎし りょうた） 以前はシステムの運用作業を主に担当しておりましたが、オンプレミスから AWS への移行プロジェクトを機に、現在は AWS を中心としたインフラエンジニアとして活動しております。最近ではガバメントクラウド環境の構築・管理、および AI 活用の推進に携わっております。（写真左）

米国ラスベガスで2025年12月1日-5日に開催された AWS re:Invent 2025 では、デジタル庁様がユーザー事例ブレイクアウトセッションに登壇されました。 デジタル庁様の大規模かつ効率的な統制のあり方を説明したこのセッションの内容は日本の一般企業のガバナンスにも参考になるものと思います。 このブログでは日本のお客様向けに日本語でセッションの内容をご紹介します。英語ではありますが YouTubeに上がっているセッション動画 もぜひご覧ください。 セッション概要 タイトル： [COP349] Balancing Agility &amp; Compliance feat. The Digital Agency of Japan（俊敏性とコンプライアンスのバランス – 日本のデジタル庁を迎えて） セッション概要： 規制業界は、クラウドにおける厳格なセキュリティとコンプライアンス要件に対応しながら、俊敏性を持ってイノベーションを推進するという課題に直面しています。このセッションでは、日本政府が各省庁と1,700以上の地方公共団体にわたってクラウド導入のための集約型ガバナンスモデルを成功裏に実装し、5,000以上のアカウントをシームレスに管理できるようにした事例を学びます。AWS Control Tower、AWS Config、AWS Security Hubなどの AWS クラウドガバナンスサービスにより、規制業界や公共部門は運用を合理化し、ガバナンスを強化し、進化するコンプライアンス要件を満たして、中央制御と地方の自律性のバランスを取ることができます。 登壇者： デジタル庁, Chief Cloud Officer 山本 教仁 様 AWS, World Wide Cloud Governance Principal Specialist Nivas Durairaj AWS Japan, Manager, Specialist Solutions Architect 大村 幸敬 AWSガバナンスのベストプラクティス 最初に AWS Cloud Governance Specialistの Nivas よりAWSにおけるガバナンスのベストプラクティスについて解説しました。 公共部門、ヘルスケア、金融業界といった機微な情報を扱う規制業種では、俊敏性とコンプライアンスという大きく２つのニーズがあります。俊敏性では、生成AIのようなイノベーションの活用、そして変化に追従して迅速に成果を出すことが求められます。コンプライアンスでは、セキュリティルールへの適合、および中央の管理者が統制しつつも多数の利用者（開発者）がスケーラブルに利用できることが求められます。 これを開発者と中央の管理者という観点で言い換えてみます。開発者は技術的な意思決定を自由に行って実験を繰り返せる環境を使って、イノベーションと迅速なリリースを実現したいと思っています。一方で中央管理者は運用効率化のために環境の標準化を求め、組織全体にわたってセキュリティとコンプライアンス統制の可視化を実現したいと思っています。 ここに、俊敏性とコンプライアンスという反対方向に働く緊張が発生することになります。この２つをAWS上ではどのようなバランスで実現するのか、というのがこのセッションのキーポイントです。 AWSではクラウドガバナンスを「組織がベストプラクティスに準拠するよう導く、ルール、プロセス、およびレポートの集合」と定義しています。 詳細はQRコードに示した、 AWSのウェブサイトをご覧ください 。 ベストプラクティスとしては、環境に関するベストプラクティス、コントロール（統制）に関するベストプラクティスの２つがあります。 環境のベストプラクティスはこの４つです。（詳細はセッション資料を参照してください） システムごとにアカウントを使用する（マルチアカウント管理を行う） アカウントの作成とカスタマイズを自動化する すべてのアカウントの活動を記録する 強力なID管理基盤を実装する コントロール（統制）のベストプラクティスは次の3つです。（詳細はセッション資料を参照してください） コントロール（統制）の目的をセキュリティフレームワークに適合させる 予防的統制の前に発見的統制を適用する コントロールを継続的に監視しテストする これらはベストプラクティスではありますが、規制業種の実際のシステムに適用することを考えた場合、多くの実装上の課題に直面することになります。ガバナンスの観点では、法律への適合方法、巨大な組織でもスケールする実装。俊敏性の観点では、アカウント作成とカスタマイズを誰が行うのか、利用者の認証方法、セキュアな基本設定を広く組織全体に展開する方法などです。 これらを実現した事例として、日本のデジタル庁によるガバメントクラウドを紹介します。 デジタル庁ガバメントクラウドの取り組み ここから、デジタル庁 CCO 山本様に、ガバメントクラウドでの取り組みを紹介していただきました。 まずは、こちらのデジタル庁様の紹介動画をご覧ください。 日本のデジタル庁は2021年に発足。コロナ禍の最中でした。コロナ禍ではワクチン接種の記録やワクチンの所在を短期間で確認することは当初困難でした。政府と社会のこういった課題をデジタルの力で解決することを目的としてデジタル庁が設立されました。以後４年間にわたってマイナンバーカードなどの施策を実現しています。ガバメントクラウドはこれらの施策の基盤となるものです。 ガバメントクラウドでは中央省庁だけでなく、地方公共団体や準公共領域の団体のシステムも稼働しており、急速に利用が増えています。2025年9月の時点で6,085アカウントが稼働しており、2025年は1ヶ月平均で370アカウントが増えています。 こういった急速なアカウント増加に対応するため、アカウントの追加や利用者のID追加作業の自動化は必須です。自動化以前では利用者の追加にかかるリードタイムは５営業日でしたが、現在は翌日までの追加が可能になっています。また利用者を１名追加することにかかるデジタル庁管理者の作業は30分から1時間であり、１ヶ月あたり370アカウントの追加であれば259時間を要する計算でした。しかし自動化によってこの作業量は現在ゼロを実現しています。 ガバナンス実現の文脈で、ガバメントクラウドがプラットフォームとして重要視すべき要素は3つあります。一つはもちろんガバナンスですが、日本の地方公共団体における固有の考慮として、地方の独立性（Local autonomy）があります。ガバナンスを実現するためには管理者であるデジタル庁が個々の環境を管理できたほうが効率的ですが、地方の独立性を重視する立場からは、デジタル庁が個々の環境を直接操作することはできません。さらに多数の自治体がガバメントクラウドを利用する場合でも、デジタル庁がそのボトルネックとなることなく俊敏性を提供するためには、スケーラビリティが必要となります。 この「ガバナンス」と「地方の独立性」そして「俊敏性とスケーラビリティ」の3つをバランスすることが、ガバメントクラウドにとって重要となります。 ガバメントクラウドの全体像がこちらです。ガバメントクラウドでは複数のクラウドサービスプロバイダー（CSP）を利用しており、利用者は個々のクラウド環境を直接利用することができます。提供するクラウド環境を払い出す機能や監査ログの記録やダッシュボードといった管理機能はユーザのクラウド環境の外側にあって、クラウド環境利用を阻害しないような構成となっています。これによって利用者はCSPが持つテクノロジをそのまま利用できるようにしています。このアーキテクチャは俊敏性とスケーラビリティを実現することに役立っています。 ガバナンスの実現にあたっては、法制面と技術面の両方から対応しています。法制面では日本法の下での日本政府と CSP との直接契約、データが日本に所在すること、そしてこれが適切に運営されていることを監査と ISMAP 認定で確認しています。技術面では利用者登録時にマイナンバーカードによる認証を行った上で、利用時は MFA で認証します。データは FIPS 140 認定の HSM （ハードウェアセキュリティモジュール）に格納された暗号キーで暗号化することができ、正しく認証したユーザのみが利用可能で、デジタル庁の管理者やCSPも含め外部からアクセスした場合でも読み取ることはできません。このようにして強固なガバナンスを実現していますが、同時に利用者の作成作業などは完全に自動化されており、俊敏性とスケーラビリティの両方を実現しています。 先に示したデータのガバナンスによって地方の環境の独立性も実現されることになります。すなわちデジタル庁の管理者であっても個々の自治体が持つAWSアカウントのデータにアクセスことはできません。さらに個々のアカウントに対してデジタル庁管理者が直接操作を行うことはなく、アカウントの作成や設定は全て自動化されています。またこの操作も毎年の監査を受けています。 アジリティとスケーラビリティ実現はここまでも述べてきましたが、さらに実際の環境における情報をガバメントクラウドとして管理しつつ、全てを自動化するための仕組みを導入しています。これは後ほど技術詳細と共に再度ご説明します。 ガバメントクラウドではマルチクラウド戦略をとっていますが、これは次の３つの戦略に基づいています。（詳細はセッション動画をご覧ください） 1つのシステムは1つの CSP で動作させる（複数のCSPを跨がない） 複数のクラウドを統合的に管理するシステムは使用しない データとプログラムの移行可能性を考慮する（ポータビリティの高いコンテナを採用するなど） 山本さんから最後にガバメントクラウドにおける AI の活用について説明がありました。日本は AI を活用し、ガバメント AI を準備するというポリシーを掲げています。デジタル庁の AI クラウド環境はその基礎となる予定とのことです。 デジタル庁でのベストプラクティス実現方法 最後のパートでは、ガバメントクラウドの実装をサポートした、AWS Japan のソリューションアーキテクト マネージャー 大村から技術的な実装の詳細について解説しました。冒頭 Nivas が提示したベストプラクティスからガバメントクラウド実装のキーとなった４つを取り上げました。 １つ目に取り上げるベストプラクティスは「コントロール（統制）の目的をセキュリティフレームワークに適合させる」です。 デジタル庁ではプリンシプル・ベース・アプローチ（原則主義アプローチ）により、法律から規制、そしてガイドラインへと抽象度の高い要求を徐々に具体化しています。これらのガイドラインをNIST CSFやNIST SP800-53といったフレームワークやコントロールカタログを参照して具体的な管理策にマッピングすることで、実装に落とし込めるようにしています。 さらに、ガバメントクラウドでは、これらのコントロールを実現するにあたり「運用効率を損なうことなく、適切なセキュリティ対策を実現する」という目的を掲げています。そのため、予防的統制は最小限とし、主に発見的統制を使ったガバナンスを実装する方針としています。予防的統制の実装には AWS Organizations の Service Control Policy を使用して特定の操作そのものをできないようにしています。発見的統制の実装には AWS Security Hub CSPM を使用して、操作自体を制限するのではなく、設定内容に統制からの逸脱がある場合、迅速に検出できるようにしています。これは AWS Config が構成情報を記録していることで実現できています。Security Hub CSPM には CIS ベンチマークや、 AWS Foundational Security Best Practice といったスタンダードがすでに用意されており、これらは NIST SP800-53 等のフレームワークとマッピングされています。これによって発見的統制の実装が容易になっています。 ２つ目に取り上げるベストプラクティスは「強力な ID 管理基盤を実装する」です。 ガバメントクラウドでは数千もの利用者やアカウントを管理する必要があり、高いセキュリティを維持しつつスケーラブルに運用するためには、強力な認証基盤とその自動化が重要です。山本さんが紹介されたように、利用者登録の際の認証はマイナンバーカードで自動化しています。これにより当初手動で5日間かかっていたリードタイムを翌日（１日）へと劇的に短縮しました。さらに IAM Identity Center (IIC) では利用するゲストアカウントにアクセスするための権限を Permission Set で設定しますが、個々の利用者、アカウントごとにこれを作成すると設定の管理対象が膨大になり、サービスクォータ（上限）に抵触する可能性もあります。そこで、管理者と非管理者という２つの Permission Set だけを使うシンプルな実装を行っています。管理者権限は IAM ロールの作成が可能で（予防的統制により IAM ユーザの作成は禁止しています）、非管理者権限はロールの切り替えのみが可能である、という仕組みです。これにより利用者が個々のアカウントで必要なロールを作りつつも、IIC の Permission Set 数が爆発的に増えることのない仕組みを実現しています。 ３つ目に取り上げるベストプラクティスは「アカウントの作成とカスタマイズを自動化する」です。 まず初回のみのアカウント設定について説明します。 利用者がAWSアカウントを作成したい場合は GCAS (Government Cloud Assistant Service) というデジタル庁が開発したポータルからリクエストします。アカウント作成自体は AWS Control Tower が行い、アカウントの並列作成をサービス上限以下にコントロールするための Amazon SQS 、そして初期設定手続きを定義する AWS Lambda 関数を、AWS Step Functions ワークフローで繋ぐ形で実現しています。Control Tower には Account Factory Customization という AWS Cloud Formation を使ったアカウント初期設定の仕組みがあります。Cloud Formationのような Infrastructure as Code は「あるべき状態（設定）」を定義するのに適しています。しかしガバメントクラウドで行う初期設定作業には、エンタープライズサポートへの登録などAPIしか利用できない操作も多く、そのような「手続き」を定義するには Lambda 関数の方が適しています。さらに、アカウント作成では自治体名や支払い用メールアドレスといった、AWS の設定とは関係のない実世界の情報も管理する必要があります。これらは GCAS 上のデータベースに登録し、ここでも手動での管理を排除しています。このようにアカウント作成時の初回設定を完全に自動化しています。 利用者のアカウントにはセキュリティの基本設定である「セキュアベースライン」を展開します。これは展開後も継続してメンテナンスする必要があるため「あるべき状態」を定義する Infrastructure as Code が適しています。ガバメントクラウドでは CDK を使用してセキュアベースラインを定義しています。このデプロイは、AWS Service Catalog を使った「Pull（引っ張る）スタイル」でおこないます。これはデプロイ対象であるセキュアベースラインをデジタル庁管理者が Service Catalog の Product として作成し、デプロイは地方公共団体の管理者が自ら（引っ張ってきて）行うやり方です。Pullスタイルの対義語は「Push（押す）スタイル」ですが、これは Cloud Formation StackSet のような、中央の管理者が全ての環境にデプロイするやり方を指します。ガバメントクラウドで Pull スタイルを採用した理由は、一つは管理の独立性の考えに基づき、デジタル庁管理者が地方公共団体などのアカウントにアクセスしないようにする必要があったことです。もうひとつの理由は、Push スタイルの場合、セキュアベースラインをアップデートする際にデジタル庁管理者が地方公共団体管理者と実施タイミングや設定内容を調整する必要があり、デジタル庁管理者の運用がスケールしないためです。Pull スタイルであることで、デジタル庁管理者は Service Catalog の Product を更新するだけでよく、地方公共団体管理者は自らの都合のよいタイミングで、自らの環境の状態を理解した上で、更新を実施することができます。これもまたスケーラブルなセキュアベースライン実現のために必要な仕組みです。 最後に取り上げるベストプラクティスは「コントロールを継続的に監視しテストする」です。 ガバメントクラウドでは、地方公共団体のアカウントで発生したセキュリティイベントは直接地方公共団体の管理者へ通知され、管理者が自ら修正する責務があります。これはセキュアベースラインに設定された Amazon EventBridge と AWS Chatbot によって実現しています。これもデジタル庁管理者を介することなく対応する仕組みによって、管理の独立性とスケーラビリティを実現しています。一方でデジタル庁管理者は多数のアカウント全体の統制について、その統制の状況を把握する必要があります。これは AWS Security Hub CSPM のレポートによって実現しており、少数の、特に注意が必要なセキュリティイベントについては、デジタル庁管理者が定期的にチェックを行い、必要に応じて改善提案を行っています。このようにして、多数のアカウントを対象にしていてもセキュリティイベントが適切に対応される仕組みを実現しています。 まとめ このセッションでは、日本の中央省庁や地方公共団体という現実の世界のシステムを管理する上で、ガバメントクラウドがガバナンスと俊敏性を両立させるためにどのように考え、実装しているのかを紹介しました。また、それがAWSのベストプラクティスにも適合していることをご紹介しました。 会場には日本の方も多くご参加いただき、登壇後に質疑応答もいただきました。ご来場いただきありがとうございました！ 著者：大村幸敬 (AWS Japan, Manager, Solutions Architect)

本記事は 2025 年 12 月 16 日 に公開された「 Unlocking video understanding with TwelveLabs Marengo on Amazon Bedrock 」を翻訳したものです。 メディア・エンターテインメント、広告、教育、企業研修などのコンテンツは、視覚、音声、動きの要素を組み合わせてストーリーを伝え、情報を届けます。個々の単語に明確な意味があるテキストと比べて、はるかに複雑です。このため、動画コンテンツを理解する必要がある AI システムには独自の課題が生じます。動画コンテンツは多次元的であり、視覚要素 (シーン、オブジェクト、アクション)、時間的ダイナミクス (動き、トランジション)、音声コンポーネント (会話、音楽、効果音)、テキストオーバーレイ (字幕、キャプション) を組み合わせています。この複雑さは、組織が動画アーカイブを検索したり、特定のシーンを見つけたり、コンテンツを自動的に分類したり、効果的な意思決定のためにメディア資産からインサイトを抽出したりする際に、大きなビジネス上の課題を生み出します。 このモデルは、異なるコンテンツモダリティに対して個別の埋め込みを作成するマルチベクトルアーキテクチャでこの問題に対処します。すべての情報を 1 つのベクトルに圧縮するのではなく、モデルは特化した表現を生成します。このアプローチにより、動画データの豊かで多面的な性質が保持され、視覚、時間、音声の各次元にわたってより正確な分析が可能になります。 Amazon Bedrock は、同期推論によるリアルタイムのテキストおよび画像処理で TwelveLabs Marengo Embed 3.0 モデルをサポートするように機能を拡張しました。この統合により、企業は自然言語クエリを使用したより高速な動画検索機能を実装できるようになり、高度な画像類似性マッチングによるインタラクティブな製品発見もサポートします。 この記事では、 Amazon Bedrock で利用可能な TwelveLabs Marengo 埋め込みモデルが、マルチモーダル AI を通じて動画理解をどのように強化するかを紹介します。Marengo モデルからの埋め込みと、ベクトルデータベースとしての Amazon OpenSearch Serverless を使用して、動画のセマンティック検索および分析ソリューションを構築します。これにより、単純なメタデータマッチングを超えたセマンティック検索機能でインテリジェントなコンテンツ発見を実現します。 動画埋め込みの理解 埋め込みは、高次元空間でデータの意味的な意味を捉える密なベクトル表現です。これは、機械が理解し比較できる方法でコンテンツの本質をエンコードする数値的な指紋と考えることができます。テキストの場合、埋め込みは「king」と「queen」が関連する概念であること、または「Paris」と「France」に地理的な関係があることを捉えることができます。画像の場合、埋め込みは見た目が異なっていても、 ゴールデンレトリバー と ラブラドール がどちらも犬であることを理解できます。以下のヒートマップは、「two people having a conversation」、「a man and a woman talking」、「cats and dogs are lovely animals」という文章フラグメント間の意味的類似度スコアを示しています。 動画埋め込みの課題 動画は本質的にマルチモーダルであるため、独自の課題があります: 視覚情報 : オブジェクト、シーン、人物、アクション、視覚的な美しさ 音声情報 : 音声、音楽、効果音、環境音 テキスト情報 : キャプション、画面上のテキスト、音声から書き起こされたテキスト 従来の単一ベクトルアプローチでは、この豊富な情報をすべて 1 つの表現に圧縮するため、重要なニュアンスが失われることがよくあります。ここで TwelveLabs Marengo のアプローチがこの課題に効果的に対処する点でユニークです。 Twelvelabs Marengo: マルチモーダル埋め込みモデル Marengo 3.0 モデルは、動画コンテンツのさまざまな側面を捉える複数の特化したベクトルを生成します。典型的な映画やテレビ番組は、視覚要素と聴覚要素を組み合わせて統一されたストーリーテリング体験を作り出します。Marengo のマルチベクトルアーキテクチャは、この複雑な動画コンテンツを理解するために大きな利点を提供します。各ベクトルは特定のモダリティを捉え、多様なデータタイプを単一の表現に圧縮することによる情報損失を回避します。これにより、視覚のみ、音声のみ、または組み合わせたクエリなど、特定のコンテンツの側面をターゲットにした柔軟な検索が可能になります。特化したベクトルは、複雑なマルチモーダルシナリオで優れた精度を提供しながら、大規模なエンタープライズ動画データセットに対する効率的なスケーラビリティを維持します。 ソリューション概要: Marengo モデルの機能 以下のセクションでは、コードサンプルを通じて Marengo の埋め込み技術の威力を実演します。これらの例は、Marengo がさまざまなタイプのコンテンツをどのように処理し、優れた検索精度を提供するかを示しています。完全なコードサンプルは、この GitHub リポジトリ にあります。 前提条件 始める前に、以下を確認してください: 適切な権限を持つ AWS アカウント Amazon Bedrock へのアクセス OpenSearch Serverless コレクションとインデックスを作成するためのアクセス ベクトルデータベースと埋め込みに関する基本的な知識 サンプル動画 Netflix Open Content は、Creative Commons Attribution 4.0 International ライセンスの下で利用可能なオープンソースコンテンツです。Amazon Bedrock 上の TwelveLabs Marengo モデルのデモンストレーションには、 Meridian という動画を使用します。 動画埋め込みの作成 Amazon Bedrock は、Marengo 動画埋め込み生成に非同期 API を使用します。以下は、S3 バケットの場所から動画を取得する API を呼び出す例を示す Python コードスニペットです。サポートされている完全な機能については、 ドキュメント を参照してください。 bedrock_client = boto3.client("bedrock-runtime") model_id = 'us.twelvelabs.marengo-embed-3-0-v1:0' video_s3_uri = "&lt;s3 bucket location for the video&gt;" # Replace by your s3 URI aws_account_id = "&lt;the AWS account owner for the bucket&gt;" # Replace by bucket owner ID s3_bucket_name = "&lt;s3 bucket name&gt;" # Replace by output S3 bucket name s3_output_prefix = "&lt;output prefix&gt;" # Replace by output prefix response = bedrock_client.start_async_invoke( modelId=model_id, modelInput={ "inputType": "video", "video": { "mediaSource": { "s3Location": { "uri": video_s3_uri, "bucketOwner": aws_account_id } } } }, outputDataConfig={ "s3OutputDataConfig": { "s3Uri": f's3://{s3_bucket_name}/{s3_output_prefix}' } } ) 上記の例では、1 つの動画から 280 個の個別の埋め込みが生成されます。各セグメントに 1 つずつ生成され、正確な時間的検索と分析が可能になります。動画からのマルチベクトル出力の埋め込みタイプには、以下が含まれる可能性があります: [ {'embedding': [0.053192138671875,...], 'embeddingOption': "visual", 'embeddingScope' : "clip", "startSec" : 0.0, "endSec" : 4.3 }, {'embedding': [0.053192138645645,...], 'embeddingOption': "transcription", 'embeddingScope' : "clip", "startSec" : 3.9, "endSec" : 6.5 }, {'embedding': [0.3235554er443524,...], 'embeddingOption': "audio", 'embeddingScope' : "clip", "startSec" : 4.9, "endSec" : 7.5 } ] visual – 動画の視覚埋め込み transcription – 文字起こしされたテキストの埋め込み audio – 動画内の音声の埋め込み 音声または動画コンテンツを処理する際、埋め込み作成のために各クリップセグメントの長さを設定できます。デフォルトでは、動画クリップは自然なシーン変化 (ショット境界) で自動的に分割されます。音声クリップは、10 秒にできるだけ近い均等なセグメントに分割されます。例えば、50 秒の音声ファイルは 10 秒ずつの 5 セグメントになり、16 秒のファイルは 8 秒ずつの 2 セグメントになります。デフォルトでは、単一の Marengo 動画埋め込み API は visual-text、visual-image、audio 埋め込みを生成します。デフォルト設定を変更して、特定の埋め込みタイプのみを出力することもできます。Amazon Bedrock API で設定可能なオプションを使用して動画の埋め込みを生成するには、以下のコードスニペットを使用します: response = bedrock_client.start_async_invoke( modelId=model_id, modelInput={ "modelId": model_id, "modelInput": { "inputType": "video", "video": { "mediaSource": { "base64String": "base64-encoded string", // base64String OR s3Location, exactly one "s3Location": { "uri": "s3://amzn-s3-demo-bucket/video/clip.mp4", "bucketOwner": "123456789012" } }, "startSec": 0, "endSec": 6, "segmentation": { "method": "dynamic", // dynamic OR fixed, exactly one "dynamic": { "minDurationSec": 4 } "method": "fixed", "fixed": { "durationSec": 6 } }, "embeddingOption": [ "visual", "audio", "transcription" ], // optional, default=all "embeddingScope": [ "clip", "asset" ] // optional, one or both }, "inferenceId": "some inference id" } } ) ベクトルデータベース: Amazon OpenSearch Serverless この例では、Marengo モデルを介して指定された動画から生成されたテキスト、画像、音声、動画の埋め込みを保存するためのベクトルデータベースとして Amazon OpenSearch Serverless を使用します。ベクトルデータベースとして、OpenSearch Serverless を使用すると、サーバーやインフラストラクチャの管理を心配することなく、セマンティック検索を使用して類似のコンテンツをすばやく見つけることができます。以下のコードスニペットは、Amazon OpenSearch Serverless コレクションを作成する方法を示しています: aoss_client = boto3_session.client('opensearchserverless') try: collection = self.aoss_client.create_collection( name=collection_name, type='VECTORSEARCH' ) collection_id = collection['createCollectionDetail']['id'] collection_arn = collection['createCollectionDetail']['arn'] except self.aoss_client.exceptions.ConflictException: collection = self.aoss_client.batch_get_collection( names=[collection_name] )['collectionDetails'][0] pp.pprint(collection) collection_id = collection['id'] collection_arn = collection['arn'] OpenSearch Serverless コレクションが作成されたら、ベクトルフィールドを含むプロパティを持つインデックスを作成します: index_mapping = { "mappings": { "properties": { "video_id": {"type": "keyword"}, "segment_id": {"type": "integer"}, "start_time": {"type": "float"}, "end_time": {"type": "float"}, "embedding": { "type": "dense_vector", "dims": 1024, "index": True, "similarity": "cosine" }, "metadata": {"type": "object"} } } } credentials = boto3.Session().get_credentials() awsauth = AWSV4SignerAuth(credentials, region_name, 'aoss') oss_client = OpenSearch( hosts=[{'host': host, 'port': 443}], http_auth=self.awsauth, use_ssl=True, verify_certs=True, connection_class=RequestsHttpConnection, timeout=300 ) response = oss_client.indices.create(index=index_name, body=index_mapping) Marengo 埋め込みのインデックス作成 以下のコードスニペットは、Marengo モデルからの埋め込み出力を OpenSearch インデックスに取り込む方法を示しています: documents = [] for i, segment in enumerate(video_embeddings): document = { "embedding": segment["embedding"], "start_time": segment["startSec"], "end_time": segment["endSec"], "video_id": video_id, "segment_id": i, "embedding_option": segment.get("embeddingOption", "visual") } documents.append(document) # Bulk index documents bulk_data = [] for doc in documents: bulk_data.append({"index": {"_index": self.index_name}}) bulk_data.append(doc) # Convert to bulk format bulk_body = "\n".join(json.dumps(item) for item in bulk_data) + "\n" response = oss_client.bulk(body=bulk_body, index=self.index_name) クロスモーダルセマンティック検索 Marengo のマルチベクトル設計により、単一ベクトルモデルでは不可能な異なるモダリティ間での検索が可能になります。視覚、音声、動き、コンテキスト要素に対して個別だが整合性のある埋め込みを作成することで、選択した入力タイプを使用して動画を検索できます。例えば、「jazz music playing」というクエリは、1 つのテキストクエリからミュージシャンの演奏動画クリップ、ジャズの音声トラック、コンサートホールのシーンを返します。 以下の例は、さまざまなモダリティにわたる Marengo の優れた検索機能を示しています: テキスト検索 以下は、テキストを使用したクロスモーダルセマンティック検索機能を示すコードスニペットです: text_query = "a person smoking in a room" modelInput={ "inputType": "text", "text": { "inputText": text_query } } response = self.bedrock_client.invoke_model( modelId="us.twelvelabs.marengo-embed-3-0-v1:0", body=json.dumps(modelInput)) result = json.loads(response["body"].read()) query_embedding = result["data"][0]["embedding"] # Search OpenSearch index search_body = { "query": { "knn": { "embedding": { "vector": query_embedding, "k": top_k } } }, "size": top_k, "_source": ["start_time", "end_time", "video_id", "segment_id"] } response = opensearch_client.search(index=self.index_name, body=search_body) print(f"\n✅ Found {len(response['hits']['hits'])} matching segments:") results = [] for hit in response['hits']['hits']: result = { "score": hit["_score"], "video_id": hit["_source"]["video_id"], "segment_id": hit["_source"]["segment_id"], "start_time": hit["_source"]["start_time"], "end_time": hit["_source"]["end_time"] } results.append(result) テキストクエリ「a person smoking in a room」からの上位検索結果は、以下の動画クリップを返します: 画像検索 以下のコードスニペットは、指定された画像に対するクロスモーダルセマンティック検索機能を示しています: s3_image_uri = f's3://{self.s3_bucket_name}/{self.s3_images_path}/{image_path_basename}' s3_output_prefix = f'{self.s3_embeddings_path}/{self.s3_images_path}/{uuid.uuid4()}' modelInput={ "inputType": "image", "image": { "mediaSource": { "s3Location": { "uri": s3_image_uri, "bucketOwner": self.aws_account_id } } } } response = self.bedrock_client.invoke_model( modelId=self.cris_model_id, body=json.dumps(modelInput), ) result = json.loads(response["body"].read()) ... query_embedding = result["data"][0]["embedding"] # Search OpenSearch index search_body = { "query": { "knn": { "embedding": { "vector": query_embedding, "k": top_k } } }, "size": top_k, "_source": ["start_time", "end_time", "video_id", "segment_id"] } response = opensearch_client.search(index=self.index_name, body=search_body) print(f"\n✅ Found {len(response['hits']['hits'])} matching segments:") results = [] for hit in response['hits']['hits']: result = { "score": hit["_score"], "video_id": hit["_source"]["video_id"], "segment_id": hit["_source"]["segment_id"], "start_time": hit["_source"]["start_time"], "end_time": hit["_source"]["end_time"] } results.append(result) 上記の画像からの上位検索結果は、以下の動画クリップを返します: 動画に対するテキストと画像を使用したセマンティック検索に加えて、Marengo モデルは会話や音声に焦点を当てた音声埋め込みを使用して動画を検索することもできます。音声検索機能により、ユーザーは特定の話者、会話の内容、または話されているトピックに基づいて動画を見つけることができます。これにより、動画理解のためにテキスト、画像、音声を組み合わせた包括的な動画検索体験が実現します。 まとめ TwelveLabs Marengo と Amazon Bedrock の組み合わせは、マルチベクトル、マルチモーダルアプローチを通じて動画理解の新しい可能性を切り開きます。この記事では、時間的精度を持つ画像から動画への検索や、詳細なテキストから動画へのマッチングなどの実践的な例を探りました。たった 1 回の Bedrock API 呼び出しで、1 つの動画ファイルをテキスト、視覚、音声クエリに応答する 336 個の検索可能なセグメントに変換しました。これらの機能は、自然言語によるコンテンツ発見、効率化されたメディア資産管理、および組織が大規模に動画コンテンツをより良く理解し活用するのに役立つその他のアプリケーションの機会を生み出します。 動画がデジタル体験を支配し続ける中、Marengo のようなモデルは、よりインテリジェントな動画分析システムを構築するための堅固な基盤を提供します。 サンプルコード をチェックして、マルチモーダル動画理解がアプリケーションをどのように変革できるかを発見してください。 著者について Wei Teh は、AWS の機械学習ソリューションアーキテクトです。最先端の機械学習ソリューションを使用してお客様のビジネス目標達成を支援することに情熱を注いでいます。仕事以外では、家族とキャンプ、釣り、ハイキングなどのアウトドア活動を楽しんでいます。 Lana Zhang は、AWS の Worldwide Specialist Organization に所属する生成 AI のシニアスペシャリストソリューションアーキテクトです。AI 音声アシスタントやマルチモーダル理解などのユースケースに焦点を当てた AI/ML を専門としています。メディア・エンターテインメント、ゲーム、スポーツ、広告、金融サービス、ヘルスケアなど、さまざまな業界のお客様と緊密に連携し、AI を通じてビジネスソリューションの変革を支援しています。 Yanyan Zhang は、Amazon Web Services のシニア生成 AI データサイエンティストです。生成 AI スペシャリストとして最先端の AI/ML 技術に取り組み、お客様が生成 AI を使用して望む成果を達成できるよう支援しています。テキサス A&amp;M 大学で電気工学の博士号を取得しました。仕事以外では、旅行、ワークアウト、新しいことの探求を楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の 榎本 貴之 がレビューしました。

Amazon Simple Storage Service (Amazon S3) は、アプリケーションの需要に応じて自動的にスケールする弾力性のあるサービスで、最新の ML ワークロードに必要な高スループットパフォーマンスを提供します。 Amazon S3 Connector for PyTorch や Mountpoint for Amazon S3 などの高性能クライアントコネクタは、S3 REST API を直接扱うことなく、トレーニングパイプラインにネイティブな S3 統合を提供します。 この記事では、Amazon S3 汎用バケットから直接データを読み取る ML トレーニングワークロードのスループットを最適化するための実用的な技術と推奨事項を紹介します。ここで説明するデータ読み込み最適化技術の多くは、さまざまなストレージ基盤に広く適用できます。 これらの推奨事項を検証するため、代表的なコンピュータビジョン (CV) 学習ワークロード、具体的には数万の小さな JPEG ファイルを使用した画像分類タスクをベンチマークしました。S3 バケットからの複数のデータアクセスパターンを評価し、Amazon S3 Connector for PyTorch や Mountpoint for Amazon S3 を含むさまざまな S3 クライアントのパフォーマンスを比較しました。 調査結果によると、データセットを適切なサイズ (通常 100 MB ~ 1 GB) のデータシャードに統合し、シーケンシャルアクセスパターンと組み合わせることで、大幅に高いスループットが得られます。頻繁にアクセスされる学習データをキャッシュすることで、マルチエポック学習シナリオの効率がさらに向上します。最後に、評価した S3 クライアントの中で、Amazon S3 Connector for PyTorch が一貫して最高のスループットを達成し、S3 のデータアクセスに一般的に使用される他の方法を上回りました。 ML トレーニングパイプラインのパフォーマンスボトルネック GPU は ML 計算の高速化に重要な役割を果たしますが、学習は相互に依存するいくつかの段階を持つ多面的なプロセスであり、そのいずれもがボトルネックになる可能性があります。以下の図は、典型的なエンドツーエンドの学習パイプラインを示し、これらの段階がどこで発生するかを強調しています。学習アルゴリズム、モデルアーキテクチャ、実装の詳細、ハードウェアなどの要素はすべて重要ですが、学習ワークロードを以下の 4 つの繰り返し高レベルステップを持つパイプラインとして考えると便利です。 学習サンプルの読み取り – 永続ストレージからメモリへ 学習サンプルの前処理 – デコード、変換、拡張などのステップをメモリ内で実行 モデルパラメータの更新 – GPU 間で計算および同期された勾配に基づいて実行 学習チェックポイントの保存 &nbsp;– 障害発生時に最新の状態から学習を再開できるようにするため、定期的に実行 ML トレーニングパイプラインの実効スループットは、最も遅いステップによって制約されます。ステップ 3 (モデル更新の実際の計算) が最終的に重要ですが、クラウドベースの ML ワークロードには独自の課題があります。通常、コンピューティングとストレージリソースが設計上分離されているクラウド環境では、データ入力パイプライン (ステップ 1 ~ 2 )が重大なボトルネックとして頻繁に現れます。チェックポイント処理 (ステップ 4) も全体的な学習効率に影響を与える可能性がありますが、この記事では取り上げません。 最新の GPU でも、処理するデータを待ってアイドル状態になっている場合、学習を加速できません。データ待ち時間が発生すると、より強力なコンピューティングハードウェアへ追加投資しても非効率であり、本番環境では高コストになります。最大の GPU 使用率を達成するには、GPU が継続的に学習データを処理できるように、データパイプラインを慎重に最適化する必要があります。 データ読み込みの課題 Amazon S3 からのデータ読み込みパフォーマンスに影響を与える最も重要な要素の 1 つは、学習中にデータがアクセスされるパターンです。特に、データ読み取り方法がシーケンシャルかランダムかによって、全体的なスループットとレイテンシーは大きく影響を受けます。これらのアクセスパターンが Amazon S3 の基礎特性とどのように相互作用するかを理解することが、効率的な入力パイプラインを設計するための鍵となります。 Amazon S3 上の ML ワークロードにおけるシーケンシャル読み取りとランダム読み取り Amazon S3 からのデータ読み取りは、機械式アクチュエータアームを持つ従来のハードディスクドライブ (HDD) の動作に例えることができます。以下の図が示すように、HDD はデータブロックが連続して配置されている場合、アクチュエータアームの移動を最小限に抑えてシーケンシャルにデータを読み取ります。対照的に、ランダム読み取りでは、アクチュエータアームがディスク表面を飛び越えて散在するブロックにアクセスする必要があり、アームの物理的な再配置による遅延が発生します。 Amazon S3 上のデータにアクセスする際、状況は HDD の例にやや似ています。正確には、各 S3 リクエストは実際のデータ転送が始まる前に最初のバイトまでの時間 (TTFB) オーバーヘッドが発生します。このオーバーヘッドは、接続の確立、ネットワークラウンドトリップレイテンシー、S3 の内部操作 (データの場所の特定やディスクへのアクセスなど)、クライアント側のレスポンス処理など、いくつかのコンポーネントで構成されます。データ転送時間自体は取得されるデータのサイズに応じてスケールしますが、S3 GET リクエストの TTFB オーバーヘッドは主に固定されており、データオブジェクトのサイズとは独立しています。これを以下の図が示しています。 ML ワークロードを議論する際の HDD のアナロジーに従えば、例えばデータセットが S3 に保存された多数の小さなファイルで構成され、各ファイルに単一の学習サンプルが含まれている場合、クラウドストレージからのランダム読み取りパターンがあると言えます。あるいは、学習スクリプトが例えばバイト範囲の S3 GET リクエストを使用して、より大きなファイルシャード内のさまざまな部分からサンプルを取得する場合にも、ランダム S3 アクセスが発生します。これは、YouTube ビデオをシーンを前後にスキップしながら視聴するのに似ています。 逆に、データセットが大きなファイルシャードに整理され、各シャードに多くの学習サンプルが含まれ、それらを次々とシーケンシャルに反復できる場合、シーケンシャル読み取りパターンが発生します。この場合、単一の S3 GET リクエストで複数のサンプルを取得でき、ランダム読み取りシナリオよりもはるかに高いデータスループットが可能になります。このアプローチはデータのプリフェッチも効率化します。次のサンプルバッチを予測し、取得してメモリにバッファリングできるため、GPU がすぐに利用できる状態になります。 スループットへの影響の分析：コンピュータビジョンのケーススタディ さまざまなデータアクセスパターンがパフォーマンスにどのように影響するかをよりよく理解するために、データセットが多くの比較的小さな画像ファイル (各約 100 KB) で構成されるコンピュータビジョンタスクの 2 つのシナリオを見てみましょう。最初のシナリオでは、データセットはそのまま Amazon S3 Standard ストレージクラスに保存され、学習スクリプトは各画像をオンデマンドで取得します。これにより、各学習サンプルが独自の S3 GET リクエストを必要とするランダム読み取りアクセスパターンが作成されます。S3 Standard の TTFB レイテンシーは数十ミリ秒のオーダーであり、小さなファイルの実際のダウンロード時間はそれに比べて最小限であるため、データローダーのパフォーマンスはレイテンシーバウンドになります。つまり、クライアントスレッドはデータの到着を待っている間、ほとんどの時間をアイドル状態で過ごします。 2 番目のシナリオでは、データセットは S3 に保存される前に、より大きなファイルシャード(例えば各約 100 MB) に統合されます。これで、データローダーは単一の S3 GET リクエストで複数の学習サンプルをシーケンシャルに読み取ります。これにより、ワークロードは帯域幅バウンドにシフトし、サンプルごとの TTFB 影響が除去され、ダウンロードフェーズ中の連続サンプルの効率的なストリーミングが可能になります。 Amazon S3 からのデータ読み込みの最適化技術 S3 からの ML ワークロード用のランダムおよびシーケンシャルデータアクセスパターンについて説明したので、実際にデータ取り込みパイプラインを最適化する方法を見ていきましょう。 S3 向けに最適化された高性能ファイルクライアントの使用 利用可能なオプションが豊富であることを考えると、パフォーマンスの高い S3 ファイルクライアントを選択することは困難です。これに対処するため、2023 年に AWS は S3 用の 2 つのネイティブオープンソースクライアント、Mountpoint for Amazon S3 と Amazon S3 Connector for PyTorch を導入しました。両方とも AWS Common Runtime (CRT) 上に構築されており、CRT はリクエストの並列化、タイムアウト、リトライ、接続の再利用などのベストプラクティスのパフォーマンス最適化を実装するネイティブ S3 クライアントを含む、高度に最適化された C ベースのプリミティブのコレクションです。これにより、お客様は最小限の労力で最大の S3 スループットを達成できます。 Mountpoint for Amazon S3 は、コンピューティングインスタンスに S3 バケットをマウントし、既存のコードを変更することなくローカルファイルシステムとしてアクセスできるオープンソースのファイルクライアントです。これにより、ML トレーニングを含む幅広いワークロードに適しています。 Kubernetes 環境では、Mountpoint for Amazon S3 Container Storage Interface (CSI) Driver が S3 バケットをストレージボリュームとして提示することでこの機能を拡張し、コンテナが使い慣れたファイルシステムインターフェースを通じて S3 オブジェクトにアクセスできるようにします。最近リリースされた Mountpoint for Amazon S3 CSI v2 では、ドライバーはポッド間の共有キャッシングも導入しており、分散 ML ワークロードがローカルにキャッシュされたデータを再利用できるため、パフォーマンスとリソース効率の両方が向上します。CSI ドライバーは、あらゆる Kubernetes ベースのアプリケーションと互換性があり、Amazon Elastic Kubernetes Service (Amazon EKS) と統合でき、そこでは合理化されたインストールとライフサイクル管理のためのマネージドアドオンとして利用できます。 Amazon S3 Connector for PyTorch は、PyTorchのための、S3 と学習パイプラインを密接に連携できる機能です。この統合により、学習データへの高スループットアクセスと、Amazon S3 への直接的な効率的なチェックポイント処理が可能になります。学習データの読み取りやモデルチェックポイントの書き込み時に、パフォーマンス最適化を自動的に適用します。 コネクタは、ランダムアクセス用のマップスタイルデータセットと、シーケンシャルアクセスをストリーミングするための反復可能スタイルデータセットの両方をサポートしており、さまざまな ML 学習パターンに適しています。また、ローカルストレージに依存せずに S3 からチェックポイントを保存および読み込むことができる組み込みのチェックポイントインターフェースも含まれています。インストールは簡単 (例えば pip を使用) で、コネクタは追加のファイルシステムクライアントや複雑なシステムセットアップを必要とせず、 GitHub で実証されているように、学習コードへの最小限の変更のみが必要です。 データセットのシャード化とシーケンシャル読み取りパターンの使用 S3 からのデータ読み込みを最適化するための効果的な戦略は、データセットを各々に多くの学習サンプルを含む、より少数のより大きなファイルシャードにシリアル化し、データローダーを使用してそれらのサンプルをシーケンシャルに読み取ることです。 S3 micro-benchmark では、100 MB ~ 1 GB のシャードサイズが通常、優れたスループットを提供しました。ただし、理想的なサイズはワークロードによって異なる場合があります。小さなシャードはプリフェッチバッファからの準ランダムサンプリング動作を改善でき、大きなシャードは一般的により良いスループットを提供します。 シャード化の一般的なファイル形式には、 tar ( WebDataset などのライブラリを通じて PyTorch で頻繁に使用されます)と TFRecord (TensorFlow で tf.data と共に使用されます) があります。とはいえ、データのシャード化はシーケンシャル読み取りを保証するものではありません。データローダーがシャード内のサンプルにランダムにアクセスする場合 ( Parquet や HDF5 などの形式で一般的)、シーケンシャルアクセスの利点が失われる可能性があります。パフォーマンス向上を完全に実現するには、各シャード内のサンプルが順番に読み取られるようにデータローダーを設計することをお勧めします。 トレーニングサンプルの並列化、プリフェッチ、キャッシング ML パイプラインのデータ取り込みおよび前処理段階の最適化は、学習スループットの最大化、特にランダムデータアクセスパターンが避けられない場合に重要です。並列化、プリフェッチ、キャッシングなどの技術は、I/O ボトルネックを最小限に抑え、GPU を完全に利用する上で中心的な役割を果たします。 並列化 は、データ読み込みパイプラインのスループットを向上させる最も効果的な方法の 1 つです。特に、データのデコードと前処理は、通信する必要なく同時に実行できる多くの独立したプロセスに分解できる、非常に並列化しやすい処理であることが多いためです。TensorFlow ( tf.data ) や PyTorch (ネイティブな&nbsp; DataLoader ) などのフレームワークを使用して、ワーカープール (CPU スレッドまたはプロセス) のサイズを調整し、データ取り込みを並列化できます。 シーケンシャルアクセスパターンの場合、経験則としては、ワーカースレッドの数を利用可能な CPU コアの数に合わせることです。ただし、CPU カウントが高いインスタンス (例えば 20 を超える) では、やや小さいプールサイズを使用すると効率が向上します。 対照的に、ランダムアクセスパターン、特に S3 から直接読み取る場合、ベンチマークでは CPU カウントよりも大きなプールサイズが有益であることが証明されました。例えば、8 個の vCPU を持つ EC2 インスタンスでは、PyTorch の&nbsp; num_workers 設定を 64 以上に増やすと、データスループットが大幅に向上しました。 とはいえ、並列化を増やすことは万能薬ではありません。過度の並列化は CPU とメモリリソースを圧倒し、ボトルネックを I/O から前処理にシフトさせる可能性があります。適切なバランスを見つけるために、特定のワークロードのコンテキスト内でベンチマークを行うことが重要です。 プリフェッチ は、データ読み込みを GPU 計算から分離することで並列化を補完します。プロデューサー-コンシューマーパターンを使用して、プリフェッチはデータを非同期で準備し、メモリにバッファリングすることで、GPU が必要とするときに次のバッチが準備できるようにします。適切なサイズのプリフェッチバッファと適切に調整されたワーカープールサイズは、I/O と前処理のレイテンシーを償却し、全体的な学習スループットを向上させるのに役立ちます。 キャッシング は、同じデータサンプルが複数回読み取られるランダムアクセスパターンを持つマルチエポック学習ワークロードに特に効果的です。Mountpoint for Amazon S3 などのツールは、データセットオブジェクトをインスタンスストレージ (例えば NVMe ディスク)、EBS ボリューム、またはメモリにローカルに保存する組み込みのキャッシングメカニズムを提供します。繰り返される S3 GET リクエストを削除することで、キャッシングは学習速度とコスト効率を向上させます。 学習中は入力データセットが通常静的なままであるため、繰り返される S3 リクエストオーバーヘッドを減らすために、無期限のメタデータ TTL で Mountpoint を構成することをお勧めします ( --metadata-ttl indefinite を設定します、 Mountpoint for S3 ドキュメント を参照ください)。さらに、ベンチマークでは、NVMe へのデータキャッシングも有効にし、Mountpoint がオブジェクトをローカルに保存できるようにしました。キャッシュは、最も最近使用されていないファイルを削除することでスペースを自動的に管理し、デフォルト設定では、ディスク容量の少なくとも 5%を空きスペースとして確保します (設定可能)。キャッシングから完全に恩恵を受けるには、インスタンスに頻繁にアクセスされるデータを保持するのに十分なディスクスペースがあることを確認してください。 パフォーマンスケーススタディ：Amazon S3 Standard からのデータ読み込み 前述のベストプラクティスを検証するため、ランダムおよびシーケンシャルデータアクセスパターンの両方で、現実的なコンピュータビジョン (CV) 学習ワークロードをシミュレートする一連のベンチマークを実施しました。正確な結果は特定のユースケースによって異なる場合がありますが、パフォーマンスの傾向と洞察は、ML トレーニングパイプライン全体に広く適用できます。 ベンチマークセットアップ すべてのベンチマークは、NVIDIA A10G GPU と 32 個の vCPU を搭載した Amazon Elastic Compute Cloud (Amazon EC2) g5.8xlarge インスタンスで実行されました。ベンチマークワークロードは、画像分類タスク用の google/vit-base-patch16-224-in21k バックボーン ViT モデルを使用し、100,000 枚の合成 JPEG 画像 (各約 115 KB) を含む 10 GB のデータセットで学習しました。データセットは、次のいずれかの S3 クライアントを使用して、学習スクリプトによって Amazon S3 Standard からオンデマンドで直接ストリーミングされました。 fsspec ベースのデータローダー – クラウドオブジェクトストア用の人気のあるオープンソースインターフェースである fsspec に基づく TorchData DataPipes の実装。TorchData は v0.10 でDataPipes を廃止しましたが、fsspec は S3 からの ML データアクセスに広く使用されています。 Mountpoint for Amazon S3 (データキャッシングなし) – AWS が開発した高スループットのオープンソースファイルクライアント。この構成では、メタデータキャッシングは有効ですが、学習サンプルはエポック間でローカルにキャッシュされません。 Mountpoint for Amazon S3 (データキャッシング) – 前のクライアントと同じですが、エポック全体で頻繁にアクセスされるサンプルを保存するために、ローカルディスクキャッシングが有効になっています。 S3 Connector for PyTorch – PyTorch のデータセット API と緊密に統合された高性能のオープンソース S3 インターフェースで、AWS がメンテナンスしています。 各ベンチマーク構成は、事前のローカルダウンロードや前処理なしに、学習中にデータセットをオンデマンドでストリーミングしました。 ベンチマークの目標 ベンチマークは以下を探求するために設計されました。 データローダーでの並列化設定の調整の効果 Mountpoint for Amazon S3 を使用したローカルディスクキャッシングのパフォーマンスへの影響 シーケンシャル読み取りパターンの採用によるスループット向上 データセットシャードサイズと持続的なデータ読み込みパフォーマンスの関係 両方のアクセスパターンについて、前処理段階には JPEG デコードと 224×224×3 へのリサイズが含まれ、その後 128 のミニバッチにバッチ化されました。この軽量なセットアップにより、CPU バウンドのオーバーヘッドを最小限に抑えながら、現実的なエンドツーエンドのパイプラインを維持することができました。 再現性とベストプラクティス 独自の環境で同様のベンチマークを再現するために、さまざまな S3 データ読み込み構成をサポートする 専用のベンチマークツール を提供しています。 一貫性のある意味のある結果を得るために： 各 S3 クライアントに対して同一の EC2 インスタンスタイプを使用します。 各テストデータセットを別々の S3 バケットに配置して、トラフィックを分離し、クライアント間の干渉を避けます。 S3 バケットと同じ AWS リージョンで実験を実行して、レイテンシーとネットワークの変動を最小限に抑えます。 これらのベストプラクティスに従うことで、クリーンな測定値を取得し、独自のワークロードでさまざまなデータ読み込み戦略を確実に比較できます。 ランダムアクセスでの単一エポックベンチマーク Amazon S3 から直接データセットをストリーミングする際の並列化の効果を評価するために、潜在的な OS レベルのキャッシングからの干渉を避けるため、1 エポックのベンチマーク (学習データセット全体を 1 回読み込み) を実行しました。 少ないワーカー数では、すべての S3 クライアントがデータ取り込みボトルネックを示し、全体的なスループットを制限します。並列化の度合いが増加すると、スループットが大幅に向上します。特に、S3 Connector for PyTorch は、16 ワーカー以上でほぼ GPU 飽和 (約 138 サンプル/秒) に達します。 ただし、ワーカープールの積極的なスケーリングは、CPU とメモリの負荷を増加させます。これは fsspec ベースのデータローダーで特に顕著で、32 ワーカーで約 100% の CPU 使用率に達し、CPU バウンドのボトルネックを引き起こし、GPU 使用率を低下させ、全体的なサンプルスループットを減少させます。対照的に、S3 Connector for PyTorch は負荷下でより良い効率を維持し、高性能 S3 クライアントを使用することの重要性を強調しています。 データキャッシングありとなしの Mountpoint for Amazon S3 は、この 1 エポックベンチマークでほぼ同じパフォーマンスを提供します。これは予想通りで、各サンプルが一度だけ読み取られ、キャッシングが利点を提供しないためです。次に説明するマルチエポックシナリオでキャッシングの利点を再検討します。 ランダムアクセスでのマルチエポックベンチマーク Mountpoint for Amazon S3 のキャッシング機能は、頻繁にアクセスされる S3 オブジェクトをローカルストレージに保存することで、学習パフォーマンスを大幅に向上させ、エポック間で取得レイテンシーとリクエストコストを削減します。ベンチマークでは、最初のエポック中にアクセスされたデータセットファイルがローカルにキャッシュされます。2 番目のエポック以降、データセット全体がディスクから提供され、データローダーワーカープールが 16 であっても GPU を完全に飽和させ、スループットを最大化します。 次のプロットに示されているように、キャッシングはトレーニングを加速するだけでなく、ネットワークトラフィックと S3 リクエスト量も最小限に抑えます。最初のエポックの終わり (約 2 分マークあたり) までに、Mountpoint は S3 への GET、LIST、HEAD リクエストをさらに削減します。対照的に、キャッシングなしの S3 クライアントは、各エポックで同じデータを継続的に再ダウンロードし、より高いレイテンシーと運用コストを発生させます。 シーケンシャルアクセスでの単一エポックベンチマーク シーケンシャルデータアクセスの利点を検証するために、以前と同じセットアップ (8 データローダーワーカー)を使用してベンチマークを再実行しましたが、シャードサイズが 4 MB ~ 256 MB の tar 形式のシリアル化されたデータセットに切り替えました。 一見すると、このベンチマークの結果は地味に見えるかもしれません。すべての折れ線プロットが平坦です。しかし待ってください、それこそが素晴らしい部分ではないでしょうか？ GPU 負荷は一貫して約 100% の使用率で平坦であり、すべてのファイルシャードサイズにわたって GPU を完全に飽和させていることを意味します。それを一貫して低い CPU 使用率と組み合わせると、非常に注目すべき成果が得られます！ シーケンシャルアクセスでの理論上の最大ベンチマーク 前述のベンチマークの結果は興味深い疑問を提起します。シーケンシャルアクセスで、このセットアップで達成できる理論上の最大スループットはどれぐらいでしょうか？調査のために、方程式から GPU バウンドのモデル学習段階を削除し、CPU 上での読み取りと前処理段階のみを残しました。ワーカープールサイズ 8 の結果を次のプロットに示します。 結果は、fsspec ベースのデータローダーを除くすべてのクライアントで、シャードサイズが大きいほどスループットが向上することを示しています。S3 Connector for PyTorch は最高のパフォーマンスを提供し、テストされた最大のシャードサイズで 8,000 サンプル/秒を超えます。より高い並列化 (32 ~ 64 ワーカー) またはより大きなシャードでは、スループットはさらにスケールし、拡張テストで 12,000 サンプル/秒を超えました。 結論 クラウドでの最新の ML トレーニングパイプラインのパフォーマンスを完全に引き出すには、データ取り込みの最適化が不可欠です。この記事では、ランダムなデータ読み取りや、小さいファイルサイズのデータを使うことがレイテンシーオーバーヘッドを増加させ、スループットを著しく制限する一方で、シーケンシャルアクセスパターンを持つ統合データセットが帯域幅を最大化し、GPU を完全に利用できることを示しました。 Mountpoint for Amazon S3 や S3 Connector for PyTorch などの高性能 Amazon S3 クライアントを使用することが、トレーニングパフォーマンスに大きな違いをもたらすことを探求しました。また、データセットをより大きなファイルにシャード化し、並列化設定を調整し、冗長な S3 リクエストを最小限に抑えるためにキャッシングを適用する利点も示しました。Amazon S3 Standard からのデータアクセスに焦点を当てたベンチマークは、これらのベストプラクティスがアイドル GPU 時間を大幅に削減し、コンピューティングリソースから最大の価値を得るのに役立つことを確認しています。 学習ワークロードが成長するにつれて、データパイプライン設計を見直し続けてください。データ読み込みに関する慎重な決定は、コスト効率と結果までの時間において大きな利益をもたらすことができます。 著者について Dr. Alexander Arzhanov は、ドイツのフランクフルトを拠点とするシニア AI/ML スペシャリストソリューションアーキテクトです。彼は、EMEA 地域全体で AWS の顧客が ML ソリューションを設計および展開するのを支援しています。AWS に入社する前、Alexander は宇宙における重元素の起源を研究しており、大規模な科学計算で ML を使用した後、ML に情熱を持つようになりました。 Ilya Isaev は、英国ケンブリッジを拠点とする Amazon S3 のソフトウェアエンジニアです。彼は、顧客が Amazon S3 で学習データとモデルチェックポイントを効率的に保存および管理できるよう支援し、高性能 GPU インスタンスの大規模クラスター向けのリアルタイムデータアクセスパフォーマンスの改善に焦点を当てています。 Roy Allela は、AWS のシニア AI/ML スペシャリストソリューションアーキテクトです。彼は、小規模なスタートアップから大企業まで、AWS の顧客が AWS 上で基盤モデルを効率的に学習および展開するのを支援しています。彼は計算最適化問題と AI ワークロードのパフォーマンス向上に情熱を持っています。 翻訳はソリューションアーキテクトの 長谷川 大 が担当しました。原文は こちら です。

2025年12月12日にAWS Systems Manager for SAPにおいて、AWSでSAPランドスケープを自動化・管理する方法を変革する3つの機能を発表しました： 構成管理のためのSAPアプリケーションカバレッジの拡張 : AWS Systems Manager for SAP Configuration Managementの自動構成検証が、SAP ABAPアプリケーションをサポートするようになり、S/4HANA、BW/4HANA、ECCなどのABAPベースのSAPアプリケーション全体にわたる包括的なカバレッジを提供します。 Amazon Qによる生成AI搭載のSAPオペレーション : Amazon Qを使用した自然言語でのやり取りを通じて、SAPオペレーションに関する即座のコンテキストに応じた支援を受けられます。 自動タスクスケジューリング : 新しいEventBridge統合により、構成チェックとSAPアプリケーションのアプリケーション認識型起動/停止などのAWS Systems Managerがサポートするオペレーショナルタスクの柔軟なスケジューリングが可能になります。 これらの機能強化により、SAPオペレーションチームに以下の主要なメリットがもたらされます： データベース層とアプリケーション層全体にわたる包括的な構成管理 迅速なオペレーショナルインサイトと運用管理タスクの実行のための対話型インターフェース EventBridgeを使用した定型管理タスクのスケジュール化された自動化 ABAPベースのSAPアプリケーション向けの包括的な構成検証 SAPアプリケーションは、財務からサプライチェーンまで、企業の中核となるビジネスプロセスを支える重要なシステムです。当社の構成チェックは当初SAP HANAデータベースをサポートしていましたが、お客様からSAP ABAPベースのアプリケーションを自動的に検証できる機能のご要望をいただいておりました。今回のリリースにより、自動検証をSAP ABAPベースのアプリケーションにも拡張いたします。この拡張により、データベース層とアプリケーション層の両方をカバーする、SAPシステム全体にわたる一貫したベストプラクティス検証が保証されます。 拡張された設定チェックに含まれる内容: 今回のリリースでは、既存の設定チェックを拡張し、SAP ABAPアプリケーションをサポートします。 HANAデプロイメントで効果が実証されている3つの包括的な設定チェックが、 AWS Well-Architected FrameworkのSAP Lens および AWS for SAP技術ドキュメント に照らしてABAPアプリケーション設定を検証できるようになりました。 EC2インスタンスタイプ選択チェック EC2インスタンスタイプ選択チェック は、ABAPアプリケーションサーバーが適切なハードウェア設定を持つ認定インスタンスタイプで実行されていることを検証します ストレージ構成チェック は、ABAPアプリケーションサーバーのストレージ構成がAWSの推奨事項に従っていることを確認します Pacemakerクラスター構成チェック は、ABAPアプリケーションサーバーの高可用性セットアップを検証します 各チェックは、構成のさまざまな側面を評価する個別のルールを通じて、同じ包括的な評価を提供し、OKAY、ERROR、WARNING、またはINFOのステータスを返します。これらのチェックは、HANAとABAPの両方の要件に合わせて調整されており、期待される値、参照リンク、および関連する技術ドキュメントを示すことで修復ガイダンスを提供します。 SAP ABAPアプリケーション構成の検証 AWS Systems Manager for SAP Configuration Managerを使い始めるには、まず SAP ABAPアプリケーションをSystems Manager for SAPに登録 してください。アプリケーション構成をベストプラクティスと照らし合わせて評価する前に、この登録が必要です。 SAP ABAPアプリケーションをAWS Systems Manager for SAPに登録した後、AWS Management Consoleから、AWS Systems Manager -&gt; Application Managerに移動します。 検索フィールドで、Application sourceとしてSAPを選択すると、登録済みのSAP ABAPシステムを素早く見つけることができます。 評価したいSAP ABAPアプリケーションを選択し、「Actions」ドロップダウンメニューをクリックして「SAP check configuration」を選択します。詳細な手順については ドキュメント を参照してください。 Amazon Q*でSAP運用を強化 *お客様がSAPトランスフォーメーションの一環としてAWS AIサービスを使用する際には、 AWS責任あるAIポリシー を参照することをお勧めします。 AWS上でSAPアプリケーションを運用するには、SAP Basis管理者からインフラストラクチャチームまで、複数の役割にわたる調整が必要です。AWS Systems Manager for SAPは、アプリケーションの登録と検出を通じて多くの管理タスクを統合しますが、包括的な運用のためには、チームは依然として複数のサービスインターフェースを操作する必要があります。 Amazon Qは、AWS Systems Manager for SAPおよび関連するAWSサービスへの統一された会話型インターフェースを提供することで、これらの機能を強化します。自然言語でのやり取りを通じて、チームは次のことができます： SAPアプリケーションの状態と設定の照会 AWSサービスとSAP運用インサイトへのアクセス コンテキストに応じたドキュメントとベストプラクティスの取得 インフラストラクチャの設定とメトリクスの調査 AWS Systems Manager for SAPおよび関連サービスAPIとのインターフェース 注：Amazon Qは運用データと推奨事項への便利なアクセスを提供しますが、本番環境に実装する前に、すべての出力をお客様の組織の要件とベストプラクティスに照らして検証する必要があります。 SAP運用のためにAmazon Qとやり取りする方法の例をいくつか示します： "What instance type is S4HANADev running on" "Compare costs between my current SAP HANA instance for S4HANADev and other certified alternatives" "Show me potential savings if I switch to Reserved Instances for my S4HANADev-HANA application" "I can't connect to S4HANADev-HANA database using HANA Studio, check network configurations" "Review security group configurations for S4HANADev-HANA database access" "Can you summarize the SAP configuration checks that were run previously on my Systems Manager for SAP application S4HANADev ? Use the following guidance - Get the failed subchecks, using list-subcheck-results - For each failed subcheck result ID, use it as an input to call it with list-subcheck-rule-results API, and get additional details on the failures and recommendations - Do the same for each failed subcheck above". Amazon QでSAPアプリケーションを運用する AWSコンソール内のAmazon Qは、AWS上でのSAP運用に対して会話形式のサポートを提供します。以下の手順で開始できます： AWSマネジメントコンソールにサインインします 任意のコンソールページの右上隅にあるAmazon Qアイコンを選択します チャットパネルが開き、SAPの運用に関するお問い合わせをサポートする準備が整います EventBridge統合によるオペレーションのスケジューリング AWS Systems Manager for SAPは、APIとコンソール体験の両方からアクセス可能な、起動/停止機能や設定検証を含むアプリケーション対応のSAPオペレーション機能を提供します。お客様はこれらの機能をオンデマンドのオペレーションに使用してきましたが、週次のコンプライアンスチェックや営業時間外の自動起動/停止などの定期的なアクティビティの自動化に対する需要が高まっています。新しいAmazon EventBridge Scheduler統合は、AWS Systems Manager for SAPオペレーションの自動実行を可能にすることでこのニーズに対応し、お客様がこれらのタスクを効率的にスケジュールおよび自動化できるようにします。 Amazon EventBridge SchedulerによるSAPオペレーションの自動化は簡単です： EventBridge Schedulerへのアクセス AWS Management Consoleにサインインします Amazon EventBridgeに移動します Scheduler を選択し、 Create schedule を選択します スケジュールタイプの選択 1回限り: 移行前のチェックやアップグレード後の検証に使用 レートベース: 定期的な間隔で実行（例：「7日ごと」） Cronベース: 正確なタイミングで実行（例：「毎週月曜日の午前2時」） ターゲットを設定する ターゲットの詳細で： AWS services を選択 「All APIs」から Systems Manager for SAP を選択 アクションとして StartConfigurationChecks を選択 必要なパラメータを指定します： { "ApplicationId": "S4HANADev", } EventBridge Schedulerは実行とログ記録を自動的に処理し、AWSオートメーションワークフローとのシームレスな統合を提供します。 2. アクセス許可 セクションで、SchedulerがStartConfigurationCheck操作を正常に実行するためには、 こちら に記載されている手順を使用してIAMロールを作成する必要があります。 提供状況と料金 AWS Systems Manager for SAPのすべての機能は、Systems Manager for SAPが サポートされている AWSリージョンで利用可能です。Amazon Qの統合とEventBridge Schedulerの自動化は、これらのサービスが利用可能なリージョンでご利用いただけます。サポートされているリージョンの最新リストについては、AWSサービスエンドポイントの ドキュメント をご覧ください。 AWS Systems Manager for SAPは、初期費用や最低料金なしのシンプルな従量課金制の料金モデルに従っています。SAPアプリケーションの登録、アプリケーション対応の起動/停止操作、基本的なモニタリングを含む基本機能は、追加料金なしで利用できます。構成管理については、アプリケーションごとに1回の構成チェック実行につき0.25ドルをお支払いいただき、結果は30日間保持されます。たとえば、2つのSAPアプリケーションに対して週3回チェックを実行する場合、月額6.00ドルとなります。SAP HANAデータベースに対してAWS Backup統合を使用する場合、使用したAWS Backupストレージに対してのみお支払いいただき、バックアップオーケストレーションに対する追加料金はかかりません。EventBridge Schedulerを使用した自動化操作については、スケジュールあたり1日0.00864ドル（日次スケジュールの場合、月額約0.26ドル）という最小限の料金が発生します。 まとめ この発表により、AWS Systems Manager for SAPの機能が拡張され、ABAPアプリケーション全体にわたる包括的な設定検証、コンテキストに応じた洞察とインテリジェントな推奨事項を提供するAmazon Qを通じた生成AI搭載のオペレーション、およびEventBridgeによる自動タスクスケジューリングが可能になりました。これらの機能強化により、お客様はSAPランドスケープ全体で一貫した設定基準を維持し、AI支援によるトラブルシューティングと意思決定を通じてオペレーションを効率化し、日常的なタスクを効率的に自動化できるようになります。AWS Systems Manager for SAPにSAPアプリケーションを登録して、今日から始めましょう。詳細については、 AWS Systems Manager for SAPドキュメント をご覧ください。 本ブログは Amazon Bedrock による機械翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

はじめに こんにちは。AWS Analytics Specialist ソリューションアーキテクトの深見 です。 データベースの変更をリアルタイムに分析基盤へ反映したいというニーズに高まりを感じています。実際に多くのお客様から相談をいただいております。またデータベースの差分をもとに連携することが望まれる場面も多くあります。そういう場合の選択肢の一つが CDC（Change Data Capture）と呼ばれる MySQL の binlogなどの変更履歴をもとにデータを連携する手法になります。しかし、CDC での実装は、データ取得・キャッシュレイヤー・コンシューマーの実装とコンポーネントが多くなる場合も多く技術的なハードルが高く、ソースデータベースのスキーマの変更をターゲットの分析基盤に滞りなく連携する必要があるなど運用負荷も大きいワークロードになります。 CDC のターゲットの選択肢の１つとして、Iceberg を利用することで多様なエンジンから利用することができ、ソーススキーマの変更にも柔軟に対応ができるコスト効率の良い、DB のデータをソースにしたデータレイクハウスを構築することができます。 本記事では、AWS パートナーである primeNumber 社 が提供するデータ統合プラットフォーム「TROCCO」の CDC 機能を使って、MySQL から AWS 上の Apache Iceberg テーブルへのリアルタイムレプリケーションを実現する方法をご紹介します。実際に検証した内容をもとに、セットアップから運用まで詳しく解説していきます。 RDB から Apache Iceberg テーブルへのデータ連携のユースケース RDB をソースに Apache Iceberg へデータを連携したい場面はどのようなケースがあるでしょうか？いくつかの例をみてみましょう。 OLTP と OLAP の分離 RDB にあるデータを分析に使いたい場合でも、様々な理由で直接 RDB に分析クエリを実行することがためらわれる場面はよくあるかと思います。その中でも多く上がる理由としては、ソース DB のトランザクショナルなワークロードのパフォーマンスに影響を与えたくないといった理由です。インタラクティブに分析されるケースでは、そのためだけにリードレプリカなどで分析用のリソースを用意することもコスト増加につながってしまいます。そのため、 OLTP (Online Transaction Processing) と OLAP(Online Analytical Processing) を分離することでリソース管理・効率の向上やコスト最適化を狙った分離を行うことがあります。Apache Iceberg を利用することで高いコスト効率で OLAP 環境を用意することが可能になります。また、Apache Iceberg のオープンなフォーマットである特徴から分析ユーザーの好みのクエリエンジンを利用することが非常に簡単になります。例えば AWS のエンジンであれば Athena や Redshift 、OSS のエンジンであれば Spark や Trino 、 DuckDB や PyIceberg から同じテーブルを参照することができるようになります。これにより、広い活用の幅をもったデータレイクを構築することが可能になります。 タイムトラベル機能を利用した過去断面の参照 データベーステーブルの過去の断面を再現する必要のある場面は度々見受けられます。例えば、テーブルのデータに不整合が発生した際のロールバック、もしくは ML や AI のモデル開発時のモデル変更による影響を過去のテーブルを使って確認するバックテストといったユースケースがあげられます。 これに関連する Iceberg の大きな特徴として、スナップショットを利用した過去のテーブルの断面を指定してクエリを実行する タイムトラベル 機能があります。RDB から Iceberg テーブルにデータを差分で連携することで過去のテーブルの状態を容易に確認することが可能です。従来変更差分をバックアップとして保持しようとすると、定期的にフルスナップショットを取得しそれを保管しておくといったコストのかかる方法が必要でした。しかし、Iceberg では差分データを効率的に保持することが可能なため高いコスト効率でテーブルの断面を保持することが可能です。 &nbsp; 他にも様々な場面で RDB から Iceberg テーブルへのデータ連携が有効なソリューションになりえます。これを実装や管理・運用の手間を低く抑えて実現することができる 1 つの手段が TROCCO の CDC 機能になります。 TROCCO とは TROCCO は、データの収集・加工・転送を簡単に実現できるデータ基盤構築・運用の支援 SaaS です。ノーコード/ローコードでデータパイプラインを構築でき、多様なデータソースとデスティネーションに対応しています。 今回ご紹介する TROCCO の CDC 機能 は、ソーステーブルの変更（INSERT/UPDATE/DELETE）やカラムの追加といったスキーマの変更をリアルタイムに検知し、ターゲットシステムへ自動的に反映することをインフラの管理なく実現することができる機能です。ソース DB としては、2025 年 12 月時点で MySQL と PostgreSQL に対応しています。(CDC 機能は Professional プランの契約が前提となります。) 今回はその中の、ソースの MySQL から ターゲットの AWS 上の Glue Data Catalog に登録された Iceberg テーブルにデータ連携する方法をご紹介します。 アーキテクチャ概要 今回構築するシステムのアーキテクチャは以下の通りです： ソース : MySQL データベース(8.x 以降推奨） CDC 処理 : TROCCO CDC 機能 ターゲット : Amazon S3 + AWS Glue Data Catalog（Apache Iceberg 形式） クエリエンジン : Amazon Athena TROCCO が MySQL のバイナリログを監視し、変更を検知すると、その変更を Iceberg 形式で Amazon S3 に書き込みます。 Glue Data Catalog にメタデータが登録されるため、Athena から即座にクエリ可能になります。 セットアップ手順 1. ネットワーク設定 TROCCO から MySQL へ接続するため、セキュリティグループの設定が必要です。TROCCO の固定 IP アドレスからの接続を許可します。 TROCCO の固定 IP アドレスは 公式ドキュメント で確認できます。また、エフェメラルポートとして 1024-65535 を使用するため、セキュリティグループでこの範囲を開放する必要があります。 2. IAM ロールの作成 TROCCO が S3 と Glue Data Catalog にアクセスするため、適切な権限を持つ IAM ロールを作成します。CDC 機能では IAM ロールのみがサポートされています（IAM ユーザーは使用できません）。 TROCCO のドキュメント &nbsp;にある必要な IAM ポリシーの例はこのようなものになります。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": "arn:aws:s3:::&lt;bucket_name&gt;" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::&lt;bucket_name&gt;/*" }, { "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:UpdateDatabase", "glue:CreateDatabase" ], "Resource": [ "arn:aws:glue:&lt;aws_region&gt;:&lt;account_id&gt;:catalog", "arn:aws:glue:&lt;aws_region&gt;:&lt;account_id&gt;:database/&lt;database_name&gt;" ] }, { "Effect": "Allow", "Action": [ "glue:GetTable", "glue:UpdateTable", "glue:CreateTable", "glue:DeleteTable" ], "Resource": [ "arn:aws:glue:&lt;aws_region&gt;:&lt;account_id&gt;:catalog", "arn:aws:glue:&lt;aws_region&gt;:&lt;account_id&gt;:database/&lt;database_name&gt;", "arn:aws:glue:&lt;aws_region&gt;:&lt;account_id&gt;:table/&lt;database_name&gt;/*" ] } ] } ターゲットの Iceberg テーブルの Location である S3 と 該当の Glue Data Catalogへのアクセス権限が必要になります。 3. TROCCO 接続情報の設定 TROCCO の管理画面から、以下の接続情報を登録します。 Amazon S3 の接続情報: IAM Role の ARN、S3 バケット名、リージョン MySQL の接続情報: ホスト名、ポート、データベース名、ユーザー名、パスワード まずは Amazon S3 への接続情報を設定する必要があります。 AWS アカウント ID、先ほど 2 番で作成した IAM Role を設定します。 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; また、下部に表示される TROCCO の AWS アカウントと外部 ID を先ほど作成した IAM Role に設定します。 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; IAM Role の 信頼ポリシーは以下のようになります。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::{TROCCO AWS Account ID}:root" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": {External ID}" } } } ] } 次に、MySQL 接続情報を設定します。接続先 DB のホスト、ポート、ユーザー名、パスワードが必要になります。この設定をする前に ソース DB 側で binlogの設定 が必要になることに注意してください。 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 4. CDC 転送設定の作成 今作成した接続情報を元に、TROCCO の管理画面から新しい CDC 転送設定を作成します。 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ここで、この CDC データ転送機能の特徴であるテーブルやカラムの自動追従に関する設定が可能です。テーブル・カラムどちらも追従する、カラムのみ追従する、追従しないの&nbsp; 3 パターンが選択できます。 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 先ほど設定した MySQL と S3 の接続情報をここで選択します。S3 の設定については Iceberg のプレフィックスやターゲットテーブルの Glue データベースも選択する必要があります。 設定はなんとこれだけで完了です！ 主要な機能 それでは先ほど作成した CDC データ転送設定を実行してみます。 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; データ連携 初回実行時にはフルロードが実行され、ソーステーブルの既存データがすべて Iceberg テーブルに転送されます。なお、スキーマ設定より連携するテーブルは選択することができます。 初回のフルロード完了後は、スケジュール設定に従って MySQL のバイナリログを監視して差分更新を継続的に実行します。スケジュールは最短 5 分間隔で設定可能です。 スキーマ変更の自動追従 TROCCO の CDC 機能は、ソースデータベースのスキーマ変更を自動的に検知し、Iceberg テーブルに反映します。 カラム追加の場合、新しいカラムが Iceberg テーブルに自動的に追加されます。既存レコードの新規カラムは NULL になります。バックフィル機能を有効にすると、全レコードを再転送できますが、Iceberg のスナップショット履歴が失われる点に注意が必要です。詳細は こちら をご覧ください。 カラム削除の場合、TROCCO 側では該当カラムのデータ転送が停止されますが、Iceberg テーブルからカラムは削除されません。必要に応じて手動での削除が必要です。 連携するテーブル・カラムの選択 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 転送するテーブルやその中のカラムを選択できるため、機密情報を含むカラムを除外したり、不要なカラムを転送しないことでコストを最適化することも簡単にできます。 その他にも、事前に通知先を設定しておくことで、ジョブの実行結果やスキーマ変更の通知を E-mail や Slack に行うことも可能です。また、ジョブの履歴やそれぞれのログについても UI 上で確認が可能になっています。 &nbsp; 連携した Iceberg テーブルへのクエリ ジョブの実行後に AWS コンソールからGlue カタログを確認してみると、TROCCO で設定したテーブルが適切に連携されていることがわかります。 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 連携先の Iceberg テーブルは Athena や Glue、Redshift などさまざまなエンジンからクエリすることが可能です。Iceberg テーブルへのクエリに対応している 3rd party の製品からのクエリももちろん可能です。（ただし、Equality Delete File の読み取りに対応している必要があります。詳細は Apache Iceberg のdocument をご参照下さい。） 今回は、 SageMaker Unified Studio の AI エージェントが組み込まれたノートブック からクエリを行ってみました。下のスクリーンショットのように、連携された Iceberg テーブルを簡単にクエリすることができました。 また、AI エージェントに対して連携した Iceberg テーブルへのクエリを指示することで、クエリ文を作らせて実行することも可能です。今回は、Iceberg の特徴の一つであるスナップショットの履歴を確認したい旨を指示してみました。 `Show me snapshots history of spark_catalog.trocco.movie_table_usecase.` 実際に生成されたクエリが以下の画像です。Iceberg 特有の概念ではありますが、適切なクエリを生成して実行してくれました。結果をみるとこのテーブルには２つのスナップショットがあるようです。この ID を指定することで、過去のテーブル断面をクエリすることができます。このように、Iceberg とくゆうの機能の操作に慣れていない場合でも AI エージェントを使いながら利用することが可能です。 まとめ TROCCO の CDC 機能を使うことで、複雑な CDC パイプラインを構築することなく低い実装コストで RDB と Apache Iceberg のデータ連携を実現することが可能になります。本ブログで説明したように GUI のみで非常に簡単に設定できる上に、ジョブやソーステーブルの監視と通知の機能も UI 上で利用が可能であり、運用する上でもその負荷を下げてくれる機能が揃っています。 これによって、簡単に RDB のデータをソースとした OLAP 基盤を構築したり、タイムトラベルによるバックアップの役割を持つデータレイクへの連携パイプライン構築することが可能になります。 連携した Iceberg テーブルについて、最適なパフォーマンスが出せるようにデータファイルサイズのコンパクションや期限切れスナップショットの処理などテーブルのメンテナンスが重要です。そのため、 Glue Data Catalog の Iceberg テーブルの自動メンテナンス機能 をはじめとして、メンテナンスジョブの実行についてもご検討いただくことをおすすめします。 ぜひ AWS と そのパートナーである primeNumber 社の TROCCO を利用して効果的なデータ基盤を構築していきましょう。 著者について Shuhei Fukami : AWS Japan で Analytics Specialist Solutions Architect としてデータ分析や検索などデータにまつわるワークロードのご支援をしています。趣味でピザ作りにはまっています。