re:Invent 2024: AWSがAurora・RDSデータをRedshiftで分析するZero-ETL機能を紹介
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Analyze Amazon Aurora & RDS data in Amazon Redshift with zero-ETL (DAT331)
この動画では、Amazon AuroraとRDSのデータをAmazon Redshiftで分析するためのZero-ETL機能について解説しています。従来のETLパイプライン構築に数週間から数ヶ月かかっていた作業を数分で実現し、データがコミットされてから数秒以内に分析可能になる仕組みを提供します。特に、Amazon Auroraの分離されたストレージレイヤーを活用した高速クローン機能や、Delete Bufferを用いた効率的な更新処理など、パフォーマンスを最適化するための技術的イノベーションが詳しく説明されています。また、Multi-Version Concurrency Control（MVCC）メカニズムを活用したトランザクショナルなスナップショットの提供方法など、バックグラウンドで実現されている高度な技術についても深く掘り下げて解説されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Zero-ETLによるデータ分析の革新：AWSの取り組み
皆様、このセッションへようこそ。本セッションでは、Zero ETLを使用してAmazon AuroraとRDSのデータをAmazon Redshiftで分析する方法についてお話しします。私はAmazon RedshiftのSenior Principal EngineerのSudipto Dasです。そして私はAuroraとRDSチームのDirector of EngineeringのJignesh Shahです。最初の部分は私が担当し、その後また戻ってきます。
今日の世界では、データが差別化要因となっています。様々なアナリストファームの調査によると、日々より多くのデータが生成され続けており、現存するデータの90%以上が過去2年間で作成されたものだということです。また別の調査では、周囲で生成されているデータを活用できる組織は、収益を20%増加させる可能性が8.5倍も高くなることが示されています。しかし、今日このデータを競争優位性として活用できている組織はわずか32%に過ぎません。
より多くの企業や組織がデータを競争優位性として活用しようとする中で、ウェブサイトやアプリでのユーザー行動のパーソナライゼーション、リアルタイムに近い不正検出、在庫の最適化、顧客関係管理など、あらゆる場面でリアルタイムに近い分析に依存しています。これらのアプリケーションシナリオすべてにおいて、本当に重要なのは、リアルタイムに近い形でインサイトにアクセスし、それに基づいてビジネスを最適化するための行動を起こせることです。
これらのインサイトを得るためには、複雑なETLパイプラインを構築する必要があり、そのパイプラインに多大なエネルギーを費やすことで、ビジネスロジックに充てる時間が奪われてしまいます。 そのため、AWSは過去数年間にわたり、Zero ETLの未来への投資を続けてきました。これにより、お客様はビジネスロジックとリアルタイムに近い分析に集中でき、異なるタイプのデータの接続についてはAWSが担当することで、これらのインサイトを導き出すことができます。
本日のトークでは、これらの異なるソースとアナリティクスエンジンのいくつかに特に焦点を当てていきます。AWSは目的に特化した運用データベースとしてAmazon RDSとAurora、そしてアナリティクスソリューションとしてAmazon Redshiftを構築してきました。これらについて簡単な概要をご説明した後、Zero ETLの実際の動作を見ていき、どのようにしてリアルタイムに近いインサイトを得る作業を簡素化できるかをお示しします。また、AuroraとRDSのサービスに関連する最近のリリースについても触れ、最後に、実際にどのようにしてこれを実現しているのかという基盤部分に深く踏み込んで、背後で何が起きているのか、なぜそれがうまく機能するのかについての概要をお伝えして、このトークを締めくくりたいと思います。
Amazon RDS、Aurora、Redshiftの特徴と活用事例
皆様ご存知の通り、オープンソースエンジン向けのAmazon RDSは、10年以上にわたって主力データベースサービスとして提供されてきました。MySQL、PostgreSQL、MariaDBなどのオープンソースデータベースエンジンの設定、運用、スケーリングを簡単に行うことができます。デプロイメント、セキュリティ、パッチ適用、可用性の観点から完全マネージド型となっており、高額な商用ライセンスに頼る必要のない、コスト効率の高いソリューションです。Multi-AZなどの選択肢により高可用性を確保し、AZの障害といった様々な障害にも対応できます。RDSの主な特徴は、オープンソースとの互換性を重視し、最新のメジャーバージョンとマイナーバージョンの両方にアクセスできること、そしてオンプレミスや自己管理型のオープンソースソリューションからAWSマネージドソリューションへの移行を容易にすることです。
このリレーショナルデータベースファミリーには、Amazon Auroraも含まれています。これは私たちが目的特化型で開発したリレーショナルデータベースで、MySQLやPostgreSQLなどのオープンソースソフトウェアとの互換性を保ちながら、グローバルスケールで比類のない高性能と高可用性を提供します。Auroraは標準的なMySQLと比べて最大5倍、標準的なPostgreSQLと比べて3倍のスループットを実現します。
Amazon Auroraは最大15個のレプリカにスケールアウトでき、ストレージとコンピュートが分離された設計により、高可用性と3つの異なるAvailability Zoneにわたるデータレプリケーションによる複数層のデータ耐久性を実現しています。セキュリティを重視して設計され、様々なレベルでの暗号化を提供し、完全マネージド型で、今年からはゼロまでスケールダウンも可能なServerlessオプションも提供しています。これにより、ワークロードの動的な変化に応じたスケーリングが可能となります。
現在、数万のお客様がAmazon RDSとAuroraを利用しています。特筆すべき統計として、上位1,000社のAWSユーザーのうち955社がAuroraを使用しており、ここにご覧いただけるように多くの著名企業が含まれています。多くのお客様が、これらの目的特化型の運用データベースを使用してアプリケーションや運用ポートフォリオを実行しています。
分析の分野では、AWSはAmazon Redshiftを提供しています。これは完全マネージド型のAI搭載クラウドデータウェアハウスソリューションです。 トランザクション、クリックストリーム、IoT、ストリーミング、アプリケーションログなど、様々なタイプのデータを一箇所に集約し、豊富なSQL機能、Machine Learning機能、データ共有などの機能を使用してデータを分析し、深い洞察を得ることができます。可視化、Machine Learningのユースケース、さらにはGenerative AIのユースケースを実現するための様々なツールと接続することができます。また、リソースやデータベースシステムのチューニングにMachine Learningを活用する多くの機能が組み込まれているため、サービスの管理よりもデータからの洞察を得ることに時間を費やすことができます。
Amazon Redshiftの主要な価値提供の一つは、業界をリードする価格性能比です。これは私たちがお客様から常に耳にすることで、お客様は価格を重視し、システムの性能を求めています。左側のグラフは、Transaction Processing Council（TPC）による業界標準のベンチマーク、TPC-DSベンチマークの結果を示しており、緑色のバーで表されているAmazon Redshiftと、他のクラウドデータウェアハウスサービスを比較しています。このグラフでは、数値が低いほど優れた価格性能比を示しています。ご覧の通り、他のクラウドデータウェアハウスプロバイダーと比較して、クエリを1つずつ順番に実行した場合、Amazon Redshiftは最大3倍の価格性能比を実現しています。
実際のワークロードの多くは同時実行を伴います。BIダッシュボードでは、多くのユーザーが同時にダッシュボードを操作しており、このような同時実行ワークロードの場合、価格性能比の優位性はさらに高まり、最大7倍もの差が生まれます。 現在、数万のお客様がAmazon Redshiftを使用して重要なビジネスインサイトを得ています。ここには、Amazon Redshiftを活用して分析を行っているAmazon.comビジネスを含む、多くの著名な企業名が並んでいます。
Zero-ETL統合の仕組みと利点
現在、目的に特化したデータベースとして、一方では運用データの生成元となるオペレーショナルデータベース、もう一方では強力な分析を実現する分析システムがあります。 これらの分析を行うためには、複雑なパイプラインを構築する必要があります。皆さんの中で、日々の業務でこのようなパイプラインを構築された経験のある方はどれくらいいらっしゃいますか？かなり多くの方がいらっしゃいますね。では、このパイプライン構築を楽しんでいる方は？手が挙がらないようですね。
これは多くのエネルギーが費やされる部分です - お客様からよく聞く話です。パイプラインの構築には時間がかかるだけでなく、様々な変更が発生した際のメンテナンスにも相当なエネルギーを費やしています。 例えば、Amazon RDSやAuroraのような高性能なトランザクションシステムから始まり、分析システムがあり、そしてシステムごとに異なるカスタムロジックを定義する必要があります。すべてのお客様がこれを繰り返し行っており、その管理が課題となっています。
Zero-ETLでは、これを非常にシンプルで簡単なセットアップに置き換え、すぐに始められるようにしたいと考えています。 Zero-ETLの主な利点の一つは、セットアップと管理が信じられないほど簡単になることです。現在、多くのお客様がETLパイプラインの構築に何週間も何ヶ月もかけているのに対し、Zero-ETLなら数分で始められるようになります。
もう1つの重要な側面は、運用データベースにデータがコミットされてから分析に利用できるようになるまでの時間が数秒という、ほぼリアルタイムでのデータアクセスを実現することです。データ転送の完全なセキュリティを確保しながら、転送中およびストレージ上での最先端の暗号化技術を使用しています。これにより、2つのシステム間でビジネスクリティカルなデータを安全に転送し、分析やMachine Learningのユースケースに活用できます。
Zero-ETLのもう1つの側面として、様々な運用ソース、複数の異なるデータベース、ストリーミングからのソースなど、多様なデータソースが存在する可能性があります。私たちは、これらのデータを1つのWarehouseに統合し、アプリケーション全体からグローバルなインサイトを得られるようにしたいと考えています。これは、昨日発表されたAWSの分析戦略とジャーニーの再構築にも関連しています。その中核となるのが、Amazon Redshiftを主力とするLake Houseで、データはAmazon Redshift Managed Storageに保存されます。
ここでは様々なデータソースを利用できます。その一部をご紹介すると、Amazon S3のファイルからのデータ取り込みがあります。Amazon Redshiftには、S3からRedshiftへ自動的にファイルをコピーするAuto-copy機能があります。また、Amazon KinesisやKafkaインスタンスからのストリーミング取り込み、Zero-ETLなども可能です。今回のトークでは、すでにAurora PostgreSQLとAurora MySQLをサポートしているAmazon Auroraについて説明します。Amazon RDSからは、Amazon RDS MySQLをサポートしています。さらに、Amazon DynamoDBからのデータ取り込みも可能で、これらのZero-ETL統合機能はすべて一般提供されており、データを統合してRedshiftに取り込むことができます。
データがRedshiftに取り込まれると、昨日発表したSageMaker Lake Houseの機能により、Lake Houseカタログからデータを簡単に見つけることができ、一貫したガバナンスポリシーを定義できるようになります。これにより、ビジネス上重要な機密データに適切なアクセス制御ポリシーを設定することができます。 Lake House内のデータは、お馴染みのツールセットを使用して分析、変換、キュレーション、クリーニング、学習を行うことができます。AWS Glue、Amazon Athena、Amazon QuickSight、Amazon SageMakerなど、多数のサービスとの連携をサポートしています。SageMaker Lake Houseの発表により、Zero-ETLを使用してデータを分析システムに移行すれば、これらのサービス群全体でデータにアクセスできるようになります。
Zero-ETL機能の実装と最新の改善点
ここで、Zero-ETLの実際の動作をご覧いただくため、私の同僚にバトンタッチします。後ほど、より詳細な説明に戻らせていただきます。それでは、Zero-ETLの動作を見ていきましょう。特にリレーショナルデータベースのZero-ETLについてお話しします。 データパイプラインの構築経験がある方なら、それが大きな仕事であることをご理解いただけると思います。 様々なサービスを理解し、あるサービスから別のサービスへのデータの受け渡し方法を理解する必要があります。そして、パイプラインのプロトタイプを作成し、実装する必要があります。 パイプラインの構築はその一部に過ぎません。従来の理解では、 変換処理のすべてのエッジケースに対応し、すべてのケースを処理することに何週間も何ヶ月もかかることがあります。
Zero-ETLを使用することで、このような面倒な作業をバックグラウンドで自動的にセットアップし、数分でパイプラインを構築することができます。これにより、素早く簡単に始められるようになり、バックグラウンドで必要な設定を行うためのウィザードが用意されています。
統合を作成する方法としては、CLIまたはConsoleを使用する方法があります。Consoleの使用をお勧めする理由は、「Fix it for me（自動修正）」機能が利用できるからです。この機能は、ソースデータベースの設定を確認し、未設定のパラメータに対する対処方法を提示してくれます。ソースデータベース上でそれらのパラメータを有効にするオプションを提供します。例えば、MySQLを使用している場合、Zero-ETLに必要なbinlogフォーマットをrow形式に変更する手助けをしてくれます。Auroraエンジンを使用している場合は、enhanced binlogのセットアップと有効化をサポートします。
Amazon Redshift側でも同様の機能が提供されています。Zero-ETLの動作に必要な暗号化のセットアップや、大文字小文字の区別に関するパラメータの設定をサポートします。また、Fix it for me機能は、これらのパラメータを有効にするためのリブートの必要性も判断してくれます。インスタンスをリブートするタイミングが適切かどうかを選択することができます。このように、ポイント＆クリックでセットアップを行い、すぐに使い始めることができる簡単な操作性を実現しています。
パラメータと統合の設定が完了すると、バックグラウンドで統合が作成されます。作成時には、パラメータが正しく設定され、すべてが正常に動作していることを確認します。その後、Active状態になります。Active状態は、統合が作成されたものの、まだ使用できる状態ではないことを示しています。統合を使用するためには、Redshiftで統合用のデータベース名を定義する必要があります。これには2つの方法があります：Consoleを使用してデータベース名を作成するか、RedshiftのCLIを使用して作成した統合IDからデータベースを作成する方法です。
この手順を完了すれば、もう統合を監視し続ける必要はありません。データはバックグラウンドで自動的に流れ続けます。この継続的なデータフロー統合がどのように実現されているのか、バックグラウンドで何が起こっているのかを見てみましょう。Redshiftデータベース統合を最初に作成すると、初期ロードが設定されます。これは、スライドの目的上、シードデータと呼ばせていただきます。シードデータは、ソースデータベースの現在の状態を表すデータで、大規模なバッチとしてRedshiftに移行されます。テーブルやスキーマの数に制限はありません。セットアップ時に、レプリケーションしたい対象を選択することができます。数百のテーブルであっても、一度設定すれば、レプリケーションを開始します。通常、レプリケーションにはプライマリキーが必要です。プライマリキーのないテーブルについては、Consoleでそれらのテーブルを簡単に確認することができ、レプリケーションを継続したい場合は必要な対応を取ることができます。
次に、データをカラムや属性の一部として移動する際に、データ型がどのように扱われるかを理解する必要があります。例えば、Aurora PostgreSQLを使用している場合、PostgreSQLのデータ型とRedshiftのデータ型は非常に似ているため、一般的なデータ型のほとんどはそのまま移行されます。しかし、Aurora MySQLやRDS MySQLを使用している場合は、Redshiftに移行する際のデータ型の変換方法を理解する必要があります。例えば、MySQLエンジンでVARCHARを使用している場合、RedshiftでもVARCHARとして移行されます。ただし、integer、float、datetimeなどのデータ型は、Redshiftの同等のデータ型に変換されます。このQRコードには、サポートされているデータ型の詳細な一覧があります。
このQRコードでは、統合の一部として自動的に処理されるすべてのデータ型を確認できます。新しいデータ型が追加されるたびに更新されていくので、定期的にこのページをチェックすることをお勧めします。初期データの移行が完了すると、移行中でもソースデータベースでの操作を継続できます。設計上、初期データセットの移行後は自動的にChange Data Capture（CDC）に切り替わり、そのCDCを開始する位置を追跡し続けます。
CDCにより、ソースデータベースで発生するすべての変更を継続的に取得し、Amazon Redshift側に複製します。テーブル、インデックス、その他の要素の状態に影響を与える可能性のあるスキーマ操作も一緒に移行されます。Zero-ETLは80種類以上のデータ修正タイプとDDLをシームレスに処理します。
実際の動作例をお見せしましょう。プライマリキーを持つ新しいテーブルを作成すると、数秒以内にAmazon Redshiftに表示されます。行を変更して更新すると、数秒以内にAmazon Redshiftに反映されます。行を削除すると、それらの行はAmazon Redshiftでも削除されます。数十万行を追加しても、通常15～20秒以内にAmazon Redshiftに表示されます。大規模な削除を実行すると、その削除も反対側に反映されます。カラムを削除しても、数秒以内にそれらのカラムがAmazon Redshiftから削除されます。
Amazon RedshiftにおけるZero-ETLの技術的詳細
手動でスキーマを同期させる必要なく、自動的に処理されるため、変更を加えることができます。例えば、ソースデータベースに新しいカラムを追加すると、その新しいカラムが反映されるのが確認できます。すべてのスキーマ変更は自動的にAmazon Redshiftに複製されます。スキーマ変更以外にも、バックグラウンドでデータベースの設定変更が発生する可能性があります。Zero-ETLは、データベースの再起動、フェイルオーバー、ソース側でのデータベースポート設定の変更など、すべての設定変更を自動的に処理します。
同様に、Amazon Redshift側で変更を加えた場合でも、Zero-ETLがそれらの変更を理解し、自動的に適応します。私たちの目標は、変更を追跡するための追加作業を必要とせず、自動的にバックグラウンドで処理することです。MySQLやPostgreSQLなどのオープンソース技術をベースにしているため、レプリケーションが破綻する可能性のあるエッジケースが存在するかもしれません。そのような場合、Zero-ETLは特定のテーブルでレプリケーションが失敗したことを自動的に検出し、 継続的なデータフローを回復するために、そのテーブル全体を再同期またはリセットします。
常時モニタリングが行われており、何らかの理由でレプリケーションが中断した場合、再度同期を作成してその時点から再開します。これにより、レプリケーションを中断させる可能性のある予期せぬケースに対処し、手動介入なしで自動的に回復することができます。Zero-ETL統合が行われると、関連するデータベースとの同期を透過的に維持することが目標です。データは同期された状態を保つことが期待され、 ここからはZero-ETLの設計における優先事項について説明したいと思います。
変換プロセスを考える際、私たちは最優先事項としてセキュリティに焦点を当てています。Zero-ETLでは、すべての転送において転送中のセキュリティとデータの信頼性が確保されており、そのため最初から暗号化が有効になっていることを確認しています。 次に優先されるのはデータの正確性です。これは、転送されるすべてのデータがトランザクション整合性のある状態を維持し、常に正確であることを意味します。システムは継続的にこれをモニタリングし、レプリケーションの精度を確保しています。
さらに、私たちは信頼性に重点を置いています。これは、バックグラウンドで発生する破壊的な変更に対処し、自動的に適応することに関連しています。これがZero-ETLの設計における3番目の優先事項でした。 また、ソースデータベースへのパフォーマンスの影響を最小限に抑えることも確保しています。Amazon Redshiftへのデータ変換におけるソースデータベースへの影響を最小限に抑えるため、複数の戦略を活用しています。 さらに、現在使用しているスタックで可能な限り最速のスピードでAmazon Redshiftへの変換を実現しています。
データがAmazon Redshiftに格納されると、提供されているすべての機能を活用できます。Materialized Viewを使用してデータをさらに変換したり、データレイク用にAmazon S3にデータをエクスポートしたり、機械学習機能を使用したり、アーカイブケースを処理したりすることができます。一般的なユースケースの1つは、OLTPからホットではないデータをデータウェアハウスに移動し、ソースデータベースから削除することです。これらの機能は現在Zero-ETLを使用して実現可能となり、データの扱い方についてより多くの制御が可能になりました。
Zero-ETL機能には、強化されたモニタリング機能も備わっています。Amazon CloudWatchのメトリクスをご存知の方なら、Zero-ETLに関連するすべてのメトリクスがCloudWatchで確認できることをご理解いただけるでしょう。利用可能なメトリクスには、レプリケーションされたテーブル数、レプリカのラグ、転送されたデータ量、現在の状態などが含まれます。また、Amazon Redshift側では、システムビューを通じて統合テーブルの状態を確認することができ、データ転送に関するステータスやリアルタイムの情報を取得できます。
昨年からの進展についてですが、Aurora MySQLとの統合がすでに利用可能だった状況から、現在では31のリージョンに拡大し、データフィルタリングという新機能も追加されました。APIを通じたAWS CloudFormationのサポートを実装し、使い始めやすさを向上させ、さらにデータベースの変更やカラムの削除などをチェックするためのイベントトリガーも追加しました。また、JSONデータタイプのサポートも追加され、対応データタイプの数が拡大しています。
数ヶ月前、私たちはAurora PostgreSQLからAmazon RedshiftへのZero-ETL統合をGA（一般提供）モードで発表しました。これにより、以前のプレビュー版と比べて本番環境でのユースケースが可能になりました。このGA版では、単一の統合で Aurora PostgreSQLの複数のデータベースをAmazon Redshiftに移行できるようになりました。PostgreSQLデータベースのスキーマ変更が自動的にAmazon Redshiftに反映される機能も追加され、設定済みの論理レプリケーションスロットもサポートしています。
この統合では、論理レプリケーションを使用してすべてのデータベースをAmazon Redshiftに移行します。すべての論理データベースは、Amazon Redshift上の個別のデータベースとしてレプリケーションされます。これらがPostgreSQLで利用可能な改善点です。オープンソース版のMySQLをお使いの場合、MySQL Zero-ETL統合は現在、一般提供されています。当初のプレビューから21のリージョンに拡大し、AWS CloudFormationでテーブルフィルタリングが利用可能になりました。Auroraエンジンだけでなく、Amazon RDSにも対応を拡大しています。
ここで新しく追加された機能、特にデータフィルタリングについて少しお時間をいただきたいと思います。データフィルタリングは現在、Aurora MySQL、Aurora PostgreSQL、そしてRDS MySQLでサポートされています。注意していただきたい点として、MySQLエンジンとPostgreSQLの間に若干の違いがあります。MySQLではデータベースとスキーマは同義です。データフィルタリングではスター・ドット・スター形式を使用しており、基本的にはスキーマ・ドット・テーブルタイプのフィルタリングになります。データフィルタリングでは、Zero-ETLに含めるための式を指定するか、除外するための式を指定するという2つのオプションが用意されています。これらを組み合わせることで、Redshiftにレプリケーションするものを選択できます。
PostgreSQLでは、同一のPostgreSQLインスタンス上に論理データベースがあるため、データベース.スキーマ.テーブルという形式を使用します。1つのIntegrationで複数の論理データベースをサポートできるため、レプリケーションしたい論理データベースをすべて追加することができます。例えば、database1.. と指定すると、database1に関連するすべてのスキーマとテーブルが自動的にレプリケーションされます。さらにデータベースを追加したい場合は、それらを含めることで自動的にRedshiftに転送されます。PostgreSQLの各データベースは個別のIntegrationとして表示されます。Redshift側で異なるデータベースを選択すると、自動的に処理が行われます。
Auroraエンジンの性能改善とCDCストリーミングの仕組み
次に、Auroraエンジンで実施したパフォーマンス改善についてお話ししたいと思います。これを説明するために、まずRDS MySQLのバイナリログレプリケーションの仕組みについて説明します。従来のMySQLデータベースのバイナリログレプリケーションでは、すべてのトランザクションに関する情報が作成されます。コミットの準備ができると、バイナリログファイルへの書き込みが開始されます。バイナリログファイルにすべての変更が記録された後で、初めてトランザクションがコミットされます。コミットの準備ができた時点でバイナリログレコードの書き込みを待つ必要があるため、これはやや非効率です。
Aurora MySQLでは、拡張バイナリログの一部として、トランザクションの発生時にメモリ内で同時に書き込みを開始します。コミット段階に到達した時点で、書き込みはほぼ完了しています。この改善は主にAuroraからPostgreSQLへのデータ移動を高速化するために行われました。これにより、Zero-ETLで1分間に140万トランザクションをサポートし、すべてのデータをRedshiftで高速に参照できるようになりました。同様の改善がAurora PostgreSQLの拡張論理レプリケーションでも実施されています。Aurora PostgreSQL論理レプリケーションのもう1つの改善点は、一般的なDDLタイプの変更を処理して、すべてのスキーマ変更がRedshift側にも反映されるようにしたことです。これにより、PostgreSQL側で行ったカラムやスキーマの変更がRedshiftに反映されるようになりました。このような改善の真価は、実際のお客様による使用とフィードバックにあります。
InfosysやIntuitなどのお客様から、好意的なフィードバックをいただいていることを嬉しく思います。彼らのフィードバックを見ると、Zero-ETLによって、バックグラウンドで行われる差別化されていないデータパイプライン作業に費やす時間を削減でき、保有するデータに基づいてより迅速な意思決定を行うことに注力できるようになったことが強調されています。
ここで、その背後で行われている魔法のような仕組みについて、さらに詳しく説明するためにSudiptoに戻したいと思います。ありがとうございました。Jigneshが、この高レベルの使いやすさとパフォーマンス特性の概要を説明しました。ご覧いただいた数字の1つは、Amazon Auroraの運用データベースで1秒あたり数百万トランザクションをサポートし、そのデータが数秒以内にAmazon Redshiftにレプリケーションされ、ほぼリアルタイムの分析が可能になるというものでした。このようなパフォーマンスを実現し、コスト効率を高め、Zero-ETLレプリケーションを行う際の運用データベースへの影響を最小限に抑えて運用トラフィックに影響を与えないようにするために、多くのエンジニアリングが背後で行われています。
私たちが取り上げた側面の1つが、このシーディングという概念です。Zero-ETL統合をセットアップする際、運用データベースからアナリティクス最適化されたソースストレージにデータを移行する必要があります。ここでは、WriterインスタンスとReaderインスタンスを持つRDS MySQLのセットアップを見てみましょう。従来の方法では、通常ReaderインスタンスかWriterインスタンスのどちらかから読み取りを行います。Readerインスタンスから読み取る場合は、トランザクションの整合性とラグを考慮する必要があります。一方、Writerインスタンスを使用する場合、運用データベースから数百ギガバイトからテラバイト規模のデータを転送する際に、ワークロードに大きな影響を与える可能性があります。
RDS MySQLでこの影響を最小限に抑えるため、Zero-ETL統合がバックグラウンドでシーディングを行う際、スナップショットを使用してクローンを作成し、トランザクション整合性のあるスナップショットを取得します。このクローンを使用してデータをストレージにエクスポートすることで、 Amazon Redshiftへのレプリケーションを Writerインスタンスへの影響を最小限に抑えて実行できます。
Amazon Auroraでは、さらに一歩進んだアプローチを取っています。Auroraは、コンピュートとストレージを分離するというAmazonの革新的な技術で構築されているためです。このセットアップでは、Writerインスタンス、Readerインスタンス、そしてAuroraの分離されたストレージレイヤーが存在します。Zero-ETL 統合を開始すると、高速クローンを作成する機能を活用して、プライマリデータベースインスタンスに影響を与えることなく、クローンからデータに対応するメタデータを取得できます。その後、多数のストレージサーバーに分散された共有ストレージレイヤーを使用して、コンピュートに触れることなく、並列でデータをエクスポートします。
その結果、このアプローチは運用データベースへの影響が少なく効率的であるだけでなく、RDS MySQLと比べて最大10倍高速です。テラバイト規模のデータベースでZero-ETL統合をセットアップする場合でも、数十分でシーディングを完了できます。これにより、シーディングが完了すると、より迅速にアナリティクスを開始できます。次のステップは、これらすべての変更にどのように対応するかということです。先ほど述べたように、運用データベースでは数十万から数百万のトランザクションが実行されている可能性があります。
私たちは、CDCストリームをキャプチャしてAmazon Redshiftにレプリケートする機能を活用しています。従来の方法では、ヘッドノードから論理レプリケーションストリームをキャプチャします。MySQLの場合はbin log、PostgreSQLの場合はPostgreSQL論理レプリケーションを使用します。ご存知の方もいらっしゃると思いますが、これには運用データベースのリソースが競合するというコストが伴います。トランザクションに対してレイテンシーの影響があり、運用データベースから重要なリソースが奪われることになります。
Amazon Auroraの場合、Head Nodeからの読み取りではなく、このデカップルされたストレージを活用してCDCストリーミングを実行します。 具体的には、トランザクションの実行中にデータの書き込みとコミットを行うのと並行して、 論理ログレコードを、Streaming Serverと呼ばれる別のストレージボリュームに書き込みます。このStreaming Serverは、並行してログレコードをデコードし、データ操作やDDLによるスキーマ変更を識別します。そして、ストリーミング形式で データを処理し、Amazon Redshiftに受け渡して適用できるようにします。これらの処理はストレージレイヤーで行われるため、Writer Instanceで実行されているトランザクションワークロードへの影響は最小限に抑えられます。
このCDCレプリケーションは、Amazon Aurora PostgreSQLとAmazon Aurora MySQLの両方で構築されており、先ほど説明したように、PostgreSQLについては標準のPostgreSQLの論理レプリケーションを拡張してDDLもレプリケートできるようになっています。このデータがAmazon Redshiftに移行される際の重要な側面として、Amazon Redshiftでどのようにデータをレイアウトし、CDCストリームを効率的に取り込んで変更を適用し、運用データベースでトランザクションがコミットされてから数秒以内にクエリ可能にするかということがあります。
Amazon Redshiftの並列処理とデータ整合性の維持
裏側では、Amazon Redshiftのマッシブパラレル処理アーキテクチャを活用しています。これは、Leader Nodeと複数のCompute Nodeで構成され、様々なクラスター構成をサポートしています。Amazon AuroraからAmazon Redshiftにデータを移行する際には、このパラレル処理の特性を活かし、データの特性に基づいてパーティション分割を行います。バックグラウンドでは、様々なShardingポリシーをサポートしています。例えば、データ全体を単独でレプリケートしたり、Primary Keyベースでシャード化されたAmazon Redshiftトポロジーを構築したりできます。これはワークロードパターンやデータ分散に基づいて自動的に検出され、 Amazon Redshift側のCPUオーバーヘッドを最小限に抑えながら、レプリケーションのラグやリソース消費を最適化できます。
このような基盤となるレプリケーションの仕組みに加えて、 効率的な分析を可能にする一連のテクニックも実装しています。ここでは、Amazon Redshift側で実装された軽量な同時実行制御と回復メカニズムについて説明します。これにより、データへの高速なアクセスが可能となり、ニアリアルタイムの分析を実現できます。ここで示しているのは、運用データベースのテーブルがAmazon Redshiftでどのように表現されるかを示す概念図です。テーブルにはPrimary Keyがあり、さらに実際の値を持つ追加のカラムがあります。私たちは、Amazon RedshiftのMulti-Version Concurrency Control（MVCC）メカニズムと、ソース側のトランザクションに関する知識を活用して、分析クエリに正確な結果を提供するためのトランザクショナルなスナップショットを提供しています。
ここでは、xminやxmaxなどの複数のカラムを内部的に追跡していることがわかります。PostgreSQLのMVCCをご存知の方なら、これはPostgreSQLがデータのどのバージョンが可視で、どのバージョンが非可視かを追跡する方法と同じです。さらに、ソースシステムからのLSNも追跡しており、これによってトランザクションの一貫性のあるプレフィックスを提供できます。そのため、データがレプリケートされる際に、LSNのプレフィックスに基づいた分析クエリの結果を得ることができます。具体例を見ていきましょう。
オペレーショナルデータベースに書き込まれ、Amazon Redshiftの表現に複製されている2つのキーAとBがあるとします。ご覧の通り、これら2つのキーにはRedshiftのトランザクションID 100が付与されています。これはCDCストリームを適用する際に使用されたトランザクションIDであり、オペレーショナルデータベースから取得したLSN（Log Sequence Number）も引き継いでいます。
これら2つの変更がRedshift側に適用され、ここでT1で示されている分析クエリ、つまりトランザクションT1がこのデータに対して操作を開始したとします。RedshiftはMulti-Version Concurrency Controlを使用して、このデータの一貫性のあるスナップショットを取得します。このトランザクションがアクティブな間、これら2つのタプルのみが見え、テーブルに追加される他のタプルは見えません。トランザクションT1がアクティブな間に、オペレーショナルデータベース上でさらに変更が発生し、それも複製されているとします。この場合、行Cが追加され、RedshiftトランザクションID 200とAurora LSN 3が付与されました。
同様に、別の行が追加され、RedshiftトランザクションID 300とLSN 4が付与されました。Redshiftはトランザクショナルなスナップショットを取得しているため、この複製が行われている間もトランザクションT1が実行中であっても、そのトランザクションはこのデータを参照せず、一貫性のあるスナップショットを維持できます。このデータを新しいトランザクションから参照できるようにするため、私たちはIn-Memory Commitと呼ぶ最適化を考案しました。データが適用され、AuroraトランザクションのCommitが確認されると、Redshiftでは非常に軽量なIn-Memory Commitを実行します。
このデータがメモリ上でコミットされると、後続のトランザクションから参照可能になります。Redshift側では、データがRedshiftのストレージに保存されていなくても、メモリ上で新しいクエリからデータを利用できるようにしています。この時点で新しいクエリT2が実行を開始すると、トランザクションスナップショットの一部として行CとDを参照でき、より新しいデータに基づいて最新のインサイトを得ることができます。
メモリ上でのみコミットした場合の障害時の動作について疑問に思われるかもしれません。この場合、Auroraが既にデータをコミットして永続化していることと、Redshiftに障害が発生した場合にCDCストリームを再生できる仕組みがあることを利用しています。例えば、行CとDがメモリ上でコミットされた後にRedshiftが障害で再起動した場合、Redshiftストレージ上でコミットされた最後の状態を記憶することができます。そこから、ストリームを再生することが可能です。CとDがディスクに保存されていないことを検出し、Redshiftのリカバリメカニズムの一部として、Redshiftがそれらを再適用し、データの整合性を損なうことなく常に利用可能な状態を確保します。
CDCレプリケーションのもう一つの重要な側面は、Change Data Captureがデータの変更を追跡する際に、挿入だけでなく、更新や削除も含まれるということです。分析システムに詳しい方ならご存知かと思いますが、これらのシステムは読み取りを効率的にするために挿入に最適化されていますが、OLTPワークロードで一般的な更新には最適化されていません。そこで私たちは、更新の安定したストリームと高スループットをサポートするために、Delete Bufferという概念を用いた新しいイノベーションを生み出しました。CDCストリームで更新を検出すると、それを削除と挿入に分解します。削除を別途保存してメモリにバッファリングし、プライマリテーブルに挿入を適用し、クエリ時に使用される隠しDelete Bufferを維持します。
この隠しDelete Bufferはデータのクエリ時に維持されます。クエリスキャンオペレーターは十分にインテリジェントで、これら2つのデータを組み合わせることで、実際には更新文として適用されていないにもかかわらず、データが更新されたかのような印象を与えることができます。例を挙げて説明しましょう。ここではABCの例があります。トランザクションがABCで開始され、スナップショットを取得したので、ABCが表示されます。
ここで、ソース側でキーAが更新されたと仮定します。この更新は削除に分解されます。LSN 300（この削除が適用されたトランザクション）でDelete Bufferにエントリを挿入し、LSN 300と挿入LSN 4で新しい値をプライマリテーブルに挿入しました。これは基本的に、Aの以前の値が100から300までの可視性を持ち、Aの新しい値が300以上の可視性を持つことを示しています。
Amazon Redshift側で新しいトランザクションが開始されると、xminとxmaxのコンテキストと共にこれら2つのデータ項目を組み合わせ、Redshift側で更新として適用されたかのように新しい値4を読み取ることができます。同様に、データタプルが削除された場合、例えばここでCが削除されると、Delete Bufferにのみ追加されます。Dが挿入された場合は、Insert Bufferにのみ追加され、スキャンオペレーターが十分にインテリジェントになったため、トランザクションは自動的にこれを認識します。これは、高いCDCスループットを維持しながら、運用データから分析までの遅延を一桁秒台に抑えることを可能にした重要なイノベーションの1つです。
お気づきの通り、これら2つを組み合わせるコストは若干高く、追加のCPUサイクルを消費します。そのため、常にこの処理を続けたくはありません。そこで、時々バックグラウンドのVacuumプロセスを実行して、このDelete Bufferをクリーンアップし、ベーステーブルにこのデータをプッシュします。このバックグラウンドVacuumまたはコンパクション処理が実行された後、データはインプレースで更新されます。その後、クエリはマージのコストを支払い続ける必要がなくなります。これはシステム全体で機会に応じてバックグラウンドで非同期的に発生するため、トランザクションへの影響はなく、コンパクション後は最適なパフォーマンスに戻ります。
Zero-ETLの未来：AWSのデータ分析戦略
それでは、このトークを締めくくるにあたり、主なポイントを振り返らせていただきます。私たちは、イノベーションに集中できるようにする Zero-ETL 統合機能をご紹介しました。これは設定と管理が容易で、数週間から数ヶ月かかっていたパイプラインの構築を数分で実現できます。セキュアなニアリアルタイム分析を提供することで、最も機密性の高いビジネスデータが、最高レベルのセキュリティで確実にシステム間で転送されます。さらに、異なるソースからのデータを組み合わせることで、データからグローバルな洞察を得ることが可能になりました。
先ほど申し上げたように、私たちは様々な Zero-ETL ソースをサポートしています。この例では、単一の Amazon Redshift データウェアハウスに、複数の RDS MySQL クラスター、Amazon Aurora MySQL 互換版または PostgreSQL 互換版、そして Amazon DynamoDB からのデータを取り込むことができます。異なる運用データベースをお持ちの場合、それらすべてのデータを Amazon Redshift の単一のデータウェアハウスに集約し、運用ポートフォリオ全体にわたる分析を行うことができます。これは Amazon Redshift の SQL 分析だけではありません。Amazon EMR、Amazon SageMaker、Amazon Athena、Amazon Bedrock、Amazon QuickSight など、AWS が提供する他の分析サービスのパワーを活用して、ユースケースに必要な洞察を得ることができます。
このアプローチは、すべてのユーザーのためのすべてのデータに対する分析を提供するという、私たちの全体的な分析戦略の一部です。データを Amazon Redshift に取り込むと、Serverless 機能を使用した Redshift のスケーリングメカニズムを活用し、データメッシュを作成できます。Amazon Redshift は、自身で管理するデータだけでなく、データレイク内のデータへのアクセスもサポートしており、様々なソースからデータを取り込むことができます。最近、8つの異なる SaaS プロバイダーからの Zero-ETL 統合を発表し、Salesforce や SAP などのプラットフォームからのデータを Redshift に取り込むことができるようになりました。Amazon SageMaker Lake House の発表により、データが Redshift に格納されると、Apache Iceberg 互換 API を使用して、お好みの分析ツールや機械学習ツールにデータを公開できます。
この Zero-ETL の取り組みは、単に Amazon Redshift にデータを取り込むだけでなく、より広範な分析の旅を可能にするものです。データが運用ソースから機械学習のライフサイクルに移行する際、そのデータは全行程を通してシームレスに遷移できます。私たちは、何年も前に示したこの Zero-ETL ビジョンへの投資を続けており、新しいソースの追加だけでなく、複雑なデータパイプラインを構築することなく、トランザクションデータや運用データの分析を可能にする機能も毎年強化しています。
このアプローチにより、チームはアプリケーションのユースケースとデータからの洞察の抽出に集中でき、AWS クラウドデータ戦略と取り組みを加速し、ビジネスのより良い意思決定を推進することができます。これらの機能を試していただき、引き続きフィードバックをお寄せいただければ幸いです。それにより、私たちはサポートする機能全体と Zero-ETL ソースの改善を続けることができます。お時間をいただき、このセッションにご参加いただき、ありがとうございました。プレゼンテーションの改善方法を理解するため、モバイルアプリでこのセッションのアンケートにご協力ください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion