1. はじめに 今年、AWS（Amazon Web Services）がAgentic Football Cupを発表しました。これまでにもDeepLens、DeepRacerやAI Leagueなど技術の可能性を体感できるサービスを出してきているAWSらしいサービスとなります。 AWS Summitでブースが出ていたので、担当者の方にいろいろと話を伺ってきましたので、紹介いたします。ただし、本サービスはワークショップは各地域で提供されているようですが、一般公開はされていないため、サービスを体感できるまでにはもう少し待つ必要がありそうです。 なお、本サービスはマルチエージェントで協調

p:has(> img) { width: 100% !important; } はじめに こんにちは、ZOZOMO部FBZブロックの杉田です。普段は Fulfillment by ZOZO が提供するAPIシステムを開発・運用しています。昨年からは、社内における開発者向けAI支援ツールの推進を担う専門チームでも兼務で活動しています。 ZOZOMO部SREブロックの𠮷富です。普段はFulfillment by ZOZOのSREをしています。 2026年6月25日・26日の2日間、幕張メッセにて「 AWS Summit Japan 2026 」が開催されました。本記事では、会場や各ブースの様子に加え、特に印象に残ったセッションについてご紹介します。 目次 はじめに 目次 AWS Summit Japanとは 会場の様子 セッション紹介 AI 駆動開発ライフサイクル (AI-DLC) のご紹介(AIM221) AI生産性のパラドックス 開発手法「AI-DLC」の紹介 実践事例と驚異的な成果 サイバーエージェントにおける AI 推進戦略と変革への取り組み(AIM229) エンジニアの評価制度 全社AI活用を可視化・底上げする「AI番付」の取り組み AIを「楽しむ」文化の醸成 人間がボトルネックにならないための「Human in the Loop」設計 生成 AI ブームのその先へ －AI を使いこなす人材戦略とプラットフォームエンジニアリング－(PRT237-S) 生成AIプロジェクトの成果創出までの「4つの壁」 本番化までの時間と「Governance as code」 生成AI時代の「FinOps」 Amazon S3セキュリティベストプラクティス（STG357） セッションのテーマと背景 S3セキュリティ8つのベストプラクティス 統制の分離とスケール Advanced VPC Networking－知っておきたいAWSネットワークの最新動向：VPC関連サービスのアップデートを総整理－（CDN320） Amazon VPC Latticeのさらなる進化とカスタムDNS対応 AWS Direct Connectとハイブリッド/マルチクラウド接続の強化 ワークフローオーケストレーターにおける複雑性と非決定性のコントロール（CNS454） ワークフローの役割とAWSサービスの紹介 指揮者は歌わない AIエージェントの非決定性を制御するアプローチ まとめ AWS Summit Japanとは AWS Summit Japanは、AWSの最新技術や活用事例を学べる日本最大級のイベントです。2026年も幕張メッセで2日間にわたり開催され、260以上のセッションや展示、ハンズオン、コミュニティ企画など、幅広いコンテンツが用意されていました。AIエージェントやサーバーレス、クラウド活用の最新動向など、今後のシステム設計や運用に関わるテーマが多く取り上げられていました。現地参加だけでなくオンデマンド視聴もできるため、気になるセッションを後から見返すこともできます。 会場の様子 紹介：𠮷富 早い時間から多くの参加者で賑わっていました。基調講演の開始時刻の前後は列が伸び、入場に1時間以上かかることもあったようです。 同僚提供写真 先着5,000名に毎年恒例のクッションとお弁当引換券が配布されました。さらに基調講演の開始前に入場したところ朝食も配布されていました。 いくつかのセッションは入場時に配布されるイヤホンを利用して視聴するサイレントセッションでした。座席に設置されたレシーバーを利用してセッションの音声を視聴できます。 AWS Builders’ FairではAWSサービスを利用したプロジェクトが多数紹介されていました。ゲーム形式のものが多く、楽しく学べました。 「Physical Hands'on Blocks　組んで守れ！　AWSアーキテクチャ」を実際に体験しました。ブロックを動かしアーキテクチャを完成させ、攻撃から守るゲームです。 ELBからEC2を切り離す痛恨のミス Physical AI特設エリアではロボットの実機を体験することができました。 セッション紹介 AI 駆動開発ライフサイクル (AI-DLC) のご紹介(AIM221) 紹介：杉田 AI生産性のパラドックス AIを開発に導入しても速度向上は10〜15％にとどまり、場合によっては「AIを使うと19％遅くなる」というデータが紹介されました。たとえコーディングで時間を節約しても、開発ライフサイクルの他の部分で時間が失われているためです。 AIは決して銀の弾丸ではないので、適材適所で効果的な使い方をしないとかえって状況の悪化を招く場合があると、実感としても強く感じています。この研究結果から、AIに丸投げしたり、逆にAIを単なる補助ツールとして狭く使ったりするだけではダメなのだとあらためて感じました。 開発手法「AI-DLC」の紹介 AIのポテンシャルを最大限に発揮したうえで、ビジネスの意図をソフトウェアシステムとして価値提供できるようにするには、従来の方法の延長線上では限界があります。具体的には、以下のような課題が挙げられます。 人間の関与を最小限またはゼロにした開発は信用が難しく、説明責任も果たすことができない AIによるアジリティは開発ライフサイクル全体では限定的 コーディングで節約した時間は他の部分で失われている これらの課題を解決するためにAWSが再構想したのは「AI-DLC」です。AI-DLCは以下の3つのステップに分かれ、人間の意図伝達、AIによる計画・実行、人間によるレビューや承認という形で進むオペレーティングモデルです。 Inception Construction Operation AI利用を前提とした開発が行われる昨今では、開発プロセス自体をAIネイティブに作り直すというアプローチはとても重要だと思いました。 コンテキストの扱いがポイントとなるAI利用を前提とした開発において、各ステップが次のステップのコンテキストを構築していく流れは、とても理にかなっていると感じました。 実践事例と驚異的な成果 実際の実践事例として、AI-DLCの導入により属人性の高い領域でも開発生産性が200％以上も向上したほか、従来の方法では2か月想定の開発をわずか48時間で達成させた事例が紹介されました。 ここまでの成果を出すには、AI単体の力ではなく、ビジネス、開発、QAなどのチームが垣根を越えて協働する「モブエラボレーション」の体制づくりが不可欠になります。 本セッションを通じて、AIを単なる開発支援のツールとして使う段階は終わったとあらためて痛感しました。適用できそうな領域からAI-DLCの思想を取り入れ、人間とAIが強みを最大化し合う新しい開発プロセスへの移行を検討していきたいと思います。 サイバーエージェントにおける AI 推進戦略と変革への取り組み(AIM229) 紹介：杉田 エンジニアの評価制度 サイバーエージェントでは、2028年の開発プロセス完全自動化を見据え、AIを武器に開発領域からビジネス領域へ越境する「ビジネスリードエンジニア」などを新設していました。技術のみならず課題発見から実装・運用までを一気通貫で担える人材を正当に評価する枠組みです。 詳細については、以下のブログに記載があったので、気になる方はご覧ください。 developers.cyberagent.co.jp AIの台頭により、コーディングそのものの価値が相対的に変化している中で、エンジニアのキャリアパスを組織主導で再定義している点が印象的でした。AI時代においてエンジニアが目指すべき姿を考えるうえで、参考になる評価軸だと感じました。 全社AI活用を可視化・底上げする「AI番付」の取り組み 各事業部におけるAI活用の「成果インパクト」や「カルチャー醸成」などを、相撲の番付表（横綱〜幕下）に見立てて評価・可視化している取り組みが紹介されました。 単にツールを導入して終わるのではなく、組織ごとの成熟度を定量・定性的に測る仕組みを作ったうえで、全社的なナレッジ共有と底上げを図る非常に効果的なアプローチだと感じました。特に、結果を分析レポートとしてまとめ、事業ごとの改善案を提案する仕組みは参考になりました。 AIを「楽しむ」文化の醸成 AIをフル活用して実装速度を競う「AI開発RTA」や、2日間でゼロからプロダクトを作る「AI Agent Arena」を開催した様子が紹介されました。これらのイベントを通じて、エンジニアがAIに楽しく触れる場を提供し、ベストプラクティスの創出・共有を促していました。 利用を強制するのではなく、イベントを通じて「AIフレンドリー化」を推進する姿勢は、組織の熱量を高める取り組みとして参考になりました。 人間がボトルネックにならないための「Human in the Loop」設計 自動化が進むと人間の監視が形骸化する「プロセスの萎縮」というリスクがあります。このリスクに対して、タスクのリスクに応じて「全件レビュー」「スコアベース」「エスカレーション」の3パターンで人間の関与を設計している取り組みが紹介されました。 タスクに関係なく一律でHuman in the Loopを採用するのではなく、リスクや複雑さを加味したうえで段階的にHuman in the Loopを設計している点が参考になりました。 サイバーエージェントの取り組みは、ツールの導入にとどまらず、評価制度、企業文化、そして開発プロセスそのものをAI時代に適合させていくといったものでした。AIと協働する新しい開発組織のあり方については、私の所属組織でも重要なテーマなので、今後の活動の参考になるセッションでした。 生成 AI ブームのその先へ －AI を使いこなす人材戦略とプラットフォームエンジニアリング－(PRT237-S) 紹介：杉田 生成AIプロジェクトの成果創出までの「4つの壁」 同社のアンケートから、2024年から2025年にかけて生成AIの活用率は増加している一方で、DXの成果について「期待通り以上」と回答した割合は減少していることが確認できました。 また、PoCの成功はゴールではなく、その先には「本番化までの時間」「LLMの精度不足」「利用が広がらない」「想定外のコスト増」という4つの壁が存在すると指摘されていました。 本番化までの時間と「Governance as code」 セキュリティやコンプライアンスの都度審査により、本番の開発開始までに数か月を要するケースがあると紹介され、これは組織の規模感が大きくなることでより顕著になる傾向があります。対策として、ガバナンス要件を組み込んだ開発テンプレート（Governance as code）を用意し、事前承認済みの型を開発者に利用させるアプローチが紹介されました。 守りのプロセスを自動化・テンプレート化して、開発者の認知負荷を下げる取り組みはまさにプラットフォームエンジニアリングの真骨頂だと思いました。Governance as codeは、社内での車輪の再発明を回避する手段として、OSSで有名な Backstage をはじめとした開発者向けポータルとの相性が良いと感じました。 生成AI時代の「FinOps」 生成AIの利用拡大に伴い請求額が想定の数倍に膨らむリスクに対し、コストの可視化とプロンプトキャッシング等の対策が紹介されました。 プロンプトキャッシングの仕組みとして、キャッシュは先頭から一致した場合のみヒットするため、プロンプトの上部に変数（可変部）が存在すると効果が薄くなる点について解説されました。 そこで、この性質を活かすために可変部をプロンプトの下部に移動させる構造変更をしたことで、1ワークフローあたり400円かかっていたコストが80円（80％削減）へと劇的に改善した事例が紹介されました。 機能としてキャッシングを有効にするだけでなく、内部の仕組みを理解してキャッシュヒット率を最大化している点は学びでした。生成AIを活用するうえで、それらのコストは切っても切り離せない課題だと思うので、機能を使いこなすことによるコストインパクトに驚きました。 Amazon S3セキュリティベストプラクティス（STG357） 紹介：𠮷富 Amazon S3はシステム構成において、データ保存先、ログ出力先、バックアップ、データ連携基盤など、さまざまな場面で利用されています。利用用途が増えるにつれて、アクセス制御や利用者・アプリケーションごとの権限管理、意図しない公開の防止など、セキュリティ面で考慮すべきポイントも増えていきます。 このセッションでは、Amazon S3のセキュリティを高めるためのベストプラクティスを改めて学べました。 セッションのテーマと背景 パブリックアクセスのブロック（BPA）や全新規オブジェクトの暗号化などがデフォルトで有効になっており、データを安全に活用しやすいデフォルト設定が用意されています。 S3セキュリティ8つのベストプラクティス データ保護を実現するためのプラクティスとして以下が提示されました。 パブリックアクセスをブロックする 。 バケットキーを有効にする ：SSE-KMS利用時のAWS KMSコストを最大99％削減。 統制を分離してスケールする 。 セキュリティ変更をモデル上でテストする 。 AWS Organizationsを活用する ：RCP/SCPによる組織レベルの強力なガードレールを適用。 データ保護をアプリケーションにも広げる ：チェックサムの活用など、アプリケーション側でもデータ保護を考慮する。 ログを有効にする ：異常検知や自動修復などの対応を実装する。 耐久性とリカバリを事前に計画する 。 統制の分離とスケール ビジネスや組織の成長に合わせて、権限管理における統制を分離する必要があります。単一のバケットポリシーだけですべてを管理しようとすると保守が難しくなりやすいため、以下の機能を活用して権限を適切に委譲・分割する考え方が紹介されていました。 S3 Access Points ：ユースケースごとに独自のポリシーを持たせる。 S3 Access Grants ：特定のプリンシパルに対して、バケットやプレフィックスへのアクセス権をプログラムで付与する。 ABAC（属性ベースアクセス制御） ：リソースやプリンシパル名ではなく、タグに基づいてセキュリティポリシーを定義する。 S3のセキュリティはバケットの設定だけで完結するものではなく、組織全体のガバナンスやアプリケーション側も含めて設計する必要があることを再認識しました。紹介されていた内容の中には、パブリックアクセスブロックや暗号化、ログ設定など、既存のバケットでもすぐに確認できる項目が多くあります。S3を利用している環境がある場合は、ぜひこの機会に設定状況を見直してみてください。 Advanced VPC Networking－知っておきたいAWSネットワークの最新動向：VPC関連サービスのアップデートを総整理－（CDN320） 紹介：𠮷富 このセッションでは、VPCやネットワーク関連サービスにおける2025年のアップデートを網羅的にキャッチアップできました。普段VPCを触っている人ほど、こんなにアップデートがあったのかと驚く内容だったと思います。紹介量が多く見応えのある内容だったので、ネットワーク構成に関わる方はぜひチェックしてみてください。特に気になったアップデートを2つ紹介します。 Amazon VPC Latticeのさらなる進化とカスタムDNS対応 VPC Lattice は、複数のVPCやアカウントをまたぐサービス間通信を論理的にグループ化（サービスネットワーク）してつなぐ機能です。これまではサービスやリソースに自動生成された一意のFQDNが割り当てられていましたが、2025年のアップデートとして、カスタムDNS名や設定可能なIPに関する機能強化が紹介されていました。自分で設定したDNS名によるアクセスが可能になり、既存のアプリケーションからのアクセスルーティングがやりやすくなります。 AWS Direct Connectとハイブリッド/マルチクラウド接続の強化 マルチクラウド接続を容易にする「AWS Interconnect Multicloud/Last Mile」が一般提供（GA）を開始しました。Direct Connectを経由してオンプレミス環境や他クラウド、AWS上のアプリケーションを接続しやすくなり、ハイブリッド/マルチクラウド環境におけるネットワーク設計の選択肢が広がりました。 VPC関連サービスでは、2025年だけでも150以上の新機能が追加されたそうです。このセッションはVPC周辺の最新情報をまとめてキャッチアップする良い機会になりました。 2024年のVPC関連サービス 2025年のVPC関連サービス ワークフローオーケストレーターにおける複雑性と非決定性のコントロール（CNS454） 紹介：𠮷富 ワークフローは事業の成長、システムの改修に伴って複雑になってしまうことがあります。さらに障害の監視・管理やリトライ処理といった例外的な処理の整備によりシステムが複雑化したり、それらの解決のためにあらゆるシステムでAI・MLとの結合が求められたりするようになっています。 このセッションでは、複雑化しがちなワークフローの管理手法と、AIエージェント特有の「非決定的」な挙動をどう扱い、どのようにアーキテクチャに組み込むべきかを学べました。 ワークフローの役割とAWSサービスの紹介 ワークフローは、複雑なシステム連携における例外処理・リトライ・並列処理・Map実行などの課題に対応し、可観測性（オブザーバビリティ）を高めるために用います。セッションでは、要件に応じたAWSの主要なワークフローオーケストレーションサービスの使い分けが紹介されました。 AWS Step Functions ：GUI上でワークフローを視覚的に設計できるサービス。JSONataに対応しており、ステートマシン内でデータの変換・抽出・加工を行える。 AWS Lambda durable functions ：JavaScript/TypeScriptやPythonなどで、長時間実行されるワークフローをコードとして記述できる仕組み。最大1年の実行に対応し、リトライや状態管理を扱いやすい。 Amazon MWAA ：Apache AirflowをAWS上で利用できるマネージドサービス。DAG（有向非巡回グラフ）によってタスクの依存関係や実行順序を管理でき、AWS外のシステム連携にも向いている。 指揮者は歌わない 複雑性保存の法則 が示す通り、システムが持つ複雑さを完全に消し去ることはできません。重要なのは「複雑性をどこに置き、どうコントロールするか」であり、その基本方針がワークフローの分割です。そこであげられていたのは「指揮者は歌わない（関心の分離）」という設計原則です。 例えばStep FunctionsのChoice stateに複雑なメール検証のような検証ロジックを書くと、保守が困難になります。オーケストレーターは進行管理に徹し、ビジネスロジックはAWS Lambdaなどのコード側に切り出すべきです。 AIエージェントの非決定性を制御するアプローチ ワークフローにとってAIは、予期せぬ判断や無限ループを引き起こす可能性のある「非決定的」なシステムです。この揺らぎをシステムに組み込む方法として、決定論的ワークフローで包み込むアプローチが紹介されました。 Outer/Inner Loopパターン：AIの非決定論的な推論を、タイムアウトやリトライを備えたワークフローで制御。 Human in the Loop（HITL）パターン：重要な判断はAIに任せきらず人間の承認フローを挟む。 Workflow as Toolsパターン：既存の決定的なワークフローを、AIから安全なツールとして呼び出す。 また、Amazon BedrockなどのAIサービス利用時は、スロットリング対策としてExponential BackoffやJitterの活用が重要です。 Exponential Backoff リトライ間隔を指数関数的に増加させることで、サーバーの負荷を軽減する。 Jitter リトライ間隔にランダムな揺らぎを加えることで、同時リトライを防ぐ。 AIエージェントを利用する場合でも「処理を適切な単位で分割・委譲する」という設計の基本が大切なことを再認識しました。 まとめ 今回のAWS Summit Japan 2026を通じて、AI活用を前提にした開発・運用のあり方を改めて考える機会になりました。 生成AIは単なる開発支援ツールではなく、開発プロセス、組織文化、評価制度、ガバナンス、コスト管理まで含めて向き合うべきテーマになっていると感じました。一方で、AIエージェントのような非決定的な仕組みを安全に扱うためには、Human in the Loopや決定論的なワークフローによる制御など、従来から大切にされてきた設計原則も引き続き重要です。また、S3やVPCといった基盤領域についても、サービスの進化に合わせて継続的に設計や設定を見直す必要性を再認識しました。 今回得た学びを、日々の開発・運用だけでなく、社内でのAI活用推進にも活かしていきたいと思います。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

本記事は 2026 年 7 月 2 日 に公開された「 Amazon Redshift RG: Faster and lower cost, Graviton-powered 」を翻訳したものです。 Amazon Redshift は、Graviton プロセッサを搭載した新しいインスタンス RG の一般提供を開始しました。Amazon 独自の Graviton プロセッサ上に構築された RG は、以下を実現します。 データウェアハウスワークロードで RA3 と比較して最大 2.2 倍高速なパフォーマンス 統合されたベクトル化データレイクエンジンにより、Iceberg クエリで最大 2.4 倍、Parquet クエリで 1.5 倍高速 データレイククエリに対する TB あたりのスキャン料金が不要。RA3 クラスターに適用されていた Amazon Redshift Spectrum のコストを排除 RA3 と比較して vCPU あたりのコストが 30% 低減 RG はより高速かつ低コストです。一般的にクラウドベンダーは高速なパフォーマンスや新世代ハードウェアに対してより高い料金を設定しますが、Amazon Redshift はより高いパフォーマンスをより低いコストで提供します。 本記事では、RG インスタンスが高速な理由を説明します。また、RG が他の主要データウェアハウスと比較して最大 4.2 倍優れたプライスパフォーマンスを実現するベンチマーク結果も紹介します。 RG が高速な理由 新しい RG インスタンスは、Graviton プロセッサの性能を最大限に活用するためにゼロから設計されています。Amazon Redshift のベクトル化エンジンは Graviton ベースの SIMD (Single Instruction, Multiple Data) カーネルで最適化されており、分析ワークロードに対して高速で並列化された実行を実現します。Parquet エンコーディングに対する述語評価などの操作では、Graviton のベクトル比較、テーブルルックアップ、ベクトル操作のインストリンシクス（組み込み命令）を活用しています。処理速度の向上を支えるため、RG インスタンスはカスタムビルドの Nitro SSD を使用します。高速なローカルストレージをキャッシュレイヤーとして活用し、 Amazon Redshift Managed Storage (RMS) やデータレイクスキャン、メモリに収まらない計算の中間結果セットに対応します。また、RG の JIT (Just-In-Time) Analyze 機能は、クエリの実行中にデータレイクファイルの統計情報を自動的に収集・保存するため、オプティマイザが大幅に優れたクエリプランを生成できます。ハードウェアアクセラレーション (Graviton)、ベクトル化実行 (SIMD カーネル)、高速ストレージ (Nitro SSD)、適切なクエリプランニング (JIT Analyze) と、スタック全体で最適化を実現しています。 上記の最適化と、RG 専用に構築された高性能ベクトル化データレイクエンジンの組み合わせにより、Amazon Redshift の RG インスタンスは分析ワークロードで RA3 と比較して最大 2.2 倍高速に動作し、コストも 30% 低く抑えられます。 専用の高性能ベクトル化データレイクエンジン RA3 では、データレイククエリのスキャンを Amazon Redshift Spectrum と呼ばれる別のコンピュートフリートにオフロードしていました。データレイククエリが別のコンピュートで実行されるため、RA3 クラスターと Spectrum フリート間でクエリメタデータや結果を転送する際に追加の負荷が発生していました。Amazon Redshift RG インスタンスには、データレイク向けにゼロから設計された、まったく新しい組み込みスキャンレイヤーが含まれています。新しいスキャンレイヤーには、データレイテンシーを削減するスマートプリフェッチ機能を組み込んだ専用 I/O サブシステムが含まれます。また、Iceberg で最も一般的に使用されるファイル形式である Apache Parquet の処理に最適化されており、Graviton 向けに最適化された SIMD カーネルによる高速なベクトル化スキャンを実行します。スキャンレイヤーには、パーティションレベルとファイルレベルの両方で動作する高度なデータプルーニングメカニズムが含まれており、スキャンが必要なデータ量を大幅に削減します。プルーニング機能はスマートプリフェッチシステムと連携して動作し、データ取得プロセス全体の効率を最大化します。 新しい専用ベクトル化データレイクエンジンは、Iceberg クエリで RA3 と比較して最大 2.4 倍、Parquet クエリで 1.5 倍高速です。 新しいベクトル化データレイクエンジンは Amazon Redshift のコア実行エンジンに直接統合されているため、RA3 と比較して新たなパフォーマンス最適化が可能です。この統合アーキテクチャにより、RG でのデータレイククエリは高速なローカルデータキャッシュ、改良されたブルームフィルタ、ベクトル化 Parquet スキャン、高度なフィルタリングとプルーニングの恩恵を受けられます。 RG は、データレイクのクエリでお客様が直面する一般的な問題も解決します。Amazon Simple Storage Service (Amazon S3) 上の Iceberg などのオープンフォーマットファイルには有用なメタデータや統計情報が不足していることが多く、SQL クエリを最適に実行することが困難でした。 統計情報とは、個別値の数、最小値/最大値、分布パターン、行数などのデータに関するメタデータです。クエリオプティマイザはこの情報を使用して、クエリの最も効率的な実行方法を選択します。たとえば、2 つのテーブルを結合する際、オプティマイザは適切な結合戦略を選択するために各側が生成する一意の値の数を把握する必要があります。統計情報がなければ推測に頼ることになり、多くの場合、結合が遅くなりノード間で不要なデータ移動が発生します。ここで Amazon Redshift の新機能 JIT (Just-In-Time) Analyze が役立ちます。RG インスタンスはクエリの実行中に Iceberg ファイルの統計情報を自動的に取得・保存するため、Amazon Redshift は統計情報がない場合と比較してはるかに最適化されたクエリ実行戦略を選択できます。 Iceberg や Parquet データのスキャンが RA3 よりも大幅に高速になります。Amazon Redshift Spectrum のコンピュートが不要になったことで、RG インスタンスではデータレイククエリの $5/TB のコストも排除されます。データレイククエリがより安価になり、コストの予測も容易になります。パフォーマンスの向上、コンピュートコストの低減、TB あたりのスキャンコストの撤廃という 3 つのメリットにより、データレイクのプライスパフォーマンスが大幅に改善します。 データロードの高速化によるインサイト取得の迅速化 Amazon Redshift RG の高速 I/O と Graviton 最適化エンジンにより、RA3 と比較してデータロードが高速化されています。パフォーマンス改善を測定するため、同等サイズの RA3 と RG クラスターで 10TB TPC-DS および TPC-H のデータ取り込みステップを実行しました。RG は TPC-DS データセットを 2 倍高速に、TPC-H データセットを 1.4 倍高速に取り込みました (次の図を参照)。 新しい Graviton ベースの RG インスタンスは、RA3 インスタンスと比較してデータロードが最大 2.0 倍高速です。ワークロードはより早く最新データを取得でき、ユーザーやエージェントはより迅速に最新のインサイトを得られます。RG でのデータ取り込み高速化は RA3 と比較して 30% 低いコストで実現されており、データロードのプライスパフォーマンスは RA3 インスタンスと比較して最大 2.9 倍です。 お客様の声 Amazon Redshift のお客様は、RG への切り替えによるパフォーマンスとコストのメリットをすでに実感しています。Southwest Airlines と tombola はビジネスクリティカルなワークロードでテストを行い、パフォーマンスの向上とコスト削減を確認しました。 Southwest Airlines 「Amazon Redshift RG インスタンスは、Southwest Airlines に大きなビジネスインパクトをもたらす可能性があります。開発環境での初期テストでは、データウェアハウスワークロードが 50〜60% 高速化し、データレイク分析は 45% 高速化しました。チームはより早くインサイトを得て、運用状況に迅速に対応し、低レイテンシーでデータドリブンな意思決定を行えるようになります。これらの初期結果は期待が持てるもので、本番環境での検証とスケールアップが楽しみです。さらに、TB あたりの Spectrum スキャン料金が不要になり、燃料価格が業界のマージンを圧迫し続ける中、RA3 と比較して 30% のコスト削減を実現しています！」 — Sean Lynch、Vice President, Data and Architecture、Southwest Airlines tombola 「Graviton ベースの Amazon Redshift RG インスタンスは、バッチジョブと分析ジョブの多様なセットで、RA3 と比較して 1.8〜2 倍の書き込みスループットと最大 2.2 倍の読み取り速度を実現しました。同じ時間枠で 40% 多くの処理が可能になりました。ETL サイクルが短縮され、インサイト取得までの時間が加速し、パイプラインによる意思決定のボトルネックがなくなりました。これらの改善により、アナリストやビジネスチームにより新鮮なデータがより早く届くようになりました。さらに魅力的だったのは、パフォーマンス向上と同時にコンピュート費用が 30% 削減されたことです。より少ないコストでより多くを実現するのは稀な成果であり、強調する価値があります。クエリレイテンシーとコストがスケールに伴い複合的に影響する tombola のような大量データを扱うゲーム業界では、今年最もインパクトのあるプラットフォーム決定の一つとなりました。」 — Akshay Srinivasan、Data Engineer、tombola Qoala 「Amazon Redshift クラスターを RA3 から Graviton ベースの RG インスタンスに移行した結果、BI および分析ワークロード全体でクエリ処理時間が 60〜70% 高速化しました。数百万件の保険契約トランザクションを処理する成長中のインシュアテックプラットフォームとして、インサイト取得までの時間短縮は、データチームがダッシュボードやレポートをより早くビジネスに届けられることを意味します。将来の成長に対応するためにより大きなノード構成に移行しましたが、パフォーマンスの向上は追加投資をはるかに上回り、今年最もインパクトのあるインフラストラクチャ決定の一つとなりました。」 — Umar Abdul Aziz、VP of Data、Qoala パフォーマンス結果 RG の実力を確認するため、業界標準の TPC-DS および TPC-H ベンチマークをベースとしたベンチマークを 10TB スケールで、新しい Amazon Redshift RG インスタンスおよび主要な代替データウェアハウスで実行しました。ベンチマークは、アドホック、レポーティング、反復的なオンライン分析処理 (OLAP)、データマイニングなど、さまざまな運用要件と複雑性を持つクエリを実行するよう設計されています。各データウェアハウスをほぼ同じオンデマンドコスト ($32/時間) でサイジングし、特別なチューニングやカスタマイズなしにそのままの状態で 3 回のパワーランを実行しました。結果は以下のチャートのとおりです。 新しい RG インスタンスが大差をつけてリードしています。プライスパフォーマンスが優れているということは、パフォーマンスが高く、 かつ コストが低いことを意味します。 まとめ Amazon Redshift RG インスタンスは次世代の分析エンジンであり、データウェアハウスとデータレイクワークロードに高いパフォーマンスを提供します。RG は RA3 と同じワークロードと機能をすべてサポートしているため、利用開始は簡単です。アップグレードして、より低コストでより高いパフォーマンスを得る方法については、 移行ガイド を参照してください。 ワークロードに最適なプライスパフォーマンスを見つける 本記事で使用したベンチマークは、業界標準の TPC-DS および TPC-H ベンチマークをベースとしており、以下の特徴があります。 TPC-DS および TPC-H のスキーマとデータを変更せずに使用しています。 クエリは公式の TPC-DS および TPC-H キットを使用し、キットのデフォルトのランダムシードで生成されたクエリパラメータで生成されています。デフォルトクエリの SQL ダイアレクトをサポートしていないデータウェアハウスでは、TPC 承認済みのクエリバリエーションを使用しています。 テストには TPC-DS の 99 個の SELECT クエリと TPC-H の 22 個の SELECT クエリが含まれます。メンテナンスとスループットのステップは含まれません。 3 回のパワーランを実行し、各データウェアハウスで最も良い結果を採用しています。 プライスパフォーマンスは、時間あたりのコスト (USD) を 1時間あたり 3,600 秒で割り、ベンチマークの幾何平均 (秒) を掛けて計算します。これはクエリあたりの幾何平均コストに相当します。すべてのデータウェアハウスで最新の公開オンデマンド料金を使用しています。 Cloud Data Warehouse ベンチマークと呼ばれるこのベンチマークの結果は、 GitHub リポジトリ で公開されているスクリプト、クエリ、データを使用して再現できます。本記事で説明したとおり TPC-DS ベンチマークをベースとしていますが、公式仕様に準拠していないため、公開済みの TPC-DS 結果とは比較できません。 著者について Stefan Gromoll Amazon Redshift チームのプリンシパルエンジニアで、Redshift のパフォーマンスを担当しています。プライベートでは料理、4 人の息子たちとの遊び、薪割りを楽しんでいます。 Ankit Sahu データ製品やサービスの構築に 18 年以上の経験を持ち、プロダクト戦略、Go-to-Market 実行、デジタルトランスフォーメーションの幅広い経験があります。現在は Amazon Web Services (AWS) のシニアプロダクトマネージャーとして、Amazon Redshift のビジョンと戦略を推進しています。 Mohammed Alkateb Amazon Redshift のエンジニアリングマネージャーで、クエリ最適化、データレイクアクセス、パフォーマンスエンジニアリング、新しいインスタンスの検証にわたるソフトウェアエンジニア、アプライドサイエンティスト、Amazon Scholar のチームを率いています。Amazon 入社前は Teradata のオプティマイザチームに 12 年以上在籍。バーモント大学で博士号を取得し、主要なデータベースカンファレンスでの論文発表や米国特許を多数保有しています。 Yousuf Hussain Amazon Redshift のシニアソフトウェアエンジニアで、大規模クラウドデータウェアハウスシステムの構築と運用に 11 年の経験があります。分析に情熱を持ち、Amazon Redshift のお客様に高パフォーマンスな体験を提供するためにインスタンス戦略、可用性、信頼性に注力しています。 Nita Shah ニューヨーク拠点の AWS シニアアナリティクススペシャリストソリューションアーキテクトです。20 年以上にわたりエンタープライズデータプラットフォーム、データウェアハウス、分析ソリューションを構築しており、Amazon Redshift を専門としています。エンタープライズ規模の Well-Architected な分析・意思決定支援プラットフォームの設計と構築を支援しています。 Sanket Hase Amazon Redshift チームのエンジニアリングマネージャーで、データレイク分析、ハードウェア・ソフトウェア協調設計、ベクトル化クエリ実行に焦点を当てたクエリ実行チームを率いています。カーネギーメロン大学でコンピューターサイエンス修士号を取得し、データベースシステム分野で複数の米国特許を保有しています。 Jingbo Zhang Amazon Redshift のデータエンジニアで、新しいインスタンスの検証とパフォーマンスバリデーションを担当しています。RG、r8gd、r7gd を含む複数の Graviton ベース Redshift インスタンスファミリーの検証とローンチに貢献し、ベンチマーク、パフォーマンス分析、自動化に注力しています。カーネギーメロン大学でデータアナリティクス修士号を取得しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。