re:Invent 2024: AWSがAmazon Redshiftの最新機能と活用事例を紹介
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Innovations in AWS analytics: Data warehousing and SQL analytics (ANT349)
この動画では、AWS AnalyticsのDirector of Product ManagementのNeeraja Rehtachintalaが、Amazon Redshiftの最新機能と進化について解説しています。Data Lake、データウェアハウス、機械学習の融合やニアリアルタイム分析など、モダンなデータウェアハウジングの4つのトレンドを紹介し、Amazon RedshiftのData SharingやServerless機能の具体的な活用方法を説明しています。後半では、Charter CommunicationsのSenior Director of Business IntelligenceのRony Jamesが、レガシープラットフォームからAmazon Redshiftへの10ヶ月間の大規模移行プロジェクトについて、運用コスト35%削減などの具体的な成果と共に詳しく解説しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
モダンなデータウェアハウジングの最新トレンド
みなさん、こんにちは。AWS AnalyticsのDirector of Product ManagementのNeeraja Rehtachintalaです。本日は、Charter CommunicationsのSenior Director of Business IntelligenceであるRony Jamesさんをお迎えし、AWSとAmazon Redshiftを活用した彼らの取り組みについてご紹介いただきます。これが本日のアジェンダです。まず、モダンなデータウェアハウジングにおける最近のトレンドについて簡単にご紹介します。その後、 Amazon Redshiftの最新のイノベーションについて詳しくお話しし、re:Inventで発表した新機能についてもご紹介します。簡単なデモをお見せした後、RonyさんにCharter Communicationsの事例をご紹介いただきます。
モダンなデータウェアハウジングにおいて、大きく4つのトレンドが見られます。1つ目は、Data Lake、データウェアハウス、機械学習のユースケースが融合しているということです。お客様は、すべてのデータを一箇所に集約し、SQLやSparkを使った分析を行い、さらに機械学習や生成系アプリケーションを構築したいと考えています。2つ目のトレンドは、ニアリアルタイム分析です。お客様は、運用システムやトランザクションシステムからのデータを、生成されたらすぐに分析環境に取り込みたいと考えています。これにより、業務をより効率的に進め、顧客により革新的な体験を提供することができます。このように大量のデータが集まると、より広い範囲での活用のためにアクセスの容易さが重要になります。同時に、適切なユーザーが適切なデータにアクセスできるよう、堅牢なセキュリティとガバナンスの制御も必要です。これがデータの民主化には不可欠なのです。
Amazon Redshiftの進化と注力分野
みなさんご存知かと思いますが - 現在Amazon Redshiftをご利用の方は挙手をお願いできますでしょうか？多くの方がご存知の通り、Amazon Redshiftは10年以上前に、最初のエンタープライズグレードの完全マネージド型ペタバイトスケールのデータウェアハウスとしてローンチされました。それ以来、お客様の分析ユースケースの可能性を広げられるよう、Amazon Redshiftは継続的にイノベーションを重ねてきました。
現在、あらゆる業種・業界のお客様がAmazon Redshiftを様々なユースケースで活用しています。データウェアハウスの移行、モダナイゼーション、セルフサービス分析、ニアリアルタイム分析、機械学習、そしてデータ共有やマネタイズといった新しいユースケースにも対応しています。 興味深い数字をご紹介しましょう。現在、数万のお客様がAmazon Redshiftを利用しており、1日あたり合計でエクサバイト規模のデータを処理し、週に数百億のクエリを実行しています。Data SharingやServerlessといった新しい人気機能については、Data Sharingを通じて1日に数千万のクエリが実行され、Amazon Redshift Serverlessでは数千のお客様が数十億のクエリを実行しています。
製品ロードマップと注力分野については、大きく4つの領域があります。サービス開始当初から、価格性能比に徹底的にこだわり、システムから最高の価値を引き出し、ユーザー数やデータ量に応じてスケールできるよう、重要な取り組みを続けてきました。2つ目のイノベーションは、Data Lakeとデータウェアハウスを融合し、Lakehouseアーキテクチャを実現することです。3つ目は、データ取り込みを簡素化し、ニアリアルタイム分析を可能にすることです。そして最後に、データウェアハウス内のデータを活用して、よりコンテキストに即した関連性の高い生成系アプリケーションを構築できるようにすること、さらに生成AIを活用してAmazon Redshiftでのユーザー生産性を向上させることに注力しています。
Amazon Redshiftの最新機能と性能向上
Amazon Redshiftは過去12ヶ月間で製品に関して大きな進歩を遂げました。2024年には、データ管理、セキュリティ、パフォーマンス、Serverlessと他のサービスとの統合、リージョン拡大など、100以上の機能を提供してきました。このセッションでは、これらの重要な機能セットのいくつかを紹介し、お客様のユースケースにどのように役立つかについてお話しします。まずは価格性能比から見ていきましょう。 Amazon Redshiftは、他のクラウドデータウェアハウスシステムと比較して、最大3倍優れた価格性能比を提供します。これは標準的なTPC-DSで行ったベンチマークです。私たちのパフォーマンスに関する目標は、個々のワークロードのパフォーマンスを向上させるだけでなく、より多くのワークロードやユーザーを追加した際にも価格性能比がスケールし、コストが予測可能であることです。Amazon Redshiftのお客様の多くに見られる一般的なパターンの1つが、ダッシュボードアプリケーションです。これは非常に高い同時実行性で発生する、レイテンシーの低い小規模なクエリです。この分野で私たちは多くの改善を行ってきました。Amazon Redshiftは、他のクラウドデータウェアハウスシステムと比較して、1ドルあたり最大7倍のスループットを提供します。
私たちは継続的にフリートを監視し、強化すべき適切なパフォーマンス機能を特定しています。過去6～9ヶ月の間に、数多くのパフォーマンス改善を実現してきました。重要な改善の1つは、ダッシュボードクエリの初回応答時間の向上です。初回クエリの応答時間におけるコンパイルのオーバーヘッドを削減するため、クエリ実行の最適化を実装しました。また、Data Sharingのパフォーマンスも大幅に向上し、初回クエリは2023年と比較して146倍高速になりました。データが継続的に更新される場合は最大4倍高速化され、Sort KeyやDistribution Keyをより効率的に生成するアルゴリズムも改善しました。
レガシーなDC2.Lファミリーをまだ使用しているお客様向けに、より小規模なRA3.Lインスタンスを導入しました。コンピュートとストレージの分離を提供するこれらの新しいインスタンスへの移行を強くお勧めします。また、Serverlessフリートにもgravitonを搭載し、最大30%の価格性能比の向上をシームレスに提供しています。これらのパフォーマンスの革新は舞台裏で行われ、追加コストなしで自動的に利用可能になります。
Amazon Redshiftのパフォーマンスは、単一クラスターの機能を超えて拡張されます。何千ものお客様が、Redshift Data Sharingを使用したマルチクラスターアーキテクチャを実装しています。これにより、複数のRedshiftデータウェアハウス間でライブかつトランザクション的に一貫性のあるデータを共有することが可能です。お客様は通常、Data Sharingを2つの一般的なパターンで展開しています。1つ目はハブアンドスポークモデルで、データウェアハウスにデータを集中させ、ダッシュボード、データサイエンスワークロード、アドホッククエリなど、異なる目的のための複数の分析クラスターを持つモデルです。各コンピュートクラスターは、中央環境からデータにアクセスしながら、特定の価格性能要件に応じてサイズを設定できます。
2つ目のパターンは、異なるビジネスチームがそれぞれのウェアハウスを維持しながらデータセットで協力する必要がある、Data Meshアーキテクチャです。Data Sharingはアカウント内、アカウント間、さらにはリージョン間で利用可能で、サードパーティのデータへの簡単なアクセスを実現するAWS Data Exchangeとも統合されています。 Data SharingはRedshift Managed Storageを基盤としており、お客様にコンピュートとストレージの分離を提供します。これにより、リソースの競合なしにコンピュートの分離が実現され、複数のワークロードを同じコンピュート上で組み合わせる必要がなくなります。さらに、コンピュートが分離されているため、マルチテナント環境でチャージバックを実装することができます。
本日は、Data Sharingの新機能である「Multi-warehouse Writes」についてご紹介できることを大変嬉しく思います。これまでのData Sharingは読み取りワークロードの分離のみをサポートしていましたが、Multi-warehouse Writesによって、ETL処理を含むデータ処理ワークロードのスケーリングが可能になりました。例えば、夜間のデータ処理ジョブには大きなコンピュート容量が必要で、日中の増分データ更新には異なるコンピュートリソースが必要、さらに週次や月次レポート用に別のコンピュートが必要、といったケースがあります。Multi-warehouse Writesを使えば、これらすべてのコンピュートを同じ共有データベース上で運用できます。また、この機能によってライブコラボレーションも実現し、営業、マーケティング、財務、データサイエンスなど、異なるチームが Customer 360 や運用ログなどの共通データモデルに対して、それぞれ独自のコンピュートリソースを使いながら共有データセットにアクセスできるようになります。
Amazon Redshift Serverlessの進化と新機能
組織全体でアナリティクスをスケールする際の使いやすさの重要性について強調したいと思います。数年前に、Redshiftの利用をシンプルにするためにAmazon Redshift Serverlessをリリースしました。Redshift Serverlessでは、コンピュートが自動的に管理されるため、ユーザーはインフラ管理ではなく、アナリティクスに集中できます。
ワークロードに基づいて自動的にプロビジョニングとスケーリングが行われるため、お客様は実際に使用した分だけを支払うことになります。例えば、1時間の中で5分間だけ実行されるワークロードがある場合、お客様はその5分間のコンピュートに対してのみ料金を支払います。このPay-for-useモデルは、Serverlessと組み合わせることで特に強力になります。
私たちは、非常に広く採用されているAmazon Redshift Serverlessの改善を続けています。さらに10のリージョンでServerlessを展開し、Cross-region Copy、Snapshotスケジューリング、AWS PrivateLinkサポートなど、多くの機能を追加してプロビジョニングクラスターと同等の機能を実現しました。現在では1024 RPU（Redshift Processing Units）の構成が可能となり、より大規模なワークロードもServerlessで簡単に処理できるようになっています。
また、本日発表できることを大変嬉しく思う機能として、Amazon Redshift ServerlessのAI駆動のスケーリングと最適化が一般提供開始となりました。これにより、Serverless Redshiftはコンピュートに関してよりインテリジェントでダイナミックになります。お客様にとっての使い方はとてもシンプルです - コストを最適化するか、パフォーマンスを最適化するか、バランスを取るかをスライダーで指定するだけで、あとはServerlessが残りの作業を行います。コンピュートの起動、スケーリング、そしてそのパフォーマンスレベルを達成・維持するための最適化の展開を処理します。例えば、テラバイト規模のデータを処理するETLタスクを15分や30分以内に完了させる必要がある場合、この機能は特に有用です。ワークロードにパフォーマンス最適化の設定を行えば、データ量が増加しても、Serverlessがそのパフォーマンスレベルの達成と維持を支援します。
この特定の機能は数ヶ月間プレビュー段階にあり、複数のお客様に試用していただきました。その一例として、あるお客様では70%のコストで最大5.3倍のパフォーマンス向上を達成しています。グラフが示すように、初期のパフォーマンスレベルから、ML（機械学習）ベースの最適化により、時間とともにパフォーマンスが大幅に向上しています。
パフォーマンスの改善に加えて、可観測性と使いやすさの面でもいくつかの機能強化を実施しました。新たに導入したQuery Profilerでは、クエリ実行プランをグラフィカルに表示し、パフォーマンスの問題を分析およびデバッグすることができます。また、Query Hashという機能も追加され、SQLクエリの一意の識別子として機能し、特定のクエリのパフォーマンスを時系列で追跡し、繰り返し発生する問題やパターンを特定することができます。
Amazon Redshiftの実装事例
ここで、Data SharingとServerlessの実装に関する具体的な事例をご紹介させていただきます。Amazon.comは、Amazon Redshiftの最大のお客様の一つで、SQLアナリティクスとデータウェアハウジングの優先的な選択肢として利用されています。彼らは、Data SharingとServerlessを大規模に展開しており、データの取り込みとキュレーションのために280以上のプロデューサークラスターを持ち、1500のチームにわたって約2500の消費クラスターを運用しています。この実装の大部分はServerless上で行われており、一部がProvisioned Clusterで運用されています。
もう一つの例は、超高速食料品配達企業のGetirです。同社はData Sharingを活用したData Meshアーキテクチャによってデータアクセスを民主化しています。このアプローチにより、コスト効率を改善しながら、大規模なアナリティクスをより迅速に提供することが可能になりました。彼らはData Sharingを積極的に活用し、テラバイト規模のデータと数千のテーブルを管理しています。また、数分、時には数秒で処理する必要のある多数のメッセージングイベントも扱っており、Data Sharingによってワークロードの分離とチャージバックの実装を実現しています。
もう一つの例は、人材管理企業のCriteriaです。同社は以前、別のクラウドデータウェアハウスを使用していましたが、インフラストラクチャの利用率が低く、コストが増大していました。この事例では、Amazon Redshift Serverlessに移行し、AWS GlueやAWS Lake Formation、さらにLambdaを活用してよりシンプルなアナリティクスアーキテクチャを構築することで、大幅なコスト削減を実現しました。
SageMaker Lakehouseとデモンストレーション
価格性能に次ぐ2番目の柱は、Lakehouseです。 まず、Lakehouseとは何かについて共通認識を持ちたいと思います。Lakehouseは、柔軟性とオープン性を提供するData Lakeの長所と、パフォーマンスとトランザクション機能を提供するData Warehouseの長所を組み合わせたものです。お客様にとってのLakehouseのメリットは、すべてのデータに対して、お好みのエンジンやツールを使用できることです。データのサイロ化や分断されたガバナンスについて心配する必要はありません。これこそがLakehouseの真価なのです。
本日のMattのキーノートでもお伝えしたように、私たちは統合された、オープンで安全なLakehouse機能として、SageMaker Lakehouseの提供を開始することを嬉しく思います。これはSageMakerの傘下で、AnalyticsやMachine Learning、AIサービスを1つにまとめたものです。 このLakehouseでは、S3 Data LakeとRedshift Data Warehouseに存在するデータを統合ビューとして提供します。多くのお客様は両方を使用しており、Data LakeとData Warehouseの両方にデータを保持しています。Lakehouseの2つ目の特徴は、オープン性です。すべてのデータはIceberg APIを通じて利用可能で、EMRやGlueなどのAWSエンジンや、Icebergと互換性のあるサードパーティのエンジンを使って、Data Warehouseのデータを含むすべてのデータにアクセスできます。3つ目の特徴は、きめ細かいセキュリティ制御が統合されており、すべてのデータに対して一貫した権限設定を適用できることです。SageMaker Lakehouseの素晴らしい点は、既存のデータアーキテクチャを変更する必要がないことで、Data LakeやData Warehouseにある既存のデータをそのままLakehouseの一部として利用できます。
SageMaker Lakehouseは、本日発表された次世代SageMakerの一部です。これには3つのコンポーネントがあります：統合データ管理のためのLakehouse、すべてのデータ処理やSQLアナリティクス、Machine Learning、Generative AIのユースケースを1つの統合された環境で提供するUnified Studio、そしてスタックの一部として統合されたデータとAIガバナンスです。 LakehouseおよびSageMaker次世代プラットフォーム全体を構成するコンポーネントは複数あります。AWS Glue Data Catalogは、Data Lakeのデータだけでなく、Data Warehouseのデータやその他の多くのデータソースもホストするため、マルチカタログサポートへと進化しました。Redshift Data Warehouseにある既存のデータは、ワンクリックでAWS Glue Data Catalogに公開でき、共通のカタログを通じてメタデータを検出できます。Redshiftをご利用でないお客様でも、Redshift Managed Storageを使用してData Lakeを構築できます。これは分析に最適化されたストレージで、バックグラウンドでRedshiftクラスターを実行してData Lakeを支えています。
昨年、すべてのサービスにわたる統一されたアイデンティティである「Trusted Identity Propagation」というイニシアチブを開始しました。Trusted Identity Propagationを使用すると、例えばAmazon QuickSightからシングルサインオンを使用して、Redshift、Lake Formation、そしてS3まで、スタック全体を再ログインすることなく通過できます。アイデンティティがスタック全体に渡って引き継がれるため、複数のサービスをデプロイする際に非常に強力な機能となります。このTrusted Identity Propagationには、ドライバーサポートやAWS IAM Identity CenterとAmazon S3 Access Grantsの統合など、多くの機能強化を行っています。
Amazon Redshiftでマルチウェアハウスアーキテクチャを構築する際、必要なのはRedshiftのデータをLakehouseに公開するだけです。データを移動させるのではなく、Redshiftのメタデータを公開するだけで、別のRedshiftクラスターからそのデータにクエリを実行できます。データ共有を明示的に設定したり、管理について心配したりする必要もありません。Lakehouseは、Redshiftでマルチウェアハウスアーキテクチャを設定する方法を簡素化します。
Lakehouseの一つ目のポイントとして、Apache Icebergとの互換性によってRedshiftのデータを広く利用可能にする方法についてお話ししました。Lakehouseの二つ目のポイントは、データレイク上のデータに対して、Redshiftを強力なSQLエンジンとして活用する方法です。Redshiftは常にオープンフォーマットをサポートしてきましたが、最近ではIcebergのサポートも導入しました。データレイク上にIceberg形式でデータを保存している場合、Redshiftを使用してそのデータにクエリを実行し、ウェアハウス内のデータと結合することができます。データレイクのパフォーマンスに関して多くの改善を行い、RedshiftがApache Iceberg形式のデータにクエリを実行する際のパフォーマンスを最大3倍向上させました。
Charter Communicationsのデータウェアハウス移行プロジェクト
私が特に気に入っている機能の一つは、データレイクテーブルに対するインクリメンタルなマテリアライズドビューです。これは、オープンフォーマットでデータレイクにデータを持っていても、高性能なダッシュボードアプリケーションを実現する必要がある場合に役立ちます。データレイクテーブルを参照するマテリアライズドビューを作成することで、数秒での応答時間を実現し、データレイク上でインタラクティブな分析を可能にする強力な機能となっています。
三つ目の柱である取り込みとニアリアルタイム分析の簡素化に移ります。過去12～18ヶ月間、私たちは取り込みの簡素化に取り組んできました。Auto-copyと呼ばれる機能が一般提供となりました。Auto-copyは、Amazon S3からの自動化された簡素な取り込み機能です。お客様は、ソースとなるS3バケットと対象のRedshiftテーブルを設定するだけで、私たちが自動的に継続的なデータロードを行います。新しいファイルを検出し、取り込み済みのデータを管理し、一度だけ確実に取り込むようにします。お客様は、コピーコマンドの設定やスケジューリング、取り込み済みファイルの追跡について心配する必要がありません。
また、ほぼ2年前にリリースしたストリーミング取り込みやストリームからの取り込みも簡素化しました。このストリーミング取り込みは非常に広く採用されている機能です。Amazon KinesisやAmazon MSK（Managed Service for Kafka）からのデータを、S3にステージングすることなく、非常に簡単にRedshiftに取り込むことができます。Redshiftでマテリアライズドビューを設定し、KinesisストリームやKafkaトピックを指定するだけで、新しいストリーミングデータが発生すると自動的にRedshiftにロードされます。
多くのお客様が、高スループット・低レイテンシーでストリーミング取り込みを使用しています。ストリーミング取り込みについて、スケーラビリティの向上やmTLS認証、レジリエンシーなど、多くの機能を改善しました。数週間前にリリースされた新機能の一つは、Amazonのストリーミングサービスを超えて、Confluent CloudやセルフマネージドのApache Kafkaクラスターもサポートするようになりました。これらの環境からのデータを、パイプラインを構築することなく、非常に簡単にRedshiftに取り込むことができるようになりました。
Streaming ingestionは多くのお客様によって、主に2つの目的で使用されています：インジェストの簡素化と、大規模なニアリアルタイム分析です。 ファイルやストリームからのインジェストの簡素化についてお話しした後は、次によく使用されるソースとしてデータベースとアプリケーションがあります。ここで私たちのZero-ETLビジョンが活きてきます。トランザクションデータやオペレーショナルデータのニアリアルタイム分析のために、運用システムからデータを簡単かつ安全に取り込む方法を提供します。私たちはAmazon Aurora MySQLからZero-ETLの取り組みを開始し、現在では、 MySQLやAurora PostgreSQLが一般提供され、Amazon DynamoDBもサポートしています。
さらに、RDS MySQLも現在利用可能です。また、SalesforceやZendeskなどのエンタープライズアプリケーションからのZero-ETLも開始しました。これら8つのソースからAmazon Redshiftへのゼロ-ETLが利用可能です。ソースとターゲットを設定するだけで、データがRedshiftに取り込まれる、とてもシンプルな機能です。
また、Zero-ETLの詳細な機能についても取り組んできました。例えば、 ソースデータベース全体ではなく、必要なデータを選択的に取り込みたい場合のデータフィルタリング機能があります。モニタリングや拡張VPCルーティングなどの機能も開発し、Zero-ETLを本番環境で使用できるよう、数多くのエンタープライズ機能を実装してきました。多くのお客様が Zero-ETLを本番環境に展開し始めています。その一例が暗号通貨取引所のPionexです。彼らはStreamingとZero-ETLの両方を使用し、レイテンシーを30分から約30秒に短縮することができました。これは大きな改善であり、パイプラインの作成と管理のコストを削減し、運用コストを大幅に削減することができました。
最後に、次の柱についてお話しします。 明日のSwamiのキーノートで、Generative AIに関する多くの発表がありますが、ここでいくつかご紹介させていただきます。 まず、Amazon Redshift Query EditorのGenerative SQL機能が一般提供開始となりました。これは自然言語でクエリを表現し、SQLの推奨を得られる機能です。組織のスキーマメタデータや複雑な技術的詳細を理解する必要はなく、自然言語でデータとやり取りできます。システムからより正確な推奨を得られるよう、ユーザーの権限やクエリ履歴も考慮されます。
先月開始したもう一つの新機能は、Amazon RedshiftとAmazon Bedrockの統合です。Claude、Llama 2、Amazon Titanなど、多くのFoundation Modelが利用可能です。これらのFoundation Modelを参照する外部モデルをRedshiftで簡単に作成し、推論のためにSQLの一部として呼び出すことができます。感情分析やテキスト要約などのタスクを直接実行できるようになります。これらのタスクをSQLで実行し、これらのGenerative機能をAnalyticsワークフローの一部にすることができます。
これからいくつかの機能についてクイックデモを通じてご紹介したいと思います。このデモでは、Any Companyという小売企業向けの包括的なアナリティクスソリューションをお見せします。本日の新発表は、Amazon SageMakerプラットフォームの一部である、Unified Studio Lake Houseです。まず、Unified Studioにログインします。Any Companyのドメインがここにあります。シングルサインオンを使用してユーザーとしてこのドメインにログインします。プロジェクトが表示され、アクセス権のあるデータアナリティクスプロジェクトにログインしています。このプロジェクトには、Lake House内にデータがあり、最初は私のデータレイク内のオープンソースS3データを含むデフォルトのカタログがあります。
Redshiftのデータをお持ちのお客様向けに、Amazon RedshiftのデータをこのLake Houseの一部にする方法をご紹介します。この会社、Any Companyには複数の事業部門があります - セールス、財務、CRMです。2つのデータウェアハウスがあり、1つはセールス用、もう1つは財務とCRMチーム用の統合データウェアハウスです。このデータをLake Houseの一部にするには、データを公開する必要があります。Lake Houseへのデータの公開は簡単で、Lake Houseとして進化したAWS Glueカタログに登録するだけです。次に、財務とCRMのデータウェアハウスも同様に登録します。登録が完了したら、Lake Formationコンソールに移動して、これらのRedshiftクラスターに関連付けられたカタログを作成します。まずはセールスカタログを作成します。そして、財務とCRMのカタログも作成します。
基本的に、これらのカタログを登録しているわけです。Amazon RedshiftデータウェアハウスのメタデータをLake Houseに登録しています。この流れではデータの移動は一切行っていません。ご覧の通り、2つのカタログができましたので、Unified Studioのユーザーに権限を付与したいと思います。AWS Lake Formationの権限を使用してこれを行うことができます。簡単にするために、今回はスーパーユーザー権限を使用していますが、実際には、行レベル、列レベル、セルレベルの制御など、Lake Formationのきめ細かなアクセス制御をすべて実装できます。
Amazon Redshiftからデータを公開し、Unified Studio環境からアクセスできるようにLake House内のカタログに権限を設定しました。次に、Unified Studioに戻ってLake Houseカタログを更新します。AWS Data Catalogに公開されたカタログがLake Houseの一部として表示されるようになりました。ご覧の通り、Amazon Redshiftデータウェアハウスが、Lake Houseの階層とデータカタログの階層の一部として表示されています。
データウェアハウスにはまだデータがないので、Zero-ETL統合を使用してAmazon Redshiftデータウェアハウスにデータを投入していきます。最初に作成するZero-ETL統合は、Aurora PostgreSQLにあるセールスデータ用です。Amazon RDSコンソールに移動して、Aurora PostgreSQLからAmazon Redshiftへのゼロ-ETL統合の作成を開始します。ここでソースとなるAuroraデータベースを選択し、ソースシステムから取り込みたい正確なデータをフィルタリングし、ターゲットとなるAmazon Redshiftデータウェアハウス（この場合はセールス）を選択します。これでZero-ETL統合を作成できます。
Aurora データベースからの Zero-ETL 統合はほぼリアルタイムで行われます。テーブルの統計を確認すると、PostgreSQL から複製された4つのテーブルがあり、それぞれ約20万から60万行のデータが含まれています。データは継続的に変化する近リアルタイムのレプリケーションで、約6秒のラグがあります。私たちのフリート全体では、Aurora Zero-ETL のラグは8秒程度です。Unified Studio に戻ってセールスカタログを更新すると、Zero-ETL を通じて取り込まれたデータを確認できます。Zero-ETL で取り込まれた4つのテーブルがすべて表示されています。
Unified Studio の利点は、これらのデータがさまざまなエンジンで照会できることです。Amazon Athena、Amazon Redshift、Apache Spark を使用してクエリを実行できます。さらにいくつかの Zero-ETL 統合をご紹介したいと思います。例えば、支払いデータが Amazon DynamoDB にあります。そこで、DynamoDB から新しい Zero-ETL 統合を作成します。支払いデータを選択し、ターゲットとなる Amazon Redshift ウェアハウス（この場合は finance）を選んで、Amazon DynamoDB からの Zero-ETL 統合を作成します。
この統合により支払いデータが取り込まれ、DynamoDB から何行のデータが取り込まれたかを確認できます。最後にご紹介したい Zero-ETL 統合は、新しい Salesforce 統合です。Salesforce 統合は AWS Glue によってコーディネートされます。AWS Glue コンソールで、ソースとして Salesforce を選択し、Salesforce システムから取り込みたいオブジェクトを具体的に選択できます。今回は顧客組織データを取り込んでいますが、Salesforce からの Zero-ETL を完了することができます。このデータは、先ほど言及した finance および CRM データウェアハウスに取り込まれます。
これで3つの Zero-ETL 統合が完了しました。Zero-ETL 統合が完了すると、すべてのワークロードの統合環境である Unified Studio に戻ることができます。この Lake House カタログを更新すると、finance と CRM の両方のカタログにデータが表示され始めます。データを移動させているわけではありません - Amazon Redshift を Lake House に登録すると、Redshift の新しいデータは自動的に Lake House に表示されます。
Unified Studio の SQL クエリエディタを使用して、SQL クエリの実行を開始できます。例えば、Amazon DynamoDB から取り込んだ支払いデータに対してクエリを実行できます。もう一つの機能として、クエリエディタで自然言語を使って質問することができます。例えば「どの製品の売上が高いか」と尋ねると、システムが SQL クエリを生成し、作業を簡素化することができます。
私はStudio内でのクエリを簡素化するためにSQLを使用しています。Lake Houseの重要なポイントの1つとして、Apache Icebergとの互換性について説明しました。先ほど取り込んだデータは、すぐにApache Sparkからアクセスできる状態になります。Jupyter Notebookを開いて、2つのAmazon Redshiftデータウェアハウス（セールスカタログとファイナンスCRMカタログ）にまたがって、未払い残高のある顧客に関するクエリを実行できます。Projectのサーバーレスコンピュートを使用して2つのデータウェアハウスにまたがるクエリを実行していますが、Sparkを使用しているため、データの利用も非常に簡単です。
さて、SQLクエリエディターに戻って、Amazon Bedrockとの連携による感情分析の実行方法をご紹介したいと思います。ここではAnthropicのClaudeモデルを使用していますが、単純に外部モデルへの参照を作成するだけです。関数が返されたら、それをSQLクエリの一部として感情分析に使用します。データはAmazon Redshift内に保持されたまま、Lake Houseを通じてApache Spark、Amazon Athena、あるいはサードパーティのエンジンからApache Icebergを介してアクセスできるという利点があります。さらに、この体験は単一のStudio内で統合されているため、複数のツールを行き来する必要がありません。
Amazon Redshiftへの移行：課題と成果
それでは、Ronyに引き継ぎたいと思います。ありがとうございます、Neeraja。皆さん、こんにちは。Charter CommunicationsのBusiness Intelligence部門のSenior DirectorのRony Jamesです。本日は、Amazon Redshiftへのデータウェアハウスプラットフォームの移行についてお話しさせていただきます。まずは当社の紹介から始めて、Charterのビジネスインテリジェンスチーム、従来のプラットフォームとその課題、将来のプラットフォームに関する評価、そしてAmazon Redshiftへの移行についてお話しします。
私たちCharter Communicationsは、すべての人のためのコネクティビティカンパニーです。多くの方々は、Spectrumブランドのコネクティビティ製品を通じて、私たちのことをSpectrumとしてご存知かもしれません。米国で約3,100万人のお客様にサービスを提供しており、米国最大級のケーブル事業者であり、最も急成長している携帯電話プロバイダーです。41の州で事業を展開し、米国内の5,800万以上の世帯にコネクティビティサービスを提供しています。
私たちのビジネスインテリジェンスチームは、企業の業務運営と労働効率に関する主要な運用指標の単一の情報源を構築・維持する責任を担っています。様々な事業部門向けの信頼できるレポートを作成し、運用分析のユースケースに向けたデータプロダクトを提供しています。ジャーニー分析のために、様々なデータセットをビジネスイベントのタイムラインとして整理しています。これらすべてを、ガバナンスの効いたプラットフォームを通じて実行し、すべてのプロダクトとデータサービスのセキュリティと標準化を確保しています。
私たちの環境の規模をご理解いただくために、いくつかの重要なデータポイントをご紹介します。日々、200以上のソースシステムからデータを収集し、50万件以上のクエリを実行して、中央データプラットフォームでデータを整理しています。この中央データプラットフォームを利用する5,000以上のレポートが、様々なビジネスグループに実用的な洞察を提供しています。店舗、コールセンター、現場レベルのスタッフから、その上司まで、25,000人のビジネスユーザーがこれらのレポーティング製品を利用しています。同じ中央データは、経営層向けおよび外部向けレポーティングにも共有されています。私たちはデータにユースケースを持ち込むことを信念としており、共有分析プラットフォームを通じて、様々な事業部門から1,000人以上の直接データベースユーザーが部門の分析を行っています。
私たちのレガシープラットフォームは過去14年間にわたって進化してきました。様々なソースシステムからデータを取り込み、メタデータ管理、ログ管理、キー管理のための多くのカスタムソリューションを構築してきました。
このレガシープラットフォームでは、センターがMPPテクノロジーを活用して、メタデータ管理、ログ管理、キー管理のための様々なワークロードを管理していました。共有型の性質により、このレガシープラットフォームでは多くの課題に直面しました。バッチ処理の遅延が発生すると、共有分析、部門別のユースケース、レポーティングユーザーの利用を制限せざるを得ませんでした。データ品質ジョブはSLAの完了を待つ必要があり、データの整合性に対する先手を打った対応が難しい状況でした。これらの問題により、中央データプラットフォームでは常にリソースの競合が発生していました。
スケーラビリティも重要な課題の一つでした。コンピュートやストレージの追加には数ヶ月の調達期間が必要でした。また、レガシープラットフォームでは、RTOとRPOに数週間を要する不十分なディザスタリカバリも大きな課題でした。2022年には、レガシーテクノロジーのクラウドベースソリューションに移行しましたが、これらの課題は依然として続き、使用量ベースの価格モデルにより運用コストが増加する一方でした。
アジリティを向上させるため、私たちは3つのアプローチによるモダナイゼーションの旅を開始しました。2023年第2四半期にアセスメントを開始し、市場のリーダーを特定し、ワークロードを評価し、同じ条件でのパフォーマンス比較のためのパイロットを実施しました。アセスメント完了後、移行のためのビジネスケースを作成しました。2023年第4四半期に経営陣の承認を得て、Amazon Redshiftへの移行を開始しました。SIパートナーを選定し、コードを変換し、履歴データの移行を完了させ、カットオーバー移行を実行しました。この移行全体を10ヶ月で完了し、移行を終えた今、より良いデータ共有と迅速なデータインサイトを実現するためのプラットフォームのモダナイゼーションに継続的に取り組んでいます。
私たちは評価の過程で、この分野における4つの主要なマーケットリーダーを選定しました。 評価のため、様々な規模のExtract、Transform、Load、およびレポーティングにわたるワークロードを選択しました。比較を通じて、Redshift RA3アーキテクチャが最速のパフォーマンスを提供し、私たちのワークロードに対して20-30%優れた価格性能比を実現することがわかりました。検討したもう一つの選択肢であるOption Bは、より優れた機能を持っていましたが、私たちのワークロードに対して特別な価格性能の向上は見られませんでした。
私たちは、Amazon Redshiftが自社のワークロードに対して最速のパフォーマンスを提供するという結論に至って移行を完了しました。Redshiftはストレージの即時スケーリングが可能で、異なるワークロードに対応する様々なコンピュートオプションを提供していました。また、多くのAWSサービスとのネイティブな統合が簡素化されており、ANSIに準拠していました。私たちのコードベースの大部分がSQLベースだったため、レガシープラットフォームからRedshiftへの移行は容易でした。これらの要因はすべて、ビジネスと技術の両面における私たちの目標と戦略的に合致していました。
移行は2023年10月に開始しました。追跡、優先順位付け、およびコミュニケーションを容易にするため、プロジェクトを5つのフェーズに分けました。基盤フェーズでは、インフラストラクチャの構築、セキュリティガイドラインの確立、そして移行のためのアクセラレーターと自動化の構築に注力しました。
データソーシングフェーズでは、プロデューサー内でのデータ取り込みとデータキュレーションに焦点を当てました。データパブリッシングフェーズでは、下流の消費者に提供するレポーティングとデータプロダクトに集中しました。次のフェーズでは、レガシープラットフォームと並行して全てを実行し、すべてのKPIが100%一致することを確認するテストを行いました。最後のフェーズ5では、ビッグバンアプローチで移行を完了させました。
移行の過程で、あまり使用されていないレガシーコードの廃止を行いました。また、AWSと協力してトレーニング教材を作成し、データワーカーがAmazon Redshiftでワークロードをサポートできるよう訓練を確保しました。 10ヶ月での移行成功を支えた4つの重要なアクセラレーターがあります。最も重要だったのは自動化で、移行ライフサイクル全体を通じて、労働集約的で反復的な多くのタスクに対して自動化を構築しました。14年かけて進化し、1000人以上のユーザーを抱える環境では、多くの人々が自分のローカルマシンにSQLを保存していることを認識し、セルフサービスを構築しました。ユーザーがSQLをアップロードすると、10分以内に変換されたコードが受信箱に届くセルフサービスポータルを提供しました。
移行を加速させるもう1つの重要な要因は、ペルソナベースのトレーニングでした。Redshiftチームと協力して、管理者からアナリストまでの各役割に応じたトレーニングプログラムを構築し、具体的なハンズオン体験を含めました。これらのトレーニングは対面とリモートの両方で実施し、自己学習用に社内大学でも提供しました。さらに、T1-T0と呼ばれるユニットテスト戦略を導入しました。Redshiftに2日分の連続したスナップショットデータを保持し、1日目のデータをソースとして、0日目のデータをターゲットとしました。1日目のターゲットに対して、行と列の完全一致を確認するジョブを実行しました。これにより、ユニットテストで100%の精度を達成し、差異が発生した場合は、移行のライフサイクル中に明確に文書化して教育することができました。
AWS Schema Conversion Tool (SCT)の拡張版を使用して、レガシープラットフォームからコードを抽出しました。変換されたコードはRedshiftの開発環境にデプロイされました。開発者はT1-T0戦略と変換されたコードを使用して、すべてのデータポイントを検証するテストを完了しました。変換およびテスト済みのコードは、その後、本番環境に継続的にデプロイされました。
最初の自動化はコード変換で実現されました。SCTチームと協力して、私たちの基準に合わせてコード変換の結果を改善し、SCTの効率を65%から95%に向上させました。 また、レガシープラットフォームからRedshiftへ週400テラバイトのデータを移行するための自動データ移行フレームワークを構築しました。このデータ移行フレームワークは、統合テストと最終的なデータ移行の両方に使用しました。
開発環境でテストされた変換済みコードを本番環境に継続的にデプロイする自動コードデプロイメントを実装しました。 また、10ヶ月の移行期間中もビジネス運用は継続し、レガシープラットフォームでの変更が続いていたため、自動コードモニタリングも導入しました。この自動コードモニタリングにより、これらの変更を特定し、将来のイテレーションに含めることができました。
変換、テスト、Amazon Redshift本番環境にデプロイされたすべてのコードに対して、自動統合テストを実装しました。テスト結果を毎日レガシープラットフォームのデータと比較しました。問題のある領域を特定するためのダッシュボードを構築しました。これらすべての自動化が、私たちの移行の基盤となりました。新しいデータプラットフォームでは、Amazon Redshiftのマルチクラスターアーキテクチャに合わせてアーキテクチャを設計しました。
私たちは様々なソースシステムからのデータ取り込みを継続しています。ロギングやキー管理においてAWSサービスとの連携を強化しました。Amazon Redshiftには、ETLクラスター、バッチクラスター、そしてプロデューサーハブとして機能するクラスターがあります。コンシューマー側のワークロードは、共有分析、レポーティング、データ品質に分かれています。これらのコンシューマークラスターは過去に多くの技術的課題を抱えていました。現在のバッチ処理中でも、共有分析のユーザーは部門の分析作業を継続できます。バッチ処理中に遅延が発生しても、レポーティングユーザーは作業を中断する必要がありません。データ品質チェックは、データの整合性検証を先回りして行うため、バッチ処理と並行して継続的に実行できます。
また、新しいユースケースの導入も非常に迅速に行えるようになりました。例えば、Amazon Redshift Serverlessを導入してデータ共有を開始したところ、24時間以内にプラットフォームの利用を開始することができました。開発環境とのデータ共有も実現しました。開発者は本番環境と同品質のデータを新規開発に使用できるようになり、開発環境での反復テストが大幅に削減され、より良い製品を最初から構築できるようになりました。
Amazon Redshiftへの移行により、技術的な課題は大きく解決されました。ワークロードの分離により、SLA製品で18%の改善が見られています。新しいプラットフォームのスケーリングに要する時間は、社内承認を含めても24時間未満です。災害復旧は現在、RPOが24時間未満、RTOが8時間となっています。Amazon Redshiftは継続的に進化しており、Neerajaが先ほど言及した機能は毎週のように新しくリリースされているため、それらを活用して私たちのアーキテクチャを継続的に進化させることができました。最後に、運用コストを35%削減することができました。
移行全体を通じて、前四半期にリリースされたAmazon Redshiftの技術的機能と、AWSチームは大きな価値を提供してくれました。Data sharing、Amazon Q generative SQL、Concurrency scaling、スコープ付き権限、Redshift Autonomicsなどの主要機能が、この移行の完了を支援してくれました。AWSの貢献は計り知れません - 私たちの大規模な移行において、これ以上ない最高のパートナーでした。SCTチームは継続的に私たちと協力してSCT製品の改善を行い、ソリューションアーキテクチャチームは隔週でレビューを実施し、コンポーネントがWell-Architectedであることを確認してくれました。パフォーマンストレーニングは主要なパフォーマンス領域の課題解決に役立ち、プロダクトチームは私たちのフィードバックに常に耳を傾け、非常に短期間で必要な機能を取り入れてくれました。
大規模なデータ移行には必ず課題が伴います。私たちが共有したい重要な学びとして、Amazon Redshiftのアーキテクチャでは、ワークロードを複数のクラスターに分散させるように設計することが重要です。1000列以上の大規模な幅広テーブルがある場合は、コンパイル時間の問題を軽減するためにグローバルキャッシュを使用してください。文字ページが異なるプラットフォームから移行する場合は、文字セット間の違いを理解し、その違いについて事前にコンシューマーに伝えることが重要です。SAMLやSSOの統合を使用する場合は、できるだけ早い段階で評価することをお勧めします。
この移行を成功に導いた3つの重要な要因についてお話しします。
堅牢なインベントリの構築とSMEとの連携が、私たちの成功の重要な基盤となりました。Charterのビジネスインテリジェンスチームがここで重要な役割を果たし、彼らに大きな感謝を捧げたいと思います。アクセラレーターと自動化は移行の中核となり、10ヶ月での移行完了を実現させました。AWSとの協力、そしてITOZとData Fact Zというベンダーとのパートナーシップにより、このプロジェクトを予定通り成功裏に完了することができました。
私たちのモダナイゼーションはここで終わりではありません。 Redshiftへの移行は、将来のデータ戦略に向けたデータプラットフォームの刷新を可能にしました。データコラボレーションの向上のためにオープンソースフォーマットを統合し、SDLCを改善しデータプロダクトへの洞察をより迅速に得るためにAI for BIを統合していきたいと考えています。先ほど発表されたばかりのAmazon SageMaker Lakehouseやデータ共有権など、これらの機能はまさに私たちが進めようとしている戦略と合致しています。多くの皆様と同様、私たちもこれらの機能が一般提供され次第、使用を開始することを楽しみにしています。
まとめと今後の展望
ここで締めくくり、最後の言葉をNeerajaに譲りたいと思います。ありがとう、Rony。では、まとめに入りましょう。 Amazon Redshiftは優れた価格性能比を実現します。Data sharingとServerlessを組み合わせることで、デプロイメントを効果的にスケールできる強力な仕組みとなります。Lakehouseを活用することで、組織全体でRedshiftのデータをより広く活用でき、ニアリアルタイム分析に重点を置くことができます。Generativeに関する発表については、これから詳しくお聞きいただけます。それでは、私かRonyへの質問を2、3お受けしたあと、残りは個別にお話しさせていただきます。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion