re:Invent 2024: AWSアナリティクスでAI/ML向けデータ戦略を構築
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Data engineering for ML and AI with AWS analytics (ANT405)
この動画では、AIアプリケーションのためのデータ戦略とAWS Analyticsサービスの活用方法について解説しています。AWS GlueやAmazon MSK、Amazon EMRなどを用いたデータパイプラインの構築方法や、自然言語からSQLへの変換パターン、Gen AIアプリケーションでの構造化データの活用方法を具体的に説明しています。特に、Nexthinkの事例では、毎秒500万以上のレコードを処理する大規模なデータプラットフォームの構築と、そこから生まれたAutopilotというGen AI製品の開発について、Amazon SageMakerを使用したFine-tuningの実装など、実践的な知見が共有されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS Analyticsによるデータエンジニアリングセッションの概要
AWS AnalyticsによるMLとAIのためのデータエンジニアリングのセッションにご参加いただき、ありがとうございます。このセッションでは、AIアプリケーションのためのデータ戦略の構築方法と、AWS Analyticsサービスを活用したデータ戦略の実現方法についてお話しします。私はAWSのPrincipal Solutions Architectで、本日はAWSのDirector of Applied SciencesでMIT教授でもあるTim Kraskaさん、そしてNextInのエンジニアリングリーダーであるMohaさんにもご参加いただいています。
アジェンダをご覧ください。本日は、AI成功のためのデータ戦略の重要性と、AWS Analyticsサービスを使用したデータ戦略の構築方法についてお話しします。その後、Timが自然言語からSQLへの変換パターンと、Genアプリケーションの一部として構造化データを使用する方法について説明します。また、本日早くにSwamiが基調講演で発表した新機能についても触れ、デモもご覧いただきます。そして、MohaがAWSサービスを使用してGen対応のチケットシステムを構築したNextInの取り組みについてお話しします。
AIアプリケーション成功のためのデータ戦略
これはAWSのセッションですので、恒例の挙手のお願いを1つさせていただきます。現在、組織内でAIアプリケーションを運用されている方は何人いらっしゃいますか？もう少し多いかと思っていましたが、夕方遅い時間帯ということもあるかもしれません。今日、AIそしてGen AIへの期待が高まっているのは、カスタマーエクスペリエンスの変革、従業員の生産性向上、そして事業運営の全体的な改善に役立つからです。AIとGenには、バーチャルチャットアシスタントからテキスト要約、コード生成まで、従業員の生産性を向上させる多くのユースケースがあります。また、小売需要予測、予測分析、感情分析などの従来型のAIユースケースもあります。
これらのアプリケーションを構築する際、アプリケーションを成功させ、お客様に採用していただくために必要な要素がいくつかあります。最も重要なのは、機械学習モデルのトレーニングに使用できる高品質なデータが利用可能でアクセス可能であることを確認することです。データは、お客様がアプリケーションを利用する際にパーソナライズされた体験を得られるようにする重要な差別化要因であり、それによってアプリケーションの採用がさらに進み、成功につながります。
アプリケーションのトレーニングに必要なすべてのデータを確実に利用できるようにするには、データ戦略を整備する必要があります。現代では、構造化データと非構造化データの両方を含む多様なデータソースが存在します。最初のステップは、これらすべてのデータを取り込んで中央の場所に集約することです。これは、バッチ取り込みやストリーミング取り込みによって、エンタープライズデータレイクにデータを取り込むことを意味します。データの再処理が必要になるシナリオに備えて、通常は生のフォーマットでデータを取り込むことが推奨されています。
このデータは、ETLツールを使用して処理され、ロジックの構築やデータ変換が行われます。データは、下流のアプリケーションが容易に利用できる構造に変換されます。変換されたデータはカタログ化され、データプライバシーやデータアクセス制御などのデータガバナンスルールが適用され、最小権限の原則に従いながら、必要なシステムやユーザーがデータにアクセスできるようになります。このデータは、組織内のビジネスユニットや他のユーザーが利用可能となり、データ処理パイプラインの構築、Machine Learning用のトレーニングおよび検証データセットの生成、GenAIユースケース向けのベクトルデータストアへのデータ変換とロード、特徴量エンジニアリングなどを行うことができます。トレーニングと検証のデータセットはAIモデルで利用可能となり、モデルのトレーニングとアプリケーションの構築が行われます。
AWSサービスを活用したデータ戦略の実装
ユーザーがアプリケーションを利用する際に生成される価値のある情報は、フィードバックループとして捉えられ、将来のモデルのチューニングやファインチューニングのためにData Lakeに送り返されます。ここで、AWSがこのプロセスをどのようにサポートできるのかという疑問が生じますので、同じフローをAWSサービスを使用して見ていきましょう。様々なソースからのデータ取り込みには、AWS Glueを使用できます。Glueコネクタを使用して70以上の異なるデータソースに接続し、Data Lake内の中央の場所にデータを取り込むことができます。
ストリーミングのユースケースでは、Amazon Managed Streaming for KafkaとKafkaコネクタを使用して異なるデータソースに接続するか、AWSネイティブのソリューションを好む場合はAmazon Kinesis Data Streamsも良い選択肢です。データがオンプレミス環境にある場合は、AWS DataSyncを使用してオンプレミスのデータストアに接続し、Data Lakeにデータを取り込むことができます。このデータはAmazon S3内のData Lakeに生データ形式で取り込まれ、AWS GlueまたはAmazon EMRを使用してデータのクリーニングと検証を行うデータ処理パイプラインを構築できます。
変換されたデータはAWS Glue Data Catalogを使用してカタログ化され、AWS Lake Formationを使用して詳細なアクセス制御を構築できます。アナリストや非技術系ユーザーがビジネスの文脈や意味でデータを見つけやすくするためのビジネスカタログを持つことが推奨され、Amazon DataZoneを使用して技術的なカタログの上にこのビジネス層を構築できます。データ処理には、GlueやAmazon EMR、あるいはSageMakerですべてを行いたいMachine Learningサイエンティストの場合はData Wranglerという選択肢もあります。
このプロセスの中で、トレーニングと検証のデータセットを生成し、RAGを使用したいGenAIベースのユースケース向けに、Amazon AuroraやAmazon OpenSearchなどのベクトルストアにデータを保存するベクトルデータ管理を実行できます。トレーニングと検証のデータセットは、SageMaker AIまたはGenAIユースケース向けのAmazon Bedrockでモデルをトレーニングするために使用されます。ユーザーがこれらのGenAIベースのアプリケーションを利用する際、フォローアップの質問のためのセッション情報とコンテキストを維持する必要があり、これらはAmazon DocumentDBやAmazon DynamoDBに保存できます。
Amazon KinesisとMSKの活用とベストプラクティス
まずはストリーミングとAmazon Kinesis Data Streamsについて、AWSサービスの活用におけるベストプラクティスを詳しく見ていきましょう。Kinesis Data Streamsは、数秒で数ギガバイトのデータをストリーミングできるサーバーレスソリューションで、使用分のみの課金となります。推奨されるベストプラクティスとして、Kinesis Producer Libraryの組み込み機能を使用して、Kinesisストリームに書き込む前にデータを集約して圧縮することが挙げられます。
コンシューマー側では、Kinesis Consumer Libraryを使用することで、データの集約解除を簡単に行えるほか、チェックポイントと障害耐性の機能も利用できます。ストリーミングアプリケーションがダウンして再起動した場合でも、どこから再開すればよいかを把握できます。Kinesis Data Streamsは複数のシャードに分割され、各シャードはコンシューマーごとに毎秒2メガバイトのスループットを持っています。複数のコンシューマーがKinesisストリームから読み取る場合、このスループットは共有されます。複数のコンシューマーがいるシナリオでは、Enhanced Fan-outコンシューマーの使用が推奨されます。これにより、各コンシューマーがシャードごとに専用の毎秒2メガバイトを確保できます。
この専用スループットにより、コンシューマーを追加しても、スループット共有による既存ジョブの速度低下を防ぐことができます。Amazon Kinesisでは、オンデマンドモードまたはプロビジョニングモードを選択できます。推奨されるアプローチは、まずオンデマンドモードで開始し、トラフィックパターンを理解した後にプロビジョニングモードに切り替えることです。
Amazon Managed Streaming for Apache Kafka（MSK）については、クラスターのCPU使用率を60%前後に維持するようにしましょう。これにより、運用上のイベントやブローカーの障害が発生した場合の回復に十分な余裕が確保できます。MSKの各ノードタイプには最大スループット容量があり、サポートされる最大CPUの80%前後を維持することが推奨されます。レプリケーション係数3で3つのアベイラビリティーゾーンにMSKクラスターを展開することで、高可用性クラスターを構築し、すべてのデータとトピックがゾーン間でレプリケートされます。最小同期レプリカを2に設定することで、1つのブローカーがダウンしても、クラスターは正常に動作し続けます。最近、MSKのExpressブローカーをリリースしました。これは通常のブローカーと比べて高スループットと高速なスケーリングを提供します。現在MSKをご利用中の方や、MSKの使用を検討されている方は、ユースケースに応じてExpressブローカーをテストすることをお勧めします。
AWS Glueを使用する際は、適切なワーカーサイジングを確保することが重要です。異なるワーカータイプは、Executorごとに異なるCPUとメモリ量を提供します。最適なアプローチは、Glueでワンクリックでアクセス可能なSpark UIを通じてExecutorの使用状況を分析することです。時間的制約のないジョブには、予備容量を利用してコストを削減できるFlex Executionを使用しますが、ジョブの開始に若干の遅延が生じる可能性があります。増分処理が必要な場合は、ジョブブックマークを実装して処理済みデータを追跡し、後続の実行で最後のチェックポイントから再開できるようにします。一般的なSparkの最適化については、シャッフルの最適化とネットワークデータ転送を最小限に抑えるためのPredicate Pushdownの実装に焦点を当てましょう。
Amazon EMRの場合、特にEMR on EC2では、ユースケースに応じて適切なインスタンスタイプを選択することが大切です。計算負荷の高いワークロードにはCompute最適化インスタンスを、メモリ集約型の処理にはMemory最適化インスタンスを使用しましょう。Gravitonインスタンスは、一般的にx86アーキテクチャと比較して、より優れた価格性能比を提供します。また、実行エンジンの段階的な性能向上が組み込まれているため、最新バージョンのEMRを活用することをお勧めします。例えば、EMR 7.x上で実行されるSparkは、バージョン6.xと比較して、より優れた価格性能比を提供します。
機械学習モデルのトレーニングでは、高品質なトレーニングデータを確保することが重要です。AWS Glue Data Qualityを使用すると、パイプラインのさまざまな段階でデータ品質ルールを実装できます。Glueコネクタを使用して異なるデータソースに接続し、そのデータをすべてGlue内でカタログ化することができます。
Glue Data Catalogでは、データ品質ルールを設定し、データの更新が発生するたびにそれらを実行して、新しいデータで期待される品質レベルが維持されているかを確認できます。また、Glueでは、ETLジョブの一部としてデータ品質変換を通じてインラインでデータ品質チェックを実行することもできます。この変換では、設定したルールに基づいてデータ品質をチェックします。データが品質ルールを満たしている場合は、データレイクに書き込むことができます。満たしていない場合は、別のセクションに書き込んで、データを確認し、品質を確保した上でデータレイクに追加することができます。
データガバナンスについては、保有するすべてのデータをGlue Data Catalogで技術的なデータカタログ内にカタログ化することが重要です。大量のパーティションを持つテーブルがある場合、通常はパフォーマンスへの影響が発生します。これに対処するために、Glueパーティションインデックスとパーティションフィルタリングを使用して、最適なパフォーマンスを確保しましょう。統計情報の実行は非常に重要です。なぜなら、AthenaとRedshiftのコストベースオプティマイザーがこれらの統計情報を使用して、クエリの最適な実行プランを構築するからです。そのため、定期的にGlueテーブルの統計情報を収集して実行することを確認してください。
Lake Formationで細かなアクセス制御を設定する際は、管理の拡張性を高めるためにタグベースのアクセス制御を使用しましょう。タグベースのアクセス制御は、テーブルにタグを割り当てることで機能します。Lake Formationで、アナリストユーザーが特定のタグを持つテーブルにアクセスできるように指定します。新しいテーブルが追加された場合でも、個々のテーブルごとに細かなアクセス制御を設定する必要はありません。特定のタグを付けてテーブルを作成するだけで、そのタグに対するLake Formationのアクセス許可を既に付与しているため、アナリストユーザーは新しいテーブルにアクセスできます。さらに、ビジネスカタログを整備することで、アナリストやビジネスユーザーなどの非技術者が分析に必要なデータを見つけやすくなります。
自然言語からSQLへの変換：課題と解決策
データの取り込み、処理、品質管理、ガバナンスについて説明してきましたが、いよいよデータを分析に活用する段階に入ります。データへのアクセスや活用方法には複数のアプローチがあります。最もシンプルなのは、Prompt Engineeringで、様々なデータストアから関連情報を取得してプロンプトを生成し、Gen AIアプリケーションに送信して回答を得る方法です。また、RAG（Retrieval Augmented Generation）を実装することもできます。RAGでは、ユーザーの質問をトークン化し、OpenSearchなどのベクトルデータストアで意味的に関連するデータを検索し、それをプロンプトに追加してGen AIアプリケーションに送信して回答を得ます。文脈を考慮したPrompt EngineeringやRAGだけでは不十分な場合は、モデルのFine-tuningが必要になることもあります。最も複雑でコストがかかるのは独自のモデルをトレーニングする方法ですが、これを実施しているお客様はあまり見かけません。今回は主にRAGアプローチに焦点を当て、Fine-tuningについても触れていきます。
ここからは、RAGアプリケーションにおける構造化データの活用について、Timに説明してもらいます。私はAmazonのApplied Scienceのディレクターで、主に機械学習とシステムの交差領域で仕事をしています。例えば、私のチームはRedshiftのQuery Editor V2の一部として、Janitor SQLという機能を開発しました。Amazonの言葉を借りると、最近HRとミーティングがあり、私がまだアカデミアと関わっている理由を説明する必要がありました。毎年彼らは、MITの教授を続けているのは趣味だと言っていますが、私は今でもそれを続けています。PhDの研究者たちにも様々なトピックで研究してもらう必要があります。研究者は様々なトピックに取り組むことができます。
それでは、Generative AIアプリケーションを作成する一般的なフローについて直接説明していきましょう。まず、S3に保存されているドキュメントの扱い方と、それを使ってGenerative AIエクスペリエンスを構築する方法について説明します。これは通常RAGと呼ばれるもので、Fine-tuningなどの側面は一旦置いておいて、現在の最先端のアプローチです。
仕組みはこうです：エンドユーザーがリクエストまたはクエリを発行すると、それは構築中のアプリケーションに送られます。リクエストは通常Amazon Bedrockでホストされているembeddingモデルにルーティングされます。そのembeddingはOpenSearchなどのベクトルストアに送られ、ベクトル検索を使用して最も類似したドキュメントを見つけます。上位の結果をプロンプトに含め、場合によっては会話履歴もプロンプトの一部として追加します。これが大きなテキスト文字列となり、選択したモデル（これも再びBedrockでホストされている可能性があります）に送信され、ユーザーに応答が返されます。
Bedrockプラットフォームがなければ、どこかでPythonを実行し、OpenSearchをセットアップし、embeddingモデルをホストするなど、すべてを自分で実装する必要があります。Bedrockプラットフォームの利点は、このプロセスが非常に簡単になることです。特にRAGを構築するための私たちの用語であるKnowledge Baseの作成は、わずか数クリックで実現できます。使用するFoundation Modelを指定し、embeddingのタイプを設定し、ドキュメントが格納されているS3バケットを指定するだけで準備完了です。さらに、SharePointなどのWebクローラー用の複数のout-of-the-boxコネクタが用意されており、これらのサードパーティシステムからドキュメントを最初に抽出することなく直接利用できるようになりました。
しかし、私たちにとって最も重要なデータは、多くの場合、ドキュメントではなく、データベースなどの他のシステムに保存されています。先ほど、データを浄化してData Warehouseに準備するためのパイプラインの構築についてお話ししましたが、このような価値のある浄化されたデータも、Generative AIアプリケーションで活用できるようにしたいところです。これには、財務、マーケティング指標、キャンペーンコストと比較などについて質問に答えられるChatbotシステムの構築など、多くのユースケースがあります。標準的な分析の質問にSlack Chatbotで回答できれば便利ですし、これらの新しいGenerative AIアシスタントを通じて、他の人々が簡単にアクセスできるようなカスタムポータルアシスタント（社内用または外部用）を構築することもできます。
ドキュメントや非構造化データから、より構造化されたコンテンツに移行する際には課題があります。ドキュメントでは1つのドキュメントに答えが含まれている可能性がありますが、データベースではスキーマがあり、通常、すべてが複数のテーブルにわたって正規化されています。「先月の収益はいくらでしたか？」といった質問に答えるには、それをクエリに変換する必要があります。最初の重要な洞察は、自然言語からSQLへの変換、つまりリクエストをクエリに変換するプロセスは、本質的に構造化データに対するRAGと同等だということです。Embeddingsを通じて類似のドキュメントを見つける代わりに、リクエストに基づいてどのようにクエリを実行するかを決定する必要があります。
このプロセス自体はかなり難しいものです。例えば、gov.orgの公開データセットを使用して「テスト受験者が100人未満の国の学校数を数えて」という質問をした場合、Large Language Modelはクエリを生成するかもしれません。しかし、問題は、それが特定のスキーマと合致しない可能性があることです。正しく回答するには、異なるJoinやテーブル操作を実行する必要があるかもしれません。クエリに答えるには、異なるJoinテーブルが必要となります。
これらの課題に対処するには、コンテキスト、スキーマ、その他の要素を考慮してクエリを作成する方法をモデルに教える必要があります。データベースのテーブルとスキーマに合わせてパーソナライズする必要があります。例えば、「チェコ共和国のガソリンスタンドでの取引の商品説明をリストアップして」という質問があった場合、トレーニングデータに基づいてクエリを生成するかもしれません。ここでは、すでにスキーマについて教えていると仮定すると、チェコ共和国で国別にフィルタリングしていますが、実際には略語を使用して全く異なる方法でエンコードされている可能性があります。
これはデータベースでは非常に一般的です。カリフォルニアの収益を確認したい場合、収益がCaliforniaなのか、CAなのか、郵便番号なのか、それとも全く異なる方法でコード化されているのかを知る必要があります。スキーマだけでなく、データに合わせて本当にパーソナライズする必要があります。データベースごとに異なる動作と構文があります。SQLは標準ですが、SQLの方言があり、その動作と実装方法には違いがあります。エンジン自体についても認識させる必要があります。例えば、Redshiftでは、他のエンジンとは異なる方法で処理される可能性のある曖昧なカラム名の処理に関する特定の要件があります。
構造化データを一般的なAIアプリケーションの一部として利用可能にするには、これらすべての側面に対応したソリューションを構築する必要があります。これは多くの研究論文やベストプラクティスの提案を含む一大研究分野となっており、最適なソリューションを決定するためのベンチマークも存在します。しかし、適切な実装には多くのML専門家が必要となるため、お客様にとって課題となっています。今朝のSwamiのKeynoteで発表された Amazon Bedrock Knowledge Base for structured data storesは、Bedrockプラットフォームの一部として、自然言語からSQLへの変換を行うナレッジベースの構築を簡素化します。
私たちは、すべてのベストプラクティスをパッケージ化し、高精度を実現するための追加機能を実装して、マネージドサービスとして提供しています。これにより、構造化データへのアクセスが迅速になり、セットアップが簡単で、高い精度を実現し、カスタマイズオプションも備えています。また、セキュリティを確保し、SQLインジェクションを防ぐための保護機能も組み込まれています。処理の流れとしては、リクエストを自然言語SQLエンジンに転送し、そこでデータベースに送信するクエリを生成します。その結果は、従来のナレッジベースドキュメントと共にジェネレーティブAIアプリケーションの一部として利用され、会話履歴とともにモデルに戻されて最終的な回答が生成されます。
私たちの重要な戦略の1つは、履歴からクエリパターンを分析し、最も頻繁に使用されるカラムやそれらの結合方法を特定することで、高い精度に貢献しています。Amazon Bedrockでは、Amazon Redshiftを選択して認証情報を入力することで、構造化データを含むナレッジベースを作成できます。Redshiftインスタンスのタイプを選択し、エンドポイントから使用するカタログを選択することができます。また、より良いクエリ作成に役立つテーブルのセマンティックアノテーションの提供や、特定のテーブル名やカラムの包含・除外など、カスタマイズオプションも提供しています。
また、想定される典型的なユースケースを指定するクエリ例を提供することもでき、それらが確実に対応されるようにしています。これらの設定が完了したら、構造化ナレッジベースを作成します。次のステップは、この新しいベースがRedshiftの選択したテーブルにアクセスできるように権限を付与することです。これにより、選択と作成の権限が確保されます。これらが基本的な設定手順となります。同期メカニズムは、すべてのメタデータを取り込み、現在の履歴分析を開始します。これは自動的に行われますが、強制的に実行することもできます。次に、プロンプト生成に使用するモデルを選択すれば、テストの準備が整います。
生成的な秘密生成には、内部でモデルとGenerative AIを使用していることに注意が必要です。ここで選択するモデルは、主に最終的な回答を得る前にLLMに送信するプロンプトに使用されます。それ以外は完全なマネージドソリューションとなっています。このデモでご覧いただいたように、セットアップと開始までにかかった時間はおよそ2.5分で、今後さらに多くの機能が追加される予定です。
NexthinkのデータプラットフォームとAutopilotの構築
Moにバトンタッチしたいと思います。ありがとうございます、Tim。私はMo Haiderと申します。ヨーロッパのスイスからNexthinkについて、そして私たちのデータプラットフォームの取り組みと、それがどのようにしてGen AI製品を効率的に構築することを可能にしたかについてお話しさせていただきます。私はEngineering Leader、Principal Staffとしてシティオフィスに所属しており、私の仕事はシンプルです - アイデアを受け取り、それを実現することです。少なくとも、ほとんどの場合はそうです。Nexthinkのミッションは、テクノロジーに関する従業員の体験をシームレスで効率的、そしてより良いものにすることです。私たちは、従業員がデバイス、アプリケーション、そしてテクノロジー全般をどのように使用しているかを監視・分析するデジタルワークプレイス、観測・自動化プラットフォームを提供しています。
私たちは生産性に影響が出る前に問題を検知し、それを修正、改善するためのツールを提供し、将来同じ問題が発生した場合の自動化も行います。ITシステムを最適化するためのインサイトも提供しています。私たちは様々な業界や地域にまたがる顧客を持っており、その中にはみなさんもご存知の企業もあるでしょう。また、Accenture、Wiproなどの主要ITプロバイダーとパートナーシップを組んでサービスを提供しています。Nexthinkの強みは、データとAIの組み合わせにあります - クリーンで構造化され、アクセスしやすいデータと、人工知能によって生成される知識とインテリジェンスの組み合わせです。本日は2つの部分についてお話しします：私たちのデータプラットフォームと、それを使って第4四半期にリリースしたGen AI製品の1つであるAutopilotをどのように作ったかについてです。
データプラットフォームを構築する際、私たちには具体的な要件がありました。新しいデータの取り込みに関して高い成長性をサポートする必要があり、100万のエンドポイントから1～2年で3,000万から4,000万のエンドポイントをサポートできるように計画していました。さまざまなユースケースや製品に対して高頻度のデータ検索をサポートする必要があり、時系列クエリの後続クエリ速度もサポートしたいと考えていました。また、チームが一から作り直す必要がないよう、最小限の労力でリアルタイムのユースケースを実現できるようにしたいと考えていました。現在、2,000万以上のエンドポイントから毎秒500万以上のレコードがデータプラットフォームに送信され、時系列データベースには2.5兆行以上のデータが格納されており、100テラバイト以上のデータを占め、毎分100万以上のクエリを処理しています。
これらの要件に対応するため、私たちはいくつかの原則を確立しました。まず、可能な限りマネージドサービスを活用したいと考えました。これにより、チームはこの規模でのサービスの運用や管理ではなく、ビジネスロジックの構築とビジネス価値の追加に集中できます。また、サービスが私たちの要件に合わせてスケールすることも確認したいと考えました。レジリエンスは私たちにとって重要です - これは私たちのアーキテクチャ特性の1つなので、非同期通信を選択することにしました。
また、この負荷をすべて吸収し、よりスケールできるようにするため、可能な限りイベント駆動型アーキテクチャを採用しました。これらの異なるユースケースに取り組む40～50のチームがあり、それぞれが自分のドメインで作業できるようにしたいと考えていました。そこで、組織的にもアーキテクチャ的にもスケールできるようにするため、マイクロサービスを実装することにしました。
私たちがこのデータプラットフォームを構築する際、AWSの2つの主要なサービスを活用しました。各チームはマイクロサービスを構築し、AWSが提供するElasticサービス上にデプロイします。チームがサービスをデプロイすると、AWSが自動的に実行とスケーリングを行います。また、通信サービスと主要なストリーミングサービスとして、Amazon MSK（managed streaming for Apache Kafka）を使用しています。
データプラットフォームの仕組みと、データが取り込まれてデータベースに保存されるまでの流れについてご説明します。先ほど申し上げたように、2,000万台以上のデバイスが毎秒データを私たちのバックエンドに送信しています。このデータはプラットフォームのマイクロサービスに到達し、トピックに格納されます。私たちはデータレイヤーを構築し、このデータのクリーニング、エンリッチメント、変換を行い、さまざまなデータベースに保存できるよう準備してMSKトピックに格納します。用途に応じて異なるデータベースを使用しており、時系列のユースケースにはTime Seriesデータベース、リレーショナルデータにはAmazon Auroraを使用しています。
要件の1つとして、チームが簡単にデータにアクセスできるようにすることがありました。そこで、チームがプラットフォームサービスを使用してデータにアクセスできるよう、プラットフォームサービスの提供に力を入れてきました。チームはMSKにクエリを発行するだけで、これらのサービスがデータを照会し、準備して、ミリ秒単位でチームにストリーミング返却します。これらの詳細についてご興味がありましたら、AWSブログに記事を書いていますので、QRコードをスキャンして読んでいただくか、後ほどご質問いただければと思います。
このデータプラットフォームで私たちが迅速に進められた主な特徴を2つご紹介したいと思います。1つ目は、データがプラットフォームに到着してからデータベースに保存されるまで、ストリーム上のデータが構造化されているということです。Protocol Buffersのようなスキーマベースのプロトコルを使用して構造化されており、チームはマイクロサービスと一緒にカスタムリソースをデプロイすることでこのデータにアクセスできます。チームは関心のあるトピックとアクセスレベルを定義し、そのトピックを購読して直接データを取得できます。私たちはデータのデコード、復号化、匿名化解除を行うライブラリを提供しており、チームはそれらをアプリケーションで活用できます。
迅速な開発を可能にした2つ目の主な特徴は、データモデルです。データモデルは、ユーザー、デバイス、イベント、そしてそれらの関係性といった異なるオブジェクトで構成されています。その上に、NQ（Next Query Language）と呼ぶ統一されたクエリ言語を構築しました。これは基本的にパイプ言語で、必要なものを記述します：異なるオブジェクトやイベント、結合、そして関心のある計算プロパティなどです。このクエリ言語を顧客が利用できるようにしたことで、すべてのデータをほぼリアルタイムで照会し、数秒以内に結果を得ることができます。また、チームがNQを使用してデータにアクセスし、その上に機能を構築できるようにしました。
ご覧の通り、このデータプラットフォームを機能させる上でMSKは非常に重要な役割を果たしています。トラフィックは1秒あたり1～3ギガバイトの間を変動する大規模な使用量があり、システムには100万から200万以上のメッセージが流入してMSKによって処理されています。本番環境では、Gravitonベースのクラスターを13個デプロイしています。各クラスターには24個のBrokerがあり、3,000～4,000個のTopicと16,000個のPartitionを持っています。Kafkaに詳しい方ならお分かりかと思いますが、これはMSKが扱うTopicとPartitionの数としては実際かなり多いのです。
また、データ保持に関する要件もあります。Topicには最低12～24時間の保持期間が必要で、チームは1週間以上の保持期間を設定することもできます。本番環境では、Topicが1週間で5テラバイト以上に成長することもあります。これらすべてを処理し、スムーズに運用するため、この1、2年で幾つかの改善を行ってきました。まず、Graviton3インスタンスに移行し、これによりコストを削減し、パフォーマンスを15%向上させることができました。また、Rack Awarenessを実装し、これによってネットワークコストを削減することができました。
Rack Awarenessにより、Consumerは最も近いBrokerに接続することができます。理想的には、同じAvailability Zone内で、完璧な状況であればクロスゾーンのコストを支払う必要がありません。今年、MSKでTier Storageを有効にしました。これは基本的に、クラスターやBrokerのストレージをCold StorageとHot Storageに分割するものです。私たちのTopicの中には、データが一度だけ処理される必要があり、レジリエンス、信頼性、災害復旧のために保持しているものがあります。このデータをCold Storageに移動し、新しいデータのみをHot Storageに保持します。これにより、MSKのストレージコストを大幅に削減でき、MSKクラスターのパフォーマンスと運用も全般的に改善されました。
最新バージョンへの追従を心がけており、これによりバグが修正され新機能がリリースされることで、無料でパフォーマンスの向上が得られています。2、3年前に学んだ重要な教訓の1つは、プロアクティブなモニタリングが非常に重要だということです。サービスを監視し、必要に応じてプロアクティブにスケールできるよう、様々なMSKメトリクスに基づいてダッシュボードを構築することに時間を投資してきました。MSKは私たちにとって良いソリューションであり、ほとんどの作業を代行してくれます。これらの改善に取り組んでいたのは小規模なチームだけでした。他のプロバイダーと比較すると、私たちにとって良い価値を提供してくれています - 他のプロバイダーの3分の1のコストで、私たちの規模では数百万ドルの違いになります。
次に、Gen AIについて、そして私たちがこのデータプラットフォーム上にAutopilotと呼ばれるGen AI製品の1つをどのように構築したかについてお話しします。Nexthinkが提供している製品の1つにAutopilot（以前はAmplifyとして知られていた）があります。仕事中に問題が発生した場合、例えばSAPにアクセスできないような場合、ITチケットを起票することになります。サービスデスクのオペレーターがチケットを開き、Amplifyを使用して問題解決を試みます。そこでは、問題、アプリケーション、ネットワーク、その他の情報に関する様々なデータにアクセスし、サービスデスクシステムのブラウザ上で直接診断と修正を行うことができます。Amplifyはその場で自動化と修復機能を提供します。
Autopilotの機能と実装の詳細
これは、Gen AIソリューションを実装してユーザージャーニーやサービスデスクオペレーターの業務をより簡単に、より速く、チケット解決時間を短縮するための絶好の機会でした。これこそがAutopilot for Service Deskの役割です。システムに入ってくる全てのチケットに対して、オペレーターが行うべき作業を最小限に抑えることで、リアルタイムでの業務をサポートします。Autopilotは問題を要約し、考えられる全ての症状をリストアップします。サービスにアクセスできない場合、それはローカルネットワークやVPNの問題、あるいはサービスがグローバルにダウンしている可能性があります。Nexthinkではこれらのデータを全て保持しており、基盤モデルがこれらのデータを分析して、問題を素早く解決するための症状リストを提供します。
また、これらの症状に対する直接的な解決プランを提供し、Nexthinkの製品であるRemote Actionsとワークフローを使用してこれらを自動化します。さらに、問題が解決しない場合のために、インサイトや類似チケットのリストも提供します。これらのインサイトは、サービスデスクオペレーターが問題の所在を特定し、対処するのに役立ちます。チケットが流れてくると、それはMSKで利用可能になります。チームはGen AIアプリケーションを構築し、MSKを通じてこれらのチケット作成イベントを監視し、プロンプトエンジニアリングを使用し、NQLを使ってデータプラットフォームから問題、デバイス、ネットワークなどに関する全ての関連データをNQLを通じて取得します。その後、それらをLLMに渡して、様々な問題や症状をリストアップします。
このプロジェクトの開発と立ち上げの過程で気づいたことの1つは、LLMに大量のデータを送信していることです。基盤モデルに送るデータが多くなればなるほど、集中力が低下し、プロンプトの焦点が影響を受ける可能性があります。この問題に対処するため、全てのクエリを前処理しています。各クエリに対して、クエリを取得し、基盤モデルに渡してデータを要約し、最も重要なデータポイントを抽出するようパイプラインを実行します。その後、これらの重要なデータポイントをクエリプロンプトに渡すことで、より小さく簡潔なものとなり、基盤モデルからより正確な回答を得ることができます。
各チケットに対してどのクエリを呼び出すべきか、特に問題が多くのカテゴリーに分散している場合に、どのように判断するのか疑問に思われるかもしれません。問題はデバイスに関するものかもしれませんし、グローバルな問題かもしれません。あるいは、キーボードと椅子の間の問題（これは本当に解決できません）かもしれません。
私たちは、これらのケースに必要な事前定義されたNLクエリを持つ、いくつかのシナリオに焦点を当てたユースケースのサブセットから始めました。これが機能することを確認した後、システムをより柔軟にし、より多くのユースケースをカバーしたいと考えました。そこで反復を重ね、チケットの問題に基づいてこれらのクエリを生成し始めました。アプリケーションやWebアプリケーションに関する問題であれば、システムはこのカテゴリーに関連するクエリを生成します。これは、以前説明したものと非常によく似た、社内で作成したNL to QLと呼ばれる技術を使用して行っています。
NL to QLでは、問題文や質問を入力すると、ワークフローが自動的にクエリを生成して結果を出力します。クエリ生成の際には、私たちの複雑なデータモデルとスキーマを考慮する必要があります。これは、基盤モデルがSQLについては学習していても、私たちの特殊なクエリの扱い方を知らないためです。この課題に対して、私たちは馴染みのある手法を実装しました。まず、データの準備として、様々なデータモデルをEmbeddingし、Vector Storeに保存します。次に、異なるラベル付きの例をEmbeddingし、Vector Storeに保存します。これらの例には、専門家が作成したデータセット、基盤モデルを使って生成した合成データセット、そして最小化した本番データが含まれます。
クエリ生成のワークフローは、質問がシステムに入力されると開始されます。この質問をEmbeddingし、認識した上で、最も関連性の高い例を意味的に検索します。質問と例の両方をTokenize化し、最も関連性の高いテーブルやカラムを意味的に検索します。例えば、特定の日付におけるデバイスのクラッシュに関する質問であれば、意味検索によってCrashesテーブルやDeviceテーブルなどの関連テーブルが返されます。これらのデータを全て収集し、Promptとともに基盤モデルに送信すると、システムで使用するクエリが生成されます。
アーキテクチャを見ると、Ticketイベントが流れ、チームはKubernetesにデプロイされたMicroserviceを通じてビジネスロジックを実装し、データプラットフォームのクエリサービスを活用しています。Embeddingレイヤーでは、様々なデータセットをTokenize化し、Vector Storeに保存します。Amazon OpenSearch ServiceやAmazon Bedrockを基盤モデルとEmbeddingのプロバイダーとして使用しています。アプリケーションが結果を生成すると、それをMSKトピックに送信し、フロントエンドがアクセスできるようにデータベースに保存します。
NL to SQLは単純な問題ではなく、特に私たちのカスタムクエリ言語では多大な努力が必要です。ソリューションをローンチした後、いくつかの課題が明らかになりました。Promptが大きく密になり、一般的な指示、クエリ固有の指示、制約、操作、文章、RAGの例、スキーマの詳細などが含まれるようになりました。Promptが密になればなるほど、応答の精度は低下します。これらのPromptは特定のLLM向けに高度にチューニングされており、あるLLMから別のLLMに変更すると応答の質が低下します。バージョン間の移行でさえ、精度の低下が見られ、継続的なチューニングが必要になります。RAGアプリケーションでは、悪い例が大きな影響を及ぼします。
Promptに2つ、3つ、4つの例を提供する場合、1つか2つの悪い例があると基盤モデルが混乱し、予期せぬ結果につながる可能性があります。さらに、これらの基盤モデルは私たちのビジネスロジックや特殊な専門用語について学習していません。例えば、「Blue Screen」は基盤モデルにとっては単に青い画面を意味するかもしれませんが、私たちにとっては、特にWindows Vistaにおけるシステムクラッシュを表します。リリースしたこのシステムは単純な質問に対しては上手く機能しましたが、質問が複雑になるにつれて、クエリの精度が低下していきました。
このソリューションをローンチした後、私たちはシステムの改善を重ねていきました。Promptingと RAGは良い手法でしたが、私たちのニーズを完全に満たすものではありませんでした。そこで、Amazon SageMakerを使用してCodeLlamaモデルをベースにNQL生成に特化した小規模モデルを作成し、Fine-tuningを行いました。このモデルはよりコンパクトで優れており、簡潔な出力が可能です。指示を必要とせず、構文をよく理解し、スキーマが組み込まれており、5万件以上のデータセット例を記憶しています。自動化された Fine-tuningプロセス全体は2時間もかかりません。
チームは2～3週間ごとにモデルのTrainingやFine-tuningを行う能力を開発し、ベースモデルの切り替え、アップグレード、またはデータセットの追加を行っています。この機能をアーキテクチャに統合するため、SageMakerとその関連ツールを使用してAIレイヤーにFine-tuningレイヤーを実装しました。コード上では、Amazon Bedrockの基盤モデルを呼び出す代わりに、Amazon SageMakerのエンドポイントを呼び出すだけで済むようになり、クエリ生成の品質が大幅に向上しました。
データ集約とInsights生成：課題と解決策
Autopilotのもう一つの重要な側面である Insightsについてお話ししたいと思います。これは機械学習、異常検知、統計分析、GenAIなどの様々な手法を用いて生成する知見のことです。良質なInsightsを生成するには大量のデータが必要です。顧客データは私たちにとって重要でしたが、セルラーアーキテクチャには課題がありました。データのローカリティコンプライアンスを必要とする顧客が異なる地域にいるため、顧客の所在地に基づいてトラフィックをルーティングし、異なる地域にスタンドアロンのセルを展開していました。
複数のセルに分散したデータの課題に対処するため、データをData Lakeに集約しました。個人情報をソースに残しながら、異なるセルからデータを集中アカウントに安全に移動させています。S3に全てのデータを統合した後、様々なInsightsを生成します。時間の制約上、詳細なプロセスは説明できませんが、同僚がAWS Summitでこれについて詳しく発表しています。S3にデータが格納された後、Amazon GlueやEMR上のSparkなどのAWSアナリティクスサービスを活用してInsightsを処理・生成し、それらを3つのバケットに保存して異なるセル間でレプリケーションします。
このデータをデータプラットフォームにフィードバックし、様々なデータベースに保存し、後で取り出せるようAmazon OpenSearchにインデックスを作成します。全ての顧客データとInsightsを集中管理することで、内部ユーザーにこのData Lakeを公開する機会が生まれました。技術的知識の少ないユーザーには、Amazon QuickSightダッシュボードでデータの照会や可視化を提供しています。開発者などの技術的なユーザーは、Amazon Athenaを使用して複雑なクエリを実行できます。AWS CloudFormationを使用して適切なアクセス制御権を実装し、適切なデータアクセスを確保しています。QRコードをスキャンして詳細をご確認ください。ここでOdayに戻して、まとめに入りたいと思います。
はい、これで本セッションは終了となります。追加の参考文献はスライドに表示されていますので、お気軽に写真を撮ってください。夜の6時半までお付き合いいただき、ありがとうございました。Vegas Stripのどこかで、きっと美味しいディナーが皆さまをお待ちしていることと思います。質疑応答の時間は5分ほどありますが、ステージを降りて個別に対応させていただきたいと思います。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion