分散システムでの共有アクセストークン

Question

多くのノードで水平方向にスケーリングするシステムを構築しています。これらのノードは、https://example.com/apiでホストされているAPIを使用する可能性があります。このAPIの認証はトークンベースです。

私の質問は、私のノードのそれぞれが個別に認証し、独自のトークンをフェッチする必要があるのですか？または、それらの間に共有キャッシュを構築し、そこにトークンを保存する必要がありますか？

後者の場合、この設計パターンの標準はありますか、それとも私のためにこれを行うことができるライブラリはありますか？すなわち。トークンをキャッシュに格納し、ラムダ関数+認証または更新用のttlを取得します）

注：

トークンは一定の時間有効です。
それらはその期間中に再利用可能であり、その後期限切れになります。
それらはすべて同じアクセスレベルです。
これまでに出会ったAPIはすべて、同時に複数のアクティブなトークンを許可します。新しいものを取得しても、古いものは無効になりません。（しかし、mvpではなく将来見られる場合に備えて、これを説明する必要があると思います）
ノードは異なるマシンで実行されます。
問題は、API呼び出しごとに個別のAuth呼び出しを行う必要がないことです。

[〜＃〜] edit [〜＃〜]また、Azureの世界でのこの問題について説明しているこの記事に遭遇しました： https://docs.Microsoft.com/en-us/Azure/architecture/multitenant-identity/token-cache

ありがとう！

Arseni Mourzenko · Answer

最も簡単な解決策は、ノードごとに1つのトークンを使用することです。

共有キャッシュを使用する必要はありません。ここでの問題は、2つのノードが同時にオンラインになった場合の処理です。最初のノードがトークンの要求を開始した場合、2番目のノードは待機する必要がありますが、2番目のノードはトークンが要求されていることを通知される必要があります。技術的には実現可能ですが、これは開発とテストが最も簡単なことではありません。
トークンの有効期限が切れたときに何が起こるかを考える必要はありません。 10個のノードがあるとします。トークンの有効期限が近づいています。トークンを更新するには、ノードの1つを選択する必要があります。ノードが選択された後、ノードが新しいトークンのリクエストを開始したが、ストアに保存する前にクラッシュした場合はどうなりますか？他のノードはそれについてどのように通知されますか？彼らは新たな選挙を行うだろうか？ノードがクラッシュし続けている間に、トークンが最終的に期限切れになった場合はどうなりますか？
トークンが更新された後、すべてのノードは新しいトークンが使用可能であることをどのようにして知るのですか（毎回共有キャッシュをクエリしない限り）？ノードが一時的に共有キャッシュにアクセスできない場合はどうなりますか？
APIへのリクエスト数が過去15分間で100倍になり、割り当てにすぐに到達したことを通知されているとします。特定のノードを原因として特定できる場合は、それらのノードに具体的にデプロイされたアプリのバグのあるリリースや、特定のノードが侵害されているセキュリティ違反などの理由を簡単に見つけることができます。この情報がない場合でも、デバッグ時に信頼できる情報は少なくなります。