容量計画とAccess Gateway
容量計画は、現在と将来のリソース消費要件を評価するための一連のタスクです。これは、ユーザーの需要を満たし、需要のピークに対応し、時間の経過とともに増加する需要に応じた拡張のために必要なシステムリソースを決定する際に役立ちます。また、余分な容量がアイドル状態になり続けてストレージとメンテナンスのコストが上昇するのを防ぐ上でも役立ちます。
容量計画の主な要素は、サイジングとスケーリングの2つです。サイジングは、Access Gatewayデプロイメントのサポートに必要なメモリ、ハードディスク容量、CPU処理能力、スループットの計算です。スケーリングは、Access Gatewayクラスターサイズの増減によるシステムリソース消費の最適化です。
容量計画を実行するには、現在のアクセスレートを特定し、Access Gatewayの消費データを使って将来の消費シナリオを推定します。
このトピックでは、環境に応じた容量計画を計算できるように、Access Gatewayの消費データとシステムの要件について説明します。
現在のアクセスレートを推定する
将来のリソース消費要件を予測するには、事前にベースラインを確立する必要があります。このベースラインは、現在の消費レベルです。Access Gatewayが対応しなければならないアクセスと認証の数を計算します。将来の予測は、収集するデータの期間が長いほど高精度になります。
- ロギングシステムやその他のソースから次のデータを収集します。
- その期間の高、低、平均アクセス数と認証数
- 需要が最も多い時間帯と日にち
- 需要が最も少ない時間帯と日にち
- Access Gatewayにアクセスするユーザーの総数
- アプリケーションを毎日利用するユーザーの数
- ユーザーが1日にアプリケーションにアクセスする回数
- 各ユーザーが1回のセッションで行うページアクセスの数
- Access Gatewayが保護するアプリケーションの数
- ユーザー数とアクセス数の現在の値を計算するには、次の計算式で収集データを使用します。
平均アクセス
全体的アクセス
平均ユーザー数 = ユーザー総数 ÷ 1日当たりの推定ユーザー数 全体アクセス数 = 平均アクセス数 x ページアクセス数
平均アクセス数 = 平均ユーザー数 ÷ 1日当たりの推定アクセス数 全体的な平均アクセス数 = 平均ユーザー数 x 1日あたりのアクセス数 - ユーザーをアクセス頻度別に分類します。
- 頻繁なユーザー：1日に5回以上システムにアクセスする
- 頻繁でないユーザー：1日に1～2回システムにアクセスする
- まれなユーザー：1週間に1～3回システムにアクセスする
- 各ユーザーグループの一般的なアクセスレートを計算します。たとえば、頻繁なユーザーが5000人で、1日に5回システムにアクセスするのであれば、そのグループの1日あたりのアクセス数は25,000となります。
ハードウェア要件を推定する
ハードウェアには、Access Gatewayデプロイメントの最適パフォーマンスを確保するために必要なメモリとハードディスクの容量、CPUとコアの数、スループットのレベルが反映されます。
メモリ要件
| 項目 | 本番環境の最小要件 |
|---|---|
| オペレーティングシステム、Access Gatewayエンジン、マイクロサービス | 1.5GB |
| セッションのキャッシュ | 128MB |
| 平均セッションサイズ | 1024バイト |
| Kerberosチケット。これらのチケットは、アクセスするIISアプリケーションの数に応じて大きくなる場合があります。 | 1024バイト |
WebアプリケーションとKerberosセッションのキャッシュを計算する
セッションキャッシュに必要な容量を計算するには、セッションの総数と平均セッションサイズを掛け合わせ、その結果を2倍にします。
各セッションは、ユーザー数、1日あたりのユーザーサインインイベントの割合、ユーザーがアクセスするアプリケーションの数から計算されます。
セッションキャッシュに必要な容量を計算するには、次の式を使用します：セッション総数 x （平均セッションサイズ x 2）
次に、この式の使用方法を示すシナリオを紹介します。
|
ユーザー |
1日当たりのサインインイベントの割合（%） |
アクセスされたアプリケーションの数 |
総セッション数 |
セッションサイズ |
セッションキャッシュ |
|---|---|---|---|---|---|
| 5,000 | 50% | 5 |
1日当たりのユーザーサインインの割合 x アクセスされたアプリケーションの数 12,500 |
1024バイト x 2 | 約25MB |
| 10,000 | 75% | 10 | 75,000 | 1024バイト x 2 | 約150MB |
| 25,000 | 50% | 100 | 125,000 | 1024バイト x 2 | 約500MB |
Kerberosアプリでは、追加のキャッシュ要件が生じます。
|
ユーザー |
1日当たりのサインインイベントの割合（%） |
アクセスされたIISアプリケーションの数 |
総セッション数 |
セッションサイズ |
セッションキャッシュ |
|---|---|---|---|---|---|
|
10,000 |
50% |
5 |
1日当たりのユーザーサインインの割合 x アクセスされたアプリケーションの数 25,000 |
1024バイト |
約50MB |
セッションの考慮事項：
- セッションは、LRU（Least Recently Used）アルゴリズムでクリアされます。キャッシュが満杯になって新しいセッションが作成されると、最も古いアイドルセッションが削除されます。
- セッションモニタリングロガーは、キャッシュが満杯または満杯近くなるとアラートを出力します。統計情報は、Access Gateway管理者コンソールで確認できます。キャッシュ満杯のインシデントを減らすには、アプライアンスメモリを増やすことを検討してください。
- 従業員の登録時期、モニタリング、昼食後のサインインイベントなど、常に負荷が多くなるタイミングを考慮します。
ハードディスク要件
Access Gatewayでは、次の要素向けにハードディスク容量が必要になります。一定期間におけるこれらの要素の数とサイズを決定してください：
- ソフトウェア：Access Gatewayソフトウェアとオペレーティングシステム。ソフトウェアファイルのサイズは通常は小規模です。
- バックアップ：毎晩実行され、30日間維持されます。バックアップファイルのサイズは通常は小規模です。
- システムログ：ログファイルはローカルディスクにスプールされ、認証、承認、監査、アクセス、セッション、および全ログのファイルがあります。通常、HTTP/HTTPSリクエストごとに1エントリとなります。ユーザー数、ユーザーがアプリケーションにアクセスする回数、そのアプリケーションで生じるページビューの数を考慮してください。
- ログアーカイブ：ロール、圧縮され、30日間維持されます。
ログエントリのサイズと増加量を計算する
必要ディスクサイズがどの程度増加するかを推定するには、次の計算を使用します。例に示される数値は、実際の環境の数値に置き換えてください。妥当なルールとしては、予想消費量の2倍に、ソフトウェアアップデート、構成、バックアップのための追加オーバーヘッド容量を加えたものを割り当てます。この例では、約14GBのディスク要件に10〜20％が追加され、毎月約17〜20GBの増加となります。
|
ユーザーベース |
10,000 |
|
アクセスレート |
75% |
|
1ユーザーあたりのアプリケーション数 |
10 |
|
1日あたりのアクセス数 |
ユーザーベース x アクセスレート x ユーザーあたりのアプリケーション数 10,000 x 0.75 x 10 = 75,000 |
|
一般的なログエントリサイズ （Access Gateway、認証、承認セッション） |
1024バイト x 3 = 3072バイト |
|
1日あたりの増加ディスクサイズ |
1日あたりのアクセス数 x 一般的なログエントリサイズ 75,000 x 3072バイト = 76,800,000バイト、または1日約230.4MB |
|
1か月（30日）あたりの増加ディスクサイズ |
1日あたりの増加ディスクサイズ x 30 230.4 x 30 = 6.912GB |
|
1年間（365日）の増加ディスクサイズ |
1日あたりの増加ディスクサイズ x 365 = 84.096GB |
ハードディスクの考慮事項：
- 最大リクエストまたはピークリクエストのディスク残量レベル低下の警告を回避するために、ディスク容量減少時のロガーアラートをモニタリングします。チェックは1時間ごとに行われ、使用量70%で警告、90%でアラートが発せられます。
- すべてのHTTPリクエストは、監査ログとアクセスログを生成します。
- ディスクIOの高速化により、スループットが向上します。
- セッションサイズは承認を使用した監査ロギングに影響し、監査ログにはセッションのコンテンツが含まれます。
- ハードディスクのサイジング計算では、控えめにならないようにしてください。バーストや大きなページリクエストによってディスク容量減少の警告が発生するのを避けるために、推定ディスク要件の2倍を割り当てます。
CPUとコア
Access Gatewayエンジンは、すべてのCPUに自動的にスケーリングされ、その結果、1 CPUごとに1ワーカーが生じます。コアを追加するたびにスレッドが追加され、追加の処理が可能になります。
-
CPU/コアが多いほど、容量が増えます。
- 処理のボトルネックになるのは、通常はCPU処理ではなく、ネットワークスループットです。
スループット
スループットは、ネットワークを介したデータ配信のレートを意味します。Access Gatewayでは、ネットワークを介して配信されるデータには、認証、承認、リターンコンテンツのデータが含まれます：
- 認証：処理されたSAMLアサーションの数（Oktaから各アプリケーションへ）
- 承認：HTTPリクエストごとにチェックされたポリシーの数（すべてのHTTPリクエスト）
認証と承認の各リクエストは約1024バイトを使用し、2048バイトのリターンデータを生じます。ネットワークスループットは、次の式を使って計算できます：
- 1秒あたりのサインイン試行数 x（1秒あたりの認証と承認 + リターンデータのサイズ）
平均ネットワーク帯域幅の計算には、次の式を使用します：
- 平均応答サイズ x 平均リクエスト到着レート
平均的な応答のサイズが約20KBであれば、500リクエストの場合、結果は20KB×500となり、1秒あたり10MBに相当します。
リクエストの実行時間やリターンデータのサイズなど、正確なデータはAuthNとすべてのログで調べることができます。
インスタンスサイズを推定する
各インスタンスサイズでサポートできるユーザー数と認証数は、多くの複雑な要因に応じて異なります。サーバーで利用できる総ディスク容量とメモリ容量の関係や、プロセッサーとネットワーク接続の速度などの要因が容量に影響します。
Access Gatewayでは、環境に適した構成を選択できます。複数のコアと大容量のメモリモジュールを備えたハードウェアには、Access Gatewayのインスタンスを1つ、または2つデプロイできます。または、クラスター内の複数のサーバーに分散した、より小規模な多数のインスタンスにAccess Gatewayをデプロイすることもできます。
Access Gatewayインスタンスがサポートできるユーザー数の決定については、このページの計算を使用するか、自分の環境についてOktaサポートまでお問い合わせください。
次の表は、さまざまなサイズのAccess Gatewayインスタンスのサポートに必要な最小ハードウェア構成を示しています。テーブルに示されるユーザーとアプリの数は、あくまでもガイドラインとしてのものです。実際のパフォーマンスは、環境独自の要因によって異なります。
| 使用 | 物理/仮想ハードウェア | AWSの同等タイプ |
|---|---|---|
|
概念実証 |
|
t2.medium |
|
小
|
|
t2.medium |
|
中
|
|
m4.large |
|
大
|
|
m4.xlarge 詳細については、「AWSインスタンスタイプ」を参照してください。 |
スケーリング要件を推定する
スケーリングは、Access Gatewayクラスターサイズを増減させるタスクです。
- 垂直スケーリング：特定インスタンスのメモリ、ディスク、CPUを追加または削除します。過度なロギングが生じるときは、ログフォワーディングソリューションを使ってAccess Gatewayのログレベルを最小（警告またはエラー）に設定します。アプライアンスのディスク容量を拡張する必要があるときは、Oktaプロフェッショナルサービスまでお問い合わせください。
- 水平スケーリング：クラスターのAccess Gatewayインスタンスを追加または削除します。
すべてのAccess Gateway高可用性クラスターメンバーを、同じCPU、メモリ、ディスク構成でデプロイすることをお勧めします。
クラスターパフォーマンスのヒント
-
最高のパフォーマンスは、CPUを追加したり、ソリッドステートディスクを使用したりすることで得られます。
- 全体的なクラスタースループットを上げるには、水平方向のスケーリングを行う、または新たなAccess Gatewayインスタンスを追加することをお勧めします。たとえば、1,500のリクエストを処理する2つのノードクラスターであれば、同じCPU、メモリ、ディスク構成の2つの新たなノードを追加することで容量を倍増できます。
- 一般に、水平方向のスケーリングは、Access Gatewayがスティッキーセッション（セッションアフィニティ）を使用するため、線形となります。Access Gatewayは、ノード間でセッションを共有しません。
容量は、ネットワークスループットやバックエンドアプリケーションのパフォーマンスなど、Access Gatewayに関連しない他の要因によって制限される場合があります。Access Gatewayネットワーキングとネットワークスループットの拡張の詳細については、「ネットワークインターフェイス」を参照してください。