re:Invent 2025: OpenSearchの検索・可観測性・ベクトルデータベース最新機能とGPUアクセラレーション

はじめに

海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！

re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください

📖 re:Invent 2025: AWS re:Invent 2025 -What’s new in search, observability, and vector databases w/ OpenSearch (ANT201)

この動画では、AWSのCarl MeadowsとMukul Karnik、NVIDIAのCorey NoletがOpenSearchとOpenSearch Serviceの最新機能を紹介しています。OpenSearchは4年間で13億ダウンロードを達成し、Linux Foundationへの移行後も急成長を続けています。主要な発表として、OpenSearch Ingestionの機能強化、改善されたPPL（Piped Processing Language）によるログ分析、Automatic Semantic Enrichmentによるハイブリッド検索の簡素化が挙げられます。特に注目すべきは、NVIDIAとの協力によるGPUアクセラレーション機能で、cuVSライブラリとCAGRAアルゴリズムにより、10億規模のベクトルインデックスを1時間以内に構築可能になり、最大1兆スケールまで対応できるようになりました。さらに、S3 vectorsの統合、Auto Optimize機能、MCPサーバーによるagentic search機能、OpenSearch Optimized Instances（OR2、OM2）、derived source機能によるストレージ40%削減など、コスト効率とパフォーマンスの両面で大幅な改善が実現されています。

https://www.youtube.com/watch?v=-tahYYe9Zi8
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。

本編

OpenSearchとOpenSearch Serviceの概要：検索から分析まで幅広いユースケース

お集まりいただきありがとうございます。本日は、OpenSearchとOpenSearch Serviceの新機能についてお話しします。私はAWSでProduct DirectorをしておりますCarl Meadowsです。私と一緒に、後ほど登壇するDirectorのMukul Karnik、そしてNvidiaからCorey Noletが、彼らがどのようにOpenSearchをサポートしてくれたかについてお話しします。

本題に入る前に、このOpenSearchで何ができるのかについてお話しすることが重要です。OpenSearchは、多くのユースケースで非常に人気のあるプラットフォームです。まず第一に、名前が示すとおり、これは検索エンジンであり、検索アプリケーションを構築するために非常に人気があります。ますます多くの検索アプリケーションが、OpenSearchを検索バックエンドとして活用する生成AIやAI駆動型アプリケーションの基盤となっています。さらに、非常に柔軟なエンジンであり、データが高度にインデックス化されていて高速で、干し草の中から針を見つけることができるため、分析のユースケースでも非常に人気があります。オブザーバビリティ、セキュリティ分析、そして私がその場で集計や検索を行い、データに対する深い洞察を構築できるような一般的なリアルタイム分析のユースケースで非常に人気があります。

OpenSearchについてお話しするとき、実際にはOpenSearchを支えるオープンソーステクノロジーのセットがあり、そしてそれらのオープンソースプロジェクトに対して私たちが提供するAWSサービスがあります。お話しする主要なオープンソースの部分は、Data Prepperです。これはOpenSearchの前に配置される取り込みパイプラインで、オープンソースとしてとOpenSearch Ingestion Serviceとして提供しています。次にOpenSearch自体があります。これはエンジン、コアデータエンジンおよび分析エンジンで、Amazon OpenSearch Serviceと私たちのserverlessオファリングを通じて提供されています。データの可視化と探索のためのフロントエンドは、OpenSearch Dashboardsによって提供されています。サービスでは、これをOpenSearch UIとして提供しており、これは集中型のダッシュボードで、OpenSearch Serviceのドメインやコレクションのいずれにも接続できます。これについては後ほどお話しします。サービスについて詳しく説明する前に、オープンソースについて少しお話ししたいと思います。

オープンソースプロジェクトとしてのOpenSearchの成長：Linux Foundationへの移行と13億ダウンロードの実績

OpenSearchはオープンソースプロジェクトです。昨年、私たちはAWSが主要な管理者であることから、Linux Foundationへの移行を行い、本当に素晴らしい一年となりました。私たちはLinux FoundationでプロジェクトをサポートするためにOpenSearch Software Foundationを立ち上げました。私たちはプレミアメンバーです。最近、IBMがプレミアメンバーとして参加しました。他にも多くのコミュニティメンバーがこのプロジェクトのサポートを手伝ってくれています。プロジェクトをサポートしている人々は、実際にはプロジェクトに貢献している人々やプロジェクトの実際のメンテナーとは独立しています。誰でも参加でき、技術的なメリットがプロジェクトのガバナンスを推進します。これらの人々は、イベントをまとめたり、トレーニングを行ったり、OpenSearchについての情報を広めて、広範で活気のあるコミュニティを確保するのを手伝ってくれている人々です。昨年、私たちはOpenSearchで達成した進歩に本当に興奮しています。

最初のフォーク以来、現在13億ダウンロードに達しており、これは4年間で非常に多い数です。昨年は、400の異なる組織から3,000以上のアクティブな貢献がありました。貢献の数だけでなく、プロジェクトに寄せられ始めている深く意味のある貢献が、プロジェクトに対する多くの興奮と勢いを本当に推進しているのです。

ご覧のように、ユーザーコミュニティは世界中で立ち上がっています。もしこれらの地域にお住まいでしたら、ユーザーコミュニティを検索して見つけることができますし、地域のイベントに参加して、OpenSearchに興味を持つ他の方々と交流することができます。もしそこに該当する地域がない場合は、私たちにお声がけください。ユーザーカンファレンスの立ち上げをお手伝いできます。このコミュニティが成長しているのを見るのは本当にワクワクします。

なぜ人々がOpenSearchに惹かれているのかを考えると、コア検索エンジンやコア分析エンジンとして、ビジネスにとって重要なプラットフォームを選ぶということは、これは複数年にわたる賭けなんです。大きな投資をするわけですから、それがイノベーションを起こしていて、持続可能であると感じることが本当に重要です。このイノベーションは、毎年OpenSearchに搭載できるようになった、どんどん意義深い機能を見ていただければわかるように、これが自分たちが賭けたい馬だという確信を人々に与えていると思います。

このオープンソースプロジェクトに参加することで、これらすべてのイノベーションを無料で手に入れられるわけですから、これが関わりたいプロジェクトなんです。ですから、OpenSearchが向かっている方向と、そこで私たちが行っているすべてのことに本当にワクワクしています。

もう一つの理由は、 forkを開始して以来、エンジンを深く見直して、パフォーマンスを本当に改善する方法を探ってきたことです。より安く、より速く、より回復力のあるデータエンジンで失敗することはありません。基本的にforkを開始した時点である1.Xラインから、サービス上の最新リリースであるバージョン3.3まで—実際には最新リリースは3.4ですが、あと数週間でリリースされます—全体的な検索とアグリゲーションで11倍の改善を達成しました。また、ベクトル検索機能では2.5倍の向上も見られました。まだ終わりではありませんので、機能を増やしながら、より高い効率性、より良いパフォーマンス、より低いコストをエンジンで実現し続けていきます。これについては後ほど詳しくお話しします。アップストリームで起こっていることに本当にワクワクしています。

Amazon OpenSearch Service：10万以上のアクティブ顧客と月間10兆リクエストを支える運用のシンプルさ

ここAWSでは、そのプロジェクトを取り入れて、Amazon OpenSearch Serviceとして皆さんにお届けしています。 少し偏っているかもしれませんが、これはオープンソースプロジェクトを利用する絶対的に最高の方法だと思います。サービスをラップして、運用のシンプルさを提供し、オープンソースで得られるすべての機能とメリットを、管理の苦労なしで提供します。コスト効率を提供し、AWSエコシステムに深く統合されているため、AWSの他の運用に統合するのが非常に簡単です。

ご覧のとおり、現在10万以上のアクティブなお客様がこのサービスをご利用いただいています。このサービスでは月間10兆件以上のリクエストを処理しています。セルフマネージドパッチング、ワンクリックアップグレード、24時間365日のモニタリング、セルフヒーリング、そしてダウンタイムなしでご利用いただけます。ボタンをクリックするだけで、ダウンタイムなしにトポロジーを完全に変更できます。ブルーグリーンデプロイメントを実行して、完全に新しい環境に移行します。きめ細かなアクセス制御、暗号化キー、監査ログなど、エンタープライズグレードのアプリケーションを実行するために必要なすべての深いセキュリティ機能を提供します。単一クラスターで最大4ナインのSLAを持つマルチAZデプロイメントをサポートしています。また、優れた経済性を提供するために、オープンソースの上に多くのイノベーションを構築してきました。例えば、UltraWarm機能や、これからお話しするOpenSearch Optimizedインスタンスのような特殊なインスタンスタイプなどです。これらは完全に回復力のある環境を提供します。ですから、OpenSearchを実行するなら、私たちが最適な場所だと信じています。

Data PrepperとOpenSearch Ingestion：サーバーレスでデータ取り込みを簡素化する新機能

それでは本題に入りますが、ランドスケープを最もシンプルに考えると、ドキュメント、ログ、またはトランザクションシステムの形式である大量のデータがあります。それは埋め込み、画像や動画、そして今では他のものもここに含めることができます。そのデータを取得し、処理して、最終的にOpenSearch Serviceに配置し、OpenSearch Serviceからエンドカスタマーにユースケースを提供したいと考えています。

最初の部分、データ取り込みの部分についてお話しすると、Data PrepperとOpenSearch Ingestionサービスについて触れました。これは非常にシンプルなサーバーレス機能で、ソースを選択できます。データのバッファリング、処理、変換を提供し、そのデータをOpenSearchに、マネージドクラスターまたはサーバーレスコレクションに同期します。また、Amazon S3にもデータを同期できます。すべての生データをS3に送り、集計だけをOpenSearchに入れたいといったルーティングを行いたい場合にも対応できます。OpenSearch Ingestionで非常に簡単に実行できます。

昨年OpenSearch Ingestionで行ったことのいくつかですが、 これはサーバーレス製品だと申し上げましたので、OpenSearch Compute Unitsによって動作します。何もプロビジョニングする必要はありません。これらは自動的にプロビジョニングされ、処理しているトラフィックに基づいてスケールアップおよびスケールダウンします。追加コストなしでメモリを15ギガバイトに増やしましたので、最大規模の集計や複雑な計算ジョブでも、追加のパイプラインをスケールアウトすることなく、これらのパイプライン上で実行できます。また、より多くのシグナルを取得することで、さまざまなタイプの需要の変化により迅速に対応できるように、オートスケーリングを強化しました。

OpenSearch Ingestionの機能全体を見ると、サポートしている幅広いソースがあることがわかります。プッシュソースとプルソースの両方をサポートしているため、HTTPエンドポイントやOTELエンドポイントを通じてプッシュできますが、DynamoDB、DocumentDB、RDS Aurora、RDS Postgres、Elasticsearch自体、OpenSearch自体などのシステムからプルすることもできます。最も人気のあるユースケースの1つは、実際にS3からデータを取り出してOpenSearchで処理することです。

RDSとAuroraのサポートを追加しました。また、JiraとConfluentのコネクタも追加しました。そして、OpenSearchにデータを取り込むのを本当に簡単にするために、コネクタを追加し続けていきます。データがパイプラインに入ったら、そのデータに対して大量の処理を行うことができます。エンリッチメント、エントリの選択、条件付きルーティング、ドロップ、集約、そしてOTEL処理を実行できます。今年、Lambdaプロセッサを追加しました。これにより、そのデータストリームに対してLambda関数で書けるあらゆる処理を呼び出して実行できます。これらのプロセッサがどれも機能しない場合や、何か別のことをしたい場合は、そのLambdaを活用してサービス外の別のデータソースからデータをエンリッチすることもできますし、カスタムコネクタを書くこともできます。

また、バッチAI推論も追加しました。これにより、このパイプラインから埋め込みを構築するのが非常にコスト効率的になります。そして、先ほど述べたように、そのデータをマネージドクラスター、サーバーレスコレクション、またはS3に同期できます。今年ローンチしたもう一つの機能で、本当に使いやすさが向上したと思うのは、ガイド付きのビジュアルワークフローを提供する改善されたユーザーエクスペリエンスです。実は、誰もがYAMLを書きたいわけではないんですね。ですから、これらのプロセッサの設定を簡単にすることで、パーミッションが正しく設定されていること、プロセッサが適切に構成されていることを高い確信を持って確認でき、数回のクリックで、これらのパイプラインを構築しながら、データが望む形式で配信されるようになります。

ログ分析の進化：OpenSearch UIとPPLクエリによる単一ペインオブグラスの実現

さて、それでは、Mukulに引き継ぎます。彼がログについて説明してくれます。ええ、ありがとうCarl。皆さん、聞こえていますよね?はい、いいですね。Carlの話で印象的だったことの一つは、OpenSearchで見られている圧倒的な勢いです。4年間で13億ダウンロードに到達するのは偉業ですから、プロジェクトは本当に急速に成長しており、その勢いはさらに加速しているのが見て取れます。本当にそれを見るのは嬉しいことです。

ログについて、そしてその後検索について話す前に、ログのユースケースでOpenSearchを使ったことがある方がどれくらいいるか知りたいと思います。なるほど、何人かいらっしゃいますね。では、検索ベクトルはどうでしょうか?なるほど、検索ベクトルの方が多いですね。それは良いことです。さて、ご存知のように、ログデータは増え続けています。そして、生成AIとエージェントによって、さらに増加しています。では、なぜ私たちはこのすべてのデータを収集するのでしょうか?このすべてのデータを収集するのは、ソフトウェアにはダウンタイムが発生するからです。そして、ダウンタイムが発生したときには、MTTR、つまり平均応答時間を短縮してオンラインに復帰したいのです。そのためには、デバッグして根本原因に素早く到達する必要があり、だからこそその根本原因に到達するためにすべてのテレメトリが必要なのです。

確かGartnerが数年前に調査を行い、平均して企業は87時間のダウンタイムがあり、約360万ドルの収益または売上の損失を被っていることがわかりました。ですから、そのダウンタイムを削減し、根本原因に素早く到達することが本当に重要なのです。そのためには、通常単一のペインオブグラスが必要です。ログデータは異なる場所に存在することがあります。一部のデータはCloudWatchにあり、一部のデータはOpenSearchにあり、そして一部のデータはS3にあります。なぜなら、インデックスを作成するにはコストがかかりすぎるからです。

昨年私たちがローンチしたのはOpenSearch UIです。これはOpenSearch Dashboardsのオープンソースプロジェクトを、フルマネージドなSaaS体験として提供するものです。現在はOpenSearchだけでなく、複数のOpenSearchクラスターに接続できるだけでなく、CloudWatchのデータにも接続でき、S3やSecurity Lakeのデータにも接続できます。そして、この1つのエンドポイントから単一のビューで、データを1つのダッシュボードで可視化できるようになっています。

これは本当に強力な機能です。なぜなら、データは異なる場所に存在していて、それを1つの場所に集めるのはコストがかかるからです。これらはCloudWatch統合やSecurity Lake統合のような、私たちがローンチした新しい機能のセットです。また、OpenSearch Dashboards UIの体験も改善してきました。では、ここにいる皆さんの中で、Discover体験に馴染みのある方はどれくらいいらっしゃいますか？あまり多くないようですが、私たちはこの体験を本当に改善してきました。そして、改善した主要な領域は、PPLクエリというクエリを入力できるようにしたことです。PPLが何かについては後ほど説明します。可視化とログの両方を取得できるので、ログという生データを取得することもできますし、集計や可視化を取得することもでき、このインターフェースでログ内のトレンドをかなり素早く取得できます。

そして、ここでの主要な力は、私たちが実装したPPLクエリです。PPLはPiped Processing Languageです。さまざまな種類のコマンドをサポートしています。検索、重複排除、そして基本的にログデータを抽出、フィルタリング、変換するためのあらゆる種類のコマンドです。これにより、ログを深く掘り下げて、探している洞察を得ることができます。そして、この1年間、私たちはPPL機能の改善に多くの注力をしてきました。多くの新しい分析機能をPPLに追加しました。インデックスを結合する機能を追加しました。つまり、2つの異なるインデックスにログデータがある場合、PPLを使ってそれらを結合できるようになりました。追加のルックアップやフィルターもできるので、かなり強力な機能セットです。

今年だけで約39の異なる機能をローンチしました。そして、先週リリースされたOpenSearch 3.3バージョンでは、これらすべての機能が利用可能になっています。これを試してみるには本当に良いタイミングだと思います。それでは、新しいダッシュボード体験とDiscoverやこれらのPPL機能が、ログの中で探しているものにどのように到達できるかのデモに移りたいと思います。こちらが昨年後半にローンチした新しいOpenSearch Dashboards体験です。それ以来、私たちはこれを改善し続けています。ワークスペースという概念があります。ワークスペースはコラボレーションの単位だと考えてください。チームがあって、オブザーバビリティのユースケースでコラボレーションしたい場合、オブザーバビリティワークスペースを作成できます。

Security AnalyticsやSearchワークスペースのような他のワークスペースもありますが、オブザーバビリティワークスペースをクリックして、どのように変わったか見てみましょう。クリックすると、新しくデザインされたDiscover体験に到達します。上部にはPPLコマンドを入力できる場所があり、そこから素早くログを見て、それらのログ内のデータのトレンドを可視化できます。これが大まかな仕組みです。では、何か問題が発生しているとしましょう。その場合、PPLクエリを素早く入力して、ログ内のエラーを検索できます。それが実質的にやっていることです。そのクエリを入力すると、可視化できます。なるほど、これが私のログ内のいくつかのエラーですね。そして、AI summaryをクリックして理解できます。LLMによって要約された、ログで何が起こっているかのビューです。

それを読み進めていくと、すぐに気づくと思いますが、ログ内のエラーが実際にはbodyメッセージの中にネストされていて、何が起こっているのかをデバッグするのが難しくなっています。そこで、bodyからエラーメッセージを抽出したいと思うわけです。そこで、PPLコマンドを更新して、ログに含まれているJSONオブジェクトからフィールドを抽出することができます。この更新されたコマンドによって、ログ内のすべてのエラーをより正確に特定できるようになります。つまり、最初は多くの異なるログメッセージがあるように見えましたが、結局はこのターゲットエラーメッセージに集約されるということがわかります。そこで次に、わかりました、エラーが発生しているようですが、これは大きな問題なのかどうかを把握したいと思います。そこで統計を取ることができます。すぐに統計を取って、これがどのくらいの頻度で発生しているのかを調べると、7万回も発生していることがわかります。これは重大な問題ですので、おそらく何が起こっているのかを知りたいと思うでしょう。では、次に何をしますか? 理想的には

この問題を引き起こしているサービスを特定し、そのサービスのオーナーにどうやって連絡を取れるかを知りたいわけです。このログデータを、おそらく持っているであろうサービスメタデータと結合することができます。そうすることで、これらのエラーメッセージは実際にはロードジェネレーターサービスから来ていることがわかります。つまり、本番システムほど重要ではないかもしれませんが、それでも何がこれらのエラーを引き起こしているのかをすぐに特定できます。

そして、これらのエラーメッセージを取り出して、いつ始まったのかを調べることができます。時間範囲を設定して、これらのエラーメッセージが特定の時刻に始まったことを確認し、それを使ってサービスのオーナーに連絡して解決してもらうことができます。また、ここで生成したビジュアライゼーションをダッシュボードに追加することもできます。そうすれば、次回は直接ダッシュボードに行ってエラーを確認できます。これは非常に強力な方法で、システムで発生しているエラーの根本原因にたどり着き、PPLを使ってデバッグすることができます。

さて、多くのユーザーはPPLに慣れていないので、自然言語もサポートしています。これは非常に直感的で、自然言語でクエリを入力するだけでPPLが生成され、もちろんレスポンスも返ってきます。私たちが取り組んでいることの一つは、MCPの機能をOpenSearchに追加することです。これについては後ほど少しお話しします。OpenSearchバックエンドがあって、例えば、すべてのログやさまざまなシステムを調べるエージェントを構築した場合、OpenSearchのMCPサーバーを使用して、これらの自然言語の質問やPPLの質問を渡すことができます。豊富な分析機能、すべての関数、結合、これらすべてがそのMCP統合を通じて利用可能です。そのため、OpenSearch Dashboardsと対話することなく、根本原因に非常に迅速にたどり着くことができます。つまり、ログのデバッグに活用できる非常に強力なコア機能です。

検索の変遷：キーワードからセマンティック、ハイブリッド検索へ、そしてAutomatic Semantic Enrichment

以上がログの概要です。多くの改善が行われており、来年にかけてもさらに多くの改善が予定されています。OpenSearchをログに使用したことがない方は、ぜひ検討してみてください。次に、検索と検索とAIについてです。生成AIには多くのイノベーションが起こっており、多くの興奮があり、多くの新しいモデルが登場しています。そして、この生成AIの世界では検索が変化しています。考えてみると、検索の問題は、その核心において情報検索の中心的な問題です。さまざまな種類の情報があり、ドキュメントがあり、画像があり、動画があります。検索の目標は、本当にその情報を抽出して、インサイトを素早く得られるようにすることです。そのためにはいくつかのテクニックがありますよね。約20年前を振り返ると、キーワード検索が大きな存在で、キーワードを入力して関連情報を見つけることが本当に便利でした。

そして機械学習モデルが登場すると、セマンティック検索ができるようになりました。これにより、完全に一致するキーワードだけでなく、意味的に類似した文章も見つけられるようになったんです。つまり、データから意味的に関連性の高い情報を取得するのに非常に役立つようになりました。その後、実はキーワード検索が70～80%のユースケースで非常にうまく機能することがわかってきました。そこで、キーワード検索とセマンティック検索を組み合わせて、ハイブリッド検索を開発することが、検索における次のイノベーションとなったわけです。最近では、多くのお客様でハイブリッド検索の導入が進んでいます。多くのお客様が、社内システムのデータ検索であれ、外部向けのユーザーアプリケーションの動力源であれ、あらゆる種類のユースケースでハイブリッド検索を使用しています。つまり、さまざまなシステムでハイブリッド検索が幅広く使われているということです。

また、お客様がOpenSearchを新しいユースケースで使用しているのも見られます。例えばagentic searchでは、OpenSearchで利用可能なデータだけでなく、OpenSearch外の他のシステムのデータも活用したいというニーズがあります。これらすべての詳細については後ほど説明しますが、このように検索は進化しており、非常に短い期間で多くのイノベーションが起きているんです。では、最近の典型的な検索ワークフローを見てみましょう。

データや情報、画像、ドキュメントがあります。これを取り込んで、通常はOpenSearchにインデックス化します。また、機械学習モデルを使用してベクトル埋め込みを生成し、そのベクトル埋め込みをOpenSearchに保存します。つまり、レキシカルインデックスとベクトルインデックスがあり、その情報をOpenSearchに保存するわけです。そして、クエリを受け取ると、これら両方のインデックスを使用して関連するドキュメントを取得し、必要に応じて再ランキングを行い、それらのドキュメントや結果をユーザーに表示します。これが私たちが目にする典型的な検索ワークフローです。

課題は、これがかなり複雑だということです。どのモデルを使用するか、モデルをどうホストするかを考え、それからこれらすべての埋め込みを生成し、レキシカルインデックスと一緒に別のインデックスに保存し、そしてこれらの結果を直感的な方法でどう組み合わせるかを考えなければなりません。つまり、かなり複雑なセットアップなんです。

最近私たちがローンチしたものの一つが、Automatic Semantic Enrichmentです。これは、お客様のユースケースに対する、すぐに使えるセマンティック検索とハイブリッド検索の機能だと考えてください。この場合、単にドキュメントをOpenSearchに送信するだけです。バックグラウンドでは、私たちがホストして管理しているスパースニューラルモデルを使用し、ベクトル埋め込みと意味的に強化されたドキュメントを生成して、お客様のデータと一緒に保存します。つまり、ホスティングについて心配する必要はありませんし、インデックス化していないときにGPUの料金を支払う必要もありません。従量課金制ですが、ドキュメントを強化してくれます。そして、クエリを実行するときには、意味的に強化されたインデックスを活用して、より良い検索結果を得ることができるんです。

私たちのテストで確認したこと、そして様々なベンチマークを使用してきましたが、このテクニックは実際に他の既存のembeddingモデルと比較しても非常に優れたパフォーマンスを発揮します。ですので、アプリケーションでsemantic searchやhybrid searchを始めるには本当に簡単な方法なんです。もしこれらのテクニックを何も使っていないのであれば、始めるのに非常にシンプルな方法があります。

それでは深く掘り下げて、このsemantic enrichmentがどのように機能するのか理解していきましょう。テキストドキュメントがあるとします。この例では、昨年開催されたCricket World Cupを取り上げていて、それに関連する多数のドキュメントがあります。インジェスト時、これらのドキュメントをインジェストする際に、機械学習モデルを呼び出して語彙を拡張し、ドキュメント内にあるものと意味的に類似した単語を生成し、それを通常のデータやインデックスと一緒に保存します。クエリが来ると、この意味的に強化された、シノニム辞書のようなものと考えていただければいいのですが、これを活用して、ユースケースに対して本当に関連性の高い結果を提供することができるんです。ですので、これは非常に強力なテクニックであり、検索結果の精度を向上させるための非常にシンプルな方法です。

ベクトルエンジンとしてのOpenSearch：1兆スケールへの対応とS3 vectorsによるコスト最適化

それでは、OpenSearchをvector engineとしてお話ししましょう。これらすべての機械学習モデルはvector embeddingsを生成しますが、このvector embeddingsをどこかに保存したいわけです。そしてOpenSearchは最近非常に人気のあるvector databaseなんです。その理由は、私たちは2019年にOpenSearchでvector機能の構築を始めました。当時はパーソナライゼーションや類似検索のような機械学習のユースケースは非常に少なく、おそらく1000万個のvectorsで十分でした。OpenSearchはそこから始まったんです。年月が経ち、2021年と2022年には、それが10億vectorsまで成長し、当時存在していたBERTのようなモデルをより多くサポートするようになりました。それでもまだ比較的小規模なサイズでした。

そして2023年と2024年に、Generative AIが本当に人気になるにつれて、より大規模なワークロードのユースケースが多く見られるようになり、OpenSearchは現在最大1000億vectorsまでサポートしています。AmazonのFraud Detection SystemはOpenSearchを使用して最大700億vectorsを扱っており、OpenSearchが非常に優れたスケーラビリティを発揮する、かなり大規模なユースケースとなっています。

さらに最近では、多くのお客様がすべてのドキュメントに対してインデックスを作成し、vector embeddingsを生成したいと考えているのを目にします。これは理にかなっています。なぜなら、これらのモデルはすべて非常に強力で、データから最大限の価値を引き出したいと考えるからです。そのためには、これらのvector embeddingsを生成する必要があります。現在、OpenSearchでは最大1兆スケールまでサポートしており、vector embeddingsを使用する大規模なユースケースにとって非常に有用です。

しかし、そのような規模でそれを行うのはコストがかかる可能性がありますよね？ ですから、コスト効率の良い方法で、かつ迅速に行う必要があります。コスト効率よく行うには、もちろん、すべてのデータをメモリに配置して完全なK-NN検索を使用すれば、最良の結果が得られますが、最もコストがかかります。次にできることは、近似手法を使用し、データは引き続きメモリに保持することです。この近似手法により、使用するデータ量と計算量を削減し、コストを削減できます。

そして今年の初めに、ベクトルデータをディスクに保持し、量子化されたデータのみをメモリに保持するディスクモードを導入しました。これによりコストをさらに削減できます。そして昨日、S3 vectorsの一般提供とOpenSearchとS3 vectorsの統合を発表しました。これにより、ベクトルデータをすべてS3に保持でき、コストをさらに削減できます。このように、兆規模に到達するにあたって、コストを削減してその規模に到達するためのさまざまな方法があります。

では、ディスク最適化ベクトルモードを見てみましょう。 この仕組みは、高次元ベクトルを取得し、さまざまなバイト量子化技術を使用して、より低い精度のベクトルを生成します。そうすると最大16倍または32倍の圧縮が得られ、これらのベクトルをメモリに保持し、高精度ベクトルはディスクに保持します。そしてクエリを受け取ると、まずバイト量子化されたベクトルに対してメモリ内でK-NN検索または近似検索を行い、10件の結果ではなく、おそらく1,000件の結果を取得します。そしてその1,000件の結果に対して、正確な高精度ベクトルを取得し、完全なK-NNを実行します。

このように、2パス方式ですが、それでも求めている高いリコールが得られ、すべてのデータをメモリに保持する必要はありません。唯一の注意点は、レイテンシーが少し増加することです。ですから、ワークロードが少し高いレイテンシーに耐えられる場合は、これはかなりうまく機能します。

もう一つの方法は、先ほど発表したS3 vectorsを使用することです。S3 vectorsには2種類の統合があります。一つは、 クラスターをプロビジョニングし、OpenSearchでベクトルエンジンとしてS3エンジンを選択できるようになりました。S3を選択すると、ベクトル埋め込みを送信した際に、OpenSearchに保存する代わりにS3に保存します。レキシカルインデックスはOpenSearchに保持できます。このようにして、ベクトル埋め込みはS3に、レキシカルインデックスはOpenSearchにあり、クエリを受け取ると、S3を使用してベクトル検索を実行できます。OpenSearchを使用して通常の検索を行い、これらの結果を組み合わせて、ハイブリッド検索を実行し、S3 vectorsの低コストを享受しながら、OpenSearchの豊富な機能をすべて利用できます。

これは、高いスループットを必要としないユースケースに非常に適しています。より高いスループットの場合は、すべてのベクトルデータをOpenSearchに保持することをお勧めしますが、低から中程度の秒間クエリ数のユースケースでは、S3ベクトルを使用することでコストの改善が得られます。これがS3ベクトルを使用する一つの方法です。

S3ベクトルを使用するもう一つの方法は、S3にあるデータを保持して、それをOpenSearchに取り込むことです。例えば、最新のデータのみ、または特定のカテゴリやセグメントのデータのみをOpenSearchに取り込んで、それをベクトル検索に使用することができます。この方法では、すべての情報をOpenSearchに取り込む必要がなく、これがOpenSearchとS3ベクトルを組み合わせて使用するもう一つの方法です。これらが利用可能な2種類の統合方法です。

NVIDIAとの協業：cuVSとCAGRAアルゴリズムによる1兆ベクトルスケールの実現

それでは、Coreyに登壇してもらいたいと思います。彼はNVIDIAがどのようにOpenSearchをオーストラリアンベクトルまでスケールさせるのを支援したかについて話してくれます。素晴らしい、ありがとう、Mukul。皆さんこんにちは、私の声が聞こえる方は手を挙げていただけますか?簡単な音声チェックです。素晴らしい。いいですね、この席が満席のままです。はい、Corey Noletです。私はNVIDIAでベクトル検索と様々な機械学習ライブラリのプリンシパルアーキテクトをしています。

ベクトルが今日のAIの言語であることは驚きではありませんよね?非構造化データは、Mukulが指摘したように、1兆ベクトルスケールがより一般的になってきています。ほんの6ヶ月前でさえ、1兆スケールという言葉を2、3の異なる組織から聞くことがあり、3、4ヶ月に1回くらいの頻度でした。今では文字通り毎週聞いています。人々は本当にこれに注目しています。多くの組織が様子見をしている段階で、これが本当に増加傾向にあるのを目の当たりにしています。1000億スケールに到達できれば、1兆スケールに到達できますよね?100億スケールに到達できれば、1000億スケールに到達できます。ですから、2017年頃から見てきた成長は指数関数的なものでした。

多くの人が気づいていないこと、そしてMukulもこれに触れていましたが、ベクトル検索インデックスは従来のデータベースインデックスとは異なるということです。それらは近似的であり、何かを近似的にすると、それをモデル化しなければならないということになります。つまり、それは何らかの機械学習モデルになるということです。従来のデータベースインデックスでは、適切にチューニングしなくても、正しい結果は得られます。ただ、少し遅くなるかもしれないというだけです。ベクトル検索モデルでは、トレードオフを考慮しなければなりません。より正確なモデルを求めると、必ずしも最高のインデックス作成スループットが得られるとは限りません。必ずしも最高の検索スループットが得られるとは限りません。そして、これらのトレードオフを行わなければなりません。さて、これらのトレードオフはかなり高コストになる可能性があります。コストとパフォーマンスの両方に大きな影響を与える可能性があります。これが重要なポイントです。そして、GPUを活用することで、これらのトレードオフのいくつかに対処し、より管理しやすくすることができます。よりコスト効率的にすることができます。より高いパフォーマンスにすることができます。特に1兆スケールにおいてはそうです。

そして、AWS OpenSearchチームとのパートナーシップは、私たちが直面しているこれら4つの課題を中心に形成されました。これから8分ほどかけて、これら4つの課題に対処するために私たちがどのようにソリューションを構築したかをご説明します。最初の課題はインデックス構築ですね。1兆個のベクトルをインデックス化し、1兆個のベクトルのための機械学習モデルを構築するには、想像できると思いますが、非常に長い時間がかかります。必ずしもすべてのケースで線形にスケールするわけではありませんからね。相互運用性も大きな問題です。多くの方が気づいていないことですが、エージェント型AIやRAGワークロードでは、少なくとも現在の技術では、実際のベクトル検索のルックアップがボトルネックになることはあまりないんです。LLMが混在していて、そのLLMで推論するために別のリモートサービスに接続する場合、あるいはLLMがローカルにあって数百ミリ秒かかる場合でも、それは通常ベクトル検索よりも桁違いに長い時間がかかります。もし私がベクトル検索をゼロ時間で実行できたとしても、何も得られないわけです。ですから、その期間にGPUを割り当てて、ほとんどの時間アイドル状態にしておくのは意味がありません。そのため、相互運用が可能であること、つまりGPU上で非常に高速にインデックスを構築でき、検索にGPUを使うことを強制しないことが重要なんです。

Mukulも指摘したように、混合型も大きな問題です。私たちはセマンティック検索だけを行うことは少ないんです。構造化検索を行い、それをセマンティック検索と組み合わせて結果を改善したり、あるいは単に結果を得るために必要な場合もあります。例えば、特定の境界ボックス内の地理座標から検索し、セマンティック検索を行う前に特定の年齢層でフィルタリングする必要があるかもしれません。そしてもちろん最後がコスト効率です。GPU上でこれを実行するために多くのお金を費やす必要はありません。本当に両方をうまく組み合わせたいんです。そこで私たちは過去数年間、AWS OpenSearchチームと協力して、これら4つの課題を解決してきました。

それでは、ソリューションをこのような階層化されたスタックにまとめてみます。まずインデックス構築から始めますが、これはおそらくNVIDIAを示す緑色として認識されると思いますので、GPU上で実行されることを意味します。数年前、私たちはcuVSというライブラリを作成しました。これはCUDA Vector Searchの標準的なCUプレフィックスを使用しています。なぜ別のライブラリが必要なのか？CUDAは書くのが難しい場合があります。難しいので、コストがかかることもあります。非常に低レベルになることもあります。CUDAでアルゴリズムを最適化するのに多くの時間を費やし、そして新しいアーキテクチャが登場していくつかの新しい命令が導入されます。新しいライブラリが優れた抽象化とともに登場します。そうすると、コードを書き直したりリファクタリングしたりする必要があり、常にこのキャッチアップゲームをプレイし続けることになります。ですから、棚から取り出せるライブラリがあり、ベクトル検索を実装するためのビルディングブロックを提供できることの大きな利点の一つは、それがアプリケーションで直接使用される場合でも、データベース内で使用される場合でもです。

これにより、GPUの製造元やCUDAバージョンの作成者が今後これを維持し、ハードウェアとソフトウェアから常に最高のパフォーマンスと最高のコスト効率を得られるようにすることができます。完全にオープンソースでApache 2ライセンスです。目標は、ビルディングブロックとエンドツーエンドのアルゴリズムの両方を提供することで、アプリケーションで使用できるだけでなく、データベースに統合することもできます。私たちは、CUDA開発を行っている方ならおそらく慣れているであろう、すべての基礎ライブラリの上に構築しています。

現在多くの方が使用しているアルゴリズムのほとんどは、特に多くのデータベースで既製品として使用されているものは、CPU上で動作しています。私たちはこれを変えようと取り組んでいますが、今日使用しているアルゴリズムのほとんどはCPU上で動作しています。標準的なアルゴリズムの一つがHNSWアルゴリズムで、グラフベースのアルゴリズムで非常に高速な検索が可能ですが、構築はそれほど速くありません。HNSWは基本的にGPU中心のアルゴリズムではありません。グラフへの挿入の低レイテンシを実現しようと、中央集権的なデータ構造に対してロックする複数のスレッドを利用します。私たちは少し原点に戻る必要があり、CAGRAと呼ぶアルゴリズムをGPU用にゼロから構築しました。これにより、最小限のロックまたはロックなしで、このグラフの構築を一つの大きなバッチで実行できるようにしました。

CAGRAはかなり有用なアルゴリズムであることが証明されています。根本的に少し異なるんですね。HNSWのHは階層的という意味ですが、CAGRAは階層的ではありません。フラットグラフなんです。SWはスモールワールドを意味しますが、CAGRAはスモールワールドグラフではありません。しかし、十分にナビゲート可能であることがわかったので、これをHNSWグラフに変換できるんです。今日の埋め込みモデルは次元数が少し制御不能になってきていて、次元数が増加するにつれて、私たちはそれに気づいています。圧縮して少し改善することはできますが、それでもまだ制御不能な状態ですね。

次元数が増加するにつれて、そしてスケールが増加するにつれて、インデックスを構築する際のギャップが増加することに気づきました。インデックス化する必要があるベクトルの数が増えるほど、そしてモデルの品質が向上するほど、そのギャップがさらに増加することに気づいています。つまり、80%や85%のようなリコール率を与えるものと比較して、99%のリコール率を与えるモデルが欲しい場合、そのギャップがさらに増加することに気づくわけです。当然のことながら、このスタック図の最下層は、インデックス構築の課題を解決するために私たちが提供したcuVSライブラリになります。

相互運用性の課題については、このCAGRAグラフをCPU上のHNSWグラフに変換できるようになったので、品質を失うことなく、レイテンシを失うこともなく、CPU上で検索できるようになりました。この下のチャートを見ていただくと、この変換を行うことで、実際にいくつかの点でより良いレイテンシを得られることがわかります。しかし、これは大きな意味を持っています。なぜなら、GPU上でインデックスを20倍以上速く構築でき、それを変換できるので、実際には何も失っていないからです。ただ、これはまだ少し課題を提示しています。

Faissライブラリは数年前から、私たちがベクトル検索と呼ぶ前から、GPU上でのベクトル検索を先駆けてきました。それは近似最近傍探索と呼ばれていて、これはMetaから出てきた近似最近傍探索ライブラリでした。彼らは長い間この分野に取り組んできて、素晴らしい仕事をしてきました。彼らのアルゴリズムはCPUとGPUの両方で本当によく最適化されています。私たちは過去3、4年ほどFaissの方々と協力してきました。最終的にはFaissの従来のGPUバックエンドをcuVSバックエンドに置き換える予定で、それに向けて取り組んでいます。しかし現時点では、Faiss用のcuVSバックエンドがあり、これによってシームレスな相互運用性が提供されるので、GPU上でインデックスを構築し、CPU上でインデックスを検索できるようになります。

これは、欠けていたピースのもう一つ、この相互運用性のピースで、ちょうどここの層に配置できるものです。つまり、Faissライブラリが私たちのソリューションになったわけです。AWS OpenSearchがすでにOpenSearch用のFaissバックエンドに投資していたことがわかったのは、ちょっと嬉しい発見でした。そのおかげで、彼らはスイッチを切り替えるだけで、GPU上でのインデックス構築にcuVSバックエンドを使用できるようになり、その相互運用性の恩恵を受けることができたんです。

Mixed workloadsというのは非常に重要なんです。セマンティック検索ができますと言うだけでは十分ではありません。構造化検索、セマンティック検索、そしてセマンティック検索と一緒にスパースな字句検索を行う、そのハイブリッドな中間を実現できるソリューションが必要なんです。Amazon OpenSearch Serviceがこれを可能にしました。彼らは、インデックスの構築とインデックスの検索を同じプロセスで行うという標準的なアプローチを取り出して、これを別々のプロセスに分離したんです。これにより、必要に応じてインデックス構築を別のインスタンスにオフロードできるようになりました。これは本当に大きなことなんです。

常に料金を支払わなければならないGPUが、ほとんどの時間アイドル状態になっているというのは良くありません。インデックスを構築したり再構築したりする必要がある理由はたくさんあります。特にここでの基盤アーキテクチャであるLuceneにおいてはそうです。新しいモデルを採用したい場合、インデックスを再構築する必要があります。リコールとレイテンシのトレードオフを見つけるためにパラメータのチューニングを行いたい場合、新しいモデルを構築して再インデックスする必要があります。ですから、混合タイプに対しては、OpenSearch Serviceを採用しました。

さて、ここが大きな映画のクライマックスのようなところですよね。ここからコストメリットを引き出すためには、使い終わったらGPUを返却できる必要があるんです。常にインデックスを構築しているわけではありません。常にインデックスを構築している場合もあるかもしれませんが、その場合は素晴らしいことです。インデックスサービスを稼働させておけますから。しかし、ほとんどの人は常にインデックスを構築しているわけではありません。かなり低いボリュームで継続的なインジェストを行っているかもしれません。しかし、使い終わったらそのハードウェアを返却できる能力こそが、これを本当にコスト効率的にするものなんです。これは大きなことです。これは、OpenSearchの仲間たち、OpenSearch Serviceの開発者との協力によって実現されたもので、完全に新しいものです。これまでこのようなことは行われてこなかったんです。そして私たちはここで非常に大きなメリットを見出しています。

右側にコストとスピードを示すベンチマークがあります。エンドツーエンドで、単にインデックスを構築するだけなら、20倍の高速化が得られます。これはサーバーレスインフラストラクチャにデータを送信したり、その後モデルを送り返したりする必要があることを含んでいません。すべてを含めて、エンドツーエンドで、それでも14倍の高速化が見られます。これによって12倍のコストメリットが得られています。これは大きなことです。

これらすべてをまとめると、GPU上のcuVSライブラリでより高速なインデックス構築ができます。GPUで構築し、FaissライブラリでCPU上で検索できます。これらすべてをOpenSearch Serviceに組み込むことで、エンドツーエンドのデータベースで混合タイプを扱うことができます。そして新しいOpenSearch Serverless GPUにより、使い終わったらGPUコンピューティングを返却できるので、常に稼働させるための料金を支払うことなくメリットを享受できるんです。

それでは改めてまとめますと、これらが私たちがここで解決した4つの課題です。コスト効率について私たちが気づいていることですが、これはMatt Garmanの基調講演で発表されたばかりだと思いますが、最大10倍高速なパフォーマンスが見られています。これは平均して約375%低いコストとなっています。

Auto OptimizeとAgentic Search：ベクトルチューニングの自動化とエージェント機能の拡充

それでは皆さん、ありがとうございました。Corey、ありがとう。NVIDIAとのパートナーシップは本当にエキサイティングです。私たちは素晴らしい成果を目にしています。例えば、今では10億規模のベクトルインデックスを1時間以内に構築できるようになりました。以前は構築に数日かかることもありましたが、今では1時間以内に構築できます。これは本当にエキサイティングなことです。それでは検索のイノベーションについて続けていきましょう。

皆さんもご存知の通り、ベクトルインデックスの構築は複雑になることがあります。Coreyがレイテンシとリコールのトレードオフについて話しましたが、それに加えてコストも考慮したいところです。様々なパラメータや設定すべき異なるモードがあり、それが課題となることがあります。 通常は構築して、評価して、そしてまた、これはうまくいかないとなって、振り出しに戻ることになり、 異なるパラメータで繰り返すことになります、そしてそれには時間がかかります。

一般的に求めているのは、レイテンシと リコールのトレードオフであり、コストも要因の一つです。問題は、これらのパラメータはデータによって異なる動作をするということです。ワークロードとデータに特定の特性がある場合、他のワークロードとは異なる動作をするため、一般化することさえできません。求めているリコールとレイテンシプロファイルを得るためにどのパラメータがうまく機能するかを見つけ出すには、実際に自分のデータを使用する必要があります。

これらの課題に 対処するために、昨日私たちがローンチしたのがAuto Optimizeです。Auto Optimizeはワークフローで、データをアップロードします。 私たちはそのデータを取得し、様々な実験を実行して、指定されたレイテンシとリコールの組み合わせの中で最も低コストなオプションを見つけ出します。より高いレイテンシでも問題ない場合は、ディスク最適化モードを推奨します。本当に高いリコールが必要な場合は、

特定のハイパーパラメータ構成を推奨します。すべての異なる構成を実行し、このジョブはクラスタに直接適用できる出力を提供し、ベクトルチューニングで求めている最良の結果を得ることができます。何日もかけて何をすべきか考える必要はありません。これにより、ベクトルユースケースの概念実証から本番環境への移行を本当に加速することができます。

先ほど申し上げたように、評価したいすべての異なる組み合わせをGPUアクセラレーション機能で並列化します。これにより、本当に迅速に実行し、1時間以内に出力を提供することができます。これはかなり重要なローンチです。

OpenSearchスタック全体を振り返ると、このスタックは従来の検索から大きく進化してきました。スタックの最下層には、Luceneと、OpenSearch用のさまざまなエンジンを取得するためのさまざまな方法があり、現在は新しいエンジンとしてS3ベクトルがあります。そして、さまざまなユースケースがあります。ハイブリッド検索、マルチモーダル検索、セマンティック検索などのすべての検索ユースケースがあります。そしてもちろん、OpenSearchのベクトルデータベース機能があり、exact K-NNとapproximate K-NN、そしてtiered storageを実行できます。

また、多くのAI駆動型ユースケースも構築しています。OpenSearchのagentic機能、MCPサーバーなどです。これについては後ほどお話しします。そして、皆さんの体験を向上させるためのツールも構築しています。さまざまなサービスに接続するコネクタや、さまざまなワークフローを構築できるAI Workbenchなどです。これらの多くが現在OpenSearchの一部となっています。皆さん、次のアプリケーションでぜひ試してみてください。OpenSearchは従来の検索エンジンから大きく進化しました。

私たちが多くの興味深いイノベーションを目にしている分野の1つは、エージェントの世界です。皆さんがエージェントを構築する際、検索は非常に重要な役割を果たしています。私たちが目にしているのは、エージェントにはコンテキストが必要であり、エージェントは非常に反復的だということです。質問をすると、どのプランを使用して実行するかを決定する方法が非常に反復的です。Agentic searchは、RAGのようなユースケースとは大きく異なります。

従来のRAGのユースケースでは、クエリがあって、ベクトルデータベースに行って、追加のコンテキストを取得し、そのコンテキストをLLMに渡すという流れでした。しかしagentic searchでは、クエリが与えられたら、そのクエリを取って、ある程度の推論を行います。異なるMCPツールを使って追加のコンテキストを取得します。そして短期メモリと長期メモリからのデータを使ってさらにコンテキストを取得します。LLMを呼び出して、プランを取得し、追加のコンテキストに基づいてそのプランを洗練させる、といった具合に、実行しなければならないagenticなループになっています。これには、今まで持っていたよりもはるかに多くのツールが必要になります。

これらのツールの多くが利用可能になったことを発表できることを嬉しく思います。MCPサーバーがあり、agenticメモリ機能があり、そしてOpenSearchで構築したいくつかの特化したエージェントもあります。MCPサーバーはかなり標準的なものです。皆さんのほとんど、おそらくほぼ全員が、MCPサーバーがどのように動作するかをご存知だと思いますが、OpenSearchにはMCPサーバー機能があり、皆さんが使うことができます。list indexやsearch indexのような異なるツールセットがあり、MCPプロトコルを使って直接呼び出すことができ、エージェントがOpenSearchのデータに直接アクセスできます。認証を統合し、一般的なフレームワークと統合しています。

また、OpenSearchでagenticメモリ機能もローンチしました。つまり、ベクトル機能のためにOpenSearchを使っていて、エージェントの短期または長期のコンテキストを保存したい場合、OpenSearchでそれができるようになり、OpenSearchの検索機能を使ってそのメモリを検索することができます。短期メモリと長期メモリの両方を保存する非常に強力な方法であり、時間的な機能を管理するさまざまな方法があります。時間に敏感なデータがある場合、それを削除できるので、その管理にも役立ちます。

最後に、3つの異なるエージェントもローンチしました。OpenSearchでFlow agentをローンチしました。これは順次実行機能を提供します。検索のためのシングルターンワークフローがある場合、Flow agentを使うことができます。

マルチターン機能のためにconversational agentを使うことができ、この場合LLMがどのツールを使うかを推論し、その能力を提供します。また、plan, execute, and reflect agentもローンチしました。これはLLMを活用して実行フローを計画し、追加のコンテキストを取得し、一部のエージェントが行う深い調査作業を行うので、その機能を使って深い調査エージェントを構築できます。OpenSearchの最新バージョンには、agentic search機能を構築するための非常に強力な機能がいくつかあります。

Amazon OpenSearch Serviceのインフラ強化：Cluster InsightsとOpenSearch Optimized Instancesによる最適化

それでは、Carlがインフラストラクチャの強化についてお話しします。ありがとう、Nicole。皆さん、まだ聞こえていますよね？ さて、OpenSearchの機能についてたくさんお話ししてきました。終わる前に、サービス上でのこれらの利点についてもう少しお話ししたいと思います。Amazon OpenSearch Serviceの利点として、スケールについて触れましたが、1兆のベクトルインデックスですね。単一クラスタで最大1,000ノード、単一クラスタで最大25ペタバイトをサポートしており、単一クラスタで99.99%のSLAによる高可用性、OpenSearch Optimized Instancesを使用した場合は11ナインの耐久性を実現し、そして先ほど強調したすべてのパフォーマンス上の利点があります。

もう一つ、私が本当に興奮している機能は、ごく最近ローンチしたCluster Insightsです。このCluster Insights機能は、クラスタを管理する際にクラスタを監視します。ノードのパフォーマンス、シャードのパフォーマンスに関する洞察を提供し、クラスタ、クエリ、ホットクエリ、ホットシャードのより良いチューニングと最適化のための推奨事項を提供してくれます。これらすべてが、詳細な推奨事項と洞察によって、クラスタが最高のパフォーマンスで動作していることを確認することをはるかに簡単にしてくれます。これは現在、2.17以降を実行しているすべてのクラスタで利用可能です。Cluster Insightsリンクが表示され、それをクリックするとOpenSearch UIに移動し、このパネルが自動的に表示されます。

他にもいくつか触れておきたいことがあります。 OpenSearch Optimized Instancesについては先ほど触れましたが、これらはS3でバックアップされた高インデックス、高スループットのインスタンスです。昨年OR1をローンチしました。今年は第2世代のOR2をローンチし、また最初のMシリーズのOpenSearch Optimized、OM2もローンチしました。OR2はR7Gと比較してインデックススループットが70%向上しています。OM2はM7Gと比較して66%向上しており、これらの世代でさらなる改善が見られるでしょう。ですので、まだ試していなくて高インデックスワークロードをお持ちの方は、ぜひチェックしてみてください。

また、derived source機能も追加しました。これは、クラスタのストレージを最大40%削減できます。OpenSearchは従来、sourceつまりJSONデータを保持していました。セグメントマージやシャードの再インデックス、その他のクラスタ操作を行う際に、そのJSONデータが必要だったからです。これにより、それを削除します。実際には、これらの操作にJSONデータを使用しなくなりました。実際には、事前にインデックス化されたデータ、つまりderived sourceに基づいてこれらの操作を実行します。これは、もはやそのソースデータにクラスタの40%を無駄にする必要がないことを意味するだけでなく、データがすでに事前にインデックス化されているため、インデックスとマージが20%高速化されます。つまり、これらの操作を行うためにそのデータを再度インデックス化する必要がないのです。ですので、ぜひそのチェックボックスをオンにして、かなりのコストを節約してください。

また、昨年ローンチしたカスタムプラグイン機能についても触れておきたいと思います。スクリプティングプラグインを追加しました。カスタムプラグインをお持ちの場合、サービス上で実行できるようになりました。そして、そこでサポートするクラスの機能を継続的に拡張しています。ですので、これらの機能についてのフィードバックをいただけると嬉しいです。 時間がかなり迫ってきているので、手短に進めます。Amazon OpenSearch Serverlessについてですが、これはOpenSearchを始める最も簡単な方法です。serverlessでは、コレクションを作成するだけです。シャードを気にする必要はありません。サイジングを気にする必要もないので、圧倒的に最も簡単な方法です。

私たちはserverless プロダクトの拡張と成熟を続けています。現在、時系列データに対して単一のコレクションで最大100テラバイトまでサポートしています。リージョンも22リージョンまで拡大しました。データプレーンコールの監査やCloudTrail、そしてスナップショットリストアといった重要な機能も追加しました。そして、serverlessプラットフォームへの投資を継続していきます。この方向性にとてもワクワクしています。

では、まとめに入りますが、もっと詳しく学びたい方は、このトピックやたくさんのOpenSearchのトピックについて、より深く学べる私たちのスキルへのリンクがあります。また、私たちのブースにもいますので、AWS VillageのD23にブースがあります。実際、エキスポにはOpenSearch Projectのブースもあります。ぜひ立ち寄って、声をかけてください。皆さんが何をされているのか、どんな質問があるのか、もっと知りたいと思っています。そして最後になりますが、お越しいただいた皆さんに本当に感謝しています。そして、もしよろしければアンケートに記入していただけると、そのデータは私たちにとって本当に貴重なものです。良い点も悪い点も学び、皆さんにとって最高のコンテンツをここで提供できるようにしたいと考えています。ですので、お時間があればぜひアンケートに記入していただければと思います。それでは、1時間お付き合いいただいた皆さんに感謝します。OpenSearchについてお話しできて、そして皆さんがそれを使って何をされるのか見られることを本当に楽しみにしています。

---

※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。