SSO製品のトラフィックは、多数のAgentもしくはReverseProxy から認証サーバー（Policyサーバー）にアクセスに行きそこでまとめられ、認証DBまで認証や認可情報を確認する流れです（図2）。
通常すべてのトラフィックで認証・認可のチェックが必要であるため、もし何も工夫せずにSSO製品を作成すると、すべてのトラフィックが毎回認証DBにアクセスすることとなります。認証DBは、データベースやLDAPが通常用いられますが、ご存知のとおり台数を増やしスケールアウトすることは容易ではありません。また処理も重くパフォーマンスも容易な向上が難しい。つまりこの部分がボトルネックとなります。
このボトルネックをいかに解消しているかが、各SSO製品のスケーラビリティに関するアーキテクチャのポイントです。
そのボトルネックの解消方法のポイントとしては、大きく以下の2点が挙げられます。
- キャッシュを使用する
- 認証DBとの接続の効率化
1.キャッシュを使用する
キャッシュの持ち方には、次の2つのパターンがあります。
- Agentに保持する場合
- 認証サーバーで保持する場合
Agentにキャッシュを保持した場合、ヒットすればそこで処理が完了するため、トラフィックとしては一番軽くなります。しかし、Agentのキャッシュには問題も多くあります。
ヒット率を上げるためキャッシュサイズを大きくとると、メモリ圧迫や検索によるCPU負荷が生じ、同じサーバー上のアプリケーションに影響を及ぼしてしまいます。また何十、何百ものAgentのキャッシュ間の整合性も問題です。たとえば本体でログアウトしても、Agentにキャッシュが残っている間は、アプリケーションにアクセスできてしまいます。したがってAgentのキャッシュは、そのようなことが起こらないようにアプリケーションに影響を与えず、整合性を損なわない程度に制限する必要があります。そうなるとヒット率は期待薄であり、主体は認証サーバーのキャッシュとなります。
認証サーバーでのキャッシュのポイントはヒット率と検索速度です。つまり認証DBになるべく問い合わせを行かせないようにすることと、多数のAgentからの大量アクセスをどう処理するかです。ヒット率を高めるためには、認証DBに近い内容をメモリに展開することになりますが、単純に展開してしまうと、今度はキャッシュの検索に時間がかかってしまいます。たとえば、10万人分のレコードがあれば、シーケンシャルに検索した場合、毎回平均5万レコード検索しなければなりません。これを解決するためには、ツリー型など高速な検索方法が必要です。また処理効率を上げるためにマルチスレッドを採用する必要があり、当然スレッド間の排他制御も巧妙に制御する必要があります。
2.認証DBとの接続の効率化
認証サーバーと認証DBとの間がシーケンシャルな処理であれば、そこがまずボトルネックとなります。スケーラビリティを実現するためには、複数のDBアクセスを同時に実行可能とする必要があります。
一方、DBアクセスで最も重い処理は、DB接続です。従って、DB接続の負荷を軽減することがボトルネックの解消となります。DBアクセスを並列処理し、かつ、DB接続の負荷を軽減しスケーラビリティを実現するには、あらかじめ確保した複数のDB接続を各処理単位で共有して使用するコネクションプールの採用が必要となります。またコネクションプールを生かすためには、認証サーバーが並列処理、つまりここでもマルチスレッド対応していることが必須です。
|
