本書は、冗長化したShibboleth-IdPのパフォーマンス計測の結果報告書です。
本書にてパフォーマンス計測のシステム構成と計測内容、計測結果を記載します。

アンカー
_Toc315862084
_Toc315862084
1.2. 比較する Shibboleth-IdP冗長化方式

パフォーマンス計測の対象となる冗長化方式は下記とします。

アンカー
_Ref272941422
_Ref272941422
Terracotta方式
- 認証情報は、冗長化したサーバー間で同期されるため、tomcatおよびTerracottaの方系がダウンしても再認証は求められない。
- 参考ページ
  https://wiki.shibboleth.net/confluence/display/SHIB2/IdPCluster
memcached方式（No Replication）
- 認証情報は、ログインしたtomcatと設定された各memcachedサーバーに認証情報を分割し振り分けて保管する。memcachedの方系がダウンした場合は、ログインしたことのあるサーバーへのアクセスではtomcatに認証情報が残っていれば、再認証は求められない。しかし、ログインしていないサーバーへのアクセス、もしくは、tomcatに認証情報が残っていない状態でのアクセスでは、再認証が求められる。
- 参考ページ
  https://wiki.shibboleth.net/confluence/display/SHIB2/Memcached+StorageService
repcached方式（replication）
- 認証情報は、冗長化したサーバー間で同期されるため、tomcatおよびrepcachedの方系がダウンしても再認証は求められない。
- 全サーバーが停止した場合、認証情報が失われるので、再認証が求められる。
- 参考ページ
  https://wiki.shibboleth.net/confluence/display/SHIB2/Memcached+StorageService
IdP Stateless Clustering方式
- 認証情報暗号化しCookieに入れてブラウザが持つ。サーバーに依存しないため、サーバーがダウンしても再認証は求められない。
- 参考ページ
  https://wiki.shibboleth.net/confluence/display/SHIB2/IdPStatelessClustering

アンカー
_Toc315862085
_Toc315862085
1.3. 検証環境の構成

...

No	ソフトウェア	バージョン	対象サーバー	備考
1	Apache HTTP Server	2.2.3	1,2,3,4,5,6,7
2	Shibboleth-SP	2.4.3-2.2	1
3	Shibboleth-IdP	2.3.5	2,3,4,5,6,7
4	memcached	1.4.10	4,5	メモリーの割り当ては512MB
5	ｒepcached repcached	2.2	4,5	メモリーの割り当ては512MB ｒepcached repcached に使われている memcachedのバージョンは1.2.8
6	Osuidpext	1.1	6,7	Stateless Clustering用ライブラリ
7	Terracotta	3.6.0	2,3
8	JDK	1.6.0_30	2,3,4,5,6,7
9	Apache Tomcat	7.0.23	2,3,4,5,6,7
10	OpenLDAP	2.3.43	2,4,6	各IdPサーバーの1台に構築

※ 対象サーバーに記述する値は、表 1 1 検証に使用したサーバー一覧に記載するNoです。

アンカー
_Toc315862086
_Toc315862086
2. パフォーマンスの測定方法

...

検証環境と同一ネットワーク内にあるSPサーバーに負荷テストツールを置き、各計測対象サーバーへ負荷をかけてパフォーマンスを測定します。

アンカー
_Toc315862088
_Toc315862088
2.2. ロードバランシング

冗長化した各サーバーへのロードバランシングは、計測対象ではない冗長化方式のサーバーにApacheモジュールのmod_proxy_balancer を使いリクエスト毎に分散する方式とします。

アンカー
_Toc315862089
_Toc315862089
2.3. 内容

負荷テストツールを使い、下記のパターンでの測定を行います。
- パターン１：　 2スレッド×1000回
- パターン２：　 10スレッド×200回
- パターン３：　 20スレッド×200回
助走期間として、各測定前に１分程度負荷ツールを実行します。
Teracottaのみ各測定後に再起動を実施します。
計測は、１認証処理にかかる時間、および１秒間の認証処理回数を計測します。
スレッドは毎アクセス新しいセッションを張る方法で行います。（常に認証処理が走る）
認証に利用するアカウントはひとつとします。

アンカー
_Toc315862090
_Toc315862090
3. ツールと使用データ

...

Grinder
Grinder（グライダー）は、オープンソースの負荷テストツールです。Jythonで認証の動作を書いて実行します。
参考：https://wiki.shibboleth.net/confluence/display/SHIB2/IdPProdLoadTest

アンカー
_Toc315862092
_Toc315862092
3.2. テストデータ

認証アカウントは学認で公開されているサンプルユーザをLDAPに設定しています。
https://www.gakunin.jp/docs/fed/technical/idp/customize/idpInst4

アンカー
_Toc315862093
_Toc315862093
4. テスト

...

テスト１	それぞれのサーバーについて、テストアカウントで認証できること、および認証結果がSPへ送信されること
テスト２	一方のサーバーで認証後、他方のサーバーに認証要求を送った場合、認証済みとして正常に処理されること
テスト３	未認証の状態で一方のサーバーでパスワード要求画面（いわゆるログイン画面）を表示した後、他方のサーバーにその応答を送った場合、正常に処理されること ※1 ※1 ブラウザによっては、ログイン画面を表示したサーバーのDNSがキャッシュされるため、他方のサーバーへ送信しようとしても、ログイン画面を表示したサーバーに応答を送ってしまいます。 Firefox9、IE9では、DNSをキャッシュし、Chrome16ではDNSをキャッシュしませんでした。今回は、ログイン画面を表示後にブラウザのDNSキャッシュをクリアしてから、他方のサーバーに応答を送る手順で行っています。また、今回のテストでは、DNSサーバーを用いずに、hostsファイルでサーバーの切り替えを行っています。