Shibboleth-IdP冗長化パフォーマンス比較試験報告書
2012年1月17日
国立情報学研究所
- 目次 -
1. はじめに \
1.1. 目的 \
1.2. 比較する Shibboleth-IdP冗長化方式 \
1.3. 検証環境の構成 \
2. パフォーマンスの測定方法 \
2.1. クライアント環境 \
2.2. ロードバランシング \
2.3. 内容 \
3. ツールと使用データ \
3.1. 測定ツール \
3.2. テストデータ \
4. テスト \
4.1. テスト内容 \
4.2. テスト結果 \
5. パフォーマンス測定結果 \
5.1. Terracotta方式 \
5.1.1. パターン１（2スレッド×1000回） \
5.1.2. パターン2（10スレッド×200回） \
5.1.3. パターン3（20スレッド×200回） \
5.2. memcached方式 \
5.2.1. パターン1（2スレッド×1000回） \
5.2.2. パターン2（10スレッド×200回） \
5.2.3. パターン3（20スレッド×200回） \
5.3. repcached方式 \
5.3.1. パターン1（2スレッド×1000回） \
5.3.2. パターン2（10スレッド×200回） \
5.3.3. パターン3（20スレッド×200回） \
5.4. IdP Stateless Clustering方式 \
5.4.1. パターン1（2スレッド×1000回） \
5.4.2. パターン2（10スレッド×200回） \
5.4.3. パターン3（20スレッド×200回） \
5.5. 測定値の平均 \
6. 考察 \
| アンカー | ||||
|---|---|---|---|---|
|
| アンカー | ||||
|---|---|---|---|---|
|
| アンカー | ||||
|---|---|---|---|---|
|
本書は、冗長化したShibboleth-IdPのパフォーマンス計測の結果報告書です。
本書にてパフォーマンス計測のシステム構成と計測内容、計測結果を記載します。
| アンカー | ||||
|---|---|---|---|---|
|
パフォーマンス計測の対象となる冗長化方式は下記とします。
...
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPStatelessClustering
| アンカー | ||||
|---|---|---|---|---|
|
本試験における検証環境は下記に記すサーバーにて計測する。各サーバーのスペックは以下に示します。
| アンカー | ||||
|---|---|---|---|---|
|
...
- 対象サーバーに記述する値は、表 1 1 検証に使用したサーバー一覧 に記載するNoです。
| アンカー | ||||
|---|---|---|---|---|
|
| アンカー | ||||
|---|---|---|---|---|
|
- 検証環境と同一ネットワーク内にあるSPサーバーに負荷テストツールを置き、各計測対象サーバーへ負荷をかけてパフォーマンスを測定します。
| アンカー | ||||
|---|---|---|---|---|
|
- 冗長化した各サーバーへのロードバランシングは、計測対象ではない冗長化方式のサーバーにApacheモジュールのmod_proxy_balancer を使いリクエスト毎に分散する方式とします。
| アンカー | ||||
|---|---|---|---|---|
|
- 負荷テストツールを使い、下記のパターンでの測定を行います。
- パターン１： 2スレッド×1000回
- パターン２： 10スレッド×200回
- パターン３： 20スレッド×200回
- 助走期間として、各測定前に１分程度負荷ツールを実行します。
- Teracottaのみ各測定後に再起動を実施します。
- 計測は、１認証処理にかかる時間、および１秒間の認証処理回数を計測します。
- スレッドは毎アクセス新しいセッションを張る方法で行います。（常に認証処理が走る）
- 認証に利用するアカウントはひとつとします。
| アンカー | ||||
|---|---|---|---|---|
|
| アンカー | ||||
|---|---|---|---|---|
|
- Grinder
Grinder（グライダー）は、オープンソースの負荷テストツールです。Jythonで認証の動作を書いて実行します。
参考：https://wiki.shibboleth.net/confluence/display/SHIB2/IdPProdLoadTest
| アンカー | ||||
|---|---|---|---|---|
|
- 認証アカウントは学認で公開されているサンプルユーザをLDAPに設定しています。
https://www.gakunin.jp/docs/fed/technical/idp/customize/idpInst4
| アンカー | ||||
|---|---|---|---|---|
|
| アンカー | ||||
|---|---|---|---|---|
|
各方式で冗長化構成が機能することを確認するテスト内容を下記に示します。
テスト１ | それぞれのサーバーについて、テストアカウントで認証できること、および認証結果がSPへ送信されること |
テスト２ | 一方のサーバーで認証後、他方のサーバーに認証要求を送った場合、認証済みとして正常に処理されること |
テスト３ | 未認証の状態で一方のサーバーでパスワード要求画面（いわゆるログイン画面）を表示した後、他方のサーバーにその応答を送った場合、正常に処理されること ※1 |
| アンカー | ||||
|---|---|---|---|---|
|
各方式でのテスト結果を下記に示します。
表 4 1 テスト結果
方式 | テスト内容 |
|
|
|
| テスト１ | テスト２ | テスト３ | |
Terracotta | ○ | ○ | ○ | |
memcached | ○ | ○ | × | |
Stateless Clustering | ○ | ○ | × |
| アンカー | ||||
|---|---|---|---|---|
|
| アンカー | ||||
|---|---|---|---|---|
|
| アンカー | ||||
|---|---|---|---|---|
|
表4 1 Terracotta方式 パターン１（2スレッド×1000回）
...
図 4 1 #T1-1の測定結果グラフ
図 4 2 #T1-2の測定結果グラフ
図 4 3 #T1-3の測定結果グラフ
| アンカー | ||||
|---|---|---|---|---|
|
表4 2 Terracotta方式 パターン２（10スレッド×200回）
...
図 4 4 #T2-1の測定結果グラフ
図 4 5 #T2-2の測定結果グラフ
図 4 6 #T2-3の測定結果グラフ
| アンカー | ||||
|---|---|---|---|---|
|
表4 3 Terracotta方式 パターン3（20スレッド×200回）
...
図 4 7 #T3-1の測定結果グラフ
図 4 8 #T3-2の測定結果グラフ
図 4 9 #T3-3の測定結果グラフ
| アンカー | ||||
|---|---|---|---|---|
|
| アンカー | ||||
|---|---|---|---|---|
|
表4 4 memcached方式 パターン１（2スレッド×1000回）
...
図 4 10 #M1-1の測定結果グラフ
図 4 11 #M1-2の測定結果グラフ
図 4 12 #M1-3の測定結果グラフ
| アンカー | ||||
|---|---|---|---|---|
|
表4 5 memcached方式 パターン２（10スレッド×200回）
...
図 4 13 #M2-1の測定結果グラフ
図 4 14 #M2-2の測定結果グラフ
図 4 15 #M2-3の測定結果グラフ
| アンカー | ||||
|---|---|---|---|---|
|
表4 6 memcached方式 パターン3（20スレッド×200回）
...
図 4 16 #M3-1の測定結果グラフ
図 4 17 #M3-2の測定結果グラフ
図 4 18 #M3-3の測定結果グラフ
| アンカー | ||||
|---|---|---|---|---|
|
| アンカー | ||||
|---|---|---|---|---|
|
表4 7 repcached方式 パターン１（2スレッド×1000回）
...
図 4 19 #R1-1の測定結果グラフ
図 4 20 #R1-2の測定結果グラフ
図 4 21 #R1-3の測定結果グラフ
| アンカー | ||||
|---|---|---|---|---|
|
表4 8 repcached方式 パターン２（10スレッド×200回）
...
図 4 22 #R2-1の測定結果グラフ
図 4 23 #R2-2の測定結果グラフ
図 4 24 #R2-3の測定結果グラフ
| アンカー | ||||
|---|---|---|---|---|
|
表4 9 repcached方式 パターン3（20スレッド×200回）
...
図 4 25 #R3-1の測定結果グラフ
図 4 26 #R3-2の測定結果グラフ
図 4 27 #R3-3の測定結果グラフ
| アンカー | ||||
|---|---|---|---|---|
|
| アンカー | ||||
|---|---|---|---|---|
|
表4 10 IdP Stateless Clustering方式 パターン１（2スレッド×1000回）
...
図 4 28 #S1-1の測定結果グラフ
図 4 29 #S1-2の測定結果グラフ
図 4 30 #S1-3の測定結果グラフ
| アンカー | ||||
|---|---|---|---|---|
|
表4 11 IdP Stateless Clustering方式 パターン２（10スレッド×200回）
...
図 4 31 #S2-1の測定結果グラフ
図 4 32 #S2-2の測定結果グラフ
図 4 33 #S2-3の測定結果グラフ
| アンカー | ||||
|---|---|---|---|---|
|
表4 12 IdP Stateless Clustering方式 パターン3（20スレッド×200回）
...
図 4 34 #S3-1の測定結果グラフ
図 4 35 #S3-2の測定結果グラフ
図 4 36 #S3-3の測定結果グラフ
| アンカー | ||||
|---|---|---|---|---|
|
表4 13 平均一覧
# | 方式 | パターン１ | パターン２ | パターン３ |
1 | Terracotta | 12.76 | 15.64 | 15.22 |
2 | memcached | 19.38 | 31.52 | 39.46 |
3 | repcached | 19.35 | 31.65 | 38.89 |
4 | Stateless Clustering | 25.83 | 42.09 | 47.20 |
| アンカー | ||||
|---|---|---|---|---|
|
今回行ったパフォーマンスの測定結果から判断すると同時に行う処理の数に関わらずStateless Clustering方式が他の方式より早いが、処理数が10以下と少ない場合、IdP Stateless Clustering方式、repcached方式、memcached方式とも同等の性能がでている。
なお、別紙の各環境構築手順書を見ると、Stateless Clustering方式はソースコードからjarファイルを作成する必要があり、他の方式と比べると複雑である。
Shibboleth-IdPの冗長化を導入する場合は、利用者数や構築にかけられるコストなどから判断して、利用する方式を選択することが望ましい。