re:Invent 2025: DynamoDBやAuroraからRedshiftへのZero-ETL統合の詳細解説
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Deep dive into databases zero-ETL integrations (DAT445)
この動画では、AWS Zero-ETL統合について詳しく解説しています。Dave Gardnerが、トランザクションデータを分析システムに移行する複雑さを軽減する方法を説明し、DynamoDBからRedshift、LakeHouse、OpenSearchへの統合、AuroraからRedshiftへの統合を中心に取り上げています。DynamoDBではPoint In Time Recoveryとテーブルポリシーの設定が必要で、OpenSearchへは数秒でデータが更新される一方、RedshiftやLakeHouseへは約15分の鮮度となります。Auroraの統合はストレージレベルで実行され、プライマリインスタンスに影響を与えません。また、RDS OracleやOracle at AWS、DocumentDBからのZero-ETL、さらに先週発表されたセルフマネージドデータベース向けのAWS Glue Zero-ETLについても紹介されています。DDL変更の自動伝播やCloudWatchによる監視機能など、運用面でのメリットも強調されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
re:invent 4日目：データパイプラインの課題とZero-ETL統合の紹介
それでは、re:invent 4日目、replayの前の最後のセッションです。re:inventの最北端のエリア、場所まで足を運んでいただき、ありがとうございます。ここまでの長い道のりを来ていただいて。私は実際にはMGMに滞在していて、以前はMandalay Bayにいたので、これらの異なる場所を移動するのは楽しいですね。本当に皆さんがここにいてくださることに感謝しています。それでは、ここにいる方の中で、データアーキテクト、データサイエンティスト、ETLプログラマーの方はどれくらいいらっしゃいますか？よし、いいですね、大多数の方がそうですね。素晴らしい。このセッションでは、皆さんのお役に立てるようなこと、できれば物事を少し簡単にできるようなことをカバーしていきます。
そういった役割では、データパイプラインについて心配することになりますよね。運用データに対してどうやって分析を行うか？複数のトランザクションシステムを1つの分析システムにまとめて、そのデータをすべて正規化するにはどうすればいいか？そして最後に、深夜の呼び出しやエスカレーション、そういったものにうんざりしていませんか？もしそうなら、良いニュースがあります。AWSのZero-ETL統合について詳しく見ていき、皆さんの生活をより簡単に、シンプルに、より良くして、今週ずっと話してきたあのクールなGen AIのことやエージェントに集中できるようにしていきます。
私の名前はDave Gardnerです。データベーススペシャリストのソリューションアーキテクトで、ノースカロライナ州シャーロット出身で、AWSに約9年在籍しており、今日のセッションを案内していきます。まず、運用データを分析システムに持ち込むためのビジネスまたはユースケースについてカバーします。なぜそれを行うのか、という理由ですね。次にZero-ETLの主要な機能についてカバーします。それから、DynamoDBとAurora向けのAWS Zero-ETLを作成する手順を説明していきます。ちょっと手を挙げていただきたいのですが、Auroraをソースシステムとして使っている方は？ほぼ全員ですね。いいですね。それからDynamoDBは？オーケー、素晴らしい。
Zero-ETLには多くのバリエーションがあることもカバーします。私たちは継続的に拡張していますので、Oracle RDSについても話しますし、先週発表した新しいこともカバーします。かなり広範囲ですが、聴衆の中で最も人気があると思われるいくつかについては深く掘り下げていきます。いいですね。最後に、それらの管理と監視についてカバーします。それでは、なぜトランザクションデータを分析システムに持ち込むのでしょうか？それは重要なインサイトを可能にし、ビジネス価値を推進するためです。
いくつかの例を挙げると、顧客関係管理、金融サービス業界であれば不正検知、ゲーム会社であればゲーマーのリーダーボード、在庫最適化、センチメント分析、そして製品インサイトと販売、さらに多くのユースケースがありますよね？つまり、そのトランザクションデータに対して行いたい多くの分析ニーズがあり、そこからすべての金を掘り出したいわけです。それでは、これはレベル400のセッションなので、例を取り上げて、それを深く掘り下げていきましょう。
Aurora MySQLとGen AIを活用した製品レビューのセンチメント分析ユースケース
それでは、トランザクションデータはAurora MySQLデータベースに格納されています。私たちから製品を購入したお客様からのレビューデータがあります。これらのレビューや製品のセンチメントを判定するためにGen AI機能を使用し、その後、特定のセンチメント分析とレビューから得られたネガティブ、ニュートラル、またはポジティブなフィードバックに基づいてプロンプトを生成するために再びGen AIを使用します。では、それがどのようなものか見ていきましょう。小さいテキストで申し訳ありません。全部を1つに収めようとしました。
一番上のところに、Aurora Zero-ETLと私たちのRedshiftクラスター間の統合があります。これによってトランザクションデータが持ち込まれます。次に製品を持ち込みます。レビューはすでにそこにありました。そして、これら2つを結合して、顧客IDに基づいてレビューとトランザクションを一緒にしたテーブルを構築します。次に、Claudeを呼び出すための外部モデルを構築し、LLMを持ち込んで、それらの特定のレビューのセンチメントが何であるかを判定します。そして、基本的にそれをテーブルに構築していきます。
そして楽しい部分は、そのセンチメントを積極的に活用して、LLMを使用する、つまりエージェントを使用して、お客様のフィードバックに基づいた応答を構築することです。お客様が非常にポジティブなレビューをした場合、購入した製品に対して次に購入すべき最適な製品はこれですよ、と伝えるかもしれません。ニュートラルだった場合は、まあ、別の種類の応答を提供するかもしれません。しかしネガティブな場合は、次回の購入時に送料無料や割引クーポンを提供して、そのお客様の信頼を取り戻したり、問題を正したりしようとするかもしれません。
これは、トランザクションデータを分析システムに移行することがなぜ重要なのかという例を示しており、Zero-ETLはそれを簡単に実現する方法の1つです。それでは、トランザクション側と分析側の両方のアーキテクチャを深く掘り下げていきます。これを実現するアーキテクチャはCQRS、つまりCommand Query Response Segregationと呼ばれています。
CQRSアーキテクチャ：トランザクションシステムと分析システムの統合における複雑性
私がこれに使うのが好きなもう1つの例えは「適材適所」です。トランザクションシステムについて、先週のことを考えてみてください。先週は米国の主要な祝日がありました。多くの旅行があり、多くの人々が愛する人たちに会いに行き、そしてBlack Friday、そしてCyber Mondayがありました。小売業者の観点から見ると、その間にバックグラウンドで多くのトランザクションが発生していました。これらのトランザクションシステムには、ピークワークロードが発生したときにそれをサポートするための高可用性、パフォーマンス、スピード、可用性が必要です。分析機能に邪魔されるわけにはいきません。
DynamoDB、DocumentDB、そしてAuroraのRDS リレーショナルデータベースを、このアーキテクチャのデータ永続化層として持っています。これは典型的な3層Webアプリケーションかもしれません。これはサーバーレスの例ですが、運用面についてはご理解いただけると思います。ビジネスを運営しなければなりません。それを壊してはいけない、ですよね？それが重要なポイントです。さて、これらのシステムからトランザクションデータを抽出して、そのデータから金を掘り当て、その上で実行したい分析を行う必要があります。
DynamoDBとDocumentDBについては、ストリームを有効にします。Lambdaファンクションでそのデータを抽出して取り込みます。リレーショナルデータベースについては、レプリケーションを使うか、あるいはDMSを使うか、もしくはお気に入りのETLツールを使ってリレーショナルシステムからデータを引き出します。データを取得したら、分析システムにロードします。もう一つ構築するものがあります。写真を撮る前に、ちょっと待っていただいた方がいいかもしれません。
S3 Data Lake、Redshift、OpenSearch、そしておそらくレポート目的で使用する別のデータベースもあります。さて、ここからが素晴らしいところです。写真を撮りたい方は、今が良いタイミングです。これが完全なアーキテクチャを描き出したものです、そうですよね？これで分析システム側にデータがあり、本当にそのデータをマイニングし始めることができます。データエンリッチメント処理、データ付加価値処理、SQL分析ができます。LLMやエージェントを接続して、データディスカバリーを行い、先ほどお話ししたビジネスに本当にインパクトを与え、お客様との信頼を獲得し、私たちを前進させるすべての素晴らしいことができます。
繰り返しになりますが、運用面では信頼性が必要です。独立したスケーリングが必要で、ビジネスを推進する必要があります。これがトランザクションシステムと分析システムを統合する全体的なアーキテクチャです。さて、真ん中のこの部分が面白い部分ですよね？そしてこの部分は、複雑になります。なぜ複雑なのか、その理由についてこれから説明します。また脆弱でもありますよね？そして今、AWS Zero-ETLを使えば、多くの場合、マネージドサービスにオフロードできる差別化されない重労働なのです。では、そのマネージドサービスがどのように役立つのか見ていきましょう。
DynamoDBからRedshift・LakeHouse・OpenSearchへのZero-ETL統合の実装手順
AWS Zero-ETL統合により、これらのデータパイプラインのセットアップをシンプルにしたいと考えています。また、それらの管理もシンプルにしたいと考えています。センチメント分析や、エージェント型AIエージェントで実行したいその他すべての素晴らしいことのために、先ほどお話しした強力な分析を可能にします。Zero-ETL統合がそれを可能にし、より簡単にすることで、皆さんは他の付加価値プロセスや物事に集中できるようになります。繰り返しになりますが、ペタバイト規模のトランザクションデータに対する分析を可能にする、シンプルで安全で簡単な方法です。
それでは、Zero-ETLがどのように機能し動作するか、そしてそれに必要なことについて、もう少し詳しく見ていきましょう。さて、複雑さについてお話ししましたよね?では、最初に見ていくソースシステムであるDynamoDBテーブルを見てみましょう。これはNoSQLデータベースで、キーバリューペアです。パーティションキーとソートキーがあり、そのNoSQLデータベースに関連付けられた複数の属性、または可変の属性があります。こちらが例です。これが私の製品説明です。製品説明には製品IDがあります。いくつかの異なる属性があります。そして、この中に組み込まれたネストされたJSONの説明フィールドがあります。
これをRedshift、つまり列指向データベースに移行するには、いくつかのマッピングが必要になりますよね?独自のETLパイプラインでは、それを自分で行う必要があります。Zero-ETLがその一部をどのように支援するかをお見せします。DynamoDBのもう一つの課題は、シングルテーブルデザインですよね?つまり、シングルテーブルデザインは基本的に、一つのテーブルがあるけれども、アイテムコレクションを保存しているということです。似た特性やキーを持つデータを収集していますが、同じ行ではない可能性があります。この場合、同じテーブルに請求書データと課金データがあります。これをETLして抽出し、それを取り出すためのすべてのロジックを実行する必要があります。
では、ターゲットについてお話ししましょう。Redshiftは列指向のMPPデータベースです。列、ディストリビューションキー、ソートキー、そしてSUPERデータタイプがあります。そして今、このNoSQLデータベースをこの列指向データベースにマッピングする必要があります。これが私たちが支援することの一つです。さて、DynamoDBからのLakeHouse S3ターゲットも似ていますが、SUPERデータタイプがないだけです。さらに面白いことに、OpenSearchもDynamoDBから使用できるターゲットシステムです。今度はドキュメント、インデックスID、検索条件について話しています、よね?
つまり、まったく異なるデータレイアウトです。これが、データパイプラインを管理し、このマッピングをすべて理解することの複雑さの一部です。ここがZero-ETLが支援する部分です。
では、Zero-ETLのソースとしてのDynamoDBです。統合パイプラインの構築を進める前に、事前に行う必要があることがいくつかあります。まず、Point In Time Recoveryが必要なので、それをオンにします。もう一つ必要なことは、RedshiftとGlueが私たちのテーブルとエクスポートテーブルをスキャンできるようにするテーブルポリシーを事前に設定する必要があるということです。
それでは、そのポリシーがどのようなものか見ていきましょう。これについてはドキュメントにも例がありますが、ちょっと順を追って説明していきますね。テーブルリソースポリシーで、GlueとRedshiftがこのテーブルにアクセスできるように設定します。何ができるかというと、export table to point in time、describe table、describe exportができます。どのテーブルにアクセスできるか、それを記述するわけです。つまり、これが基本的に設定するポリシーで、残りの部分はZero-ETLが自動的にマッピングしてくれます。
というわけで、まずこれをカバーしておきたかったんです。これは再びGlueコンソールです。スクリーンショットでは少し小さく表示されていますが、ここに複数のソースタイプがあるのが見えますね。この特定のユースケースでは、DynamoDBに焦点を当てます。Salesforceやその他のものもありますので、Zero-ETLが私たちにとって大きな取り組みであることがわかると思います。皆さんのようなお客様からのフィードバックに基づいて投資を続けています。必要なものはここに追加していきます。
さて、この特定のウォークスルーでは、ソースとしてDynamoDBを選択します。そしてこの場合、ターゲットはRedshiftとLakeHouse、またはS3になります。DynamoDBテーブルを定義します。ここでクールなことの一つは、クロスアカウントが最初から使えることです。つまり、トランザクション操作を一つのAWSアカウントで行い、分析を別のアカウントで行うといったことができるわけです。これがそれを実現してくれます。
次に定義するのは、Redshiftに送るのか、データレイクに送るのか、そして実際のカタログは何か、ターゲットデータベースは何かということです。そしてポリシーですが、ここに「fix it for me」というのがありますね。これはAIエージェントが登場する前に作られたものですが、似たようなコンセプトです。つまり、適切なリソースポリシーがないですよ、私が代わりに構築してもいいですか、と言ってくれるんです。それが「fix it for me」機能です。
それがどのように見えるかというと、データカタログのリソースポリシーとS3ロケーションに、Zero-ETLが動作するためのIAMポリシーが必要ですよ、と言ってきます。そしてこれがそのポリシーです。それを見て、いいね、やってくれ、と言えばいいわけです。さて、出力設定では、先ほど説明した異なるデータタイプとデータレイアウトのマッピングに入っていきます。ここにいくつかのオプションがあるのが見えますね。トップレベルのフィールドだけをunnestするか、すべてのフィールドをunnestするか、あるいは何もunnestしないかを選択できます。
そして、パーティショニングの観点からは、DynamoDBにネイティブなパーティションキーを使用することもできますし、カスタムキーを使用することもできます。そして、ここでテーブル名を設定して名前を付けることもできます。さて、データマッピングのパーティショニングオプションです。これはターゲットによって異なりますよね。つまり、Redshiftがある場合は、どのように見えるかを確認します。そして、データレイクをターゲットとする場合は、Icebergテーブルになります。ですので、それぞれ少し異なる動作をすることになります。
そして、これがどのように見えるかです。こちらが再びproductsテーブルです。これが、Zero-ETLでRedshiftに移行したときのRedshift側での定義の様子です。ご覧のように、私のキーがRedshiftでのディストリビューションキーになっています。つまり、同じキーで分散されることになります。これにより、DynamoDBのパーティションキーが適切であれば、良好な分散、正規分布が得られます。そして、残りの値を取得して、SUPERデータ型とvalueに格納します。
そして、RedshiftにはそのSUPERデータ型からデータを取り出して使用できる関数があります。もしそれらを個別のカラムに分割したい場合は、付加価値プロセスを行ってそうすることもできます。さて、LakeHouseまたはS3をターゲットとする場合です。Icebergテーブルの抜粋をコピーしました。Icebergテーブルの定義はこれくらい大きくて、画面に収まりきらなかったのですが、例として示すためにdescriptionフィールドをここに抜き出しました。
そして、こちらがそのIcebergテーブルがどのように見えるかのAthenaクエリです。ご覧のように、product ID、product name、さまざまな属性、そしてJSON形式のdescriptionフィールドがあります。同様の機能ですよね。良いニュースは、Zero-ETLがこれらすべてを私のために行い、テーブルをセットアップしてくれたことです。わずか数分で作成できます。
さて、Zero-ETLのセットアップの最後のいくつかのステップです。セキュリティ統合を設定します。パイプライン用に異なるKMSキーを使用できますので、カスタマー暗号化キーを使用することも、サービスキーを使用することもできます。また、ワンタイム移行オプションもあります。
では、DynamoDBテーブルの一回限りのスナップショットを取得したい場合もありますし、継続的なレプリケーションを行うこともできます。つまり、製品が変更されたり何かが起こったりすると、それがDynamoDBからRedshiftやレイクハウスへと伝播していくわけです。そして、説明できるように名前を付けます。これで、DynamoDBからRedshiftまたはレイクハウスへのセットアップがほぼ完了です。
これをアクティブ化して作成すると、おそらく5分から10分かかります。内部では、Glueやその他のパイプラインステップの設定をすべて行っています。作成中からアクティブになり、それが完了すると、基本的に15分ごとにそのデータをプルして、継続的なレプリケーションを行う場合はRedshiftに送信し始めます。内部的には、DynamoDB S3エクスポートとポイントインタイムリカバリを活用しています。したがって、ターゲットシステムまたは分析システムでのデータの鮮度は約15分です。つまり、DynamoDBで何かが起こると、約15分ほどでデータレイクに表示され、これは通常、Redshiftの分析タイプのクエリに適しています。リアルタイムの応答は必要ありません。
DynamoDB StreamsとOpenSearchを使った数秒単位のリアルタイム検索の実現
次にお話しするターゲットでは、もっと高速にしたいと思うでしょうし、その理由についてもお話しします。DynamoDBがソースで、今度はOpenSearchをターゲットとして使用します。これはDynamoDB Streamsを使用するため、DynamoDB Streamsで新旧イメージをオンにする必要があり、もちろんプロセスがテーブルにアクセスできるようにする別のIAMポリシーも必要です。ここでStreamsを使用して数秒でデータを更新したいユースケースの理由ですが、私は旅行・ホスピタリティ業界を担当しています。例えば、プロパティ管理またはカーフリート管理がDynamoDBにあり、何が工事中で何が利用可能かなどがわかりますが、顧客が12月の最初の週にラスベガスで赤いテスラを検索できるようにしたいとします。これらのクエリやアクセスパターンが常に変化する場合、DynamoDBでは非常に難しいことですが、OpenSearchなら本当に得意です。そして、メンテナンスから車が戻って利用可能になったら、すぐにその顧客がレンタルできるように、数秒で更新されることを確認したいのです。だからこそ、OpenSearch側では数秒単位のデータの鮮度が重要になるのに対し、他の2つでは15分でほとんどのユースケースをカバーできるはずです。
さて、OpenSearchでブループリントを用意し、基本的にここで空のパイプラインを選択します。そして、次のスライドで多くのJSONマッピングを行います。さて、その4:15は月曜日に行われたワークショップでした。これは基本的にそのワークショップのスクリーンショットです。ですから、家に帰ってこれをユースケースの1つとして検討したい場合は、AWSアカウントチームとイマージョンデイを設定できます。これを一緒に進めて、セットアップの実践的な経験を積むことができますので、ぜひAWSアカウントチームに連絡してください。
では、JSONを見ていきましょう。あまり難しくならないように、そして繰り返しになりますが小さい文字で申し訳ありませんが、少なくとも画面は大きいです。まずマッピングを行います。DynamoDBテーブルがあり、それを定義し、新しいイメージが何かを指定し、Streamsから来てS3に入る中間的なデータランディングゾーンとなるS3バケットを用意します。そして、その機能に名前を付け、次に同期側、つまりOpenSearchターゲット側を行います。そして、画像を使いたい場合は、構築していきます。
それでは同期側では、このデータを送信したいOpenSearchクラスターを定義します。このデータを送信したいインデックスは何かを定義します。複数のパイプラインを同じクラスターの異なるインデックスに、または同じインデックスに送ることもできます。そして重要なのがこのマッピング関数です。そうですね、これは皆さんにとって少し作業が必要になります。マッピングとJSONを書いて、これを完成させて、望む形でマッピングする必要があります。ただ、これはETLではあるんですが、少し注意点があります。マッピングの部分は皆さんが書く必要がありますが、パイプライン処理、データの移動、監視はすべて自動でやってくれます。
さて、これでセットアップができました。インデックスタイプ、フィールド、マッピング、アクション設定について説明しました。DynamoDBでの変更のストリーミングを開始します。これがすべて作成されて稼働したら、OpenSearchクラスター上で同じデータセットに対して製品検索を開始できます。そしてこれはOpenSearchクラスター上で数秒で更新されます。これでほぼあらゆるものに対して検索が可能になります。また、OpenSearchは自然言語処理やセマンティック検索などに非常に優れています。本当に多くの可能性が開けます。
さて、OpenSearchに関して1つ注意点があります。そのパイプラインにはOpenSearch Compute Units、つまりOCUがあり、各OCUは1秒あたり1メガバイトのデータを処理できます。これはスライドのタイプミスで申し訳ありません、気づかなかったのですが、これは実際にはDynamoDBテーブルの10 WCUに相当します。ですので、ここでやりたいことは、WCUとOCUをマッチさせて、パイプラインがデータを処理し、変更に追いつけるようにすることです。OCUはオートスケーリングをサポートしており、スケールアップとスケールダウンができるようにしておきたいところです。サーバーレスではありますが、DynamoDBテーブルへのスループットに応じてスケールアップとスケールダウンします。これは注意しておくべき点です。この統合はデッドレターキューをサポートしているので、何らかのエラーや処理されないものがあれば、CloudWatchですべて処理されます。
Auroraストレージレベル統合とセルフマネージドデータベース向けZero-ETLの拡張
さて、これでソースとしてのDynamoDBについて説明しました。詳しく見てきましたね。では次にAuroraに話題を切り替えましょう。多くの皆さんが使っているので、非常に関連性が高いはずです。Auroraのゼロ-ETLについても同様に、シンプルで高性能にして、トランザクションデータを分析システムに移行しやすくし、そこに眠る金を掘り出せるようにしたいと考えています。エンジニアリングチームがこの統合で実現した素晴らしいことの1つは、ストレージレベルで行われるということです。つまり、コンピュートのAuroraクラスターのプライマリインスタンスには影響がありません。すべてストレージレベルで行われます。データのシーディングと継続的なレプリケーションを、AuroraとRedshift間でストレージレベルで自動的に処理します。
また、CloudWatchによる監視もあり、ラグ、行数、パフォーマンスなどを監視できます。そしてターゲットがRedshiftの場合は、Redshift側にもいくつかのテーブルがあり、そこに入ってくるデータを監視できます。では、これがどのように機能するか、もう少し詳しく見ていきましょう。MySQL 3.5.2以上を実行していれば、3.5.2は今ではサポート終了していると思いますので、誰も実行していないことを願いますが、そしてPostgres 16.14以上であれば、データを取得できます。Aurora側のストレージからRedshiftストレージへの並列直接エクスポートを使用します。これでシードデータの移行が実現します。DMSの用語を使えば、フルムーブのようなものですね。
次にCDCを行います。内部的にはMySQL拡張binlogを使用してデータを移動し、Postgresの場合はPG論理レプリケーションを使用します。これを設定すると、CDCがストレージから開始されます。CDCストリームが実行され、Redshiftにレプリケートされます。これは通常数秒で完了します。データの鮮度という観点から見ると、通常数秒で最新の状態になります。こちらでトランザクションが発生すると、わずか数秒でRedshiftに反映されるので、その上で分析を開始できます。これが基本的なセットアップです。そして、これは本当に気が散りますね、すみません。
さて、それではデータのセットアップをもう一度見ていきましょう。Auroraは、MySQLでもPostgresでもリレーショナルデータベースです。プライマリキー、インデックスがあり、通常のリレーショナルデータベースと同じようにカラムがあります。次にRedshiftですが、Redshiftもある意味リレーショナルですが、データはカラムナー形式です。そして先ほどお話ししたSUPERデータ型もあります。これをマッピングする必要があります。LakeHouseも同様ですが、SUPERデータ型はありません。
さて、Aurora zero-ETLについて、主な違いの一つはフィルタリングが可能になっていることです。このフィルタリングは、インクルード・エクスクルード型のフィルタリング機能です。完全なETLではありません。複数のトランザクションシステムについてお話ししましたが、私が数年間サポートしていたあるお客様は、8つの異なるトランザクションシステムをデータウェアハウスに統合し、それらすべての顧客コード、製品コードなどを正規化していました。これはそういうものではありません。これは、その8つすべてをデータウェアハウス内のステージングエリアやローエリアのようなところに持ってくるのに役立ち、その後、付加価値のある処理を行って、それらすべての顧客コード、製品コードをデータウェアハウスにある何かに正規化します。
でも、これは面白いですよ。インクルードやエクスクルードができます。これはマニュアルから直接引用したMySQLの例です。bookデータベースがあるとして、ミステリー好きならミステリーだけを持ってくることができますし、それを除外することもできます。スティーブン・キングが好きなら、彼の本をすべて持ってくることができます。フィルタリング機能がどういうものか、おわかりいただけると思います。一つ指摘しておきたいのは、2年前に最初にリリースした時点ではフィルタリング機能はありませんでした。皆さんのようなお客様からのフィードバックで、このデータをフィルタリングできるようにしてほしいという声があり、サービスチームがこれを追加しました。ですから、zero-ETLを試してみて、こういう機能があればいいのにと思ったら、AWSのアカウントチームに伝えてください。そのフィードバックをサービスチームに届け、それらの機能を組み込むよう努力します。この分野では決して完成したわけではなく、投資と拡張を続けています。繰り返しになりますが、フィルタリングロジックはインクルード・エクスクルードですが、完全なETLではありません。これがAuroraをソースとしてzero-ETLをセットアップする際の重要なポイントまたは違いです。
「自動修正」機能もあります。これについては一つ注意が必要です。ここに「再起動が必要」と書かれているのがわかりますね。本番システムでこれを実行する場合、日中に再起動されるのは必ずしも望ましくありません。これはおそらくスケジュールしたいものでしょう。ちょっとした考慮事項です。再起動が必要な理由は、例えば私のAurora MySQLデータベースやPostgreSQLでレプリケーションサービスが有効になっていない場合です。論理レプリケーションをセットアップする際には再起動が必要で、Auroraをソースとしてセットアップする際に考慮すべき点です。
Redshift側では、大文字小文字の区別に関する「fix it for me」機能もあります。例えば、Redshiftクラスターをセットアップした時に、大文字小文字の区別を設定していなかったとします。この「fix it for me」がそれを行ってくれます。基本的にはここで、「これをやりましょうか?」と聞いてくるので、continueを押すことができます。繰り返しになりますが、これらはAIエージェントではありませんし、クールな小さなボットでもありませんが、少なくとも「fix it for me」機能です。クリックすれば、すべてを処理してくれます。将来的にKyraが基本的にこれらすべてを自動でやってくれるようになっても驚かないでください。
さて、これでAuroraからRedshiftへのZero-ETLが完了しました。ここに例があります。これは先ほどセンチメント分析で見せたのと同じ画面です。はい、これでAuroraについては以上です。では次に他のRDSエンジンに移ります。これらはAuroraと似ていることがわかると思います。基本的にはZero-ETLをセットアップします。今回はOracleなので、binlogやPostgreSQLの論理レプリケーションではなく、redo archive logになります。これはデータベースが変更を私たちにレプリケートするためのメカニズムで、ここではストレージレベルの統合はありません。RDS OracleからRedshiftやLakeHouse S3へは、EBSまたはlog minerを使用することになります。
さて、OracleとAWSについてですが、昨年のOracle Worldで、AWSとOracleは、AWSデータセンター内でOCI Exadataをサポートすることを発表しました。これに触れる理由は、Oracle and AWSが何なのか知らない方もいるかもしれないので、皆さんに知っておいていただきたいからです。これは、Exadataのパフォーマンスと可用性を必要とする重要なビジネスワークロードを持つお客様向けですが、それを他のすべての重要な要素と一緒にAWSインフラストラクチャ内で実行したいという場合のものです。Oracle at AWSからのZero-ETLも提供しています。基本的には、ODBをRedshiftやデータレイクなどのAWS分析サービスに接続することになります。
そのために必要なことですが、ODBネットワーク上でZero-ETLを有効にする必要があります。Secrets Manager、KMS、IAMポリシーをすべて設定する必要があります。そして、Oracle at AWS側では、変更をキャプチャできるようにredo logを有効にする必要があり、さらにアクセスを許可するためのSSL ASMのユーザー名とパスワードのgrantsが必要になります。はい、これでOracle at AWSについては以上です。これについては、まもなく本番環境に移行する予定のお客様が1社いますが、これは比較的新しいものです。
DocumentDBからOpenSearchへ、これは確か前四半期に発表されたと思います。DocumentDBからOpenSearchへのZero-ETLは、DynamoDBと非常に似ています。IAMパーミッション、中間のS3バケット、パイプラインのパーミッションが必要で、さらにドキュメントやコレクションをOpenSearchインデックスにマッピングするJSONパイプラインも必要です。DocumentDBをソースとする場合、いくつか注意すべき点があります。制限事項がいくつかあります。DocumentDBクラスターに複数のコレクションがある場合、パイプラインごとに1つのDocumentDBコレクションのみとなります。そのクラスターに対して複数のパイプラインを実行することはできますが、コレクションとパイプラインの間は1対1の関係になります。
さて、1つ注意点があります。他のサービスにあったクールなクロスリージョン、クロスアカウント機能が、DocumentDBではまだ完全には実装されていません。もしそれが必要な場合は、ぜひAWSチームに連絡して要望を伝えてください。そうすれば、その機能リクエストを登録します。また、DocumentDBのelastic clusterフレーバーは、まだこれをサポートしていません。そして、OpenSearchのパイプライン設定は、DynamoDBと非常に似ています。
先週、セルフマネージドデータベース向けのAWS Glue Zero-ETLを発表しました。つまり、オンプレミスやEC2上で稼働しているMySQL、SQL Server、Oracle、PostgreSQLデータベースをお持ちの場合、同じZero-ETLの魔法を使って、そのデータをAWSの分析サービスに取り込むことができるようになりました。このプレゼンテーションの大部分は、少し前に作成したものです。これは先週発表されました。
ただ、皆さんにも知っていただきたいので、ここで触れておきたいと思いました。では、オプションをまとめると、8つの新しいZero-ETL接続があります。これには、AuroraやDynamoDBデータベースのようなAWSマネージドサービスが含まれます。Amazon EC2上で稼働するデータベースや、オンプレミスのデータベース、さらにサードパーティクラウドも含まれます。つまり、AWSとサードパーティクラウドやオンプレミスで稼働しているものとの間でネットワークが設定されていれば、Zero-ETLサービスを使ってデータを同期し、分析システムに追加することができます。
Zero-ETLの運用メリット：自動スキーマ変更対応とCloudWatchによる監視機能
繰り返しになりますが、たくさんのオプションがあります。私たちは本当に、お客様がトランザクションデータから価値を引き出せるように、シンプルで、パフォーマンスが高く、簡単にしたいと考えています。これで、ソースとターゲットのすべての組み合わせをカバーしました。では次に、モニタリングとZero-ETLのメリットについて少しお話ししましょう。パイプラインがすべて稼働していて、私は幸せいっぱいです。そして開発チームがカラムを追加して、誰にも伝えません。私のETLはどうなるでしょうか？通常、ETLを設定したときにそのカラムがあることを知らなかったので、そのカラムを取得できないか、または最初にデプロイされた夜中にETLが壊れる可能性が高いです。なぜなら、余分なカラムがあって、insertがrawレイヤーにあるデータと一致しないからです。どちらにしても楽しくありません。
では、Zero-ETLの場合、そのケースで何が起こるでしょうか？binlogやPostgreSQLの論理レプリケーションを使用しているので、テーブルの変更やカラムの追加といったDDLやDML変更操作が、Zero-ETLを通じて伝播され、Redshiftテーブルがその追加カラムで更新されます。私は夜ぐっすり眠れます。データも保持されるので、大規模な更新を行った場合も、それが流れてきてすべてのレコードが更新されます。ですから、間違いなくメリットがあります。他のことに集中でき、夜もぐっすり眠れます。
そして、これはRedshift側でそれがどのように見えるかを示しているだけです。繰り返しになりますが、イマージョンデイを開催して、皆さんにこれを実際に体験していただき、テストしていただければと思います。それでは、脆弱な複雑性の問題に対処できるはずだということについて触れておきたいと思います。Zero ETLがそれを処理してくれます。すべての可能なシナリオに対応できるかというと、そうではないかもしれませんが、テーブルの変更、カラムの追加、新しいテーブルの追加といった一般的なユースケースは確実にカバーします。これらすべてがZero ETLでカバーされます。
それでは、Zero ETLに組み込まれている監視と管理機能についてお話ししましょう。まずはステータスです。ご存知のように、私たちが作成しているものには、いくつかのステータスがありますので、それを追跡することができます。これはそれほど興味深いものではないかもしれません。しかし、興味深いのは、変更中、同期中、または注意が必要といったステータスです。これはおそらく知っておきたい情報でしょう。ですので、CloudWatchアラートを設定して、Zero ETLのステータスが注意が必要または失敗となった場合に、おそらくそれを確認したいと思うでしょう。
そういったことで、これは通常のCloudWatchアラートメカニズムに接続されており、それが用意されています。さて、Zero ETLを通じてデータがどのように流れているかを追跡するには、CloudWatchと通常のメトリクスを使用します。挿入、更新、削除のカウントなどがあり、ここではCDCとシードデータの両方があることがわかります。つまり、フルムーブで何行移動したか、1日または1時間の間にCDCで何行移動しているかを教えてくれます。また、これらについてもCloudWatchアラートを設定できます。
例えば、通常CDCで1分あたり1000行を確認している場合、10分以上500行を下回った場合にアラートを設定して、何が起こっているのか確認する必要があるということができます。つまり、CloudWatchで慣れ親しんでいるすべての監視とアラートメカニズムを、Zero ETLでも同様に適用できるということです。OpenSearchについてですが、OpenSearchパイプラインには追加の監視メトリクスがあります。CloudWatchを通じてダッシュボードを設定できます。パイプラインのメトリクスタブにもあります。CPU使用率、OCU使用率、メモリを追跡します。また、中間部分であるS3にドロップしたレコード数、レコード数、エラーがあるかどうかも教えてくれます。
そして、同期では、転送されたバイト数、書き込まれたドキュメント数、レイテンシなどの詳細が表示されます。これにより、すべてのZero ETLを追跡できます。これはトラブルシューティングにも役立ちます。これらすべてはCloudWatchログに記録されるため、トラブルシューティングが必要な場合は、CloudWatchログを調べることができます。まとめると、AWS Zero ETL統合は、繰り返しになりますが、トランザクションデータを分析システムに移行することをシンプルで管理しやすくし、これまでお話ししてきたすべての素晴らしい生成AIと分析機能を実現しようとしています。
それでは、これでプレゼンテーションはほぼ終了となります。その他の参考資料として、いくつかURLをこちらに載せています。ドキュメントもありますし、もし他にご質問があれば、喜んでここ前の方に座ってお答えしますので。それでは、re:Playの前の最後のセッションまでお越しいただき、改めてありがとうございました。今夜は素晴らしいre:Play体験をお楽しみください。そしてお越しいただきありがとうございました。アンケートへのご記入もお忘れなく。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion