Software for reckoning AnVIL/Terra usage
May 19, 2021
Contents
1 Introduction
Detailed billing information is essential for cost and resource planning in cloud based analysis projects, but it can be difficult to obtain. The goal of this software is to help users of the Terra/AnVIL platform get access to this data as easily as possible.
The google cloud platform console can be used to acquire information at varying levels of detail. For example, it is simple to generate a display like the following.
Cost track from Google console.
However, the cost track here sums up charges for various activities related to CPU usage, storage, and network use. Our aim is to provide R functions to help present information on charges arising in the use of AnVIL.
To whet the appetite, we will show how to run an exploratory app that looks like:
Early view of reckoning app.
2 Installation
Install the AnVILBilling package with
if (!requireNamespace("BiocManager", quietly = TRUE))
install.packages("BiocManager", repos = "https://cran.r-project.org")
BiocManager::install("AnVILBilling")Once installed, load the package with
3 Setup
The functions in this vignette require a user to connect the billing export in the Google Cloud Platform project associated with Terra/AnVIL to a BigQuery dataset.
General information on this process can be found here:
https://cloud.google.com/billing/docs/how-to/export-data-bigquery
In order to set this up with the AnVIL/Terra system:
- Create a new project in Google under the billing account linked to the Terra project
- Create a BigQuery dataset to store the billing export
- Go to the billing tab in the gcloud console and enable export to this dataset
- Make sure the user of this software has the BigQuery scope on the billing project
Once this is accomplished you will be able to see
exportview
with values appropriate to your project and account configuration substituted for ‘landmarkMark2’ (the compute project name), ‘bjbilling’ (the Google project with BigQuery scope that is used to transmit cost data on landmarkMark2 to Bigquery), and ‘anvilbilling’ (the BigQuery dataset name where next-day cost values are stored).
4 Obtaining billing data
4.1 Overview
Billing data is generally available 1 day after incurring charges. Billing data is stored in BigQuery in a partitioned table, and is queryable using the bigrquery package.
4.2 Setting up a request
In order to generate a request you need:
- start: date of start of reckoning
- end: date of end of reckoning
- project: GCP project id
- dataset: GCP dataset id for billing data in BigQuery
- table: GCP table for billing data in BigQuery
Then you can use the function:
setup_billing_request(start, end, project, dataset, table, billing_code)To create a request.
Once you have a request object, then you can get the billing data associated with that request using the reckon() function on your billing request.
4.3 Output
The result of a reckoning on a billing request is an instance of avReckoning
We took a snapshot of usage in a project we work on, and it is available as demo_rec. This request represents one day of usage in AnVIL/Terra.
## AnVIL reckoning info for project bjbilling
## starting 2020-01-28, ending 2020-01-29.
## There are 1599 records.
## Available keys:
## [1] "goog-resource-type" "goog-metric-domain"
## [3] "goog-dataproc-cluster-name" "goog-dataproc-cluster-uuid"
## [5] "goog-dataproc-location" "cromwell-workflow-id"
## [7] "goog-pipelines-worker" "terra-submission-id"
## [9] "wdl-task-name" "security"
## [11] "ad-anvil_devs" "ad-auth_anvil_anvil_gtex_v8_hg38"
## ---
## Use ab_reckoning() for full tableThe available keys for the billing object are shown.
For Terra, 3 of the most useful keys are:
- terra-submission-id : this key is associated with a cromwell workflow execution
- cromwell-workflow-id : this key is associated with a job in a workflow, so if you apply a workflow to multiple inputs, you will have 1 terra id and multiple cromwell ids
- goog-dataproc-cluster-name : this key is associated with a jupyter notebook or Rstudio cluster on Terra. The user of these resources can be determined using Bioconductor’s AnVIL package.
The code, to be used while the cluster is in use, would look like this:
library(AnVIL)
leo = Leonardo()
leo$getCluster(clustername)5 Drilling down
Given a key type, we want to know associated values.
## [1] "terra-196d3163-4eef-46e8-a7e6-e71c0012003d"To understand activities associated with this submission, we subset the table.
## # A tibble: 955 x 17
## billing_account_id service sku usage_start_time usage_end_time
## <chr> <list> <list> <dttm> <dttm>
## 1 015E39-38569D-3CC~ <named l~ <named ~ 2020-01-28 20:00:00 2020-01-28 21:00:00
## 2 015E39-38569D-3CC~ <named l~ <named ~ 2020-01-28 20:00:00 2020-01-28 21:00:00
## 3 015E39-38569D-3CC~ <named l~ <named ~ 2020-01-28 20:00:00 2020-01-28 21:00:00
## 4 015E39-38569D-3CC~ <named l~ <named ~ 2020-01-28 20:00:00 2020-01-28 21:00:00
## 5 015E39-38569D-3CC~ <named l~ <named ~ 2020-01-28 20:00:00 2020-01-28 21:00:00
## 6 015E39-38569D-3CC~ <named l~ <named ~ 2020-01-28 20:00:00 2020-01-28 21:00:00
## 7 015E39-38569D-3CC~ <named l~ <named ~ 2020-01-28 20:00:00 2020-01-28 21:00:00
## 8 015E39-38569D-3CC~ <named l~ <named ~ 2020-01-28 20:00:00 2020-01-28 21:00:00
## 9 015E39-38569D-3CC~ <named l~ <named ~ 2020-01-28 20:00:00 2020-01-28 21:00:00
## 10 015E39-38569D-3CC~ <named l~ <named ~ 2020-01-28 20:00:00 2020-01-28 21:00:00
## # ... with 945 more rows, and 12 more variables: project <list>, labels <list>,
## # system_labels <list>, location <list>, export_time <dttm>, cost <dbl>,
## # currency <chr>, currency_conversion_rate <dbl>, usage <list>,
## # credits <list>, invoice <list>, cost_type <chr>The following data is available in this object
## [1] "billing_account_id" "service"
## [3] "sku" "usage_start_time"
## [5] "usage_end_time" "project"
## [7] "labels" "system_labels"
## [9] "location" "export_time"
## [11] "cost" "currency"
## [13] "currency_conversion_rate" "usage"
## [15] "credits" "invoice"
## [17] "cost_type"You can drill down more to see what products used during the submission:
## [1] "Storage PD Capacity"
## [2] "SSD backed PD Capacity"
## [3] "Network Inter Zone Ingress"
## [4] "Network Intra Zone Ingress"
## [5] "External IP Charge on a Standard VM"
## [6] "Custom Instance Ram running in Americas"
## [7] "Custom Instance Core running in Americas"
## [8] "Licensing Fee for Shielded COS (CPU cost)"
## [9] "Licensing Fee for Shielded COS (RAM cost)"
## [10] "Network Internet Ingress from APAC to Americas"
## [11] "Network Internet Ingress from EMEA to Americas"
## [12] "Network Google Egress from Americas to Americas"
## [13] "Network Internet Ingress from China to Americas"
## [14] "Network Google Ingress from Americas to Americas"
## [15] "Network Internet Egress from Americas to Americas"
## [16] "Network Internet Ingress from Americas to Americas"
## [17] "Network Internet Ingress from Australia to Americas"
## [18] "Network HTTP Load Balancing Ingress from Load Balancer"
## [19] "Network Inter Region Ingress from Americas to Americas"
## [20] "Network Egress via Carrier Peering Network - Americas Based"
## [21] "Network Ingress via Carrier Peering Network - Americas Based"
## [22] "Licensing Fee for Container-Optimized OS from Google (CPU cost)"
## [23] "Licensing Fee for Container-Optimized OS from Google (RAM cost)"
## [24] "Licensing Fee for Container-Optimized OS - PCID Whitelisted (CPU cost)"
## [25] "Licensing Fee for Container-Optimized OS - PCID Whitelisted (RAM cost)"6 Using the exploratory app
To simplify some of the aspects of reporting on costs, we have introduced
browse_reck, which will authenticate the user to Google BigQuery, and
use user-specified inputs to identify an interval of days between which
usage data are sought. This function can be called with no arguments,
or you can supply the email address for the Google identity to be used
in working with Google Cloud Platform projects and BigQuery.
7 Session Information
## R version 4.1.0 RC (2021-05-10 r80283)
## Platform: x86_64-w64-mingw32/x64 (64-bit)
## Running under: Windows Server x64 (build 17763)
##
## Matrix products: default
##
## locale:
## [1] LC_COLLATE=C
## [2] LC_CTYPE=English_United States.1252
## [3] LC_MONETARY=English_United States.1252
## [4] LC_NUMERIC=C
## [5] LC_TIME=English_United States.1252
##
## attached base packages:
## [1] stats graphics grDevices utils datasets methods base
##
## other attached packages:
## [1] magrittr_2.0.1 dplyr_1.0.6 AnVILBilling_1.2.0 BiocStyle_2.20.0
##
## loaded via a namespace (and not attached):
## [1] tidyselect_1.1.1 xfun_0.23 bslib_0.2.5.1
## [4] purrr_0.3.4 colorspace_2.0-1 vctrs_0.3.8
## [7] generics_0.1.0 viridisLite_0.4.0 htmltools_0.5.1.1
## [10] yaml_2.2.1 plotly_4.9.3 utf8_1.2.1
## [13] rlang_0.4.11 jquerylib_0.1.4 pillar_1.6.1
## [16] later_1.2.0 glue_1.4.2 DBI_1.1.1
## [19] bit64_4.0.5 dbplyr_2.1.1 lifecycle_1.0.0
## [22] stringr_1.4.0 munsell_0.5.0 gtable_0.3.0
## [25] bigrquery_1.3.2 htmlwidgets_1.5.3 evaluate_0.14
## [28] knitr_1.33 fastmap_1.1.0 ps_1.6.0
## [31] httpuv_1.6.1 fansi_0.4.2 Rcpp_1.0.6
## [34] xtable_1.8-4 promises_1.2.0.1 scales_1.1.1
## [37] DT_0.18 BiocManager_1.30.15 jsonlite_1.7.2
## [40] shinytoastr_2.1.1 mime_0.10 bit_4.0.4
## [43] ggplot2_3.3.3 digest_0.6.27 stringi_1.6.2
## [46] bookdown_0.22 shiny_1.6.0 grid_4.1.0
## [49] cli_2.5.0 tools_4.1.0 sass_0.4.0
## [52] lazyeval_0.2.2 tibble_3.1.2 tidyr_1.1.3
## [55] crayon_1.4.1 pkgconfig_2.0.3 ellipsis_0.3.2
## [58] data.table_1.14.0 lubridate_1.7.10 rstudioapi_0.13
## [61] assertthat_0.2.1 rmarkdown_2.8 httr_1.4.2
## [64] R6_2.5.0 compiler_4.1.0