re:Invent 2024: Amazon Redshiftによるデータウェアハウスのモダナイゼーション
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Modernize your data warehouse by moving to Amazon Redshift (ANT345)
この動画では、Amazon RedshiftのSenior Product ManagerのRaza Hafeezが、データウェアハウスのモダナイゼーションについて解説しています。AWS Analyticsの概要とAmazon Redshiftの新機能を紹介した後、ZalandoとADPの事例を詳しく取り上げています。ZalandoはData Sharingを活用したマルチウェアハウスアーキテクチャを実装し、クエリの76%で高速化を実現。ADPは5万社以上の顧客向けにPeople Analyticsソリューションを提供し、Row-Level SecurityとSession Context変数を活用したマルチテナンシー環境を構築し、30%のコスト削減を達成しました。Amazon RedshiftとAWS Analyticsの組み合わせにより、データの取り込みから分析、AI/MLまでをシームレスに実現する方法が具体的に示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon Redshiftを活用したデータウェアハウスのモダナイゼーション：セッション概要
皆様、こんにちは。Re:Inventでお楽しみのことと思います。今は17時30分で、皆様お疲れのことと思いますが、見覚えのあるお顔も何人か拝見しています。手を挙げていただきたいのですが、Data Warehouseを使用したことがある方はどのくらいいらっしゃいますか？では、この会場が適切ですね。では、Data Warehouseのモダナイゼーションを計画中、あるいは現在進行中の方は？素晴らしいですね。まさに最適なセッションを選んでいただきました。17時30分からのセッションとなり、大変申し訳ございません。朝の早い時間帯に、皆様がお元気で集中できる状態でご参加いただきたかったのですが、残念ながらこの時間帯となってしまいました。
私はAmazon RedshiftのSenior Product ManagerのRaza Hafeezと申します。Amazon Redshiftの新機能の開発を担当しています。本日は、Zalando SEのSebastian Herold氏とADPのRavi Tadysetty氏にもご参加いただき、お客様がAmazon Redshiftのパワーを活用してビジネス価値を創出するために、どのようにData Warehouseをモダナイズできるかについてご説明させていただきます。 まず、AWS AnalyticsとAmazon Redshiftの概要を手短にご紹介します。その後、Amazon RedshiftとAWS Analyticsにおける主要な機能のアナウンスメントと、私たちのイノベーションのハイライトをご紹介します。そして、お客様がどのようにAmazon Redshiftを活用してビジネスを推進できるかについて、実際のユースケースをご紹介します。SebastianがZalandoがAmazon Redshiftを使用してData Warehouseをどのようにモダナイズしたかについて、そしてRaviがADPがAnalyticsスタックをモダナイズするためにAmazon Redshiftをどのように活用したかについて、その変革の旅をご紹介します。
データの重要性とAWS Analyticsの役割
データは、あらゆるビジネスプロセスの中核であり、重要なビジネス判断を導くものです。また、多くの組織にとってデジタルトランスフォーメーションの基盤ともなっています。さらに、データはGenerative AIの重要な構成要素となっています。お客様はGenerative AIを活用してデータモデルを強化していますが、データモデルの品質は、その基盤となるデータ基盤の品質に大きく依存します。そのため、強固なデータ基盤の構築は、ビジネスとGenerative AIの両方にとって極めて重要です。最近の調査によると、97%の経営者がGenerative AIは自社の業界を変革すると述べており、67%の組織がGenerative AIとデータへの投資を増やす予定だと回答しています。
しかしながら、データの力を活用することは依然として課題となっています。Accentureの調査によると、データから価値を引き出すことができている組織はわずか32%に留まっています。これは、データシステムがサイロ化し、複雑化し、散在しているためです。データはData Warehouse、Data Lake、運用データソース、さらにはオンプレミスシステムやSaaSアプリケーションなど、様々な場所に分散しています。「このデータはどこから来たのか？」とITアドミニストレーターに尋ねたことがある方はいらっしゃいますか？誰もが頭の中で考える質問ですよね。そして、データを入手した後の次の質問は、「誰がこのデータにアクセスできるのか」です。データが散在しているため、ガバナンスも課題となります。
そこでAWS Analyticsの出番です。AWS Analyticsは、エンドツーエンドのデータ戦略を提供し、多様なソースからデータを取り込み、処理し、分析して、Spark、SQL、AI/ML、Generative AIなど、目的に応じたデータソースやAnalyticsツールを使用して、ゲームチェンジングなインサイトを見出すことができます。また、AWS Analyticsは包括的なセキュリティとガバナンスのフレームワークを提供し、データのエンドツーエンドのセキュリティを確保します。お客様は、AWS Analyticsのパワーを活用して、ビジネスを推進し、可能な限り迅速に成長を実現しています。
</transcript>
この強力な分析基盤を基に、AWSは次世代のAmazon SageMakerを導入しました。次世代のAmazon SageMakerは、データ分析とAIの機能を統合した統一プラットフォームで、統合されたStudioを使用してより迅速なコラボレーションとソリューション構築を実現します。Amazon Redshift、Amazon S3などの使い慣れたAWSツールを活用し、オープンなLakehouseアーキテクチャを採用することで、データウェアハウス内のデータだけでなく、すべてのデータにアクセスできるようになり、サイロ化を軽減できます。次世代のAmazon SageMaker内では、すべてのデータが端から端まで確実に安全に管理されています。
Amazon Redshiftの革新的機能と進化
Amazon Redshiftは、数万社のお客様にサービスを提供している、最もコストパフォーマンスの高いSQLエンジンです。企業はAmazon Redshiftを使用して、テラバイトからペタバイト規模の構造化データと非構造化データを統合し、大規模な分析を行っています。お客様のニーズを起点に考え、私たちはいくつかの重要な分野でイノベーションを進めてきました。そのイノベーションの中心となっているのが、Data Sharingを活用したMulti-warehouseアーキテクチャで、組織全体でのシームレスで安全なデータ共有を実現します。このアーキテクチャは、リソースのワークロード分離にも役立ち、リソースの競合を減らすことで、Redshiftのスケーラビリティ、パフォーマンス、コスト効率を向上させています。さらに、Amazon Redshiftは、高いクエリパフォーマンスを実現する分析最適化されたカラム形式でのデータ保存に加え、Apache Icebergなどのオープンテーブル形式もサポートしています。
運用データソースやAmazon S3からのデータ取り込みに必要な複雑なデータパイプラインの管理を不要にするZero-ETLやAuto-copyなどの機能を導入しました。多くのお客様が分析用のデータウェアハウスへのデータ取り込みに苦労していましたが、これらの機能により、取り込みパイプラインを管理することなく、シームレスにデータを分析できるようになりました。Amazon Redshiftでは、ユーザーが好みの分析スタイルでデータを分析できます。ビジネス開発者でもエンジニアでも、SQL、Spark、さらにはAI/MLや生成AIを使用してワークロードを実行できます。
私たちのイノベーションは、いくつかの重要な分野に焦点を当ててきました。価格性能、スケーラビリティ、セキュリティの面では、Data Sharing ReadsとData Sharing Writesを導入し、複数のRedshiftデータウェアハウス間で、他のコンピュートクラスターを通じた読み取りと書き込みの両方の機能を持つワークロード分散を可能にしました。自律的なワークロード管理を強化し、お客様がワークロードのチューニングを心配する必要がないようにしました。また、データレイクとRedshift間でのSQLをシームレスにし、SQLやSparkなど、お好みの分析ツールを使用してすべてのデータにアクセスできるようにしました。Zero-ETL、Auto-copy、ストリーミング取り込みなどの機能を導入することで、データ取り込みを効率化し、Amazon Redshiftにデータが到着するとほぼリアルタイムで分析できるようになりました。Amazonサービスでのスケーリングをよりインテリジェントにし、より広範なワークロードをサポートするためにコンピュート容量を拡大することで、データ分析ワークロードを簡素化しました。より幅広いワークロードにAmazon Redshiftを活用できるようになっています。
さらに機能を強化するため、お客様が分析ワークロードで生成AIのパワーを活用できるよう、Amazon RedshiftとGenerative AIの統合を目指しました。まずAmazon Bedrockとの統合を行い、Amazon Qを含む2つの機能を追加しました。これにより、自然言語で質問すると自動的にSQLに変換されるようになりました。複雑なSQLを書く必要はもうありません。過去1年間のデータを特定の次元や日付範囲でスライスして表示するよう依頼するだけで、Amazon Redshiftがそのデータを提供してくれます。
こうしたイノベーションにより、お客様は従来のBusiness Intelligenceやレポーティングを超えて、Amazon Redshiftを幅広いユースケースで活用できるようになりました。お客様はセルフサービス機能を備えたモダンなデータアーキテクチャの構築にAmazon Redshiftを活用しています。また、ハブアンドスポークやData Meshなどのデータ共有アーキテクチャを構築し、複数のRedshiftクラスター間でワークロードを分散させています。ニアリアルタイムのデータ取り込みにより、データがAmazon Redshiftに到着するとすぐに分析を開始できます。私たちは、お客様がすべてのデータを分析できるようにしたいと考えています。データを複数のコピーで管理するのではなく、1つのコピーを利用可能になり次第アクセスできるようにしたいのです。Amazon Redshiftのパワーを活用することで、Data Lake、Redshift、運用データソースにまたがってシームレスにクエリを実行できます。
Hiltonの事例：エンタープライズBIとレポーティングの最適化
次に、お客様がどのようにAmazon Redshiftをビジネスに活用しているかをご紹介したいと思います。最初のユースケースは、Hiltonにおけるエンタープライズ向けBusiness Intelligenceとレポーティングです。Hiltonは2017年にAmazon Redshiftに移行し、2023年にアーキテクチャの刷新を決定しました。世界中の施設からデータを統合し、客室予約や顧客体験に関する洞察を分析したいと考えていました。そこで、Serverlessを活用したデータ共有アーキテクチャを実装し、Amazon ServerlessとData Sharingを使用したマルチウェアハウスアーキテクチャを採用しました。このアーキテクチャにより、Hiltonは複数のRedshiftクラスター間でワークロードを分散させることで、すべてのビジネスSLAを達成することができました。このアーキテクチャにより、22,000人のアクティブユーザーが同時にデータに対してクエリを実行できるようになりました。さらに、追加の顧客やワークロードの変化に対応できるよう拡張性を確保し、毎月2,000人のユーザーを追加できるようになりました。この解決策により、Hiltonは異なる施設からのデータを統合し、顧客体験に関する洞察を得て、業務を最適化することができました。
次に、EchoStarにおけるニアリアルタイム分析のユースケースをご紹介します。衛星テレビプロバイダーDISH Networkの親会社であるEchoStarは、150のAmazon Managed Streaming for Apache Kafkaトピックからデータを取り込んでいました。毎日10テラバイトものデータを取り込んでおり、最大の課題はワークロードをSLA内でスケールさせ、運用することでした。EchoStarは、Amazon Redshift、Redshift Serverless、Data Sharingを使用したマルチウェアハウスアーキテクチャを採用しました。このアーキテクチャに移行する前は、取り込みの遅延が2～3日でしたが、移行後は37秒になりました - これこそがお客様が活用しているAmazon Redshiftのパワーです。ユーザーに関するデータが37秒で利用可能になることで、テレビプロバイダーは実際にターゲットを絞った広告を表示し、これまで想像もできなかった機会を開拓することができるようになりました。
これがAmazon Redshiftのパワーです。
Zalandoの事例：Data Meshプラットフォームの構築とRedshiftへの移行
最後に、Generative AIチャットボットのユースケースについてお話ししたいと思います。最近では、データについて語る際にGenerative AIを避けて通ることはできません。画面に表示されているのは、私たちのソリューションアーキテクチャチームが考案したアーキテクチャです。このアーキテクチャは、ユーザーIDやユーザー名などのユーザー入力を受け取り、その情報をAmazon Redshiftに渡します。Amazon Redshiftは、各ユーザーの名前、住所、年齢、趣味、過去と将来の旅程など、包括的なデータを保存します。Redshiftは、運用データソースやData Lakeなど、さまざまなソースからこれらのデータを収集しています。
このデータが Amazon Redshift に取り込まれると、Amazon Bedrock との新しい連携機能を通じて Bedrock に送信され、Anthropic Claude Large Language Model が Amazon Redshift に格納されているデータを使用して、ユーザーの興味や趣味に応じてパーソナライズされた旅行プランを作成します。このユースケースについて、簡単なデモをお見せしましょう。まずは AWS Console から始めます。Amazon Bedrock に移動し、このリージョンで Anthropic Claude Large Language Model が有効になっていることを確認します。
次に、AWS Console に戻って Amazon Redshift に移動します。ここでは、すでに Amazon Redshift Serverless クラスターが利用可能な状態になっており、Query Editor V2 を使ってこのサーバーレスクラスター内のデータをクエリします。ここで Amazon Redshift クラスターに接続します。このクラスター内では、Aurora や RDS などのソースから Zero ETL を通じてデータが取り込まれているのが分かります。ここには2つのテーブルがあります - 1つはユーザープロファイル用、もう1つはホテル予約用です。
特定のユースケースについて、ユーザープロファイルデータをクエリしてみましょう。このユーザーの名前は Santiago です。45歳で、スクラップブッキングとパイナップルパンが好きだそうです。パイナップルパンが何なのかは私も知りませんが、ご存知の方がいらっしゃったら教えてください。次に、ホテル予約テーブルを見て、同じユーザーについてクエリを実行すると、Santiago がタイへの旅行を予定していることが分かります。
次に、同じユーザーIDを使って、すでにアプリケーションを初期化し、左側にユーザー名とユーザーIDを入力済みの Cloud9 に移動します。ご覧のように、Amazon Redshift に対してクエリが実行されています。このクエリは、この特定のユーザーに関する重要なデータを収集し、Bedrock に渡しています。これにより、Bedrock はこのユーザーが誰で、どこに行くのかを把握できます。自然言語の力を使って、「次の旅行で何かすることを教えて」といった質問を始めることができます。左側を見ると、プロンプトには実際に Amazon Redshift からのデータが含まれており、そのデータを使用してSantiago がタイに行くことを認識し、Santiago の興味に応じて、できそうなことを提案してくれます。
さらに検索を絞り込んで、「次の旅行の天気について教えて」と尋ねることもできます。Redshift の機能と Redshift に格納されているデータを使用して、Amazon Bedrock は暑くなるので日焼け止めを忘れないようにと回答することができます。Amazon Redshift の活用事例をいくつかご紹介しました。従来型のビジネスインテリジェンスやレポーティングのユースケースから、Amazon Redshift の機能を活用した最新のチャットボットまでをカバーしました。ここで少し、皆さんの組織で Amazon Redshift の機能を使って解決できるユースケースについて考えてみてください。
ADPの事例：大規模HCMソリューションのクラウド移行とパフォーマンス最適化
それでは、Zalandoのデータエコシステムの近代化にAmazon Redshiftの機能をどのように活用したのかについて、Sebastianさんにお話しいただきたいと思います。ありがとうございます。ご紹介ありがとうございます。私からご説明させていただきます。私はSebastian Heroldと申しまして、Zalandoのセントラルデータプラットフォーム部門でSenior Principal Data Engineerとして働いております。本日は、Fast-Serving Layerを革新するために私たちが取り組んできたAmazon Redshiftの活用についてお話しさせていただきます。
まず、Zalandoについてご説明させていただきます。アメリカではZalandoについてほとんど知られていませんが、ヨーロッパでは、私たちは20カ国以上で展開する主要なマルチブランドファッションデスティネーションです。言わばヨーロッパにおけるファッション版Amazonとも言えます。5,000万人以上のアクティブな顧客を抱え、140億ユーロを超えるGMVを達成しています。
このような大規模なファッション体験を提供するために、私たちはテクノロジーカンパニーである必要があると理解しています。つまり、すべての業務がデータによって支えられているということです。返品率を減らすためのサイズ推奨、最適な価格設定、需要予測、物流、マーケティング、コンテンツ選定、キャンペーンのユーザー選定、そしてもちろん不正検知にもデータを活用しています。
データが私たちのビジネスにとってこれほど重要だと理解していたため、Zalandoは大規模なData Meshプラットフォームを構築しています。Data Meshには4つの重要なコンポーネントがあり、その中心にあるのがデータプロダクトです。なぜなら、これがデータから価値を生み出す方法だからです。データプロダクトを中心に、分散化されたドメインが取り巻いています。各ドメインの専門家として、データチームがドメイン内に配置されています。さらに、データの取り扱いを容易にするComputational Governanceと、すべてのデータプロダクトが存在するセルフサービスプラットフォームがあります。
セルフサービスデータプラットフォームの構成要素を詳しく見ると、データへのSQLアクセス、レポーティング、ダッシュボード作成、データ変換、オーケストレーション、データ検索機能などがあります。データの品質測定機能も提供していますし、教育やトレーニングなども含まれています。プラットフォームの利用状況を見ると、月間アクティブユーザーが6,000人を超えており、これは社員全体の80%以上に相当します。データレイクには20ペタバイト以上のデータがあり、その大部分がDelta形式です。また、350以上のチームが全ビジネスユニットにわたって所有する約5,000のデータプロダクトが存在します。
ここでは Fast-serving layer についてお話ししたいと思います。これは私たちのメインデータセットに対して高速なSQLアクセスを実現する重要なコンポーネントです。約5,000のテーブルとビューがあり、主にすべての分析とMLに使用されています。毎週3,000人以上のユーザーに向けて、ダッシュボードやレポートを提供するために、Fast-serving layerでこれらのテーブルを提供しています。また、非常に高速であるため、アドホック分析にも使用されています。内部ストレージは約300テラバイトで、主にS3からデータをロードし、時にはS3にエクスポートすることもありますが、従来型のデータウェアハウスとは異なります。Fast-serving layerでは大規模なETLは行わず、シンプルなビジネスユニットと変換のみを行い、主にセレクトクエリに使用されています。
では、どのような問題があるのでしょうか？現在、私たちは巨大なモノリスと、Fast-serving layerを実行する大規模なクラスターを持っています。問題は、クラスターのスケーリングが週に数回のピーク負荷に最適化されていることです。例えば月曜の朝には週次ジョブや日次ジョブがあり、大きなピークが発生します。また週中にも他のピークがあります。クラスターサイズはこれらのピークに対応できるように最適化されていますが、80%の時間はアイドル状態です。現在使用している技術ではクラスターを動的にスケールできないため、多くのコンピュートリソースを無駄にしています。これが主な課題の一つでした。また、Oracle時代以降、このFast-serving layerは既に廃止されたOracleデータウェアハウスと密接に結びついていることがわかりました。Amazon S3との効率的なデータのロードとアンロードが重要になっています。
現在の技術では、CSVの効率的なエクスポートのみが可能で、これは理想的ではありません。Parquetを使用しようとすると、非常に遅くなりリソースを大量に消費してしまいます。2、3年後も現在のようなFast-serving layerが本当に必要なのかと自問自答した結果、将来性に欠けるため、必要ないという結論に達しました。
オンラインのクエリエディタもなく、Generative AIアシスタントもなく、セッション制限は100に制限されており、分離機能も不足していました。これは、重いクエリを実行する一人のアナリストが重要なレポーティングに影響を与える可能性があることを意味します。また、水平スケーラビリティの限界にも達していました。そこで、ベンダーとAmazonに問題解決の支援を求めました。Amazon Redshiftを含むいくつかのプルーフオブコンセプトを実施し、特にRedshiftは非常に有望な結果を示しました。
データのプロデューサーとコンシューマーを分離したいと考え、Data shareで接続された2つのインスタンス（プロデューサーインスタンスとコンシューマーインスタンス）をセットアップしました。Apache JMeterを使用してパフォーマンステストを実施したところ、結果は完璧でした。このマルチインスタンスアーキテクチャは優れた柔軟性を提供し、軽いクエリと重いクエリのパフォーマンステストでは、Redshiftが現在のクラスターよりも大幅に高速であることが示されました。クエリの16%は以前のシステムと比べて20倍以上高速で、44%は2倍以上高速でした。遅くなったのはわずか8%でした。月曜の朝の実行時間は全体で3分の1に短縮されると予測され、特にダッシュボードやレポーティングにとって重要な点として、Redshiftは軽いクエリで特に優れており、ダッシュボードやレポートに対して迅速なフィードバックを提供できます。
AWS Professional ServicesやAWSのエキスパートの方々から素晴らしいサポートを受けることができました。会場にもその方々が何人かいらっしゃいます。このサポートのおかげで、Proof of Conceptのスピードアップや最適化の実装が可能となり、素晴らしい結果を達成することができました。私たちはAmazon Redshiftの採用を決定し、目標とするアーキテクチャは次のようになりました： ユースケースごとにクラスターを分離し、Data Shareを使って各ユースケースとクラスターをファンアウトする構成です。Data Loading APIは、複数の分散したS3バケットからProducerクラスターにデータをロードするために使用されます。
Data Loading APIを採用した理由は、本日の発表にもあったように、IcebergのREST APIを使用してデータを取り込めるようになり、大幅な改善が見られたからです。私たちはこの機能を活用したいと考えており、Data Loading APIはユーザーが単にS3データセットと目的のテーブルを指定するだけで、バックグラウンドの詳細な処理を私たちが担当する抽象化レイヤーとして機能します。新機能や発表があるたびに、ユーザー側の変更を必要とせずにData Loading APIに組み込むことができ、今後登場する機能からも継続的に恩恵を受けることができます。Consumerは各ユースケース、異なるBIツール、アナリスト、レポーティングなどに特化することができ、パフォーマンスに影響を与えることなくData Shareを通じて簡単にConsumerを追加できます。また、可能な限りRedshift Serverlessを使用したいと考えています。これにより、最適な価格対パフォーマンス比を実現できるからです。
移行に関して、以前のシステムを詳しく見ると、データがロードされるSourceレイヤーがあり、そこにスクリプティングとETLが存在していることがわかります。このレイヤーにはViewも含まれています。Presentationレイヤーは、アプリケーションやシステムを利用する人間、特にアナリストが使用するレイヤーです。 私たちは新しいクラスターでPresentationレイヤーを設定し、Data Shareで接続されたConsumer クラスターを通じて、ユーザーが使用できるようにPresentationレイヤーを準備したいと考えています。
第一フェーズでは、MWAAで実行されるAirflow DAGで生成されるChange Hubと呼ばれるものを使用してデータを同期させたいと考えました。タイムスタンプカラム、パーティション、テーブルが大きくない場合はフルロードを基にしたChange Data Captureを使用しました。新しいAmazon Redshiftクラスターに簡単にPresentationレイヤーを複製することができ、作業を並列化することができました。移行中、データのProducerとConsumerを同時に移行できたことは、すべての作業を並列化できたという点で大きなスピードメリットとなりました。
フェーズ2では、プレゼンテーション層が新旧のシステム間で一貫性を保っていたため、最初のアプリケーションとユーザーを新システムへの移行を開始することができました。 また、Data Loading APIを構築し、これによってデータプロデューサーが新しい方法でRedshiftにデータをロードできるようになりました。社内のコンサルタントと協力して、データの消費者であれ生産者であれ、各チームの移行作業を進めることができました。
フェーズ3では、すべてのアプリケーションとユーザーの移行が完了した時点で、Change Hubをシャットダウンし、システムの廃止を行うことができました。 現在、フェーズ3はほぼ完了しています。 完全な完了まであと3、4ヶ月ほどかかりそうですが、これまでの学びを共有させていただきたいと思います。5,000以上のSQLクエリの移行・変換が必要でしたが、そのうち80%は単純なものかLLMsを使用するものだったため、自動的に変換することができ、このプロセスは非常に迅速に進みました。残りの20%はLUAスクリプトやその他の複雑な要素を含んでおり、Redshiftへの移行が容易ではなく、これらのスクリプトの変換には数ヶ月を要しました。
Amazon Redshift Serverlessは素晴らしいデフォルトオプションで、もし最初からやり直すとしたら、常にRedshift Serverlessを選択するでしょう。きめ細かいWorkload Managementが必要な特殊なケースでのみ、Provisionedクラスターを使用しました。また、多くのDelta形式のデータセットを扱っているため、Redshiftへの増分ロードの実装は少し難しかったのですが、これらはすべてData Loading APIでカバーされています。もしIcebergや他の形式に切り替えたとしても、データプロデューサー側で変更を加える必要はありません。
また、Redshiftのオンラインクエリエディタが利用可能になり、ユーザーからとても好評を得ています。新しいSageMaker Unified Studioがどのように採用されるか興味深く見守っています。というのも、これによってユーザーエクスペリエンスがさらに向上すると考えているからです。唯一の課題として、Data Sharesを使用する際、消費者側の多くのワークロードが、プロデューサークラスターの自動最適化に影響を与えないことが分かりました。ここでは手動でのチューニングが必要でしたが、AWSは最適化に大きく貢献してくれており、継続的な支援を提供してくれています。私たちはAWSと協力してこの状況の改善に取り組んでおり、近いうちに改善されると考えています。
10月末からシステムは本稼働していますが、現時点で76%のクエリがRedshiftで高速化されているという結果が出ています。これは非常に大きな成果です。毎朝のレポート提供時間を1時間以上短縮でき、月間コストも削減することができました。最終的な数字はまだ出ていませんが、月間コストが大幅に削減されると予想しています。運用の観点からも、クラスターを必要に応じて簡単にスケールアップ・ダウンできるため、様々な負荷状況により適切に対応できるようになりました。MicroStrategyのジョブキューの状況を示す画像もありますが、以前は長いキューがなかなか減少しませんでしたが、現在のRedshiftでは非常に速くキューが処理され、朝一番のダッシュボードやレポートがとても早く利用可能になっています。
今後の展望についてお話しします。 クラスター間のデータアクセスを一元化するために、Lake Formationの活用を検討しています。これは非常に素晴らしい機能です。というのも、現在は各クラスターやインスタンスごとに個別にデータアクセスを管理する必要があるからです。Lake Formationを中心に据えることで、Google Catalogとも連携しながら、データアクセスを完璧にコントロールできます。社内には既存のRedshiftクラスターがあり、これらのクラスターをData Share機能を通じて中央インフラに接続したいと考えています。Redshiftによると、書き込み可能なData Shareは現在プレビュー段階とのことですが、これは私たちにとって非常に興味深い機能になるでしょう。既存のクラスターにData Shareを提供し、そこにデータを書き込むと自動的に中央インフラで利用可能になるからです。Serverlessをデフォルトとし、すべてのProvisioned ClusterをServerless環境に移行することを目指しています。Redshiftへの信頼から、社内でRedshift-as-a-Serviceとして提供したいと考えています。これは認証、データアクセス、データ共有、中央プラットフォームへの接続、最適化、Data Opsなどの標準を含むパッケージとして、より多くのユースケースで簡単に採用できるようにするものです。
ADPのRedshift移行：課題と学び
私からは以上です。では、ADPのRaviに引き継ぎ、Amazon Redshiftでの取り組みについてお話しいただきます。 皆さん、こんにちは。ADPのVice PresidentでAnalytics Application Product Engineeringを担当しているRavi Tadysettyです。本日は、私たちのRedshift移行の経験と主なポイントについてお話しできることを嬉しく思います。 ADPは給与計算会社として知られているかもしれませんが、実際には業界最大のHuman Capital Managementソリューションのグローバルリーダーです。私たちの包括的な製品は、HR、給与計算、福利厚生、勤怠管理、報酬など、革新的なソリューションを提供しています。小規模企業から、Amazonを含む大規模な多国籍企業まで、幅広い企業にサービスを提供しています。現在、140カ国で100万以上のクライアントにサービスを提供しており、米国では6人に1人、つまり約2,000万人の従業員の給与計算を行っており、世界では4,000万人に及びます。ご想像の通り、私たちは膨大なデータを持っており、お客様に素晴らしいインサイトを提供することができます。
これが、私が担当しているADP Analyticsについての説明です。 これはData Cloudとも呼ばれています。ADP AnalyticsはHCMのお客様向けのPeople Analyticsソリューションです。5万社以上のお客様がこの製品を利用しています。主なユーザーは、HR、給与計算、福利厚生の実務担当者やマネージャーです。このアプリケーションは、100以上のメトリクス、KPI、ストーリーボードを通じて、お客様のデータに関するインサイトを提供します。離職率の時系列での推移、給与の公平性、ダイバーシティなど、幅広いトピックについての分析を提供しています。
分析結果は、Q&A形式で提示されます。例えば、「どの拠点で離職率が上昇傾向にあるか」や「どの部門で高い数値を示しているか」といった質問に答える形です。例えば、お客様は異なる拠点や部門間での離職率の特定のトレンドについて調べることができます。これらの分析はすべて、オンプレミスのデータセンターでホストされているテクノロジーとデータウェアハウスによって支えられています。
私たちは約10年前、数百のクライアントからこの取り組みを始めました。年々、製品は急速に成長し、その成長に伴って多くの課題も生まれました。ご想像の通り、主な課題はスケーラビリティとパフォーマンスに関するものでした。クライアント数とデータ量が増加するにつれて、ワークロードのパフォーマンスが低下し始めました。データベースを追加したりアップグレードしたりすることはできましたが、ハードウェアの調達サイクルは長く、コストもかかります。新しい地域で製品の販売を開始するにつれて、新しい環境を構築し、新しいデータセンターにアプリケーションをデプロイする必要がありましたが、これにも多大な労力が必要でした。
これらの課題に対処するため、私たちはデータウェアハウスとアプリケーション全体をクラウドに移行することを決定しました。クラウドへの移行の旅は、Amazon Redshiftを含む3つの主要なデータウェアハウス製品の評価から始まりました。データウェアハウジングに対する要件は多岐にわたりましたが、特に重要な3つの要件がありました：スケーラビリティ、パフォーマンス、そしてマルチテナンシーです。詳細な評価の結果、3つの製品のいずれも私たちの期待を完全に満たすものではありませんでした。その中でもAmazon Redshiftがスケーラビリティの面で最も期待に近く、Redshiftチームとソリューションアーキテクトは、パフォーマンスとマルチテナンシーの要件についても解決すると約束してくれました。
クラウドへの移行により、アーキテクチャを簡素化・合理化し、お客様に新しい機能を提供する機会が得られました。アーキテクチャを見ると、左側にはAmazon S3にデータを複製するトランザクション処理システムがあります。私たちはETLパイプラインを構築して、データをスタースキーマに変換し、Redshiftにロードしています。右側には、アナリティクスアプリケーションを含む利用者が表示されています。オンプレミスのデータセンターでは、ETLの実行に夜間10～12時間かかっていたため、お客様は前日のデータしか見ることができませんでした。データの鮮度は不満の一つでしたが、クラウドでは1時間以内にETLを実行できるようになり、1日に複数回ETLを実行できるため、お客様は最新のデータを見ることができるようになりました。
ここで、私たちのアプリケーションが提供するワークロードの性質とパフォーマンスへの期待についてお話しします。アプリケーションはWebとモバイルで提供されているため、パフォーマンスに関するSLAは非常に厳しいものとなっています。95パーセンタイルは3秒で、ピーク時の平均応答時間は1秒未満です。数千のお客様が製品を使用しており、1時間あたり約50万のSQLクエリが生成されるため、本質的に高同時実行性・低レイテンシーのワークロードとなっています。ワークロードは1日を通じて変動し、負荷パターングラフに示されているように、ピーク時の負荷はオフピーク時の3倍になりますが、それでも1日を通じてほぼ1秒未満の応答時間を実現できています。
これらの結果をどのように達成したのか、詳しくご説明しましょう。まず何より重要なのは、クラスター構成がパフォーマンスとスケーラビリティに大きな役割を果たしているということです。Redshiftチームは私たちのワークロードを検証し、最適なクラスター構成を提案してくれました。私たちはストレージとコンピュートを独立してスケールでき、SSDストレージを備えたRA3ノードを使用しています。また、ピーク時のワークロードに応じてシステムが自動的にコンピュートを調整するConcurrency Scalingも使用しています。最大制限である10個の同時クラスターが使用されているのを確認しており、これは私たちにとって非常に価値のある機能でした。
ピーク負荷に対応するハードウェアを事前に用意する必要はありませんでした。パフォーマンステストを開始した当初、平均応答時間は5～10秒で、目標とはかけ離れていました。パフォーマンスチューニングの旅が私たちの前にあることを認識し、本番環境と同等の品質のワークロードをテスト環境で生成できる自動化プログラムを構築することにしました。
この課題に対して、私たちは2つのアプローチを取りました。まず、オンプレミスのアプリケーションサーバーからすべてのAPIログを収集し、それらのAPIをクラウドインスタンスに対して呼び出すReplayユーティリティを構築しました。次に、Amazon Redshiftチームが提供するSimple Replayユーティリティを使用しました。Simple Replayはデータベースレベルでワークロードを記録し再現します。これら2つのツールを組み合わせることで、本番環境に匹敵する品質のワークロードをテスト環境で作成することができ、チューニング、テスト、デプロイメントを何度も繰り返す必要があった私たちにとって非常に有用でした。
初回クエリのコンパイルは非常に興味深い課題で、私たちはこれに多くの時間を費やしました。お客様が様々な観点でデータを分析するため、私たちのアプリケーションは多数の短いダッシュボード型クエリを生成します。これらの短いダッシュボード型クエリは、初回実行時のコンパイルコストが数秒かかり、SLAに影響を及ぼしていました。Amazon Redshiftチームは私たちと協力し、これらの短いクエリの一部セグメントをスキップできる機能強化を提供してくれました。初回コンパイルコストの問題は解決されましたが、すべてのセグメントはバックグラウンドでコンパイルされるため、後続の実行では最適な実行が可能になります。
行ベースのデータウェアハウスからAmazon Redshiftに移行した際、いくつかのSQLパターンがうまく機能しませんでした。Redshiftチームはそれらを特定し、それらのSQLクエリの書き換えを支援してくれました。私たちのソリューションアーキテクトが詳細なブログを書いており、喜んで共有させていただきます。ダッシュボード型クエリに加えて、スタースキーマでは効率的に実行できないレポートもあるため、レポートのトラフィックが多いテーブルについては非正規化を行っています。
私たちは1日を通じてパフォーマンスが低下するのを防ぐために、いくつかの対策を実施しています。先ほど少し触れましたが、1日に複数回ETLを実行しており、これによってデータウェアハウスに大量の更新と削除が発生します。Redshiftでは、削除操作によって解放されたスペースはすぐには再利用されないため、パフォーマンスを維持するために複数回Vacuumを実行しています。Query Monitoring Rules（QMR）も私たちが活用している興味深い機能です。時々、クラスター上でうまく実行されないアドホッククエリが発生し、クラスターリソースを大量に消費して他のクエリを実行できなくしてしまうことがあります。私たちはQMRを使用してそのような不適切なクエリを特定し、終了させています。
これらすべての手法を組み合わせることで、私たちはSLAを達成することができています。Amazon Redshiftチームとのパートナーシップは非常に広範で、設計アーキテクチャ、パフォーマンスチューニング、行レベルのセキュリティ、コスト最適化など、多岐にわたる支援を受けています。 Multi-tenancyは、数千のお客様を抱えるSaaSプロダクトとして、私たちにとってもう一つの重要な要件です。私たちの要件は、複数のお客様のデータを1つのデータウェアハウスに格納しながら、各お客様が自社のデータのみを閲覧できるようにすることです。また、バッチ指向のETLジョブは、複数のお客様のデータを同時に処理できる必要があります。
これらの要件を念頭に置いて、私たちはAmazon Redshiftのオプションを検討し始めました。Bridge ModelとPool Modelという2つのソリューションを検討しました。Bridge Modelはクライアントごとに1つのスキーマを推奨していましたが、これはスケーラブルではありませんでした。Pool Modelは、複数の顧客のデータを同じData Warehouseに格納し、アクセス制御の制限を使用して顧客ごとの仮想的な境界を作成することができます。例を挙げて説明しましょう。複数の顧客のデータを含むEmployeeテーブルがあるとします。顧客1が単純なクエリを実行する場合、自社のデータのみを閲覧できるようにする必要があります。これを実現するために、Row-Level SecurityとSession Context変数を使用します。このテーブルでRLSを有効にし、Customer ID述語を使ってRLSポリシーを構築します。顧客がログインすると、最初にSession Context変数にCustomer ID値を設定します。その後、その顧客が実行するクエリは、自社のデータのみを返すようになります。
このアプローチにより、開発者のミスによって発生する可能性のある重大なセキュリティインシデントを防ぐことができます。Row-Level Securityの観点からは、ETLジョブの観点からスキップまたはバイパスしました。ソフトウェアエンジニアリングの観点からは、アプリケーション側とData Warehouse側の両方で実装が比較的容易でした。
スケーラビリティ、パフォーマンス、Multi-tenancy、データの鮮度に加えて、他にもいくつかのメリットを実感しました。データベースのフットプリントを数百のデータベースから5つのAmazon Redshiftクラスターに削減しました。サポートチームによると、失敗したワークロードのトラブルシューティングに費やす時間が減り、実際の顧客の問題解決により多くの時間を費やせるようになったとのことです。コスト面では、すべてのクライアントをクラウドに移行し、オンプレミスのインフラをすべて廃止したことで、約30%のコスト削減を実現しています。また、オンプレミスとクラウドのインフラを併用している移行フェーズでは、Migration Acceleration Programのクレジットを活用しています。さらに、新しい環境のセットアップも容易で、最近ヨーロッパでRedshiftクラスターとアプリケーション全体のセットアップを数日で完了しました。
10万社の顧客データをクラウドに移行する際には、いくつかの課題と学びがありました。詳細な計画と実行が必要です。クラウドでプロダクトを構築することは魅力的ですが、初日から移行について考え続ける必要があります。私たちが採用した戦略は、リスク、利用パターン、プロファイルに基づいてクライアントをグループ化し、バッチで移行するというものでした。データ品質は最重要です。クライアントを移行する前に、Data Warehouse内のデータの品質が正確であることを確認する必要があります。Data Warehouseは整合性制約を強制しないため、常に重複の可能性があります。データの正確性の問題を特定し、クライアントを移行する前にそれらの問題を修正するための自動化されたツールとプロセスを構築しました。
コストを最適化するためにインフラストラクチャを適切なサイズにすることが重要です。Redshiftが提供する様々なノードタイプとそれに関連する価格を理解することが重要です。私たちが従った最善の方法は、最小のノードタイプから始めて、目的のパフォーマンスレベルに達するまで徐々に増やしていくことです。チームがクラウドでアプリケーションを管理できるように、クラウドとRedshiftのスキル、特にパフォーマンスチューニングのアーキテクチャのベストプラクティスについてトレーニングを行います。また、Concurrency Scalingは独自のキャッシュを構築するため、最初の数回のクエリではコールドスタートが発生することもわかりました。
今後の展開として、クラウドでのソリューションの最適化を計画しています。Aurora PostgreSQLからRedshiftへのデータレプリケーションにはZero-ETLの活用を予定しています。また、管理の簡素化とコストの更なる最適化のためにRedshift Serverlessの検討も進めています。さらに、災害対策のためのクロスリージョンレプリケーションについても検討中です。このセッションが皆様に新しいアイデアを提供し、私たちの経験が参考になれば幸いです。ありがとうございました。それでは、Razaに締めくくりのお言葉をお願いしたいと思います。
まとめ：Amazon Redshiftを活用したデータウェアハウスモダナイゼーションの支援
ご参加いただき、ありがとうございます。これからデータウェアハウスを始められる方、あるいはモダナイゼーションを計画されている方々にとって、RaviとSebastianが共有した情報は、お客様がAmazon Redshiftを使用してデータウェアハウスの移行とモダナイゼーションをどのように実現しているかについて、実践的な洞察を提供できたのではないかと思います。これから始められる方や計画段階の方々のために、私たちはサポートリソースをご用意しています。AWS Skill Builderトレーニングでは、モダンデータウェアハウスの構築に必要なスキルを習得していただけます。また、Amazon Redshiftの実践的な経験を積んでいただけるよう、詳細な概念実証の実施もサポートしています。
Migration Acceleration Program（通称MAPプログラム）では、Amazon Redshiftでの移行を開始されるお客様向けにクレジットを提供しています。このプログラムを通じて、AWS Professional ServicesまたはAWSの信頼できるパートナーと共に、評価や将来のアーキテクチャの構築、データウェアハウスの移行をサポートさせていただきます。Professional Servicesの元メンバーとして、私自身、多くのお客様のAmazon Redshiftへの移行やモダナイゼーションをサポートしてきました。プロセスや移行の進め方について質問がございましたら、セッション後にお気軽にお声がけください。
こちらに様々なリソースをまとめさせていただきました。お客様の成功事例やAmazon Redshiftの最新機能について詳しく知りたい方、またはAmazon Redshiftを使い始めたい方は、10〜20分のデモについてアカウントチームにご連絡いただくか、スペシャリストソリューションアーキテクトにお問い合わせください。わずか数クリックでAmazon Redshiftを体験していただけます。データウェアハウスのモダナイゼーションや移行をお考えの方は、画面に表示されているリンクからアクセスしていただければ、私たちがサポートを開始させていただきます。
re:Inventでは、エキサイティングなセッションを多数ご用意しています。もう18時30分になり、皆様お疲れのことと思います。最後まで残っていただき、私たちの話とRavi TadysettyとSebastian Heroldという素晴らしいお客様のエキサイティングな事例に耳を傾けていただき、本当にありがとうございます。このモダナイゼーションと移行の事例から、皆様も独自の移行とモダナイゼーションの取り組みのヒントを得ていただければと思います。セッションのアンケートにもぜひご協力ください。Ravi、Sebastian、そして私からも、本日は貴重なお時間をいただき、誠にありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion