Events
レジリエントなAIインフラの構築：Zilliz Cloudの新しい本番環境対応機能を徹底解説

ウェビナー

レジリエントなAIインフラの構築：Zilliz Cloudの新しい本番環境対応機能を徹底解説

Name: レジリエントなAIインフラの構築：Zilliz Cloudの新しい本番環境対応機能を徹底解説
Start: 2024-10-04T00:00:00.000Z
End: 2024-10-04T01:00:00.000Z

Zillizウェビナー | Zoom

Join the Webinar

このウェビナーについて

AIアプリケーションが実験段階から本番環境へ移行する中で、開発者や技術リーダーは、ベクトルデータベースを大規模に管理するうえで新たな課題に直面しています。このウェビナーでは、これらの課題に正面から対応するために設計されたZilliz Cloudの最新機能を紹介し、堅牢で効率的なAIインフラストラクチャの構築と維持を可能にします。ぜひご参加いただき、これらの新機能がAIインフラストラクチャ管理における一般的な問題をどのように解決できるかをご確認ください。

取り上げるトピック

シームレスなデータ移行および復旧戦略を実装し、データのポータビリティを確保してベンダーロックインを排除する
多様なソースからの非構造化データの統合を効率化し、AIモデルの広がりと深さを強化する
トラフィックの多いAIアプリケーション向けにクエリ性能とシステム可用性を最適化する
変動するワークロードに効率的に対応するためにリソース割り当てを自動化する
ミッションクリティカルなAIシステム向けにエンタープライズグレードの信頼性と監視を実現する

技術デモと実際のユースケースを通じて、これらの機能を活用してボトルネックを克服し、システムのレジリエンスを高め、AIの取り組みを加速するための実践的な知見を得ることができます。

View presentation slides

Transcript

本日は、このセッションをご紹介できることを嬉しく思います。ええと、2024年9月、Zell Cloudプロダクトローンチ、AIのためのレジリエントなデータインフラストラクチャの構築です。そして、私と皆さんの旧友であるJohnが、ええと、彼は、ええと、ziのEcosystemにおけるGabrielleの責任者で、ええと、このお話を皆さんにお届けします。ええと、John、皆さんに挨拶してもらえますか？こんにちは、ご紹介ありがとうございます、ええと、Stephanie。皆さん、こんにちは。では、始めましょう。

ええと、それでは先月リリースしたものについてお話ししましょう。私たちはこれについて実は非常にワクワクしています。ええと、OpenAIが約18か月前に製品をリリースして以来、多くの、ええと、開発者が本当に皆さんのデータベースをバックにしようとし、レコメンドシステムに使おうとしました。多くのことにおいて、製品をプロトタイプ化し、ええと、徐々に「さて、今は本番環境にいる。すべてがスムーズに動くように、本当に皆さんの助けが必要だ」となっていきました。

つまり、今回のローンチはそのすべてに関するものです。つまり、これは一つです。私たちは皆さんにデータをよりコントロールできるようにし、そうした大規模で複雑なAIアプリに取り組むのを支援し、本番環境にいるところで、すべてがスムーズかつ安全に動作することを確実にしたいだけです。このローンチでは、機能を3つのバケットに分類しています。最初のものはデータ主権です。

基本的に、私たちは異なる、ええと、ベクターデータベースシステム間のこの種のグレード移行サービスを提供し、そのうえでFiveTranソースコネクタを、ええと、GAで提供します。ええと、非常に良い点として、多くの方々、多くの皆さんが、ええと、FiveTranを知っていると思いますが、彼らの本当に良いところは、接続を持っていることです。彼らはすでに500以上のシステムのポートフォリオを構築しています。そのため、実際には、FiveTranの接続先であるあらゆるシステムから、非構造化データのようなデータを取得しやすくなります。そして2つ目のバケットは高性能です。

ええと、これは本当に、レプリカを通じてより高いスループットを提供したいということであり、さらにいくつかの、ええと、より優れたフォールトトレランスを備えています。また、アップスケールのようなものを通じて、運用上の負担をいくらか取り除くお手伝いをしたいと考えています。これについては後ほどもう少しお話しします。最後の部分はセキュリティと信頼性についてです。ええと、私たちは実際に過去数か月間メトリクスとアラートに取り組み、多くの新しいメトリクスとアラートをリリースしてきましたし、継続して取り組んでいます。ええと、これについても後ほどもう少しお話しします。

また、ええと、すべての非常に重要なことについて、先月リリースした機能は、この99.95の稼働時間、SAA SOAsに関するものでした。これは、ええと、現時点で他の主要なベクターデータベースプロバイダーよりもおそらく優れています。本当に、ええと、皆さんの、ええと、常に、ええと、ダウンタイムを最小化することを確実にしたいのです。ですので、ええと、これに対して私たちが行っていることはそれです。

では、ええと、機能のもう少し詳細に入っていきましょう。ええと、最初に述べたとおり、移行サービスのようなものです。シームレスで信頼性の高いデータ移行を確実にすることが本当に重要であることは、皆さんご存じです。ええと、Vectorにとっては、実は新しいことです。ええと、これを試したことがある人、または達成した企業はほとんどありませんが、ベンダー、ベンダーロックインを回避し、データのバックアップとリカバリなどに対処するのを支援するために非常に重要であることは皆分かっています。

そのため、私たちは、ええと、移行サービスの第1フェーズをリリースしました。これは構造化データ移行におけるゼロロスを本当にターゲットにしています。ええと、現在はバッチインポートをサポートしていますが、今月後半には実際に、ええと、リアルタイムデータストリーミングもリリースする予定です。ええと、また、私たちはこの種の変換を簡素化することを目指しています。そのため、埋め込みサービスのタグ付けのような多くのツールを提供して、さらに簡単にしています。そして最後の部分は、先ほど述べたように、データを移行する際、品質が本当に大きな問題だということです。

そのため、私たちはエンドツーエンドのデータ品質を確保したいと考えています。ええと、私たちは非常に堅牢なモニタリングとアラートを通じてそれを行うつもりです。ですから、プロセスの中で何かがうまくいった場合でも心配する必要はありません。それでは、それが実際にどのように機能するのか見てみましょう。John、ええと、移行サービスが正確にどのように機能するのか、もう少し詳しく共有してもらえますか？もちろんです。

ええと、つまり、移行サービスは本当に、ええと、私たちが開発したインフラストラクチャの一部であり、移行プロセス中の信頼性や、データ損失について心配する必要がないようにするものです。これは多くの、ええと、あの、非常に多くの、ええと、うーん、エンジニアリング作業であり、開発者が対処しなければならない多くの開発でした。ですから、考えてみてください。移行中に、もし、ええと、たった1つの、うーん、1つのリクエストが通ってきて、たとえばネットワークエラーが起き、そのリクエストが失われたらどうなるでしょう。リトライを行う必要があります。すべてのデータポイントを、うーん、確実に移行したことを確認する必要があります。ですから、この移行サービスとその背後のインフラストラクチャが、すべての問題を自動的に解決し、ええと、豊富なデータセットのリストに接続します。ええと、非構造化データソースからのものです。たとえば、うーん、現在はElasticに対応しており、また、PG Vectorのようなベクトルストレージの、ええと、ソースにも対応していますし、またbu、うーん、そして、ええと、将来のリリースでは他の、いわゆる、ベクトルデータソースや非構造化データソースにも対応する予定です。

そして、ええと、これを支えているものは実際には、うーん、オープンソースです。VTSと呼ばれています。ええと、GitHub上のZi Techでオープンソースリポジトリを確認できます。ですから、うーん、内部は、うーん、ソースとシンクのコネクタがあり、アダプターさえあれば、任意のソースや任意のものに接続できるようになっています。そしてその間にあるのがトランスフォーマー、つまり変換ステージで、うーん、そこでは、ええと、いくつかのデータクリーニング、たとえば、ええと、ソースデータから特定のフィールドだけを選択する、あるいは将来的には、うーん、ええと、埋め込みモデルサービスと連携して、その間でベクトル化、ええと、を行うことにも対応します。そして移行の信頼性と正確性を保証します。

うーん、その他にもいくつかのコンポーネントがあります。うーん、チェックポイントモジュールや監視モジュールなどで、それにより、全体のプロセスが、ええと、スムーズに動作することを確実にできます。そして、うーん、私たちが現在ローンチしているサービスは、うーん、Zeus Cloudで利用可能です。そして、たとえばローカルのVUSインスタンスや、PG vectorインスタンスおよびelastic searchからのベクトルを、Zeusに移行して、より高性能でよりスケーラブルなベクトル検索サービスを利用できます。では、このデモを少し見ていきましょう。はい。

もう撮りました、次のステップはデモです。わかりました。わかりました。画面共有をお願いします。わかりました。

ここで画面を共有します。ご覧のとおり、ええと、これは私の、うーん、zills cloudアカウントです。ログインすると、特定の、うーん、クラスターを選択して、そのクラスター内の、ええと、コレクションを確認できます。そして左側のナビゲーションバーで、migrationsをクリックすると、データを、うーん、zills cloudクラスターから、またはzills cloudクラスターへ移行できます。たとえば、既存のZills Cloudクラスターがあり、新しいものへ移行したい場合、ええと、たとえば、うーん、サーバーレスの、ええと、クラスターから専用クラスターへ引き上げたい場合や、データを、うーん、複製して他の目的に使いたい場合は、ここをクリックできます。

うーん、この例だけお見せします。たとえば、うーん、同じクラスターからの移行です。そこで、うーん、この中で、移行元のクラスターを選択できます。うーん、たとえば、これを選択して、それから、ええと、既存のクラスターへ移行できます。つまり選択できるということで、少しここでお見せすると、ええと、もし私が、このクラスターに2つのコレクションを持っていて、たとえば特定のコレクションだけを、うーん、移行したい場合、それを別のプロダクトへ移行できます。うーん、別のクラスター、ええと、migration testのようにして、それから移行できます。うーん、もう1つの、もう1つの機能は、新しいクラスターへ移行できることです。そしてこのプロセスの一部として、実際に、うーん、クラスター作成プロセスを案内してくれます。

ええと、serverless に既存のクラスターがあって、それはコスト効率が良かったのですが、もう少しパフォーマンスが欲しいとします。専用クラスターに移行したいです。これを自分で行う必要はありません。ここに来て、プロジェクトを選択し、クラスターに名前を付けます。たとえば、これは私の新しいクラスターです。そして、このクラスターをどこにデプロイしたいか、AWS や GCP などを選択できます。ここではデフォルトの選択のままにします。

そして、このクラスターの設定を選択できます。パフォーマンス最適化にするか、容量最適化にするか。CU 価格は同じですが、CU ごとに保持できるベクトルの量が異なります。というのも、それぞれパフォーマンスやコストへの影響が異なるからです。ですので、パフォーマンスが欲しいとして、パフォーマンス最適化クラスタータイプを選択します。1 CU に保存するベクトルは少なくなりますが、その分、より高いパフォーマンスが得られます。すべて設定したら、移行ボタンをクリックするだけで、ここで新しいクラスターが作成されます。

ユーザー名とパスワードをダウンロードできます。これは別の認証方法です。通常は、認証用トークンとして API キーを使用します。そしてここでパブリックエンドポイントを見ることができます。今はコレクションがありません。移行プロセスが開始されたばかりだからです。ただし、移行のすぐ下にある jobs セクションで進捗を確認できます。ここでは、migration test という新しいクラスターにデータを移行するために、以前に移行を正常に実行したことがわかります。

そしてここでは、私がたった今作成した新しい移行ジョブが進行中です。セットアップが完了し、コレクションがセットアップされると、データの 10% が移行済みである、などの進捗も表示されます。また、Sales Cloud クラスター間での移行に加えて、ローカルの、つまりセルフホストされた VUS インスタンスから移行することもできます。たとえば、ekis や自己管理の Kubernetes クラスターにデプロイされた mill インスタンスがあるとします。バックアップファイルをダンプすることで、これを移行できます。

または、より多くのデータがある場合や、すべてのデータを格納する一時ファイルを持ちたくない場合は、ローカルの mills クラスターのエンドポイントを指定できます。ネットワークエンドポイントとユーザー名、パスワードを指定するだけで、自動的に移行してくれます。それ以外は、前のプロセスと同様に見えます。また、ソースを選択し、すみません、スキーマを設定する機会もあります。つまり、移行プロセス中にフィールドを選択できるので、データの一部が不要な場合、あるフィールドが不要な場合は、それを削除できます。同じことが Elastic Search と PG Vector にも当てはまります。

これも同じ考え方で、Elastic Search のエンドポイントと API キー、またはユーザー名とパスワードを指定するだけです。はい。以上で、だいたいこれで終わりだと思います。あ、続けましょう。はい。

わかりました。画面共有に戻ります。すみません、少しお待ちください。あの画面がもう見つかりません。あ、ここです。

失礼しました。次について話しましょう。Fly Train Connector は、先ほど触れたように、私たちにとって Five Train チームとの本当にエキサイティングな連携、パートナーシップのようなものです。というのも、彼らはすでに 500 以上のシステムに接続するという非常に難しい作業を完了しているからです。おそらく多くの企業が Snowflake、Salesforce、gong、Asana などの多くを使用しています。そのため、おそらくすでに Five Chain を通じて、そこに大量の非構造化データを保存しているでしょう。

私たちは、ええと、非構造化データを抽出し、OpenAIのembedding、つまりembeddingサービスを使ってベクトル化を行うことができます。その後、Wareのソースまたは宛先コネクタを使って、V Cloudまたはvisに接続できます。ええと、John、このプロセスについてもう少し話して、皆さんにデモを見せてもらえますか？もちろんです。ええと、Five Trendチームは、このプラットフォームを通じて、ほぼすべてのビジネスアプリやデータソースを接続できるようにするうえで、本当に素晴らしい仕事をしています。また、移行サービスと同じように、ええと、信頼性と正確性の問題を解決しており、自動的にリトライロジックを実装しています。また、ええと、ご存じのとおり、データをリアルタイムかつ確実に同期できるようにするための、あらゆる種類のインフラサポートも備えており、ええと、データレコードを一切失うことなく同期できます。

ええと、Five Tryとその統合によって実現できる例としては、この接続を通じて、ほぼすべての単一のビジネスデータソースを検索可能にすることができます。つまり、ええと、たとえば、SalesforceやZendesk、GitHub、Slackメッセージにデータがある場合、Five Trend ZI統合がなければ、それらを検索可能にするためのデータパイプラインを構築するのにかなりの手間がかかります。ええと、しかしこれを使えば、データソースを用意し、それをFiverのソースコネクタとして設定するだけの簡単な作業になります。そして、ええと、Fiverには、データソース上の最悪のテーブルを結合するための事前実装済みのビジネスロジックがあります。たとえばGitHubであれば、issueテーブルがあり、user profileテーブルがあり、commentテーブルがあり、たくさんのテーブルがありますが、通常、検索ではそれらを1つの単一テーブルにフラット化し、ええと、ほぼエラー情報を含めたいものです。そうすることで、ええと、汚染されたテキスト上で検索しやすくなり、さらにメタデータ上のプロジェクトケースなどでフィルタリングできるかもしれません。つまりTranには、これらのテーブルを結合し、その後、ソーステーブルから新しいデータレコードと既存のデータレコードをすべてデータウェアハウスに同期する、この機能があります。

たとえば、データウェアハウスとしてsnowflakeを選択でき、その後、ええと、Snowflakeデータウェアハウス内にフラット化された、ええと、正規化されたテーブルができます。そして、Snowflakeをデータソースとして、VUを宛先として設定できます。そして、ええと、その間、つまり、ええと、データ移動プロセス中に、ええと、five tonコネクタが現在invitingサービスを呼び出します。ええと、これはOpenAI invitingサービスをサポートしており、これがストリームライン化された機能でベクトル化を行います。そうすることで、ええと、このプロセスの後には、ベクトル、すべての、ええと、テキストやラベル、たとえばメッセージの送信者、ええと、MAメッセージのタイムスタンプなど、すべてがZeusに取り込まれます。

そしてこれはストリーミング形式で動作します。つまり、GitHubに現れるすべての新しいデータレコード、たとえば誰かが新しいissueを作成すると、Fiverがそれを自動的に検出し、その後Sales Cloudまたはbuに同期します。では、これが実際に動く様子をご覧になりますか？ええ、そうですね。では、デモを見てみましょう。はい。わかりました。

こちらが私のFive Trendアカウントです。ええと、destinationでは、VUタイプの新しいdestinationを作成できます。ええと、現時点では、これはpublic previewでのpreviewであり、これは、ええと、partner builtです。つまり、ええと、私たちはTranと協力して、この、ええと、このコネクタロジックを実装しました。これを選択し、myvuのような名前を入力できます。そして、ええと、このページでは、ええと、VUアカウントの認証情報、ええと、またはMilインスタンスの認証情報を指定できます。あるいは、これはinstance networkと呼ばれるものなのですが、少し、ええと、いくつかお見せできます。はい。見てみましょう。

ええと、もし、うーん、たとえばこのテストアカウントから移行したい場合は、ええと、エンドポイントとトークンをそのまま、あの、コピーすればよくて、もちろん、なぜなら、これは、ええと、OpenAIを使うからです。OpenAIキーを、ええと、どこかに、あの、ええと、用意しておいたほうがいいです。それで、ええと、ここでは、ええと、簡単な例をいくつか示します。なので、あの、ここで、自分の、自分のエンドポイントと、ええと、トークンを指定できます。また、open Iキーも指定する必要があります。

さらに、ええと、使用したいopen in埋め込みモデルを指定する必要があります。ええと、これは重要です。なぜなら、ええと、この埋め込みモデルは、ええと、buにデータを取り込むために使われるからで、それは、クエリを埋め込むために使用する埋め込みモデルと同じであるべきだからです。たとえばユーザーが質問をした場合、それをベクトルに埋め込み、それから、ええと、vuコレクション内の既存のベクトルを検索したいわけです。そして、その埋め込みモデルはまったく同じものである必要があります。そうでないと、ただ、単に、単に互いに一致しません。

そして、そこには、そこには、そこには検索する方法がない、そうですよね？なので、ええと、これを指定し、データ処理場所と、プロバイダー、ええとクラウドプロバイダーを指定します。そこでは、ええと、このコネクタが実行されます。通常はデフォルトの選択のままにしておき、それから保存してテストできます、ええと、そして、あの、これを保存できます。するとそれが、宛先になります。そしてコネクタの部分については、ええと、コネクタを追加できます。なので通常、最初にやりたいのは、ええと、GitHubまたは任意の、あの、データソース、たとえばZendeskやSnowflake、ええと、失礼、Zendeskと、そして、ええと、ええと、Salesforceからデータウェアハウスへのコレクション接続を確立することです。そのために、あなたは、ええと、Snowflakeタイプの別の宛先を作成する必要があります。

そして、Snowflakeの認証情報を指定します。ええと、それから、あなたのSnowflakeアカウント内で、ええと、あの、ええと、設定する必要があり、手順に従って、five tryingが使用するためのアカウントを設定してください。しかしその後、あなたの、ええと、GitHubデータをSnowflakeに移植できます。なのでここでは、ええと、これの部分的なデモを行います。ええと、宛先としてSnowflake、ええと、アカウントを選択でき、それからGitHub、OLSまたはその他の、あの、認証方法でアカウントを認証できます。

ええと、ここではこれを認可して、何が起こるか見てみます。ええと、lemme see has GitHub。はい、ここで自分のGitHubアカウントを認可しました。それから、ええと、あの、すべてのリポジトリを同期することもできますし、アクセス権のある特定のリポジトリを同期することもできます。いいえ、ここでは、ええと、ランダムなデモだけを行います。

これで、接続のテストが開始されます。そして、ええと、あの、すべての接続が通れば、このデータをSnowflake、あなたのSnowflakeアカウントに流し込むことができます。そしてそれができたら、ええと、あなたのSnowflakeアカウントにはすでにデータがあるはずで、それからSnowflakeアカウントをVu、ええと、宛先に接続するための別のコネクタを作成できます。なのでここで、あの、私は、GitHubデータの移植先にしていた同じSnowflakeアカウントを選択でき、それから、ええと、Snowflakeアカウントの認証情報を指定でき、それから、ええと、メールボックスアカウントへの接続を確立できます。失礼、少し間違えました。

このステップでは、宛先はあなたのVUアカウントであるべきです。なのでここでは、ええと、Zs cloud上にデプロイされた私のメールボックス、ええと、宛先のようなものです。それからSnowflakeアカウントの認証情報を指定し、それによってSnowflakeテーブルとVU接続の間の接続を確立できます。はい。これで何ができるかというと、ええと、ここに、私が作成したデモがあります。ええと、まずデータを見てみましょう。

それでは、ええと、あー、これは私が作成したコレクションで、ええと、Toki という GitHub repo から、ええ、Snowflake にデータを同期する前のものです。そして Snowflake から、ええと、VU の、ええ、collection へ同期します。ここにあるこのコレクションでは、ええと、実際にかなり多くのデータを移行しました。スキーマは、元のテキストを持っているように見えます。これは連結された、ええと、issue、topic、issue、comments、そしてその issue からのすべてのテキスト情報のようなものです。さらに、issue の URL などのメタデータもいくつか含まれています。

ではこれを見てみましょう。ええと、これはこの、ええと、リポジトリの issue で、人々が質問をして、ええ、いくつか回答があります。つまり、すべての質問と回答、コメントが 1 つのテキストとして一緒に連結されています。それが元のテキストです。また、ええと、作成日時の timestamp などの他のメタデータもあり、ええと、もちろん vector もあります。これは、ええ、元のテキストから生成された vector embedding です。

これを使うと、実際に自分の GitHub issues の検索アプリを作ることができますし、さらに良いことに、その上でそのまま実行することもできます。ここに、ええと、私たちが作成したサンプルアプリがあります。こちらです。ええと、指定します、ええ、この、これは単なる streamed app です。なので ZI host を指定します。これは、ええと、Mills collection の network endpoint と token、それから Open I Key です。

というのも、rag では large language model を使う必要があり、さらに、ええと、クエリをエンコードするための embedding model も必要だからです。ええと、そして、この embedding model を、データの取り込みに選んだ embedding model に指定できます。その場合、私は、ええと、embedding three を使っていました。おっと、壊れていますね。はい、これを試してみます。

Okay、もう一度これをお見せします。ええと、ここで credentials を指定します。おっと、できました。では、endpoint と token、key を指定します。okay、これでこのテーブル内の既存の collection がすべて表示されます、ええと、すみません、この cluster 内です。ではこれを選択して、選択して、これで質問できます。

見てみましょう。ええと、この support report, local pass、すみません、model local pass です。ランダムな質問をして、何が返ってくるか見てみます。Okay、裏側では実際には、この query text を vector に embed して、それからこの特定の collection に対して vector search を行います。そして返されたデータを使って、large language model を呼び出して生成を行います。

この場合、実際にこの fieldsources of information を取得しました。これが何について話しているのか見てみます。Okay、この場合、ええと、local encoder または model を load しようとしています。そして、ええ、検索結果を尊重しているように見えますが、私は、これは、でも確認すると、はい、これは私が探していた答えではないと思います。別の聞き方をしてみます。

Support localslocally stored model has、okay、どうやら、ええ、yes と言っています。そこに reference があるか見てみましょう。Okay、まさにこのトピックについて話している ques、issue があるようです。そして、ええ、ここで、はい、ええと、誰かが答えています。click model は Check one pass をサポートしており、これはローカルにキャッシュできます。Alright、これで、ええと、デモはだいたい以上です。もしこれを試してみたい場合は、ええと、この demo app のリンクを、ええと、Zoom chat に送ります。そしてここには、ええと、Fran による専用セッションがあり、ええと、fiver connectors と numerous destination のセットアップ全体のプロセスを説明します。

そして、ええ、この demo app を使って、GitHub や Zendesk のような任意の business app からのデータで検索できることを示します。Okay、以上です。どなたか質問はありますか？ええと、もしあれば、ええと、QS session にコピー＆ペーストするような形で投稿してください。私たちは、いつでもどんな質問にも喜んでお答えします。ええと、okay、それでは続けましょう。

ええと、もう一つすごくワクワクしたのは、Model Replica のようなものです。ええと、これはかなり多くのお客様から聞きました。彼らはそれほど非常に大きなデータセットを持っているわけではありませんが、非常に高いスループットを必要としています。なぜならコンシューマー向けアプリだからです。たとえば、ユーザーに製品を推薦するためのレコメンデーションエンジンのようなことをしている場合、通常、多くの人が同時にオンラインになっています。ええと、だからこそこの replika があり、ええと、現在はパブリックプレビューです。そして良いニュースは、ええと、今月末か来月初めには GA になると思います。ええと、つまり基本的に、同時により多くのクエリを処理できるように支援します。

一方で、より高い、ええと、耐障害性を必要とし、ええと、ダウンタイムのようなものを本当に許容できない種類の企業にとっては、ダウンタイムを最小限に抑えるためにいつでもこれを使うことができます。もう一つ本当にエキサイティングな機能は autoscaling に関するものです。ええと、これもまた、私たちのジュニアチームから聞いた言葉、または一部のお客様から聞いたものです。彼らのアプリは実際、ええと、ワークロードがかなり変化し、ただ増え続けています。

なので彼らは本当に、ええと、彼らは本当に忙しくて、「ねえ、別のクラスをスケールアップしたい、ええと、すみません、別の c、別の cu をスケールアップしたい」としようとしていて、これは彼らにとって大変な作業になります。そこで私たちはこの機能を Kathleen Private preview で作りました。つまり、クラスターの容量のある種の、ええと、ええと、事前設定された割合に達したときはいつでも、たとえば D 40、70% のように、システムが自動的に別の CU をスケールしてくれます。また、ええと、自分が許容できない範囲まで進んでしまうことを心配する必要もありません。なぜなら、そこで設定できる最大リソースしきい値があるからです。たとえば、対応できる最大が、たとえば 32 cu なら、そこで設定できます。

そのため、そのようなしきい値レベルに達したときでも、32 cu を超えることはありません。あとは確認するだけでよいです。システムを最適化したいかもしれませんし、私たちに連絡するか、あるいは「なるほど、データが大量にあるので、スケールを続けたい」となるかもしれませんが、システムは自動的にそれ以上スケールしません。そしてここで共有する最後の部分は、ええと、メトリクスとモニタリングについてです。ええと、先ほど述べたように、チームは過去数か月間、すべてのアラート、ダッシュボードについて本当に懸命に取り組みました。まさに、アラートを受け取り、パフォーマンスを監視し、既存のツールを使用できるようにし、特にサービスのオンタイムを最小化することを確実にしようとしています。

ええと、アラート自体については、現在 39 の organization organizational およびプロジェクトアラートをサポートしています。そのうちいくつかは事前設定されています。ええと、しかし実際にはそれらの多く、さらに多くをカスタマイズできます。受け取りたいアラートの種類が何であれ、ui の中で設定できます。ええと、次の部分はメトリクスについてです。現在、リソース使用量、QPS リクエスト結果、データ操作にわたる 18 のメトリクスを提供しています。

そして実際、ui には多くのカスタマイズ可能なツールがあります。いくつかの詳細な分析を行うことができます。たとえば、特定の期間だけを選択したい場合、ui の中だけでそれを行うことができます。そして最後の本当に重要な部分はインテグレーションについてです。現在、New Relic と Grafana と連携しており、もしあなたがそれらのユーザーであれば、Zillow Cloud を、ええと、New Relic または Grafana に接続して、そこでモニタリングを行うことができます。またチームは、data doc と permit permit のこのインテグレーションを実現するために一部取り組んでいます。今月後半か来月初めには出ると思います。

必ず皆さんにお知らせします。ですので、ええと、Data Doc がこれを許可できる場合、または現在皆さんが監視しているものについても、ええと、まもなくそれらを活用してそれらも監視できるようになります。ええと、質問がありますね、ええと、Dynatrace、素晴らしい質問です。ええと、John、Dynatrace をサポートする計画がまだあるかどうかは分かりませんが、ええと、もしそのニーズがある場合は、いつでも私たちの、皆さんのアカウントマネージャーに連絡してください。私たちは、レポートのようなものを送る、すみません、サポートリクエストを送ります。それを、ええと、ロードマップに載せて、ええと、近い将来のどこかでリリースされるようにします。

はい、私たちは、ええと、現時点では Dynatrace の、ええと、計画はありませんが、ええと、これを、提供する監視統合の、別の選択肢として検討したいと思っています。おそらく、ええと、Datadog と Promises から始める、始めることになるでしょう。ええと、ですが、はい、ぜひアカウントマネージャーに相談するか、または私たちにサポートメッセージを送ってください。フィードバックありがとうございます。これを検討します。では、今回のローンチについて話したい機能は以上です。ただ、もう一つあります。

ええと、皆さんのうちどれくらいの方がこれを聞いたことがあるか分かりませんが、ええと、ええと、私たちの syllabus は実は先月 GA になりました。ええと、かなりの期間がありました。たしか約5か月、各5か月くらいだったと思います。私たちはパブリックレビュー中でした。たくさんのフィードバックを受け取りました。

ええと、ですので、これは間違いなく正しい方向に進んでいます。もともと私たちは2つ持っています。つまり、商用オファーでは、主に2種類のクラスター、standard と、ええと、ええと、enterprise dedicated を提供しています。ええと、そのどちらも、ええと、つまり、皆さん、これはよりインフラストラクチャに焦点を当てたもののようなものを必要とします。ですので、それぞれ異なる種類のユースケースがあります。

例えば、standard は実際には POC や開発向けで、Enterprise は本当にミッションクリティカルなユースケース向けです。そこでは多くの設定オプションがありますが、多くの開発者から、Hey、ええと、私たちは本当に始めたばかりなんです。ワークロードがどこに行くのか、またはワークロードが実際に大きく変動するのか、本当に確信がありません。クラスターを常に上下に、ええと、スケールさせるだけのリソースも本当にそれほどありません、という声を聞きました。ですので、その声は届いています。

そこで私たちは、ええと、serverless をリリースし、たしか4月にパブリックプレビューに入り、先月ついに GA になりました。これは本当に、私たちは、ええと、serverless アプリケーション向けとして位置づけるものです。ええと、もしトラフィックが、ええと、たまにしかない、または本当にこれがどうなるか分からない場合、これは皆さんにとって素晴らしい選択肢になるでしょう。あるいは、アプリケーションを始めたばかりで、ええと、無料枠が提供する時間を少し超えたものが欲しい場合、ええと、serverless から始めて、これが自分にとって適切な選択肢かどうかを確認できます。ええと、John が先ほど示したように、移行サービスを使えば、望むならいつか dedicated に簡単に移行できますし、または serverless が皆さんのすべてのニーズを満たすなら、そのまま serverless に留まることもできます。ですので、ここで私が強調している SLI にはいくつかの違いがあることが分かります。実際には CU オプションはありません。

ええと、実際には、ああ、どの compute、つまり infra infrastructure が自分のニーズにより適しているのか、ということを考える必要はありません。皆さんはただその1つを使えばよく、つまり、スケールについて心配する必要はありません。先ほど dedicated clusters 向けの optic scale について話しましたが、それはスケールアップするためのものです。しかしこちらについては、それを考える必要はありません。CU のような概念はありません。

ええと、使いたい分だけ使えばよく、ああ、自分のインフラストラクチャをスケールすべきかどうか、などと心配する必要はまったくありません。現時点では SLA はありませんが、将来的には必ず追加する予定です。ですので、本番ユースケースで機能できるようにします。ええと、ただし、必要であれば、多くの、ええと、セキュリティおよびコンプライアンスはまだ得られます。すべてのデータ暗号化、R back、そして主要なコンプライアンスである SOC two、GPR はすでにあり、Heap もすでに、ええと、またその背後にサポートがあります。

ええと、それは専用の、ええと、すみません、専用の標準クラスターサポートティアに似ています。ええと、つまりそれが私たちの Serverless 提供内容です。ええと、なので、ええと、まだ試していないなら、たぶん今すぐ試してみるといいと思います。いくつか無料オプションがあると思います。一定の範囲までは無料で使ってみて、これが自分のニーズを満たせるかどうかを確認できます。

ええと、John、あなたも Serverless 用に、ええと、なんというか、ええと、小さなデモを用意してくれていたと思います。はい、その通りです。ええと、ここで画面を共有します。はい。ええと、そうですね、では、ええと、実際に、Serverless の紹介Webページをここで見せましょう、いいですね？Serverless についてもっと知りたい場合は、この、ええと、この、に進んでください。

com serverless、ここには、ええと、料金プランと、それが、ええと、有効にするすべての機能が表示されています。Serverless の背後にある重要な考え方は、専用と比較して、ええと、大幅なコスト削減を提供するということです。ええと、そしてこれは、たとえば検索レイテンシーについてそれほど高い要件がないワークロードに適しています。なぜなら、ええと、もちろん、ええと、共有の、ええと、リソースプールを使用しており、ええと、大きなコスト、ええと、削減を提供しますが、専用クラスターほどの性能はありません。そしてより重要なのは、専用と比較して検索レイテンシーの予測可能性が低いことです。なぜなら。

別のケースでは、つまり、専用リソースでは、専用マシン、専用の、ええと、そうですね、サーバーがそれらのリクエストを処理します。そして Serverless は、ええと、共有リソースプールを使用しています。そのリソースプールで、ええと、競合が少なければ、専用よりも、そうですね、検索レイテンシーが高い性能を示すことさえあります。しかしほとんどの場合、検索レイテンシーは変動する可能性があります。なので、つまり、それを念頭に置いてください。

しかし全体として、これは、まさに、そうですね、生成 AI アプリケーションや、あなたの、あなたの rack チャットボットをデプロイし始めているだけで、ええと、どれだけのトラフィックが、ええと、発生するのか、あるいは、ええと、ユーザーがその製品をどれだけ気に入るのかが分からないケースに適したオプションです。そして、Serverless より安価なオプションで試したい場合には、これは良い、素晴らしいオプションです。そして、さらに、ええと、私たちは、ええと、surveys の無料ティアを提供しています。つまり、もし、そうですね、Vector とすべてのメタデータを含めて、ストレージが5ギガバイト未満であれば、ええと、無料ティアを、ええと、使用できますし、ええと、それは、そうですね、無料になります。では、ええと、ここで Serverless クラスターを作成してみましょう。

では、ええと、そうですね、この、ええと、クラスター管理トピックで、新しいクラスターを作成できます。無料のものを作成できます、ええと、ただし1つの組織で作成できる無料クラスターは1つだけです。そして Serverless のものを作成できますが、cu では課金されず、抽象的な、ええと、そうですね、ええと、単位で課金されます。それは、ええと、VCU と呼ばれ、基本的にはあなたが実行する操作数です。ええと、使用された100万 VCU あたり、そうですね、4ドルが、ええと、課金されます。そして、ええと、また、指定することもでき、また、ええと、リージョンを指定する必要もあります。

そして現在、Google Cloud の、ええと、US west one リージョンで Serverless クラスターをサポートしています。そしてここでクラスターを作成できます。では、ええと、これを実際にどう使うか見てみましょう。ここでは画像検索の短いデモを用意しました。ええと、つまり、このような画像検索を支えるバックエンドを構築したいと思います。1つの画像をクエリとして渡し、それから類似画像を検索したいのです。

ええと、いくつかセットアップを行う必要がありますが、これは以前に済ませています。基本的には、ええと、そうですね、以前は、ええと、ローカルで実行される、ええと、mul slide を使うことができます。たとえば、この、この notebooks 環境内で、指定する必要があるのは、ええと、URI、つまりすべてのデータが永続化されるローカルファイル名です。つまり、ローカルで実行される mail slide を使って、この、このアプリケーションを開発したとしましょう。そしてもちろん、ここで画像検索を実行できます。ええと、そして今これを本番環境にデプロイ、デプロイして、そうですね、実際のユーザーに提供したいとします。そして今、サーバーが必要です。

つまり、Z cloud serverless cluster上で稼働している、ええと、mill serverを使うことができます。仕組みとしては、このURIを指定する代わりに、URIとしてserverless clusterのendpointを指定し、tokenを指定します。では、ここでは、ええと、作成したばかりのserverless clusterを使ってみましょう。準備ができているか見てみます。はい、できました。

ここでendpointをコピーします。おっと。それからもちろんtokenも。はい。自分のtokenと新しいclusterのendpointをコピーします。

これにはコメントがあり、このコード行を実行します。すると、このcluster内にimage embedsというcollectionが作成されます。ではやってみましょう。はい、成功したようです。確認して、更新してみましょう。

はい、できました。ここにimage embedsがあります。data previewをしてみましょう。予想どおり、dataはありません。では、たくさんの画像のvectorsをここに取り込みましょう。つまり、ええと、さまざまな、ええと、画像が入ったfolderがあるので、それらをすべてそこに取り込みます。

これが何をしているかというと、ええと、このtrain、ええと、folder内の各画像を1つずつ処理して、inviting modelを使ってvectorを生成し、そのvectorとfile nameというmetadataをimage embedding collectionにinsertします。そしてここで、dataが徐々に追加されていくのが確認できるはずです。では、もう一度data previewをしてみましょう。今は多くのvectorsが取り込まれていて、file nameがそれぞれのファイル名全体を示しているのが分かります。なので、任意のrandom vectorでvector searchを試すこともできます。たとえば、このvectorに隣接するvectorsを検索したい場合、ここでtop K searchを実行します。

top Kは3にします。つまりこれが何をするかというと、ええと、このsquare vectorのtop three nearest neighborsを検索します。これを検索します。すると、ここで、ええと、3つのresultsが得られました。またscoreも表示されます。これはtarget vectorとこのvectorの間のdistanceです。ええと、ここで非常に興味深いことに、1つ、scoreが1.0になっています。これは可能な最高scoreです。なぜでしょうか？それは、このcollection内に存在するvectorを検索したからです。つまりこれはtargetのものとまったく同じvectorであり、そしてこれには、ええと、つまりこの、ええと、使用するdistance metricsによって異なります。なのでこの場合、使っているのは、ええと、見てみます。はい、なので、ええと、metricは表示されていませんが、覚えている限りでは、metricはおそらくco-signです。

そのため、もし同じvectorであれば、co-sign distanceはちょうど1になります。はい、もう完了しているはずです。見てみましょう。ではこのままvectorの検索を試してみます。では、ええと、このdocを検索して、何が返ってくるか見てみましょう。

これはかなり遅いですね。GPUを使っていなかったと思います、いや、GPUは使いました。はい、これをterminateします。なぜなら、repositoryにはすでに十分な、ええと、vectorsがあるからです。では検索だけ実行しましょう。はい、できました。

このdockのvectorのnearest neighborsである、いくつかの、ええ、かわいいdocsが返ってきました。ここで別のexampleを試してみましょう。ええと、見てみます。car mirrorを検索したいです。この行のコメントを外して、何が起こるか見てみましょう。

はい、できました。ええと、car mirrorのtarget query vectorを使うと、他のcar mirrorsがたくさん、ええと、返ってきました。はい、これはserverlessで何ができるかを簡単に、ええ、sneak peekしただけです。examplesを試したい場合は、mills ioに行くことができ、ここには他にも多くのdemosが掲載されています。docs page tutorialsに行くと、VUやこのcloud、ええと、serverlessとdedicated clustersで何ができるかを見ることができます。これらは同じAPIを共有しているので、ええと、rag image searchを構築できます。

マルチモデルのRAGも構築できますし、ええと、ナレッジグラフを使ったグラフや、ええと、bu内のナレッジエンティティの取り込みもできます。ということで、これが私の、ええと、Zeus Cloudサービスに関する簡単なデモでした。ステップに戻します。素晴らしいです。ええと、本日ご用意している内容は以上だと思います。ですので次のパートは、ええと、Q&Aです。ご質問があれば、どうぞ遠慮なくお寄せください。

それでは、ええと、先ほどご紹介した役立つリンクをいくつか共有していますので、ぜひご確認ください。どなたかご質問はありますか？はい、なければ、ええと、はい、これでほぼ以上になると思います。ご参加いただいた皆さん、ありがとうございました。リンクや、ええと、新しくリリースされた機能、たとえば移行、5つのチャネルコネクタ、サーバーレスクラスターなどもぜひご確認ください。はい、ご質問があればいつでもご連絡ください。ええと、Discordチャンネルは常にオープンしています、ええと、vis.

io/discord. ええと、ぜひこちらに参加して、私たちのDiscordチャンネルにご参加ください。ええ、これは録画されています。ええと、数日以内には録画を受け取れると思います。はい、通常は1日程度以内です。

録画を公開し、録画リンクと、ええと、スライドも記載したメールをお送りします。ええと、ジョン、ありがとう。皆さん、この15分間ご参加いただきありがとうございました。ええと、また近いうちにお会いしましょう。皆さん、ありがとうございました。

それでは。またね、バイバイ。

Meet the Speaker

Join the session for live Q&A with the speaker

Jiang Chen
Head of Ecosystem and Developer Relations
Jiang is currently Head of Ecosystem and Developer Relations at Zilliz. He has years of experience in data infrastructures and cloud security. Before joining Zilliz, he had previously served as a tech lead and product manager at Google, where he led the development of web-scale semantic understanding and search indexing that powers innovative search products such as short video search. He has extensive industry experience handling massive unstructured data and multimedia content retrieval. He has also worked on cloud authorization systems and research on data privacy technologies. Jiang holds a Master's degree in Computer Science from the University of Michigan.