認証情報の管理戦略

API リクエスト間で認証情報を共有すると、パフォーマンスが向上し、レート制限エラーにつながる可能性のある過剰なオーバーヘッドを回避できます。このガイドでは、OAuth2 認証情報の管理を最適化して、アプリが Google Ads API と効率的にやり取りできるようにする方法を説明します。

認証情報の共有戦略は、アプリがマルチスレッドマルチプロセス(または分散)かによって異なります。各プロセス内でマルチプロセスとマルチスレッドの両方を行うアプリでは、両方の戦略を採用する必要があります。これらの戦略は、複数の Google 広告アカウントに適用することもできます。

マルチスレッド

スレッドによって描画された各セッションまたはユーザーは、同じ認証情報オブジェクトを使用する必要があります。また、競合状態を回避するため、アクセス トークンの更新は同期的に実行する必要があります。

Google のクライアント ライブラリにより、認証情報は、アクセス トークンの有効期限が切れたときに同期的に更新されるスレッドセーフなオブジェクトであることが保証されます。各クライアント ライブラリには、存続期間中に再利用される認証情報を含むセッション(ユーザー)オブジェクトがあります。スレッド間で認証情報を共有するには、同じ認証情報を使用して各セッションを作成するだけです。たとえば、Java クライアント ライブラリでは、Credential シングルトンを作成し、すべてのセッションで共有します。

マルチプロセスまたは分散型

マルチプロセスまたは分散プロセスの場合は、共有する前に認証情報を保持する必要があります。複数のプロセスまたはサーバーが同時に認証情報の更新を試みて過剰な更新リクエストが発生しないようにするには、更新を単一のプロセスに割り当てる必要があります。

たとえば、別のジョブまたはサービスによって認証情報を定期的に更新し、サーバーのプールによって共有されるデータストアにプロアクティブに push できます。各サーバーは API リクエストを行うときにデータストアから認証情報を取得できます。

更新ジョブ

更新ジョブは、現在の認証情報の有効期限が切れるまで待ってから更新を開始しないでください。これを行うと、有効な認証情報がないためにアプリが停止することがあります。ただし、API リクエストの処理中に認証情報のアクセス トークンが期限切れになった場合、リクエストは完了し、結果が返されます。

アクセス トークンが最後に更新された時刻を追跡し、有効期限まで 5 分未満の場合は強制的に更新することをおすすめします。

アクセス トークンが最後に更新された日時が不明な場合は、すでに有効期限が切れていると想定して更新してみてください。アクセス トークンのラップが古くない場合、サーバーは同じアクセス トークンを、トークンの有効期限が切れるまでの残りのミリ秒数とともに返します。

データストア

既存のデータストアを利用しても、サーバー間での認証情報の共有専用のデータストアを配置しても構いません。ソリューションには、MemcachedInfinispan などのキャッシュ サーバーや、MongoDB などの NoSQL データストアがあります。

読み取りリクエストの数は書き込み数より多いため、データストアは高速読み取りオペレーション向けに最適化する必要があります。また、認証情報は安全に保存する必要があります。

認証情報を保存するときは、計算した expiry_time(現在は + expires_in)と refresh_tokenaccess_token とともに保存する必要があります。expiry_time は、access_token 更新リクエストの時刻に expires_in を足した時間として計算されます。

サーバープール

プール内の各サーバーまたはプロセスは、リクエストを行う前にデータストアから最新の認証情報を取得します。更新ジョブが正しく実行されている限り、認証情報は有効です。ただし、更新ジョブやデータストアが失敗した場合は、フォールバック メカニズムが必要です。

サーバーまたはプロセスがデータストアから認証情報を取得できなかった場合や、認証情報の有効期限が切れた場合は、問題が解決するまでアプリケーションと API の接続が途切れないように、サーバーが自身の認証情報を更新する必要があります。

複数のアカウントの認証情報管理

Google 広告 MCC アカウント用に生成された認証情報を使用して、そのすべての子アカウントにアクセスできます。したがって、MCC アカウントの階層が 1 つのユーザーの場合、通常は最上位の MCC アカウントの認証情報を生成して、その下位にあるすべての Google 広告アカウントで使用するのに十分です。

MCC アカウントの階層内で互いに関連性のない Google 広告アカウントにアプリがアクセスする必要がある場合は、アカウントごとに異なる認証情報を生成して維持する必要があります。たとえば、アクセスする Google 広告クライアント アカウントごと、アクセスする独立した階層内の最上位の MCC アカウントごとに認証情報を生成して維持する必要があります。

マルチスレッド アプリまたはマルチプロセス / 分散アプリでも、少しだけ修正して同じ戦略を使用できます。共有データストアを使用する場合は、認証情報をアカウント ID customerId でインデックス化して、認証情報を正しいアカウントに関連付ける必要があります。また、更新ジョブではすべての認証情報を更新する必要があります。新しいアカウントがリンクされた場合、更新ジョブをトリガーすることが必要になる場合があります。

最後に、マルチスレッド アプリでは、認証情報オブジェクトが関連付けられているアカウントで操作しているスレッド間でのみ、認証情報オブジェクトを共有する必要があります。