re:Invent 2024: AWSのデータ取り込み戦略 - RedshiftやData Lakeの活用法
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Solving different data ingestion use cases with AWS (ANT330)
この動画では、AWSにおけるデータIngestionの戦略について、様々なユースケースに応じた手法が解説されています。Amazon RedshiftやData Lake、Lake House、Amazon OpenSearchなど主要なターゲットシステムごとに、Zero-ETL統合やAWS Glue、Amazon Kinesis Data Streams、Amazon MSKといった取り込み手法の特徴と活用戦略が詳しく説明されています。特にZero-ETL統合では、Amazon AuroraやDynamoDBからRedshiftへのデータ取り込みが数回のクリックで設定でき、運用負担を大幅に軽減できる点が強調されています。また、ストリーミングデータの取り込みでは、Amazon Kinesis Data StreamsやAmazon MSKのExpress brokerを活用した高スループットな処理の実現方法なども具体的に解説されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
データIngestionの重要性と本セッションの概要
こんにちは。セッションANT330へようこそ。このセッションはサイレントセッションとなっておりますので、セッション中のご質問にはお答えできません。ただし、セッション終了後に10～15分ほど、演台の横で質問をお受けいたします。また、Analytics boothの展示エリアでもお会いできます。
セッションを始める前に、ある状況についてお話しさせてください。家で火事が起きていて、その家の隣に数千ガロンの水を数分で供給できる大きな消火栓があるとします。もし私が信頼できるスパナを持って行って消火栓の蓋を開け、水を流したとしたら、この方法で火を消せるでしょうか？手が挙がらないようですね。その通りです、これでは上手くいきません。では、スパナだけでなく、水を取り込んで火災現場に向けるためのホースを持って行ったら、火を消すことができるでしょうか？皆さん自信を持って反応してくださってありがとうございます。はい、この方法なら効果があるでしょう。なぜなら、水を取り込んで適切な場所に導くことができるからです。
私たちは、様々なデータを持っているにもかかわらず、明確なIngestion戦略がないためにビジネス目標を達成できずに苦労しているお客様で、同じような課題を目にします。そこで本日は、AWSでデータをIngestionする際の様々なユースケースに応じた戦略についてお話しします。まず、自己紹介させていただきます。私はRahul Sonawaneと申します。AtlantaのGeorgiaを拠点とするPrincipal Solutions Architectで、AnalyticsとAIを専門としています。同僚のChinmayi Narasimhadevaraも同席しています。「皆様、こんにちは。Chinmayi Narasimhadevaraと申します。AWSのSenior Solutions Architectとして、主にAnalyticsのユースケースを担当しています。本日はお越しいただき、ありがとうございます。」
はじめに、時代とともに変化してきたデータIngestionの状況について、特にモダンなData Architecture戦略に焦点を当ててお話しします。続いて、ビジネスパートナーや利用者がデータを読み取ることができるTarget Systemに関連したデータIngestionのユースケースについて説明します。最後に、一般的なアーキテクチャと主要な戦略について説明し、効果的なデータIngestionを実現してビジネスデータへのアクセスをできるだけ迅速に行えるようにする方法を解説します。
モダンなデータアーキテクチャとIngestionパターン
これは皆様がすでにご覧になったことがある一般的な図の一つです。この図を見たことがある方、または設計の一部として使用したことがある方は手を挙げていただけますか？ありがとうございます。はい、この図が広く使われているのは、シンプルに機能するからです。スケーラブルなストレージと、すべてのデータとプラットフォームに対する統合されたガバナンスを提供します。本日のセッションでは、重要な柱の一つである「シームレスなデータIngestion」に焦点を当てます。セッション全体を通じて、様々なツールやサービスにおけるIngestion戦略について説明していきます。
Ingestion Strategyについて、特にこの図に関して説明する際、3つのパターンが浮かび上がります。パターン1は、論理的に集中化された場所（Data Lake）からData Warehouseや機械学習アプリケーション、ログ分析などの目的特化型のデータストアにデータが取り込まれるケースで、これをInside-outパターンと呼んでいます。パターン2は、特定分野で働くビジネスパートナーが新しいデータセットを生成し、それを中央の場所と共有するケースで、これがOutside-inパターンとなります。パターン3は重要で、共通のビジネス目標のために互いにコミュニケーションを取りたいユーザーが、場合によってはデータを物理的に他の場所に転送して共有するケースで、これをAround-the-perimeterパターンと呼んでいます。
さまざまなパターンを見ていく中で、リレーショナルデータベースやData Lakeなど、多くの異なるユニットやソースシステムを扱う際に生じる課題について検討してみましょう。これらの異種システムの組み合わせは、コンシューマーが特定の方法やフォーマットでデータを期待する場合に課題となることがあります。これには時としてETLジョブの作成が必要となり、それによってダウンストリームアプリケーションがデータを利用できるようになるまでのプロセスが遅くなってしまいます。その副作用として、ダウンストリームアプリケーションの分析までの時間が遅延することになります。
副作用の一つとして、ビジネスパートナーが特定のビジネスニーズを満たすために独自のデータセットを作成し始める可能性があります。これの欠点は、データサイロが作られてしまうことで、最終的には信頼できる単一のデータバージョンを持てないという課題に直面することです。これを克服するために、私たちはいくつかの重要な戦略を考え、それらをアーキテクチャに適用して柔軟でコスト効率の良いものにする方法を検討しています。
私たちのIngestionパターンをいくつかの重要な特性に分類してみましょう。 最初の特性はソースに基づくものです。異種システムにおける様々なソース、特にリレーショナルデータベースを見ると、主に構造化データを含んでいます。リレーショナルデータベースから来るデータは主に定められた構造を持つテーブル行形式である一方、ファイルから来るデータは半構造化または非構造化かもしれません。SaaSアプリケーションやリアルタイムデータを送信するIoTデバイスについて話す場合、その構造は可変で、構造化、半構造化、非構造化のいずれかになる可能性があります。
お気づきの通り、私は構造について話していますが、同時にデータタイプという別のカテゴリーに移行しています。ここで、構造化データやJSONファイル形式のような半構造化データが重要になってきます。最近の進展を見ると、非構造化データも重要な洞察を得るためにビジネスが活用すべき重要な要素となっています。データが到着するタイミングに基づいて、プッシュモデルやプルモデルに基づいて特定の時間に実行されるジョブによるバッチプロセスやマイクロバッチとして分類されます。リアルタイムデータを送信できるデバイスや、ニアリアルタイムデータを送信するWebアプリケーションは、ストリーミングアプリケーションに分類されます。
Amazon Redshiftを活用したデータウェアハウスへのIngestion戦略
最初にご紹介するシステムは、Data Warehouseへのデータ取り込みについてです。これは非常に古くからある概念です。私が25年前にキャリアをスタートした時、最初の仕事がData Warehouseに関するものでした。Data Warehouseを使用している方、使用したことがある方、これから使用を検討している方は手を挙げていただけますか？ありがとうございます。Data Warehouseを簡単に説明すると、ビジネスアナリストが傾向分析や履歴分析を行えるように、過去のデータを保存できる高効率なデータハブと言えます。最近では、決まったレポートや分析だけでなく、アドホック分析も求められるようになってきています。そこで登場するのが、ストレージとコンピューティングを独立してスケールできる、フルマネージド型のAIパワードクラウドウェアハウスであるAmazon Redshiftです。
では、Amazon Redshiftをターゲットシステムとして使用する場合に、どのような取り込みパターンがあるのか見ていきましょう。詳しく説明する前に、これから何度か出てくるZero-ETLという概念についてご紹介します。 Zero-ETLは、ポイントツーポイントのデータ移動のために設計されており、ユーザーがETLパイプラインを作成する必要がありません。Zero-ETL以前は、ソースからデータを抽出し、ターゲットシステムにロードするパイプラインを作成し、バッチやトリガーに基づいて全体のジョブをオーケストレーションする必要がありました。 しかし、Zero-ETLでは、ソースとターゲットを設定し、転送したいオブジェクトを選択するだけでよくなりました。AWSが効率的なリソースとコストを活用してデータを効果的に転送します。必要に応じて自動的にスケールアップ・ダウンするため、データは素早くターゲットシステムで利用可能になります。同時に、この場合はData Warehouseで統合されたデータを提供し、ユーザーが複数のシステムにまたがる分析を行い、インサイトを得られるようサポートします。
それでは、Amazon RedshiftへのデータロードにZero-ETLをどのように活用できるか、さらに詳しく見ていきましょう。 私たちは昨年からZero-ETLの取り組みを開始しました。最初は、Amazon Aurora MySQLをソースとしてRedshiftにデータをロードする機能を導入しました。その時点では、スキーマまたはデータベース全体でデータを転送するオプションを提供していました。現在では、includeとexcludeオプションを使用して、転送したい特定のテーブルを定義できるように改良しています。
お客様は特に、OLTPシステムとData Warehouseをニアリアルタイムで統合する際に、この機能を高く評価してくださいました。OLTPシステムに追加の負荷をかけることなく、ニアリアルタイムでデータを転送できることが、重要な役割を果たしています。お客様からさらなるサービス統合の要望があり、私たちはAmazon Aurora PostgreSQL、Amazon RDS for MySQL、そして最近ではAmazon DynamoDBとの統合も実現しました。これらはすべて、Zero-ETLを使用してRedshiftと統合できるサービスです。Data Warehouseについて考える時、AWSサービスだけでなく、多くのアプリケーションからもデータが送信されることを理解しています。そこで、SalesforceやZendesk などのサードパーティアプリケーションと統合できるようにZero-ETLを拡張しました。ユーザーは、Zero-ETLの同じ機能を使用して、サードパーティアプリケーションと様々なデータソースからのファーストパーティアプリケーションのデータを統合し、Redshiftで組み合わせることができます。データがRedshiftに取り込まれると、SQLを使用してデータを操作したり、インサイトを見つけたりすることができます。
では、別のアプローチに移りましょう。 オンライントランザクションシステムやPOSシステムがWarehouseアプリケーションにリアルタイムデータを送信でき、ビジネスパートナーがリアルタイムデータとWarehouseデータを組み合わせたアプローチを求めているケースを想像してください。このニアリアルタイムのData Warehouseシナリオでは、Amazon Kinesis Data StreamsやApache Kafka（ここではAmazon MSKとして表現）などのストリーミングアプリケーションからのデータを直接Redshiftに取り込むオプションがあります。Redshiftには、ストリーミングアプリケーションから直接データを取り込む機能があります。この例では、POSターミナルが継続的にストリーミングを通じて送信するデータを、直接Warehouseに取り込むことができます。Warehouseに取り込まれると、それはマテリアライズドビューのように動作し、データの所有権はWarehouseに移ります。ユーザーは既存のデータとこのストリーミングデータを組み合わせて分析することができます。これは、ニアリアルタイムのData Warehouseと既存の履歴データの結合に関する要件がある場合に非常に有効なパターンです。
それでは、他のパターンを見ていきましょう。 ニアリアルタイムや設定可能なオプションについてお話ししてきましたが、ベンダーがAmazon S3にファイルを送信するシナリオや、ETLジョブがデータを処理してS3にファイルを配置するシナリオがあることも理解しています。この機能が導入される前は、ユーザーはRedshiftでCopyコマンドを記述し、ファイルからRedshiftテーブルにデータをコピーするためのオーケストレーションを行う必要がありました。Auto-copy機能を使用すれば、もはやジョブのオーケストレーションを心配する必要はありません。最初にCopyコマンドを設定するだけで、それ以降はRedshiftが自動的にファイルからテーブルへのデータ転送を担当します。ファイルが到着すると、内部的にファイルの到着を認識し、対応するマニフェストファイルを作成して、データを効率的にRedshiftウェアハウスに転送します。
これは重要な側面のもう一つです。 ストリーミングデータ、ニアリアルタイムデータ、バッチデータを一緒にアクセスできるのです。これらのパターンについて説明してきましたが、他にも適用できるパターンがあることを理解しています。例えば、オンプレミスのデータベースからデータを取得してウェアハウスにロードする必要がある場合、AWS DMSがリレーショナルデータベースなどのソースシステムからデータを読み取り、Redshiftに転送する能力を発揮します。さらに、データのクレンジング、処理、または複数のデータセットの結合が必要なケースもあるでしょう。
このような場合、AWS GlueやInformatica、DBTなどのサードパーティサービスが取り込みパターンとして機能するETL関連のパターンが登場します。これらを組み合わせることで、できるだけ早くデータをウェアハウスに取り込み、ビジネスユーザーが分析を行い、インサイトを見つけるための一元化された単一の真実を提供することができます。
Data LakeとLake Houseにおけるデータ取り込みの手法
ここで話題を変えて、Data Lakeについて説明したいと思います。 始める前に、Data Lakeをご存知の方、あるいは何らかの形でData Lakeを使用している方は手を挙げていただけますか？ほぼ全員ですね。ありがとうございます。Data Lakeが非常に人気があるのは、データの保存と調整に関して、スケーラブルなストレージと対応するカタログ化の柔軟性を提供するからです。同時に、消費者が自分の好みのコンピュートを持ち込んでデータとやり取りする柔軟性も提供します。消費者について話し始めると、それぞれのニーズがあります。効果的に活用するために、列指向のParquetファイルが必要な場合もあれば、AvroファイルやCSVファイルが必要な場合もあり、データ実行をより効果的にするための効率的なパーティショニングメカニズムも必要です。
Data Lakeについて話すとき、SQL、NoSQLデータベース、リアルタイムデータ、サードパーティデータ、APIデータなど、さまざまな分野から異種のソースシステムが集まってきます。頻度に基づいて、2つの異なるカテゴリに分類できます。1つ目は、1日1回、週1回、1日2回、あるいはマイクロバッチの場合は15分ごとなど、一定の間隔でデータが到着するバッチレイヤーです。もう1つのカテゴリは、ソースがリアルタイムデータを送信し、できるだけ早くData Lakeに到着させる必要があるストリーミング取り込みです。
データレイクにデータが格納されると、ユーザーは自由に好みの計算リソースを選択できるようになります。ユーザーには、Amazon SageMakerやBedrock を使用した分析を行いたいML関係者もいれば、Trinoエンジンを使用するAmazon Athenaのようなクエリツールを使用したい人、あるいはデータを視覚的に表現するためにAmazon QuickSightを使用したい人もいるでしょう。
ここで、AWS Glueがデータ取り込みに関して提供する機能について簡単にご説明します。AWS Glueは、広い意味でサーバーレスのデータ取り込み、ディスカバリー、データ準備のためのサービスです。また、データ品質ルールの実装やデータカタログの作成機能も備えています。今回のセッションでは、これらすべてを説明すると1時間近くかかってしまうため、Glueの機能をすべて説明することは控え、データ取り込みのパターンに焦点を絞ってお話しします。異種の複数システムからのデータ取り込みに関して、AWS Glueは様々なデータベースやストリーミングアプリケーションに接続できる多様なコネクターを提供しています。70以上の異なるコネクターを標準で提供しています。
ソースシステムに関しては、私たちがコネクターを用意していないシステムも多数あることを理解しています。そこで、ユーザーの皆様には、マーケットプレイスから独自のコネクターを導入していただくか、カスタムコネクターを利用していただく柔軟性を提供しています。素晴らしい点は、これらのカスタムコネクターを使用する際、AWS Glueが追加コストなしで実行時に自動的にそれらを組み込むことです。マーケットプレイスからコネクターを入手する場合、ベンダー側のコストが発生する可能性はありますが、AWS Glue側では追加コストは発生しません。
ここで、データベースから一定の時間間隔でデータを取得し、Parquet形式でデータレイクに格納する必要があるユースケースを考えてみましょう。このような場合、コネクターライブラリの一部として提供されているJDBCコネクションを利用できます。MySQLやその他のデータベースからデータを取得することができます。同時に、AWS Glueはリアルタイムでのデータ取り込み機能も備えており、Amazon MSKやAmazon Kinesisに接続するコネクターも提供しています。これらのジョブは継続的に実行され、私たちはこれを継続実行ジョブと呼んでいます。このジョブでは、ハードウェア要件を自由に定義でき、両タイプのジョブともデータフローに基づいてスケールアップ・ダウンが可能です。
続くスライドでいくつかの戦略についてより詳しく説明していきますが、ここでは継続実行ジョブによるニアリアルタイムでのデータ取り込み機能と、バッチモードでの特定の時間間隔でのデータ読み取りとデータレークへの取り込み機能があることを強調しておきたいと思います。
次のサービスについてお話しします。クリックストリームデータを含むマーケティングキャンペーンがあり、そのデータを可能な限り早くターゲットシステムに取り込む必要がある場合を想像してください。そのような場合に活躍するのが、フルマネージド型で大規模なスケーラビリティを持ち、データニーズに応じてスケールできるAmazon Kinesis Data Streamsです。プロビジョンドとサーバーレス、両方の容量オプションを提供しています。プロビジョンドオプションでは、レコードの取り込みとIOPS容量の両方のスループットに直接関連するシャードの数を定義できます。私のお客様の一社は、シャードを使用して毎秒2GBのデータを転送しています。シャードの計算が面倒な場合は、データニーズに応じて私たちがシャードの追加と削除を担当するオンデマンド容量を使用することもできます。
次のサービスも同様の機能を持ち、Apache Kafkaに関連しています。Kafkaは非常に有名な別のオープンソースアプリケーションです。Kafkaの経験がある方は手を挙げていただけますか？予想通り、多くの方がいらっしゃいますね。Kafkaをご存知の方なら、ハードウェアの管理、高可用性の確保、災害復旧の対応、レイテンシーのない継続的なレスポンスの維持が主な課題だとご理解いただけると思います。そこで私たちはAmazon MSKを導入し、ハードウェアの保守を完全に代行します。このフルマネージド型サービスは、高可用性と耐久性を確保します。Amazon MSKもプロビジョンド容量とサーバーレスの2つのオプションを提供しており、リアルタイムのデータ取り込み要件を満たしながら、従量課金モデルを使用できます。
ここで少し話題を変えましょう。ここまでリアルタイムデータの取り込みについて話してきましたが、フォーマットについては触れていませんでした。先ほどData Lakeについて話した際、ParquetフォーマットやCSVフォーマットで高度なパーティション分割が必要だと言及しました。そこで活躍するのがAmazon Firehoseサービスです。FirehoseはMSKを含む複数のソースシステムからデータを取り込み、特定のフォーマットで複数のターゲットシステムにデータを送信するオプションを持っています。動的パーティションの作成が可能で、S3にデータを送信する際に1時間単位でパーティションを作成するオプションがあります。これは、セキュリティログを取り込んだり、複数のシステムから1時間ごとに情報を収集したりする必要のある多くのお客様にとって非常に便利です。パーティション分割されたデータを作成すると、迅速な分析のために複数のコンピューティングサービスと統合できます。
ここで一旦立ち止まって、ビジネスの観点から見てみましょう。WarehouseとData Lakeについて話してきましたが、ビジネスサイドの方々は、これらの技術的な区別をそれほど気にしていません。彼らの主な関心事は、データがカラムナーWarehouseのテーブルから来ているのか、ファイルシステムのParquetファイルやパーティションから来ているのかを気にすることなく、クエリを実行できる統一された中央データストアを持つことです。彼らの主な目的は、クエリを実行できる一元化された場所を持つことです。
そこで私たちは、Data WarehouseとData Lakeの間のギャップを埋めるLake Houseアプローチを導入し始めました。基調講演でもお聞きになったと思いますが、私たちはAmazon SageMaker Lake Houseを導入しました。これは、Data Warehouse、Data Lake、運用データソース、さまざまなアプリケーション、そしてエンドユーザー間でデータを統合できる機能を持っています。データがData WarehouseとData Lakeのどちらから来ているかを気にする必要はありませんが、今回の主な話題は取り込みパターンに関連しています。
SageMaker Lake Houseへのデータ取り込みについてお話ししましょう。 先ほどAmazon Redshiftとのゼロ-ETL統合についてお話ししましたが、SageMaker Lake Houseでも同様のアプローチが可能です。Amazon DynamoDB、SQL、MySQL、Amazon Aurora、Amazon RDSといったファーストパーティのソースからデータを取得できます。同時に、Salesforce、SAP、ServiceNowなどのアプリケーションとの統合も可能です。ゼロ-ETLではほぼリアルタイムでデータを転送できますが、利用するソースによって、Amazon SageMaker Lake Houseという中央集中型の場所にデータを転送する際の遅延を考慮する必要があります。
特定のAWSサービスやゼロ-ETLについて説明しましたが、ユーザーの皆様は必ずしもゼロ-ETLを直接使用したいとは限らないことも理解しています。 独自のアプリケーションやデータ取り込みのアプローチをお持ちかもしれません。そこで、Apache IcebergのオープンAPIを通じてSageMaker Lake Houseへのアクセスを提供しています。現在利用可能なAmazon SageMaker Unified Studioを使用してSageMaker Lake Houseと連携する方法が一つの選択肢です。Studio内で利用可能なコネクタを使用してLake Houseにデータを取り込むことができます。Jupyterノートブックを使用したジョブの作成や、AWS Glue上でアプリケーションを実行するなど、独自のカスタムアプリケーションをお持ちの場合でもサポートしています。特に最近発表されたGlue 5.0では、SageMaker Lake Houseとの直接統合が可能で、AWS Glueサービスを使用してデータを取り込むことができます。また、Apache IcebergのオープンAPIと連携可能なサードパーティツールをお使いの場合も、それらを使用してLake House形式でデータを取り込むことができます。
Lake Houseと、すべてのデータを中央に集約することについてお話ししました。 多くのシステムや企業が既に様々なオープンテーブルフォーマットの採用を始めていることも理解しています。オープンテーブルフォーマットを既に使用している方、検討中の方、あるいは実験的に使用したことがある方は手を挙げていただけますか？ありがとうございます。オープンテーブルフォーマットが人気なのは、Amazon S3上でACIDトランザクションを実行できる柔軟性があるためです。Lake HouseとApache Icebergについて特に言及しましたが、モダンなデータレイクとしてApache Hudi、Apache Iceberg、Delta Lakeフォーマットもサポートしています。特にAWS GlueやAmazon EMRといった先ほど説明したツールは、これらのオープンテーブルフォーマットに対してデータの取り込みと処理を効果的に行うことができます。
Amazon OpenSearch Serviceを用いたログと分析データの取り込み
次に、ログと分析サービスへのデータ取り込みについてお話ししましょう。AWSでは、Amazon OpenSearch Serviceが検索・分析エンジンとして提供されています。Amazon OpenSearchはスケーラブルで安全なサービスで、分析と検索の両方のユースケースに使用できます。分析の観点では、アプリケーションのトラブルシューティング、アプリケーションパフォーマンスの追跡、システムの可観測性に関する問題の可視化などが可能なログとセキュリティ分析のユースケースをサポートしています。検索のユースケースでは、クエリの意図を理解して結果を返すテキストベースの検索をサポートしています。また、特に最近注目を集めているAIユースケースに対応するため、クエリの意味を理解できるセマンティック検索やベクトル検索もサポートしています。さらに、Amazon OpenSearch Serviceには多数のゼロ-ETL統合機能があります。
まずはそれらについて説明していきましょう。Amazon DynamoDBのゼロ-ETL統合について、 その仕組みを説明する前に、顧客事例を通じてその必要性について理解しましょう。DynamoDBに大量のデータを持つお客様がいます。これは顧客からのフィードバックである可能性があり、このデータを分析して高度な検索を行い、より多くのフィードバックを得てビジネスを改善したいと考えていました。
これらの検索に対する論理的な選択は OpenSearch Service に移行することでしたが、DynamoDB からデータを OpenSearch に取り込むのは簡単ではありませんでした。まず DynamoDB streams を有効にする必要がありました。これは DynamoDB のテーブルで発生するあらゆる変更、更新、削除、挿入を追跡し、下流で利用可能なストリームにデータを移動させる機能です。次に、DynamoDB 形式から OpenSearch が期待する JSON 形式に変換するためのカスタムワークフローと Lambda 関数を作成する必要がありました。DynamoDB との zero-ETL 統合を導入することで、このような面倒な作業をすべて解消しました。この統合により、コードを書くことなく、DynamoDB のデータをほぼリアルタイムで確認できます。これは Amazon OpenSearch Ingestion をベースにしており、パイプラインが設定に基づいてデータのルーティング、変換、集約を行い、DynamoDB から OpenSearch にデータを移動させ、両システムを同期した状態に保ちます。
DynamoDB に加えて、AWS のもう一つのネイティブ JSON データベースである Amazon DocumentDB もサポートしています。DocumentDB でも同様の zero-ETL 統合を使用して、OpenSearch とシステムを同期させることができます。話題を変えて、Amazon S3 のデータについて見ていきましょう。 DynamoDB と DocumentDB では、データを OpenSearch にコピーしていましたが、この統合については、お客様のユースケースをお話ししましょう。通信事業者のお客様の大半は、テラバイト規模のデータを生成していますが、経済的な理由から、そのすべてを OpenSearch に取り込むことはできません。通常は直近24時間分のデータのみを取り込んで OpenSearch で分析を行いますが、それ以外にも価値のあるデータが大量に存在します。
そのため、ツールを切り替えるか、分析のためにデータの一部を OpenSearch に取り込む必要がありました。このようなお客様をサポートするため、直接クエリ統合を導入しました。これにより、データを OpenSearch に移動することなく、OpenSearch から直接データにクエリを実行できるようになりました。データは S3 に置いたままです。S3 に加えて、この re:Invent の直前に、AWS のすべてのログの中心である Amazon CloudWatch Logs や、 セキュリティデータを集約できる Amazon Security Lake との統合も発表しました。ここでの最終目標は、データを OpenSearch に取り込むことなく、このような大容量で価値の高いデータから直接価値を引き出せるようにすることです。
具体的な仕組みを見てみましょう。まず、これらの統合のいずれかを使用して OpenSearch Service にデータソースを作成し、OpenSearch のUIインターフェースであるダッシュボードを使用します。これにより、データが置かれている場所から OpenSearch を通じて直接クエリを実行できます。 OpenSearch で SQL または PPL（Pipeline Processing Language）を使用して、異なるテーブル間のデータを取得できます。OpenSearch 内のデータと組み合わせることも、そのデータを独立してクエリすることも可能です。Security Lake については、すでにいくつかの事前構築されたクエリやダッシュボードが用意されており、それをベースに要件に応じてカスタマイズできます。
また、非常に低レイテンシーが必要なクエリがある場合や、OpenSearch からデータにアクセスしたい場合のために、このデータを OpenSearch に取り込むこともできます。クエリの最終結果だけを OpenSearch に取り込むことで、より良いレイテンシーとデータ体験を得ることができます。複雑な集計を含むマテリアライズドビューを構築することも可能です。テラバイト規模のデータをすべて取り込む代わりに、数キロバイト程度の結果だけを取り込むことで、ダッシュボードを活用したり、アラートを設定したり、OpenSearch のすべての価値を活用することができます。
OpenSearchのデータ取り込みについてまとめますと、OpenSearchはゼロETL 連携だけでなく、他の多くのソースもサポートしています。Amazon S3、HTTP、そしてOpenTelemetryのソースに対応しており、MSKやKinesis Data Streamsなどのストリーミングサービスからもデータを取り込むことができます。
Amazon OpenSearch Ingestionは、OpenSearchにデータを取り込むための推奨される方法です。データの収集、変換、バッファリング、適切なOpenSearchインデックスへのルーティングを行うことができるためです。シンプルなものから複雑なものまで、多くのカスタム変換に対応しています。タイムスタンプ形式の標準化といった基本的な変換から、生成AIのユースケースで使用するためにテキストデータをベクトル埋め込みとして取り込むプロセッサーまで提供しています。完全にサーバーレスでスケーラブルなサービスなので、トラフィックや要件に応じたスケールアップ・ダウンを心配する必要がありません。
小売業を例にしたデータIngestionのリファレンスアーキテクチャ
これで取り込みサービスの説明は以上です。 次に、これまで説明してきた取り込みサービスを使用して、異なるターゲットシステム向けのリファレンスアーキテクチャを構築していきましょう。このアーキテクチャをより具体的に構築していく際には、シンプルさと高効率性を指針としていきます。 ここでは、小売業のユースケースでよく見られるデータセットをいくつか取り上げています。このアーキテクチャでは、Amazon AuroraとAmazon DynamoDBに格納される商品データ、サプライヤーデータ、顧客データ、注文データがあります。Kinesis Data Streamsに流れ込むクリックストリームデータ、この小売業者が使用しているSAPやSalesforceなどのSaaSアプリケーションもあります。さまざまなソースから異なるS3バケットに入ってくる構造化、非構造化、半構造化データファイルも多数あります。そして最後に、この小売業者が運用しているすべてのアプリケーションから生成されるログデータがあります。これまで説明してきた4つのターゲットシステム、つまりAmazon Redshift、データレイクS3、データLakehouse、そしてOpenSearchに引き続き焦点を当てていきます。
まず、Auroraからのデータ取り込みについて説明します。商品データやサプライヤーデータなど、さまざまなAuroraデータベースにデータがあります。顧客は意思決定のために、これらのデータをすべてRedshiftに統合して、異なるビジネスユニット全体を包括的に把握したいと考えています。ゼロETL連携が登場する前は、AuroraからRedshiftにデータを取り込むために多くのカスタムパイプラインを実行し、カスタムコードを保守する必要があり、これは大きな運用負担でした。現在は、ゼロETL連携により、パイプラインやコードの保守を心配する必要がありません。数回クリックするだけで連携を設定でき、AuroraからRedshiftへのデータレプリケーションは連携機能が処理してくれます。これにより、運用面で大きなメリットが得られ、SLAを数秒単位まで短縮することができました。
ここで重要な戦略をいくつか見ていきましょう。まず第一に、追加しているすべてのゼロETL連携を把握しておくことです。ゼロETL連携サービスが利用可能な場合、それがニーズに合致するかもしれません。その場合は運用の負担を抱える必要はありませんので、そのサービスを活用しましょう。私たちはお客様からのフィードバックに基づいて、新しい連携機能を継続的に追加しています。次に、レプリケーションの頻度をコントロールすることです。ビジネス要件に基づいてレイテンシーを調整できるよう、更新間隔を制御することができます。パイプラインを常時実行し続ける必要はなく、それによってアップストリームやダウンストリームのシステムに負担をかけることを避けられます。
次に、Auto-copyについてお話ししましょう。この小売業者は、販売ログトランザクションやトランザクションログから大量のデータを取得しており、それらは異なる時間間隔で異なるS3バケットに保存されています。S3 Auto-copy機能が登場する以前は、データをRedshiftに取り込むために、カスタムワークフローを作成し、それらのジョブを維持管理する必要がありました。そうしたパイプラインすべての保守が必要だったのです。しかし現在は、継続的インテグレーションや継続的Auto-copyが利用可能になったことで、データチームはインテグレーションについて心配する必要がなくなりました。一度設定するだけで、システムが自動的にデータをAmazon Redshiftにコピーしてくれるようになったのです。
次に、バッチインジェストについて説明しましょう。これは、これまでに見てきた中で最も一般的なタイプと言えるでしょう。POSシステムやWebアプリケーションの販売など、複数のデータソースからデータが入ってきます。これは、下流での利用のためにデータレイクに取り込む前に、変換とデータ品質チェックが必要な大量のデータです。AWS Glueがここで最も人気のある選択肢として見られており、これらの要件を満たすためにAWS Glueを使用することができます。具体的なユースケースに応じて、Amazon EMRやDMSなどの他のサービスを使用することも可能ですし、これらすべてを組み合わせて使用することも効果的かもしれません。
AWS Glueの主要な戦略について見ていきましょう。 AWS Glueでジョブから最高のパフォーマンスを引き出すために、さまざまなワーカータイプが用意されています。標準ワーカータイプでも、G1とG2という異なるバージョンがあり、それぞれが異なるvCPUとメモリを提供しています。ジョブのパフォーマンス要件に基づいて適切なインスタンスを選択し、Auto Scalingを有効にしましょう。ワークロードが変動する場合、要件に応じて自動的にスケールアップ・ダウンし、ジョブから最高のパフォーマンスを引き出すことができます。また、AWS Glueの余剰キャパシティを活用するFlexタイプと呼ばれるものもあります。時間に余裕のあるバッチ処理データの場合は、このFlexタイプのワーカーを使用することで、SLAを満たしながらより低コストで実行できます。
常に最新バージョンのAWS Glueを使用することをお勧めしています。というのも、前バージョンに比べて常にパフォーマンスが改善されているからです。最新バージョンを使用することで、オープンソースのApache Sparkと比べて、すぐに使えるパフォーマンス向上のメリットが得られます。AWS Glueは数多くのジョブメトリクスを提供し、ジョブのリアルタイムモニタリングのためのSpark UIへのアクセスも可能です。最近では、AWS GlueにおけるSparkエラーの根本原因分析のための生成AIによるSparkデバッグ機能を追加し、ジョブパフォーマンスを改善するための洞察と推奨事項を提供しています。これらの機能をぜひすべて活用してください。
次は、ストリーミング分析についてお話ししましょう。Amazon Kinesis Data Streamsには大量のストリームデータが流れ込んでいます。ストリーミングには、ストリームストレージへの取り込みと、そのストレージからの消費という2つの部分があります。ストリームストレージからのデータ消費に関して、Amazon Kinesis Data Streamsにデータが入ると、それをデータレイクや他のダウンストリームシステムに取り込むための方法が複数用意されています。複雑なイベント処理のビジネスロジックを実行する必要がある場合は、Amazon Managed Service for Apache Flinkを使用して、Flinkでデータを処理し、別のストリームやAmazon Timestreamやデータレイクなどのダウンストリームシステムに送ることができます。コードのメンテナンスのオーバーヘッドを避けたい場合や、単にストリームからデータレイクへのデータ転送だけを行いたい場合は、Amazon Kinesis Data Firehoseを使用できます。
この観点についても、いくつかの重要な戦略についてお話ししましょう。まず、Amazon Kinesis Data Streams は、使用および取得するデータ量に基づいて課金されます。ストリームにデータを投入する際には、データの集約と圧縮を行うことをお勧めします。Kinesis Producer Libraryには、データの集約、圧縮、バッチ処理を支援し、リトライメカニズムを内蔵したAPIが用意されています。同様に、コンシューマー側でも、データの集約解除と読み取り、問題が発生した場合のリトライが可能です。複数のコンシューマーがいる場合、Amazon Kinesis Data Streamsでは拡張ファンアウトを有効にすることで、各コンシューマーに対して毎秒2MBのスループットを確保できます。ほとんどのお客様は、最初はオンデマンドモードで始め、要件を満たさない場合はスケールアップとダウンを行います。それでも要件を満たさない場合は、プロビジョンドモードに移行します。
次に、Amazon MSKについてお話しします。このApache Kafkaクラスターは、すべてのブローカーで構成されています。ここには異なる種類のブローカーがあります。特定のCPUとストレージ構成を持つスタンダードブローカーがあり、さらに最近リリースされたExpressブローカーもあります。
Expressブローカーは、高スループットの要件に対応してスケールします。Expressブローカーはスケーラブルなスループットを提供し、障害からの復旧も速いため、ぜひ活用してください。要件に基づいて、ニーズに合った適切なブローカーを選択してください。システムをセットアップしたら、Amazon MSKが提供するCloudWatchメトリクスを監視してCPU使用率をチェックすることが重要です。特に分散システムでは多くのプロセスが実行されているため、他の運用タスクのための容量を確保できるよう、CPUを60%程度に保つことをお勧めします。また、監視可能なストレージメトリクスも提供しています。Expressブローカーを使用していない場合は、クラスターの容量が満杯になるとストレージが自動的にスケールアップする自動スケーリング機能を利用できます。
Amazon Managed Service for Apache Flinkに移りましょう。これは完全マネージド型のサービスで、Java、Scala、Python、またはSQLを使用してデータの処理と分析を行うことができます。継続的な処理やインタラクティブな分析など、さまざまな種類のジョブを実行できます。完全マネージド型サービスではありますが、Flinkアプリケーションから最高のパフォーマンスを引き出すためにはいくつかの運用上の考慮事項があります。アプリケーションの障害が発生した場合に特定の時点から復旧できるよう、チェックポイントとスナップショットを有効にしてフォールトトレランスを実装することをお勧めします。また、Flinkにはスループットを決定するParallelismというパラメータがあり、これを制御することができます。ジョブの要件に応じて、ジョブレベルまたは負荷の高い操作に対してオペレーターレベルでParallelismを設定できます。コストを最適化するために、これを適切に使用するようにしてください。
Flinkには多数のConnectorが付属しており、Flinkのバージョンごとにサポートされる新しいバージョンのConnectorがあります。 データの不整合やランタイムの問題を避けるため、使用しているFlinkのバージョンに適した依存関係を必ず使用するようにしましょう。Amazon Kinesis Data Firehoseは、フルマネージドサービスとして、データをバッチ処理やバッファリングするための機能を提供し、下流のシステムにデータを送信する前に一定時間や特定のサイズまで待機することができます。また、エラーレコードを後で処理や調査ができるよう、別の場所に振り分けるエラー処理戦略を実装することもできます。
次に、今回のre:Inventで発表されたばかりのAmazon Zero-ETL統合についてお話しします。あるお客様は、SalesforceのチャットデータをLakehouseに取り込みたいと考えていました。このZero-ETL統合を使用することで、基盤となるConnectorやAPIを気にすることなくデータを取得できるようになりました。私たちがすべてを管理し、スループット要件に応じて調整やスケーリングを行います。以前は、カスタムETLパイプラインを作成してConnectorを特定する必要がありましたが、現在はそのオーバーヘッドが解消されています。
OpenSearch Ingestionについては、ある小売業のお客様が、様々なWebサーバーやアプリケーションから生成される大量のログを収集し、分析のためにAmazon OpenSearch Serviceに取り込んでいます。OpenSearch Ingestion以前は、EC2インスタンス上でこれらの取り込みパイプラインを実行する必要があり、インスタンスの管理だけでなく、コードの制御、パッチ適用、スケーリング、パイプラインの監視も行わなければなりませんでした。OpenSearch Ingestionにより、そのような保守や運用のオーバーヘッドがなくなりました。要件に基づいて変換を使用してインジェクションパイプラインを設定するだけで、OpenSearchが必要に応じてスケーリングを行います。
OpenSearch Ingestionの主要な戦略として、VPCベースのサービスであるため、高可用性を確保するために複数のAvailability Zoneにまたがって配置することが重要です。Availability Zoneが停止した場合でも、OpenSearchパイプラインが失われることはありません。エラー処理のためにDead Letter Queueを設定することで、すべてのエラーレコードをそのQueueに送信することができます。
これらのエラーレコードはDead Letter Queueに送信され、後でデバッグに使用できます。Amazon OpenSearch Serviceは、入力データのデータ型をOpenSearchインデックスに動的にマッピングすることができます。ただし、検索に特定の要件がある場合は、最適な効果を得て検索を最適化するために、それらのデータ項目を自分でマッピングする必要があります。また、S3ファイルの内容をすべてOpenSearchに送信する必要はなく、必要なフィールドのみを送信するオプションもあります。OpenSearchに送信する前に、S3データに対して任意の選択的フィルタリングを行うことができます。
まとめと今後の学習リソース
以上で、様々なデータ取り込み手法を検討してきたデータ取り込みアーキテクチャの説明を終わります。マネージドサービスとZero-ETL統合を活用したアーキテクチャにより、大規模なデータ取り込みを効率的に実現できます。振り返りますと、Data Warehouse、Data Lake、Lakehouse、そしてログと検索分析エンジンへのデータ取り込みについて説明しました。また、これらの取り込みサービスを活用して、信頼性が高く、堅牢で、コスト効率の良いシステムを設計するための重要な戦略についても説明しました。
最後に、より詳しく学べるリンクをご紹介します。これらの様々な取り込みサービスとその主要な戦略を活用して、自動化され、スケーラブルで、数多くのZero-ETL統合パイプラインを備えたシステムを構築していただければと思います。本セッションにご参加いただき、お時間を割いていただき、ありがとうございました。セッションのアンケートにもぜひご協力ください。また、本セッションについて質問がございましたら、お気軽にお声がけください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion