App Service のサイズ設定

基本事項

SCEPmanは主にCPUリソースに依存します。メモリやディスクははるかに重要度が低いです。

1つのSCEPmanインスタンス（バージョン3.0以降）を1つのAzure P0V3 App Serviceプラン（195 ACU）で運用した場合、通常の条件下で毎分約4000リクエストを処理できます。リクエストは

• SCEP発行リクエストと

• OCSPリクエストです。

これは、SCEPmanがACUあたり約毎分20リクエストを処理できることを意味します。

証明書は一度登録されますが、有効性は何度もチェックされるため、合計ではSCEPリクエストよりもはるかに多くのOCSPリクエストが発生します。したがって、SCEPmanインスタンスのサイズはOCSPリクエストに基づいて決めるべきです。

依存関係

SCEPmanサービスへの負荷にはいくつかの依存関係があり、環境によって変動します。重要な依存項目は次のとおりです：

1. リクエストの分布

2. ネットワークリソースへのログイン頻度

3. 証明書リクエスト／更新の頻度

特にリクエストの分布は重要です。すべてのクライアントが同時にリクエストを行うと、SCEPmanインスタンスに大きな負荷がかかります。いかなる場合でもSCEPmanがSCEPリクエストに1分未満で応答できるようにすることを目指すべきです。

SCEPプロファイルを多数のユーザー／デバイスに一度に割り当てないでください。これによりSCEPmanインスタンスでリクエストのピークが発生する可能性があります。

推奨事項

開始点として、Azure App ServiceプランのAzure Compute Units（ACU）に関して次のサイズを推奨します：

ユーザー／クライアント数	単一構成	ジオ冗長構成
< 5000 クライアント	約100 ACU （例：1 x S1）	2 x 約100 ACU （例：2 x S1）
< 10,000 クライアント	約200 ACU （例：1 x P0V3）	2 x 約200 ACU （例：2 x P0V3）
< 25,000 クライアント	約400 ACU （例：2 x P0V3）	2 x 約400 ACU （例：4 x P0V3）
< 50,000 クライアント	約800 ACU （例：4 x P0V3）	2 x 約800 ACU （例：8 x P0V3）
< 100,000 クライアント	約1600 ACU （例：4 x P1V3）	2 x 約1600 ACU （例：8 x P1V3）
> 100,000 クライアント	約3200 ACU （例：4 x P2V3）	2 x 約3200 ACU （例：2 x 4 x P2V3）

これらの推奨に基づいて、トラフィックを監視し、以下のセクションに記載のように縮小できるかどうかを確認できます。 微調整 以下。

Azureコスト予測

主なAzureコストはAzure App Serviceプランに対するものになります。上の表の要件からコストを算出し、 あなたのAzure価格表 または一般的な割引のない App Serviceの料金 概要を参照してください。

追加のAzureリソース（Key Vault、Storage Account、Log Analytics、プライベートエンドポイント用のネットワークリソース）はコストに対して小さな割合を占めます。環境のユースケースによりますが、これら追加リソースのためにApp Serviceプラン費用の上にさらに5%〜25%を見込むべきです。

このコスト見積もりはAzureのコストを推定するための経験則にすぎません。環境により大きく異なる場合があります。

微調整

各環境は1日の中で独自の負荷分布を持っています。多くの環境では、朝（業務開始時）がSCEPmanにとって負荷のピークを生み出します。

手動スケール

Azure App Serviceのスケールアウト機能を使って、App Serviceの計算能力を個々の1日あたりの負荷分布に合わせて調整できます。例えば、朝のピークをカバーするために08:00〜10:00に2 x S1を定義し、残りの時間は1 x S1に減らす、などが可能です。

自動スケール

代替として、必要なリソースに合わせて適応するためにAzureの自動スケーリング機能を利用できます。その詳細は オートスケーリング.

手動スケール vs. 自動スケール

負荷をうまく予測できる場合（例えば過去の負荷履歴から導出できる場合）は、フラッピングを防ぐために自動スケールは遅延（ヒステリシス）動作を行う必要があるため、手動スケールを自動スケールより推奨します。