Use the getting started guide to create a tenant and start your free trial. This tenant can be your personal tenant, or shared with others. It can not be renamed.
If the tenant is already created, add more users to it. Click the “account” button in the Vespa Cloud Console (top right in the tenant view), then “users”. From this view you can manage users in the tenant, and their roles - from here, you can add/set tenant admins. The user email must have a Google or GitHub account associated.
Vespa Cloud currently uses Auth0 with Google or GitHub login only, contact Vespa Cloud Support.
When starting the free trial, you are asked to accept Terms of Service. For paid plans, this is covered by the contract.
Contact Vespa Cloud Support for a contract. Click “account”, then “billing” in the console to enter information required for billing. Use Vespa Cloud Support if you need to provide this information without console login.
See vector-search for examples of how to feed and query with security credentials.
Use the “Resource view” per instance in the Console to assess current and auto-suggested resources. See Autoscaling for how to automate.
Managing resources is easy, as most changes are automated. Adding / removing / changing nodes starts automated data migration, see Elastic Vespa.
Schema changes might require data reindexing, which is automated, but takes some time. Other schema changes require data refeed - details
Use the Memory Visualizer to evaluate how memory is allocated to the fields.
Fields can be index, attribute and summary, and combinations of these,
with settings like fast-search that affects memory usage.
Attributes is a great read for understanding Vespa memory usage.
Listing archived objects can fail,
e.g. gsutil -u my_project ls gs://vespa-cloud-data-prod-gcp-us-central1-f-12345f/my_tenant can fail with
AccessDeniedException: 403 me@mymail.com does not have serviceusage.services.use access to the Google Cloud project.
Permission \'serviceusage.services.use\' denied on resource (or it may not exist).
This can be due to missing rights on your Google project (my_project in the example above)
- from the Google documentation:
“The user account accessing the Cloud Storage Bucket must be granted the Service Usage Consumer role
(see https://cloud.google.com/service-usage/docs/access-control)
in order to charge the specified user project for the bucket usage cost”
Autoscaling is the best guide to understand how to size and autoscale the system. Container clusters are stateless and can be autoscaled more quickly than content clusters.
It is not possible to autoscale content clusters for 8x load increase in 5 minutes, as this requires both provisioning and data migration. Such use cases are best discussed with the Vespa Team to understand the resource bottlenecks, tradeoffs and mitigations. Also read Graceful Degradation.
It depends. Vespa aims to adapt to resources (like auto thread config based on virtual node thread count) and actual use (when to run maintenance jobs like compaction), but there are tradeoffs that applications owners can/should make. Start off by reading the Vespa Serving Scaling Guide, then run benchmarks and use the dashboards.
Vespa Cloud applications have a Prometheus endpoint. Find guides for how to integrate with Grafana and AWS Cloudwatch at monitoring.
Vespa Cloud has detailed dashboards linked from the monitoring tab in the Console, one for each zone the instance is deployed to.
Vespa is normally upgraded daily. There are exceptions, like holidays and weekends. During upgrades, nodes are stopped one-by-one per cluster. As all clusters have one redundant node, serving and write traffic is not impacted by upgrades. Before the upgrade, the application’s system and staging tests are run, halting the upgrade if they fail. Documents are re-migrated to the upgraded node before doing the next node, see Elastic Vespa for details.
Issues like Feed Blocked, Deployment and Deprecation warnings show up in the console. There are no warnings on redundancy level / searchable copies, as redundant document buckets are activated for queries automatically, and auto data-migration kicks in for node failures / replacements.
The management of data stored in an application running on Vespa Cloud is the responsibility of the application owner and, as such, Vespa Cloud does not have any retention policy for this data as long as it is stored by the application.
The following data retention policies applies to Vespa Cloud:
It does not, but it is a great feature request!
Vespa Cloud is build on Vespa.ai. Find documentation and support resources on this site for how to feed / query / rank with Vespa.
Vespa Cloud itself is not yet certified. It is deployed on AWS, see iso-27001-faqs and soc-faqs.
Read more in GDPR.
Vespa is most often used for queries in data written from the information sources, although it can also be used without data, e.g. for model serving. It is the application owner that writes the integration with Vespa Cloud to write data.
Vespa Cloud uses LUKS2 with default aes-xts-plain64 encryption for all file storage.
Also, Vespa Cloud uses AWS EC2 instances with local or remote storage, encrypted at rest - see
encryption-of-data-at-rest.
See the security guide for roles and permissions. The Vespa Cloud Console has a log view tool, and logs / access logs can be exported to the customer’s AWS account easily. Deployment operations are tracked in the deployment view, with a history. Vespa Cloud Operators do not have node access, unless specifically granted by the customer, audit logged.
At termination, all application instances are removed, with data, before the tenant can be deactivated.
In dev zones we use shared resources hence have more than one node on each host/instance. In order to provide a best possible overall responsiveness we do not restrict CPU resources for the individual application nodes.