WEBVTT
1
00:00:03.825 --> 00:00:04.355
おはようございます。
2
00:00:04.385 --> 00:00:06.395
こんにちは、ええと、こんばんは。
3
00:00:06.425 --> 00:00:07.675
どちらにいらっしゃるかによりますね。
4
00:00:07.845 --> 00:00:10.555
本日のセッションにご参加いただき、誠にありがとうございます。
5
00:00:11.125 --> 00:00:13.995
本日は実は、私たちの初めての月例、ええと、
6
00:00:14.315 --> 00:00:15.435
ZILLS Cloud製品デモです。
7
00:00:16.015 --> 00:00:18.755
ええと、私はsfiです。私はheのメンバー、ええと、
8
00:00:18.875 --> 00:00:20.315
ここZillowsのチームメンバーです。
9
00:00:20.495 --> 00:00:22.875
同僚の、ええと、Ameeと一緒にいます。
10
00:00:23.185 --> 00:00:25.675
彼はソリューションアーキテクトの一人ですよね?
11
00:00:25.695 --> 00:00:28.075
そう、それで合っています。あなたの肩書きですよね、Amik。
12
00:00:28.075 --> 00:00:29.235
皆さんに挨拶しますか?
13
00:00:29.965 --> 00:00:33.225
皆さん、こんにちは。ええと、ここに参加できて、ええと、とても嬉しいです
14
00:00:33.725 --> 00:00:36.625
そして、ええ、私はただのソリューションアーキテクトで
15
00:00:36.625 --> 00:00:39.625
そして、ええと、ええ、楽しみにしています、ええと、
16
00:00:40.045 --> 00:00:42.345
今月の、ええと、
17
00:00:42.345 --> 00:00:43.665
月例デモで皆さんをご案内することを。
18
00:00:44.495 --> 00:00:46.125
素晴らしいです。では始めましょう。
19
00:00:46.905 --> 00:00:50.485
ええと、では、ええと、本日は皆さんにご紹介できることをとても嬉しく思います
20
00:00:50.485 --> 00:00:53.125
このZillow Cloud、私たちのスケーラブルで
21
00:00:53.385 --> 00:00:55.565
高性能なベクトルデータベースソリューションを。
22
00:00:58.315 --> 00:01:00.895
ええと、やってみます、はい。
23
00:01:01.115 --> 00:01:05.095
それでは、ええと、アジェンダには、ええと、2つの項目があります、ええと、
24
00:01:05.095 --> 00:01:06.615
短いウェビナーになりますので。
25
00:01:07.035 --> 00:01:09.855
まず最初に、皆さんに大まかな
26
00:01:10.175 --> 00:01:13.175
概要をお伝えします、ええと、zills Cloudとは何かについて。
27
00:01:13.435 --> 00:01:15.495
ええと、もし私たちのことをあまりご存じでなければ、
28
00:01:15.845 --> 00:01:18.295
その後、amekが簡単な製品デモを行います。
29
00:01:22.105 --> 00:01:26.525
はい。ええと、はい。
30
00:01:26.745 --> 00:01:30.885
ええと、皆さんの中にはご存じの方もいると思いますが、ULU Cloudは、ええと、
31
00:01:30.885 --> 00:01:35.685
buの上に構築されています。ええと、buはこの最も有名な、
32
00:01:36.025 --> 00:01:37.645
ええと、すみません、こうは言いません。
33
00:01:37.875 --> 00:01:41.245
最も人気のあるオープンソースの、ええと、ベクトルデータベースで、ええと、
34
00:01:41.465 --> 00:01:44.325
私たちはLinux Foundationに寄贈しました
35
00:01:44.985 --> 00:01:46.925
2020年に、ええと、
36
00:01:46.925 --> 00:01:49.525
なぜなら私たちは、ツールを構築することを本当に信じているからです
37
00:01:49.595 --> 00:01:51.765
開発者が信頼し、specし、
38
00:01:51.865 --> 00:01:54.525
貢献できるツールを、ええと、ここにある数字は、
39
00:01:54.705 --> 00:01:56.205
そのストーリーをかなり物語っています。
40
00:01:56.745 --> 00:02:00.085
私たちは32K以上のスターを達成しました、ええと、
41
00:02:00.325 --> 00:02:01.845
今年の初めだったと思います、
42
00:02:02.505 --> 00:02:06.485
そして6,800万以上のDockerプルが見られています。
43
00:02:06.905 --> 00:02:10.565
つまり中核として、VUSは目的特化型に構築されています、ええと、
44
00:02:10.675 --> 00:02:13.205
皆さんが扱っているもののために、ベクトルデータベースとして目的特化型に構築され、
45
00:02:13.685 --> 00:02:14.725
保存、インデックス作成、
46
00:02:14.725 --> 00:02:17.405
そして埋め込みの管理を行います、ええと、
47
00:02:17.405 --> 00:02:20.605
皆さんのために、ええと、機械学習モデルから出てくるものです。
48
00:02:21.025 --> 00:02:24.365
ええと、セマンティック検索レコメンデーションを構築している場合でも
49
00:02:24.365 --> 00:02:28.205
システムでも、その他の、ええと、ベクトル検索アプリケーションでも、
50
00:02:28.795 --> 00:02:31.725
これは皆さんのニーズに合わせてスケールするインフラです。
51
00:02:35.945 --> 00:02:39.035
ええと、millは、millは素晴らしいです。私たちは皆気に入っています。
52
00:02:39.135 --> 00:02:43.315
ええと、ですが、ええと、ええと、私たちは開発者から、そして
53
00:02:43.455 --> 00:02:44.635
また一部の、ええと、
54
00:02:44.775 --> 00:02:48.355
アプリケーションをプロトタイプから本番環境へ移行する際の
55
00:02:48.425 --> 00:02:50.475
いくつかの課題について、DevOps の人たちと話しました。
56
00:02:51.015 --> 00:02:53.155
ええ、そこでそれらのクラウドが登場し、
57
00:02:53.155 --> 00:02:56.635
そして、ええ、3つの重要な、いわば3本柱を構築します
58
00:02:56.655 --> 00:02:59.885
この、ええ、課題を支えるために。
59
00:03:00.305 --> 00:03:03.485
まず1つ目は、私たちの、私たちの Cardinal 検索エンジンです。
60
00:03:03.625 --> 00:03:04.645
聞いたことがあればですが。
61
00:03:05.185 --> 00:03:09.405
ええ、ですから、ええ、VU ユーザーであっても、気に入るはずです
62
00:03:09.405 --> 00:03:13.005
なぜなら、それは、ええ、この箱から出してすぐに10倍高速な、ええ、
63
00:03:13.035 --> 00:03:14.565
パフォーマンスを提供するからです。
64
00:03:15.025 --> 00:03:17.285
そして私たちは、
65
00:03:17.305 --> 00:03:19.005
手動のインデックスツール調整の頭痛の種を取り除きました
66
00:03:19.105 --> 00:03:20.605
そして彼女との調整の損失のようなものも
67
00:03:20.605 --> 00:03:22.125
それは本当に時間がかかり
68
00:03:22.145 --> 00:03:24.325
多くの、ええ、専門知識を必要とします。
69
00:03:25.185 --> 00:03:28.125
自動インデックス機能は基本的に、
70
00:03:28.165 --> 00:03:31.165
通常は自分で見つけ出さなければならないすべての最適化を処理します。
71
00:03:32.265 --> 00:03:37.245
ええ、インフラ、DevOps の、ええ、人たち向けに、私たちはこれを
72
00:03:37.305 --> 00:03:39.485
真のクラウドネイティブな分散システムとして構築しています。
73
00:03:40.225 --> 00:03:43.365
ええ、これは単にクラウドラッパーを付けた bu ではありません。
74
00:03:43.465 --> 00:03:46.725
ええ、多くの、ええ、オープンソースプロジェクトは、
75
00:03:46.725 --> 00:03:50.365
ただ、ええ、自分たちのオープンソースの、ええ、製品を
76
00:03:50.905 --> 00:03:52.845
クラウド上の Kubernetes クラスターに入れて
77
00:03:52.905 --> 00:03:54.405
フルマネージドと呼んでいます。
78
00:03:54.905 --> 00:03:55.965
ええ、私たちはそれはしません。
79
00:03:56.185 --> 00:03:59.565
ええ、villa は実際にゼロから設計されています、ええ、
80
00:03:59.585 --> 00:04:01.845
水平スケーリングと高可用性のために
81
00:04:02.155 --> 00:04:05.085
なぜなら、スイートを壊すことなくスケールアップまたはスケールダウンできるからです
82
00:04:05.625 --> 00:04:08.645
そして分散アーキテクチャは、より優れた適合性
83
00:04:08.785 --> 00:04:09.925
とコスト効率を意味します。
84
00:04:10.665 --> 00:04:13.605
最後に、ここでは本番データを扱っているので、
85
00:04:14.105 --> 00:04:17.565
ええ、私たちは、ええ、セキュリティを非常に、非常に真剣に考えています。
86
00:04:18.145 --> 00:04:20.565
ええ、セキュリティと信頼性の両方を確保します。
87
00:04:21.095 --> 00:04:24.205
私たちが話しているのは、ええ、よりよくテストされたパフォーマンスで、
88
00:04:24.205 --> 00:04:26.165
エンタープライズのセキュリティ要件を満たすものです
89
00:04:26.275 --> 00:04:27.885
なぜなら、誰も自分の CISO に
90
00:04:27.885 --> 00:04:31.525
なぜ適切なセキュリティ制御のないソリューションを選んだのかを
91
00:04:31.565 --> 00:04:32.965
説明したくないからです。
92
00:04:35.895 --> 00:04:37.155
ええ、それでは、ええ、
93
00:04:37.155 --> 00:04:39.235
Cardio 検索エンジンの技術的な詳細を
94
00:04:39.295 --> 00:04:40.755
もう少し深く見ていきましょう。
95
00:04:41.375 --> 00:04:44.235
以前に Novis を使ったことがあるなら、気づくでしょう。
96
00:04:44.235 --> 00:04:46.755
ここで対処している、いくつかの一般的な痛み、ええ、です。
97
00:04:47.005 --> 00:04:48.635
まずはインデックス作成です。
98
00:04:49.415 --> 00:04:52.915
私たちは、皆その手順を知っています。何時間も費やして、
99
00:04:53.455 --> 00:04:56.115
パラメーターを調整し、ベンチマークを実行し、
100
00:04:56.415 --> 00:05:00.035
それでも最適なパフォーマンスに達したのか疑問に思うのです。
101
00:05:00.495 --> 00:05:03.155
自動インデックスシステムは基本的にこれを代わりに処理します。
102
00:05:03.615 --> 00:05:05.355
それはあなたのデータセットを分析し
103
00:05:05.575 --> 00:05:06.915
そして何であれ、ええ、
104
00:05:07.235 --> 00:05:10.635
基盤となるオンラインハードウェアのハードウェアが、最も
105
00:05:10.915 --> 00:05:11.915
効率的な検索戦略を選択します。
106
00:05:12.295 --> 00:05:14.435
つまり、そこにはもう推測の余地はありません。
107
00:05:15.135 --> 00:05:17.155
コアアーキテクチャはかなり単純です
108
00:05:17.665 --> 00:05:19.875
インデックス構築を備えたアルゴリズム層
109
00:05:19.935 --> 00:05:22.955
そして量子化のための検索パーコレーション層
110
00:05:23.015 --> 00:05:27.035
さらに、グラフ IVF ハイブリッドを使用したリファインメントとストレージ
111
00:05:27.395 --> 00:05:29.755
アプローチで、これは業界でも実際に非常にユニークです。
112
00:05:30.185 --> 00:05:32.675
競合のほとんどはおそらく、いや、
113
00:05:32.675 --> 00:05:34.955
ほぼ IVF のようなものを使っているだけで、ええと、
114
00:05:35.015 --> 00:05:38.675
しかしこの種の IVF は、ええと、すみません、主に使われているのはグラフです。
115
00:05:39.055 --> 00:05:42.355
ええと、しかしこのタイプのグラフ IVF ハイブリッドは、ええと、興味深いです
116
00:05:42.455 --> 00:05:45.075
ワークロードに基づいて容量
117
00:05:45.135 --> 00:05:47.075
とパフォーマンスのトレードオフを調整しない限り。
118
00:05:47.495 --> 00:05:50.675
私たちのテストでは、約50%多い容量を得ており
119
00:05:50.735 --> 00:05:55.435
検索速度は、ええと、vis より最大10倍速いことが確認されています。
120
00:05:56.285 --> 00:06:00.135
ええと、低レベルの最適化もたくさん行いました、ええと、
121
00:06:00.375 --> 00:06:01.735
カーネルレベルのものや CPU
122
00:06:01.735 --> 00:06:03.655
およびメトリクス分析によって、絞り出せました、
123
00:06:04.195 --> 00:06:05.415
ええと、バッドあたりのパフォーマンスを。
124
00:06:07.105 --> 00:06:10.125
では、クラウド Cloud native
125
00:06:10.505 --> 00:06:11.525
そして fully managed についてもう少し話しましょう。
126
00:06:11.755 --> 00:06:14.045
それが実際には何を意味するのか。
127
00:06:14.785 --> 00:06:18.045
ええと、ここに比較を載せています。皆さんが
128
00:06:18.045 --> 00:06:19.085
理解しやすいようにです。
129
00:06:19.625 --> 00:06:23.885
ええと、ご覧のとおり、ええと、私たちが構築したものは、
130
00:06:23.885 --> 00:06:26.485
単なるホステッドソリューションではなく、fully managed のようなクラウドコードです。
131
00:06:26.485 --> 00:06:27.605
というものです。
132
00:06:28.265 --> 00:06:32.125
ええと、一番左の列を見ると、ええと、
133
00:06:32.185 --> 00:06:34.045
それはほぼ open source のようなものですよね?
134
00:06:34.465 --> 00:06:35.965
VIS
135
00:06:36.025 --> 00:06:38.325
または他の open source ベクターデータベースを運用したことがある人なら、ええと、
136
00:06:38.775 --> 00:06:40.965
運用上のオーバーヘッドが非常に多いことを知っています。
137
00:06:41.585 --> 00:06:44.605
ええと、open source 版は開発には素晴らしいと
138
00:06:44.705 --> 00:06:46.885
私たちは言えますが、本番環境に到達すると、
139
00:06:47.145 --> 00:06:49.685
データ移行からスケーリング、アップグレードまで、
140
00:06:49.825 --> 00:06:52.605
すべて自分で対応することになります、ええと、
141
00:06:52.605 --> 00:06:55.045
市場にはいくつかのホステッドソリューションがありますが。
142
00:06:55.345 --> 00:06:58.845
ええと、インフラストラクチャと Kubernetes 管理は得られます、ええと、
143
00:06:58.865 --> 00:07:00.365
しかし、運用関連の大部分については依然として
144
00:07:00.365 --> 00:07:01.605
自分で責任を負うことになります。
145
00:07:02.185 --> 00:07:04.805
ええと、私たちの管理アプローチが異なる点は、
146
00:07:04.835 --> 00:07:07.325
そうした本番環境の悩みをすべて私たちが処理することです。
147
00:07:07.665 --> 00:07:10.885
そのため、ゼロダウンタイムのスケーリングがあり、スケールアップ
148
00:07:11.265 --> 00:07:13.765
またはサービス中断なしでスケールダウンできます。
149
00:07:13.865 --> 00:07:15.045
これは非常に重要だと考えています。
150
00:07:15.665 --> 00:07:18.245
ええと、自動バックアップとデータ移行。
151
00:07:18.465 --> 00:07:20.605
そのため、カスタムスクリプトを書く必要も
152
00:07:20.865 --> 00:07:21.925
このプロセスを管理する必要もありません。
153
00:07:22.825 --> 00:07:25.325
ええと、特定のユースケースに基づく
154
00:07:25.325 --> 00:07:26.445
パフォーマンスチューニングがあります。
155
00:07:26.745 --> 00:07:29.565
つまり、実際のワークロードパターンに基づいて最適化します。
156
00:07:29.745 --> 00:07:32.935
ええと、うーん、それについては後でもう少し共有します。もちろんです。
157
00:07:32.935 --> 00:07:34.815
つまり、自動スケーリングがあり、ええと、
158
00:07:35.235 --> 00:07:37.175
そして手間のかからないアップデートとパッチ適用があります。
159
00:07:37.315 --> 00:07:38.615
つまり、セキュリティパッチ
160
00:07:38.615 --> 00:07:41.415
や発生するバージョンアップグレードは、ええと、まさに
161
00:07:41.415 --> 00:07:43.255
裏側で行われるので、心配する必要はありません。
162
00:07:44.045 --> 00:07:46.375
これは本質的に、チームがインフラの管理ではなく、
163
00:07:46.775 --> 00:07:48.575
機能の構築に集中できることを意味します。
164
00:07:50.325 --> 00:07:53.465
では、うーん、クラウドネイティブの大きな部分は、
165
00:07:53.465 --> 00:07:54.545
マルチテナンシーをどう管理するかでもあります。
166
00:07:54.605 --> 00:07:57.745
うーん、amik、ええと、ここでの
167
00:07:57.885 --> 00:07:59.545
マルチテナンシーの仕組みを説明してもらえますか?
168
00:08:01.675 --> 00:08:02.965
はい、もちろんです。
169
00:08:03.025 --> 00:08:07.205
マルチテナンシーに関しては、3つの、ええと、レイヤー、つまり3層のアプローチがあります。
170
00:08:07.385 --> 00:08:09.045
ええと、マルチテナンシーに関してです。
171
00:08:09.585 --> 00:08:12.925
うーん、1つ目はデータベース指向のマルチテナンシーです。
172
00:08:13.505 --> 00:08:15.245
2つ目はコレクション指向、
173
00:08:15.905 --> 00:08:18.445
そして3つ目はパーティション指向です。
174
00:08:19.225 --> 00:08:23.085
うーん、今ご覧になっているものは、ええと、私たちのパーティを説明しています。
175
00:08:23.085 --> 00:08:25.045
ええと、今ご覧の図は、私たちの
176
00:08:25.045 --> 00:08:28.125
パーティション指向の、ええと、マルチテナンシー、
177
00:08:28.685 --> 00:08:31.325
具体的にはパーティションキーに基づくマルチテナンシーを説明しています。
178
00:08:32.225 --> 00:08:35.965
そして、ええと、コレクションの作成時に、うーん、
179
00:08:35.985 --> 00:08:39.005
実際にテナントフィールドを指定して
180
00:08:39.745 --> 00:08:42.285
それをパーティションキーフィールドにすることができます。
181
00:08:43.065 --> 00:08:44.325
そして VIS
182
00:08:44.825 --> 00:08:49.205
または Zillow は基本的に、パーティションキー フィールドの
183
00:08:49.205 --> 00:08:52.845
ハッシュ値に従って、エンティティをパーティションに保存し、
184
00:08:53.185 --> 00:08:54.885
その特定のパーティションキーを含む
185
00:08:54.950 --> 00:08:56.805
パーティションだけを検索します。
186
00:08:57.665 --> 00:09:00.925
そして、この戦略が非常に効果的である理由は、
187
00:09:00.925 --> 00:09:04.685
Novus のコレクションがサポートできるテナントの最大数に関する
188
00:09:04.685 --> 00:09:06.445
制限を取り払うからです。
189
00:09:07.105 --> 00:09:09.765
ええと、例えば、コレクションにおける
190
00:09:10.505 --> 00:09:14.565
テナントの最大数は、ええと、10,000未満です。
191
00:09:15.025 --> 00:09:18.485
しかし、パーティションキーに基づくアプローチでは、
192
00:09:18.505 --> 00:09:22.085
サポートできるテナント数は、うーん、1,000万を超えます。
193
00:09:23.005 --> 00:09:25.445
さらに、パーティションキーに基づくマルチテナンシーの
194
00:09:25.645 --> 00:09:29.045
アプローチでは、例えば、うーん、
195
00:09:29.185 --> 00:09:30.445
テナントごとに1つのコレクションを使う場合
196
00:09:31.065 --> 00:09:33.725
またはすべてのテナントに対して1つのコレクションを持ち、
197
00:09:33.725 --> 00:09:36.605
そのうえで、うーん、すべての、
198
00:09:37.105 --> 00:09:38.245
うーん、各パーティションにフィルタリングシステムを使う場合よりも、はるかに高速です。
199
00:09:38.865 --> 00:09:41.005
そのため、これは拡張性
200
00:09:41.005 --> 00:09:44.285
および、ええと、速度の面で、私たちが提供する中で最も
201
00:09:44.545 --> 00:09:46.085
動的なオファリングです。
202
00:09:48.055 --> 00:09:51.765
いいですね。うーん、では続けて、
203
00:09:51.765 --> 00:09:54.485
ええと、エンタープライズ機能について少し話しましょう。
204
00:09:55.185 --> 00:09:58.165
ええと、本番データを扱うとき、セキュリティが
205
00:09:58.165 --> 00:09:59.925
重要であることは明らかです。
206
00:10:00.545 --> 00:10:02.525
私たちはこれを多層的なアプローチで構築しています。
207
00:10:02.785 --> 00:10:04.165
ええと、認証があります
208
00:10:04.165 --> 00:10:08.045
複数レベルでのSSOアクセス制御を通じたものです、ええと、
209
00:10:08.345 --> 00:10:09.685
またバックエンドのプライベートな
210
00:10:09.865 --> 00:10:12.005
エンドポイントにより、決して公開されないようにします
211
00:10:12.005 --> 00:10:13.165
あなたのデータがインターネットに。
212
00:10:13.585 --> 00:10:15.445
そしてすべてがエンドツーエンドで暗号化されています、
213
00:10:15.445 --> 00:10:17.165
転送中も保存時もです。
214
00:10:17.665 --> 00:10:19.085
ええと、デプロイメント側では、
215
00:10:19.625 --> 00:10:22.485
ご覧のとおり、これは次のような形で構成されています、
216
00:10:22.485 --> 00:10:25.205
実行したい場所が
217
00:10:25.245 --> 00:10:28.205
A-W-S-G-C-P Azure でも、bring your cloud でも柔軟性を提供するためです。
218
00:10:28.415 --> 00:10:30.645
これについては、後でもう少し詳しくお話しします。
219
00:10:31.025 --> 00:10:32.245
ええと、すべてサポートされています。
220
00:10:32.625 --> 00:10:34.525
ええと、ここで重要なのは、もし必要であれば
221
00:10:34.525 --> 00:10:37.205
データを自分のVPC内に保持することができます
222
00:10:37.815 --> 00:10:40.445
右側のこのアーキテクチャ図を見てください。
223
00:10:40.625 --> 00:10:43.005
ええと、各顧客には物理的に分離されたクラスターが割り当てられます、
224
00:10:43.545 --> 00:10:44.645
共有リソースはありません。
225
00:10:44.955 --> 00:10:47.605
あなたのサービスは他の顧客から完全に分離されています。
226
00:10:48.305 --> 00:10:50.805
ええと、下部の紫色のレイヤー、そこは、ええと、
227
00:10:50.805 --> 00:10:52.805
すべてのデータストレージを処理する場所です
228
00:10:53.075 --> 00:10:54.365
組み込みの暗号化付きで。
229
00:10:54.985 --> 00:10:57.245
稼働時間を心配している方のために言うと、ええと、
230
00:10:57.255 --> 00:10:59.725
私たちはマルチAZデプロイメントで運用しており、ええと、
231
00:10:59.725 --> 00:11:02.445
99.95%のSOAです。
232
00:11:02.585 --> 00:11:05.085
これは稼働時間で、SOAの組み込みバックアップ
233
00:11:05.305 --> 00:11:08.365
および災害復旧が、ええと、標準で付いています。
234
00:11:10.085 --> 00:11:13.545
ええと、それでは、ええと、BIOCについてもう少しお話ししましょう。
235
00:11:13.635 --> 00:11:16.025
データ主権を維持したいという
236
00:11:16.025 --> 00:11:19.785
多くのお客様からのフィードバックを聞いてきましたし、運用負荷も最小化したいということでした。
237
00:11:20.285 --> 00:11:22.145
そこで昨年BIOCをリリースしました。
238
00:11:22.425 --> 00:11:25.945
実は本日、もう一つ非常に大きなアップグレードを発表しました、
239
00:11:26.205 --> 00:11:27.545
ええと、RBLCへのものです。
240
00:11:27.575 --> 00:11:28.785
リンクは少し後で載せます
241
00:11:28.845 --> 00:11:30.665
もしこれに関心があれば確認できるように、
242
00:11:30.725 --> 00:11:32.145
ええと、デプロイメントモデルです。
243
00:11:32.925 --> 00:11:35.265
それで、ええと、お客様のニーズに応えるために、
244
00:11:35.405 --> 00:11:37.665
bring all on cloudオプションを提供しています。
245
00:11:38.215 --> 00:11:39.865
これは、必要とするチーム向けです
246
00:11:39.865 --> 00:11:42.825
通常はコンプライアンス要件のために、すべてを自分たちのVPC内に保持する必要があるチーム、
247
00:11:42.845 --> 00:11:44.465
または内部セキュリティポリシーのためです、
248
00:11:45.005 --> 00:11:49.305
現在は、ええと、AWS
249
00:11:49.305 --> 00:11:52.585
とA GCPで利用可能で、Azureサポートは近日提供予定です。
250
00:11:53.185 --> 00:11:55.405
ええと、もちろん左側にはまだ、
251
00:11:55.665 --> 00:11:58.845
ご覧のとおり、私たちの完全マネージドサービスもまだあります、
252
00:11:58.955 --> 00:12:01.565
基本的にvis Rayは特に設計されています
253
00:12:01.665 --> 00:12:03.285
クラウドネイティブなデプロイメント向けに。
254
00:12:03.745 --> 00:12:06.285
これはA-W-S-G-C-PまたはAzureで実行できます。
255
00:12:06.465 --> 00:12:07.725
私たちがすべて対応します。
256
00:12:07.795 --> 00:12:12.605
スケーリング、アップグレード、更新、メンテナンス、ええと、つまり、ええと、
257
00:12:12.785 --> 00:12:15.765
それが、ええと、それが、Zillow Cloud cellサービスです。
258
00:12:17.555 --> 00:12:20.255
では、どのようにするかについてもう少しお話しします
259
00:12:20.965 --> 00:12:25.095
まさに当社のBIOCで、ワークロードを安全にします。
260
00:12:25.575 --> 00:12:28.985
というのも、BIOCは、
261
00:12:29.165 --> 00:12:31.345
新しいものではないと聞いていますが、
262
00:12:31.345 --> 00:12:33.145
多くのベンダーが実際には正しく実装できていません。
263
00:12:33.645 --> 00:12:35.825
そこで、私たちのアプローチを皆さんに共有したいと思います。
264
00:12:36.125 --> 00:12:38.945
この図は、当社のセキュリティアーキテクチャを示しており、
265
00:12:39.505 --> 00:12:42.065
2つの異なる環境、
266
00:12:42.555 --> 00:12:45.425
つまりCloud VPCと顧客管理VPCがあります。
267
00:12:45.925 --> 00:12:49.345
左側にはCloud VPCがあり、
268
00:12:49.725 --> 00:12:52.905
ここには当社のコントロールパネル、リソース管理用のBLCコントローラー、
269
00:12:52.905 --> 00:12:53.985
そして
270
00:12:54.365 --> 00:12:56.585
パフォーマンス追跡用のシステムモニターが含まれています。
271
00:12:57.205 --> 00:13:00.305
右側は顧客管理VPCです。
272
00:13:00.565 --> 00:13:04.225
ここには、監視ツールとともに
273
00:13:04.225 --> 00:13:05.305
Kubernetesクラスター上で稼働するデプロイメントが含まれています。
274
00:13:06.045 --> 00:13:09.625
「outbound 443」とラベル付けされた矢印が見えると思います。
275
00:13:09.925 --> 00:13:12.825
これは皆さんのためにこのようにしています。
276
00:13:12.925 --> 00:13:15.625
すべてがHTTPで暗号化されています。
277
00:13:16.125 --> 00:13:17.585
そして最も重要なのは、
278
00:13:17.655 --> 00:13:20.745
この接続を開始できるのは顧客側だけだということです。
279
00:13:20.855 --> 00:13:22.905
外部から到達できるものは何もありません。
280
00:13:23.765 --> 00:13:28.105
そのため、非常に安全になります。
281
00:13:28.975 --> 00:13:31.785
そして、スケールやvisのようなリソース管理が必要な場合は、
282
00:13:31.785 --> 00:13:35.225
厳格に制限された権限を通じて行われます。
283
00:13:35.725 --> 00:13:38.425
これは実際に新しくリリースされたシステムで、
284
00:13:38.695 --> 00:13:40.065
顧客が制御します。
285
00:13:40.605 --> 00:13:44.545
特定の部屋に対して、請負業者に特定の鍵を渡すようなものだと考えてください。
286
00:13:44.625 --> 00:13:45.705
建物全体への
287
00:13:46.005 --> 00:13:48.265
マスターキーではありません。
288
00:13:48.325 --> 00:13:49.785
それが安全性を確保する方法です。
289
00:13:50.205 --> 00:13:53.145
このアウトバウンドのみの通信と
290
00:13:53.245 --> 00:13:54.385
制御された権限の組み合わせにより、
291
00:13:54.615 --> 00:13:58.545
B-R-B-B-I-O-Cは真にエンタープライズグレードのセキュリティを実現します。
292
00:14:01.135 --> 00:14:04.315
では、非常に手短にですが、実は先週、
293
00:14:04.715 --> 00:14:07.875
Milvusの新しいバージョンをリリースしました。
294
00:14:08.135 --> 00:14:09.715
たしか先週だったと思います。
295
00:14:10.415 --> 00:14:13.435
今回リリースした最も重要な機能は、
296
00:14:13.675 --> 00:14:16.595
実はMilvus 2.5がZilliz
297
00:14:16.595 --> 00:14:17.755
Cloudでパブリックプレビューとして利用可能になったことです。
298
00:14:18.145 --> 00:14:21.875
テキスト検索、
299
00:14:22.145 --> 00:14:25.755
テキストマッチング、ビットマップインデックスなど、多くの優れた機能があります。
300
00:14:25.985 --> 00:14:28.955
後ほど確認していただけるように、
301
00:14:28.975 --> 00:14:30.035
リリースノートを載せておきます。
302
00:14:30.575 --> 00:14:34.235
ですが、最もワクワクするのは全文検索です。
303
00:14:34.815 --> 00:14:36.955
Amik、私たちのテキスト検索が具体的に
304
00:14:37.055 --> 00:14:38.835
どのように機能するのか、もう少し共有してもらえますか?
305
00:14:41.665 --> 00:14:42.755
はい、もちろんです。
306
00:14:42.895 --> 00:14:46.075
全文検索の背後にある原理は、
307
00:14:46.075 --> 00:14:49.835
まず生のテキストデータを
308
00:14:50.225 --> 00:14:51.295
プラットフォームに入力することです。
309
00:14:51.755 --> 00:14:55.535
そして、それをアナライザーにかけます。
310
00:14:55.535 --> 00:14:59.295
基本的にはそれを生成し、ええと、生テキストの
311
00:14:59.715 --> 00:15:02.215
それらの、ええと、トークンに分解します。
312
00:15:02.995 --> 00:15:06.535
そしてその後、ええと、それらのトークンを、うーん、
313
00:15:06.925 --> 00:15:11.655
それらを変換する関数に渡し、うーん、
314
00:15:12.265 --> 00:15:16.755
単語をスパース埋め込みに変換します。
315
00:15:17.555 --> 00:15:20.135
そしてそれが起こると、うーん、
316
00:15:20.315 --> 00:15:22.855
次にそれらのスパース埋め込みを、うーん、
317
00:15:22.855 --> 00:15:25.615
発生するフィルタリング
318
00:15:25.615 --> 00:15:27.375
または検索に基づいてコレクション内でグループ化し、うーん、
319
00:15:27.435 --> 00:15:32.095
そしてそれを使って、ええと、ええと、それを私たちの BM 25、ええと、
320
00:15:32.095 --> 00:15:36.775
スコアリングアルゴリズムに入れて、うーん、特定の top K 結果を生成します。
321
00:15:37.555 --> 00:15:39.415
うーん、そしてユーザーが受け取る結果
322
00:15:39.415 --> 00:15:43.975
に基づいて、ユーザーはその後、うーん、ある程度修正し
323
00:15:44.275 --> 00:15:46.215
アナライザーに挿入するテキストクエリ
324
00:15:46.215 --> 00:15:48.175
を反復していくことができます。
325
00:15:48.755 --> 00:15:51.575
そして、うーん、そのフィードバックループによって、ええと、
326
00:15:51.575 --> 00:15:52.575
時間とともにより良い結果を生成できます。
327
00:15:55.555 --> 00:16:00.525
いいですね。うーん、ではより exciting なデモ部分に入りましょう。
328
00:16:00.625 --> 00:16:02.285
ええと、Amik、画面共有してもらえますか?
329
00:16:03.075 --> 00:16:04.005
はい、もちろんです。
330
00:16:06.685 --> 00:16:08.385
うーん、いいですね。
331
00:16:08.805 --> 00:16:13.675
では、そこに入っていくと、これは Zillow cloud の、ええと、
332
00:16:14.055 --> 00:16:15.235
UI とプラットフォームそのものです。
333
00:16:15.965 --> 00:16:19.145
そして左側には、クラスターを作成できる
334
00:16:19.145 --> 00:16:21.145
セクションがあります。
335
00:16:21.885 --> 00:16:25.945
うーん、バックアップの管理や、ええと、
336
00:16:26.115 --> 00:16:29.185
異なる、ええと、プラットフォームからの移行もできます。
337
00:16:29.285 --> 00:16:33.625
つまり、私たちは、ええと、VIS から Zillow への移行を
338
00:16:34.125 --> 00:16:36.065
さまざまな組織内でサポートしています。
339
00:16:36.845 --> 00:16:40.745
うーん、そして私たちが提供する機能の
340
00:16:40.765 --> 00:16:44.225
全体的な目的は、Zillow cloud
341
00:16:44.745 --> 00:16:46.545
プラットフォームをできるだけ簡単に使えるようにし、
342
00:16:46.565 --> 00:16:48.225
皆さんのチーム側で必要となる作業量を
343
00:16:49.025 --> 00:16:51.705
減らすことです。
344
00:16:51.885 --> 00:16:53.985
私たちのプラットフォームを使い始めるため
345
00:16:54.405 --> 00:16:57.985
だけでなく、私たちのプラットフォーム上で皆さんが立ち上げる
346
00:16:57.985 --> 00:17:00.505
その、その、そのコンピュートユニットを維持するためにもです。
347
00:17:00.645 --> 00:17:03.505
したがって、それが私たちが、ええと、
348
00:17:03.505 --> 00:17:05.585
多くの外部データソースからの移行をサポートしている理由です。
349
00:17:06.405 --> 00:17:10.425
うーん、また既存の組織については、ジョブの管理、
350
00:17:10.445 --> 00:17:14.185
共同作業者の管理、うーん、
351
00:17:14.285 --> 00:17:16.225
さらにはアラートの設定もできる UI を提供しています。うーん、
352
00:17:16.525 --> 00:17:19.585
データがインポートまたはエクスポートされたときに管理するためです。
353
00:17:19.885 --> 00:17:23.865
そして最後に、うーん、Steff が言及していたように、ええと、私たちは、
354
00:17:24.005 --> 00:17:26.105
プライベートエンドポイントの作成を可能にするだけでなく、
355
00:17:26.105 --> 00:17:27.865
特定のネットワークの管理も可能にしています。
356
00:17:27.865 --> 00:17:30.585
そして最後に、Datadog、
357
00:17:30.585 --> 00:17:35.185
Prometheus、そして、うーん、S3 との統合を提供し、うーん、皆さんのチームが
358
00:17:35.205 --> 00:17:37.465
ログを一元化された場所で管理できるようにしたり、
359
00:17:38.085 --> 00:17:41.665
バックアップファイルを Amazon S3 にプッシュしたりできるようにしています。
360
00:17:42.615 --> 00:17:44.875
うーん、ここでさらに深く掘り下げたいと思います
361
00:17:45.175 --> 00:17:46.435
どのように、クラスターを作成するかです。
362
00:17:47.175 --> 00:17:50.645
ええと、当社では3つのプランを提供しています。無料プラン、
363
00:17:50.645 --> 00:17:52.005
serverless、そしてdedicatedです。
364
00:17:52.315 --> 00:17:55.205
当社のエンタープライズのお客様の多くはdedicatedプランを選択されています。
365
00:17:55.545 --> 00:17:59.005
そしてちょうど今日、実際に、ええと、その機能をリリースしました。
366
00:17:59.145 --> 00:18:01.445
つまり、ええと、そちら側のユーザーが
367
00:18:01.445 --> 00:18:05.005
自分でBYOクラスター、BYOCクラスターを立ち上げられる機能です。
368
00:18:05.725 --> 00:18:09.285
以前は、それを管理するには、ITの、ええと、ええと、ITの、
369
00:18:09.285 --> 00:18:12.165
個人貢献者がそのシステムを管理する必要がありました。
370
00:18:12.625 --> 00:18:16.205
ええと、クラスターに名前を付けることができます。ええと、無料
371
00:18:16.205 --> 00:18:19.525
およびserverlessのCLクラスターでは、ええと、GCPUのみがサポートされていますが、
372
00:18:19.525 --> 00:18:22.285
dedicatedでは、3つすべてのCLO主要クラウドが
373
00:18:22.285 --> 00:18:24.525
サポートされており、これらの既存リージョンもサポートされています。
374
00:18:25.495 --> 00:18:28.075
ええと、CUタイプも3つあります。
375
00:18:28.215 --> 00:18:31.755
つまりperformance optimizedは、最も高い、ええと、
376
00:18:31.775 --> 00:18:33.875
最も低いレイテンシーと最高のスループットが必要なケース向けです。
377
00:18:34.455 --> 00:18:36.915
ええと、capacity optimizedは、それでも、
378
00:18:36.915 --> 00:18:38.195
非常に良好なLAレイテンシーが得られます。
379
00:18:38.195 --> 00:18:39.875
およそ100ミリ秒のレイテンシーが得られますが、
380
00:18:39.935 --> 00:18:43.275
ええと、より強化されたストレージ機能を備えています。
381
00:18:43.295 --> 00:18:45.435
そして最後に、extended capacityは
382
00:18:46.135 --> 00:18:49.355
最も手頃なソリューションで、ええと、
383
00:18:49.535 --> 00:18:52.715
500ミリ秒未満から1秒未満のレイテンシーですが、
384
00:18:52.715 --> 00:18:56.675
そのCUは、ええと、さらに多くのベクトルを保存できます。
385
00:18:57.395 --> 00:19:01.175
ええと、では戻りますが、これは既存のクラスターで、
386
00:19:01.175 --> 00:19:03.215
私がすでに作成したものです。
387
00:19:04.155 --> 00:19:07.695
ええと、ここでは、CUサイズとプランで
388
00:19:08.165 --> 00:19:09.855
クラスターの詳細を管理できます。
389
00:19:10.195 --> 00:19:12.375
必要であれば、ここでプランをアップグレードできます。
390
00:19:12.995 --> 00:19:16.135
ええと、CUも手動でスケールできます。
391
00:19:16.755 --> 00:19:20.705
ええと、そしてここでコレクションを管理できます。
392
00:19:21.285 --> 00:19:24.465
ええと、コレクションは、ええと、先ほど述べたように
393
00:19:24.465 --> 00:19:26.625
マルチテナンシーに使うこともできますし、
394
00:19:27.205 --> 00:19:29.785
または、特定のフィールドを持つ特定のコレクションを自分で作成できます。
395
00:19:29.805 --> 00:19:30.905
そうですね、特定のフィールドです。
396
00:19:31.005 --> 00:19:32.985
ここでスキーマを定義できます。
397
00:19:33.445 --> 00:19:35.545
ええと、そして高度な設定内でも、
398
00:19:35.545 --> 00:19:36.665
動的フィールドを作成できます。
399
00:19:36.665 --> 00:19:39.305
たとえば、スキーマを作成したとして、ええと、
400
00:19:39.925 --> 00:19:41.505
データをコレクションにロードし、
401
00:19:41.765 --> 00:19:44.905
その後、そのスキーマに、ええと、別の、ええと、
402
00:19:45.405 --> 00:19:46.585
列を追加したい場合です。
403
00:19:46.585 --> 00:19:48.625
動的なdi動的フィールドも追加できます。
404
00:19:49.005 --> 00:19:51.745
そして、もし、または、ええと、
405
00:19:52.255 --> 00:19:53.345
パーティションキーによる
406
00:19:53.345 --> 00:19:54.745
マルチテナンシーを実行したい場合は、ここで有効にできます。
407
00:19:55.565 --> 00:19:56.705
ええと、同様に、
408
00:20:00.405 --> 00:20:01.745
metricsタブは、ええと、
409
00:20:02.395 --> 00:20:04.305
あなたの、ええと、CUの健全性について示します。
410
00:20:04.645 --> 00:20:08.585
つまり、計算、ええと、計算能力です
411
00:20:09.045 --> 00:20:11.665
または、いくつの、ええと、
412
00:20:11.815 --> 00:20:14.625
ベクトルが保存されているか、ええと、などに対するストレージ容量です。
413
00:20:15.125 --> 00:20:17.105
そしてユーザーについても、ここで
414
00:20:17.105 --> 00:20:18.385
少し
415
00:20:18.385 --> 00:20:22.145
ロールベースのアクセス制御を行い、ええと、誰が制御権を持つかを確認できます。
416
00:20:23.065 --> 00:20:26.125
ええと、たとえば、複数の、ええと、
417
00:20:26.185 --> 00:20:28.965
ここでも異なるユーザーロールを、ええと、選択できます。
418
00:20:30.095 --> 00:20:35.065
ええと、できます、ええと、それから、ええと、これはより、
419
00:20:35.165 --> 00:20:36.985
ええと、コレクションレベルであり、一方で
420
00:20:36.985 --> 00:20:38.145
こちらはよりクラスターレベルです。
421
00:20:38.205 --> 00:20:43.185
ですので、ここでは異なる権限を割り当てることができます、ええと、
422
00:20:43.605 --> 00:20:46.145
異なる、ええと、粒度のレベルに対してです。
423
00:20:46.565 --> 00:20:50.645
ええと、そしてこのスライドが、ええと、最もよく説明していると思います。
424
00:20:50.825 --> 00:20:54.845
つまり、ええと、組織レベルでは、ええと、
425
00:20:54.985 --> 00:20:57.685
プロジェクトレベルと同様に権限を割り当てることができます。
426
00:20:57.825 --> 00:21:00.045
それが実際にコントロールプレーンに保存されるものです。
427
00:21:00.265 --> 00:21:02.085
そして、データに誰がアクセスするかについて
428
00:21:02.085 --> 00:21:03.965
慎重な顧客向けのデータプレーン内では、
429
00:21:04.265 --> 00:21:08.405
クラスターレベルのロールを提供しています、ええと、それは、ええと、
430
00:21:08.455 --> 00:21:10.045
UIでご覧になっていたもので、
431
00:21:10.045 --> 00:21:11.125
データベースレベル、
432
00:21:11.185 --> 00:21:13.605
そして、コレクションレベルでもあります。
433
00:21:15.545 --> 00:21:19.005
ええと、ですのでクラスター内で、ええと、
434
00:21:19.185 --> 00:21:20.845
データベース権限と
435
00:21:20.845 --> 00:21:21.925
クラスター権限の間で選択できることがわかります。
436
00:21:21.925 --> 00:21:25.085
さらに、たとえば、読み取り専用、読み取り、ReadWrite
437
00:21:25.185 --> 00:21:27.965
または管理者権限もあります。
438
00:21:28.585 --> 00:21:33.255
ええと、そして最後に、ええと、この画面では、
439
00:21:33.275 --> 00:21:34.495
ええと、バックアップを生成できます。
440
00:21:34.495 --> 00:21:36.935
データの自動バックアップをスケジュールすることもできますし、
441
00:21:37.315 --> 00:21:38.775
手動バックアップをスケジュールすることもできます。
442
00:21:38.995 --> 00:21:43.295
さらに、これらのバックアップを、ええと、S3バケットにプッシュすることもできます
443
00:21:43.565 --> 00:21:46.545
私たちの、ええと、インテグレーションを使ってです。
444
00:21:47.765 --> 00:21:52.045
ええと、そしてコレクション自体の中では。
445
00:21:52.185 --> 00:21:54.245
つまり、コレクションをクリックすると、
446
00:21:54.905 --> 00:21:58.795
確認できるのは、管理する方法も提供できるということです、ええと、
447
00:21:59.555 --> 00:22:00.995
各個別のコレクションをです。
448
00:22:01.015 --> 00:22:03.835
ここでは、作成されたスキーマを確認できます、ええと、
449
00:22:03.835 --> 00:22:05.995
フィールドタイプや値とともにです。
450
00:22:06.655 --> 00:22:08.675
ええと、ここでデータをインポートできます。
451
00:22:09.215 --> 00:22:11.755
ええと、データを挿入したい場合は、私たちは、ええ、
452
00:22:11.825 --> 00:22:15.975
それをシームレスに、ええと、
453
00:22:16.435 --> 00:22:17.775
実行するために必要な、ええと、APIコードを提供します。
454
00:22:18.355 --> 00:22:21.195
ええと、データのプレビューも確認できます。
455
00:22:21.255 --> 00:22:23.115
ここでは、ベクトルが一覧表示されているのを確認でき、
456
00:22:23.115 --> 00:22:24.315
必要なすべてのフィールドも表示されます。
457
00:22:25.055 --> 00:22:27.395
そして最後に、ベクトル検索を実行できます
458
00:22:27.755 --> 00:22:29.315
実際にプラットフォーム内でもです。
459
00:22:29.695 --> 00:22:32.855
ですので、ここにクエリベクトルを入力できます、ええと、
460
00:22:34.395 --> 00:22:36.775
topの値を変更したり、フィルターを追加することもできます。
461
00:22:37.395 --> 00:22:39.655
つまり、フィルターもまた別の方法です
462
00:22:39.655 --> 00:22:42.655
コレクションレベルでマルチテナンシーを実行するための、ええと、
463
00:22:42.755 --> 00:22:44.815
フィルタリング用のコレクションを指定するための方法です。
464
00:22:44.815 --> 00:22:47.575
ただし、パーティションキーの使用を強くお勧めします
465
00:22:47.915 --> 00:22:49.255
マルチテナンシーを実行するには、単に
466
00:22:49.255 --> 00:22:52.775
パフォーマンスがはるかに優れているからです、ええと、私たちの、
467
00:22:52.775 --> 00:22:55.255
アルゴリズムでは、パーティションキーに基づく
468
00:22:55.255 --> 00:22:58.055
マルチテナンシーアプローチを使用する場合、コレクションレベルの、ええと、
469
00:22:58.205 --> 00:23:00.495
フィルタリングベースのマルチテナンシーアプローチと比べてです。
470
00:23:01.555 --> 00:23:03.815
ええと、ここでは実際にベクトル検索も
471
00:23:03.955 --> 00:23:07.135
実行できます、ええと、そして、ええ、結果を見ることができます。
472
00:23:07.395 --> 00:23:11.455
ええと、ええ、そうですね、これで、ええと、
473
00:23:11.845 --> 00:23:16.245
これで、デモは終わりです、ええと、
474
00:23:16.545 --> 00:23:18.125
私のほうは、そう思います。
475
00:23:20.855 --> 00:23:22.945
いいですね。何か、ええと、質問はありますか?
476
00:23:23.205 --> 00:23:25.745
ええと、Q&A に貼り付けてください。
477
00:23:26.405 --> 00:23:29.065
ええと、実はもう一人のチームメンバーである John、私たちの責任者で、
478
00:23:29.065 --> 00:23:31.145
ええと、DevRel の責任者もここにいます、ええと。
479
00:23:31.565 --> 00:23:35.625
なので、ええと、デモに関して
480
00:23:36.245 --> 00:23:40.945
または製品や何でも、ええと、それらに関連することについて、ええと、
481
00:23:41.135 --> 00:23:42.425
遠慮なく私たちに送ってください。
482
00:23:43.325 --> 00:23:45.330
これは私たちがデモを行う初めての機会です。
483
00:23:45.985 --> 00:23:48.525
何かフィードバックがあれば、ええと、
484
00:23:49.305 --> 00:23:51.045
それも本当にありがたいです。
485
00:23:51.045 --> 00:23:55.885
私たちのほうに送ってください。はい。
486
00:23:55.985 --> 00:23:58.845
ええと、すべてをうまく説明できたようですね。
487
00:23:58.845 --> 00:24:00.405
今のところ質問はありませんが、
488
00:24:00.425 --> 00:24:03.765
後で何か思いついたら、ええと、遠慮なく
489
00:24:03.765 --> 00:24:08.525
私たちの、ええと、ああ、ええと、定期的なトレーニングの予定がありますね。
490
00:24:09.345 --> 00:24:11.765
ええと、定期的なトレーニングとはどういう意味ですか?
491
00:24:11.765 --> 00:24:14.285
Google と同じように、私たちは、この種の
492
00:24:14.285 --> 00:24:15.645
デモを、ええと、毎月行う予定です。
493
00:24:16.225 --> 00:24:19.205
実際、私たちは多くの、ええと、ウェビナーもあります、ええと、
494
00:24:19.345 --> 00:24:21.685
さまざまな種類の、ええと、トピックを扱うためのものです。
495
00:24:21.875 --> 00:24:24.245
その一部はよりハンズオンで、一部は
496
00:24:24.245 --> 00:24:27.285
トレンドについて話すものです、例えば
497
00:24:27.385 --> 00:24:31.045
他の、ええと、ああ、わかりました。
498
00:24:31.605 --> 00:24:33.045
今のところ正式な
499
00:24:33.195 --> 00:24:34.445
種類のプログラムはないと思います。
500
00:24:34.585 --> 00:24:38.005
ええと、でも、ええと、私たちの、ええと、ウェブサイト Learn に行けば
501
00:24:38.005 --> 00:24:41.365
まだたくさんのリソースがあります、
502
00:24:41.745 --> 00:24:43.725
そして those are come slash learn
503
00:24:44.065 --> 00:24:46.245
そこにはたくさんの良いリソースがあります。
504
00:24:50.955 --> 00:24:54.645
はい。では、ええと、ひとつ、ああ、ここに質問がひとつあると思います。
505
00:24:55.785 --> 00:24:56.845
ええと、Sergo、
506
00:24:56.905 --> 00:24:59.925
ZI と vus についてもっと知りたい場合は、
507
00:25:00.145 --> 00:25:03.365
ええと、遠慮なく私たちにメッセージを送ってください。
508
00:25:03.505 --> 00:25:06.645
できます、つまり、それが、ええと、単発のもので、あなたが
509
00:25:06.645 --> 00:25:09.525
特定の機能のようなものについて
510
00:25:09.865 --> 00:25:13.005
何か学びたい場合や、特定のユースケースがある場合は、ええと、
511
00:25:13.095 --> 00:25:14.765
サポートを通じて私たちに連絡できます
512
00:25:15.345 --> 00:25:19.125
または、オープンソースの vu のユースケースがある場合は、Vu の、
513
00:25:19.465 --> 00:25:22.285
ええと、オフィスアワーが毎週2回予定されています。
514
00:25:22.745 --> 00:25:27.315
ええと、ですので、ええと、mill.io のウェブサイトを、ええと、
515
00:25:28.135 --> 00:25:31.715
このクラウド向けの meals オフィスアワーについて確認できますし、
516
00:25:31.715 --> 00:25:32.835
z cloud.com に連絡できます。
517
00:25:32.835 --> 00:25:34.195
サポートページがあります。
518
00:25:34.335 --> 00:25:37.555
書面形式で私たちに連絡できます。ありがとうございます。
519
00:25:38.505 --> 00:25:41.645
ええと、my young、あなたは、質問したいんですよね、ええ、
520
00:25:41.645 --> 00:25:42.925
ライブで質問して大丈夫です。
521
00:25:42.925 --> 00:25:47.425
大丈夫です。ええ。話したいですか?
522
00:25:47.625 --> 00:25:49.425
ミュートを解除して話せると思います。ええ、
523
00:25:50.215 --> 00:25:51.215
ええ。ええと、今のところ
524
00:25:51.215 --> 00:25:53.385
質問はありません。わかりました。
525
00:25:53.685 --> 00:25:57.785
でも、ええと、あなたが用意しているセッションから、ええと、学んだら、
526
00:25:58.135 --> 00:26:01.785
それから、ええと、その後で、ええと、
527
00:26:02.535 --> 00:26:06.225
LinkedIn に質問を投稿します。それでよければ。ええ、
528
00:26:06.655 --> 00:26:07.655
ええ。では、
529
00:26:07.655 --> 00:26:10.065
vis.io にリンクを貼りました。
530
00:26:10.065 --> 00:26:13.065
すみません、vis io slash Discord にもう1つあります。
531
00:26:13.325 --> 00:26:17.025
ええと、それはまた別の、ええと、素晴らしい、ええと、
532
00:26:17.175 --> 00:26:19.585
チャンネルコミュニティで、ええと、私たちや、
533
00:26:19.645 --> 00:26:23.385
他の、他の、ええと、他の開発者で、
534
00:26:23.925 --> 00:26:25.065
ええと、Melva と Zoles を使っている人たちとつながれます。
535
00:26:27.045 --> 00:26:28.295
わかりました。ありがとうございます。
536
00:26:32.625 --> 00:26:35.035
わかりました。ええと、今日はこれで大丈夫だと思います。
537
00:26:35.255 --> 00:26:37.315
ええと、皆さんのお時間に本当に感謝します。
538
00:26:37.575 --> 00:26:42.455
ええと、それでは、ええと、ええと、引き続き連絡を取り合いましょう。バイバイ。