re:Invent 2024: AWSが提案するBatchからStreamへの移行とApache Flinkの活用
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Accelerate value from data: Migrating from batch to stream processing (ANT324)
この動画では、データ処理の進化とストリーミングアーキテクチャへの移行について解説しています。従来のBatch処理からStream処理への移行が必要な背景として、データの多様化と継続的な生成、そしてビジネスにおける迅速なインサイト生成の必要性を説明します。具体的な実装方法として、CDCツールによるデータ取得、Amazon MSKやKinesisによるストリームストレージ、Amazon Managed Service for Apache Flinkによる処理、そしてApache Icebergを用いたデータ保存までの一連の流れを詳しく解説しています。特にApache Flinkの活用により、Medallionアーキテクチャの簡素化や、生成AIを含む最新のユースケースへの対応が可能になることを示しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
データ処理の進化とセッションの概要
このセッションは皆様の時間を費やす価値があるものですし、re:Inventセッションの第一選択としてお選びいただいたことを後悔されることはないと思います。私はまだコーヒーを飲んでいないので、この1時間で私が言うことについては責任を負いかねます。たくさんのコーヒーマグが見えますね、それは素晴らしいことです。
これから1時間ほどで扱うトピックについてお話ししましょう。まず、データ処理がどのように進化してきたかについて簡単に概観します。 ビジネスにおけるデータのニーズと、データ処理の要件について説明し、どのツールが最適かを検討します。トピックから分かる通り、BatchとStreamingの両方について、そしてそれぞれをどのような場合に使用できるかについて説明します。 その後、Sofiaが引き継いで、サンプルアーキテクチャの例を通じて、既存のシステムをどのように変換してモダナイズし、Stream処理システムとしてビジネス目標を達成するために活用できるかをご案内します。 最後に、皆様がこの部屋を出る前に全体を整理できるよう、重要なポイントをまとめて終わりたいと思います。
現代のデータ環境とビジネスニーズの変化
それでは、データ処理の進化について詳しく見ていきましょう。人類とビジネスは何千年もの間、データを収集してきました。最も古い記録管理の証拠は、古代メソポタミアの約3000年前にまで遡ります。粘土板から始まった時代 - その頃のビジネスはゆっくりとしたものでした。9時から5時までビジネスを行い、データを収集し、粘土板に記録を刻みました。現代のビジネスが発展するにつれて、より多くのデータが生成されるようになりました。人口の増加とともにビジネス活動も拡大し、私たちは粘土板から台帳やノートブックの形での紙への記録へ、そして20世紀にはビットとバイトへと移行しました。データの生成、分析、処理は爆発的に増加したのです。
これが現代のデータ環境につながっています。21世紀のデータ処理は、私たちの先人たちの時代から大きく進化しました。インターネットの普及、スマートフォンの出現、そしてE-コマースによって、ビジネスはオンライン化し、データ生成は24時間365日の営みとなりました。 データは新しくユニークな性質を持つ多様なソースから生成され、必ずしも構造化されているわけではなく、マルチモーダルな形式で届くこともあります。そのため、処理する際には多様なデータに対応しなければなりません。 また、データは継続的に生成されています。ビジネス活動は営業時間内だけでなく、世界中で24時間体制で行われています。 興味深いことに、データは多くのアプリケーションによって分析されています。ビジネス内のより多くのアプリケーションが、顧客とのやり取りや内部プロセスを通じて捕捉された最新の情報を求めているのです。
ここで、ビジネスがこのデータに求めているものについて考えてみましょう。組織はますますデータ駆動型になっており、それによってビジネスニーズが年々進化してきました。 時代を超えて変わらないニーズもあります。すべてのビジネスは今でも週次、日次、月次などのレポートを必要としています。経営陣はこれらのレポートを使って長期的なトレンドを把握し、それに基づいて戦略を立てているからです。 しかし、この10年で形作られた新しい要件もあります。まず、単なるインサイトではなく、より迅速なインサイトを生成する能力が求められています。インサイトがより良い、より迅速な意思決定につながるという考えからです。顧客とのやり取りデータを生成するビジネスを考えてみてください - そのデータを即座に処理したいですか、それとも2、3日待ちたいですか？ 最後に重要なのが、Artificial IntelligenceとMachine Learningが現代のビジネスデータ戦略の強力な柱となっていることです。AIとMLモデルによる差別化は、データの品質とそれを処理する能力にますます依存するようになっています。全体像として、ビジネスはデータをビジネスレポートやBIツールの動力源として必要としていますが、それ以上のものも求められているのです。
データチームは、ビジネスチームが迅速なインサイトを得られるようにデータを提供し、今後数年間で企業の差別化につながるような機械学習や人工知能の機能を実現する必要があります。現代のデータ環境が継続的なデータ処理や多様なデータ処理へと進化していることと、データ駆動型ビジネスの現代的なニーズ（迅速なインサイトの生成、BIツールの継続的な活用、そして生成AIを含む人工知能や機械学習の機能の実現）を組み合わせると、これまで使用してきたツールで十分なのかを考え直す必要があります。
Batch ProcessingからStream Processingへの移行
これらのツールを簡単に評価してみましょう。まず一つ目はBatch Processing（バッチ処理）です。これは本質的に、一定の時間間隔でデータのスナップショットを取得し、それを処理してアプリケーション、ダッシュボード、レポートなどのダウンストリームシステムに情報を提供する機能です。Batch Processingは様々なユースケースで有効であり、ビジネスにおいて今でも重要な位置を占めています。先ほど議論したように、1時間ごと、1日ごと、または1週間ごとなど、固定された間隔で動作するビジネスレポートやBIツールの運用には、Batch Processingが引き続き適しています。しかし、他の2つの柱である迅速なインサイトの生成能力と、人工知能・機械学習機能の実現についても考慮する必要があります。
これを、工場でのセンサー読み取り値のモニタリングと、それを使用して設置済み機器の問題を事前に検知しようとする一般的な例で説明しましょう。4台のモーターが温度、振動、速度などのメトリクスをセンサーを通じて読み取っているシナリオを考えてみましょう。このデータは収集・処理が可能な状態にあります。Batch Processingシステムを使用してこのデータを収集、集約、処理する場合、毎時0分にスナップショットを取得し、バッチで処理することになります。
ここで、保守管理者がこのデータを使って不具合を検知する必要があるとします。バッチシステムでは、このデータをローカルデータベースに収集し、スナップショットを取得して、毎時ダウンストリームのデータベースに送信し、そこでクエリツールやダッシュボードツールを使用して読み取り値を表示することができます。この仕組みを不具合検知に使用する場合を考えてみましょう。保守管理者は特定の機械の問題をリアルタイムで特定し、事前に対処したいと考えています。この仕組みがどのように機能するか見てみましょう。目標は、保守管理者が不具合を検知し、事前に対処できるようにインサイトを生成することです。
ある機械がT=1の時点で異常値を出力した場合、標準的なネットワーク遅延により、システムはT=2の時点でそれを取り込みます。バッチは1時間ごとにスナップショットを取得するように設定されているため、直前のバッチ完了直後にデータが取り込まれた場合、次のバッチ実行まで約50分待つ必要があります。次のバッチはT=3の時点で処理を開始し、処理にはバッチサイズに応じて数秒から数分かかります。T=4の時点、つまり約60分以上経過してようやくデータが利用可能になります。保守管理者はこの結果に満足するでしょうか？おそらく満足しないでしょう。したがって、Batch Processingは迅速なインサイトを生成するには不十分だと結論付けることができます。
人工知能について、もう少し身近な例で考えてみましょう。最近の生成AIの登場により、Chatbotは至る所で見られるようになってきました。オンライン旅行会社で働いていて、ユーザーが簡単に情報を見つけられるように旅行用Chatbotを構築する任務を任されたとしましょう。
このChatbotは、フライト、ホテル、レンタカーなどの旅行情報をユーザーが簡単に見つけられるようにサポートします。この状況では、ユーザーに対して検索インターフェースを提供するChatbotがあり、バックエンドでは大規模言語モデルがこれらのクエリを解釈して回答を提供します。また、フライトの価格情報や空き状況、ホテルやレンタカーの情報などのコンテキストも必要です。これらの情報はすべてVector Databaseに流れ込み、機械学習モデルとChatbotにリアルタイムのコンテキストを提供して、お客様に応答します。
フライト、ホテル、レンタカーの空き状況や価格に関するすべての情報を1時間ごとにバッチ処理で収集し、Vector Databaseに取り込むとしたら、ユーザー体験がどうなるか想像してみてください。最新のスナップショットが午前11時の場合、11時02分に検索するユーザーは比較的新しい情報を得られるかもしれませんが、11時30分に検索する人はそうではないかもしれません。特に、休暇シーズンや夏休みなどの繁忙期には、旅行の価格や空き状況が数分で大きく変動する可能性があります。Vector Databaseを固定のバッチ間隔で更新すると、コンテキストに合わない情報となり、お客様の体験が損なわれてしまいます。
Stream Processingの実装と利点
機械学習や人工知能のユースケース、特に新しいものは、バッチ処理のニーズでは十分に満たすことができないことが分かりました。AWSでは、より良い方法があると考えています。それがStream Processingです。Stream Processingとは、固定の時間間隔でバッチを取得するのではなく、データが到着した時点でデータを収集、集約、処理することです。
センサーの読み取り値を監視する例に戻ってみましょう。1時間ごとにスナップショットを取得し、これらの読み取り値をローカルデータベースに保存して、そのデータベースのスナップショットを1時間ごとに取得する代わりに、Apache Kafkaトピックにこのデータをパイプ処理します。Kafkaは、ご存じない方のために説明すると、最も人気のあるデータストリーミング技術の1つです。オープンソースで、現在利用可能で、AWSでマネージドサービスとしても提供されています。このデータはKafkaトピックに保存され、各レコードは到着時にKafkaに書き込まれます。Kafkaはこのデータをすぐに処理できるようにするため、Apache Flinkアプリケーションを使用して即座に処理し、結果を提供することができます。
不具合検知の例に戻りましょう。この場合、時刻1の時点で異常値の読み取りが発生すると、すぐにKafkaトピックに書き込まれます。多少の処理遅延やネットワークレイテンシーはありますが。ほぼリアルタイムでデータが利用可能になるため、Flinkアプリケーションはすぐにそのデータの処理を開始できます。データサイズも小さいため、バッチ全体を処理するよりもはるかに速く、より効率的に処理を完了できます。最も重要なのは、結果がずっと早く得られることです。エンドツーエンドのレイテンシーは、数分や数十分ではなく、数秒程度になります。その結果、保守管理者は以前よりもずっと満足できるでしょう。ここでの重要なポイントは、Streamingがバッチ処理と比べてより迅速な洞察を可能にするということです。
人工知能と機械学習についてはどうでしょうか？チャットボットの例をもう一度見てみましょう。1時間ごとにスナップショットを取得してVector Databaseを更新する方式では、ユーザーに対して古い情報や文脈に合わない情報を提供してしまい、カスタマーエクスペリエンスの低下を招く可能性があります。その代わりに、レコードを1件ずつリアルタイムで処理する方式を考えてみましょう。各レコードには、航空券の価格、ホテルの価格、レンタカーの価格、および空き状況に関する情報が含まれています。各レコードはトピックにコミットされ、すぐにVector Databaseで処理されるため、最新のフライトやホテルの空き状況をチャットボットに問い合わせるお客様に、ほぼリアルタイムの情報を提供できます。
最新の人工知能と機械学習の機能、特に生成AIの機能は、システムを最新情報と同期させるためにリアルタイムで文脈に応じた情報が必要な場合、より良いカスタマーエクスペリエンスを提供し、より高い顧客価値を生み出すことができると言えます。ここまでたくさんの内容を扱ってきましたので、ここで振り返ってみましょう。
データが変化しているという事実から始めました - データはますます多様化し、より継続的に生成されるようになっています。その結果、データの扱い方を変える必要が出てきています。同時に、ビジネス要件はますます厳しく、要求の高いものになってきています。競争が激化する中、ビジネスエグゼクティブやマネージャーは、より迅速で適切な意思決定を行い、より多くのビジネス価値を生み出すために、このデータをすぐに必要としています。また、バッチシステムだけでは不十分であることも明らかになりました。バッチ処理は依然としてデータアーキテクチャの中で重要な位置を占めていますが、今日のデータに関する要件をすべて満たすには不十分です。そして最後に、Streamingは、これまでバッチシステムでは実現できなかった価値を引き出すことができます。
プレゼンテーションの次のセクションでは、本日の共同発表者であるSofiaが、現在のバッチシステムに存在する従来のアーキテクチャのサンプルをご紹介し、それらを最小限の混乱でStream処理システムに変換する比較的簡単な方法と、ビジネスにさらなる価値をもたらし続ける方法をご説明します。バッチからStreamingへの移行の詳細に入る前に、まず多くの方々にとって馴染みのある出発点を見てみましょう。典型的なバッチ処理、つまり分析システムのための典型的なETLパイプラインを見ていきましょう。
多くの方にとって馴染み深い状況だと思いますが、複数のデータソースや複数のデータベースがあり、定期的なバッチ処理のETLがこれらのデータを抽出し、クレンジング、フィルタリング、エンリッチメントによる変換を行い、スマートなダッシュボード作成のために整理された使用可能なデータをデータウェアハウスにロードします。しかし問題は、これらのワークロード、つまりデータパイプラインに時間がかかることです。データソースからのデータ抽出だけでも数時間、場合によっては1日かかることもあります。また、数十、場合によっては数百もの定期的なバッチジョブが1時間単位や分単位で実行されてデータを整理しています。
システムがスマートなインサイトを得るまでのエンドツーエンドの時間は、数時間から数日かかる可能性があることがわかります。変換部分は実際にはもっと複雑です。通常、この変換部分はMedallionアーキテクチャとして実装され、データがBronzeレベルからSilverレイヤー、Goldレイヤーへと流れる過程で段階的にデータを改善していきます。Bronzeレイヤーには生データ、Silverレイヤーにはよりクリーンで、フィルタリングされ、エンリッチされたデータ、そしてGoldレイヤーはキュレーションされ、クエリ可能な状態のデータが存在します。
エンドツーエンドの処理時間は、実際には最も長いバッチジョブのチェーンが完了するまでの時間に依存します。処理を効率化し、素早く反応するため、到着する各イベントにすぐに対応するために、データを停止することなく処理したいと考えています。処理を繰り返したくないのです。ストリーミングアーキテクチャの基本的なコンポーネントを見てみましょう。バッチシステムで見たアーキテクチャによく似ています。ストリーミングされたデータがStream Storageに送られます。
このStream Storageは、大量のデータを取り込むことができるメッセージブローカーとして機能し、一定期間データを永続化します。この永続性が必要なのは、プロデューサーが自分のペースでデータを生成し、コンシューマーが自分のペースでデータを消費できるようにするためです。プロデューサーやコンシューマーに何か問題が発生しても、データは失われません。Stream StorageはAWSにおいて重要であり、最初のステップはストリーミング方式で生成されるデータです。
次のステップはデータ処理です。データが到着する度に継続的に処理を行い、動きのあるデータを処理します。S3バケットにデータが格納された後に処理を行うバッチアーキテクチャと比較すると、Stream Storageから各イベントを受信しながら、データの継続的な処理が行われます。ストリーミングアーキテクチャの最後のコンポーネントは、データの保存先であるデータストアへの書き込みです。より長期間データを保持し、BIチームやデータアナリストなどによる更なる分析のためにデータを利用可能にするため、データストアにデータを書き込みます。
ご覧の通り、これらのステップは従来のバッチ処理アーキテクチャやETL（Extract Transform Load）によく似ています。 データが到着した時点で処理を行うことで、エンドツーエンドでほぼリアルタイムの体験を実現できます。 次のスライドでは、先ほど説明した各ステップの詳細について見ていきましょう。
ストリーミングアーキテクチャの詳細と課題
まず、データの生成とストリーミングストレージへの保存について説明します。 従来のデータベースでは、運用データベースからデータを抽出する際に、様々な抽出手順を実装していました。スナップショット手順やクエリ、データポーラーなどを使用して、異なる間隔で異なるクエリを使ってデータを抽出していました。これらの手順の実装方法は、データベースの種類によって異なります。そのため、MySQLデータベース用の手順、PostgreSQLデータベース用の手順というように、それぞれ別々の手順が必要でした。 実際には、1つのデータベースだけでなく、複数のデータベースタイプを使用することがあるため、より多くの手順とクエリが必要になります。また、多くのコンシューマーが存在し、それぞれが独自のデータ取得条件やデータ形式の要件を持っています。
ストリーミングアーキテクチャでは、データを取得する方式を「プル型」から、よりイベントベースのモードに移行したいと考えています。つまり、データベースから発生する各イベントに反応する方式です。 ストリーミングモードでデータを生成するには、2つの選択肢があります。1つはマイクロサービスなどのアプリケーションからイベントをプッシュする方法、もう1つはデータストアの変更を捕捉するCDCを使用する方法です。ここでCDCについて少し詳しく説明しましょう。 CDCは、データベースのトランザクションログを監視する仕組みです。各OLTPデータベースには、データベース上で発生する各操作を記録するトランザクションジャーナルがあります。例えば、挿入、削除、その他すべての操作がこのトランザクションログに記録されます。
CDCツールはこのトランザクションログを監視し、各イベントが発生すると、そのイベントを受け取り、変換し、捕捉して、目的の場所に送信します。
CDCツールの送信先として、KafkaやAmazon MSK、Amazon Kinesisなどを使用できます。AWS Database Migration Service（AWS DMS）や、人気のオープンソースライブラリであるDebeziumを使用することができます。このセッションでは、KafkaやKinesisのようなストリーミングストレージにデータを送信することに焦点を当てます。CDCツールは、データを取得して様々なデータベースやデータウェアハウスに保存したり、Apache Iceberg形式でデータレイクに送信したりすることができます。
Debezium の採用を決めた場合、最も一般的な導入方法はApache Kafkaコネクターを使用することです。AWSでは、Amazon MSK Connectを使ってDebeziumをAmazon MSK Connectと共に導入することができます。もう一つの選択肢は、Debeziumを組み込みライブラリとして使用することです。これは、アプリケーションがJavaライブラリをインポートし、データベースから直接アプリケーションにデータをストリーミングすることができます。例えば、Apache Flink CDCライブラリがまさにこの方法を採用しており、Amazon Managed Service for Apache Flinkと組み合わせて使用できます。最後の導入オプションとしては、あまり一般的ではありませんが、Debeziumをコンテナとしてスタンドアロンアプリケーションとして使用し、Kinesis、Pulsar、Redisなどの他のストリーミングソースと統合することができます。
CDCモードに移行することで、まず第一に、システムに発生するすべての変更にリアルタイムで対応できるため、レイテンシーを低く抑えることができます。また、ソースデータベースからデータを抽出してストリームストレージにプッシュするCDCツールが1つあれば済むため、負荷も軽減されます。多くのコンシューマーがいたとしても、すべてのコンシューマーはKafkaやKinesisなどのストリームストレージからデータを読み取ることができます。データベースに直接アクセスするのではなく、トランザクションログから読み取るようになりました。さらに、異なるスクリプトやクエリを実装する代わりに、様々なデータベースに接続できる1つのCDCツールを使用するため、アーキテクチャがよりシンプルになりました。
ステップ2は、データインモーションの処理です。先ほど述べたように、定期的に実行されるすべてのジョブには時間がかかります。データ処理を停止するのではなく、継続的にデータを処理したいと考えています。そのために、基本的なストリーミングアーキテクチャに立ち返って、どのようなサービスを使用するのか見てみましょう。データの生成と保存にはDebeziumとDMS、ストリームストレージにはAmazon MSKまたはAmazon Kinesis、ストリーム処理にはAmazon Managed Service for Apache Flinkを使用します。
ここで、会場の皆さんにお聞きしたいと思います。Apache Flinkをご存知の方は何人いらっしゃいますか？手を挙げていただけますでしょうか？素晴らしいですね。Apache Flinkを使用すると、スマートな処理が可能になります。おさらいですが、Apache Flinkは、有界・無界データの大量処理が可能な、広く採用されているストリーム処理フレームワークです。ストリームモードとバッチモードの両方でデータを処理できますが、Flinkの真の強みは、ステート処理を使用してストリームでデータを処理できる点だと考えています。これには、特定の時間枠内でのスマートな処理、スマートな集計、イベント相関、ルールエンジンの実装、Complex Event Processing（CEP）などの操作が含まれます。これがステート処理ですが、フィルタリング、データルーティング、データエンリッチメントなどの処理も可能です。実際、1つのジョブでステート処理とステートレス処理の両方を組み合わせることができます。
Amazon Managed Service for Apache FlinkでのApache Flinkの使用について少しお話しします。Apache Flinkを使用でき、オープンソースと完全な互換性があります。
現在、Amazon Managed Service for Apache Flinkでは、高レベルのSQL言語から、JavaやPythonによる低レベルのストリーミングAPIまで、Apache Flinkがサポートするすべての表現力豊かなAPIを活用できます。具体的なユースケースやチームのスキルに応じて、Amazon Managed Service for Apache Flinkであらゆる言語やAPIを使用することが可能です。また、Apache Flinkのオープンソースコミュニティが開発したすべてのコネクタを使用することもできます。最近、AWSはApache Flinkコミュニティに4つの新しいコネクタを提供しました：Kinesis Data Streams用、DynamoDB Streams用、SQS用、そしてPrometheus用のコネクタです。
Amazon Managed Service for Apache FlinkとApache Flinkを使用すると、遅延イベントの処理や複雑なウィンドウ処理など、高度な時間管理機能を使用してアプリケーションを実装できます。Apache Flinkには、セッションウィンドウ、動的ウィンドウ、タンブリングウィンドウ、カスタムウィンドウなど、さまざまなウィンドウ機能を実装するための多くのオプションが用意されています。もちろん、Apache Flinkのステートフル処理機能やExactly Once処理のセマンティクスも活用できます。
これがFlinkのアプリケーションモデルです。これは各ジョブのオペレーターの論理的な有向非循環グラフのサンプルデータフローです。ここでは、異なるKafkaトピックから読み取ることができる1つのFlinkジョブが示されています。これは単なるサンプルですが、先ほど説明したETL処理を思い出させます。各Flinkジョブは、異なるKafkaトピックからデータを読み取り、データの結合、フィルタリング、エンリッチメント、集計を行うことができます。実際には、機械学習の推論のようなより高度な処理も可能です。変換部分は、データ処理のプロセスを実際に短縮することができます。先ほどMedallionアーキテクチャについて説明しましたが、Flinkを使用することでこれらのステップを簡素化できます。増分処理を行う代わりに、最も洗練されたデータであるGoldを直接作成し、このデータを異なる出力先に書き込むことができます。この例では、S3とOpenSearchというデータ出力先があり、1つのFlinkジョブで異なるタスクを処理できることを示しています。
ステップ3では、データをデータストアに書き込みます。データストアにデータを書き込む理由は、より長期間データを保持し、追加の処理や分析のためにこのデータを利用可能にしたいからです。従来のデータレークアーキテクチャでは、バッチシステムで可変データセットを扱う際、多くの場合、追記専用またはデータの書き換えアプローチに依存していました。つまり、定期的にデータのスナップショットを作成する際、毎回新しいバージョンを作成するか、データセット全体を書き換えていたのです。追記専用モードや書き換えを使用するもう1つの理由は、Hiveやデータウェアハウスなどの従来のデータストレージフォーマットがデータの更新に適していなかったためです。ストリーミングの場合、変更をすぐに反映したい場合に問題となる可能性があります。例えば、ユーザープロファイルをすぐに更新したいレコメンデーションエンジンのようなアプリケーションを考えてみましょう。データをすぐに更新する機能をサポートする必要があります。では、取り込みパターンについて説明しましょう。
ストリーミングシステムにおける追記とアップサートについて考えてみましょう。部屋の温度を測定するIoTデバイスを表すテーブルがあるとします。デバイスIDで分割された、デバイスID、温度、最終更新時間を含むテーブルがあります。左側から単純な追記文（単なるINSERT SQL）でイベントのストリーミングを開始します。右側では、データを更新するアップサートクエリがあります。データがデータベースに存在する場合は見つかった行を更新し、データが存在しない場合は新しい行を挿入します。
この例では、IoTデバイスからイベントの取り込みを開始してみましょう。最初のイベントであるRoom Aが両方のテーブルに挿入され、次に2番目のイベントであるRoom Bを受信します。これは新しいイベントなので、両方のテーブルにこのイベントが追加されます。Room Aについては、これは更新イベントです。Appendモードのテーブルでは新しい行を挿入しますが、Upsertモードでは既存の行を更新するだけです。Room Cは新しいイベントで、新しい行を追加するだけです。最後はRoom Aのもう一つの更新です。ご覧のように、Appendテーブルには温度の詳細な履歴があり、右側のUpsertテーブルには部屋の温度の更新された現在のステータスがあります。
2つのモードの違いを見てみましょう。これは適切な更新戦略を選択する際の参考になります。Appendモードでは、すべてのデータの変更を記録するため、正確な履歴を保持できます。これにより、時間経過による温度トレンドの計算など、新しいビジネスユースケースを実現できます。書き込み手順は新しい行を挿入するだけなので、実際にはとてもシンプルです。ただし、データを読み取って部屋の温度の最新の正確なステータスを取得したい場合は、データを読み取る前にマージ操作のようなものを行う必要があり、読み取りがより複雑になります。
Upsertモードでは、部屋の温度の最新状態を反映し、マージ操作が不要なため、クエリがはるかに簡単です。ただし、履歴は失われてしまいます。データを更新する際に発生する可能性のある別の問題として、同じキーを持つ複数のレコードが存在する可能性があり、これらのレコードをデータベースに更新する際には、最後の更新を処理し、おそらく重複排除を行う必要があります。そのため、書き込み方法がより複雑になります。また、レイテンシーと効率性のジレンマもあります - 各行を更新することで優れたレイテンシーを実現したいものの、パフォーマンスを向上させるには、マイクロバッチングを行って更新前に複数の行をまとめる必要があるかもしれません。
基本的なストリーミングアーキテクチャに戻って、各ステップを可能にするサービスについて続けていきましょう。データストアにデータを書き込むこともできるApache Flinkのマネージドサービスを見てきましたが、もう1つのサービスとして、Amazon Data Firehoseを追加したいと思います。これはサーバーレスのノーコードソリューションで、Snowflake、Apache Iceberg、Redshiftなど、17以上の異なる宛先へのデータ取り込みを可能にします。また、更新操作をサポートしたいので、データレイク用にApache Icebergオープンテーブルフォーマットも追加しました。
ところで、Apache Icebergをご存知の方は何人いらっしゃいますか？手を挙げていただけますか？素晴らしいですね。Apache Icebergは本当に人気が出てきています。Apache Icebergは更新やUpsertをサポートしているだけでなく、スキーマ進化もサポートしているため、ストリーミングとの相性が抜群です。スナップショット分離やタイムトラベルをサポートし、ストリーミングシステムで非常に重要な機能をすべて備えています。Apache Icebergを使用することで、ニアリアルタイムデータの高スループット取り込みを実現し、即座にクエリ可能なデータを提供できます。
Apache Icebergのストリーミングと相性の良いもう1つの特徴は、2つの更新方法を提供していることです。Merge-on-Read戦略とCopy-on-Write戦略を使用してデータを更新できます。Merge-on-Read戦略を使用したデータ更新では、ファイルを書き換えることはありません。データを書き込む際は、新しいファイルを追加するだけです。データを読み取る際には、これらのデータをすべて結合する必要があります。つまり、Merge-on-Read戦略は書き込みに最適化されており、読み取り前により多くの最適化が必要になります。一方、Copy-on-Write戦略は、ほとんどの更新が同じテーブルパーティションに集中しているユースケースで、読み取りパフォーマンスを重視して最適化されています。
しかし、Data Lakeへのストリーミングデータには完璧なものはありません。これは Apache Icebergに限らず、一般的にData Lakeにデータをストリーミングする際の課題です。低レイテンシーを実現するために頻繁に変更をコミットする必要があるため、多くの小さなファイルが生成されてしまいます。これは、コミットの頻度が高いだけでなく、Apache Icebergでは、Merge-on-Read更新戦略を使用して多くのファイルを作成するためです。 多くのファイルを作成すると、読み取りパフォーマンスに影響が出る可能性があり、テーブルのメンテナンスを実行する必要があります。もう1つの注意点として、小さなファイルを大きなファイルにコンパクト化するようなテーブルメンテナンスを実行する際は、ストリーミングジョブを中断させないように実行する必要があります。
ストリーミング中にデータを更新する際の最後の考慮事項は、同じバッチ内で同じキーを持つ複数のイベントがあり、それらをすべて更新したい場合のUpsertモードで議論した問題です。この更新を行う際、データの保存先がIcebergであるか他のデータストアであるかに関係なく、 非決定的な更新が発生する可能性があります。どのイベントを更新に使用すべきでしょうか？そのため、 ソートを行い、最後の更新を取得するという追加のロジックが必要になります。
ストリーミングアーキテクチャの総括と今後の展望
さて、バッチからストリーミングへの移行の3つのステップをすべて説明しました。データの取り込み、処理、保存のストリーミング方式について説明しました。では、これまで説明した サービスをすべて組み合わせたシンプルなアーキテクチャの図を見てみましょう。Amazon RDSやAmazon EKSマイクロサービスなどのデータソースがあり、実行されてストリームストレージにデータをプッシュしています。RDSは実際にCDCイベントを生成し、それらは Debeziumソースコネクタを実行しているMSK Connectによって取得され、システムに送られます。
これらのイベントはAmazon MSKに送られます。マイクロサービスはKafka Produce APIを使用して直接データをプッシュします。次のステップは、Amazon Managed Service for Apache Flinkで、 常時データを処理し、フィルタリングや強化を行い、スマートなロジックを実行してインサイトを生成し、 それらのインサイトを異なる保存先に格納します。先ほど述べたように、Amazon Managed Flinkは既に最も洗練されたデータを生成できるため、ストリーミングアーキテクチャではMedallionアプローチが不要になるかもしれません。もちろん、すべてはユースケース次第です。1つのApache Flinkアプリケーションで、Apache Icebergにデータを書き込むことができます。また、ビジネス分析用のリアルタイムダッシュボードを作成するためにOpenSearchにデータをストリーミングすることもできますし、エンドユーザーに直接イベント通知を送信するというオプションもあります。
では Usama さん、始めましょうか？いくつかの重要なポイントがあります。Sofia、ありがとうございました。このプレゼンテーションを、いくつかの点で締めくくりたいと思います。システムが24時間365日生成しているデータからリアルタイムのインサイトを得て、システム間で同期を取る本質的なニーズがあります。そこでStreamingが役立ちます。また、Streamingは遅延を許容するユースケースにも対応できます。従来型のBIレポーティング用のシステムとリアルタイムや生成AIのためのStreamingシステムという2つの並行システムを維持する必要はなく、両方のユースケースにStreamingを活用できます。
Streamingの成熟度について懸念があるかもしれませんが、Kinesis Data Streamsが登場してから11年の間にAWSが追加してきた機能により、Streamストレージと処理ツールはより成熟し、コスト効率が良く、使いやすくなっています。かつてはこれらのツールはミッションクリティカルなワークロードやTier Zeroサービスには対応できませんでしたが、現在では何百、あるいは何千ものお客様がこれらのミッションクリティカルなワークロードやTier Zeroサービスにこれらを活用しています。十分な性能を備えているだけでなく、年々より成熟し、実戦で検証されたものになっています。
最後に、簡単なCall to Actionをお伝えしたいと思います。ぜひ学び続けてください。これは氷山の一角に過ぎないことは承知しています。素晴らしいセッションをご用意しています。 ここにいくつか紹介していますが、写真を撮っていただいて結構です。他にもたくさんあります。カタログをご覧いただき、Streaming技術についてさらに学べる機会を探してください。この学びをチームに持ち帰り、どこから実装を始められるか検討してください。もしまだ始めていない場合は、小規模から始めることをお勧めします。通常、お客様にはそのようにStreamingを採用することをお勧めしています - 最も重要度の高いものでなくても構いませんので、小規模なユースケースを選んで始め、そこから徐々に拡大していくのです。
カメラを取り出して、これらのQRコードをご覧ください。re:Inventから戻られた後でも実践的に試せるワークショップをご用意しています。ご清聴ありがとうございました。私たちはデータドリブンな企業ですので、アンケートにご協力いただき、セッションやコンテンツについてのご意見をお聞かせいただければ幸いです。皆様からのフィードバックは真摯に受け止め、来年に向けて改善していきたいと考えています。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion