Strategi pengelolaan kredensial

Membagikan kredensial di seluruh permintaan API Anda akan meningkatkan performa dan menghindari overhead berlebihan yang dapat menyebabkan error batas kecepatan. Panduan ini menjelaskan cara mengoptimalkan pengelolaan kredensial OAuth2 sehingga aplikasi Anda dapat berinteraksi secara efisien dengan Google Ads API.

Strategi berbagi kredensial Anda akan bergantung pada apakah aplikasi Anda multithreaded atau multiprocess (atau terdistribusi). Aplikasi yang bersifat multiproses dan multithread dalam setiap proses harus menggunakan kedua strategi tersebut. Strategi ini juga dapat disesuaikan untuk beberapa akun Google Ads.

Multi-thread

Setiap sesi atau pengguna yang ditarik oleh thread harus menggunakan objek kredensial yang sama. Penyegaran token akses juga harus dilakukan secara sinkron untuk menghindari kondisi persaingan.

Library klien kami memastikan bahwa kredensial adalah objek yang aman untuk thread yang memperbarui dirinya secara sinkron saat token aksesnya berakhir. Setiap pustaka klien kami memiliki objek sesi (atau pengguna) dengan kredensial yang digunakan kembali selama masa pakainya. Untuk membagikan kredensial di seluruh thread, Anda cukup membuat setiap sesi menggunakan kredensial yang sama. Misalnya, di library klien Java, Anda akan membuat singleton Credential dan membagikannya di semua sesi.

Multiprocess atau terdistribusi

Untuk proses multiproses atau terdistribusi, Anda harus mempertahankan kredensial sebelum dapat membagikannya. Untuk memastikan bahwa beberapa proses atau server tidak mencoba memperbarui kredensial secara bersamaan, yang mengakibatkan permintaan pembaruan yang berlebihan, Anda harus menetapkan pembaruan ke satu proses.

Misalnya, tugas atau layanan terpisah dapat bertanggung jawab untuk memperbarui kredensial secara berkala dan mendorongnya secara proaktif ke penyimpanan data yang dibagikan oleh kumpulan server. Setiap server kemudian dapat mengambil kredensial dari penyimpanan data saat membuat permintaan API.

Memuat ulang tugas

Tugas refresh tidak boleh menunggu hingga kredensial saat ini berakhir sebelum memulai refresh. Melakukannya dapat menyebabkan aplikasi terhenti karena tidak adanya kredensial yang valid; meskipun, jika token akses kredensial berakhir saat permintaan API sedang diproses, permintaan akan tetap selesai, dan hasil akan ditampilkan.

Sebaiknya lacak waktu saat token akses Anda terakhir kali dimuat ulang, dan paksa muat ulang jika waktu habis masa berlaku kurang dari 5 menit.

Jika Anda tidak tahu kapan terakhir kali token akses diperbarui, Anda dapat mencoba memperbaruinya dengan asumsi token tersebut sudah habis masa berlakunya. Jika masa berlaku token akses tidak akan segera berakhir, server akan menampilkan token akses yang sama, beserta sisa waktu dalam milidetik hingga masa berlaku token berakhir.

Penyimpanan data

Anda dapat menggunakan penyimpanan data yang ada atau men-deploy penyimpanan data khusus untuk berbagi kredensial antar-server. Solusinya mencakup server penyimpanan cache, seperti Memcached atau Infinispan, atau penyimpanan data NoSQL, seperti MongoDB.

Penyimpanan data harus dioptimalkan untuk operasi baca yang cepat karena akan ada lebih banyak permintaan baca daripada tulis. Selain itu, kredensial harus disimpan dengan aman.

Saat menyimpan kredensial, Anda harus menyimpan expiry_time yang dihitung (sekarang + expires_in) dan refresh_token bersama dengan 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 pemuatan ulang berjalan dengan benar, kredensial akan valid. Namun, jika tugas refresh atau penyimpanan data gagal, Anda harus memiliki mekanisme penggantian.

Jika server atau proses tidak dapat memperoleh kredensial dari penyimpanan data, atau jika kredensial telah habis masa berlakunya, server harus memperbarui kredensialnya sendiri agar aplikasi dapat terus berfungsi 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, untuk pengguna dengan hierarki satu 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 mana pun, Anda harus membuat dan mempertahankan kredensial yang berbeda untuk akun yang berbeda—seperti untuk setiap akun klien Google Ads yang Anda akses, atau setiap akun pengelola tingkat teratas dalam hierarki independen yang Anda akses.

Anda dapat mengikuti strategi yang sama untuk aplikasi multithreaded atau multi-proses / terdistribusi dengan sedikit modifikasi. Saat menggunakan penyimpanan data bersama, kredensial harus diindeks berdasarkan ID akun customerId untuk memastikan kredensial dikaitkan dengan akun yang tepat. Selain itu, tugas refresh harus menjaga semua kredensial tetap diperbarui. Jika akun baru ditautkan, tugas pemuatan ulang mungkin perlu dipicu.

Terakhir, di aplikasi multithread, Anda hanya boleh membagikan objek kredensial di seluruh thread yang beroperasi di akun yang terkait dengan objek kredensial.