マルチワーカー自動化のためのブラウザプロファイル・リースの設計

停滞したロックはリカバリの問題である。 プロファイル・リースはランタイム設計の問題である。

多くの人は、2つのワーカーが同じブラウザプロファイルを開くのを防ぐには、ロックファイルだけで十分だと考えている。 しかし、スケールアップする際にはそれが間違いとなる。

ロックは、プロファイルが使用中であることしか教えてくれない。 そのプロファイルが安全に使用できるかどうかまでは教えてくれないのだ。

ログインの途中でワーカーがクラッシュした場合、アカウントの状態は不明になる。 次のワーカーは、間違ったページから開始したり、破損したクッキーを使用したりする可能性がある。 これは、デバッグが困難なサイレント・フェイラー（静かな失敗）を引き起こす。

リースは単なるロック以上のものだ。 それはスケジューラ、ワーカー、そしてプロファイルの間で交わされる契約である。

優れたリースは、以下の問いに答えるものである：

  • 現在、誰がこのプロファイルを所有しているか？
  • どの特定の実行（run）がそれを使用しているか？
  • この所有権はいつ期限切れになるか？
  • ワーカーが消失した場合、何が起こるか？

最小限のリースレコードには、以下を含めるべきである： • profile_id および account_id • worker_id および run_id • proxy_id • heartbeat_at（ワーカーが生存しているかを確認するため） • last_safe_step（最後に確認された正常な状態を確認するため） • release_policy

TTL（Time To Live）の期限切れを、ロックを削除するためのコマンドとして扱ってはならない。 期限切れのリースは「未解決の終了」である。 クリーンなリリースは「説明可能な終了」である。

ワーカーがハートビートの送信を停止した場合、そのプロファイルを自動的に再利用してはならない。 代わりに、プロファイルを隔離（quarantine）状態に移行させるべきである。

プロファイルには以下のステータスを使用すること：

  • Available（利用可能）: チェックアウトの準備ができている。
  • Leased（リース中）: 現在使用中。
  • Stale（停滞）: ワーカーの報告が停止しており、状態が不明。
  • Review Required（要確認）: 人間の確認が必要。
  • Quarantined（隔離）: 解除されるまで使用不可。
  • Disabled（無効）: ローテーションから除外。

隔離は罰ではない。それは安全メカニズムである。 以下の場合、プロファイルを隔離すべきである：

  • フォーム送信中にワーカーが停止した。
  • 最終的なURLが不明である。
  • 実行中にプロキシが変更された。
  • セキュリティプロンプトが表示された。

ロックは同時アクセスからプロファイルを保護する。 リースは不安全な再利用からプロファイルを保護する。

ブラウザプロファイルを使い捨てのフォルダのように扱うのはやめよう。 管理されたアカウント環境として扱うべきだ。

Source: https://dev.to/web4browser/designing-browser-profile-leases-for-multi-worker-automation-1bfa