데이터 계층 성능

목차
sm1252sp1kkr
목차
2
Single Sign-On
데이터 저장소, 특히 사용자 디렉터리와 연관된 성능 저하는
Single Sign-On
성능 저하의 가장 일반적인 원인 중 하나입니다. 데이터 계층 성능은 일반적으로 다음 두 가지 일반 영역과 관련이 있습니다.
  • 데이터 계층 자체. 적절하게 조정되지 않았거나 시스템 리소스가 부족한 사용자 디렉터리로 인해
    Single Sign-On
    성능이 저하될 수 있습니다.
  • 사용자 디렉터리가 작동해야 하는 용량.
    Single Sign-On
    인증 및 권한 부여 서비스 때문에 사용자 디렉터리에 대해 많은 수의 읽기 및 쓰기(통칭하여 요청)가 수행됩니다.
    Single Sign-On
    작업 부하를 처리할 수 있도록 사용자 디렉터리 자체에 대한 용량 계획 수립을 수행하십시오.
성능 전략은 다음과 같습니다.
  • 데이터 계층 자체가 성능 저하의 주요 원인이 아닌지 확인합니다.
  • 특정 기간 동안
    Single Sign-On
    이 처리해야 하는 인증 및 권한 부여의 수를 식별합니다.
    참고:
    사용자 인증 및 권한 부여가 발생하는 지속적 비율 및 최고 비율을 계산할 수 있습니다.
  • 각각의 사용자 인증 및 이후의 권한 부여가 생성하는 사용자 디렉터리 요청의 수를 추정합니다.
데이터 계층 지침
정책 서버는 표준 프로토콜을 사용하여 데이터 계층과 상호 작용합니다. 디렉터리 서버 및 데이터베이스가 일반적인 클라이언트에서 최대한의 성능을 발휘하도록 조정된 경우에는 이러한 조정을 통해
Single Sign-On
성능이 향상됩니다.
참고:
조정 지침은 해당 공급업체의 설명서를 참조하십시오.
Single Sign-On
성능은 사용자 디렉터리의 성능과 연관되므로 그 성능을 향상시키기 위한 몇 가지 일반적인 고려 사항이 있습니다. 다음 영역을 확인하십시오.
  • 사용자 디렉터리가 사용할 수 있는 시스템 리소스와 이러한 리소스를 사용하기 위해 경합할 수 있는 모든 외부 리소스
  • SSL(Secure Socket Layer)의 사용
  • Single Sign-On
    이 사용자 디렉터리를 검색할 수 있는 효율성
  • 정적 IP 주소의 사용
  • 복제의 사용
시스템 리소스
사용자 디렉터리가 사용할 수 있는 시스템 리소스는
Single Sign-On
의 성능과 직접적으로 관련이 있습니다. 사용자 디렉터리가 높은 수준의 사용률로 작동 중인 경우에는
Single Sign-On
을 조정하여 성능을 향상시킬 수 없습니다.
사용자 디렉터리를 호스트하는 시스템의 성능이 다음 사항으로 인해 저하되지 않는지 확인하십시오.
  • 느린 CPU 또는 I/O 시스템
  • 메모리 부족
  • 올바르지 않게 구성된 버퍼 캐시
  • 부족하거나 단편화된 디스크 공간
SSL(Secure Socket Layer) 및 사용자 디렉터리
Single Sign-On
환경에 SSL을 구성할 계획이라면 다음 사항을 고려하십시오.
  • 정책 서버와 LDAP 사용자 디렉터리가 SSL을 통해 통신하도록 구성하면 성능이 저하됩니다. 보안 요구 사항을 검토하여 SSL이 필수인지 확인하십시오.
  • SSL을 구성하기로 결정한 경우에는 정책 서버와 디렉터리 서버 사이에 SSL 가속기를 배치하지 마십시오. 그렇지 않으면 정책 서버가 디렉터리의 단일 인스턴스를 가정합니다. 이 경우 가속기 뒤의 여러 사용자 디렉터리 간에 일관되지 않은 쓰기가 발생할 수 있습니다.
정적 IP 주소 및 사용자 디렉터리
관리 UI에서 사용자 디렉터리 연결을 구성할 때 호스트 이름 대신 정적 IP 주소를 사용하는 방법을 고려하십시오. 정책 서버가 호스트 이름을 확인하는 데 걸리는 시간은 무시해도 좋은 정도지만 정적 IP 주소를 사용하면 DNS(Domain Naming Services) 종속성이 제거됩니다.
사용자 디렉터리 검색
Single Sign-On
이 사용자 디렉터리를 효율적으로 검색할 수 있도록 하면 성능에 직접적인 영향을 미칩니다. 다음 사항을 고려하십시오.
  • 디렉터리 인덱싱을 사용하여
    Single Sign-On
    의 검색 결과를 향상시킵니다.
    • LDAP - 검색에 사용되는 다른 모든 특성에 더하여 objectClass 특성도 인덱싱해야 합니다.
      참고:
      Microsoft에서는 objectClass 대신 objectCategory 특성을 사용할 것을 권장합니다. Active Directory에서 objectClass 특성을 인덱싱하지 못하면 성능이 크게 저하될 수 있습니다.
    • ODBC -
      Single Sign-On
      스키마 쿼리에서 검색 조건으로 정의된 모든 필드는 인덱싱되어야 합니다.
      참고:
      인덱싱에 대한 자세한 내용은 공급업체 설명서를 참조하십시오.
  • 관리 가능한 사용자 그룹 집합을 반환하도록 쿼리를 설계합니다.
    참고:
    쿼리를 최적화할 수 없는 경우 최대 검색 결과 매개 변수를 설정하여 너무 큰 결과 집합으로 인해 전체 성능이 저하되는 것을 방지하십시오.
  • 표준 SQL 분석기로 ODBC에 대한 SQL 쿼리 체계를 최적화합니다.
복제
복제는 다음 상황에서 성능을 저하시킬 수 있습니다.
  • 마스터-슬레이브 복제에서 마스터 복제본만 쓰기 요청을 허용하는 경우. 일반적으로 암호 서비스를 사용할 때는 각 인증마다 암호 Blob 특성을 업데이트해야 합니다. 마스터 복제본만 쓰기를 처리할 수 있는 경우에는 각 쓰기 요청이 마스터로 리디렉션됩니다.
    이 리디렉션으로 인해 인증 단계에서 시간이 더 소요되며 마스터-복제본이 쓰기가 발생하는 속도를 수용하지 못할 수 있습니다.
  • LDAP 조회가 사용되는 경우. LDAP 조회의 경우 각 요청에 디렉터리에 대한 둘 이상의 요청이 수반될 수 있으므로 성능을 저하시킬 수 있습니다.
사용자 저장소 용량 계획
정책 서버는 일련의 서비스를 수행하여 사용자를 인증하고, 권한을 부여합니다. 이러한 서비스의 결과로 사용자 디렉터리에 대한 여러 개의 읽기 및 쓰기가 발생하며 이를 통칭하여 요청이라고 합니다. 지속적 작업 및 최고 작업 기간 중 사용자 디렉터리가 이러한 작업 부하를 처리할 수 있는지 여부를 파악하면
Single Sign-On
성능에 큰 도움이 됩니다.
Single Sign-On
성능에 영향을 미치는 일반적인 요소는 다음과 같습니다.
  • 총 작업 수 및 지속적 사용자 디렉터리 검색 비율 - 총 작업 수는 인증 및 권한 부여 요청을 처리할 때 정책 서버가 처리해야 하는 조합된 요청 수입니다. 이러한 작업이 발생하는 비율은 업무일 동안 크게 변동할 수 있습니다.
    이에 따라 정책 서버가 작업을 처리하기 위해 사용자 디렉터리 요청을 생성하는 속도가 변동합니다. 어떤 기간에는 비교적 적은 수의 사용자 디렉터리 요청이 생성되지만 다른 기간에는 더 많은 수가 생성됩니다.
    지속적 사용자 디렉터리 검색 비율은 정책 서버가 평균적인 숫자의 작업을 처리하기 위해 평균적인 숫자의 사용자 디렉터리 요청을 생성하는 기간을 나타냅니다.
  • 총 작업 및 최고 사용자 디렉터리 검색 비율 - 지속적 활동 기간 중에 사용자 활동이 급증할 수 있습니다. 최고 사용자 디렉터리 검색 비율은 정책 서버가 최고 작업 수를 처리하기 위해 가장 높은 수의 사용자 디렉터리 요청을 생성하는 기간을 나타냅니다.
사용자 디렉터리가 작동해야 하는 부하를 추정할 때는 다음 지침을 사용하는 것이 좋습니다. 부하를 추정한 후에는 표준 도구를 사용하여 디렉터리에 부하를 생성하고 그 결과를 추적할 수 있습니다.
참고:
여러 요소로 인해 필요한 수치를 달성하지 못할 수 있습니다. 조정 지침은 해당 공급업체의 설명서를 참조하십시오.
사용자 저장소 용량 계획 검사 목록
인증 및 권한 부여 요청을 처리하기 위해 정책 서버가 수행해야 하는 사용자 디렉터리 요청의 수를 추정하려면 특정 정보가 필요합니다. 사용자 저장소 용량 계획을 시작하기 전에 다음 정보를 수집하십시오.
  • 응용 프로그램에 대한 일별 총 인증 수(인증 부하)
  • 응용 프로그램에 대한 일별 총 권한 부여 수(권한 부여 부하)
  • 사용자가 응용 프로그램에 인증되고 보호된 리소스를 요청하는 지속적 기간 및 최고 기간
    참고:
    용량 계획을 수립하면 사용자 활동의 인증 부하, 권한 부여 부하 및 지속적 수준과 최고 수준에 관련된 메트릭을 식별하는 데 도움이 됩니다.
  • 활성화된 정책의 총 숫자. 각 정책에 대해 다음을 확인합니다.
    • 정책 구성원 자격 필터로 인해 하나 이상의 사용자 디렉터리 검색이 수행되는지 여부
    • 정책에 바인딩된 응답으로 인해 하나 이상의 사용자 디렉터리 검색이 수행되는지 여부
지속적 사용자 디렉터리 검색 비율을 추정하는 방법
지속적 사용자 디렉터리 검색 비율을 추정하려면 다음을 확인해야 합니다.
  • 업무일 중 총 사용자 디렉터리 요청 수의 변동
  • 사용자 디렉터리 요청이 지속 기간 동안 초당 요청 수로 해석되는 방식
지속적 사용자 디렉터리 검색 비율을 추정하려면 다음 단계를 완료하십시오.
  1. 인증 지침을 사용하여 인증 부하가 생성하는 사용자 디렉터리 요청의 수를 추정합니다.
  2. 권한 부여 지침을 사용하여 권한 부여 부하가 생성하는 사용자 디렉터리 요청의 수를 추정합니다.
  3. 지속적 사용자 디렉터리 검색 비율을 추정합니다.
인증 지침을 사용하여 디렉터리 검색 추정
정책 서버는 각 인증 요청을 처리하기 위해 많은 수의 사용자 디렉터리 요청을 생성합니다. 사용자 디렉터리 요청 중 일부는 필요하지만 다른 일부는 회피할 수 있습니다.
다음 지침을 사용하여 각 인증으로 인해 생성되는 정책 서버 요청 수를 추정하십시오.
(필수) 각 사용자를 인증하기 위한 두 개의 검색:
  • 사용자를 식별하기 위한 저장소당 하나의 검색/쿼리
  • 사용자 자격 증명을 확인하기 위한 하나의 검색/쿼리
(선택 사항) 정책을 설계한 방식과 암호 서비스를 활성화했는지 여부에 따라 추가 검색이 필요할 수 있습니다.
  • 사용자가 인증될 때 수행되는 규칙(OnAuth 규칙)에 바인딩된 각 정책에 대한 하나의 검색/쿼리
  • 사용자 특성을 반환하는 응답에 바인딩된 각 정책마다 하나의 검색/쿼리
  • 암호 서비스에 대해 활성화된 사용자 저장소당 하나의 쓰기/업데이트. 암호 서비스가 정책 도메인의 사용자 디렉터리에 적용되지 않는 경우 쓰기/업데이트는 필수가 아닙니다.
다음 사용 사례에서는 각 지침을 사용하여 인증 부하로 인해 생성되는 총 사용자 디렉터리 검색 수를 확인하는 방법을 자세히 설명합니다.
사례 1: 사용자 인증 및 디렉터리 요청
회사에서 다음을 완료했습니다.
  • 뱅킹 응용 프로그램을 위한 하나의 사용자 디렉터리를 배포했습니다.
  • 용량 계획을 수립했습니다. 그 결과 사용자가 88,000회의 로그인으로 인증 부하를 생성하는 것으로 확인되었습니다.
회사에서는 다음 공식을 사용하여 정책 서버가 인증 부하를 처리하기 위해 사용자 디렉터리로 전송하는 요청 수를 추정하기 시작합니다.
authentication_load * 2 * number_of_user_stores = requests_for_authentication
  • authentication_load
    응용 프로그램에 대한 일별 인증 수를 지정합니다.
    참고:
    2는 상수입니다. 사용자를 인증할 때 두 회의 요청이 생성됩니다. 사용자를 식별하기 위한 검색 하나와 자격 증명을 확인하기 위한 바인딩 하나입니다.
  • number_of_user_stores
    구현의 사용자 저장소 수를 지정합니다.
  • requests_for_authentication
    인증 부하가 생성하는 사용자 디렉터리 요청의 수를 지정합니다.
결과:
88,000 * 2 * 1 = 176,000회의 요청
회사는 이 추정을 사용하여 일별 인증 부하를 처리하기 위해 필요한 총 사용자 디렉터리 요청 수를 결정합니다.
사례 2: 정책 설계 및 사용자 디렉터리 요청
회사는 응용 프로그램 포털을 보호하기 위해 네 개의 정책을 구성했으며, 그중 하나는 인증 성공 시 수행되는 규칙에 바인딩됩니다.
회사에서는 다음 공식을 사용하여 정책 서버가 인증 부하를 처리하기 위해 사용자 디렉터리로 전송하는 요청 수의 추정을 계속합니다.
authentication_load
* (
percent_of_policies
*
number_of_searches
) =
requests_for_authentication
  • authentication_load
    응용 프로그램에 대한 일별 인증 수를 지정합니다.
  • percent_of_policies
    활성화된 정책의 총 수를 지정하며, 백분율로 표현되고 특성은 다음과 같습니다.
    • onAuth 규칙에 바인딩됩니다.
    • 동일한 수의 사용자 디렉터리 검색을 생성합니다.
    예:
    활성화된 정책이 4개 있습니다. 하나는 OnAuth 규칙에 바인딩됩니다. 이 정책은 정책 구성원 자격을 확인하기 위해 하나의 사용자 디렉터리 검색을 생성합니다. 활성화된 정책의 25%가 인증 시 실행되며 하나의 사용자 저장소 검색을 생성합니다. 나머지 정책은 인증 도중에 실행되지 않습니다.
  • number_of_searches
    정책이 인증된 각 사용자에게 적용되는지를 확인하기 위해 정책 서버가 수행하는 요청의 수를 지정합니다.
  • requests_for_authentication
    인증 부하가 생성하는 사용자 디렉터리 요청의 수를 지정합니다.
결과:
88,000 * 0.25 * 1 = 22,000회의 요청
회사는 이 추정을 사용하여 일별 인증 부하를 처리하기 위해 필요한 총 사용자 디렉터리 요청 수를 결정합니다.
사례 3: 응답 및 사용자 디렉터리 요청
회사에서 OnAuth 규칙을 사용하여 하나의 정책을 정의했습니다. 이 정책에 따르면 정책이 실행될 때 CN(일반 이름) 특성 응답이 반환되어야 합니다. 회사는 이 값을 반환하기 위한 웹 에이전트 응답을 정의하고 이를 정책 규칙에 바인딩합니다.
회사에서는 다음 공식을 사용하여 정책 서버가 인증 부하를 처리하기 위해 사용자 디렉터리로 전송하는 요청 수의 추정을 계속합니다.
authentication_load
*
percent_of_policies
*
number_of_responses_per_policy
=
requests_for_authentication
  • authentication_load
    응용 프로그램에 대한 일별 인증 수를 지정합니다.
  • percent_of_policies
    사용자 특성을 반환하는 특정한 수의 응답에 바인딩된, 활성화된 정책의 전체 수(백분율로 표현)를 지정합니다.
    예:
    활성화된 정책이 네 개이고 그중 하나가 응답을 사용하여 사용자 특성을 반환할 경우 정책의 25%에 사용자 디렉터리 검색이 필요합니다.
  • number_of_responses_per_policy
    정책에 바인딩된 응답의 수를 지정합니다.
  • requests_for_authentication
    인증 부하가 생성하는 사용자 디렉터리 요청의 수를 지정합니다.
결과:
88,000 * 0.25 * 1 = 22,000회의 요청
회사는 이 추정을 사용하여 일별 인증 부하를 처리하기 위해 필요한 총 사용자 디렉터리 요청 수를 결정합니다.
사례 4: 암호 서비스 및 디렉터리 요청
회사에서 사용자 저장소에 대해 암호 서비스를 활성화했습니다. 회사에서는 다음 공식을 사용하여 정책 서버가 인증 부하를 처리하기 위해 사용자 디렉터리로 전송하는 요청 수의 추정을 계속합니다.
authentication_load
* 1 =
requests_for_authentication
  • authentication_load
    응용 프로그램에 대한 일별 인증 수를 나타냅니다.
    참고:
    1은 상수입니다. 사용자 로그인 상세 정보를 추적하려면 각 인증마다 하나의 사용자 디렉터리 쓰기가 필요합니다.
  • requests_for_authentication
    인증 부하가 생성하는 사용자 디렉터리 요청의 수를 나타냅니다.
결과:
88,000 * 1 = 88,000회의 요청
회사는 이 추정을 사용하여 일별 인증 부하를 처리하기 위해 필요한 총 사용자 디렉터리 요청 수를 결정합니다.
사례 5: 인증에 대한 총 디렉터리 요청 수
회사에서는 각 사용 사례의 개별적인 총계를 사용하여 정책 서버가 인증 부하를 처리하기 위해 사용자 저장소에 전송하는 총 요청 수를 확인합니다.
  • 88,000명의 고유한 사용자와 이들의 자격 증명을 식별하기 위한 176,000회의 요청
  • OnAuth 정책이 해당 사용자에게 적용되는지 확인하기 위한 22,000회의 요청
  • 인증 시 일반 이름 특성을 반환하기 위한 22,000회의 요청
  • 암호 정책에 대한 88,000회의 요청
결과:
176,000 + 22,000 + 22,000 + 88,000 = 322,080회의 요청
회사는 이 결과와 권한 부여에 기반한 결과를 사용하여 사용자 저장소가 정책 서버 요청을 처리해야 하는 지속적 비율을 추정합니다.
권한 부여 지침을 사용하여 디렉터리 검색 추정
정책 서버는 사용자에게 권한을 부여하기 위해 몇 개의 사용자 디렉터리 요청을 수행합니다. 어떤 사용자 디렉터리 요청은 정책 구성원 자격을 확인하기 위해 필요하지만 다른 요청은 정책 설계에 따라 다릅니다. 다음 지침을 사용하면 각 권한 부여로 인해 생성되는 정책 서버 요청 수를 추정할 수 있습니다.
  • 정책 도메인의 각 정책마다 하나의 검색/쿼리
    참고:
    이 지침은 구성원 자격 필터의 결과로 하나 이상의 사용자 디렉터리 요청이 생성되는 정책에만 적용됩니다. 정책 구성원 자격과 사용자 디렉터리 요청의 관계에 대한 자세한 내용은 "Policy Membership and Authorization Requests"(정책 구성원 자격 및 권한 부여 요청)을 참조하십시오.
  • 사용자 특성을 반환하는 응답에 바인딩된 각 정책마다 하나의 검색/쿼리
    참고:
    응답과 사용자 디렉터리 요청의 관계에 대한 자세한 내용은 "응답 및 권한 부여 성능"을 참조하십시오.
다음 사용 사례에서는 각 지침을 사용하여 권한 부여 부하로 인해 생성되는 총 사용자 디렉터리 검색 수를 확인하는 방법을 자세히 설명합니다.
참고:
사용자 권한 부여 캐시를 통해 사용자 디렉터리에 대한 권한 부여 관련 요청의 수를 크게 줄일 수 있습니다.
사례 1: 정책 구성원 자격 및 사용자 디렉터리 요청
회사에서 포털 응용 프로그램을 보호하는 세 개의 정책을 활성화했습니다.
  • 정책 A에는 정책 구성원 자격을 확인하기 위해 하나의 사용자 디렉터리 요청이 필요합니다.
  • 정책 B에는 정책 구성원 자격을 확인하기 위해 최대 두 개의 사용자 디렉터리 요청이 필요합니다.
  • 정책 C에는 정책 구성원 자격을 확인하기 위해 최대 세 개의 사용자 디렉터리 요청이 필요합니다.
또한 용량 계획 수립 결과 응용 프로그램의 권한 부여 부하가 726,000회인 것으로 확인되었습니다.
회사에서는 다음 공식을 사용하여 정책 서버가 권한 부여 부하를 처리하기 위해 사용자 디렉터리로 전송하는 요청 수의 추정을 시작합니다.
authorization_load
x
percent_of_policies
*
number_of_searches
=
daily_authorization_requests
  • authorization_load
    응용 프로그램에 대한 일별 권한 부여 수를 지정합니다.
  • percent_of_policies
    정책 구성원 자격을 확인하기 위해 동일한 숫자의 사용자 디렉터리 요청을 생성할 수 있는 활성화된 정책의 수(백분율로 표현)를 지정합니다.
    참고:
    총 백분율은 100%여야 합니다.
  • number_of_searches
    정책 서버가 정책 구성원 자격을 확인하기 위해 수행할 수 있는 사용자 디렉터리 요청의 수를 지정합니다.
  • daily_authorization_requests
    권한 부여 요청을 처리하기 위한 사용자 디렉터리 요청의 수를 지정합니다.
결과:
  • 정책 A - 792,000 * 0.33 * 1= 261,360회의 요청
  • 정책 B 및 C - 792,000 * 0.66 * 2= 1,045,440회의 요청
  • 총 사용자 디렉터리 요청-158,000 + 1,045,440= 1,306,880회의 요청
회사는 이 추정을 사용하여 일별 권한 부여 부하를 처리하기 위해 필요한 총 사용자 디렉터리 요청 수를 결정합니다.
사례 2: 응답 및 사용자 디렉터리 검색
회사에서 포털 응용 프로그램을 보호하기 위해 세 개의 정책을 활성화했으며 그중 두 개는 사용자 특성을 반환하는 응답에 바인딩되어 있습니다.
정책 A는 실행될 때 하나의 사용자 특성을 반환합니다.
  • 정책 B는 실행될 때 두 개의 사용자 특성을 반환합니다.
  • 정책 C는 사용자 특성을 반환하는 응답에 바인딩되어 있지 않습니다.
회사는 다음 공식을 사용하여 정책 서버가 사용자 특성을 반환하는 응답을 확인하기 위해 수행하는 사용자 디렉터리 요청의 수를 추정합니다.
authorization_load
*
percent_of_policies
*
number_of_responses
=
daily_authorization_requests
  • authorization_load
    응용 프로그램에 대한 일별 권한 부여 수를 지정합니다.
  • percent_of_policies
    사용자 특성을 반환하는 응답 때문에 동일한 수의 사용자 디렉터리 요청을 생성하는 활성화된 정책의 수(백분율로 표현)를 지정합니다.
    참고:
    총 백분율은 100%여야 합니다.
  • number_of_responses
    정책에 바인딩된 응답의 수를 지정합니다.
  • daily_authorization_requests
    권한 부여 요청을 처리하기 위한 사용자 디렉터리 요청의 수를 지정합니다.
결과:
  • 정책 A - 792,000 * 0.2 x 1= 158,000
  • 정책 B - 792,000 * 0.2 x 2= 316,800
  • 정책 C - 792,000 * 0.6 x 0= 0
  • 총 사용자 디렉터리 요청 - 158,000 + 316,800 + 0= 526,000
회사는 이 추정을 사용하여 일별 권한 부여 부하를 처리하기 위해 필요한 총 사용자 디렉터리 요청 수를 결정합니다.
사례 3: 권한 부여에 대한 총 디렉터리 요청 수
회사에서는 각 사용 사례의 개별적인 총계를 사용하여 정책 서버가 권한 부여 부하를 처리하기 위해 사용자 디렉터리에 전송하는 총 요청 수를 확인합니다.
  • 정책 구성원 자격을 확인하기 위한 1,203,440회의 요청
  • 응답과 연결된 사용자 특성을 반환하기 위한 526,000회의 요청
결과:
1,203,440 + 526,000= 1,729,440회의 요청
회사는 이 결과와 인증에 기반한 결과를 사용하여 사용자 저장소가 정책 서버 요청을 처리해야 하는 지속적 비율을 추정합니다.
지속적 사용자 디렉터리 검색 비율 추정
지속적 사용자 디렉터리 검색 비율은 총 작업 수(인증 부하 더하기 권한 부여 부하), 즉 이러한 요청이 발생하는 시기와 비율을 기반으로 합니다. 이러한 요청이 업무일 동안 균등하게 분산될 가능성은 거의 없습니다. 대신 이러한 요청이 발생하는 비율은 지속 기간 중 가장 낮은 수준과 가장 높은(최고) 수준 내에서 크게 변동합니다.
지속적 사용자 디렉터리 검색 비율을 추정하려면 다음을 확인해야 합니다.
  • 시스템이 평균적인 수의 작업을 처리하는 지속 기간
  • 이러한 요청이 사용자 디렉터리 검색으로 변환되는 방식
지속적 사용자 디렉터리 검색 비율을 추정할 때는 일일 인증 부하 및 권한 부여를 사용하여 다음을 식별하는 것이 좋습니다.
  • 하루 중 총 작업이 수행되는 비율
    참고:
    1시간 단위로 분할된 24시간의 평가 기간부터 시작하는 것이 좋습니다. 하지만 엔터프라이즈의 요구 사항에 따라 하루 동안의 결과를 몇 주 또는 몇 개월 동안 비교하면 연중 사용 처리량을 더 정확하게 파악할 수 있습니다.
  • 시스템이 평균적인 수의 요청을 처리하는 지속 기간
  • 지속 기간 동안 발생하는 대략적인 요청 수
사례: 지속적 사용자 디렉터리 검색 비율 추정
회사에서 다음을 확인했습니다.
  • 응용 프로그램에 대한 일별 인증 부하 및 권한 부여 부하로 인해 약 888,000개의 총 작업이 발생합니다.
  • 총 작업은 약 2,051,520개의 사용자 디렉터리 요청으로 이어집니다.
  • 시스템은 약 5시간(오전 9시 - 오후 2시) 동안 지속 수준에서 작동합니다.
  • 지속 수준 중 시간당 약 84,000개의 작업이 발생합니다.
  • 이 시간 동안 약 420,000(84,000 * 5)개의 작업 또는 총 작업의 48%(420,000 / 880,000)가 수행됩니다.
회사는 다음 공식을 사용하여 지속적 사용자 저장소 검색 비율을 추정합니다.
(
total_user_directory_requests
 * 
percentage_of_requests
) / 
number_of_hours
 / 3600 = 
sustained_user_directory_search_rate
  • total_user_directory_requests
    정책 서버가 인증 및 권한 부여 요청을 처리하기 위해 사용자 디렉터리에 수행하는 일별 요청 수를 나타냅니다.
  • percentage_of_requests
    시스템이 지속 수준에서 작동할 때 발생하는 총 작업의 백분율을 나타냅니다.
  • number_of_hours
    시스템이 지속적 비율로 작동하는 시간을 나타냅니다.
  • sustained_user_directory_search_rate
    정책 서버가 지속적 작업 비율을 유지하기 위해 사용자 디렉터리에 수행하는 초당 요청 수를 나타냅니다.
결과:
(2,051,520 * 0.48) / 5 /3600 = 초당 54.7개의 사용자 디렉터리 요청 수
정책 서버는 지속적 작동 수준 도중 인증 및 권한 부여 요청을 처리하기 위해 사용자 디렉터리에 대해 초당 54.7회의 요청을 생성합니다.
최고 사용자 디렉터리 검색 비율 추정
최고 사용자 디렉터리 검색 비율은 총 작업 수(인증 부하 더하기 권한 부여 부하), 즉 시스템이 최고 수준에서 작동하는 시기와 비율을 기반으로 합니다. 최고 사용자 디렉터리 검색 비율을 추정할 때는 시스템이 최고 수준의 작업을 처리하는 시기와 이러한 요청이 사용자 디렉터리 검색으로 이어지는 방식을 식별해야 합니다.
최고 권한 부여 비율을 추정할 때는 지속 권한 부여 비율을 확인할 때 수집한 메트릭을 사용하여 다음을 파악하는 것이 좋습니다.
  • 시스템이 가장 높은 수의 작업을 처리하는 시간
  • 이 기간 중 발생하는 대략적인 작업의 수
사례: 최고 사용자 디렉터리 검색 비율 추정
회사에서는 응용 프로그램의 일별 총 작업 수가 888,000개인 것으로 확인했습니다. 이 작업은 약 2,051,520개의 사용자 디렉터리 검색으로 이어집니다. 용량 계획 수립 중 수집된 메트릭을 사용하여 회사는 업무 시간 1시간 동안 약 278,000개의 작업 또는 총 작업의 31%가 수행되는 것으로 확인했습니다.
회사는 다음 공식을 사용하여 최고 사용자 저장소 검색 비율을 추정합니다.
(
total_user_directory_requests
 * 
percentage_of_requests
) / 
number_of_hours
 / 3600 = 
peak_authentication_request_rate
  • total_authentication_requests
    정책 서버가 사용자 저장소로 보내는 총 요청 수를 나타냅니다.
  • percentage_of_requests
    시스템이 최고 수준에서 작동할 때 발생하는 작업의 백분율을 나타냅니다.
  • number_of_hours
    시스템이 최고 수준에서 작동하는 시간을 나타냅니다.
  • peak_user_directory_request_rate
    정책 서버가 최고 인증 비율을 유지하기 위해 사용자 저장소에 수행하는 초당 요청 수를 나타냅니다.
결과:
(2,051,520 * 0.31) / 1 / 3600 = 초당 176.6회의 요청
정책 서버는 최고 작업 수준에서 인증 및 권한 부여 요청을 처리하기 위해 사용자 디렉터리에 대해 초당 176.6회의 요청을 생성합니다.