성능 및 용량 계획(FAST Search Server 2010 for SharePoint)

아티클
01/25/2017

적용 대상: FAST Search Server 2010

마지막으로 수정된 항목: 2015-03-09

Microsoft FAST Search Server 2010 for SharePoint 배포의 성능 및 용량을 계획할 때는 비즈니스 환경과 시스템 아키텍처 모두에 대한 여러 측면들을 고려해야 합니다.

비즈니스 환경 고려 사항
시스템 아키텍처 고려 사항

일반적으로 Microsoft SharePoint Server 2010 팜의 성능 및 용량을 계획하는 방법에 대한 자세한 내용은 SharePoint Server 2010의 용량 관리을 참조하십시오.

참고

이 문서에서는 SharePoint Server 2010 크롤러, 인덱싱 커넥터 프레임워크 및 FAST Search Server 2010 for SharePoint Content SSA(Content Search Service 응용 프로그램)를 사용하여 콘텐츠를 크롤링하는 것으로 간주합니다.

비즈니스 환경 고려 사항

환경 내에서 다음과 같은 항목을 정의합니다.

콘텐츠 볼륨 용량	검색할 수 있어야 하는 콘텐츠는 얼마나 됩니까? 총 항목 수에는 문서, 웹 페이지, 목록 항목 등 모든 개체가 포함되어야 합니다.
가용성	가용성 요구 사항은 무엇입니까? 특정 서버에 장애가 발생해도 고객에게 검색 솔루션을 계속 제공할 수 있어야 합니까? 가용성에는 쿼리 일치에 대한 가용성과 인덱싱에 대한 가용성의 두 가지 중요 가용성 수준이 있습니다.
콘텐츠 최신 상태	검색 결과는 얼마나 "최신 상태"로 제공되어야 합니까? 고객이 데이터를 수정한 후 얼마나 지나서야 업데이트된 콘텐츠를 검색 결과에 제공해야 합니까? 콘텐츠는 얼마나 자주 변경됩니까?
쿼리 계산 용량	콘텐츠를 동시에 검색하는 사용자 수는 얼마나 됩니까? 여기에는 쿼리 상자에 입력하는 사용자의 쿼리와 데이터를 자동으로 검색하는 웹 파트와 같은 기타 숨겨진 쿼리 또는 검색 시스템에서 보안 조정이 필요한 URL이 포함된 Microsoft Outlook 2010 Social Connector의 요청 활동 크롤링이 포함됩니다.

시스템 아키텍처 고려 사항

시스템 아키텍처의 관점에서는 인덱싱 및 쿼리 계산 프로세스는 물론 다양한 토폴로지 선택과 이로 인해 발생하는 네트워크 트래픽의 효과를 이해하고 있어야 합니다. 또한 웹 분석기 구성 요소의 크기를 조정하는 데에도 주의해야 합니다. 이 구성 요소의 성능은 인덱싱된 항목 수 및 항목에 하이퍼링크가 포함되는지 여부에 따라 달라집니다.

성능 및 용량에 인덱싱이 미치는 영향
성능 및 용량에 쿼리 계산이 미치는 영향
성능 및 용량에 토폴로지가 미치는 영향
성능 및 용량에 네트워크 트래픽이 미치는 영향
성능 및 용량에 웹 링크 분석이 미치는 영향

성능 및 용량에 인덱싱이 미치는 영향

FAST Search Server 2010 for SharePoint 팜은 콘텐츠를 크롤링할 때 인덱스 가져오기, 인덱스 유지 관리 및 인덱스 정리와 같은 여러 단계를 거칩니다.

인덱스 가져오기

인덱스 가져오기 단계의 특징은 전체(동시 가능) 크롤링입니다.

새 콘텐츠를 추가할 때 크롤링 성능은 주로 구성된 항목 처리 구성 요소 수에 따라 결정됩니다. 각 구성 요소의 CPU 코어 수와 처리 속도는 모두 결과에 영향을 줍니다. 대략적으로 1GHz CPU 코어는 초당 하나의 평균 크기(약 250kB) Office 문서를 처리할 수 있습니다. 예를 들어 항목 처리를 위해 각각 2.26GHz의 CPU 코어가 48개 있다고 가정하면 예상되는 초당 총 처리량은 평균적으로 48 × 2.26 ≈ 100개 항목이 됩니다.

인덱스 유지 관리

인덱스 유지 관리 단계의 특징은 새로운 콘텐츠 및 변경된 콘텐츠를 검색하여 모든 콘텐츠에 대해 증분 크롤링을 수행하는 것입니다. 일반적으로 SharePoint Server 2010 콘텐츠 원본을 크롤링할 경우 발견된 변경 사항의 대부분은 액세스 권한과 관련된 것입니다.

증분 크롤링은 여러 작업으로 구성될 수 있습니다.

ACL(액세스 권한) 변경 및 삭제: 이 작업을 수행하기 위해서는 거의 0에 가까운 항목 처리가 필요하지만 인덱서의 처리 부하가 높아집니다. 크롤링 속도는 전체 크롤링 속도보다 빠릅니다.
콘텐츠 업데이트: 이 작업을 수행하기 위해서는 전체 항목 처리를 수행해야 하며 새 콘텐츠를 추가할 때와 비교하여 인덱서의 처리 능력이 더 많이 요구됩니다. 내부적으로 이러한 업데이트는 오래된 항목의 삭제 및 새 콘텐츠 추가에 따른 작업입니다.
추가: 증분 크롤링에는 새로 검색된 항목이 포함될 수도 있습니다. 이러한 작업의 작업 부하는 인덱스 가져오기 크롤링과 동일합니다.

작업 종류에 따라 증분 크롤링이 초기 전체 크롤링보다 빠르거나 느릴 수도 있습니다. 주로 ACL 업데이트와 삭제만 있을 경우 속도가 빠르고 주로 업데이트된 항목인 경우에는 속도가 느립니다.

콘텐츠 원본에서의 업데이트 외에도 링크 분석, 클릭 방문 로그 분석 및 인덱스 파티션 재구성과 같은 내부 작업으로 인해서도 인덱스가 변경됩니다. FAST Search Server 2010 for SharePoint 링크 분석과 클릭 방문 로그 분석은 인덱스에 대한 내부 업데이트를 추가로 발생시킵니다. 예를 들어 한 항목의 하이퍼링크로 인해 참조된 항목과 관련된 고정 텍스트 정보가 업데이트될 수 있습니다. 이러한 업데이트는 ACL 업데이트와 비슷한 부하 패턴을 지닙니다. 인덱서는 인덱스 파티션에 대한 내부 재구성 및 데이터 조각 모음을 수행합니다. 인덱서는 매일 새벽 3시에 조각 모음을 시작하고 필요에 따라 파티션 간의 재배포를 수행합니다. 이러한 내부 작업은 모두 지속적인 콘텐츠 크롤링 작업에서 인덱싱 활동이 간격을 벗어나게 만들 수 있습니다.

인덱스 정리

인덱스 정리 단계는 콘텐츠 원본 또는 시작 주소를 Search Service 응용 프로그램에서 삭제할 때 발생합니다. 이 단계는 또한 콘텐츠 인덱싱 커넥터가 콘텐츠를 제공하는 호스트를 찾을 수 없는 경우에도 발생합니다. 인덱싱 커넥터는 세 번의 연속된 크롤링 중에 호스트를 검색하지만 호스트를 찾을 수 없으면 콘텐츠 원본을 삭제하여 인덱스를 정리 단계로 전환합니다.

성능 및 용량에 쿼리 계산이 미치는 영향

일반적으로 인덱스에는 인덱스 열과 인덱스 파티션이라는 두 가지 구분된 수준이 포함됩니다.

전체 인덱스가 너무 커서 하나의 서버에 상주할 수 없는 경우 인덱스를 여러 개의 중첩된 인덱스 열로 분할할 수 있습니다. 그런 다음 쿼리 일치 구성 요소는 검색 클러스터 내에서 모든 인덱스 열에 대해 쿼리를 평가하고 각 인덱스 열의 결과를 최종 쿼리 적중 횟수 목록에 병합합니다. 각 인덱스 열 내에서 인덱서는 낮은 인덱싱 및 쿼리 대기 시간으로 다수의 인덱싱된 항목을 처리할 수 있도록 인덱스 분할을 사용합니다. 이 분할 작업은 동적으로 이루어지며 각 인덱서 서버에서 내부적으로 처리됩니다. 쿼리 일치 구성 요소가 쿼리를 평가할 때 각 파티션은 별개의 스레드로 실행됩니다. 기본 파티션 수는 5개입니다. 서버(열)당 1500만개 이상의 항목을 처리할 수 있도록 하려면 더 많은 수의 파티션을 구성해야 합니다.

다음 그림에서는 단일 쿼리에 대한 계산을 체계적인 방식으로 보여 줍니다.

단일 쿼리 그림

CPU 처리(연한 파란색) 다음에는 디스크 액세스 주기에 대한 대기(흰색) 및 실제 디스크 데이터 읽기 전송(진한 파란색)이 수행됩니다. 이러한 단계는 쿼리당 2~10회 반복해서 수행됩니다. 즉, 쿼리 대기 시간은 CPU 속도는 물론 저장소 하위 시스템의 I/O 대기 시간에 따라 달라집니다. 쿼리 일치 구성 요소는 각 단일 쿼리를 개별적으로 계산하고 모든 인덱스 열에 있는 여러 인덱스 파티션에서 병렬로 수행합니다. 기본 5개 파티션 구성에서는 각 쿼리가 모든 열 내에서 5개의 개별 스레드로 계산됩니다.

쿼리 부하가 증가하면 쿼리 일치 구성 요소가 다음 그림에 표시된 것처럼 여러 쿼리를 병렬로 계산합니다.

다중 쿼리 그림

쿼리 계산의 여러 단계가 각기 다른 시간에 수행되므로 동시 I/O 액세스는 병목 지점이 될 가능성이 낮습니다. CPU 처리에서는 서버의 가용 CPU 코어에서 예약되는 것과 상당히 일치하는 부분을 보여 줍니다. 모든 테스트된 시나리오에서 쿼리 처리량은 모든 가용 CPU 코어가 100% 사용될 때 최대치에 도달합니다. 이러한 상황은 저장소 하위 시스템이 포화되기 전에 발생합니다. 속도가 빠른 CPU 코어를 더 많이 추가할수록 쿼리 처리량이 증가하므로 결국은 디스크 액세스가 병목 지점이 됩니다. 테스트된 시나리오에 대한 자세한 내용은 FAST Search Server 2010 for SharePoint 용량 계획(영문일 수 있음) 백서를 참조하십시오.

참고

인덱스 열이 많은 대규모 배포에서는 쿼리 처리 및 쿼리 일치 구성 요소 간의 네트워크 트래픽도 병목 지점이 될 수 있으며 이 경우 이 인터페이스에 대한 네트워크 대역폭을 늘리도록 고려할 수 있습니다.

쿼리 대기 시간은 최대 처리량에서 CPU가 고갈되는 지점까지는 쿼리 부하와 다소 독립적입니다. 각 쿼리의 대기 시간은 가장 큰 인덱스 파티션에 있는 항목 수의 영향을 받습니다. 유휴 기간 후 쿼리 부하를 적용하면 캐싱 효과로 인해 쿼리 대기 시간이 약간 늘어납니다. 지속적인 크롤링은 쿼리 대기 시간을 약간 늘어나게 만듭니다. 하지만 백업 인덱서가 설정된 검색 행이 있는 경우 인덱서 및 항목 처리와 동일한 서버에서 검색을 수행하는 시스템에서보다 효과가 적게 적용됩니다.

성능 및 용량에 토폴로지가 미치는 영향

인덱싱과 쿼리 일치는 모두 CPU 리소스를 사용하므로, 동일 행에서 인덱싱 및 쿼리 일치가 포함된 배포는 콘텐츠 크롤링 중에 쿼리 성능을 약간 저하시킬 수 있습니다. 단일 행 배포에서는 일반적으로 인덱싱, 쿼리 일치 및 항목 처리가 모두 동일한 서버에서 실행됩니다.

쿼리 트래픽을 인덱싱 및 항목 처리로부터 격리시키려면 전용 검색 행을 배포할 수 있습니다. 이렇게 하려면 검색 클러스터에 두 배의 서버 숫자가 필요하며, 보다 일관적이고 더 나은 쿼리 성능을 제공합니다. 이러한 구성은 또한 쿼리 처리 및 쿼리 일치를 위한 중복성도 제공합니다. 전용 검색 행은 인덱서가 새 인덱스 생성(제공된 파티션에 대한 새로운 버전의 인덱스)을 만들 때 크롤링 및 인덱싱 중에 추가 트래픽을 유발합니다. 인덱서 구성 요소는 네트워크를 통해 새 인덱스 데이터를 쿼리 일치 구성 요소에 전달합니다. 적합한 저장소 하위 시스템을 사용할 경우에는 캐시 무효화로 인해 새로운 생성이 도착할 때에도 쿼리 성능에 대한 영향이 적습니다.

또한 기본 인덱서에서 복구할 수 없는 오류를 처리할 수 있도록 백업 인덱서를 배포할 수 있습니다. 일반적으로 백업 인덱서는 검색 행과 함께 둡니다. 이 시나리오에서는 조합된 백업 인덱서 및 검색 행에 항목 처리를 배포하지 않아야 합니다. 백업 인덱서는 두 서버에서 인덱스 데이터를 동기화된 상태로 유지하기 위해 기본 인덱서와 백업 인덱서 간에 추가적인 내부 관리 통신이 수행되기 때문에 검색 행에서 I/O 부하를 늘립니다. 여기에는 또한 두 서버 모두의 디스크에 대한 추가 데이터 저장소도 포함됩니다. 추가 부하를 처리할 수 있도록 저장소 하위 시스템의 크기를 조정해야 합니다.

성능 및 용량에 네트워크 트래픽이 미치는 영향

개별 서버의 CPU 성능이 향상되면 서버 간 네트워크 연결이 병목 지점이 될 수 있습니다. 한 가지 예로, 서버가 4개인 소규모 FAST Search Server 2010 for SharePoint 팜에서도 초당 100개 이상의 항목을 처리하고 인덱싱할 수 있습니다. 평균 항목이 250Kbytes이 경우 평균 250Mbit/s의 네트워크 트래픽이 발생합니다. 이러한 부하는 1Gbit/s 네트워크 연결이라도 포화 상태로 만들 수 있습니다.

콘텐츠 크롤링 및 인덱싱으로 인해 발생하는 네트워크 트래픽은 다음과 같이 해제할 수 있습니다.

Content SSA 내의 인덱싱 커넥터가 원본에서 콘텐츠를 검색합니다.
SharePoint Server 2010 팜 내의 Content SSA는 배치에서 검색된 항목을 FAST Search Server 2010 for SharePoint 팜에 있는 콘텐츠 배포자 구성 요소로 전달합니다.
콘텐츠 배포자는 각 항목 배치를 일반적으로 다른 서버에 있는 사용 가능한 항목 처리 구성 요소로 전송합니다.
처리 후에는 항목 처리 구성 요소가 각 배치를 인덱스 열 배포에 따라 분할하는 인덱싱 발송자로 전달합니다.
인덱싱 발송자는 처리된 항목을 각 인덱스 열의 인덱서에 배포합니다.
검색 행이 여러 개인 경우 인덱서는 이진 인덱스를 추가 검색 행으로 복사합니다.

모든 서버 및 구성 요소에서 누적된 네트워크 트래픽은 분산 시스템에서 콘텐츠 스트림 자체의 트래픽보다 5배 이상 높을 수 있습니다. 이러한 배포에서 서버를 상호 연결하려면 고성능 네트워크 스위치가 있어야 합니다.

높은 쿼리 처리량은 또한 여러 인덱스 열을 사용하는 경우 특히 높은 네트워크 트래픽을 발생시킵니다. 쿼리로 인한 네트워크 트래픽과 콘텐츠 크롤링 및 인덱싱으로 인한 네트워크 트래픽이 너무 많이 겹치지 않도록 배포 구성과 네트워크 구성을 정의해야 합니다.

성능 및 용량에 웹 링크 분석이 미치는 영향

웹 분석기 구성 요소의 성능 조정은 인덱싱된 항목 수 및 항목에 하이퍼링크가 포함되는지 여부에 따라 달라집니다. 하이퍼링크를 포함하는 항목이나 다른 대상으로 연결되는 항목은 부하가 높습니다. 데이터베이스 유형의 콘텐츠는 일반적으로 하이퍼링크를 포함하지 않습니다. 인터넷 콘텐츠(SharePoint 사이트 콘텐츠 포함)는 하이퍼링크가 있는 HTML을 포함하는 경우가 많습니다. 외부 웹 콘텐츠는 하이퍼링크가 많이 포함된 HTML 문서인 경우가 거의 대부분입니다.

웹 분석기 구성 요소의 성능 조정에서는 CPU 코어 수가 중요한 요소이지만 고정 텍스트 및 순위 데이터를 사용하여 인덱스를 업데이트해야 하는 시간이 가장 중요합니다. 웹 분석기 구성 요소는 충분한 디스크 공간을 사용할 수 있는 경우 링크, 고정 텍스트 또는 클릭 방문 로그 분석만 수행합니다. 다음 표에서는 웹 분석기 구성 요소에 가장 중요한 크기 조정 권장 사항을 보여 줍니다.

콘텐츠 유형	CPU 코어당 항목 수	100만 항목당 GB 디스크
데이터베이스	2000만	2
SharePoint Server 2010 /인트라넷	1000만	6
공개 웹 콘텐츠	500만	25

참고

표에서는 전체 팜에 대한 크기 조정 규칙을 제공합니다. 웹 분석기 구성 요소를 두 서버로 배포하면 서버당 요구 사항이 제공된 값의 절반이 됩니다.

사용할 수 있어야 하는 메모리 양은 모든 종류의 콘텐츠에 대해 동일하지만 사용하는 코어 수에 따라 달라집니다. 100만개 항목당 30MBytes를 사용하고 이에 더해 CPU 코어당 300MBytes를 사용하는 것이 좋습니다. 설치에 다른 종류의 콘텐츠가 포함된 경우 최상의 용량 계획 전략은 수요가 가장 많은 콘텐츠 유형을 크기 조정이 기본 콘텐츠로 사용하는 것입니다. 예를 들어 시스템에 데이터베이스 및 SharePoint 사이트 콘텐츠가 혼합되어 있는 경우 SharePoint 사이트 콘텐츠만 포함된 것처럼 시스템 크기를 조정하는 것이 좋습니다.