本記事は 2025 年 11 月 12 日 に公開された「 From 2D to 3D: Building a Scalable Human Mesh Recovery Pipeline with Amazon SageMaker AI 」を翻訳したものです。 コンピュータグラフィックスとアニメーションの絶えず進歩する分野において、動画データから現実的な 3D ヒューマンアニメーションを自動生成する技術は、デジタルコンテンツの作成方法を変革する可能性があります。没入型フィットネス体験から最先端の映画制作まで、正確で生き生きとしたデジタルヒューマン表現への需要はこれまでになく重要になっています。しかし、現実世界の人間の動きを詳細な 3D メッシュデータに変換するプロセスは、従来から時間がかかりリソース集約的な作業であり、多くの場合、専用ハードウェアと複雑なソフトウェアパイプラインが必要でした。 組織が高度なコンピュータビジョン技術の活用をますます求める中、堅牢な 3D ヒューマンデジタル化ソリューションへの需要は高まり続けています。この記事では、エンタープライズレベルの信頼性とパフォーマンスを維持しながら、大量の動画データを処理できるスケーラブルなヒューマンメッシュリカバリ (HMR) パイプラインをAWSで構築する取り組みについて説明します。 ヒューマンメッシュリカバリの概要 ヒューマンメッシュリカバリは、画像や動画などの視覚データから人体の 3D ポーズと形状を再構築することを目的とするコンピュータビジョン技術です。HMR は、 Skinned Multi-Person Linear (SMPL) などのパラメトリック人体モデルを使用してモデルパラメータを推定します。パラメトリック人体モデルは、ポーズと形状パラメータによって定義されるメッシュとして人体を表現します。 HMR の困難な性質のため、これは継続的な研究トピックであり、新しく革新的なアプローチが定期的に発表されています。HMR の主な課題の 1 つは、人体が他のオブジェクトによって遮蔽されている、異常なポーズをとっている、または最適な背景や照明条件を提供しない環境にある画像や動画から人間の形を正確に検出することです。もう 1 つの課題は、詳細な 3D メッシュの再構築が計算量が多く時間のかかるプロセスであることです。特に入力データのすべてのフレームに人間が含まれる動画の場合はなおさらです。データニーズの削減、効率の向上、入力データからの人間の識別は、HMR 研究の主要な焦点です。 最近の HMR の進歩により、実際の人物が他のオブジェクトや人々によって遮蔽されている場合でも、単一の画像や動画から正確なデジタル 3D ヒューマンを構築することが可能になりました。HMR 技術は、拡散モデルなどの新しい AI モデルを使用して動画内の将来の時点での人間のポーズと形状を計画し、時間を通じた人間の動きを予測する研究を進歩させました。これらの技術により、HMR は 3D ヒューマンアニメーションに適用可能になります。 スコアガイド付き HMR (ScoreHMR) の概要 私たちのソリューションの中核には、3D ヒューマンポーズと形状再構築への独自のアプローチである スコアガイド付きヒューマンメッシュリカバリ (ScoreHMR) があります。従来の最適化技術とは異なり、ScoreHMR は拡散モデルを使用して入力画像から人体パラメータをキャプチャし再構築します。この高度なアプローチにより、正確な単一フレームモデルフィッティング、カメラキャリブレーションなしのマルチビュー再構築、シームレスな動画シーケンス再構築が可能になります。ScoreHMR の主な利点は、画像データを効果的に活用することで困難なデータセットで強力なパフォーマンスを達成し、従来の最適化ベースのモデルフィッティング手法を上回ることです。拡散モデル技術により、以前の回帰ベース手法と比較して多様な人間のポーズの分布をキャプチャできます。 ScoreHMR はラトガース大学の研究グループによって発表されました。彼らの研究についての詳細は、 Score-Guided Diffusion for 3D Human Recovery という論文を参照してください。この投稿の著者と本文で議論される研究は、ラトガース大学や以前の研究者とは一切関係ありません。 AWS での ScoreHMR のスケーリング 人体の 3D 表現を抽出するために大量の動画データを処理することは、計算集約的なタスクであり、特にデータ量が増加するにつれて迅速にボトルネックになる可能性があります。ここで AWS が活躍し、要求の厳しいワークロードを処理するためのスケーラビリティとパワーを提供します。 このスケーラブルなヒューマンメッシュリカバリパイプラインは、 AWS Lambda 、 Amazon S3 、 Amazon SQS 、 Amazon SageMaker AI を含む複数の AWS サービスを活用するサーバーレスアーキテクチャとして設計されています。この強力な組み合わせにより、ソリューションは容易にスケールし、パフォーマンスや効率を損なうことなく任意の量の動画データを処理できます。 図 1 – 処理用の元動画 – フットボール選手 Amazon S3 は、パイプラインで処理する必要がある元動画データを保存するためのデータ取り込みソースとして使用されます。新しい動画ファイルが S3 バケットにアップロードされると、Amazon SQS へのイベント通知をトリガーして処理リクエストをキューに入れます。AWS Lambda 関数はパイプラインの複数の段階で使用されます: AWS Lambda 関数は Amazon SQS キューによってトリガーされ、Amazon S3 から動画データを前処理し、ScoreHMR モデルでの推論用に準備します。 この AWS Lambda 関数は、前処理されたデータで Amazon SageMaker AI 非同期エンドポイントを呼び出し、ScoreHMR モデルを使用して推論を実行します。 AWS Lambda 関数は、Amazon SageMaker AI からの成功/失敗通知を処理し、それに応じて Amazon DynamoDB のメタデータを更新するためにも使用されます。 Amazon SageMaker AI は ScoreHMR モデルを実行するためのインフラストラクチャをホストし管理します。モデルは非同期エンドポイントとしてデプロイされ、数分かかる可能性がある大きな動画ペイロードの処理を可能にします。Amazon SageMaker AI エンドポイントは受信リクエストをキューに入れ、トラフィックに基づいてコンピュートリソースを自動的にスケールします。 図 2 – 処理済み動画 – フットボール選手の 3D 再構築 非同期推論は Amazon SageMaker AI の機能で、受信リクエストをキューに入れて非同期で処理します。このオプションは、大きなペイロードサイズ (最大 1GB)、長い処理時間 (最大 1 時間)、準リアルタイムレイテンシ要件を持つリクエストに最適です。非同期推論により、処理するリクエストがない場合にエンドポイントインスタンス数をゼロに自動スケールしてコストを節約できるため、エンドポイントがリクエストを処理している時のみ料金を支払います。 現在、ScoreHMR と Amazon SageMaker AI は、1GB 以上、または 1 時間以上の長さの動画のような大きなペイロードを分割する機能を提供していません。この課題への対応として、マルチモーダル Amazon Nova 基盤モデルを使用した Amazon Bedrock Data Automation を使用して、入力ビデオのシーン変化を検出し、より小さな動画クリップに分割することができます。その後、 Amazon S3 Event Notifications などのイベント駆動アプローチを使用して SageMaker エンドポイントを呼び出すことができます。 図 3 – 3D レンダリング – フットボール選手の 3D 再構築 処理が完了すると、ScoreHMR モデルは、トラッキングされた人間の 3D メッシュ、ベクトルキーポイントデータ、トラッキングされたカメラポーズと方向、生成されたメッシュがオーバーレイされた動画ファイルなど、複数のファイルタイプを出力します。出力データは Amazon S3 バケットに保存され、SageMaker エンドポイントは Amazon SNS を使用してトピックを公開します。この場合、モデルの実行が成功すると Lambda 関数が呼び出され、DynamoDB テーブルのメタデータが出力データで更新されます。これにより、生成された 3D メッシュとキーポイントデータを任意の 3D アプリケーションで使用し、入力動画に映っている人間の動きを再現できるようになります。 ソリューション概要 図 4_AWS リファレンスアーキテクチャ スケーラブルなヒューマンメッシュリカバリパイプラインは、最先端の AI/ML 技術を活用して動画データから 3D ヒューマンポーズと形状を再構築します。このソリューションの中核では、3D ヒューマンメッシュリカバリにおける逆問題を解決するための最先端アプローチである Score-Guided Human Mesh Recovery (ScoreHMR) モデルを利用しています。AWS サーバーレスアーキテクチャ上に構築されたこのパイプラインは、AWS Lambda、Amazon S3、Amazon DynamoDB、Amazon SageMaker を含む様々な AWS サービスをシームレスに統合します。この強力な組み合わせにより、ソリューションは容易にスケールし、パフォーマンスや効率を損なうことなく任意の量の動画データを処理できます。 AWS Web Application Firewall (AWS WAF) は、アプリケーションを一般的な Web 攻撃やボットから保護し、可用性の低下、セキュリティ侵害、リソースの過剰消費を防ぎます。 Amazon Cognito は、ユーザーアクセス制御を追加し、サインインとサインアウトプロセスを処理します。サインインすると、ユーザーはバックエンドへのリクエストを行うことが承認されます。 Amazon API Gateway は、バックエンドアプリへのフロントドアとして機能するように設定されています。API は、データにアクセスするためのユーザーリクエストをルーティングします。 AWS Lambda は、リクエストパラメータに基づいてクエリをルーティングし、バックエンド操作を実行します。 Amazon S3 は、元動画と画像データを保存する取り込みデータソースとして使用されます。 新しいファイルが Amazon S3 にアップロードされると、イベント通知が Amazon SNS をトリガーして Lambda 呼び出しをキューに入れます。 Invoke SageMaker Endpoint Lambda 関数 がトリガーされ、Amazon SageMaker 非同期エンドポイントに推論リクエストを行います。 Amazon SageMaker AI は ScoreHMR モデルをホストし、非同期エンドポイントを使用して利用可能にします。SageMaker は AWS でこの AI モデルを実行するためのインフラストラクチャを管理します。 成功した場合、SageMaker エンドポイントは AWS Lambda を使用して成功メッセージを送信する Amazon SNS トピックを呼び出します。このシーケンスは、 モデル呼び出しの成功について Amazon DynamoDB のメタデータも更新します。 失敗した場合、SageMaker エンドポイントは AWS Lambda を使用してエラーメッセージを送信する Amazon SNS トピックを呼び出します。このシーケンスは、モデル呼び出しの失敗について Amazon DynamoDB のメタデータも更新します。 AWS Identity and Access Management (AWS IAM) は、AWS サービスとリソースへのアイデンティティ管理とアクセス制御を安全に行います。 Amazon CloudWatch は、リソースの監視、ログ記録、オブザーバビリティを提供します。 AWS X-Ray は、アプリケーション全体でトレースされたリクエストの全体像を提供します。 AWS サービスのスケーラビリティ、パフォーマンス、コスト効率性を活用することで、このスケーラブルなヒューマンメッシュリカバリパイプラインの実装は大規模な動画処理ワークロードを効率的に処理でき、正確な 3D ヒューマンメッシュリカバリを必要とする幅広いアプリケーションに適しています。 今後の可能性 画像や動画データから 3D ヒューマンを正確に生成する能力は、幅広い業界にわたって大きな可能性を秘めています。エンターテインメントとゲームにおいて、ヒューマンメッシュリカバリのスケーラブルなパイプラインは、ユーザー体験を向上させる現実的なヒューマンアニメーションの作成に使用できます。スポーツ分野では、このパイプラインは動きの詳細な 3D 表現を提供することで、コーチやトレーナーが改善すべき点を特定できるようにし、アスリートのトレーニングとパフォーマンス分析を大きく変える可能性があります。この技術は、トレーニング計画の最適化を支援し、アスリートのパフォーマンス向上と怪我の予防を実現します。応用範囲は、患者の動きの監視がリハビリテーションと遠隔ケアを支援できる医療などの領域にまでさらに広がります。 図 5 – 処理済み動画 – グループブレイクダンスの 3D 再構築 AWS クラウドサービスと ScoreHMR などの最先端 AI モデルの統合により、3D ヒューマンメッシュアニメーション用の堅牢な自動化ソリューションの作成が可能になります。最先端の AI 技術と AWS プラットフォームのスケーラビリティを融合した効率的なパイプラインにより、3D アニメーション制作の複雑なプロセスがよりアクセスしやすく効率的になります。この自動化パイプラインは、エンターテインメント、スポーツ、ファッションなど、人間の動作解析を必要とする多様な業界にとって非常に価値があることが証明できます。プロジェクトの範囲や複雑さに関係なく、ワークフローを最適化し、高品質でスケーラブルな結果を提供する可能性があります。 図 6 – 処理済み動画 – バスケットボール選手の 3D 再構築 独自の 3D ヒューマンメッシュアニメーションパイプラインを始める準備はできましたか？ Amazon SageMaker AI ドキュメント で非同期 AI ワークフローについて詳しく学び、 ScoreHMR リソース で今日からソリューションの構築を始めましょう！ 著者について Kellan Cartledge Kellan Cartledge は、AI/ML、生成 AI、クラウドインフラストラクチャ、リアルタイムグラフィックス、没入型 AR/VR 技術にわたる変革的ソリューションの設計と実装において 10 年以上の経験を持つ、AWS Prototyping and Cloud Engineering チームのシニアプロトタイピングアーキテクトです。Kellan は複雑な課題の解決と、新興技術で可能性の境界を押し広げるチームの支援に情熱を注いでいます。 翻訳はプロフェッショナルサービス小林知幾が担当しました。原文は こちら です。

本記事は 2025 年 4 月 1 日 に公開された「 Build an Immersive Virtual Reality Experience of Amazon Fulfillment Center Tour 」を翻訳したものです。 はじめに 倉庫効率、在庫計画、サプライチェーン管理の急速に進化する環境において、Amazon はフルフィルメントセンター (FC) モデルで革新を続けています。Amazon では、顧客の注文準備の背後にある人々、テクノロジー、プロセスを紹介するため、世界各地の選ばれた拠点で無料の対面およびバーチャルツアーを提供しています。Amazon Tour では、顧客がさまざまなタイプのロボットの動作を見て、それらがフルフィルメントプロセスをより効率的にする方法を説明できます。ロボットは、一緒に働く人々の歩く距離を短縮することで利益をもたらすだけでなく、より多くの在庫を保持し、注文をより迅速に処理できるようにすることで、顧客のショッピング体験も向上させます。従来のオンサイト FC ツアーは有益ですが、業界のパーソナライゼーション、リソースと対応能力の制約、スケーラビリティに制限があります。これらの課題に対処するため、私たちは Treedis と Matterport を使用した Amazon フルフィルメントセンターの没入型バーチャルリアリティ (VR) ツアーを展開し、24 時間 365 日の完全に没入型の体験を提供しています。主な目標は、最新の VR テクノロジーを活用して、FC のリアルで魅力的なバーチャルウォークスルーを顧客に提供することです。この技術ブログでは、プロジェクトの目的、ソリューションコンポーネント、および多様な業界の AWS 顧客が自社の運用に向けて没入型でインタラクティブな VR 体験を開発する手法について詳しく説明します。 目的 VR FC ツアープロジェクトには、Amazon がフィジカル AI と AWS サービスを使用して毎日数百万のパッケージを処理する方法を AWS のお客様に実証することを目的とした複数の観点の目標があります。このプロジェクトの包括的な目標は以下の通りです。 技術とプロセスの紹介 FC で使用される革新的なテクノロジーと AWS サービスを学べます。このバーチャルツアーは、Amazon が機械学習、コンピュータビジョン、ロボティクスを AWS サービスと統合して運用効率を達成する方法について、AWS 顧客に詳細な視点を提供します。 すべての AWS のお客様向けの Amazon FC ツアーのスケーリング AWS のお客様が Amazon FC の運用プロセスを理解できる、没入型でインタラクティブ、カスタマイズ可能なバーチャル環境を開発します。このバーチャル環境は、ユーザーを FC 運用の中心へと導き、複雑なプロセスとテクノロジーを直接体験できるようにします。FC ツアー体験をスケーリングすることで、多様な業界の AWS 顧客が自社の運用に対する貴重な洞察とインスピレーションを得ることができます。 新たなアイデアの創出 強化されたインタラクティブディスプレイ、業界固有のオーバーレイ、パーソナライズされたナレーションなどのソリューションの主要要素は、顧客に運用哲学、持続可能性イニシアチブ、Amazon FC の全体的な効果についてより深い理解を提供します。さらに、この没入型体験は顧客の間で新しいアイデアの生成を促進し、AWS サービスを使用して独自のビジネスニーズに合わせた予知保全、作業者トレーニングと安全ソリューション、倉庫自動化を構築するよう彼らにインスピレーションを与えます。 これらの目標を達成することで、VR FC ツアープロジェクトは Amazon の運用力を紹介し、AWS 顧客が自社の運用を再構想できるよう支援します。この革新的なアプローチは、AWS と物理 AI テクノロジーの力を活用した最先端ソリューションのコラボレーション、知識共有、探索を促進します。 ソリューション概要 このプロジェクトの構築において、私たちは AWS、Matterport、Treedis のテクノロジーを統合して、Amazon FC ツアーのエンドツーエンドの没入型バーチャルリアリティ体験を提供しました。以下では、各アーキテクチャコンポーネントについて詳しく説明します。 Amazon FC ツアー VR 体験のアーキテクチャ図 没入型体験の構築 没入型 VR FC ツアー体験を作成するため、私たちは Treedis ノーコードプラットフォームを活用し、カスタムブランドのデジタルツイン、ハイブリッド体験を作成し、バーチャル環境を簡単にナビゲートできるようにしました。コーディングの必要なく、ユーザーフレンドリーなソリューションを活用して、独自のバーチャル体験を構築しました。Treedis の高度なワークフロークリエーター「Flows」は、フルフィルメントセンターをステップバイステップのオンボーディングプロセスに変換し、ユーザーがガイド付きトレーニングフローを簡単に設計し、自分の裁量で特定の経路を探索できるようにしました。これにより、開発者以外でも重要な知識と専門知識を体験に貢献できるようになりました。 もう一つのノーコードソリューションである Digital Twin Studio により、私たちは FC 施設のデジタルツインモデルをシームレスな柔軟性でカスタマイズおよびレンダリングできました。 ナビゲーションタグ 機能は非常に重要で、ツアー内の特定の場所への経路を表示するバーチャルバブルを通じて自動ユーザーガイダンスを可能にしました。没入型体験をさらに向上させるため、私たちは 3D Editor を使用して、ビデオやワークフロー画像などの顧客メディアを組み込み、パッケージやロボットなどの 3D アセットを配置して FC 運用を実演しました。さらに、私たちはグリーンスクリーン機能を使用して、FC 運用の各段階をナレーションする実際の人物を統合し、バーチャル体験に本物のタッチを追加しました。 Treedis はまた、デジタルデバイスと VR デバイスの両方にすべての拡張機能を適用するパイプラインを構築し、将来の使用に向けて AR 対応を利用可能にして、あらゆるプラットフォームでシームレスで没入型の体験を保証しています。Treedis の強力なツールにより、私たちはデジタル世界と物理世界を融合し、施設の内部動作を詳しく見ることができる、非常にユニークで有益な VR FC ツアー体験を作成しました。Treedis サービスとサブスクリプションの詳細については、 AWS Marketplace をご覧ください。 3D モデリングとシミュレーション Amazon FC 施設の没入型で正確な表現を作成するため、私たちは Matterport の SaaS、3D カメラ、プロフェッショナルキャプチャーサービスの強力な機能を活用しました。これらのツールにより、物理空間をナビゲート可能で写実的、寸法的に正確なデジタルレプリカに変換できました。完全マネージド型ソリューションである Matterport Capture Services により、私たちは FC 施設の実物そっくりのデジタルツインを簡単にキャプチャできました。その後、これらのデジタルツインを Matterport の 3D データプラットフォームでホストし、SaaS ソリューションを利用してシームレスなアクセスと統合を保証しました。 Matterport API を活用して、私たちは Treedis システムをプログラムで接続し、Matterport プラットフォームでホストされている FC モデルへの直接アクセスを可能にしました。この統合により、高度に詳細で正確なデジタルレプリカを VR 体験に組み込むことができ、没入感と臨場感を向上させ、顧客の時間を節約し、約 1 マイルの歩行を不要にしました。Matterport のサービスとサブスクリプションオプションをさらに詳しく知りたい方は、直接お問い合わせいただくか、包括的な情報と価格詳細を見つけることができる AWS Marketplace をご覧ください。 アプリケーションホスティングとアクセス Amazon FC VR ツアーを探索するユーザーにシームレスでアクセス可能な体験を提供するため、私たちは React ベースのウェブサイトのホスティングに AWS Amplify を活用しています。アプリケーションは、バーチャル体験にアクセスするための VR とデスクトップブラウザ間の相互運用性体験を提供します。大規模な安全なアクセスとユーザー管理を提供するため、私たちはアプリケーションを顧客 ID とアクセス管理のための堅牢なソリューションである Amazon Cognito と統合しました。 生成 AI 統合 インタラクティブな VR 体験を作成するため、私たちはリモートコラボレーションと知識共有のために Amazon Bedrock を統合し、Treedis の VR 機能を追加で使用しました。バーチャル環境の Q&A ボットにより、顧客は FC プロセスに慣れ親しむことができます。Amazon Bedrock を搭載した Q&A ボットは、一般的な質問と詳細なプロセス情報の包括的なリポジトリでトレーニングされました。このトレーニングにより、ユーザーは自然言語を使用して質問でき、直感的で会話的な体験を保証します。このアプローチを通じて、私たちは没入型バーチャルツアーを提供するだけでなく、リアルタイムの知識共有とコラボレーションも促進しました。顧客はバーチャル FC 環境を探索しながら、同時に Q&A ボットと関わり、貴重な洞察を得て、その場で疑問を解決できました。 エンドユーザー体験 新規または既存の AWS 顧客、潜在的なパートナー、または物流の専門家を目指す方であっても、Amazon FC Tour VR 体験は FC 運用を変革するための印象的な洞察を得ることができ、大規模なフルフィルメントセンターを効率的に運営するための AWS サービスとフィジカル AI の役割を学ぶのに役立ちます。VR デバイスまたはワークステーションを使用して、施設運用のための複雑なプロセスとテクノロジーを明らかにできます。 Amazon FC ツアー VR 体験のエンドユーザー体験 まとめ Amazon フルフィルメントセンターバーチャルリアリティ体験プロジェクトは、顧客と組織が AWS とフィジカル AI を活用して倉庫効率を高めるための重要な一歩を表しています。この画期的な体験は re:Invent 2024 New to AWS Expo ブースで開始され、Treedis と Matterport も発表に参加し、顧客の関心を集め、さまざまな分野で同様のソリューションを活用する革新的なアイデアを生み出しました。作業者トレーニングソリューションの合理化とシームレスなサイト運用から、工場計画プロセス、予知保全、不動産マーケティングの加速まで、このテクノロジーの潜在的な応用は広大で広範囲に及びます。参加者からの圧倒的にポジティブな反応は、この VR 体験が業界全体で持つ変革的な影響を強調しました。Amazon フルフィルメントセンターのこの VR ツアーを直接体験することに興味がある場合は、 Experience Amazon Fulfillment Center (FC) Virtual Reality Experience リンクからお問い合わせください。特定の業界ニーズに合わせたカスタマイズされたソリューションを開発したい場合は、AWS Marketplace で Treedis と Matterport をご確認ください。 著者について Abhishek Srivastav Abhishek Srivastav は AWS のシニアソリューションアーキテクトです。顧客のクラウド導入加速を支援することに情熱を注いでいます。IoT 愛好家であり、NoSQL データベース、アナリティクス、AI/ML テクノロジーに深い専門知識を持っています。これらのテクノロジーの深い理解を活用して複雑な問題の答えを見つけることに情熱を注いでいます。AWS 入社前は、さまざまなエンタープライズ顧客で NoSQL Center of Excellence の主導的な役割を担っていました。 Johanna Albarran Johanna Albarran は Amazon Web Services のソリューションアーキテクトです。AWS での生成 AI と機械学習の活用において顧客をサポートすることに情熱を注いでいます。クラウドネイティブアーキテクチャの専門知識により、企業の規模拡大と運用の効率的な変革を支援する革新的なソリューションを設計できます。Johanna は San Diego State University で経営情報システム学の学士号を取得し、現在 Virginia Polytechnic Institute and State University (Virginia Tech) で情報技術の修士号を取得中です。 Gabriele Biagini Gabriele Biagini は Amazon Web Services のソリューションアーキテクトです。サーバーレステクノロジーと生成 AI を専門とし、革新的なイベント駆動アーキテクチャとクラウドネイティブソリューションを通じて組織のクラウド導入プロセスを加速することを支援しています。技術コミュニティへの積極的な貢献者として、実装パターンを定期的に共有し、技術カンファレンスで講演しています。AWS 入社前は、さまざまなテクノロジー企業でクラウドエンジニアリングチームを率いていました。 翻訳はプロフェッショナルサービス小林知幾が担当しました。原文は こちら です。

2025 年 12 月 2 日、Google、Moonshot AI、MiniMax AI、 Mistral AI 、NVIDIA、 OpenAI 、 Qwen のフルマネージドオープンウェイトモデルが Amazon Bedrock でさらに18種類の一般販売されることを発表しました。これには、新しい Mistral Large 3 および Mistral 3 の3B、8B、14B モデルが含まれます。 今回の発表により、Amazon Bedrock は 100 近くのサーバーレスモデルを提供し、主要な AI 企業による幅広く幅広いモデルを提供するようになりました。これにより、お客様は独自のニーズに最適な機能を正確に選択できます。AWS は、お客様のニーズと技術の進歩の両方を注意深くモニタリングすることで、お客様のニーズと技術進化に基づいて 厳選されたモデルのセレクション を定期的に拡大し、業界で定評のあるモデルに加えて、有望な新しいモデルも含めるようにしています。 この高性能で差別化されたモデルオファリングのこの継続的な拡大は、お客様が AI イノベーションの最前線に留まるのに役立ちます。Amazon Bedrock のこれらのモデルには、統合 API を通じてアクセスでき、アプリケーションを書き換えたり、インフラストラクチャを変更したりすることなく、新しいモデルを評価、切り替え、採用できます。 新しい Mistral AI モデル Amazon Bedrock では現在、次の 4 つの Mistral AI モデルがまず利用可能です。それぞれ異なるパフォーマンスとコスト要件に合わせて最適化されています: Mistral Large 3 — このオープンウェイトモデルは、ロングコンテキスト、マルチモーダル、および命令の信頼性を考慮して最適化されています。長い文書理解、エージェントとツールの使用ワークフロー、エンタープライズナレッジワーク、コーディング支援、数学やコーディングタスクなどの高度なワークロード、多言語分析と処理、ビジョンを備えたマルチモーダル推論に優れています。 Ministral 3 3B — Ministral 3 ファミリーの中で最小の製品で、強力な言語機能とビジョン機能を備え、シングル GPU デプロイ向けにエッジ最適化されています。画像キャプション、テキスト分類、リアルタイム翻訳、データ抽出、ショートコンテンツ生成、およびエッジデバイスや低リソースデバイスでの軽量リアルタイムアプリケーションにおいて優れたパフォーマンスを発揮します。 Ministral 3 8B — テキストとビジョン向けのクラス最高の Ministral 3 モデルは、シングル GPU デプロイ向けにエッジ最適化されており、高性能で設置面積が最小限に抑えられています。このモデルは、制約のある環境でのチャットインターフェイス、画像や文書の記述と理解、特化したエージェントのユースケース、ローカルシステムや組み込みシステムのバランスの取れたパフォーマンスに最適です。 Ministral 3 14B — 最も高性能な Ministral 3 モデルは、シングル GPU デプロイ用に最適化された最先端のテキストおよびビジョンパフォーマンスを提供します。高度な機能がハードウェアの実際の制約を満たしている場合には、高度なローカルエージェンシーのユースケースやプライベート AI のデプロイを使用できます。 その他のオープンウェイトモデルオプション これらのオープンウェイトモデルは、さまざまな業界の幅広いユースケースに使用できます。 モデルプロバイダー モデル名 内容 ユースケース Google Gemma 3 4B ラップトップ上でローカルに実行される効率的なテキストおよび画像モデル。デバイス上の AI アプリケーションの多言語サポート。 モバイルおよびエッジアプリケーション向けのオンデバイス AI、プライバシーに配慮したローカル推論、多言語チャットアシスタント、画像のキャプションと説明、軽量コンテンツ生成。 Gemma 3 12B ワークステーション用のバランスの取れたテキストと画像モデル。多言語を理解し、プライバシーに敏感なアプリケーションをローカルにデプロイできます。 ワークステーションベースの AI アプリケーション、企業向けのローカルデプロイ、多言語文書処理、画像分析、Q&A、プライバシーに準拠した AI アシスタント。 Gemma 3 27B エンタープライズアプリケーション向けの強力なテキストおよび画像モデル。多言語サポートによるローカルデプロイメントによるプライバシーと制御 エンタープライズローカルデプロイ、高性能マルチモーダルアプリケーション、高度な画像理解、多言語カスタマーサービス、データセンシティブ AI ワークフロー。 Moonshot AI Kimi K2 Thinking ツールを使いながら考える深層推論モデル。リサーチ、コーディング、および何百ものシーケンシャルアクションを必要とする複雑なワークフローを処理します。 計画、多段階ワークフロー、データ分析と計算、リサーチを伴う長文コンテンツの作成を必要とする複雑なコーディングプロジェクト。 MiniMax AI MiniMax M2 コーディングエージェントと自動化向けに構築されています。複数ファイルの編集、ターミナル操作、長いツール呼び出しチェーンの効率的な実行に優れています。 コーディングエージェントと統合開発環境 (IDE) の統合、マルチファイルコード編集、ターミナルオートメーションと DevOps、ロングチェーンツールオーケストレーション、エージェンティックソフトウェア開発。 Mistral AI Magistral Small 1.2 数学、コーディング、多言語タスク、マルチモーダル推論に優れ、効率的なローカルデプロイのためのビジョン機能を備えています。 数学とコーディングのタスク、多言語の分析と処理、そしてビジョンを備えたマルチモーダル推論。 Voxtral Mini 1.0 トランスクリプション、多言語サポート、Q&A、要約、関数呼び出しを備えた高度な音声理解モデル。 音声制御アプリケーション、高速音声テキスト変換、オフライン音声アシスタント。 Voxtral Small 1.0 クラス最高のテキストパフォーマンスを備えた最先端のオーディオ入力を搭載し、音声の書き起こし、翻訳、理解に優れています。 企業向け音声文字起こし、多言語カスタマーサービス、音声コンテンツ要約。 NVIDIA NVIDIA Nemotron Nano 2 9B ハイブリッドトランスフォーマー Mamba 設計の高効率 LLM は、推論とエージェントタスクに優れています。 推論、ツール呼び出し、数学、コーディング、指示の順守。 NVIDIA Nemotron Nano 2 VL 12B ビデオ理解とドキュメントインテリジェンスのための高度なマルチモーダル推論モデルで、検索拡張生成 (RAG) およびマルチモーダルエージェンティックアプリケーションを強化します。 複数の画像や動画の理解、視覚的な Q&A、要約。 OpenAI gpt-oss-safeguard-20b カスタムポリシーを適用するコンテンツ安全モデル。有害なコンテンツを、信頼と安全のワークフローを説明して分類します。 コンテンツモデレーションと安全性の分類、カスタムポリシーの適用、ユーザー生成コンテンツのフィルタリング、信頼と安全のワークフロー、および自動コンテンツトリアージを行います。 gpt-oss-safeguard-120b 複雑なモデレーションのための大規模コンテンツ安全性モデル。企業の信頼および安全性チームに詳細な理由を記載したカスタムポリシーを適用します。 大規模なエンタープライズコンテンツモデレーション、複雑なポリシーの解釈、多層的な安全性分類、規制遵守チェック、ハイステークスコンテンツレビュー。 Qwen Qwen3-Next-80B-A3B 超長文書向けのハイブリッドアテンションによる高速推論。RAG パイプライン、ツール使用、エージェンティックワークフローに最適化されており、迅速な対応が可能です。 長いドキュメントを含む RAG パイプライン、ツール呼び出しを伴うエージェンティックワークフロー、コード生成とソフトウェア開発、拡張コンテキストでのマルチターンの会話、多言語コンテンツ生成。 Qwen3-VL-235B-A22B 画像や動画を理解します。ドキュメントからテキストを抽出し、スクリーンショットを作業コードに変換し、インターフェイスのクリックを自動化します。 画像や PDF からのテキストの抽出、UI デザインやスクリーンショットの作業コードへの変換、アプリケーションでのクリックやナビゲーションの自動化、動画の分析と理解、チャートや図の読み込み。 公開されているモデルを実装する場合は、本番稼働環境でデータプライバシー要件を慎重に考慮し、出力のバイアスがないか確認して、データセキュリティ、 責任ある AI 、 モデル評価 の観点から結果をモニタリングしてください。 Amazon Bedrock の エンタープライズグレードのセキュリティ機能 にアクセスし、 Amazon Bedrock のガードレール を使用して、アプリケーション要件と責任ある AI ポリシーに合わせてカスタマイズされた安全策を実装できます。また、 Amazon Bedrock モデル評価ツール を使用してモデルを評価および比較し、ユースケースに最適なモデルを特定することもできます。 開始するには、 Amazon Bedrock コンソール のプレイグラウンドでいくつかのプロンプトを入力するだけで、これらのモデルをすばやくテストできます。また、任意の AWS SDK を使用して Bedrock InvokeModel および Converse API へのアクセスを組み込むこともできます。また、これらのモデルは、Amazon Bedrock をサポートする任意のエージェンティックフレームワークで使用でき、 Amazon Bedrock AgentCore と Strands Agents を利用してエージェントをデプロイできます。詳細については、「Amazon Bedrock ユーザーガイド」の「 AWS SDK を使用する Amazon Bedrock のコード例 」を参照してください。 今すぐご利用いただけます 新しいモデルの提供状況や今後の更新については、 全リージョンリスト を確認するか、 AWS Capabilities by Region の [AWS CloudFormation] リソースタブでモデル名を検索してください。詳細については、 Amazon Bedrock 製品ページ と、 Amazon Bedrock の料金ページ を参照してください。 Amazon Bedrock コンソール でこれらのモデルを今すぐお試しいただき、 AWS re:Post for Amazon Bedrock に、または AWS サポートの通常の連絡先を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

本ブログは 2025 年 2月 21 日に公開された AWS Public Sector ブログ「 NATO’s march to multi-domain operations: Transforming the alliance with hyperscale cloud 」を翻訳したものです。 脅威は今日も急速に進化し続けています。この状況に対抗するために、高度なテクノロジーソリューションを絶えず近代化することは NATO の 32 の加盟国すべてにとって急務となっており、同盟のデジタルトランスフォーメーションの戦略的重要性は 強まっています 。この近代化の取り組みには、優位性を維持するためのスピード、規模、セキュリティ、そしてグローバルなイノベーション能力が必要です。Amazon Web Services (AWS) のようなテクノロジーリーダーと協力することで、イノベーションを加速し、既知の脅威や新たな脅威に対抗するためのミッション対応ソリューションを提供する NATO の能力を高めることができます。 NATO のデジタルトランスフォーメーション実施戦略 は、同盟国同士が高度に接続されたクラウドベースのインフラストラクチャへと移行する方法を概説しています。2030 年までに、NATO は相互運用性、リアルタイム分析、データドリブンな意思決定を備えたマルチドメインオペレーション (MDO) 対応の同盟関係を構想しています。この変革は、脅威の軽減、意思決定の強化、 セキュアかつアジャイルで即応性に優れた同盟の維持 に寄与します。 物理的環境とサイバースペースの両方にわたって MDO を実施し、敵対勢力に対する技術的優位性を維持する NATO の能力には、ハイパースケールクラウドコンピューティングが必要です。この複雑な状況で成功するには、膨大な量のデータを管理し、分析を適用し、迅速に意思決定を行うための、高度な人工知能 (AI) と機械学習 (ML) テクノロジーが不可欠です。 次世代の防衛 地政学的状況の変化を背景に、NATO 加盟国間の足並みを揃えることがこれまで以上に重要になっています。情報システムと、それらに関連するすべての標準とポリシーは、あらゆる環境、あらゆる機密区分において、常に相互運用可能で安全でなければなりません。そして、予測不可能な需要に対応するために柔軟にスケールできるインフラストラクチャによって支えられている必要があります。 政府機関のお客様から信頼をいただいているクラウドである AWS は、政府機関向けに最も包括的で、信頼性が高く、安全で、目的に特化したクラウド機能を提供しています。当社のコアインフラストラクチャは、軍、情報機関、民間機関、そして NATO のような高度な機密性を持つ組織のミッションの達成と厳格な要件の充足を支援するために構築されています。現在、AWS は、世界で 7,500 を超える政府機関における最重要ミッションの遂行、レガシー IT のモダナイズ、変革の加速、市民向けサービス提供の革新を支えています。 NATO の目標達成を支える AWS は、AI、ML、分析、シミュレーションなどの高度なクラウド機能を費用対効果の高い方法で使用することにより、NATO の最も差し迫った課題に対処するソリューションを構築しています。例えば、AWS と選定されたパートナーは、 NATO Edge Conference でシニアリーダーと会談し、NATO のデジタルトランスフォーメーションを支援し、適切なスピードでのデータドリブンな意思決定を可能にする最新のイノベーションとテクノロジーを紹介しました。 当社は、ハイパースケールクラウドが組織のミッション成功の実現にどのように役立つかをより深く理解するために、NATO と積極的に連携しています。過去 1 年間、AWS はヨーロッパで 3 つの戦略的イベントを共催し、NATO が新興テクノロジーを活用して同盟の能力を強化する際に抱く期待と直面する課題について、直接話を聞きました。Aspen Strategy Group、 Concordia 、 Atlantic Council とのこれらのイベントは、NATO のミッションとクラウド要件、そして AWS がそれらの達成をどのように支援できるかを議論するプラットフォームを提供しました。 NATO のための高度なクラウド機能 AWS は NATO と連携し、そのデジタルトランスフォーメーション目標を推進するクラウド機能を提供すると同時に、欧州の防衛関連企業やイノベーターによる同盟向けの能力近代化を支援しています。防衛分野での豊富な経験を持つ主要なクラウドプロバイダーとして、AWS は NATO がレジリエンシー、セキュリティ、相互運用性、強化されたコラボレーションの要件を満たすことを支援することに尽力しています。これらの機能は、NATO の 変革戦略 と直接的に整合しています。 回復性（レジリエンシー）: 同盟国は、ハードウェア障害、自然災害、サイバー攻撃、その他の中断に直面した場合でも、ミッションシステムとデータが常にアクセス可能で運用可能であることを確保する必要があります。AWS は、すべてのクラウドプロバイダーの中で最高のネットワーク可用性を提供し、すべてのリージョンで 3 つ以上のアベイラビリティーゾーン (AZ) を提供する唯一のクラウドプロバイダーであり、より高い冗長性と問題を封じ込めるためのより優れた分離を実現しています。 セキュリティ: AWS クラウドは、同盟国がスピードと自信を持って運用できるようにする実証済みのセキュリティ機能を提供します。最も安全なクラウドコンピューティング環境となるように設計されたインフラストラクチャを通じて、同盟国は重要な資産に対する堅牢な保護を獲得します。セキュリティの自動化により、人的エラーが削減され、防御の有効性が最大化されます。また、組み込みのセキュリティコントロールとガイダンスにより、同盟国は包括的なエンドツーエンドの保護対策を実装できます。これらの機能は、機密データとシステムの保護を支援し、より安全なミッション機能の迅速な展開を可能にします。 相互運用性: AWS クラウドは、標準化されたインターフェイスと共通のプラットフォームを通じて NATO 加盟国間のシームレスな通信を可能にし、同盟国間の情報共有と運用統合を合理化します。 強化されたコラボレーション: クラウドベースのプラットフォームは、NATO 加盟国間での共同計画と MDO を可能にし、より迅速で協調的な同盟国の対応を促進する安全な脅威インテリジェンス共有を実現します。共有データリポジトリと通信プラットフォームにより、同盟国は同じリアルタイム情報にアクセスでき、新たな脅威への対応における意思決定を加速できます。 ミッションスピードでの前進 AWS は、国家安全保障と防衛のお客様への支援において揺るぎない姿勢を持ち、安全でミッションクリティカルな運用を支える実証済みの機能を提供しています。今日の変化する安全保障環境において、NATO のデジタルトランスフォーメーションは、集団的抑止と防衛を通じてグローバルな安定性を維持するために不可欠です。AWS は、ミッション成功のためのイノベーションを支援し、NATO のデジタルトランスフォーメーションを加速する準備ができています。 関連情報 Trusted Secure Enclaves on AWS で国家安全保障と防衛任務のデータを保護する方法 AWS 活用で実現する同盟国間の防衛機密情報と技術共有 IdentityE2E Seamless Migration of NATO School Oberammergau (NSO) Website to AWS LZA Platform NATO’s Deputy Secretary General visits Amazon’s Development Centre in Iași, Romania 執筆協力: Chris Bailey, GM, global national security and defense, AWS Worldwide Public Sector 著者について David Appel David Appel は、AWS のグローバル政府、国家安全保障、防衛ビジネスを統括しています。彼とそのチームは、お客様がテクノロジーの可能性を実現し、組織を変革してミッションを達成できるよう支援しています。この役割において、彼はお客様のクラウド導入の取り組みに伴走し、最先端のテクノロジーを活用することで、エンドユーザーに効率性と迅速性をもたらす能力向上を実現します。David は、プログラムリーダーシップ、ビジネスオペレーション、財務、ビジネス開発、戦略的計画において幅広い経験を持っています。 このブログは WWPS Proposal Writer 中村昌幸が翻訳しました。

本記事は、” Achieve a high-speed InnoDB purge on Amazon RDS for MySQL and Amazon Aurora MySQL ”  を翻訳したものです。 パージ は、MySQL データベースにおけるハウスキーピング操作です。InnoDB ストレージエンジンは、 マルチバージョン同時実行制御 (MVCC) やロールバック操作のために不要となった、 undo ログ や削除マークの付いたテーブルレコードのクリーンアップを、この操作に依存しています。私たちのアプリケーションは、元より最高の書き込みスループットを提供することを目的としたデータベース設計を追求していますが、同様にパージがバックグラウンドでタイムリーに実行できることを確認することも重要です。大量のデータ変更とパージの進行のバランスが崩れると、データベースのパフォーマンスが低下する可能性があります。 この投稿では、 Amazon Relational Database Service (Amazon RDS) for MySQL DB インスタンス、及び Amazon Aurora MySQL 互換エディション DB クラスターにおける、高速なパージのための一連の設計およびチューニング戦略の概要を説明します。まず、MySQL データベースの内部構造について私たちの理解を活用して、パージの仕組みを簡単に紹介します。次に、パージの課題となる一般的な要因と、使用できる最適化手法について説明します。この記事は MySQL 8.0 に基づいており、ほとんどの推奨事項は一般的な MySQL データベースに適用可能です。また、Amazon マネージドデータベースサービスに特有の考慮事項も示します。 パージの仕組みを理解する 他の多くの主流のリレーショナルデータベース管理システム (RDBMS) と同様に、MySQL は MVCC を実装して、データにアクセスするための読み取りと書き込みの同時操作を可能にしています。MVCC の核となる考え方は、トランザクションによってテーブルレコードが更新されたときに、データベースエンジンにテーブル内の新しいバージョンのデータを作成させることです。古いデータのバージョンは物理的には削除されず、削除済みとマークされます。クエリは望ましい分離レベルで、適切なデータバージョンを選択してデータベースの独自のビューを構築できます。そうすることの大きな利点は、読み取りと書き込み間でのブロッキングが発生する状況を回避することです。読み取りは常に古いデータバージョンにアクセスできますが、書き込みは新しいバージョンで実行されます。テーブルレコードの複数のバージョンを保持できるので、データベースエンジンがトランザクション内またはクラッシュリカバリ中にロールバック操作を実行することも容易になります。 スケーラブルなソリューションとして、MVCC には固有の制約があります。削除マークが付いたテーブルレコードはガベージコレクションにより処理される必要があるということです。さまざまなデータベースエンジンに、独自のバージョントラッキングとガベージコレクションメカニズムが備わっています。一般的な課題は、大量のトランザクションにより古いデータバージョンが速く生成され過ぎ、ガベージコレクションが追いつけない場合です。その結果、テーブル構造に古いデータバージョンが大量のバックログとして蓄積されることがあります。表面的には、これはスペース使用量の予想外の増加を直接引き起こします。その裏で、古いバージョンをチェックして読み取り操作を実行するには、追加の I/O 操作を行う必要があります。この I/O 消費量の増加は、システムリソースを奪い合い、データベース全体のパフォーマンスを低下させる可能性があります。 MySQL データベースでは、InnoDB は MVCC とロールバック操作をサポートするための主要なデータ構造として undo ログを使用します。テーブルレコードが変更されると、古いデータバージョンは undo ログに保存されます。同じテーブルレコードに関連するすべての undo ログはリンクされ、バージョンチェーンを形成します。その裏返しとして、パージはガベージコレクションのことです。undo ログだけでなく、それらが参照する削除マークの付いたテーブルレコードもクリーンアップします。本質的に、パージは InnoDB トランザクションシステムの不可欠な部分と見なされます。 次のグラフは、InnoDB パージの高レベルの設計アイデアと 3 段階のワークフローを示しています。 トランザクションが開始されると、 ロールバックセグメント が割り当てられます。ロールバックセグメントは、 undo テーブルスペース 内の多数の undo ログページで構成されます。テーブルレコードが保存されるデータページのように、undo ログページを読み書きするには InnoDB バッファプールにロードする必要があります。 トランザクションによってテーブルデータが変更されると、undo ログレコードが作成されます。undo ログレコードには、テーブル ID、クラスタ化インデックス、変更前の古いデータバージョンなど、テーブルレコードに行われた変更をロールバックするために必要な関連情報が含まれています。INSERT、DELETE、UPDATEステートメント用に、異なる種類の undo ログレコードがあります。後でパージする必要があるかどうかに応じて、それらは別々の undo ログにグループ化されます。 コミット中、トランザクションはトランザクションシリアル番号 (trx_no) を取得し、それを undo ログに書き込みます。パージする必要のある undo ログが存在する場合、それらは trx_no 順に並べられた ロールバックセグメント履歴リスト に追加されます。InnoDB トランザクションシステムは trx_no を使用して、コミットされたすべてのトランザクションの順序を追跡します。その意味では、履歴リストはデータベース全体でグローバルなリストです。 パージはマルチスレッド操作です。パージスレッドの数は、 innodb_purge_threads を使用して設定されます。通常、1 つのパージコーディネーターといくつかのワーカースレッドが存在します。これらのスレッドは、3 つのステップを含むパージ操作を継続的に繰り返します。 パージコーディネータースレッドは、パージできる undo ログがあるかどうかをチェックします。そのような undo ログが見つかったらひとまとめに取り出し、undo レコードを解析して、テーブル ID でソートします。次に、処理を行うため各グループをワーカースレッドに割り当てます。 パージワーカースレッドは、undo ログレコードをテーブル ID ごとに並行して処理します。undo ログレコード中の情報を使用して、クラスタ化インデックス、セカンダリインデックス、BLOB 列など、削除マークの付いたレコードを識別して削除します。クリーンアップ後にデータページ内のデータが少なすぎる場合は、ストレージを最適化するために別のページにマージされます。 いくつかの undo ログのまとまった単位が処理された後、パージコーディネータスレッドはそれらをロールバックセグメント履歴リストから削除して、ロールバックセグメントを解放します。MySQLには、undo テーブルスペースを自動的に切り捨てる innodb_undo_log_truncate というオプションが用意されています。これは、undo テーブルスペースが innodb_max_undo_log_size で指定されたサイズ制限を超え、内部に含まれるすべてのロールバックセグメントが解放されたときに、物理ストレージスペースを縮小するためのものです。このステップが完了すると、パージコーディネータースレッドは別のパージサイクルを開始します。 undo テーブルスペースの自動切り捨てオプションは、Aurora MySQL 互換 バージョン 3.06.0 以降で使用できます。 読み取りと書き込みのワークロードのバランスを取る トランザクションがレコードを変更するために INSERT、DELETE、UPDATEなどのデータ操作言語 (DML) ステートメントを使用するとき、InnoDB は異なる種類の undo ログレコードを作成します。ただし、すべての種類の undo ログレコードをパージする必要はありません。INSERT ステートメントにより生成された undo ログには古いデータバージョンが含まれていないため、トランザクションがコミットされた直後に削除され、ロールバックセグメント履歴リストには追加されません。 DELETE 及び UPDATE ステートメントによって生成された undo ログレコードには、テーブルレコードが削除または更新される前の古いデータバージョンが保存されているため、パージ操作の対象となります。他の並行した SELECT クエリやオープントランザクションは、MVCC の目的で 一貫した読み取り を構築するために、それらにアクセスする必要があるかもしれません。InnoDB は、アクティブなクエリとトランザクションのために undo ログの可視性を追跡するメカニズムとして、 読み取りビュー を使用しています。また、パージコーディネータースレッドが undo ログを安全に削除できるかどうかを判断するためにも使用されます。 undo ログの作成と使用の両方を行うデータベースワークロードは、パージスレッドの動作に直接影響します。undo ログは、ロールバックセグメント履歴リストから trx_no の昇順で削除されます。undo ログをパージできない場合、trx_no が大きい他の undo ログは、別のテーブルに属していてもパージされなくなります。つまり、パージはデータベース全体でグローバルな操作であり、1 つの長時間実行されたクエリまたはトランザクションにより、それより後に開始された全てのトランザクションの undo レコードのクリーンアップがブロックされます。パージが常に懸念事項となる MySQL データベースでは、データベースワークロードのタイミング、同時実行性、およびトランザクション特性を確認することをお勧めします。 1つの戦略は、DELETE よりも DROP PARTITION または DROP TABLE ステートメントを選択することです。これらのステートメントは undo ログを生成しないからです。次の図に示すように、DROP PARTITION を使用してデータのサブセットを削除できるようにテーブルをパーティション化すれば、パージを回避できます。テーブルから大量のデータを削除したい場合は、新しいテーブルを作成し、データをコピーして、古いテーブルを削除するという方法をいつも検討する価値があります。 もう 1 つの戦略は、大量の DELETE または UPDATE ステートメントが実行されている間、読み取りビューが undo ログを保持しパージをブロックする可能性がある、長時間実行される SELECT クエリを避けることです。 max_execution_time を使用して最大制限時間を設定することで、実行時間が長すぎる SELECT クエリを自動的に停止できます。トランザクションの分離レベルを、 REPEATABLE READ から READ COMMITTED に切り替えることもできます。これにより、SQL ステートメントによって作成される読み取りビューの範囲が狭まり、undo ログのパージがブロックされる可能性が低くなります。 Aurora MySQL は、1 つ以上の DB インスタンスで構成されるクラスター化されたデータベースであり、すべての DB インスタンスが同じ共有されたクラスターストレージボリュームを使用します。InnoDB のパージの実装は、そのクラスタリングトポロジーの影響を受けます。Aurora MySQL DB クラスターを使用する場合、Amazon RDS for MySQL DB インスタンスと比較すると、次のような違いがあります。 パージがデータベース全体のグローバルな操作であるという概念は、Aurora MySQL のデータベースアーキテクチャ全体で一貫しています。パージはプライマリ (ライター) DB インスタンスで実行されます。ただし、Auroraレプリカ DB インスタンス上の SELECT クエリが読み取りビューを作成するため、パージがブロックされる可能性があります。 Aurora Global Database においても、セカンダリ DB クラスター上の SELECT クエリがプライマリ DB クラスターのパージをブロックする可能性があります。 Aurora レプリカ DB インスタンスでは、 READ COMMITTED 分離レベルは、長時間実行される SELECT クエリがパージスレッドに与える影響を軽減するように最適化されており、Aurora MySQL 固有の動作をします。クエリの結果は、プライマリDBインスタンスで MySQL のネイティブの READ COMMITTED レベルを使用する場合とは少し異なる場合がありますが、それでも ANSI SQL 標準に準拠しています。この機能を有効にするには、DBクラスターパラメータグループ、またはセッションレベルで aurora_read_replica_read_committed を ON に設定します。 テーブルとインデックスの構造を最適化する undo ログに加えて、InnoDB テーブルで削除済みとマークされたテーブルレコードもパージ操作の対象になります。一般的な意味では、テーブルレコードとは、クラスター化インデックス、セカンダリインデックス、 InnoDB の行フォーマット に従って外部に保存された可変長列など、テーブルの行データを格納または示すさまざまなデータ構造を参照します。undo ログレコードにはテーブル ID とクラスタ化インデックスしか含まれていないため、パージスレッドは削除マークの付いた他の関連するテーブルレコードを識別し、存在する場合は削除する必要があります。これは、パージ操作で最も負荷の高い部分になる可能性があります。 セカンダリインデックスがパージ操作に与える影響の例を考えましょう。次のグラフは、2 つの Aurora MySQL DB クラスターの Amazon CloudWatch メトリック RollbackSegmentHistoryListLength を比較しています。どちらのクラスターにも r7g.2xlarge プライマリ (ライター) DB インスタンスがあり、 Sysbench の oltp_write_only.lua prepare ワークロードを使用して 80 GB のデータを含む 1 つのテーブルをロードします。1 つのクラスター (クラスターA) では、 oltp_update_non_index.lua ワークロードを実行して、セカンダリインデックスでカバーされていない列を更新します。他のクラスター (クラスターB) では、 oltp_update_index.lua ワークロードを実行して、その上にセカンダリインデックスが構築されている列を更新します。どちらの Sysbench ワークロードも、 --rate を使用して同じレートでトランザクションを生成します。 次のことを観察できます。 DMLThroughput は両方のクラスターで同じパターンを示し、同じ数の UPDATE ステートメントを実行していることを示しています。 oltp_update_index.lua ワークロードを実行するクラスターでは、 RollbackSegmentHistoryListLength がピーク時に 300 万を超えます。しかし、他のクラスターではゼロに近いままです。これは、セカンダリインデックスを含むundo ログを処理すると、パージスレッドが大幅に遅くなる可能性があることを示しています。セカンダリインデックスの使用は必ずしも問題ではありません。両方のクラスターのテーブル構造は同じで、どちらのテーブルにもセカンダリインデックスがあります。セカンダリインデックスは、データベースのワークロードによって変更された場合にのみ、パージスレッドに課題をもたらします。 11:52 の縦線は、クラスター B のセカンダリインデックスをいつ削除したかを示しています。セカンダリインデックスを削除すると、パージによりセカンダリインデックスのレコードを検索してクリーンアップする必要がなくなるため、パージ操作がすぐにスピードアップします。セカンダリインデックスを削除してから数分で RollbackSegmentHistoryListLength がゼロに下がることがわかります。SYS スキーマの schema_unused_indexes ビューを使用して、使用されていないセカンダリインデックスを特定し、必要かどうかを評価できます。 MySQL 8.0 以降、パージワーカースレッドは、削除マークの付いたテーブルレコードをクリーンアップするために、異なるテーブルで並行して動作するように設計されています。並列処理の効率は、いくつかの要因によって決まります。次のグラフは、パージワーカースレッドの数と、パージされるのを待機している undo ログを保持するテーブルの数との相関関係の例を示しています。 データは、前の 2つの Aurora MySQL DB クラスターでの別のテストから収集されました。1 つのクラスター (クラスターB) は 80 GB のデータを持つ 1 つのテーブルを引き続き使用し、もう 1 つのクラスター (クラスターA) は合計 80 GB のデータを、それぞれ 8 GB のデータを持つ 10 個のテーブルに分散させています。どちらのクラスターも Sysbench oltp_update_index.lua ワークロードを実行し、 --rate を使用して同じレートでトランザクションを生成します。両方のクラスターの DB インスタンスは r7g.2xlarge なので、 innodb_purge_threads はデフォルトで 3 に設定されています。つまり、2 つのパージワーカースレッド (及びパージコーディネーター) を同時に実行できます。 次のことを観察できます。 DMLThroughput は両方のクラスターで同じパターンを示し、同じ数の UPDATE ステートメントを実行していることを示しています。 RollbackSegmentHistoryListLength は、1 つのテーブルがロードされたクラスター A では 300 万ですが、10個のテーブルを持つクラスター B ではピーク時に約 50 万に達します。パージ速度が速いのは、2 つのワーカースレッドが並行して動作することと、作業する各ワーカースレッドにとってテーブルサイズが小さいことの 2 つの要因によるものです。一度に 1 つのテーブルを消去できるワーカースレッドは1つだけです。並列処理を最大限に活用するには、パージワーカースレッドよりも多いか同数のテーブルに対し、データ変更を均等に分散するのが理想的です。 innodb_purge_threads は、パージ操作のスピードに影響する要因です。他の要因が作用している場合、パージスレッドをスピードアップするのに役立つかもしれません。 適切なインスタンスクラスを選択する 設計上、パージは非干渉的です。パージスレッドはバックグラウンドで実行され、ユーザートランザクションとは非同期に動作します。妥当な遅延時間でジョブを終わらせるために、システムリソースの消費を最小限に抑えることが期待されています。MySQL では、 innodb_purge_threads の最大値を 32 と定義しています。つまり、MySQL データベースには最大 32 のパージスレッドを設定できます。このような設定は、負荷の高い本番データベースに何千ものユーザー接続を同時に許可する max_connections と比較して、パージスレッドに競争上の優位性をもたらすことを意図したものではありません。 パージスレッドが undo ログや削除マークの付いたテーブルレコードを処理する際、undo ログページと InnoDB バッファプールのデータページからデータを読み取る必要があります。それらのデータページがバッファプールに存在しない場合は、I/O コールを発行してストレージから取得します。RDS DB インスタンスの CPU、メモリ、IO 帯域幅などのシステムリソースが、パージ操作の速度に大きな影響を与える可能性があります。 高速なパージ操作には、パージスレッドだけでなく、データベース全体のワークロードについてもキャパシティプランニングが必要です。リソースが不足している、またはユーザートランザクションによるシステムリソースの使用率が高い DB インスタンスでは、リソースの競合によりパージスレッドが遅くなり、パージの遅延が予期せず現れることがあります。次のグラフは、この状況の例を示すために、r7g.2xlarge のプライマリ (ライター) DB インスタンスを持つ Aurora MySQL DB クラスターで実施したテストの結果です。 テストは、2 つの異なる Sysbench データセットを順番にロードすることから始まります。まず、クラスターにはそれぞれ 8 GB のデータを含む 10 個の Sysbench テーブルがロードされ、次に、34 GB のデータの別のテーブルがロードされます。データをロードした後、テストは 34 GB のテーブルに対して oltp_read_only.lua ワークロードを実行します。 innodb_buffer_pool_size はデフォルトで 42 GB に設定されているため、この 34 GB のテーブルデータは InnoDB バッファプールに完全にキャッシュされます。同時に、他の 10 個のテーブルのほとんどのデータはバッファプールから削除されます。読み取り専用ワークロードが完了する前に、テストは他の 10 個のテーブルで oltp_update_index.lua ワークロードを開始します。 次のことを観察できます。 SelectThroughput と DMLThroughput は、2つの異なるタイプのワークロードが、自身のデータセットをロードするために InnoDB バッファプールをめぐって競合していることを示しています。 oltp_update_index.lua ワークロードの終了時、 RollbackSegmentHistoryListLength が 500 万を超えました。これは前のテストと比較すると想定外です。そのテストでは、10 個のテーブルで同じ oltp_update_index.lua ワークロードをより高いレート ( 1 万 5 千対 1 万) で実行したところ、 RollbackSegmentHistoryListLength は約 50 万でした。 oltp_update_index.lua ワークロードが開始されると、バッファプールの競合が原因で、 BufferCacheHitRatio が急激に低下します。ワークロードが完了した後も低いままです。これは、パージスレッドが undo ログやテーブルレコードをバッファプールに取り込むときに、I/O パスでボトルネックになっていることを示しています。 InnoDB バッファプールへの適切なメモリ割り当ては、パージ操作の速度に大きな影響を与える可能性があります。必要な undo ログやテーブルデータがバッファプールにない場合、パージスレッドのパフォーマンスは IO レイテンシーと相関します。 MySQL データベースでは、 innodb_purge_threads パラメーターを変更することで、パージスレッドの数を設定できます。RDS for MySQL を使用する場合、MySQL コミュニティエディションと同じくデフォルト値は 1 で、DB パラメータグループで変更できます。Aurora MySQL を使用する場合、デフォルトは、DB インスタンスのサイズが大きくなるにつれて増加し、 DB クラスターパラメータグループ で変更できます。次の表は、r7g インスタンス~タイプのデフォルト式に基づいた、パージ関連の設定の有効値を示しています。 RDS インスタンスタイプ vCPU メモリ (GiB) innodb_buffer_pool_size (GiB) innodb_purge_threads innodb_purge_batch_size db.r7g.large 2 16 7.76 1 600 db.r7g.xlarge 4 32 19.36 1 600 db.r7g.2xlarge 8 64 42.59 3 1800 db.r7g.4xlarge 16 128 89.11 3 1800 db.r7g.8xlarge 32 256 182.06 6 3600 db.r7g.12xlarge 48 384 275.11 12 7200 db.r7g.16xlarge 64 512 368.13 12 20000 Aurora Serverless V2 インスタンスタイプでは、この設定はインスタンスのスケールアップまたはスケールダウン時に自動的に設定され、パラメータグループでは変更できません。 監視とアラーム InnoDB のパージを監視するためのよく知られたメトリックは、パージラグとも呼ばれるロールバックセグメント履歴リストの長さです。これは、パージされるのを待機している undo ログの数を示します。MySQL データベースでは、 SHOW ENGINE INNODB STATUS を実行して、 History list length を直接確認できます。Aurora MySQL は、すべての 3.0 リリースで RollbackSegmentHistoryListLength を CloudWatch メトリックとして提供しています。Amazon RDS for MySQL では、 Performance Insights にて trx_rseg_history_len というメトリックを提供しており、それを CloudWatch に公開 できます。 パージラグがはるかに遅れ、データベースのパフォーマンス上の問題を引き起こす可能性がある状況を検出するために、このメトリックに CloudWatch アラーム を設定することをお勧めします。アラームのしきい値は、データベースがこれまでに到達した過去の正常値と、アラームがトリガーされたときに取るアクション項目に基づいて設定できます。 データベースワークロードによって、パージスレッドが十分に速く処理仕切れないほどの undo ログが生成され、パージラグが増加していることに気付いた場合は、データベースインスタンスのサイズを増やして、パージスレッドに割り当てるシステムリソースを確保してください。または、 データベースシャーディング アーキテクチャを使用して、複数のデータベースシャードにワークロードを分散することもできます。MySQLには、ロールバックセグメント履歴リストの長さの閾値を設定するための innodb_max_purge_lag も用意されています。違反すると、INSERT、DELETE、UPDATE ステートメントに対し内部のスロットリングが開始され、最大 innodb_max_purge_lag_delay までの遅延が発生します。これらのオプションをテストして、どれが自分のユースケースに最適かを確認できます。 まとめ InnoDB のパージ効率を向上させるには、ワークロードの最適化、データベースのキャパシティプランニング、および設定を組み合わせる必要があります。この記事では、RDS for MySQL DB インスタンス、Aurora MySQL DB クラスター、またはその他の種類の MySQL データベースでそれを実行するために役立つガイドラインを提供します。 著者について Lei Zeng は AWS のデータベースエンジニアです。 本記事の翻訳はクラウドサポートエンジニアの野沢が担当しました。

本稿は、2024 年 11 月 7 日に公開された “ Securing PartyRock: How we protect Amazon Bedrock endpoints using AWS WAF ” を翻訳したものです。 PartyRock は、 Amazon Bedrock をベースとした直感的で実践的な生成 AI アプリ構築プレイグラウンドです。それは、ユーザーが生成 AI テクノロジーを実験でき、 クイズジェネレーター や レジュメオプティマイザー などコーディングなしで楽しいアプリケーションを構築できます。無料のオンライン生成 AI プレイグラウンドを開発者に提供することは非常に大きな価値があることですが、それは重要なセキュリティ面での課題も存在します。 この投稿では、 AWS WAF を利用して分散型サービス拒否 (DDoS) 攻撃や Wallet 拒否攻撃 (DoW) のような潜在的な脅威から PartyRock を保護した方法を探求します。また、オンラインアプリケーションに生成 AI 機能をインテグレーションしている開発者は、同様の脅威からそのアプリケーションを保護する具体的な AWS WAF の基本テクニックについて学ぶことができます。 セキュリティの課題 ここで述べている 2 つの脅威は、私たちの無料の生成 AI プレイグラウンドの機能やユーザー体験に影響を与えます。 分散型サービス拒否 (DDoS) 攻撃 : DDoS 攻撃は、大量のトラフィックであなたのリソースを圧倒して、あなたのサービスをオフラインにする可能性があります。PartyRock は評価を落とし、その可用性を損なう、評判を傷つける、または身代金を要求しようとする攻撃者によって標的にされる可能性があります。 サービス悪用: 悪意のある攻撃者が、汎用的な生成 AI のコンピュート能力の転売など意図されていない目的でプラットフォームを悪用しようと試みる可能性があります。攻撃者は、PartyRock 上で大量のアプリ実行を生成することにより、私たちのユースケースにおいてクラウドサービスのリソース自動スケーリング機能(クラウドの弾力性)を悪用します。PartyRock での平均的なアプリ実行では、Bedrock 上の Anthropic Sonnet 3 モデルを使用して 2000 個の入力トークンと 400 個の出力トークンを消費するため、1000 回のアプリ実行ごとに約 12 ドルのコストがかかります。アプリ実行の悪用を放置すると、予期しない、そして潜在的に重大なクラウド請求が発生する DoW (Wallet 拒否攻撃)につながり、悪意のある攻撃者がクラウドの柔軟性を PartyRock に対して悪用することを可能にしてしまいます。 これらの課題に対処するため、私たちは最初から堅牢なセキュリティ制御を実装し、AWS WAF が私たちの防御戦略において中心的な役割を果たしています。 PartyRock のサーバーレスアーキテクチャ セキュリティ対策について詳しく説明する前に、 AWS Cloud Development Kit (AWS CDK) を使用してデプロイした PartyRock のサーバーレスアーキテクチャを確認します。 Amazon CloudFront : PartyRock のエントリーポイントとして機能し、キャッシュとダイナミック API コールの高速化を通じて、より良いユーザー体験を提供します。CloudFront エッジにおいて、Bot Control ルールなどの AWS WAF による保護を実装しています。 Amazon S3 : PartyRock の静的フロントエンドをホストします。 AWS Lambda : Amazon Cognito や Bedrock などの他のインフラストラクチャコンポーネントと統合し、アプリケーションロジックを実行することで、私たちの React アプリケーションと API を動作させています。レイテンシとコストを削減するため、CloudFront 経由で Lambda 関数を利用可能にしています。Lambda URL を直接 CloudFront のオリジンとして設定しています。私たちのケースでは、API は通常 API ゲートウェイが提供する高度な機能を必要としないため、必要な構成要素を少なくしてアーキテクチャをシンプルに保つことができ、より安価で高速にすることが可能です。さらに、 CloudFront ディストリビューションのみが Lambda URL と通信できるよう、CloudFront の機能である Origin Access Control を使用して Lambda URL を設定しています。Bedrock とのインターフェースを担当する Lambda 関数は、Bedrock のレスポンスをユーザーにストリーミングで返すため、レスポンスストリーミングで設定されています。 Amazon Cognito : Google、Amazon、Apple などのソーシャルアイデンティティプロバイダーを通じてユーザー認証を管理します。 Amazon Aurora Serverless : PostgreSQL データベースとして機能し、豊富な機能と自動スケーリングを提供します。Amazon Aurora Serverless はオンデマンド型のマネージドデータベースで、重い作業を軽減し、機能に集中して迅速に反復開発することを可能にします。 Amazon CloudWatch RUM : クライアントサイドのパフォーマンスとエラーを分析します。 図 1 : PartyRock のアーキテクチャの概要 AWS WAF を用いた多層防御の構築 多層防御は、インフラストラクチャを保護するために複数のセキュリティ制御を採用するサイバーセキュリティ戦略です。単一のセキュリティ対策に依存するのではなく、このアプローチは様々な防御メカニズムの組み合わせを使用します。この考え方は、セキュリティの一つの層が失敗したり侵害されたりした場合でも、他の層が代わりに攻撃を検出、防止、または軽減するというものです。私たちは、PartyRock を保護するために、認証ステップと組み合わせた AWS WAF ルールの組み合わせを使用しました。 IP reputation 私たちは、Amazon の内部脅威インテリジェンスに基づくマネージドルールグループである、 Amazon IP 評価リスト を設定しました。これは、典型的なボットやその他の脅威に関連する IP アドレスをブロックしたい場合に有用です。このリストには 3 つのルールが含まれています： AWSManagedIPReputationList : 悪意のある活動に積極的に関与していると特定された IP アドレスを検査します。 AWSManagedReconnaissanceList : AWS リソースに対して偵察活動を行っている IP アドレスからの接続を検査します。 AWSManagedIPDDoSList : DDoS 活動に積極的に関与していると特定された IP アドレスを検査します。 実際の影響 : 2024 年 2 月、AWSManagedIPReputationList ルールにより、ユーザーの体験に影響を与えることなく、悪意のある活動に関連する 20 万件のリクエストを数十分で特定してブロックすることができました。 Rate limiting レートベースルールは、短時間内の大量のリクエストによって Web アプリケーションが圧倒されることを防ぐように設計されています。これは特に、DDoS 攻撃、ボット攻撃、悪意のあるトラフィックを軽減するのに有用です。このルールは定義された基準に従ってリクエストを集約し、ルールの評価ウィンドウ、リクエスト制限、およびアクション設定に基づいて、集約されたグループに対してレート制限を適用します。 私たちは、アプリケーションが圧迫されることを防ぐために、複数のレートベースルールを実装しました: 単一のソース IP が Web サイトを圧倒することを防ぐための包括的なレート制限。 使用する IP アドレスに関係なく、単一のユーザーセッションが Web サイトを圧倒することを防ぐためのCookieベースのレート制限。 実際の影響 : 2024 年 6 月、両方のルールにより、PartyRock のインフラストラクチャを圧迫しようとする数百万件の悪意のあるリクエストをブロックすることができました。 図 2 : レート制限ルールを利用してブロックしたリクエスト数 カスタム緩和ルール 私たちは、AWS WAF で手動対応が必要な DDoS 攻撃に迅速に対応するためのカスタムルールをいくつか作成しました。これらのルールは、私たちが定義した値のリストと一致する特定の属性(例: IP や TLS フィンガープリント (JA3) )を持つリクエストをブロックするように設定されています。通常の状況では、これらのルールにはマッチング文が含まれていないため、どのリクエストもブロックしません。DDoS 攻撃に手動で対応する必要がある場合、まず CloudWatch Logs Insights を使用して攻撃を分析し、トップトーカー(例: 攻撃に最も寄与する JA3 シグネチャ)を特定します。その後、作成したカスタムルールに対応するマッチング文を追加します。これにより、脅威により迅速に対応することができます。 実際の影響 : 2024 年 1 月、私たちは JA3 ベースのカスタムルールを使用して、1 時間あたり数百万件のリクエストを生成する継続的な HTTP フラッド攻撃をブロックしました。 図 3 : カスタム JA3 シグネチャーを利用してブロックしたリクエスト数 CAPTCHA による登録ステップのセキュリティ強化 PartyRock のセキュリティにとって登録ステップは重要です。悪意のある攻撃者が偽のアカウントを作成すると、私たちの無 料の生成 AI 計算能力を悪用される可能性があります。 PartyRock を無料にするトレードオフとして、私たちは 3 つのプロバイダー (Amazon、Apple、Google) からの連携アイデンティティのみを使用した登録を限定的に許可することにしました。登録ステップでは、まずこれらのアイデンティティプロバイダーのいずれかを通じてログインし、それらの認証ステップを経て、PartyRock が必要な情報にアクセスすることを認可する必要があります。最後に、PartyRock でユーザーアカウントを作成する前に、AWS WAF のカスタムルールがさらなる認証ステップとして CAPTCHA を提示します。 CAPTCHA Javascript API を使用して、PartyRock ウェブアプリケーション内で CAPTCHA フォームを表示するようにフロントエンドコードを変更し、登録体験をよりスムーズにしました。CAPTCHA 統合について詳しくは、この Amazon Networking の投稿 をお読みください。 自動化されたボットトラフィックの高度な管理 AWS WAF で設定したセキュリティの最後のレイヤーは Bot Control です。私たちの目標は、匿名ユーザーからのトラフィックかログインユーザーからのトラフィックかに関係なく、自動化されたボットトラフィックを識別し管理することです。Bot Control のマネージドルールグループは 2 つのレベルの保護を提供します。 自己識別型のボットにラベルを追加し、一般的に望ましいボットを検証し、高信頼度のボットシグネチャを検出する、基本となる Common インスペクションレベル 自己識別しない高度なボットを検出する Targeted インスペクションレベル 実際の影響 : 次のグラフを見ると、Bot Control の Common インスペクションレベルが一年を通して異なるHTTPフラッド攻撃を防いだ実績を確認することができます。 Bot Control の Targeted インスペクションは、ブラウザ検査、フィンガープリンティング、行動ヒューリスティックなどの技術に基づいた高度な検出機能を提供し、悪意のあるボットトラフィックを識別します。これらの検出機能には、クライアント側で実行される AWS WAF Javascript Challenge が必要です。 このため、私たちはページに Bot Control Javascript SDK を統合しました。ページが読み込まれると、SDK はユーザー体験に影響を与えないよう非同期で Javascript チャレンジを実行します。チャレンジが正常に解決されると、SDK は暗号化されたトークンを Cookie に配置します。このトークンはユーザーセッションからのすべてのリクエストで AWS WAF に送信され、ユーザーの行動を分析できるようになります。トークンには自動化されたブラウザの検出されたフィンガープリントも含まれています。さらに、SDK はユーザーのナビゲーション中にテレメトリを収集し、検出と緩和ロジックをさらに強化します。 これは非同期であるため、有効なトークンを持たない最初のリクエストも許可する必要があります。Bot Control の TGT_ VolumetricIpTokenAbsent ルールによって、アプリケーションがトークンなしで単一の IP から大量のリクエストを受信した場合、AWS WAF は JavaScript チャレンジペイロードを使用してチャレンジを強制実行し、チャレンジをサイレントに完了してから元のページにリダイレクトします。 前述したように、Bot Control は JavaScript チャレンジの正常な解決後に取得される暗号化トークンを使用して、ユーザーセッ ションの行動を分析します。これにより、通常よりも多くのリクエスト量を持つセッションを特定し、CAPTCHA レスポンスでチャレンジすることができました。 実際の影響 : 以下のグラフは、2024 年を通じて PartyRock へのセッション毎のトラフィックレベルの上昇により、CAPTCHAでチャレンジされたリクエストを示しています。 図 12 : トラフィックレベルが上昇したセッションからのリクエストに対し、CAPTCHA でチャレンジ まとめ 生成 AI の実験的なオープンで創造的な環境を維持しながら、潜在的な脅威や悪用から保護するために、私たちは PartyRock に堅牢な多層防御を構築しました。AWS WAF を使用して、高レベルで以下のルールを実装しています。 DDoS 攻撃のような悪意ある活動に関連した IP からのリクエストをブロックする IP 評価ルールベースのルール 単一の IP やセッションが PartyRock のインフラストラクチャを圧迫することを防ぐための様々な種類のレートベース インシデント対応中に特定された疑わしい属性に基づいてリクエストをブロックするカスタムルール ユーザー登録のワークフローでさらなる認証ステップのための CAPTCHA ルール ボットネットからの自動化されたトラフィックを識別し、適切に管理する Bot Control マネージドルール この AWS WAF 設定は固定的なものではありません。アプリケーションログの継続的な監視と分析を通じて、日常業務で観察される新たな脅威やパターンに対処するため、定期的にルールセットを改良し拡張しています。 私たちはまた、別の AWS WAF ルールセットを使用して Cognito User Pools も保護しました。AWS WAF を使用した Cognito User Pools の保護について詳しくは、 ドキュメント で学ぶことができます。 AWS WAF を始めるには、この ショートビデオ をご覧ください。より詳細な情報は AWS WAF ドキュメント で確認できます。 大規模言語モデル (LLM) アプリでコスト高なトラフィックを回避するための AWS WAF の使用方法について詳しく学ぶには、re:Inforce 2024の この講演 をご覧ください。 Andre Guelfi Torres Andre は AWS のソフトウェア開発エンジニアとして約 4 年間勤務しており、2023 年 8 月の開始時から PartyRock チームに所属しています。それ以前は、コンサルティング、フィンテック、決済など他の業界で働いていました。 Achraf Souk Achraf Souk は EMEA のエッジスペシャリストソリューションアーキテクトチームをリードしています。このチームは、AWS エッジサービスを使用して企業や開発者のウェブアプリケーションのセキュリティと高速化を支援しています。エッジテクノロジー (CDN、パフォーマンス、DDoS、ボット、WAF) に興味がある専門家、ソリューションアーキテクトとしてのスキルを開発したい方、またはリーダーシップ経験からの洞察を求めている方は、LinkedIn でフォローしてください。 翻訳は、パートナーセールスソリューションアーキテクトの小林が担当しました。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 AWS re:Invent 2025 に現地参加し、これが初めての投稿です。会場では Builders Fair エリアにて「Command a Robot with Amazon Bedrock」というブースを出展しました。多くの日本のお客様にお越しいただき、ありがとうございました。ブースでは Bedrock を活用し、ロボットを自然言語で操作するデモを実装しました。ほかにも AI 搭載ロボットの展示が複数あり、フィジカル AI に関する関心が高いと感じました。デモの詳細は今後ブログやアセットとして公開予定です。フィジカル AI に興味のある方は、 こちらのブログ もご参照ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年12月15日週の主要なアップデート 12/15(月) AWS Billing and Cost Management でダッシュボードの PDF エクスポートと CSV データダウンロードをサポート開始 AWS Billing and Cost Management のダッシュボードで、PDF エクスポートと CSV データダウンロード機能が利用可能になりました。これまでスクリーンショットで対応していたダッシュボードの共有が、PDF として直接エクスポートできるようになり、会議や戦略企画での資料作成が効率化されます。また、個別のウィジェットデータを CSV でダウンロードできるため、スプレッドシートでの詳細分析も可能です。追加コストは不要で、中国リージョンを除く全ての商用リージョンで利用できます。詳細は こちらのドキュメントをご参照ください。 ユーザー属性を使用したコスト配分の発表 ユーザー属性を使った新しいコスト配分機能を発表しました。これまで部署やプロジェクトごとの AWS 利用コストを把握するのは困難でしたが、今回の機能により Amazon Q Business や Quick Suite などのアプリケーションの利用料金を、コストセンターや部門といったユーザー属性で自動的に分類できるようになります。経理担当者や FinOps チームが Cost Explorer で詳細なコスト分析を行い、どの部署がどの程度 AWS を利用しているかを簡単に把握できる点が大きなメリットです。詳細は こちらのドキュメントをご参照ください。 Amazon Connect が評価フォームで複数選択と日付の質問をサポート Amazon Connect の評価フォームで複数選択と日付の質問タイプが新たに利用できるようになりました。これまでは単一選択のみでしたが、営業会話で顧客が興味を示した複数の商品を選択できたり、ローン申請日や承認日といった具体的な日付を記録できるようになります。マネージャーは人間と AI エージェントのパフォーマンスをより詳細に分析でき、顧客対応の品質向上に活用できます。詳細は こちらのドキュメントをご参照ください。 12/16(火) Amazon Quick Suite でチャットエージェントのメモリ機能をサポート開始 Amazon Quick Suite のチャットエージェントにメモリ機能が追加されました。この機能により、過去の会話内容や設定した好みを記憶し、パーソナライズされた応答が可能になります。従来は毎回同じフォーマット設定やダッシュボード設定を繰り返す必要がありましたが、今回のアップデートでその手間が解消されます。ユーザーは記憶された内容を確認・削除でき、プライベートモードでの利用も選択できます。バージニア北部リージョンとオレゴンリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 カーボンフットプリントデータの公開時間を 21 日以内に短縮 AWS のカーボンフットプリントデータの公開が大幅に高速化されました。従来は最大 3 か月かかっていたデータ公開が、21 日以内に短縮されています。毎月 15 日から 21 日の間に前月分のデータが確認できるため、アプリケーションの配置や運用方法をより迅速に見直せます。環境負荷削減とコスト最適化の両方を同時に実現でき、過去 38 か月分のデータで長期トレンドも把握可能です。詳細は こちらのドキュメントをご参照ください。 AWS Security Incident Response が Slack との統合を導入 AWS Security Incident Response が Slack との統合に対応しました。これまではセキュリティインシデント対応時に複数のツールを行き来する必要がありましたが、今回の統合により Slack 上で直接ケースの作成や更新が可能になります。各インシデントケースが専用の Slack チャンネルとして作成され、コメントや添付ファイルがリアルタイムで同期されるため、セキュリティチームの迅速な対応と効率的なコラボレーションを実現できます。 AWS IoT Device Management Commands が動的ペイロードをサポート AWS IoT Device Management Commands で動的ペイロード機能が利用できるようになりました。これまではデバイスごとに個別のコマンドを作成する必要がありましたが、今回のアップデートによりテンプレート化されたコマンドを作成し、実行時にパラメータを指定できます。例えばスマートサーモスタットの温度設定では、温度値ごとに別々のコマンドを用意する代わりに、温度をプレースホルダーにしたテンプレート 1 つで対応可能です。パラメータ検証機能も追加され、実行前に値の妥当性をチェックします。詳細は こちらのドキュメントをご参照ください。 12/17(水) AWS Marketplace で必須の発注書とカスタムメッセージングをサポート開始 AWS Marketplace で購買注文書の必須化とカスタムメッセージ機能が利用開始されました。これまで組織の調達ルールを徹底するのが困難でしたが、管理者が購買時に注文書の提出を必須にしたり、調達ページにポリシーや連絡先などのメッセージを表示できるようになります。Private Marketplace との組み合わせで、承認済み製品のカタログ管理も強化され、コンプライアンス遵守と購買の俊敏性を両立できます。詳細は こちらのドキュメントをご参照ください。 AWS のデータベースが Vercel Marketplace で利用可能になりました AWS のデータベースサービスが Vercel Marketplace で利用できるようになりました。Amazon Aurora PostgreSQL、Amazon Aurora DSQL、Amazon DynamoDB を Vercel から数秒で直接作成・接続できます。これまで複雑だったデータベース設定が大幅に簡素化され、Web アプリ開発者にとって画期的なアップデートです。新規アカウント作成時には 100 ドルのクレジットが付与され、6 ヶ月間利用可能です。 12/18(木) AWS Direct Connect が AWS Fault Injection Service による耐障害性テストをサポート AWS Direct Connect が AWS Fault Injection Service (FIS) での耐障害性テストに対応しました。これまでは本番環境での障害時の動作確認が困難でしたが、今回のアップデートにより BGP セッションの中断を意図的に発生させ、冗長化された Virtual Interface への自動切り替えをテスト可能になりました。ネットワーク接続の継続性が重要なシステムでの事前検証に活用できます。詳細は こちらの製品ページをご参照ください。 Amazon SES がメール検証機能を発表 Amazon SES でメールアドレスの事前検証機能が追加されました。メール送信前にアドレスの有効性をチェックし、バウンス率を下げて送信者の評判を保護できます。API での個別検証や、コード変更不要の自動検証が可能で、構文チェックや DNS レコードの詳細な検証情報も取得できます。従来はメール送信後にバウンスで判明していた無効なアドレスを事前に特定できるため、メールリストの品質向上や配信成功率の改善が期待できます。詳細は こちらのドキュメントをご参照ください。 AWS IoT Core が HTTP ルールアクションにメッセージバッチング機能を追加 AWS IoT Core の HTTP ルールアクションに、複数の IoT メッセージを 1 つのバッチにまとめて処理する機能が追加されました。従来は各メッセージを個別に HTTP エンドポイントに送信していましたが、今回のアップデートにより複数のメッセージをまとめて送信できるようになり、コストとスループットの負荷を削減できます。例えば、複数のスマートホームデバイスからのデータを 1 つのバッチにまとめて処理できるため、より効率的な IoT システムの構築が可能です。詳細は こちらの開発者ガイドをご参照ください。 12/19(金) Amazon WorkSpaces Applications が Microsoft Windows Server 2025 をサポート開始 Amazon WorkSpaces Applications で Microsoft Windows Server 2025 をサポート開始しました。最新のセキュリティとパフォーマンス向上により、エンドユーザーに Windows 11 デスクトップ体験を提供できます。従来のサーバー OS では実現できなかった最新機能を活用し、ビジネス重要アプリケーションやリモートアクセス環境をより安全で高性能に構築できます。AWS 提供の標準イメージまたは Image Builder でカスタムイメージの作成も可能で、全リージョンで利用開始できます。 Amazon Bedrock Data Automation がドキュメントブループリント向けの指示最適化機能を開始 Amazon Bedrock Data Automation で blueprint instruction optimization 機能が登場しました。従来はドキュメントからの情報抽出精度を上げるのにモデル訓練が必要でしたが、今回のアップデートで最大 10 個のサンプルドキュメントを用意するだけで自動的に指示文を最適化し、本番レベルの精度を実現できます。請求書の項目抽出や契約条件の分析、医療請求コードの識別など、様々なビジネスシーンで活用可能です。詳細は こちらのドキュメントをご参照ください。 AWS IoT が可観測性コストの最適化を支援するイベントベースログ機能を提供開始 AWS IoT でイベントベースロギング機能が新たに利用開始となりました。従来は全てのイベントを同じログレベルで記録していましたが、今回のアップデートでイベントの種類や重要度に応じて個別にログレベルを設定できるようになります。例えば、証明書関連のイベントは INFO レベル、接続イベントは ERROR レベルのみといった具合に細かく制御可能です。これにより Amazon CloudWatch のログコストを大幅に削減しつつ、必要な情報の可視性は維持できます。AWS IoT コンソールや CLI、API から設定でき、AWS IoT がサポートされている全てのリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲料やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 今週で仕事納めの方が多いかと思います。 年末年始休める方は英気を養って、来年以降の生成AIの波も乗り切っていきましょう。 それでは、12 月 15 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「寄稿：SCRIPTS Asia における生成 AI を活用 した決算説明会等スクリプトの自動翻訳 ～ Amazon Bedrock とナレッジの融合 ～」を公開 日本取引所グループの SCRIPTS Asia 社様が、Amazon Bedrock を活用して決算説明会等のスクリプトを自動翻訳するシステムを構築した事例を紹介しています。単純な AI 翻訳が45〜50点だったのに対し、過去の翻訳履歴や辞書、担当者が持つ暗黙知をプロンプトに取り込むことで90点以上の品質を達成し、時間効率は10倍以上、費用効率は数十倍に改善しました。 AWS生成AI国内事例ブログ「【寄稿】障害原因分析AIエージェントの開発とガバメントクラウド運用業務への導入」を公開 株式会社アイネス様が、ガバメントクラウド運用における障害原因分析を自動化する AI エージェント「FA3（Failure Analysis Assistant Agent）」を Amazon Bedrock Agents で構築した事例を紹介しています。マルチエージェント構成により、アラーム発生時に自動で障害分析を行い、初動調査時間を従来の約10分の1に短縮。経験の浅いエンジニアでも迅速な対応が可能になりました。AWS が公開していた「 FA2（Failure Analysis Assistant） 」を参考に実装されたそうです。 ブログ記事「AWS re:Invent 2025 で発表された AI を活用したセキュリティイノベーション」を公開 AWS re:Invent 2025 で発表された AI を活用したセキュリティイノベーションをまとめて紹介しています。AWS Security Agent、Amazon GuardDuty の拡張脅威検出、AWS Security Hub のニアリアルタイム分析、IAM policy autopilot など、AI と自動化によりセキュリティをプロアクティブでスケーラブルな保護へと変革する新機能が発表されました。 ブログ記事「一般提供が開始された Amazon Nova Act で UI ワークフロー自動化のための信頼性の高い AI エージェントを構築しましょう」を公開 2025 年 12 月 2 日に一般提供開始された Amazon Nova Act を紹介しています。Nova Act は、UI ワークフロー自動化のための信頼性の高い AI エージェントを構築・デプロイ・管理できるサービスで、大規模環境で 90% 以上の信頼性を実現します。Playground での実験から IDE での開発、AWS へのデプロイまでの統合開発環境を提供しています。 ブログ記事「Amazon Nova Forge の紹介: Nova を使用して独自のフロンティアモデルを構築」を公開 Amazon Nova Forge は、Nova を使用して独自のフロンティアモデルを構築できる新サービスです。初期のモデルチェックポイントから開発を開始し、自社データと Amazon Nova のトレーニングデータを混合することで、破滅的忘却を防ぎながら専門知識を組み込んだカスタムモデルを構築できます。Amazon SageMaker AI と Amazon Bedrock との統合も提供されています。 ブログ記事「AWS DevOps Agent はインシデント対応の迅速化とシステム信頼性の向上に役立ちます (プレビュー)」を公開 2025 年 12 月 2 日にパブリックプレビューが発表された AWS DevOps Agent を紹介しています。過去のインシデントと運用パターンを分析し、根本原因の特定や将来の問題防止を支援するフロンティアエージェントです。CloudWatch、Datadog、Splunk などのオブザーバビリティツールや GitHub/GitLab と連携し、Slack に結果を通知することが可能です。 ブログ記事「【EdTech Meetup】AI 時代の EdTech ~プロダクト・開発・運用の変革と EdTech の未来~【開催報告】」を公開 本ブログは、2025 年 11 月 11 日に開催された「EdTech Meetup」の開催報告です。ユニファ、スタディポケット、ビズメイツの 3 社が AI 時代の EdTech について、プロダクト開発や運用での AI 活用事例を紹介しました。AI と人間の役割分担、コスト課題、教育現場での導入障壁などについてパネルディスカッションが行われました。 サービスアップデート Amazon Quick Suite でチャットエージェントのメモリ機能をサポート開始 Amazon Quick Suite のチャットエージェントにメモリ機能が追加されました。この機能により、過去の会話内容や設定した好みを記憶し、パーソナライズされた応答が可能になります。プライベートモードでの利用も選択できるようになっており、その場合会話はメモリの推測に使用されません。米国東部 (バージニア北部) と米国西部 (オレゴン) リージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 Amazon Quick Suite ブラウザ拡張機能が Quick Flows をサポート Amazon Quick Suite ブラウザ拡張機能で Quick Flows がサポートされました。これまで Web ページから手動で情報を抽出していた作業が、ブラウザ内でワークフローを直接実行することで自動化できます。契約書の重要項目抽出やプロジェクトダッシュボードからの週次レポート生成など、日常的な定型業務の効率化に役立ちます。Chrome、Firefox、Edge で利用可能で、米国東部 (バージニア北部) と米国西部 (オレゴン) 、アジアパシフィック (シドニー)、欧州 (アイルランド) リージョンで提供開始されています。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock Data Automation がドキュメントブループリント向けの指示最適化機能を開始 Amazon Bedrock Data Automation で blueprint instruction optimization 機能が登場しました。従来はドキュメントからの情報抽出精度を上げるのにモデル訓練が必要でしたが、今回のアップデートで最大 10 個のサンプルドキュメントを用意するだけで自動的に指示文を最適化し、本番レベルの精度を実現できます。請求書の項目抽出や契約条件の分析、医療請求コードの識別など、様々なビジネスシーンで活用可能です。詳細は こちらのドキュメント をご参照ください。 本年度はこのブログが最終号となります。1年間ありがとうございました！ 次回は1月12日(月)の予定です！それではまたお会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

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 オンラインセミナーなどのイベントへの登壇にも力を入れています。