背景

業務の振り返りとしてここにまとめます。
外部サービスとOAuth認可で連携する機能があり、その際のトークンに関わる処理の見直しをしました。

前提
メインサーバー、イベントをリッスンし実行するワーカーサーバー、バッチ用のサーバーから同一の外部サービスにリクエストを送るため、プロセス内に限らず、マルチプロセスでの並列リクエストが起こり得る設計になっています。

当時の処理

リクエストの度に以下を行っていました。

リフレッシュトークンは同じものを使い続けています。

外部サービスの仕様が以下のように変わりました。

これにより、アプリは更新されたリフレッシュトークンをDBに保持することはしないため、2回目のリクエストで失敗するという障害が起こりました。

理由

毎回アクセストークンを更新する運用の場合、直列で各リクエストを行うようにするとロック待機時間が課題となる
- refresh すると既存の access_token を失効させることも分かったため

前提: 毎回refreshする運用では、並列リクエストは成立しない（競合して失敗する）

しかしロックにより直列化すると、ロック待機時間が課題となる

採用案: access_token を使い回す

access_tokenが期限切れの場合はrefreshをします。
その際に並列リクエストが走る場合を考慮します。

先にリクエストを実行する予定だったもの（リクエストA）のaccess_tokenが、後続リクエストによりrefreshされると、リクエストAは失敗します。

そのため、以下のように排他制御が必要になります。

物理ロック（行ロック）を取得せず、論理ロックを取得することにした理由

pg_advisory_xact_lock はDBサーバー側のロックなので、バッチ用のサーバーも、mainのサーバーも同じキーを使うことでマルチプロセス間での排他制御をすることが可能です。
ロックはトランザクション終了時に自動解放されます。

リクエストを送信するたびにアクセストークンを更新するのはなぜ良くないのか
- https://stackoverflow.com/questions/60272875/why-is-it-a-bad-idea-to-refresh-access-token-every-time-when-i-sent-request
なぜリクエストのたびにリフレッシュトークンを送信するのか
- https://www.reddit.com/r/webdev/comments/1iu9jv8/why_people_send_refresh_tokens_on_every_request/
トークン更新時の同時実行処理方法
- https://nango.dev/blog/concurrency-with-oauth-token-refreshes/#how-o-auth-token-refresh-works
OAuthリフレッシュトークンの競合について
- https://dev.to/wartzarbee/the-oauth-refresh-token-race-that-logs-your-users-out-and-the-two-layer-fix-3obf
Redisを用いた分散ロック
- https://redis.io/docs/latest/develop/clients/patterns/distributed-locks/
- https://christina04.hatenablog.com/entry/redis-distributed-locking
Goライブラリ singleflightについて
- https://dev.to/nickytonline/gos-singleflight-package-and-why-its-awesome-for-concurrent-requests-4122
- https://zenn.dev/nkmrkz/articles/go-singleflight
- https://www.issoh.co.jp/tech/details/9058/

DB

データベースの排他制御
- https://fintan.jp/wp-content/uploads/2022/03/Database-Exclusion-Control.pdf
SELECT FOR UPDATEの使い方と注意点
- https://gyas.co.jp/knowledge_blog/db-sql-select-for-update/
アドバイザリーロックについて
- https://zenn.dev/yumemi_inc/articles/rdb-advisory-locks
- https://zenn.dev/castingone_dev/articles/advisory_lock
- https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS
排他ロックとは
- https://wa3.i-3-i.info/word18394.html
ロック取得順を一か所で決めてデッドロックを避ける
- https://zenn.dev/more_tech_blog/articles/a3bce59a4a442a