容量計画とAccess Gateway

容量計画は、現在と将来のリソース消費要件を評価するための一連のタスクです。これは、ユーザーの需要を満たし、需要のピークに対応し、時間の経過とともに増加する需要に応じた拡張のために必要なシステムリソースを決定する際に役立ちます。また、余分な容量がアイドル状態になり続けてストレージとメンテナンスのコストが上昇するのを防ぐ上でも役立ちます。

容量計画の主な要素は、サイジングとスケーリングの2つです。サイジングは、Access Gatewayデプロイメントのサポートに必要なメモリ、ハードディスク容量、CPU処理能力、スループットの計算です。スケーリングは、Access Gatewayクラスターサイズの増減によるシステムリソース消費の最適化です。

容量計画を実行するには、現在のアクセスレートを特定し、Access Gatewayの消費データを使って将来の消費シナリオを推定します。

このトピックでは、環境に応じた容量計画を計算できるように、Access Gatewayの消費データとシステムの要件について説明します。

現在のアクセスレートを推定する

将来のリソース消費要件を予測するには、事前にベースラインを確立する必要があります。このベースラインは、現在の消費レベルです。Access Gatewayが対応しなければならないアクセスと認証の数を計算します。将来の予測は、収集するデータの期間が長いほど高精度になります。

  1. ロギングシステムやその他のソースから次のデータを収集します。
    • その期間の高、低、平均アクセス数と認証数。
    • 需要が最も多い時間帯と日にち。
    • 需要が最も少ない時間帯と日にち。
    • Access Gatewayにアクセスするユーザーの総数
    • アプリを毎日利用するユーザーの数。
    • ユーザーが1日にアプリにアクセスする回数。
    • 各ユーザーが1回のセッションで行うページアクセスの数。
    • Access Gatewayが保護するアプリの数。
  2. ユーザー数とアクセス数の現在の値を計算するには、次の計算式で収集データを使用します。
    平均アクセス 全体的アクセス
    平均ユーザー数 = ユーザー総数 ÷ 1日当たりの推定ユーザー数 全体アクセス数 = 平均アクセス数 x ページアクセス数
    平均アクセス数 = 平均ユーザー数 ÷ 1日当たりの推定アクセス数 全体的な平均アクセス数 = 平均ユーザー数 x 1日あたりのアクセス数
  3. ユーザーをアクセス頻度別に分類します。
    • 頻繁なユーザー（Frequent users）：1日に5回以上システムにアクセスする。
    • 頻繁でないユーザー（Infrequent users）：1日に1～2回システムにアクセスする。
    • まれなユーザー（Rare users）：1週間に1～3回システムにアクセスする。
  4. 各ユーザーグループの一般的なアクセスレートを計算します。たとえば、頻繁なユーザーが5000人で、1日に5回システムにアクセスするのであれば、そのグループの1日あたりのアクセス数は25,000となります。

ハードウェア要件を推定する

ハードウェアには、Access Gatewayデプロイメントの最適パフォーマンスを確保するために必要なメモリとハードディスクの容量、CPUとコアの数、スループットのレベルが反映されます。

メモリ要件

項目 本番環境の最小要件
オペレーティングシステム、Access Gatewayエンジン、マイクロサービス 1.5GB
セッションのキャッシュ 128MB
平均セッションサイズ 1,024バイト
Kerberosチケット。これらのチケットは、アクセスされるIISアプリの数に応じて大きくなる場合があります。 1,024バイト

WebアプリとKerberosセッションのキャッシュを計算する

セッションキャッシュに必要な容量を計算するには、セッションの総数と平均セッションサイズを掛け合わせ、その結果を2倍にします。

各セッションは、ユーザー数、1日あたりのユーザーサインインイベントの割合、ユーザーがアクセスするアプリの数から計算されます。

セッションキャッシュに必要な容量を計算するには、次の式を使用します：セッション総数 x （平均セッションサイズ x 2）

次に、この式の使用方法を示すシナリオを紹介します。

ユーザー 1日当たりのサインインの割合 アクセスされたアプリ 総セッション数 セッションサイズ セッションキャッシュ
5,000 50% 5 1日当たりのユーザーサインインの割合 x アクセスされたアプリ

12,500

 1,024バイト x 2 約25MB
10,000 75% 10 75,000 1,024バイト x 2 約150MB
25,000 50% 100 125,000 1,024バイト x 2 約500MB

Kerberosアプリでは、追加のキャッシュ要件が生じます。

ユーザー 1日当たりのサインインイベントの割合（%） アクセスされたIISアプリ 総セッション数 セッションサイズ セッションキャッシュ
10,000 50% 5 1日当たりのユーザーサインインの割合 x アクセスされたアプリ

25,000

 1,024バイト 約50MB

ハードディスク要件

Access Gatewayでは、次の要素向けにハードディスク容量が必要になります。一定期間におけるこれらの要素の数とサイズを決定してください：

  • ソフトウェア（Software）：Access Gatewayソフトウェアとオペレーティングシステム。ソフトウェアファイルのサイズは通常は小規模です。
  • バックアップ（Backups）：毎晩実行され、30日間維持されます。バックアップファイルのサイズは通常は小規模です。
  • System Log：ログファイルはローカルディスクにスプールされ、認証、承認、監査、アクセス、セッション、および全ログのファイルがあります。通常、HTTP/HTTPSリクエストごとに1エントリとなります。ユーザー数、ユーザーがアプリにアクセスする回数、そのアプリで生じるページビューの数を考慮してください。
  • ログアーカイブ（Log archives）：ロール、圧縮され、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 3,072バイト = 76,800,000バイト、または1日約230.4MB
1か月（30日）あたりの増加ディスクサイズ 1日あたりの増加ディスクサイズ x 30

230.4 x 30 = 6.912GB
1年間（365日）の増加ディスクサイズ 1日あたりの増加ディスクサイズ x 365 = 84.096GB

CPUとコア

Access Gatewayエンジンは、すべてのCPUに自動的にスケーリングされ、その結果、1 CPUごとに1ワーカーが生じます。コアを追加するたびにスレッドが追加され、追加の処理が可能になります。

スループット

スループットは、ネットワークを介したデータ配信のレートを意味します。Access Gatewayでは、ネットワークを介して配信されるデータには、認証、承認、リターンコンテンツのデータが含まれます：

  • 認証：処理されたSAMLアサーションの数（Oktaから各アプリへ）
  • 承認：HTTPリクエストごとにチェックされたポリシーの数（すべてのHTTPリクエスト）

認証と承認の各リクエストは約1024バイトを使用し、2048バイトのリターンデータを生じます。ネットワークスループットは、次の式を使って計算できます：

Sign-in attempts per second x (authentications + authorizations per second + returned data size)

平均ネットワーク帯域幅の計算には、次の式を使用します：

Average response size x average request arrival rate

平均的な応答のサイズが約20KBであれば、500リクエストの場合、結果は20KB×500となり、1秒あたり10MBに相当します。

インスタンスサイズを推定する

各インスタンスサイズでサポートできるユーザー数と認証数は、多くの複雑な要因に応じて異なります。サーバーで利用できる総ディスク容量とメモリ容量の関係や、プロセッサーとネットワーク接続の速度などの要因が容量に影響します。

Access Gatewayでは、環境に適した構成を選択できます。複数のコアと大容量のメモリモジュールを備えたハードウェアには、Access Gatewayのインスタンスを1つ、または2つデプロイできます。または、クラスター内の複数のサーバーに分散した、より小規模な多数のインスタンスにAccess Gatewayをデプロイすることもできます。

Access Gatewayインスタンスがサポートできるユーザー数の決定については、このページの計算を使用するか、自分の環境についてOktaサポートまでお問い合わせください。

次の表は、さまざまなサイズのAccess Gatewayインスタンスのサポートに必要な最小ハードウェア構成を示しています。テーブルに示されるユーザーとアプリの数は、あくまでもガイドラインとしてのものです。実際のパフォーマンスは、環境独自の要因によって異なります。

使用 物理/仮想ハードウェア AWSの同等タイプ
概念実証
次のハードウェアを備える1つのインスタンス：
  • 2コア2ギガバイトのメモリー
  • 220ギガバイト（デフォルト）のハードドライブ
  • 1 Gbps NIC x 1
t2.medium
小
  • 1,000～5,000ユーザー
  • 1～10アプリ
それぞれが次のハードウェアを備える2つのインスタンス：
  • 2コア4ギガバイトのメモリ
  • 220ギガバイト（デフォルト）のハードドライブ
  • 1 Gbps NIC x 1
 t2.medium
中
  • 5,000～20,000ユーザー
  • 10～100アプリ
それぞれが次のハードウェアを備える3つのインスタンス：
  • 2コア8ギガバイトのメモリ
  • 220ギガバイトのハードドライブ
  • 1 Gbps NIC x 1
 m4.large
大
  • 20,000ユーザー以上
  • 100アプリ以上
それぞれが次のハードウェアを備える3つのインスタンス：
  • 4コア16ギガバイトのメモリ
  • 220ギガバイトのハードドライブ
  • 1 Gbps NIC x 1
 m4.xlarge。「AWSインスタンスタイプ」を参照してください。

スケーリング要件を推定する

スケーリングは、Access Gatewayクラスターサイズを増減させるタスクです。

  • 垂直スケーリング（Scaled vertically）：特定インスタンスのメモリ、ディスク、CPUを追加または削除します。過度なロギングが生じるときは、ログフォワーディングソリューションを使ってAccess Gatewayのログレベルを最小（警告またはエラー）に設定します。アプライアンスのディスク容量を拡張する必要があるときは、Oktaプロフェッショナルサービスまでお問い合わせください。
  • 水平スケーリング（Scaled horizontally）：クラスターのAccess Gatewayインスタンスを追加または削除します。

Oktaは、すべてのAccess Gateway高可用性クラスターメンバーを、同じCPU、メモリ、ディスク構成でデプロイすることをお勧めします。

認可サーバーノードのサイズ設定

Access Gatewayをオフラインにデプロイする場合は、Access Gatewayノードに加えて、認証サービス用に別のサーバーをプロビジョニングします。既存のAccess Gatewayノードで認証サービスを実行することは、CPUとRAMの要件により、本番用デプロイメントでは推奨されていません。

次の表に、各ユースケースに推奨される認可サーバーノードの仕様を示します。
使用 Access Gatewayクラスター 各Access GatewayノードのAWS同等タイプ Access Gateway認可サーバーノード 認可サーバーノード用のAWS同等タイプ
概念実証（1つのサーバー上のAccess Gatewayクラスター） 次のハードウェアを備える1つのインスタンス：
  • 2個のCPUコア
  • 2 GBのRAM
  • 220 GBのハードドライブ
  • 1 Gbps NIC x 1
 t2.medium 2個のCPUコアと2 GBのRAMを備える1つのインスタンス。以下を管理できます。
  • 1秒あたり30回のパスワードベースのユーザーサインイン/サインアウト、または
  • 1秒あたり240件のリフレッシュトークンリクエスト、または
  • 1秒あたり240個のクライアント資格情報付与、または
  • 16,000回のキャッシュされたセッション。
 t2.medium
小
  • ユーザー1,000～5,000人
  • 1～10アプリ
 それぞれが次のハードウェアを備える2つのインスタンス：
  • 2個のCPUコア
  • 4 GBのRAM
  • 220 GBのハードドライブ
  • 1 Gbps NIC x 1
 t2.medium 4個のCPUコアと8 GBのRAMを備える1つのインスタンス。以下を管理できます。
  • 1秒あたり60回のパスワードベースのユーザーサインイン/サインアウト、または
  • 1秒あたり480件のリフレッシュトークンリクエスト、または
  • 1秒あたり480個のクライアント資格情報付与。
 c5.xlarge
中
  • ユーザー5,000～20,000人
  • 10～100アプリ
 それぞれが次のハードウェアを備える3つのインスタンス：
  • 2個のCPUコア
  • 8 GBのRAM
  • 220 GBのハードドライブ
  • 1 Gbps NIC x 1
 m4.large 8個のCPUコアと32 GBのRAMを備える1つのインスタンス。以下を管理できます。
  • 1秒あたり120回のパスワードベースのユーザーサインイン/サインアウト、または
  • 1秒あたり960件のリフレッシュトークンリクエスト、または
  • 1秒あたり960個のクライアント資格情報付与。
 t2.2xlarge
大
  • ユーザー20,000人超
  • アプリ100個超
 それぞれが次のハードウェアを備える3つのインスタンス：
  • 4個のCPUコア
  • 16 GBのRAM
  • 220 GBのハードドライブ
  • 1 Gbps NIC x 1
 m4.large 12個のCPUコアと48 GBのRAMを備える1つのインスタンス。以下を管理できます。
  • 1秒あたり180回のパスワードベースのユーザーサインイン/サインアウト、または
  • 1秒あたり1,440件のリフレッシュトークンリクエスト、または
  • 1秒あたり1,440個のクライアント資格情報付与。
 m5zn.3xlarge

認可サーバーノードのvCPU要件

次のベンチマークを使用して、単一の認証サービスノード上の操作に必要なvCPU要件を推定しましょう。
操作 vCPUあたりのスループット
パスワードベースのユーザーサインイン 1秒あたり15
クライアント資格情報付与 1秒あたり120
リフレッシュトークンリクエスト 1秒あたり120
たとえば、次のボリュームのある環境では、次のようになります。
  • 1秒あたり45回のサインイン/サインアウト
  • 1秒あたり360個のクライアント資格情報付与
  • 1秒あたり360件のリフレッシュトークンリクエスト

必要なvCPUは、45 ÷ 15 + 360 ÷ 120 + 360 ÷ 120 = 3 + 3 + 3 = 9 vCPUです。

vCPUの合計を計算したら、ピーク使用量を処理するために50%の余裕を追加し、合計は9 x 1.5 = 14 vCPUになります。

認可サーバーノードのRAM要件

認可サーバーノードには、レルムデータキャッシュとキャッシュされたセッション10,000件をサポートするために約1,250 MBのRAMが必要です。メモリが不十分な場合、ごみ箱がより頻繁に実行されるため、CPUの使用量が増加し、パフォーマンスが低下します。