Berbagi kredensial di seluruh permintaan API akan meningkatkan performa dan menghindari overhead berlebihan yang dapat mengakibatkan error batas kapasitas. Panduan ini menjelaskan cara mengoptimalkan pengelolaan kredensial OAuth2 sehingga aplikasi Anda dapat berinteraksi dengan Google Ads API secara efisien.
Strategi berbagi kredensial akan bergantung pada apakah aplikasi Anda multithread atau multiproses (atau didistribusikan). Aplikasi yang multiproses dan multi-thread dalam setiap proses harus menerapkan kedua strategi tersebut. Strategi ini juga dapat disesuaikan untuk beberapa akun Google Ads.
Multi-thread
Setiap sesi atau pengguna yang digambar oleh thread harus menggunakan objek kredensial yang sama. Muat ulang token akses juga harus dilakukan secara sinkron untuk menghindari kondisi race.
Library klien kami memastikan bahwa kredensial adalah objek thread-safe yang
memperbarui dirinya sendiri secara sinkron saat token aksesnya berakhir. Setiap library klien kami
memiliki objek sesi (atau pengguna) dengan kredensial yang digunakan kembali
sepanjang masa aktifnya. Untuk membagikan kredensial ke seluruh thread, Anda cukup
membuat setiap sesi menggunakan kredensial yang sama. Misalnya, di library klien Java, Anda akan membuat singleton Credential dan membagikannya ke semua sesi.
Multiproses atau terdistribusi
Untuk proses multiproses atau proses terdistribusi, Anda harus mempertahankan kredensial sebelum dapat membagikannya. Untuk memastikan beberapa proses atau server tidak mencoba memuat ulang kredensial secara bersamaan, yang mengakibatkan permintaan refresh yang berlebihan, Anda harus menetapkan refresh ke satu proses.
Misalnya, tugas atau layanan terpisah dapat bertanggung jawab untuk memperbarui kredensial secara berkala dan secara proaktif mengirimkannya ke penyimpanan data yang digunakan bersama oleh kumpulan server. Setiap server kemudian dapat mengambil kredensial dari penyimpanan data saat membuat permintaan API.
Muat ulang lowongan
Tugas refresh tidak boleh menunggu hingga kredensial saat ini berakhir masa berlakunya sebelum memulai pemuatan ulang. Melakukannya dapat menyebabkan aplikasi terhenti karena tidak memiliki kredensial yang valid. Namun, jika token akses kredensial berakhir masa berlakunya saat permintaan API sedang diproses, permintaan akan tetap lengkap, dan hasilnya akan ditampilkan.
Sebaiknya pantau waktu saat token akses terakhir diperbarui, dan paksa refresh jika masih ada waktu kurang dari 5 menit hingga masa berlakunya habis.
Jika tidak tahu kapan token akses terakhir diperbarui, Anda dapat mencoba memperbaruinya dengan asumsi bahwa masa berlaku token sudah berakhir. Jika token akses tidak mendekati siklus, server akan menampilkan token akses yang sama, beserta sisa milidetik hingga token berakhir masa berlakunya.
Penyimpanan data
Anda dapat menggunakan penyimpanan data yang sudah ada atau men-deploy penyimpanan data khusus untuk berbagi kredensial antar-server. Solusinya mencakup server cache, seperti Memcached atau Infinispan, atau penyimpanan data NoSQL, seperti MongoDB.
Penyimpanan data harus dioptimalkan untuk operasi pembacaan yang cepat karena akan ada lebih banyak permintaan baca daripada penulisan. Selain itu, kredensial harus disimpan dengan aman.
Saat menyimpan kredensial, Anda harus menyimpan expiry_time yang dihitung (sekarang + expires_in) dan refresh_token bersama access_token. expiry_time
dihitung sebagai waktu permintaan refresh access_token
ditambah waktu expires_in.
Kumpulan server
Setiap server atau proses dalam kumpulan mengambil kredensial terbaru dari penyimpanan data sebelum membuat permintaan. Selama tugas refresh berjalan dengan benar, kredensial akan valid. Namun, jika tugas refresh atau penyimpanan data gagal, Anda harus memiliki mekanisme penggantian.
Jika server atau proses tidak bisa mendapatkan kredensial dari penyimpanan data, atau jika kredensial sudah tidak berlaku, server harus memuat ulang kredensialnya sendiri agar aplikasi dapat terus bekerja dengan API hingga masalah teratasi.
Pengelolaan kredensial untuk beberapa akun
Kredensial yang dibuat untuk akun pengelola Google Ads dapat digunakan untuk mengakses semua akun turunannya. Oleh karena itu, bagi pengguna dengan satu hierarki akun pengelola, biasanya cukup membuat kredensial untuk akun pengelola tingkat teratas yang akan digunakan untuk semua akun Google Ads di bawahnya.
Jika aplikasi Anda perlu mengakses akun Google Ads yang tidak terkait satu sama lain dalam hierarki akun pengelola, Anda harus membuat dan mempertahankan kredensial yang berbeda untuk akun yang berbeda, misalnya untuk setiap akun klien Google Ads yang Anda akses, atau setiap akun pengelola tingkat teratas di hierarki independen yang Anda akses.
Anda dapat mengikuti strategi yang sama untuk aplikasi multithread atau
multiproses / terdistribusi dengan sedikit perubahan. Saat menggunakan penyimpanan data bersama, kredensial harus diindeks oleh ID akun customerId untuk memastikan kredensial dikaitkan dengan akun yang benar.
Selain itu, tugas refresh akan terus memperbarui semua kredensial. Jika akun
baru ditautkan, tugas pemuatan ulang mungkin perlu dipicu.
Terakhir, di aplikasi multi-thread, Anda hanya boleh membagikan objek kredensial di seluruh thread yang beroperasi di akun yang terkait dengan objek kredensial.