このブログは、 “ AWS re:Invent 2025: A transformative moment for healthcare and life sciences ” の翻訳です。 今年で14回目を迎える AWS re:Invent には、6万人を超える経営陣、開発者、業界のリーダーがラスベガスに集結し、最先端のデータ・AI イノベーションを体験しました。数十の新サービス発表、数百のデモンストレーション、数千のセッションが開催される中、ヘルスケア・ライフサイエンス分野の企業が注目の的となりました。これらの企業は実際の活用事例を紹介し、Amazon Web Services（AWS）のソリューションを使って創薬を加速し、臨床業務を効率化し、患者体験を革新する取り組みを実演しました。 本記事では、AWS ヘルスケア・ライフサイエンスチームが厳選した注目セッション、重要な発表、顧客事例をご紹介します。 注目セッション re:Invent では、ヘルスケア・ライフサイエンス企業が数多くのセッションに登壇しました。特に印象的だったセッションをご紹介します： ライフサイエンス分野におけるリアルワールドエビデンス創出の加速化 臨床時間を取り戻す：Veradigm の AI 活用による業務変革 ノバルティスの次世代データプラットフォームがAI創薬を実現 UC San Diego Health、Amazon Connect で患者エンゲージメントを刷新 研究室から市場へ：アストラゼネカの全社的 AI 成功ストーリー ヘルスケアの変革：生成 AI が描く未来像 EHR の枠を超えて – AWS で実現する臨床・運用への最大インパクト 基調講演 Matt Garman の年次基調講演では、 Lila Sciences 、Bristol Myers Squibb、Cohere Health、Pfizerといったヘルスケア・ライフサイエンス企業が、イノベーションを牽引する業界リーダーの事例として紹介されました。開発者を「AWS の心臓部」と位置づけ、「発明の自由」を重視する Matt のメッセージは、20年間変わらない AWS の根本理念を表しています。 Swami Sivasubramanian のAI基調講演は、Allen Institute の取り組みから始まりました。同研究所が開発した、単一細胞マルチモーダル脳細胞データを解析する高度なニューラルネットワークモデルが紹介されました。Swami は講演の中で、特定の患者アウトカムを予測するモデルの学習や、分子構造とタンパク質相互作用を深く理解する AI モデルの開発など、複数のヘルスケア事例を取り上げました。 Peter DeSantis と Dave Brown は、AWS が追求し続ける6つの基本要素 – セキュリティ、可用性、パフォーマンス、弾力性、コスト効率、俊敏性 – について改めて強調しました。AI 時代においては、これらのクラウド基盤要素がこれまで以上に重要になっています。Dave Brown は、これらの要素を大規模に実現する Graviton と AWS のカスタムシリコン技術革新を紹介しました。 Werner Vogels は14年間の最後の基調講演で、「ルネサンス開発者」という概念を提唱しました。これは好奇心旺盛で、システム思考を持ち、効果的なコミュニケーション能力を備えた開発者像です。AI と開発者の進化について語った彼のメッセージは多くの共感を呼びました：「AI は私の仕事を奪うのか？そうかもしれない。AI は私を時代遅れにするのか？進化し続ける限り、決してそうはならない。」彼は開発者がオーナーシップを持つことの重要性を強調しました：「成果物はあなたのものであり、ツールのものではない。あなたが作り、あなたが責任を持つ。」 重要な発表 ヘルスケア組織のデジタル変革が進む中、今年の発表は業界が直面する根深い課題に正面から取り組むものでした：データプライバシー、臨床ワークフローの効率化、専門特化 AI 開発、セキュアなインフラ構築。 また、ライフサイエンス企業では、バリューチェーン全体で AI エージェントの活用が拡大しています。新サービスは、標的探索から個別化患者エンゲージメントまで、効率性を大幅に向上させながら市場投入までの時間短縮を実現します。 今週発表された数十の新サービス、機能、アップデートの中から、ヘルスケア・ライフサイエンス関係者が最もインパクトの大きいイノベーション領域を厳選しました。 データプライバシー・セキュリティの革新 セキュリティは最優先課題であり続けており、顧客がデータを安全に保護し、コンプライアンスを維持しながらイノベーションを推進できる複数の新サービス・アップデートを発表しました。中でも最もインパクトの大きい発表は、 AWS Clean Rooms の機能拡張で、プライバシー強化合成データセット生成が可能になりました。 この新機能により、組織とパートナー企業は共有データから回帰・分類機械学習（ML）モデル学習用のプライバシー強化合成データセットを生成できます。ヘルスケア・ライフサイエンス組織にとって、このアップデートは患者情報や機密データを公開することなく、より精密で用途に特化したモデル構築を可能にします。統計的妥当性を保ちながら設定可能なプライバシー保護を追加する合成データセット生成機能は、ヘルスケア業界最大の課題の一つ – データ活用とプライバシー要件のバランス – に直接的な解決策を提供します。例えば、研究機関は HIPAA に準拠しながら統計パターンを保持する合成データセットを生成することで、希少疾患研究での協力が可能になります。また、創薬チームは患者健康情報（PHI）を公開することなく、複数の臨床データセットでモデルを学習できます。 その他の重要な発表 ： データ主権： AWS AI Factories により、ヘルスケア・ライフサイエンス組織は業界規制・コンプライアンス要件を満たしながらAIの力を活用できます。機密患者データのローカル処理が可能になり、コンプライアンス体制が強化され、PHI 要件への準拠が実現します。例えば、ヘルスケア組織は病院内や自社のデータセンター内に AWS AI インフラを導入できるようになりました。 プロアクティブなアプリケーションセキュリティ： AWS Security Agent は、PHI を扱うヘルスケアアプリケーションに不可欠な積極的セキュリティ開発・監視を実現します。Security Agent は継続的セキュリティ評価を通じて HIPAA・GxP コンプライアンスの維持を支援し、患者・機密データに影響が及ぶ前にセキュリティ問題を特定します。 脅威検出： Amazon GuardDuty Extended Threat Detection は、ヘルスケア組織全体で統一されたセキュリティ可視性を提供します。多様なヘルスケアワークロード全体で患者データを標的とする高度な攻撃を特定できます。この新機能は複雑なヘルスケア IT 環境のセキュリティ監視を簡素化し、HIPAA 等の規制監査用包括的セキュリティレポート生成を支援します。 セキュリティハブ： AWS Security Hub は重要セキュリティ問題の優先順位付けと大規模対応を支援し、応答時間を改善します。ヘルスケア組織はほぼリアルタイム分析でダウンタイム中断を最小化し、問題優先順位付け・コンプライアンスチェックを自動化できます。 AI 技術の進歩 2025年を通じて、AWS はあらゆる組織が AI の力を活用しやすくする Amazon Bedrock AgentCore などの新サービス開発に継続投資してきました。re:Invent では、この流れが数多くの発表とともに加速しました。 特に注目すべき発表： Amazon Connect の患者エンゲージメント向け新機能 を発表。電子健康記録（EHR）との安全なリアルタイム統合により、患者・介護者のセルフサービス認証が可能になり、予約が最新かつ正確な情報でスケジュールされることを確認できます。Nova Sonic の高度音声モデルを活用した AI エージェントは、複数言語・アクセントに対応し、適切なペース・トーン・理解力で自然で人間らしい会話を実現します。 AWS は業界最高水準の価格性能で推論機能を提供する次世代汎用モデル、Amazon Nova 2 を発表しました。 Speech-to-speech： Amazon Nova 2 Sonic は音声間変換モデルで、開発者が音声アプリケーションを構築するための業界最高水準の会話品質、価格設定、音声理解機能を提供します。患者インタラクション・アクセシビリティ向上のため、Sonic はより自然な多言語会話と遠隔医療サービス・遠隔監視向けリアルタイム翻訳を実現します。ライフサイエンス分野では、研究者が音声でデータソースを調査し、仮説を立て、手動入力に代わって音声で実験作業を記録することで、時間節約と生産性向上を支援します。 マルチモーダルデータ： Amazon Nova 2 Lite (*)と Nova 2 Omni は拡張推論機能を備えた費用対効果の高い AI を提供します。強力な機能の一つがマルチモーダルデータ統合で、医用画像、テキストレポート、研究文献、患者データの統合解析を可能にします。100万トークンのコンテキストウィンドウにより、Lite は患者の全履歴を処理してより的確な推奨を提供できます。臨床試験・遠隔監視では、ウェアラブルから在宅監視機器まで複数のデータストリームを処理できます。 (* 訳者注：Nova 2 Lite は現在、日本国内に限定したクロスリージョン推論に対応しています。) 専門ドメインモデル開発： Amazon Nova Forge は専門ドメイン向けモデル開発を簡素化します。分子特性を予測する創薬アシスタント開発から、放射線学・病理学・ゲノミクス向けカスタムモデル構築でドメイン専門知識を深く組み込むヘルスシステム支援まで、ヘルスケア・ライフサイエンス業界で特に有用です。 反復作業の自動化： Amazon Nova Act は、電子カルテデータ入力、請求処理、フォローアップ調整などの反復的ワークフローの安全な自動化を実現します。 AWS EC2 Trainium3 と P6e UltraServers は、専門的ヘルスケア・ライフサイエンスモデル訓練のための価格性能向上オプションを提供します。医用画像、ゲノミクス、デジタル病理学などの複雑で大規模なデータセットでの訓練時に特に効果を発揮します。 データ管理・分析 安全でスケーラブルなデータ基盤は、AI 成功の原動力であり続けています。re:Invent で AWS は数多くのデータ管理・分析サービスを発表しました。ヘルスケア・ライフサイエンス顧客向けの注目機能は、ベクトルスケーラビリティとレプリケーションです。 Amazon S3 Vectors は、ベクトル保存・クエリのネイティブサポートを持つ初のクラウドオブジェクトストアで、Amazon S3 に保存されたコンテンツの AI エージェント、AI 推論、セマンティック検索向けに目的特化・コスト最適化されたベクトルストレージを提供します。ゲノム解析では、研究者はコストを抑えながら数十億のゲノムベクトルを効率的に保存・クエリできます。医用画像分野では、S3 Vectors は膨大な画像リポジトリ全体での高速類似性検索を可能にします。創薬では、類似分子構造の迅速特定により化合物スクリーニングを加速できます。 Amazon S3 Tables レプリケーションサポート は、データレジデンシー要件・災害復旧のコンプライアンスを簡素化します。マルチリージョンコンプライアンスでは、ヘルスケア企業が多様な規制要件を満たすためにリージョン間で患者データを簡単に同期維持できます。研究者にとっては、一貫したガバナンスを維持しながら研究拠点間でのデータ共有が簡素化されます。 戦略的提言 re:Invent での業界向け発表を踏まえ、ヘルスケア・ライフサイエンス組織のリーダーは以下の検討を開始しましょう： データ戦略の見直し： AWS Clean Rooms と S3 Vectors がプライバシーを維持しながら新たな共同研究イニシアチブをどう実現できるかを評価 AIロードマップの加速： Nova Forge と Nova 2 による専門モデルが特定の臨床・研究ドメインをどう変革できるかを検討 業務プロセス自動化の機会： Nova Act の自動化機能から恩恵を受ける大量管理プロセスを特定 インフラ計画： AWS AI Factories が、これまで AI 導入を制限していたデータ居住・推論レイテンシの懸念に対処できるかを評価 セキュリティ強化： 機密ヘルスケアアプリケーション・データ保護強化のため新しい AWS Security Agent を導入 まとめ AWS re:Invent 2025 は、ヘルスケア・ライフサイエンス組織にとって大きな転換点となりました。プライバシー保護協力、専門 AI モデル開発、ワークフロー自動化、セキュアインフラへの注力は、業界が直面する最も差し迫った課題に直接対応しています。既に AWS を活用しているヘルスケア組織には、患者ケア向上、研究加速、運用効率改善の即座の機会を提供します。クラウド導入初期段階の組織には、AWS がヘルスケア・ライフサイエンス固有のプライバシー、セキュリティ、専門ドメイン専門知識要件にどう具体的に対応しているかを説得力を持って示しました。 タグ: re:invent Stephanie Dattoli Stephanie Dattoli は、Amazon Web Services（AWS）のライフサイエンス・ゲノミクスマーケティング部門のワールドワイドヘッドです。ライフサイエンスとクラウド技術の融合領域を専門とし、過去10年間にわたって主要ライフサイエンス組織の新製品市場投入と市場拡大を支援してきました。スタンフォード大学で遺伝学の大学院修了証明書を取得し、ビジネスと戦略マーケティングの学部二重学位を保有しています。 Brian Loyal Brian Loyal は、Amazon Web Services のグローバルヘルスケア・ライフサイエンスチームでシニア AI/ML ソリューションアーキテクトを務めています。バイオテクノロジーと機械学習分野で16年以上の経験を持ち、顧客のゲノミクス・プロテオミクス課題解決支援に情熱を注いでいます。プライベートでは友人・家族との料理と食事を楽しんでいます。 Jennifer Rouse Jennifer Rouse は、AWS のヘルスケアマーケティング部門でワールドワイドヘッドを務めています。IBM、Ciscoなどの大企業や2つのクラウドベーススタートアップでリーダーシップを発揮し、直近では Forrester Research/Sirius Decisions でグローバルアナリスト兼アドバイザーを務めました。キャリアの大部分を、公共部門など従来十分なサービスを受けていない業界に変革をもたらす企業で過ごしました。公共部門での経験により、ヘルスケア、公共安全、教育、行政分野で人生を変える多くの技術プログラムに携わってきました。 Nadeem Bulsara Nadeem Bulsara は、ゲノミクス・ライフサイエンス専門の AWS プリンシパルソリューションアーキテクトです。13年以上のバイオインフォマティクス、ソフトウェアエンジニアリング、クラウド開発スキルと、研究・臨床ゲノミクス・マルチオミクス経験を活かし、世界中のヘルスケア・ライフサイエンス組織を支援しています。人々の長く健康な人生を実現するという業界使命に強く動機づけられています。 このブログは、Senior Solutions Architect の松永が翻訳しました。

この記事は、 Building a Credit Card Payment Processing Platform on AWS を翻訳したものです。 金融サービス業界（FSI）は大きな変革のただ中にあり、デジタル化が果たす重要な役割を考慮すると、電子決済はこの変革の中心的存在です。決済のキャッシュレス化が進展する中、業界がインクルージョン（包摂性）を促進する役割は重要な優先事項となっています。デジタル経済の革新と発展は、世界経済の安定した基盤として機能する決済によって支えられています。カード決済取引の裏側では多くの処理が行われており、クレジットカード処理の仕組みを明確に理解することは、企業が業務をより効果的に管理する上で役立ちます。本ブログ記事では、AWS上でクレジットカード決済処理プラットフォームを構築する方法を解説します。また、クレジットカード決済のオーソリゼーションにおけるアクワイアリング側とイシュアリング側の2つの高レベルなリファレンスアーキテクチャを紹介します。 ベネフィット 決済処理システムをクラウド上でモダナイズすることで、以下の目的が達成されます： 季節的な需要急増に対応するための迅速かつ効率的なスケーリング 高可用性を維持しつつ、年々増加するスループットをサポートし、厳格なセキュリティ要件に対応 データ居住要件や規制要件を遵守しながら市場へ展開し、グローバルビジネスを支援 新製品開発のための迅速なプロトタイピングを実現 クレジットカード決済処理では、金融機関が高可用性とスループットのSLAを満たすと同時に低遅延を実現する必要があります。 AWSは、 Amazon API Gateway 、 Amazon Managed Streaming for Apache Kafka (MSK) 、 Amazon DynamoDB などのツールとサービスを提供し、クラウド上で最新の分散型決済処理プラットフォームを構築し、毎秒数千件のトランザクションにスケールアップしたいお客様を支援します。AWSのお客様は、コンテナ化を強力な技術として活用し、アプリケーションの依存関係を持ち運び可能な方法で分離・管理することで、決済処理システムの可用性を大幅に向上させています。 組織が Amazon Elastic Kubernetes Service（EKS） を活用すると、需要やリソース可用性に応じてコンテナ化ワークロードのスケーリングと管理を自動化できます。また、AWSのネットワークセキュリティサービスと統合することで、さらに高い可用性と回復力を実現できます。さらに、自動化された監視・アラートツールをコンテナオーケストレーションプラットフォームと統合することで、決済処理システムの健全性とパフォーマンスをリアルタイムに可視化し、ユーザーに影響が出る前に先制的に問題へ対応することが可能になります。 AWSクラウドは、厳格なセキュリティ要件を満たすID管理を備えた、多層的なセキュリティを提供します。また、潜在的なセキュリティ設定ミス、脅威、または予期せぬ動作を特定するための脅威検知および対応サービスが利用可能です。AWSは、 Amazon Virtual Private Cloud（VPC） や AWS PrivateLink などの最新のネットワーク機能を提供し、メッセージがパブリックインターネットを経由せずに決済事業者間で通信することを可能にします。グローバルな顧客は、複数のAWSアベイラビリティゾーンおよびリージョンを使用して新規市場に拡大することができます。さらに、顧客は AWS Artifact のコンプライアンスレポートや認証、ベンダーデューデリジェンスメカニズムを活用し、AWSが責任を負う統制を理解・立証できます。また、AWSのサービスやリソースを活用して堅牢な統制環境を構築することで、現地市場におけるコンプライアンス要件への準拠を実証することが可能です。 開発者は、AWSのツールやサービスを活用することで、コンプライアンス、セキュリティ、インフラストラクチャ・アズ・コードの標準化と自動化を実現できます。また、技術プロダクトマネージャーは開発チームと連携して顧客と迅速にプロトタイプを作成し、新たなユースケースの解決に役立てます。AWS DevOpsは開発者が新機能を迅速にリリースできるようにし、運用チームがアプリケーションを本番環境に投入するまでの時間を短縮します。 AWS Config Rules 、 Service Catalog （ガバナンス・アズ・コード、セキュリティおよびIAMポリシー、バックアップ保持ポリシー、ロギング・モニタリングポリシー）、 CloudFormation Guard などのツールにより、中央管理チームは分散開発チームを容易に統制でき、コンプライアンスとクラウドのベストプラクティスを維持しながら迅速な開発を実現します。 クレジットカード決済処理の構成要素 クレジットカード決済は通常、3つの主要なステップで構成されるメッセージ取引として処理されます。最初のステップは取引の「オーソリゼーション（信用照会）」です。オーソリゼーションはリアルタイムで行われ、発行銀行に照会してカード所有者の口座に資金が存在することを確認します。また、発行銀行は取引を承認するか拒否するかの判断も提供します。第2のステップは取引の「決済」です。決済では、オーソリゼーション済み取引をまとめて発行銀行に送付し、照合が行われます。第3段階である「清算」では、資金を加盟店の銀行口座へ移動します。 次に、クレジットカード決済における主要なプレイヤーの概要を見ていきましょう。これにより、クレジットカード決済のバリューチェーンの一部を説明し、アクワイアラー処理と発行者処理のリファレンスアーキテクチャを提示します。 加盟店には、企業、起業家、個人事業主およびその間のあらゆるタイプの事業者が含まれます。加盟店が決済取引プロセスにおいて基盤的な役割を果たすのはカード決済受入ツールを活用するためです。具体的には、カード取引用のクレジットカード端末またはPOSシステム、決済ゲートウェイを備えた安全なe コマースウェブサイト、あるいは拡大を続けるアプリケーション群に統合された決済手段などがあります。 決済ゲートウェイは、決済ポータル（ウェブサイト、携帯電話、音声応答サービスなど）と決済処理業者（アクワイアラー）間の情報転送を通じて、決済取引を仲介します。 決済処理業者は、加盟店およびその取引銀行に代わってクレジットカード・デビットカード取引を処理する企業です。クレジットカードライフサイクルに関わるすべての関係者を結びつける決済処理業者は、単なる処理機能を超え、事業成長を支援する包括的な決済関連サービスを提供するように進化しています。 アクワイアラー（加盟店契約会社または加盟店管理会社）は、加盟店口座を開設・管理する機関です。加盟店口座とは、企業が電子決済カード取引を受け付け処理できるビジネス口座の一種です。クレジットカードやデビットカード決済を受け付けるすべての企業は、アクワイアラー銀行や独立系販売組織（ISO）などの機関を通じて加盟店口座を開設できます。また、決済代行業者などを通じて、サブ加盟店口座（別の企業が代わりに加盟店口座を提供する形態）を開設することも可能です。カード決済取引中、アクワイアラーまたはその処理業者は、加盟店とカードネットワーク間で取引リクエストと認証データをやり取りします。 カードネットワーク（ブランドネットワーク）は、顧客、加盟店、発行銀行、アクワイアラーを結びつけます。カードネットワークは、決済処理の統括機関として機能し、主要なカードネットワークには、アメリカン・エキスプレス、ディスカバー、マスターカード、銀聯（ユニオンペイ）、VISAなどがあります。カードネットワークはインターチェンジ料率を設定し、イシュアーとアクワイアラー間を仲介し、安全で迅速かつ効率的な決済を促進することに努めています。 イシュアー（カード発行銀行またはカード発行会社）は、クレジットカードを発行する機関であり、消費者を金融システムに接続して事業者への取引資金調達を促進するという、重要なサービスを提供しています。この資金調達プロセスは、事業者が存続し繁栄するための財務的な原動力となっています。 消費者（カード保有者）は、対面（カード提示）または非対面（カード非提示）の方法で支払い認証情報を提供し、カード取引を開始します。取引金額は金融機関に記録され、口座の種類に応じて貸方または借方として処理されます。カード決済取引のライフサイクルはさまざまな要因で変動しますが、オーソリゼーション・決済・清算という基本プロセスは固定されています。本稿ではカード取引ライフサイクルの第1段階である「オーソリゼーション」について、イシュアーとアクワイアラー双方のリファレンスアーキテクチャを用いて解説します。 オーソリゼーション クレジットカードライフサイクルの最初のステップはオーソリゼーションです。顧客は、対面または安全な通信を通じて加盟店に支払いカードの認証情報を提示します。カード提示取引の場合、カードの詳細情報は、カードチップの挿入、タッチ決済、カードのスワイプ、または手動でのカード入力などの方法を通じてPOS端末に伝達されます。物理的なPOS取引では、EMVカードまたはデジタルウォレットと端末間で通信する際に、アプリケーション識別子（AID）とカード所有者認証方法（CVM）が決定されます。カード非提示取引では、カード情報が加盟店プラグインや利用可能な決済ウォレットなどの複数のオプションを通じて提供されます。決済サービスプロバイダー（PSP）は、チェックアウト時にカード情報をトークン化する機能を提供し、加盟店によるカード認証情報の保存を防止します。カード情報は、適切な決済処理業者へルーティングするために、暗号化されて決済ゲートウェイに送信されます。決済処理業者はカードBIN（カード番号の最初の6 桁または8 桁）または口座情報を確認して、取引に適用すべきサービス（不正スコアリングやアカウント更新サービスなど）を決定します。アカウント更新サービスは、カード紛失・盗難時にカードライフサイクルにおける最新カード番号を非対面取引向けに提供するために利用されます。プロセッサーは決済スイッチと連携して取引をルーティングすべきカードネットワークを決定します。また、ネットワーク送信前に適切なメッセージ形式（ISO 8583、ISO 20022など）とレイアウトに変換する責任を負います。 Acquiring Processor Authorization Flow カードネットワークがネットワークメッセージを受信すると、必要に応じて支払い情報をデトークン化し、カードの種類・取引タイプ・支払いチャネルに応じて、不正利用のスコアリングや支出管理、データ変換、デジタル認証、その他の検証サービスといった関連する代行サービスを実行します。 Issuer Processor Authorization Flow カードネットワークは、発行銀行またはプロセッサーにメッセージを送信し、承認または拒否の応答を返す前に、リスク管理・カード制御・残高・チップ・住所・利用頻度・ポリシー・その他の必要なチェックを実行します。応答メッセージには承認の場合は「0-承認」などの理由コード、拒否の場合は「05-承認不可」または「62-制限付きカード」などの理由コードが提供されます。カードまたはトークンの種類および各取引のチャネルに応じて、カードネットワークまたは発行者はカード取引用に一意に生成される動的情報を検証します。 AWS におけるオーソリゼーションのためのリファレンスアーキテクチャ 以下のアーキテクチャ概要図は、AWS 上に構築されたオーソリゼーションシステムの主要コンポーネントと、異なるチャネルおよび各種スキーム間の通信モデルを示しています。 フローは、さまざまなチャネルが暗号化されたカード情報を、セキュアな通信回線を通じて Amazon API Gateway に送信するところから始まります。 AWS WAF を有効化することで、SQLインジェクションやクロスサイトスクリプティング（XSS）攻撃といった一般的なWeb攻撃からAPI Gateway APIを保護できます。API Gatewayは Amazon Cognito と統合されているため、許可されたユーザーのみがAPIにアクセスでき、リソースを不正アクセスから保護できます。 承認済み決済トランザクションは、ネットワークロードバランサー経由で Amazon Managed Streaming for Apache Kafka（MSK） に送信されます。PCIではカード所有者データの転送中と保存時における暗号化が義務付けられています。Amazon MSKはデフォルトでTLS 1.2を使用し、MSKクラスターのブローカー間で転送されるデータを暗号化するために、TLS 1.3の使用を推奨しています。 転送中のTLS暗号化（クライアント-ブローカー間、ブローカー間）、 TLSベースの証明書認証 、 SASL/SCRAM認証 は、 AWS Secrets Manager の支援によって実現できます。Kafkaトピック内のトランザクションは、AWS Fargateコンテナによってリアルタイムで消費されます。 AWS Fargate は Amazon ECS と組み合わせて使用できます。これにより、Amazon EC2インスタンスのサーバーやクラスターを管理せずにコンテナを実行できます。 Amazon ECR プライベートリポジトリを使用すれば、Amazon ECSタスクがプルするコンテナイメージやアーティファクトをホストできます。 コンテナはデータを決済用HSM（ハードウェア・セキュリティ・モジュール）に渡し、復号化されたデータを受け取ります。決済用HSMは、新たに提供が開始されたAWSのフルマネージド型決済HSMサービスである「 AWS Payment Cryptography 」を通じてプロビジョニングできます。また、 DynamoDBクライアントサイド暗号化ライブラリ を使用すれば、原文を暗号化して、その暗号テキストを暗号されているデータベースに保存できます。トークン応答は、内部アプリケーション操作のためにアプリケーションデータベースに保存されます。 Amazon ElastiCache for Redis 上のサブミリ秒レイテンシのインメモリデータキャッシュを使用することで、カードネットワークからのカード利用可能リクエストに即座に対応できます。トークン化された情報を、 AWS Step Functions を使用して様々なビジネスフローに適用すると、カードと取引タイプに基づくBINチェック、リスクチェック、アカウントチェック、不正検知チェック、その他の付加価値サービスを検証できます。検証後、応答はISO形式にフォーマットされ、消費のためにイグレスAmazon MSKに送信されます。複数のKafkaリスナーがカードネットワークに接続できます。 AWSにおけるイシュアーオーソリゼーションのリファレンスアーキテクチャー イシュアー処理フローにおいて、カードネットワークはソケット接続を介してペイロードを送信し、発行銀行またはプロセッサー（IBP）へオーソリゼーションリクエストを中継します。オンプレミスまたはコロケーション施設に設置された決済ネットワークインターフェースプロセッサー（PNIP）は、カードネットワークからのTCP/IPトラフィックを受信します。IBPは AWS Direct Connect を利用して内部ネットワークから標準イーサネット光ファイバーケーブル経由で、AWS Direct Connectロケーションに接続できます。AWS Direct Connectと AWS Transit Gateway の組み合わせは、複数のVPCとオンプレミスネットワークを接続するネットワークトランジットハブを構築するのを支援します。 オーソリゼーションリクエストのトラフィックは、AWS Transit Gateway経由でNetwork Load Balancerを介してトークナイゼーションVPCにルーティングされます。Network Load Balancerは接続レベル（レイヤー4）で動作し、IPプロトコルデータに基づいて顧客VPC内のターゲットコンテナへ接続をルーティングします。トークナイゼーションVPCは機密カード情報をトークン化します。カードデータに対する検証や確認といった暗号処理は、AWS Payment Cryptographyのようなスケーラブルで耐障害性の高いサービス上で実行する必要があります。情報は暗号化されたデータベースに保存されますが、データベースに依存せずAmazon ElastiCacheから取得することができます。 リクエストはオーソリゼーション決済処理VPCに転送され、さらに処理されます。オーソリゼーションコンテナは Amazon Elastic Kubernetes Service（EKS） と統合でき、アプリケーションをデプロイすることができます。 オーソリゼーションコンテナは、カード種別に基づくビジネス検証チェックのため、承認リクエストに追加情報を付加します。ビジネスプロセスワークフローエンジンは、カード種別に応じた不正検知・リスク・取引頻度・口座情報およびチップ・PIN・トークン・限度額・現金取引などのさまざまなポリシーに基づく複数のチェックを実行します。ビジネス検証応答は Amazon Managed Streaming for Apache Kafka (MSK) のトピックにストリーミングされます。オーソリゼーションコンテナが応答を処理して、 Amazon DynamoDB に情報を保存します。その後、IBPはオーソリゼーション応答（承認または拒否応答など）をカードネットワークに送信します。この応答は、アクワイアリングプロセッサーを経由して最終的に加盟店端末に戻ります。 決済事業者は、貴重な顧客データを保有しています。このデータは、 Amazon Comprehend を使用して、感情分析や商品レビュー分析といった顧客インサイト導出に活用できます。また、 Amazon Personalize を活用すれば、商品ランキングや特定商品の推奨、カスタマイズされたダイレクトマーケティングといった、リアルタイムなパーソナライズドレコメンデーションを実現できます。 まとめ クレジットカードは、店頭決済と非対面決済の両方において重要な決済手段であり続けています。キャッシュバックやカード特典、航空会社のポイントなどは、顧客がクレジットカードで支払う理由の一部でしかありません。2022年、米国の大手クレジットカード発行会社では、旅行・娯楽支出の増加に伴い、クレジットカードの利用が大幅に増加しました。また、クレジットカード分野では、デジタルファーストのクレジットソリューションによる革新も進んでいます。この革新により、顧客の申し込みが承認されるとすぐに仮想カードやトークンが利用可能になり、カード情報をデジタルウォレットに即座に追加できるようになります。 顧客はクレジットカード決済が数秒で処理されることを期待しています。本稿では、AWSのサービスを活用し、安全かつリアルタイムに処理でき、高い耐障害性を備え、ピーク時の決済量急増にも対応可能なクラウド決済処理ソリューションの構築方法について説明しました。また、クラウドベースの決済システムでは、AWSのツールとサービスを用いて PCI DSS に準拠した堅牢なセキュリティ対策を実現できます。フィンテック企業により、加盟店が自社ブランド（別名プライベートラベル）クレジットカードを容易に発行し、顧客セグメントの独自のニーズやライフスタイルに基づいた報酬をカスタマイズできるようになったことで、イノベーションはクレジットカード市場を活性化し続けています。 AWSとの連携方法や、世界中の決済顧客が決済処理を実行するのを当社がどのように支援しているかについての詳細は、AWSアカウントマネージャーにお問い合わせいただくか、 AWS Financial Services – Payments をご覧ください。 免責事項： 本投稿におけるリファレンスアーキテクチャに関する記述は、説明を目的とした参考情報であり、公開時点での情報に基づいています。記載の手順や推奨事項は教育目的および初期概念実証を意図したものであり、企業全体向けの完全なソリューションではありません。組織に適したアーキテクチャ設計についてはお問い合わせください。 本稿はソリューションアーキテクト畑が翻訳を担当しました。

 株式会社ダイレクトマーケティングエージェンシー （以下、DMA）は、2006年の創業以来、ECビジネス支援エージェンシーとして自社開発にこだわり、ITとBPOソリューションを提供してきました。近年のEC市場では、顧客行動の多様化やチャネルの増加により、データ活用の重要性が一層高まっています。DMAはこうした背景を受け、データレイクおよびAI機能を実装したEC基盤「D-Sales ECクラウド」を開発・提供してきました。 本ブログでは、DMAがAmazon Bedrock AgentCoreを中核に据えて開発した、 AIオートパイロット型CRMプラットフォーム「リピートMAX」 の開発事例をご紹介します。 背景と課題 多くのEC事業者は、CRM運用において以下のような構造的な課題を抱えています。 1. CRM運用の属人化問題 従来のCRM運用では、施策の立案から実行まで、担当者の経験とスキルに大きく依存していました。優秀な担当者の異動や退職により、それまで築き上げてきたノウハウが失われてしまうリスクが常にありました。また、担当者によって施策の質にばらつきが出てしまうことも大きな課題でした。 2. 短期的施策への偏重 四半期ごとの売上目標達成を優先するあまり、タイムセールや一時的な割引施策に依存し、顧客の購買サイクルや中長期的な関係構築を考慮したCRM設計が十分に行われていないケースも少なくありませんでした。特に、初回購入から2回目・3回目の購入につながらないことが、LTV最大化の大きな障壁となっていました。 3. データ統合・活用の複雑さ EC運営の現場では、複数のマーケティングツールが併用され、データが分散していることが一般的です。その結果、顧客行動の全体像を把握することが難しく、ツール間連携やデータ統合に大きな運用負荷がかかっていました。 ソリューションの概要 DMAは、単なるツール統合やルールベースの自動化では上述の課題解決が難しく、課題を根本から解決するために顧客行動を文脈として理解し、状況に応じて判断を変えるAIの活用が不可欠と考えました。そこで、Amazon Bedrock AgentCoreを中核とした次世代CRMプラットフォーム「リピートMAX」の開発に着手しました。「リピートMAX」に搭載されているAIオートパイロットが売上予測に基づいた最適なCRM施策を提案します。「ターゲティングからクリエイティブ/売上予測/事後検証」まで全てのCRMプロセスを対話形式で選択していきます。目的に応じた提案施策を選択するだけで最適CRM施策によるLife Time Valueの最大化を実現します。 図 1: リピートMAXについて 以下が「リピートMAX」のシステム概要になります。 図2:リピートMAXのシステム概要図 「リピートMAX」の処理の流れは以下です。 ECサイト運営者はWebブラウザ上のWidgetを通じて、 売上予測、クリエイティブ生成、AIチャットなどの機能を選択し、必要な情報を入力する フロントエンドが入力された内容をAPI Layerに送信する API Layer は入力内容に応じて、対象者抽出、売上予測、クリエイティブ、AIチャットを行う 3 の処理を行う際、必要に応じて Amazon Bedrock AgentCore を利用したり、Amazon Redshift Serverless、Amazon Aurora 、Amazon S3から顧客データや過去の購買履歴を取得する ユーザーの操作ログ等の分析のため、外部連携も行う システムはユーザーの入力に応じて以下のアウトプットを生成・提供する ・対象顧客セグメントの抽出結果 ・売上予測データとレポート ・マーケティング用のクリエイティブ素材 ・AIチャットによる質問への回答 Amazon S3およびAmazon Redshift Serverlessに蓄積された顧客行動データを基に、AgentCore上のAIエージェントが推論を行い、その結果を再びデータレイクへフィードバックする循環型アーキテクチャを構築しています。また、「リピートMAX」は、以下の観点でAWSサービスを選定しています。 日本国内リージョンでの運用による セキュリティ確保 豊富なAIサービスによる 開発効率の向上 Amazon Bedrock AgentCore、Amazon S3、Amazon Redshift Serverless、AWS Lambda といったサーバーレスなサービスの採用による 初期投資の最小化 代表取締役の芦塚氏は、AWS のサービス選定理由をこう話します。 ” 従来のCRMの枠を超えた、真にインテリジェントなCRMを実現したいと考えました。そのため、データの統合と活用、コスト最適化、そして施策の自動化という点に重点を置きました。また、セキュリティ面では顧客データの取り扱いに特に慎重な取引先も多く、東京リージョンに閉じた環境を構築できる点が決め手でした。” 開発の体制とプロセスについて DMAの開発責任者岡本氏および福田氏は、開発体制とプロセスについて、以下のように述べています。 ”外部からAWS開発経験のあるエンジニア2名を採用し、アジャイル開発手法を採用してプロジェクトを推進しました。しかし、Amazon Bedrock AgentCoreという新技術の導入において、十分なリファレンスやベンチマークが存在しない中で、試行錯誤を重ねながら設計・実装を進めました。経験者を見つけることは困難で、一度ゼロから再構築しました。この過程を通じて、新技術開発に適したエンジニアの特性やプロジェクト管理の知見を獲得し、Amazon Bedrock AgentCoreの特性理解やデータレイク構築における既存システムとの統合やAI活用最適化のノウハウを蓄積しました。テスト段階では、機能ベースの○×判定に加え、AIチャットの回答精度を評価するシナリオテストを重視し、自社ECプラットフォームの実データを活用した検証や、顧客との協働による分析結果の妥当性確認を実施することで、実用性の高いソリューション開発を実現しました。” 導入効果と今後の展開 AIオートパイロット型CRMプラットフォーム「リピートMAX」を導入された大手百貨店 EC サイトにおいて、以下の効果が得られています。 リピート購入率が125%向上 離脱予兆顧客のCVRが150%以上改善 CRM運用の工数が大幅に削減され、約1時間まで効率化 顧客は AIによる最適なターゲティングとタイミングの自動化により、従来は見逃していた顧客接点を効果的に活用できるようになったと評価しています。 DMAは、このプロジェクトを通じて得られた知見を基に、以下のような機能拡張を計画しています。 より高度なAI予測モデルの導入 クリエイティブ提案機能の強化 まとめ AIオートパイロット型CRMプラットフォーム「リピートMAX」の事例は、技術革新とビジネスニーズの適切な統合を意識しつつ、いかにバランスを取りながら実践的な価値を生み出せるかが分かる好例です。この取り組みが、EC業界におけるDX推進の重要なベンチマークとなること、今後も機能拡充してより多くのEC事業者のビジネス成長に貢献していくことを期待します。 また、内製化でソフトウェアに生成AIや新技術を組み込む上での課題および解決方法は多くの方に参考になるのではないでしょうか。AWSのサービスを活用した本事例は、クラウドネイティブな開発アプローチの有効性を実証する好例です。AI活用をご検討の企業様は、ぜひAWSまでご相談いただければと思います。

本記事は、2025 年 11 月 25 日に公開された How Rivian and Volkswagen Technology Group Built Real-Time Vehicle Security with Amazon Kinesis Video Streams を翻訳したものです。 このブログ記事では、Rivian と Volkswagen Group Technologies (Rivian) が AWS と提携し、Rivian の Gear Guard 機能強化を通じて車両のセキュリティ向上に役立てた方法をご紹介します。 Amazon Kinesis Video Streams (KVS) を使用することで、Rivian はより洗練されたリアルタイムビデオストリーミングソリューションを構築し、車両所有者が Rivian モバイルアプリケーションから車載カメラのライブ映像をより即座にアクセスできるようになりました。 はじめに Rivian は、R1T ピックアップトラック、R1S SUV、Electric Delivery Vans(EDVs) で知られる先駆的な電気自動車メーカーで、自動車ソリューションを絶えず革新しています。Rivian の中核的な製品の 1 つである Gear Guard は、オーナーが不在の際に車両とその内容物を保護するための包括的な機能群です。当初の Gear Guard は、車載カメラと AI アルゴリズムを使用して、不審な人的活動を検知し、ビデオを記録し、Rivian モバイルアプリでオーナーに通知するものでした。これらのビデオと記録は、車両のローカルに保存されていました。この重要なセキュリティ機能の自然な進化として、車両からリアルタイムのライブビデオストリーミングを Rivian モバイルアプリに直接導入することになりました。これにより、オーナーは検知された事象中に即座に視覚的にアクセスできるようになりました。 図1 Rivian Gear Guard キャラクター ライブ動画ストリーミングのビジネス要件と技術要件 Gear Guard のライブビデオストリーミングを実装するには、重要な機能、パフォーマンス、セキュリティ要件に対応できるより堅牢なソリューションが必要でした。このシステムの主な目的は、車両所有者が認証済みのモバイルデバイスから Gear Guard のセキュリティカメラのライブビデオストリームを遠隔で視聴できるようにすることです。車両所有者は、オンデマンドでこのライブビューを開始したり、車両が駐車中、施錠中、無人の状態でも、Gear Guard のアラームシステムからの通知に応じてライブビューを開始したりできます。 Rivian がこの新しいライブ動画ストリーミングサービスを開発する際の主な機能要件は以下のとおりでした: トラックベッドカメラを含む、車両のカメラからのリモート映像の視聴。 特定のカメラを選択するか、カメラの映像を切り替えて表示するモードを選択できる機能。 アラームやモーション検知時にモバイル通知を生成し、最も関連性の高いカメラストリームを選択するボタンとサムネイルガイダンスを表示。 イベントの同時ライブストリーミングと車内ストレージへの録画。 さまざまな携帯通信会社や Wi-Fi ネットワークプロバイダー、モバイル端末に対応。 Rivian が応答性の高いユーザーエクスペリエンスを実現するために重要だった主なパフォーマンス基準は以下の通りです: アクティベーション時間: リクエストからストリーム表示までの時間は 5 秒未満。 ストリーム遅延: カメラキャプチャからモバイル表示までの時間は 1 秒未満。 カメラ切り替え時間: カメラ選択から表示までの時間は 1 秒未満。 Rivian の主なプライバシーとセキュリティの要件は次のとおりでした: エンドユーザーのプライバシーは、Rivian にとって設計プロセス全体を通して最重要の関心事でした。プライバシーの閾値分析とセキュリティ脅威分析が行われました。たとえば、Gear Guard アプリケーションは、サラウンドビューの校正への干渉や望まれないビデオトリガーを防ぐため、工場モードでは無効になっています。さらに、Rivian はストーカー行為への悪用を防ぐため、1 セッションおよび 1 日あたりの使用制限を設けました。 Amazon Kinesis Video Streams の選定理由 複数のオプションを評価した結果、Rivian は機能、パフォーマンス/スケーリング、セキュリティ/プライバシーの要件をすべて満たしていたため、ビデオストリーミングサービスとして Amazon KVS を選択しました。意思決定プロセスで重要だった Kinesis Video Streams の主な機能は次のとおりです。 複数のストリーミングおよびメッセージングプロトコル (Web リアルタイム通信 (WebRTC)、リアルタイムストリーミングプロトコル (RTSP)、ストリーム伝送制御プロトコル (SCTP)) をサポートします。 堅牢なシグナリングインフラストラクチャ – フルマネージドシグナリング、自動スケーリングとコミュニケーション用のチャネルの動的作成をサポートする STUN および TURN サーバー。 包括的な監視機能 – サーバーの正常性と稼働時間のリアルタイム監視、コスト監視、メトリクスとアラートのための Amazon CloudWatch との統合、パフォーマンス追跡用のカスタムダッシュボード作成機能。 セキュリティ – Rivian のセキュリティモデルと適切に統合される AWS セキュリティとその他ネイティブサービスとの組み込み統合。 拡張性 – オープンな標準 API をサポート (例: V4 signer URL を生成して、有効な署名付き一時 URL を生成し、Rivian の IoT およびモバイルデバイスでベンダーニュートラルな機能を許可)。複数の言語でアルゴリズム、クライアント側の実装、およびリファレンス SDK が利用可能です。 パフォーマンス – Native WebRTC は、サブ秒レイテンシーのストリーミングをサポートし、同時に数百万のストリームをサポートするための自動スケーリングと、最適なパフォーマンスのための地域展開をサポートします。 深い技術的コラボレーション – Amazon Kinesis Video Streams サービスチームとの緊密なパートナーシップにより、SDK 統合と SigV4 デバッグ機能が実現し、開発の加速と複雑な実装課題の解決が可能になりました。 システムアーキテクチャ Gear Guard のライブカメラアーキテクチャは、WebRTC を中心に構築されています。WebRTC は低レイテンシーを実現し、双方向のオーディオ/ビデオをサポートしているため、将来的にクライアントから車両への音声インタラクションを可能にする助けとなります。 図2 Gear Guard のテクニカルアーキテクチャ ストリーミングシーケンスを開始 1 認証済みでペアリングされたモバイルアプリケーションのインスタンスがリモートトリガーを開始します。このリモートトリガーはモバイルゲートウェイを経由してクラウド上のリモートコマンドプロセッサに渡され、車両に送信されます。 2 モバイルと車両はそれぞれ、クラウドサービスから署名付きシグナリングサーバーの URL と TURN サーバーの詳細を要求し、Amazon KVS インフラストラクチャに接続できるようになります。 3 Amazon KVS シグナリングチャネルは、車両とモバイルアプリケーション間のピア間 IP アドレスの対話型検索を含む ICE を容易にし、Amazon KVS WebRTC TURN サーバーを経由した接続にフォールバックします。車両のカメラストリーミングとモバイルビューアーアプリケーションは、SDK ハンドシェイクで開始され、直接または間接的な接続を介して送信されるビデオストリームのパラメータを確立するのに役立ちます。 4 車両は WebRTC SRTP (暗号化) チャネルを介して RTSP ビデオストリームをモバイルに転送します。モバイルは WebRTC データチャネルを介してコマンドを送信し、別の SVS カメラから RTSP ストリームを選択できます。 主要な実装の概要 モバイルと車両間のメトリクスとイベントの交換にデータチャネルを使用する。 WebRTC データチャネルを利用することで、モバイルアプリケーションと車両間の情報のより堅牢な双方向の交換が可能になりました。これには、モバイルアプリケーションから車両へのカメラ切り替え要求などのリモートコマンドの送信が含まれ、ユーザーが異なるカメラビューを選択できるようになりました。逆に、ストリーミングセッションの終了を示すセッション終了要求が車両からモバイルアプリケーションに送信されました。さらに、データチャネルはストリーミング開始までの時間などの重要なメトリクスの送信を容易にし、パフォーマンスの監視と最適化を可能にしました。より効率的で構造化された通信を確保するため、このチャネルを介して送信されるすべてのデータは、プロトコルバッファ (protobuf) を使用してフォーマットされました。 シグナリングサーバーの資格情報を配信するための、車両証明書ベースの認証 Go プログラミング言語ベースのクラウドサービスが、一時的な資格情報を持つ SigV4 署名付き URL、TURN と STUN 接続の詳細を車両とモバイルアプリケーションに認証して提供します。これにより、SDP オファーを開始し、ICE 候補を確立できます。リクエストの順序は関係ありませんが、SDP オファーは 5 秒以内に開始する必要があります。車両はサービスに対して mTLS で認証され、その ID は証明書に埋め込まれています。モバイルアプリケーションのリクエストは oauth2 JWT で認証され、ユーザーが要求された車両にプロビジョニングされているかどうかを確認します。 このサービスは、車両の信号チャネルが存在するかどうかを確認するために、マルチリージョン Amazon DynamoDB テーブルを使用し、その後、車両に新しい Amazon Kinesis Video Streams 信号チャネルを提供するか、既存のものを再利用します。Amazon DynamoDB レコードは、30 日間の有効期限を設定するのに役立ち、リクエストごとに更新されます。 Amazon DynamoDB のレコード有効期限切れイベントが Lambda 関数をトリガーし、30 日間使用されていない場合にシグナリングチャネルを削除するのに役立ちます。これにより、Gear Guard サービスのアクティブユーザーを追跡し、プロビジョニングされたリソースのコストを削減するのに役立ちます。wss エンドポイントは SDP オファーを送信するために使用されます。SigV4 署名付き URL には、ChannelARN、ClientId、有効期限、セキュリティトークンなどが埋め込まれています。このサービスには、STUN サーバーと TURN サーバー (UDP、セキュア UDP、TCP) と資格情報も含まれています。 図3 Gear Guard ライブカメラフィード AWS リージョンベースのシグナリングサーバーと TURN サーバーの割り当て: ピア間接続で TURN サーバーを使用する場合、車両の位置と同じ AWS リージョンにシグナリングと TURN サーバーを割り当てたいと思います。これは、米国西海岸に車両とモバイルアプリケーションがあり、シグナリングチャネルが米国東海岸にプロビジョニングされる可能性を回避するためです。組み合わせは次のとおりです。 図4 Gear Guard の地域展開 最適化された実装では、AWS Elastic Kubernetes Service (Amazon EKS) 上で us-east-1 および us-west-2 の両リージョンにデプロイされているクラウドサービスが、カスタムの地理位置情報サービスを使用して、車両がカンザス州レバノン (39°50′N 98°35′W) の東側か西側のどちらに位置するかを特定するのに役立ちます。AWS と Rivian は、この地点を米国の中心地と特定しています (図 4 の破線で示されています)。このサービスは、車両が存在するリージョンに共存するアプリケーションの Kinesis Video Streams シグナリングチャネルをプロビジョニングするのに役立ちます。上記の例 (図 4) では、モバイルデバイスが東海岸または西海岸のどちらにあるかに関係なく、car-01 は us-west-2 にシグナリングチャネルが設定されます。同様に、car-02 は us-east-1 リージョンに設定されます。 プロダクション環境での学び (1 年間の振り返り) 1 年間の運用を経て、以下の重要な知見が得られました。 レイテンシ: WebRTC の選択は、HTTP Live Streaming (HLS) などの他のストリーミングプロトコルよりも低レイテンシストリーミングを実現するのに効果的でした。 複数の視聴者に対するスケーラビリティ: WebRTC のピア・ツー・ピア方式の主な設計上の課題は、各クライアントが一意の暗号化キーを使用した個別の SRTP/SRTCP ストリームを必要とすることです。つまり、2 番目のクライアントが同じ車両からストリームを要求した場合、新しいストリームを開始する必要があり、単一の車両ストリームを複数のピアで直接共有することが制限されます。現在の設計は、ライブ視聴用の 1 つのピア・ツー・ピア接続に最適化されており、シグナリングチャネルごとに最大 10 人の参加者がサポートされています。 コスト管理: 接続サービスを介したユーザー要求に応じたシグナリングチャネルのプロビジョニングと削除の最適化。これにより、機能を使用していないエンドユーザーにシグナリングチャネルが事前にプロビジョニングされることがなくなります。 課題と解決策: ネットワークインターフェースへのバインディング: AWS SDK for C ++ では、ソケット接続に特定のネットワークインターフェースをバインドすることができませんでしたが、Rivian のストリーミング APN はデフォルトのネットワークインターフェースとは異なるため、これは不可欠でした。しかし、SDK はオープンソースなので、Rivian はネットワークバインディングのパッチを作成し、ストリーミングインターフェースにバインドすることができました。 車両のウェイクアップ時間: スリープ中の車両がモバイルコマンドに応答し、ストリーミングを開始するまでの時間を最適化することが、重要なパフォーマンス要件でした。 機能強化と今後の計画 Rivian は、Gear Guard ライブカメラ機能を進化させ続け、次の機能強化を計画しています: ユーザーインターフェースの次世代アップデートには、接続の異なる段階でのユーザーの可視性の向上や、ストリーミング中の車両ネットワーク状況の可視化が含まれます。 適応ビットレートと ICE 再起動などの最適化により、セッション成功率 (この機能の最も重要な KPI) の向上を含め、成功したセッションを強化します。AWS WebRTC SDK はメディアチャネルの TWCC をサポートしており、これを適応ビットレート実装に使用できます。また、SDK は restartIce() をサポートしており、これを使って接続の切断/ネットワークの切り替え時に再接続する予定です。 結論 Rivian の Amazon Kinesis Video Streams を使用した Gear Guard ライブカメラの実装は、所有者のプライバシーを最優先にしながら (Rivian のインフラストラクチャや AWS クラウドにビデオ録画が保存されない)、車両のセキュリティ強化を支援するより高度なソリューションを示しています。WebRTC の低レイテンシと双方向通信機能、Kinesis Video Streams との密接な統合による堅牢なシグナリングと安全な資格情報管理を戦略的に活用することで、Rivian はパワフルなリアルタイムビデオストリーミング体験を実現しました。 Anirban Kundu Anirban Kundu は、Rivian および Volkswagen Technology Group において、データプラットフォーム部門の IoT およびストリーミングのディレクターを務めています。分散型コンピューティングとビッグデータ処理、特にデータ収集とストリーム処理に情熱を注いでいます。過去にはゲノム解析や三次分析、産業用インターネットなど、世界をより良くするという利他的な目標に向けた取り組みに携わってきました。 Adam Arsenault Adam Arsenault は、Rivian および Volkswagen Technology Group のプリンシパルソフトウェアエンジニアである。Rivian 車両と連携する iOS および Android モバイルアプリケーションのエンドツーエンドアーキテクチャと開発に注力している。25 年以上の経験を持つアダムは、顧客を魅了する階層化され信頼性が高くスケーラブルな分散アプリケーションの構築、およびデータとメトリクスを用いた情報に基づいた意思決定に尽力している。 Aditya Purohit Aditya Purohit は、Rivian および Volkswagen Technology Group のスタッフソフトウェアエンジニアであり、スケーラブルでインテリジェントなコネクテッドカーシステムの開発に注力している。組み込みソフトウェアとデータ処理の深い専門知識を活かし、車載コンピューティングとクラウドベースの知見を連携させ、より豊かでリアルタイムなコネクテッドカー機能を実現する取り組みを行っている。EV 技術とエッジ AI の進化に情熱を注ぐアディティアは、車両の知能性、効率性、プライバシー、安全性を高めるシステムの設計を楽しんでいる。仕事以外では、ハイキングやアウトドア探索、新しいスポーツに挑戦する時間を過ごしている。 Asif Khan Asif Khan は、Amazon Web Services のプリンシパルソリューションアーキテクトとして、自動車業界の企業顧客を支援している。自動車産業向けに革新的でコスト効率が高くスケーラブルなソリューションを設計・構築・提供することに情熱を注いでいる。仕事以外では、若手プロフェッショナルのメンタリングや、プロトタイプ構築を通じて新興技術トレンドを把握することを楽しんでいる。 Ajay Paknikar AWS のプリンシパルカスタマーソリューションマネージャーである Ajay Paknikar は、グローバルな自動車顧客をサポートしています。アジャイは、AWS の優れた機能を活用して成功したビジネス成果を確保し、企業の AWS 導入プロセスを導くことに情熱を注いでいます。クライアント経営陣への戦略的アドバイザーとして、クラウド導入とクラウド成熟度の向上に注力しています。 本記事は Senior Solutions Architect の 長谷川 仁志 が翻訳しました。

本記事は 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 原文は こちら です。