はじめに

複数のサービスを立ち上げて、運用している企業の中で、実際には一人のユーザーに対して、ユーザー情報が複数できてしまって、広告効率や運用効率が下がってしまっているようなお悩みを聞くことがあります。とはいえ、会員の属性の管理や、どのシステムを誰が使ってよいのか？という認可の部分も多く相談を受けます。オンラインでのアクション(例えば、ECサイトでの購入やシリアルナンバーの入力)からすぐさまコンテンツを確認できるような仕組みや、サービスの利用開始になる仕組みを構築することが増えてきました。その中でお話できることを書いてみます。

共通基盤と呼んだり、認証基盤・会員基盤などと呼ばれるケースがありますが、今回は"共通基盤"と呼ぶことにします。

解決したいこと

各サービスで同一のユーザーを1アカウントとして扱いたい一元管理
必要な情報だけ共有できる形で、疎結合な状態にしたい
どのシステムで誰が何を利用できるのかを管理したい

考えたこと

認証システムはSaasのシステムを利用する
Client Credentials Flowを使って、各サービスが参照できる内容などを定義する
認証システム側に購入履歴などを持たせて、ライセンスの管理をしたところで、認証システムへの負荷が上がって、アクセスできない状態がうまれては元も子もない
一つのサービスが落ちることよりも、全体のサービスが継続稼働することを優先した。各サービス側で最適なリソースや負荷対策をすることで解消できるようにする
ライセンスの付与・削除および有効期限を正しく管理することで、情報を「配信」して、各サービスに保存する形で運用することが最もAPI実行数を節約できる

実行したこと

Barista(https://prismatix.jp/authenticate/)を採用して、利用者と認証の負荷に関する対応はお任せした
各サービスごとにClientを発行。情報の使える範囲を限定し、会員情報の矢印を一方通行にした
認証システムには会員情報の基本的な内容以外持たせないことにした。iOSアプリでの会員登録をすることも想定し、個人情報も最小限にした
AWSのSQSとSESを使い、ライセンス情報に動きがあれば情報を発行。各サービスへ、情報取得のアクションと取得後の消し込みを各サービス主体で行うことで、確実に受け取ったことを実現

実際にやってみて

各システム側の構築のコストとして、認証基盤とのつなぎこみとライセンス情報の保存の部分は、負担が一部上がる結果にはなったが、どこかのシステムに大量のアクセスや負荷があったとしても、完全に切り離すことができた。
どの情報をどこに持つか、という設計で、インフラや実装方法ではなく、データ管理の方針でも負荷対策として正しい対策となりうる。設計時にどのくらいのアクセスや利用があるか想定できていないと、このような解消は実現できなかったと思う。
SSOで多くのシステムを連携して〜とか、ポイント管理を複数サービスで共通にして〜などの話はあるが、ノウハウがないと正しい設計はできず、それぞれをただ利用しているシステムが出来上がり、あとになって相談に来るケースがある。最初にどの程度のサービスの伸びを考えるか、将来を見越した設計をするのか、直近のコストを優先するか。
プロジェクトの状況において様々あるが、何を重視するか、を正しく議論して設計に望んでほしい