re:Invent 2024: AWSのサーバーレス分析で高性能データソリューションを構築
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Build highly performant data solutions with serverless analytics (ANT335)
この動画では、データシステムのパフォーマンスを考慮した設計について、Performance Pentagonという5つの要素(Latency、Scalability、Efficiency、Reliability、Cost)のバランスを取るフレームワークが紹介されます。高い同時実行性を持つワークロードやリアルタイムインテリジェンスなど、実際のユースケースに基づいて、Amazon RedshiftやAthena、QuickSightなどのServerlessサービスを活用したソリューションパターンが解説されます。特にWorkhumanの事例では、QuickSightを活用して数千人規模のユーザーにレポーティングソリューションを提供した実装方法が詳しく共有されており、Data APIサービスやNamespaceを活用したマルチテナント対応の具体的な手法を学ぶことができます。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
パフォーマンスを考慮したデータシステム設計の重要性
パフォーマンスは単なる技術的な詳細ではありません。ビジネスが先手を打って行動できるか、後手に回るかの違いなのです。大規模セールスの日にアプリケーションがスケールアップできずに販売機会を逃してしまうことや、不正取引を事前ではなく事後に検知してしまうことを想像してみてください。そのため、特にデータシステムにおいて、パフォーマンスを考慮した設計は、適切なタイミングで適切な洞察に基づいて正しい判断を下すために不可欠です。私はAWSのPrincipal Analytics SAを務めるSandipan Bhaumikです。本日は、Scott RigneyとKamal Sampathkumarが発表を行います。彼らは登壇時に自己紹介をさせていただきます。
本日のアジェンダをご説明させていただきます。まず、パフォーマンスを考慮した設計に関する考え方のフレームワークについて説明します。次に、データシステムから最適なパフォーマンスを引き出す際によくお客様から伺う3つの一般的な課題について説明します。そして、お客様に実装してきた3つのソリューションパターンをご紹介します。そのうちの1つは、実際に本番環境で実装したKamalが共有します。最後に、データワークロードのパフォーマンス最適化に関する考え方をお伝えし、次のステップについての示唆を残して締めくくりたいと思います。
誰もが経験したことがあるでしょう - クエリを実行して結果を待ち続けたり、レポートを実行してロードが終わるのを待ち続けたり。結果が出てきても、期待していたデータが見つからない、最新のデータがまだ到着していないといった状況に遭遇し、データシステムへの信頼が損なわれてしまいます。人々はデータへの信頼を失い、そのようなシステムの利用を止めてしまいます。一方で、スケールできないシステムは、負荷がかかるとボトルネックを生み出します。これらのボトルネックは、ユーザー体験を損なうだけでなく、IT部門に問題対応の負担を強いることになります。そのため、これらのシステムを設計する際にパフォーマンスの視点を持つことが極めて重要なのです。
簡単な話ではありませんが、考え方のフレームワークをいくつかご紹介させていただきます。私の考えでは、Performance Pentagonという5つの重要な要素のバランスを取るメンタルモデルで考えるとよいでしょう：データの処理と配信を高速化する「Latency」、ピーク時の需要増加に対応してスケールアップし、需要がない時にはコスト削減のためにスケールダウンする「Scalability」、システムの効率性とリソース使用率を最大化しながらコストを抑える「Efficiency」、障害に備えた設計と何かが壊れた時の対応を考える「Reliability」、そして最も重要な「Cost」です。データシステムでサブセカンドのレイテンシーを実現することは可能ですが、それはコストを押し上げることになります。つまり、トレードオフの関係にあるのです。データワークロードにパフォーマンスの視点を取り入れる際には、これらのトレードオフと決定のバランスを取り、最適なポイントを見つけることが重要になります。
リアルタイムデータ処理とイベント駆動型ストリーミングパイプライン
具体的な例を見ていきましょう。まずは、高いパフォーマンスが求められるデータシステムの概念的な設計から始めます。実店舗とオンラインストアの両方を持つ小売業を想像してください。このようなシステムでは、様々なユーザーがデータを利用します。システム上でレポートやクエリを実行する人間のユーザーがいます - 在庫データに依存する店舗マネージャーを考えてみてください。彼らは在庫に関する意思決定を行う際に、必要なときにすぐにデータを参照する必要があり、古いデータに頼ることはできません。また、支払いを済ませた顧客は、支払いが完了したことの確認や、過去の注文履歴、以前に注文した商品などの情報を確認したいと考えます。これらの人間のユーザーは、必要なときにデータにアクセスできる必要があるのです。
システム、人以外のユーザー、自動通知システム、そしてエージェント型ワークフローは、データが生成された瞬間に最小のレイテンシーでそのデータを要求します。不正行為が発生する前に検知することを考えてみてください。これらは高性能データシステムで構築する必要のあるリアルタイムインテリジェンスシステムなのです。
このアーキテクチャから理解していただきたいのは、データシステムのコアコンポーネントについてです。左側には、WebサイトやWebアプリケーションから異なる機能を提供するために構築されたMicroservicesがあるConsumption層があります。そして、異なる種類のストレージシステムを持つStorage層があります - これはデータベース、Data Warehouse、Blob Storageなどで、それぞれが異なる内部アーキテクチャを持っています。つまり、Data System Performance Pentagonにおける重要な要素のバランスを取りながら、ベストプラクティスについて異なる判断を下す必要があるということです。
データ処理サービスは、バッチでもリアルタイムでも、様々な速度で移動する大量のデータを処理し、データの増加に応じてスケールする必要があります。Ingestionシステム、つまりデータ収集システムは、異なるソースの異なるフォーマットやサイズのデータに接続し、それらを統合して処理サービスに送ります。アーキテクチャ全体を見たとき、パフォーマンスについて考える方法は、これらの各コンポーネントに焦点を当て、Pentagonモデルを当てはめ、各領域でこれらの重要な要素のバランスをどのように取れるかを見ることです。
では、実際の例を見てみましょう。これは、お客様とよく話し合う非常に一般的なユースケースの1つです - 高い同時実行性を持つワークロードです。Consumption側では、システム上で何百、何千というクエリを実行するユーザーについて話しています。このような負荷で簡単にシステムがダウンする可能性があります。これらのクエリには異なるパターンがあります - 長時間のクエリを実行するユーザー、大量のデータに対して複数のテーブルにまたがる複雑なJoinを実行するユーザー、短時間のクエリを実行するユーザー、インタラクティブなクエリ、アドホッククエリを実行するユーザー、そして広いテーブルに対して集計を実行するユーザーがいます。彼らは低レイテンシーを必要とし、これらのシステム上で最新のデータを見たいと考えています。
これらのシステムのソリューションを構築する際に考えるべきことは、すべてに適合する1つのサービスは存在しないということです。異なるクエリパターン、ピークと谷に対応する必要があります。Microservicesはアーキテクチャとして優れていますが、バックグラウンドで異なるデータシステムを使用することで複雑さが増す可能性があります。そのため、これらのソリューションには目的に特化したサービスを選択することが重要です。これは、高い同時実行性を持つワークロードに実装できるソリューションのパターンの例です。利用状況調査、健康モニタリング調査、トレンド分析などでクエリを実行する、異なる要件を持つユーザーに対応できます。
ユーザーがこのような種類のクエリを実行する際、そこにはさまざまなパターンが存在します。ユーザーに提供できる優れた体験とは、クエリをどこで実行すべきかという意思決定を抽象化することです。ここでQuery APIサービスが活躍します。このサービスはユーザーからのクエリワークロードを受け取り、クエリの実行プランを分析して、そのクエリをどこで実行すべきかを判断します。複数のテーブルを結合し、複数年にわたるデータをスキャンする低レイテンシー要件の複雑なクエリは、Amazon Redshiftで実行できます。Amazon Redshiftはこのようなクエリのために設計されており、これらのワークロードに対してサブセカンドのレイテンシーを提供します。インタラクティブなクエリやアドホッククエリについては、Amazon Athenaの利用を検討できます。
ストレージ側では、お客様がデータレイクを構築するオブジェクトストレージであるAmazon S3があります。ここで、Apache Icebergオープンテーブルフォーマットの実装について考え始めることができます。
これらのオープンテーブルフォーマットには、パフォーマンスを向上させるための機能が組み込まれています。例えば、Icebergはパーティションプルーニングを通じて読み取りクエリを最適化します。データの上でクエリスキャンを改善するために5レベルのメタデータを使用します。アトミックトランザクションをサポートしているため、データレイク上でデータ処理や挿入を行う際に、データレイク自体に対して増分更新や削除を実行できます。これにより、スケールをどこまで行うか、コストを最小限に抑えるにはどうすればよいか、レイテンシーをどう達成するかなど、Data System Performance Pentagonに基づいた判断が可能になり、パフォーマンスが向上します。もう一つの利点は、Iceberg上のAWS Glueとのメタデータストアの統合により、これらすべてのシステムがデータカタログに接続でき、カタログレベルでデータを整理してセキュリティを管理できることです。
高同時実行性ワークロードに対するRedshift ServerlessとAthenaの最適化
Scott、Amazon RedshiftとAthenaのパフォーマンスについて、お客様とどのような話をされているか教えていただけますか？ ありがとうAndy、そして今朝はご参加いただきありがとうございます。私はScott Rigneyと申します。EMR、Glue、Athenaチームのプロダクトマネージャーの一人です。Andyの質問は、私のメールやSlackでよく目にする質問です。つまり、このようなアーキテクチャが与えられた場合、高い同時実行性を実現するためにワークロードをどのようにスケールアップすればよいのかということです。 この議論が注目される理由は明らかです。私たちは、低レイテンシーで多様なワークロードを処理できるようにワークロードをスケールしたいと考えています。
通常、お客様にお勧めしている手順の一つは、まず個々のクエリの実行時間の最適化に時間を投資することです。その理由は直感的です - クエリの実行時間を短縮できれば、単位時間あたりより多くのクエリを実行できるようになります。クエリの最適化は難しいトピックで、適切に行うには相当な時間が必要です。ありがたいことに、Redshift ServerlessやAthenaのようなサービスには、クエリの実行時間を短縮するのに役立つ機能が組み込まれています。
まず、Redshift Serverlessの機能から見ていきましょう。Auto Materialized Viewsと呼ばれる機能があります。Redshiftは、この機能を使って様々なパフォーマンス指標でワークロードを監視し、頻繁にアクセスされるテーブルをビューとしてマテリアライズすべきタイミングを判断します。これにより、そのビューに対する後続のクエリが高速化されます。Automatic Table Optimizationsも、Redshiftが提供する自動化機能の一つです。これは、テーブル全体のクエリパターンを最適化するために、ソートキーやディストリビューションキー、その他のインデックスを自動的にテーブルに適用します。
Athenaは少し異なるアプローチを取っています。Athenaにも自動結合順序の最適化など、多くの組み込みの最適化機能があります。Auto Join Reorderingでは、クエリの正確性を損なうことなく高速化できると判断した場合、クエリプラン内の結合順序を自動的に並べ替えます。これは、Athenaサービスに送信するクエリを修正することなく利用できる組み込み機能です。Athenaの特徴は、Redshiftとは異なり、組み込みのストレージを持たないことです。Redshiftではデータに対してインデックスを適用できますが、Athenaでは通常Amazon S3を使用してデータレイクファイルを保存するため、仕組みが異なります。
ストレージに関する選択は、Athenaサービスから得られる最適化の種類に影響を与えます。その一例が、パーティションインデックスとパーティションプルーニングです。Parquetを使用している場合、Athenaはこれらの機能を活用して、S3から読み取るデータ量を削減し、レイテンシーやクエリプランニング時間、その他のクエリ実行に関する要素を最小限に抑えることができます。私たちは今年、すべてのサービスにわたって新機能の開発に取り組んできました。ここで紹介したのは、Redshift ServerlessとAthenaを使用した高同時実行ワークロードを構築する際に活用できる機能の一部に過ぎません。その一つがRedshift Serverlessのクエリ識別子で、これによってクエリやワークロードにタグを付け、時間の経過とともにパフォーマンスを監視することができます。理想的には、クエリにタグを付けることで、Automatic Table Optimizations、Auto Materialized Views、その他の機能を活用し、クエリの実行時間が徐々に短縮されていくことが期待できます。
低レイテンシークエリのシナリオでは、セッション再利用も有効です。セッション再利用により、Redshift Serverlessのコンピュートに対して素早く接続、切断、セッション再開が可能になり、データ取得に要する時間を最小限に抑え、エンドユーザーにとってのTime-to-Insightを短縮できます。
多くのユーザーがAmazon S3に保存したデータをクエリするためにAmazon Athenaを使用しています。さらに、今年初めにOracleなどのトランザクショナルソースに対してPass Through Queriesという機能を導入しました。この機能により、クエリ操作全体をソースにプッシュダウンし、ソースから直接データを読み取ることができます。この機能を使用してレイテンシーを大幅に削減できたという、素晴らしいフィードバックをお客様からいただいています。 個々のクエリの実行時間を短縮することで最適化できましたが、高同時実行ワークロードにとって重要な別の課題がまだ残っています。これは、多くの方が日々直面している可変ワークロードの問題です。ここでは、定常的な使用状況に加えて、バースト的な高需要期間が発生し、スライドの右端に示される巨大なジャンボクエリから、一日の早い時間帯に実行される小規模なダッシュボードクエリまで、さまざまなサイズのクエリが混在しています。
Redshift Serverlessがこの問題を解決する方法の1つが、AI駆動のスケーリングです。 これにより、Redshiftはワークロードの変化に応じて自動的にスケーリングを行い、柔軟な対応が可能になります。Redshift Serverlessは、データ量、同時接続ユーザー数、クエリの複雑さなどの指標を評価して、価格とパフォーマンスの最適なバランスを維持します。社内でのテストでは、チューニングを必要とせずにAI駆動のスケーリングを使用することで、10倍もの価格性能比の向上が確認されました。
一方、Amazon Athenaは少し異なるアプローチを取ります。Athenaのワークロードをスケーリングする際には、異なる要素を考慮する必要があります。Athenaのクエリは、デフォルトでマルチテナント方式のサーバーレスキャパシティプールで実行され、Athenaは内部的に顧客の利用状況に基づいてそのキャパシティの規模と構成を最適化します。ユーザーがAthenaサービスにクエリを送信すると、Athenaサービス自体がキャパシティプールを調整し、全顧客のクエリ開始時間を最小限に抑えることを目指して動作します。
アカウント内のクエリは、実際にはアカウントレベルのクエリクォータを奪い合うことになります。ワークロードを拡大する際に、異なるビジネスチームが性能低下を経験したり、クエリが長時間キュー状態になったりする状況に遭遇する可能性があります。この問題を解決するために、私たちはAthenaのProvisioned Capacityという機能をお勧めしています。Provisioned Capacityは、お客様のアカウント専用のサーバーレスキャパシティであり、ワークロードをスケーリングするために自由に調整できるキャパシティリソースです。
Provisioned Capacityは、高い同時実行性が必要で、アカウント内で明示的に制御できる予測可能なパフォーマンスが求められる場合に推奨されます。Provisioned Capacityでは、ワークグループに自由に割り当てることができるキャパシティのバンドルである「リザベーション」を作成し、ワークロードに合わせてキャパシティユニットを追加または削除することができます。さらに素晴らしいことに、このProvisioned Capacityは同じクエリエンジンと同じクエリ送信モデルを使用するため、エンドユーザーはクエリを修正する必要がありません。リザベーションをスケーリングするために、CloudWatchを通じて利用率メトリクスを監視する機能を活用し、AWS Lambdaとセット関数を使用してリアクティブなシステムを構築し、アプリケーション内にカスタムスケーリングロジックを実装することができます。
Workhumanのデータプラットフォーム：課題と解決策
ありがとうございます、Scott。ユースケース2：リアルタイムインテリジェンスについて説明します。お客様からよく相談される別の一般的な問題は、リアルタイムでデータを処理してイベントに対応することです。これはジョブのスケジューリングの問題ではなく、イベントが発生した時点での対応が必要なのです。 不正検知、というよりも不正防止について考えてみましょう。取引が行われる際に、どのように不正を防止できるでしょうか？どのように検知し、そのデータを処理して下流のシステムに送信できるでしょうか？これは継続的なデータ処理であり、パターンに動的に適応できるインテリジェントなシステムが必要です。事前に一定の知識で訓練された機械学習モデルがありますが、新しい不正パターンを検知できるように、データの変化するパターンに適応していく必要があります。
不正検知・防止チームには、今まさに何が起きているかを把握するためのリアルタイムレポーティングと運用分析が必要です。彼らにとって価値があるのは、過去のデータではなく、現在のデータなのです。このようなシステムでは、通知システムや、判断を下して他のシステムにその判断を伝えるシステムなど、人間以外のコンシューマーが存在することも多いです。リアルタイムでイベントに反応し、大量のデータをリアルタイムで処理できるイベント駆動型パイプラインをどのように構築できるか、考える必要があります。
このようなユースケースでよく見られるパターンの1つが、イベント駆動型ストリーミングパイプラインの活用です。左側から見ていくと、アプリケーション上でトランザクションが発生した時 - クレジットカードを使用して顧客が決済を行うEコマースの例を考えてみましょう - これらのイベントはAPI Gatewayを通過します。その後、AWS Lambda関数が軽量な処理を行い、データ構造をクリーンにして、リクエストペイロードをストリーミングバッファであるAmazon Managed Service for Apache Kafka（MSK）に送信します。MSKは、オープンソースのKafkaのマネージドバージョンとして提供されており、イベントストリームを取り込み、保存し、Amazon Managed Service for Apache Flinkなどのダウンストリームシステムに渡すことができます。
Flinkは、このストリーミングデータを処理し、Amazon SageMakerの機械学習モデルなどのインテリジェンスシステムに非同期呼び出しを行う役割を担っています。リクエストペイロードはMSKを通じて送られ、Amazon Managed Service for Apache Flinkに入り、そこから機械学習モデルに情報を送信します。モデルがそのイベントを不正と判定した場合、データはFlinkに返されます。Flinkはそのデータを構造化し、参照データを結合してイベントをより多くの情報で充実させ、それを再びMSKに渡して、異なるコンシューマーにどのように配信するかを決定します。コンシューマーには、メールやアラートを送信するSMSを使用した通知システム、運用分析のためのAmazon OpenSearchを使用したリアルタイムレポーティング、あるいはAmazon S3にデータを送信してAWS Glueを使用しビジネスインテリジェンスや機械学習トレーニング用にデータを構造化するバッチ分析などがあります。
MSKは1秒あたり数十万のイベントまでスケールでき、MSFも同様に数十万のイベントを処理できるようにスケールします。重要なのは、これらがServerlessであり、多くの作業の負担を軽減してAWSに責任を委ねることができる点です。私たちがその多くを管理するため、お客様は不正検知に集中できます。これらのサービスは互いによく統合されているため、異なる目的に異なるツールを管理する必要がなく、単一のシステムとして管理できます。Amazon OpenSearch Serviceが提供する機能の1つが、ゼロETLとストリーミング統合です。これにより、OpenSearchにデータを取り込むためのスケーラブルで費用対効果の高い方法が提供され、データが取り込まれると、非常に低いレイテンシーでインデックス化とクエリが可能になります。今年初めには、Amazon S3、Amazon DocumentDB、Amazon MSKとの統合を開始し、それを実現するお手伝いをしています。これにより、より多くのデータをOpenSearchクラスターに取り込み、超低レイテンシーでインサイトを提供できるようになりました。
OpenSearchには、OpenSearch Compute Units（OCU）で測定されるインデックス作成と検索コンピュートのキャッシングを提供する組み込みのキャッシング層があります。以前は、OCUはインデックス作成ジョブによって消費され、消費率は主にワークロード自体のサイズに基づいて決定されていました。スマートキャッシングにより、最も使用される可能性が高く、最も頻繁にアクセスされるデータのみをキャッシュに保持することで、インデックス作成ジョブのデータ管理の側面を最適化しました。これにより、全体的なOCU消費を削減し、データ取得タスクを提供する際のインデックス作成プロセスをより効率的で費用対効果の高いものにしています。
今年は、OpenSearchの拡張容量と自動スケーリング機能も構築しました。これにより、OpenSearchでより大規模なデータセットに対してワークロードをスケールできるようになりました。具体的には、アカウントごと、リージョンごとのOCU容量の制限を200から500 OCUまで引き上げています。 私たちのユースケースでは、AWS Glue ETLも活用して、Smartジョブで実行するバッチデータ処理を行っています。これにより、下流の機械学習トレーニングジョブを実行し、それらのジョブの実行における一貫性を確保しています。
今年初めに、AWS Glue Usage Profilesをリリースしました。Usage Profilesは、ジョブの実行時の境界を定義できる設定とコントロールのセットを提供します。これにより、ジョブのパフォーマンスとコストの側面でより一貫した制御が可能になります。例えば、ジョブの最大ワーカー数やタイムアウトを設定できるようになり、これは下流のビジネスユーザーにタイムリーなインサイトを提供する上で役立ちます。システム内のジョブ数が増加する中で、今年初めにJob Run Queuesをリリースしました。これにより、開発者はジョブをAWS Glueサービスに送信するだけで、Glueがキューを管理してくれる「fire-and-forget」な体験が可能になります。これによって、サービスクォータによるエラーの処理やリトライの管理にかかる時間と労力を節約できます。ジョブを開始するだけで、サービスクォータ制限によって失敗するはずのジョブは、Glueがキューに入れ、先入れ先出し方式で実行してくれます。
すべてのシステムやシステムの利用者がリアルタイムでデータを必要とするわけではありません。大量のデータのエクスポートや抽出を必要とする利用者を考えてみましょう。オプション1は、バッチジョブで定期的にスケジュールされたデータを顧客に提供することです。顧客が必要なときにデータを抽出できるようにすれば、システムをより効率的にできます。これにより、システムを繰り返し実行する必要がなくなるため、リソースの活用が改善されます。カスタマーニュースレポートやアドホックレポートは、必要なときに生成される自己サービス分析となります。これはビジネスインテリジェンスレポートでも同様です。多くの顧客が組織全体で標準的な既製のレポートを見ていますが、一部のチームはこれらのレポートをカスタマイズして、より多くのデータや列を追加する必要があります。これがWorkhumanが顧客のために解決した課題です。
Data Feed APIとQuickSightを活用したB2Bソリューションの構築
皆様、Workhumanのデータアーキテクチャ部門ディレクターであるKamal Sampathkumarをお迎えしたいと思います。おはようございます。聞こえますでしょうか？re:Inventに参加できることを嬉しく思います。 私たちがどのように顧客にセルフサービス分析を提供しているか、Workhumanの成功事例をご紹介できることを楽しみにしています。ソリューションについてお話しする前に、Workhumanについて - 私たちが誰で何をしているのかをご紹介させていただきます。私たちはソーシャル認識のグローバルリーダーで、アイルランドのDublinとボストンのFraminghamを拠点としています。多くの組織に人間中心の職場ソリューションを提供しています。私たちのプラットフォームは3つのことをサポートしています：従業員同士が感謝し合うこと、従業員同士がお祝いし合うこと - お祝いは勤続記念日や家の購入、結婚などのライフイベントなどです。
また、従業員同士が対話することもサポートしています。Workingプラットフォームでは、従業員がピア認識を通じてリアルタイムでお互いの貢献を認め合うことができます。これらはクラウドベースのSaaSプラットフォームを通じて実現しています。
プラットフォームが扱うメトリクスについてお話しさせていただきます。私たちのプラットフォームには700万人のユーザーがおり、2秒ごとに1回の認識の瞬間が生まれています。これにより、複数のタッチポイントと人と人とのつながりが生まれています。プラットフォーム上では1億以上の人的つながりが形成されています。このような規模になると、特にデータに関する課題が出てきます。例えば、このデータをどのようにしてセルフサービスの形でお客様に提供するかということです。Sandyが先ほど話したような消費機能を提供し、柔軟に対応できる基盤的なプラットフォームを、ボトムアップで考える必要があります。
データプラットフォームで最初に取り組んだ戦略の一つは、お客様向けのセルフサービス機能の実現方法でした。例えば、ユーザーがデータを通じて十分な情報に基づいた意思決定を行えるようにするにはどうすればよいか。ITチームやエンジニアリングチームの介入なしに、お客様が自分でレポートを作成できるようにするにはどうすればよいか。ユーザーが自分のデータを見て、トレンドやパターンを理解できるようにするにはどうすればよいか。例えば、2025年に向けて私がどれくらいの支出をするのかといったことです。データそのものには価値が少ないので、どのようにしてスケールを確保しながらユーザーにビジネス価値を届け、さらにユーザーがデータを扱う際の運用負荷を全体的に削減できるかが課題でした。
このプラットフォームは4年前に構築しました。これを基本原則として私たちは開発の旅を始めました。ここでお見せする設計図は複雑に見えますが、これは私たちが今まで構築してきたもので、実際に本番環境で稼働し、エンドユーザーに機能を提供しています。この設計を4つの主要レイヤーに単純化してご説明します。まず、ソースシステムからデータを抽出する抽出レイヤーがあり、データタイプに応じて処理を行います。様々なソースシステムに特化した複数の取り込み機能を採用しており、DMS、AWS Glue、EMRを使用しています。これらのテクノロジーを組み合わせることで、高速にデータをプラットフォームに取り込むことができます。
設計の2番目のレイヤーはキュレーションレイヤーです。このレイヤーはクレンジングレイヤーとしても機能し、PIIデータの保護などデータのセキュリティも確保します。プラットフォームに入ってくるデータをカタログ化し、下流のアプリケーションが利用できる統一された用語集を提供します。システムの3番目のレイヤーはモデリングレイヤーです。ここで魔法が起きます。ここですべての変換が行われ、生データが実用的なデータプロダクトに変換され、下流のアプリケーションで消費され、アクショナブルなインサイトを提供し、製品機能にも力を与えることができます。プラットフォームの最後のレイヤーは消費レイヤーです。このレイヤーについては、私たちが構築したいくつかのソリューションについて、より詳しくお話ししたいと思います。このレイヤーは、準備され、ユーザーや製品が消費できる状態になったデータプロダクトを提供する役割を担っています。 ここで、Fortune 500のお客様との間で直面した課題についてご紹介したいと思います。
これらのお客様は、それぞれ独自のエンタープライズデータプラットフォームを持っており、データを取り込みたいと考えていましたが、SQLインターフェースとのやり取りは望んでいませんでした。SQLインターフェースとのやり取りのように、SQLパラメータ、クエリパラメータ、順序句などを受け渡せる、APIインターフェースを通じたオンデマンドの動的なデータフィードが必要でした。私たちはこれを機会と捉え、Data Feed Data APIと呼ぶ新しい消費レイヤーをプラットフォームに追加しました。これにより、お客様が直接Workhumanのデータプラットフォームと連携し、自社のエンタープライズデータウェアハウスにデータを取り込むことができるB2Bソリューションが実現しました。
高レベルで見ると、データフィードの生成は非同期で実行され、3つの異なるエンドポイントがあります：データのリクエスト方法、データの取得方法、データセットの準備状況の確認方法、そしてデータセットの取得方法です。 ここでご紹介するのは、データセットをリクエストする方法についての設計です。設計図からお分かりの通り、このフローの構築には完全なServerlessのAWSテクノロジーを使用しています。認証・認可にはAmazon Cognito、APIエンドポイントの公開とセキュリティ確保にはAmazon API Gateway、そしてリクエストを受け付けてロジックを処理するAWS Lambdaを使用しています。Lambda関数は、クエリの複雑さに応じてAmazon RedshiftまたはAmazon Athenaのいずれかに処理を委譲します。Lambda関数による評価が行われ、リクエストのルーティングとAPIのステータスをAmazon DynamoDBに保存します。処理が成功すると、データはAmazon S3バケットにアンロードされます。
2番目のエンドポイントは、データが準備され消費可能な状態になった時点で機能します。 データはAmazon S3バケットに保存されています。リクエストは取得したいデータセットIDに基づいて受け付けられます。ここでもフローはユーザーのIDを検証し、API GatewayがAPIリクエストを検証します。Lambda関数が委譲を行い、このリクエストに対応するファイルの場所を特定します。レスポンスは単純なPre-signed URLで構成され、エンドポイントにレスポンスとして配信され、お客様がデータをダウンロードします。 この解決策により、私たちが構築した汎用的なAPIインターフェースによって大きな影響がもたらされました。今では複数のデータプロダクトを容易に公開できるようになりました。すべてを書き直す必要はなく、ロジックの変換に時間を費やすだけで済みます。というのも、インフラはすでに整っているからです。
2番目の解決策として、Amazon QuickSightを使用して数千人のユーザーに対してレポーティングソリューションをスケールさせた方法についてお話ししたいと思います。この解決策は当初かなり難しいものでした。というのも、お客様は事前にレンダリングされたレポートを使用しており、私たちのプラットフォームもそのようにユーザーにレポートを提供していたからです。ユーザーは自分の好みのディメンションでデータを細かく分析することができませんでした。カスタマイズが必要で、自分で分析を行い、それを社内ユーザーと共有できる機能を求めていたため、苦労していました。課題は、これをスケールさせる方法と、この体験をWorkhumanプラットフォームに組み込む方法でした。ユーザーにQuickSightに移動してもらうのではなく、Workhumanプラットフォーム内で作業してもらいたいと考えていました。
私たちはエンドツーエンドのソリューションを提供するための候補としてAmazon QuickSightを検討しました。QuickSightが提供する重要な機能の1つはダッシュボードの埋め込みですが、私たちはそれ以上に、提供体験全体を埋め込む方法を模索しました。そしてQuickSightはそれを可能にしてくれました。
マルチテナントのSaaSベースのプラットフォームを扱っているため、多くのお客様がおり、データとユーザーを保護するためにお客様の分離を提供する必要があります。QuickSight画面の上部にNamespaceが表示されているのがお分かりかと思います。QuickSightにはNamespaceと呼ばれる機能があり、これによってユーザーを分離することができます。あるNamespaceのユーザーは、他のNamespaceのユーザーとデータをやり取りしたり共有したりすることができません。これにより、各Namespaceに複数のお客様のフットプリントを作成することができました。
次にお話ししたいのは、分析のカスタマイズについてです。私たちの作業プラットフォームで作成した分析を、お客様と共有する必要がありました。これらの分析は大きく変わることはありませんが、お客様にとって良いスタートポイントとなります。私たちはQuickSight APIを通じて、テンプレートを各お客様のデータネームスペースにコピーし、お客様固有のデータセットとバインドすることでこれを実現しました。
お客様は、ソリューション内でセキュリティを管理したいと考えていました。例えば、分析が公開された場合、特定のユーザーグループが閲覧できるデータポイントを制限したいというニーズがありました。QuickSightにはロールレベルのセキュリティがありますが、私たちのプラットフォームではこれを制限基準と呼んでいます。私たちは、ユーザーインターフェース上で独自のルールセットを作成できるようにし、それをロールレベルのセキュリティに変換するようにしました。これにより、お客様は私たちを介することなく、誰が何を見られるかを自分たちでコントロールできるようになりました。
この組み込みダッシュボードの統合は、私たちにとって画期的なものでした。複数のお客様向けに多数のダッシュボードを大規模に展開できるからです。現在、何千人ものユーザーがこのアプローチを使用していますが、これはインフラ管理を必要とせず、何千人ものユーザーをスムーズに収容できています。最後に、これをどのように実現したのかについてお話ししたいと思います。これらの機能を提供するために、私たちは自社のデータプラットフォームを大いに活用しました。将来のデータニーズの変化に対応できるよう、基盤となるブロックを適切に配置することが重要です。re:Inventでお話しする機会を与えてくださったAWSとチームの皆様に感謝申し上げます。
Serverlessサービスのパフォーマンス最適化と今後の展望
ここで2つの重要なポイントをお伝えしたいと思います。1つ目は、Data APIサービスがこのようなアーキテクチャの素晴らしい点だということです。AWSクラウドを使用していないお客様にも対応できるからです。すべてのお客様がAWSを使用しているわけではありません。Data APIサービスは、セキュアなHTTP通信を介してデータを転送できます。
2つ目は、QuickSightに関して、1つのQuickSightアカウントから複数のお客様にスケールし、その体験を製品に組み込めるという点です。BIサービス内でマルチテナントアプリケーションアーキテクチャを効率的に構築することを考えることは、ゲームチェンジャーとなります。このセッションを終えた後、これらのトピックについてさらに探求していただければと思います。
セッションの締めくくりとして、Serverlessサービスについて、そしてServerlessサービスのパフォーマンス最適化をどのように考えるべきかについて、いくつかの考えを共有したいと思います。Serverlessでは、多くの責任をお客様から切り離しています。セキュリティ、スケーラビリティ、可用性、インフラストラクチャ管理、パッチ適用など、多くの部分を私たちが管理しています。では、パフォーマンスについてはどうすればよいのでしょうか？ データとアナリティクスの分野では、冒頭でお見せしたアーキテクチャ図に関連する各機能において、Serverlessサービスを提供しています。取り込み、処理、ストレージ、データウェアハウス、検索・分析、可視化、ガバナンス、メタデータ管理など、さまざまなコンポーネントと領域に対応したServerlessサービスがあります。
このパフォーマンス最適化のサイクルを、お客様のデータワークロードに適用する必要があります。最初のステップは選択プロセスです - Serverlessファーストの戦略を取れるか、Serverlessがワークロードに適しているかを検討します。先ほどのペンタゴンモデルとそれらの要素間のバランスを念頭に置きながら、目的に特化したサービスを選択してください。ボトルネックの原因となるため、万能なサービスを選ぶのは避けましょう。選択が完了したら、レビュープロセスと継続的なレビューの実施方法について考えます。AWS Trusted AdvisorとAWS Well-Architected Frameworkを提供しており、これらを使用して継続的にワークロードをレビューすることができます。これは一度きりの作業ではなく、AWS Well-Architected Frameworkを6ヶ月ごとに実施することをお勧めしています。AWS Solutions Architectsがこれらのレビューの実施をサポートいたします。
トレードオフに関しては、すでにキャッシングと圧縮のバランス、コンシューマーとのサービスレベルアグリーメントの合意方法、システムの効率性とパフォーマンスを向上させるためのトレードオフについて議論しました。ペンタゴンモデルを使用してこれらを検討してください。そして、モニタリング、オブザーバビリティ、データのベースライン化に焦点を当てます。現在どこにいるのか？パフォーマンスをどのように最適化できるのか？これは継続的改善と呼ばれる ongoing processであり、データシステムにパフォーマンスの視点を適用する際には、このサイクルを適用してこれらの要素を考慮する必要があります。
私たちがどのようにサポートできるか、そして次に何ができるかについて説明させていただきます。データシステムがない状態から設計を始める場合、データ戦略の策定からサポートできます。Data-Driven Everythingプログラムでは、組織のデータ戦略の策定を支援し、1つのユースケースでパイロットを実施して、他のユースケースを取り込むための基盤となるフレームワークを構築することができます。次に、モダナイゼーションと移行については、オンプレミスからの移行とデータアーキテクチャのServerless化を検討されている場合、re:iMagine Dataプログラムを通じて、AWSのスペシャリストがアカウントチームと連携して、移行とモダナイゼーションの計画をサポートします。第三に、AWS Well-Architected Frameworkは、コスト最適化、セキュリティ、パフォーマンス、持続可能性など、6つの柱をカバーしています。これらのレビューをどのように実施し、計画するか、そしてアカウントマネージャーやアカウントソリューションアーキテクトと相談して、これらのレンズを使用してデータシステムを最適化する方法を検討することをお勧めします。
最後にお願いがございます - このコンテンツについて、ぜひレビューをお寄せください。私たちはこのコンテンツの作成に多くの時間を費やしており、皆様からのレビューは、このような内容をre:Inventで再び提供する際の参考となります。本セッションにご参加いただき、ありがとうございました。皆様が素晴らしいre:Inventを過ごされますことを願っています。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion