SharePoint에서 특정 성능 요구 사항에 대한 엔터프라이즈 검색 토폴로지 다시 디자인
적용 대상:
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
SharePoint Server 2016의 엔터프라이즈 검색 아키텍처 계획 의 지침을 수행했을 때 충족되지 않은 특정 성능 요구가 검색 환경에 있는 경우 해결 방법은 엔터프라이즈 검색 아키텍처의 토폴로지를 확장하는 것입니다.
토폴로지 다시 디자인(이 문서)
다시 디자인한 토폴로지 구현(SharePoint Server에서 검색 토폴로지 관리)
SharePoint Server 2016에서 검색 시스템의 구성 요소와 상호 작용하는 방법에 대해 잘 알고 있나요? 시작하기 전에 SharePoint Server의 검색 아키텍처 개요 및 SharePoint Server 2016에 대한 검색 아키텍처 (또는 SharePoint Server 2013의 검색 아키텍처)를 읽으면 검색 아키텍처, 검색 구성 요소, 검색 데이터베이스 및 검색 토폴로지를 숙지할 수 있습니다.
이 문서에서는 특정 성능 요구에 맞게 검색 토폴로지를 다시 디자인하는 단계별 방법을 보여 줍니다.
아래 단계를 따르면 다음 사실을 알게 됩니다.
토폴로지에 필요한 각 검색 구성 요소 및 검색 데이터베이스 유형의 수
각 검색 구성 요소를 배포할 응용 프로그램 서버 및 데이터베이스 서버
각 응용 프로그램 서버 및 데이터베이스 서버에 필요한 하드웨어 리소스
1단계: 특정 성능 요구 사항 확인
특정 성능 요구와 관련이 있는 비즈니스 요구를 이해해야 합니다. 예를 들어 뉴스 및 금융 검색의 경우 거의 실시간으로 인덱싱되는 최신 데이터가 필요하지만 소송 지원 서비스는 한 번 인덱싱된 일괄 데이터를 수집하면 됩니다. 다음 방법 중 하나 이상으로 성능 요구 사항을 나타내세요.
인덱싱된 항목 수
검색 솔루션이 초당 크롤링해야 하는 항목 수 및 적용할 대기 시간
검색 솔루션이 초당 제공해야 하는 쿼리 수 및 적용할 대기 시간
이러한 성능 요구 사항 외에도, 작업 환경은 쿼리 결과가 적합하고 검색 토폴로지의 중복성이 충족되어야 합니다. 경우에 따라 특정 성능 요구 사항이 없지만 성능에 영향을 줄 수 있는 검색 아키텍처에서 병목 상태를 식별했습니다. 우리는 너무 그것을 다룰 것입니다.
2단계: 확장해야 하는 검색 구성 요소 확인
더 높은 성능을 전달하거나 병목 현상을 없애려면 작업을 수행할 더 많은 검색 구성 요소를 추가하거나 검색 구성 요소를 호스팅하는 서버에 더 많은 리소스를 추가할 수 있습니다. 더 많은 검색 구성 요소를 추가하는 것을 수평 확장이라고 하고 서버에 더 많은 리소스를 추가하는 것을 수직 확장이라고 합니다. 수평 확장할 검색 구성 요소나 수평 확장할 서버는 향상시킬 성능 메트릭이나 제거할 병목 현상에 따라 다릅니다. 아래에 몇 가지 예가 나와 있습니다.
환경에 더 높은 쿼리 속도가 필요하거나 인덱싱을 위한 CPU 리소스가 병목 상태인 경우 인덱스의 각 파티션에 다른 인덱스 복제본을 추가합니다. 이렇게 하면 더 많은 검색 쿼리가 동시에 처리될 수 있습니다.
크롤링된 콘텐츠를 처리하기 위한 CPU 리소스가 병목 상태인 경우 콘텐츠 처리 구성 요소의 수를 수평 확장합니다. 더 많은 CPU나 더 빠른 CPU가 있는 서버에서 실행하여 콘텐츠 처리 구성 요소를 수직 확장할 수도 있습니다. 두 확장 방법 모두 콘텐츠 처리를 위한 CPU 리소스가 늘어나는 것을 의미합니다.
분석 구성 요소가 분석을 충분히 빠르게 완료하지 못한 경우 분석 구성 요소를 호스팅하는 서버의 프로세서 리소스, 디스크 IOPS 또는 네트워크 대역폭을 수직 확장합니다.
검색 구성 요소 또는 데이터베이스 수의 무제한 스케일 아웃은 지원되지 않습니다. 검색 구성 요소와 데이터베이스 사이에서 시기 적절하고 강력한 통신을 유지하기 위해 검색 제한에서 최대 제한을 확인하고 이러한 제한을 벗어나지 않도록 합니다. 필요한 경우 검색 구성 요소 수를 줄여 검색 아키텍처의 용량을 줄입니다.
다음 섹션에서는 각 요구 사항을 충족하기 위해 확장할 검색 구성 요소나 데이터베이스에 대한 지침을 제공합니다.
인덱스의 더 많은 항목을 처리하는 방법
인덱싱된 항목이 이전과 같은 속도로 변경되는 동안 인덱싱된 항목의 양이 증가하면 이러한 검색 구성 요소 및 데이터베이스를 수평 확장하여 검색 토폴로지의 용량을 늘리세요.
| 검색 구성 요소 또는 데이터베이스 | 지침 |
|---|---|
| 인덱스 구성 요소 | 인덱싱된 항목 2천만1 개마다 인덱스 파티션 하나를 사용합니다. 각 파티션에는 하나 이상의 파티션 복제본이 들어 있습니다. 모든 파티션에는 동일한 수의 복제본이 있어야 합니다. 하나의 인덱스 구성 요소는 단일 인덱스 복제본을 나타냅니다. 따라서 인덱스의 두 복제본을 원하는 경우 인덱스 파티션보다 두 배 많은 인덱스 구성 요소가 필요합니다. 예를 들어 항목이8천만 개 인 중복 인덱스에는 4개의 파티션이 필요합니다. 각 파티션에 대해 복제본 2개를 사용할 경우 8개의 인덱스 구성 요소는 4개의 파티션을 나타냅니다. |
| 크롤링 데이터베이스 | 콘텐츠 모음에 있는 2천만 개 항목 전체에 대해 하나의 크롤링 데이터베이스를 사용합니다. 예를 들어 항목이 1억 개 있는 인덱스에는 크롤링 데이터베이스가 5개 필요합니다. 인덱싱된 항목 수를 늘렸을 때 크롤링 속도가 더 커지면 크롤링 데이터베이스에 사용될 IOPS 리소스도 더 많이 필요합니다. 크롤링 속도가 초당 문서 1개에 해당할 경우 크롤링 데이터베이스에는 약 10 IOPS가 필요합니다. |
| 링크 데이터베이스 | 콘텐츠 모음에 있는 6천만 개 항목 전체에 대해 하나의 링크 데이터베이스를 사용합니다. 예를 들어 항목이 1억 개 있는 인덱스에는 링크 데이터베이스가 2개 필요합니다. 콘텐츠를 추가했을 때 크롤링 속도가 더 커지면 링크 데이터베이스에 사용될 IOPS 리소스가 더 많이 필요할 수 있습니다. |
| 분석 보고 데이터베이스 | 필요한 분석 보고 데이터베이스 수는 검색 환경이 분석을 사용하는 방식과 빈도에 따라 달라집니다. 일반적으로 분석 성능이 감소하기 시작할 때 분석 보고 데이터베이스를 추가합니다. 예를 들어 야간 데이터베이스 업데이트에 더 많은 시간이 소요되기 시작할 때가 여기에 해당됩니다. 데이터베이스가 250GB 크기 또는 2천만 개의 총 행 수에 도달하거나 일별 보기 수가 500,000개의 고유 항목에 도달할 경우 이러한 상황이 발생할 수 있습니다. |
SharePointServer 2013 또는 SharePoint Server 2016에서 500GB 스토리지, 32GB RAM 및 8개의 CPU 코어보다 적은 리소스로 실행되는 1,000만 개의 항목
SharePointServer 2013 또는 SharePoint Server 2016에서 500GB 스토리지, 32GB RAM 및 8개의 CPU 코어보다 적은 리소스로 실행되는 4천만 개의 항목
결과의 수집 속도 및 최신성을 높이는 방법
수집 속도를 늘려야 하는 상황이 있을 수 있습니다. 한 가지 예로, 작업 환경이 좀 더 최신 결과를 요구하고 콘텐츠 볼륨이 검색 아키텍처의 상한에 가까워지거나 콘텐츠가 자주 변경되는 경우를 들 수 있습니다. 사람들이 팀 사이트의 파일을 보관하는 데 사용한 경우 콘텐츠가 자주 변경될 수 있지만 이제는 작업하는 동안 OneDrive에 파일을 저장합니다. 검색은 사용자들이 파일에 대해 수행한 모든 변경 내용을 인덱싱합니다.
검색이 항목을 수집하는 속도에 영향을 미치는 다음과 같은 요인을 이해하는 것이 도움이 됩니다.
검색이 항목을 크롤링할 수 있는 속도. 이 속도는 다음에 따라 좌우됩니다.
크롤링 구성 요소와 콘텐츠 원본 간 연결의 속도
크롤링할 항목의 유형 및 평균 크기
크롤링 데이터베이스를 호스팅하는 SQL Server의 성능
크롤링 구성 요소가 갖는 CPU 및 메모리 리소스의 양
인덱싱 전에 각 항목에 필요한 콘텐츠 처리 양
인덱스가 갖는 파티션 수. 파티션이 많으면 인덱싱 부하가 분산될 수 있습니다.
수행할 작업은 다음과 같습니다.
크롤링된 항목의 연령 분포를 확인하여 팜에서 결과의 새로 고침을 확인합니다. SharePoint 중앙 관리 웹 사이트에서 크롤링 상태 보고서 로 이동하고 새로 고침 크롤링을 선택합니다. 팜에 허용되는 연령 분포는 비즈니스 요구 사항에 따라 달라집니다. 예를 들어 크롤링 새로 고침 페이지에 콘텐츠의 90%를 인덱싱하는 데 4시간이 걸리지만 요구 사항이 30분인 경우 수집 속도를 높입니다.
크롤링 최신성 페이지에서 하루 중에서 결과가 충분히 최신 상태가 아닌 기간을 식별합니다.
지침에 따라 이러한 기간의 수집 속도를 늘립니다.
| 지침 |
|---|
| 특정 콘텐츠 원본의 최신성 향상 |
| 크롤링을 위한 처리 리소스 늘리기 |
| 크롤링 데이터베이스를 위한 처리 리소스 늘리기 |
| 콘텐츠 처리를 위한 처리 및 메모리 리소스 늘리기 |
| 인덱스 파티션 수 늘리기 |
특정 콘텐츠 원본의 최신성 향상
크롤링 일정을 확인하고 검색 기능이 최신성이 부족한 기간에 크롤링하는 콘텐츠 원본을 파악합니다. 특정 콘텐츠 원본에 대한 최신성이 낮으면 다음을 고려합니다.
크롤링 구성 요소를 호스트하는 서버와 해당 콘텐츠 원본 간의 연결 속도를 높입니다. 크롤링 속도이며, 콘텐츠 원본에서 항목을 다운로드하고, 크롤링 구성 요소에 대한 네트워크 대역폭의 필요성을 유도하는 콘텐츠 처리 구성 요소에 항목을 전달합니다.
콘텐츠 원본이 SharePoint이면 팜에는 더 많은 전용 크롤링 대상이 필요할 수 있습니다. 크롤링 부하 관리(SharePoint 2010)에서 크롤링 대상에 대해 읽어보세요.
콘텐츠 데이터베이스의 성능을 향상시킵니다. SharePoint Server 팜의 SQL Server 모범 사례에서 방법을 알아봅니다.
크롤링을 위한 처리 리소스 늘리기
크롤링 구성 요소가 프로세서 리소스의 100%를 사용하는 경우가 잦으면 크롤링 구성 요소를 호스팅하는 서버에 크롤링 구성 요소나 프로세서 리소스를 더 추가하는 것을 고려합니다. 이는 크롤링 속도, 링크 검색 및 프로세서 리소스의 필요성을 유도하는 크롤링 관리입니다. 일반적으로 크롤링은 Microsoft에서 예상한 중소형 샘플 검색 아키텍처와 같은 검색 아키텍처에서 두 개의 크롤링 구성 요소를 사용할 때 충분히 빠릅니다. 대형 및 초대형 샘플과 같은 검색 아키텍처에는 3개 이상의 크롤링 구성 요소가 필요할 수 있습니다.
크롤링 데이터베이스를 위한 처리 리소스 늘리기
크롤링 데이터베이스를 호스트하는 SQL 서버에 충분한 리소스가 있는지 확인합니다. SharePoint Server 팜의 SQL Server 모범 사례에서 이 작업을 수행하는 방법을 읽어보세요.
모든 크롤링 데이터베이스가 많은 프로세서 리소스를 사용하는 경우 데이터베이스를 호스팅하는 SQL 서버에 프로세서 리소스를 더 추가하는 것을 고려하거나 기존 SQL 서버와 같은 수의 크롤링 데이터베이스가 있는 다른 SQL 서버를 추가하도록 합니다. 예를 들어 각각에 3개의 크롤링 데이터베이스가 있는 두 대의 SQL 서버가 있는 경우 3개의 크롤링 데이터베이스가 있는 다른 SQL 서버를 추가합니다.
하나 또는 소수의 크롤링 데이터베이스만 많은 수의 프로세서 리소스를 사용하는 경우 크롤링 데이터베이스에서 부하가 균일하지 않은 것입니다. 모든 크롤링 데이터베이스에서 콘텐츠 균형을 다시 조정하는 것을 고려합니다. 이와 같이 균형을 다시 조정하는 동안 크롤링이 일시 중지되므로 일시 중지 중에 발생한 변경 내용이 크롤링이 모두 반영될 때까지 결과의 최신성이 떨어집니다. 데이터베이스 페이지의 밸런스 단추를 사용해서 균형을 다시 조정하기 시작합니다. 검색 관리에서 크롤링 로그로 이동한 후 데이터베이스를 선택합니다.
콘텐츠 처리를 위한 처리 및 메모리 리소스 늘리기
콘텐츠 처리 구성 요소가 100%에 가까운 CPU 리소스를 사용하는 경우 콘텐츠 처리 구성 요소를 더 추가하거나 콘텐츠 처리 구성 요소를 호스팅하는 서버에 CPU 리소스를 더 추가하는 것을 고려합니다.
메모리가 자주 다시 시작되면 콘텐츠 처리 구성 요소를 호스팅하는 서버의 메모리 양을 늘리는 것을 고려합니다. CPU 코어당 작동 메모리가 2GB이면 적절합니다.
인덱스 파티션 수 늘리기
콘텐츠 처리 작업을 확인합니다. 검색 관리로 가서 크롤링 상태 보고서를 선택한 후 콘텐츠 처리 작업을 선택하면 됩니다. 인덱싱에 가장 많은 시간이 소요되면 인덱스를 더 많은 파티션으로 나누는 것을 고려합니다. 인덱스 파티션이 더 많아지면 인덱싱 부하가 분산될 수 있습니다.
사용 중인 설치에 더 많은 파티션을 추가하면 인덱스 파티션이 자동으로 다시 지정됩니다. 인덱스 파티션을 다시 지정하는 데 몇 시간 또는 며칠이 소요될 수 있습니다. 소요 시간은 파티션을 다시 시작할 때 팜의 상태에 따라 달라집니다.
쿼리 대기 시간을 줄이고 쿼리 처리량을 늘리는 방법
검색 기능이 초당 처리할 수 있는 쿼리 수를 쿼리 처리량이라고 합니다. 쿼리 처리량은 검색 기능이 쿼리를 처리하는 데 사용하는 시간과 처리 리소스를 사용할 수 없기 때문에 쿼리가 대기하는 시간에 따라 좌우됩니다. 이러한 처리 시간과 대기 시간을 합한 시간을 쿼리 대기 시간이라고 합니다. 쿼리 대기 시간을 줄이면 쿼리 처리량이 늘어납니다. 쿼리 대기 시간을 줄이려면 다음 지침을 따르세요.
| 지침 |
|---|
| 쿼리 처리 시간 절감 |
| 쿼리 대기 시간 절감 |
쿼리 처리 시간 절감
인덱스에 더 많은 파티션을 추가하는 것을 고려합니다. 파티션이 많다는 것은 각 파티션에 있는 항목 수가 작다는 것입니다. 항목 수가 작으면 각 파티션이 쿼리에 더 빠르게 응답할 수 있다는 것입니다. 그렇지만 파티션이 너무 많은 것도 좋은 것은 아닙니다. 쿼리 처리 구성 요소는 각 파티션의 응답을 병합하여 쿼리 답변을 생성하기 때문에 인덱스에 많은 파티션이 있으면 병합 시간도 늘어납니다. 모든 파티션에는 동일한 수의 복제본이 있어야 합니다.
사용 중인 설치에 더 많은 파티션을 추가하면 인덱스 파티션이 자동으로 다시 지정됩니다. 인덱스 파티션을 다시 지정하는 데 몇 시간 또는 며칠이 소요될 수 있습니다. 소요 시간은 파티션을 다시 시작할 때 팜의 상태에 따라 달라집니다.
쿼리 대기 시간 절감
다음 작업을 고려하세요.
인덱스 복제본을 더 추가합니다. 더 많은 복제본을 추가하면 검색 기능이 복제본 간에 쿼리를 분산하며 동시에 쿼리를 처리합니다. 하나의 인덱스 구성 요소는 하나의 인덱스 복제본을 나타냅니다. 모든 파티션에는 동일한 수의 복제본이 있어야 하므로 인덱스의 각 파티션에 하나의 인덱스 구성 요소를 추가합니다. 사용 중인 설치의 기존 파티션에 인덱스 구성 요소를 복제본으로 추가하면 검색 기능은 인덱스 파티션의 데이터로 새 복제본을 자동으로 시드합니다. 새 복제본이 작동되려면 몇 시간이 소요될 수 있습니다.
인덱스 구성 요소를 호스팅하는 서버에 메모리를 더 추가합니다.
인덱스 구성 요소를 호스팅하는 서버에서 SSD(Solid State Drive)와 같은 인덱스를 위해 더 빠른 저장소로 전환합니다.
인덱스 구성 요소를 호스팅하는 서버에 프로세서 리소스를 더 추가합니다. 그러면 구성 요소는 초당 더 많은 쿼리를 처리합니다. 예를 들어 서버에 2GHz CPU가 있으면 코어 하나가 다음을 처리할 수 있습니다.
인덱스에 백만 개의 항목이 있을 때 초당 5개의 쿼리
인덱스에 5백만 개의 항목이 있을 때 초당 2개의 쿼리
인덱스에 천만 개의 항목이 있을 때 초당 1개의 쿼리
쿼리 처리 구성 요소를 호스트하는 서버에 더 많은 프로세서 리소스를 추가합니다. 그런 다음, 특히 쿼리가 드물고 복잡한 경우 구성 요소는 초당 더 많은 쿼리를 처리합니다. 쿼리 처리 구성 요소에 대한 프로세서 리소스의 필요성을 유발하는 쿼리 속도 및 쿼리 변환 수입니다. 쿼리 처리 구성 요소에는 일반적으로 초당 4개 쿼리당 하나의 CPU 코어가 필요합니다.
분석 처리 시간을 줄이는 방법
분석 처리는 매일 밤 수행됩니다. 분석 처리 구성 요소는 구성 요소를 호스팅하는 서버에 중간 데이터를 저장하고 분석 결과를 분석 보고 데이터베이스에 저장합니다. 오류로 인해 분석 처리가 방해되는 경우 문서 크롤링 또는 쿼리 답변에 영향을 미치지 않습니다. 그러나 쿼리 결과에는 최적의 관련성이 없습니다.
다음 작업을 고려하세요.
작업 환경에 쿼리 결과에 대해 최적의 적합성이 요구되지만 분석 처리가 이를 충족시킬 만큼 빠르지 않으면 더 많은 디스크(스핀들) 또는 더 빠른 디스크를 추가합니다.
분석 처리에 평소보다 더 많은 시간이 소요되기 시작하면 분석 보고 데이터베이스를 추가합니다. 데이터베이스가 250GB 크기 또는 2천만 개의 총 행 수에 도달하거나 일별 보기 수가 500,000개의 고유 항목에 도달할 경우 이러한 증가가 나타날 수 있습니다.
분석 처리를 완료하는 데 24시간 이상 소요되면 분석 처리 구성 요소를 더 추가하거나 분석 처리 구성 요소를 호스팅하는 서버에 프로세스 리소스를 더 추가합니다. 인덱스의 항목 수와 프로세서 리소스의 필요성을 유도하는 사이트의 활동입니다.
분석 처리가 절대 완료되지 않거나 분석 구성 요소를 호스팅하는 서버에서 디스크에 대한 상태 알림이 발생하면 서버에 디스크 공간을 더 추가합니다. 분석 구성 요소가 더 많은 중간 데이터를 더 빠르게 처리하려면 분석 처리 구성 요소를 호스팅하는 서버에 분석 처리 구성 요소나 프로세서 리소스를 더 추가하는 것을 고려합니다.
검색 구성 요소 및 데이터베이스가 중복되게 하는 방법
결함이 있는 별도의 도메인에서 중복된 검색 구성 요소 및 데이터베이스를 호스팅할 때 검색 아키텍처는 고가용성을 지원합니다. 중복된 검색 데이터베이스 및 구성 요소로 검색 토폴로지를 디자인하는 것이 좋습니다. Microsoft에서 테스트한 모든 샘플 검색 아키텍처에는 중복 검색 구성 요소 및 데이터베이스가 있으므로 사용자 고유의 토폴로지에서 작업할 때 이러한 샘플을 연구하는 것이 유용할 수 있습니다( SharePoint 2016용 엔터프라이즈 검색 아키텍처 참조).
다음 지침을 따르세요.
| 지침 |
|---|
| 인덱스 중복 |
| 크롤링, 콘텐츠 처리, 쿼리 처리, 분석 처리 및 검색 관리 구성 요소 중복 |
| 검색 데이터베이스 중복 |
인덱스 중복
인덱스 파티션당 2개 이상의 인덱스 복제본이 있는 경우 인덱스가 중복된 것입니다. 인덱스 복제본을 호스팅하는 서버에 장애가 발생하면 성능은 저하되지만 검색 기능은 여전히 쿼리를 처리하고 항목을 인덱싱할 수 있습니다. 그렇지만 항상 동일한 성능을 요구하는 환경이라면 더 많은 중복 인덱스 구성 요소가 필요합니다. 예를 들어 항상 쿼리 대기 시간을 짧게 유지해야 하는 환경에서 파티션당 2개의 복제본이 있는 검색 토폴로지를 디자인하여 쿼리 대기 시간을 줄이려고 합니다. 이 경우 파티션당 인덱스 복제본 수를 늘리세요.
모든 파티션에는 동일한 수의 복제본이 있어야 합니다. 하나의 인덱스 구성 요소는 단일 인덱스 복제본을 나타냅니다. 따라서 인덱스의 두 복제본을 원하는 경우 인덱스 파티션보다 두 배 많은 인덱스 구성 요소가 필요합니다. 예를 들어 항목이 8천만 개인 SharePoint Server 2016a 중복 인덱스를 사용하려면 4개의 파티션이 필요합니다. 각 파티션에 대해 복제본 2개를 사용할 경우 8개의 인덱스 구성 요소는 4개의 파티션을 나타냅니다.
사용 중인 설치의 기존 파티션에 인덱스 구성 요소를 복제본으로 추가하면 검색 기능은 인덱스 파티션의 데이터로 새 복제본을 자동으로 시드합니다. 새 복제본이 작동되려면 몇 시간이 소요될 수 있습니다.
크롤링, 콘텐츠 처리, 쿼리 처리, 분석 처리 및 검색 관리 구성 요소 중복
크롤링 구성 요소를 예로 들어 보겠습니다. 유지 관리를 위해 크롤링 구성 요소를 호스팅하는 서버 중 하나를 중단해야 하는 경우 결과의 새로 고침이 줄어들 수 있지만 검색은 여전히 모든 콘텐츠를 크롤링할 수 있습니다. 그러나 환경에 항상 동일한 새로 고침 결과가 필요한 경우 검색에는 더 많은 중복 크롤링 구성 요소가 필요합니다. 예를 들어 세 개의 크롤링 구성 요소를 사용하여 검색 토폴로지를 설계했으며 두 개의 크롤링 구성 요소 서버가 실패하더라도 동일한 새로 고침 결과를 원합니다. 두 개의 크롤링 구성 요소를 더 추가합니다.
검색 관리 구성 요소는 이 원칙에 대한 예외입니다. 하나의 검색 관리 구성 요소에는 모든 크기 검색 토폴로지의 용량이 충분합니다. 따라서 두 개의 검색 관리 구성 요소가 중복성을 위해 충분합니다.
콘텐츠 처리 구성 요소는 서로 간에 부하를 분산하므로 중복된 콘텐츠 처리 구성 요소가 있으면 항목을 처리하기 위한 용량을 늘어납니다.
검색 데이터베이스 중복
검색 데이터베이스가 중복되도록 하려면 SQL Server에서 제공하는 고가용성 대안을 사용합니다(SharePoint Server에 대한 고가용성 아키텍처 및 전략 만들기 참조).
3단계: 서버를 실제로 실행할지 또는 가상으로 실행할지 선택
처음에 검색 아키텍처를 계획할 때 실제 서버나 가상 시스템 중 한 가지를 사용하거나 두 가지를 모두 사용할지 결정했을 것입니다. 이러한 결정이 여전히 유효한지 고려해봅니다. 현재 더 많은 검색 구성 요소가 있는 경우 가상 시스템을 사용하여 아키텍처를 더 용이하게 관리할 수 있습니다. 예를 들어 실제 컴퓨터보다 결함이 있는 가상 머신을 교체하는 것이 더 쉽습니다. 가상 환경이 관리하기 더 쉽지만 실제 환경보다 성능 수준이 더 나쁜 경우도 있습니다. 실제 서버는 가상 서버와 동일한 서버에 더 많은 검색 구성 요소를 호스팅할 수 있습니다. SharePoint 2013용 팜 가상화 및 아키텍처 개요에서 유용한 지침을 찾을 수 있습니다.
4단계: 어떤 서버에서 어떤 검색 구성 요소 또는 데이터베이스를 호스팅할지 결정
검색 토폴로지를 다시 디자인했으면 이제 검색 및 데이터베이스 구성 요소를 실제 또는 가상 서버에 할당해야 합니다. 물리적 서버 또는 가상 머신에 검색 구성 요소를 할당하는 최적의 방법은 하나도 없지만 다음 지침이 있습니다.
서버당 하나의 검색 구성 요소 유형
각 실제 서버 또는 가상 시스템은 각 유형의 검색 구성 요소를 하나씩만 호스팅할 수 있습니다. 인덱스 구성 요소는 예외입니다. 실제 서버 또는 가상 시스템은 최대 4개의 인덱스 구성 요소를 호스트할 수 있습니다. 검색 제한에서 이러한 제한에 대해 읽을 수 있습니다.
일괄 처리 및 실시간 구성 요소를 서로 분리
일괄 처리 및 실시간 처리 검색 구성 요소를 동일한 실제 서버 또는 가상 시스템에 혼합해서 두지 않도록 합니다. 크롤링, 콘텐츠 처리 및 분석 처리 구성 요소는 일괄 처리를 수행합니다. 인덱스 및 쿼리 처리 구성 요소는 실시간 처리를 수행합니다.
경합하는 검색 구성 요소를 혼합하지 않기
구성 요소가 동일한 리소스를 상대로 경합하는 경우 실제 서버나 시스템에 혼합된 검색 구성 요소를 두지 않도록 합니다. 각 구성 요소에 필요한 리소스의 상대적 양을 보여 주는 테이블은 다음과 같습니다.
예를 들어 크롤링 및 분석 처리 구성 요소는 둘 다 많은 양의 네트워크 대역폭을 사용하므로 같은 서버에 두는 것은 바람직하지 않을 수 있습니다. 그러나 실제 서버 또는 가상 머신에 충분한 네트워크 용량이 있는 경우 구성 요소는 경쟁하지 않습니다.
또 다른 예로 Microsoft에서 예측해온 초대형 검색 아키텍처 샘플이 있습니다. 여기서는 크롤링 및 검색 관리 구성 요소를 별도의 가상 컴퓨터에 배치했습니다. 두 구성 요소가 프로세서 리소스를 놓고 경쟁하기 때문에 이와 같이 분리하면 크롤링 속도가 빨라집니다.
결함 있는 도메인 사용
결함 있는 별도의 도메인의 호스트에 중복 검색 구성 요소를 할당합니다.
5단계: 알아야 할 하드웨어 요구 사항
다음 단계에서는 필요한 하드웨어를 계획합니다.
호스트 서버의 하드웨어 리소스 양 선택
각 검색 구성 요소 및 검색 데이터베이스가 제대로 작동되려면 최소 크기의 하드웨어 리소스가 필요합니다. 그렇지만 하드웨어 리소스가 많을 수록 검색 아키텍처의 성능은 더 좋아집니다. 따라서 최소 크기의 하드웨어 리소스보다 더 많은 리소스가 있는 것이 좋습니다. 각 구성 요소에 필요한 리소스는 작업 부하에 따라 다르며, 주로 크롤링 속도, 쿼리 속도 및 인덱싱된 항목 수에 따라 결정됩니다.
예를 들어 Windows Server 2008 R2 SP1(서비스 팩 1)에서 가상 머신을 호스팅하는 경우 가상 머신당 4개 이상의 CPU 코어를 사용할 수 없습니다. Windows Server 2012 이상에서는 가상 머신당 8개 이상의 CPU 코어를 사용합니다. 그런 다음 더 많은 가상 머신으로 스케일 업하는 대신 각 가상 머신에 대해 더 많은 CPU 코어로 스케일 아웃할 수 있습니다. 동일한 하드웨어 리소스를 사용하여 동일한 검색 구성 요소를 호스트하는 서버 또는 가상 머신을 설정합니다. 인덱스 구성 요소를 예로 들어 보겠습니다. 가상 머신에서 인덱스 파티션을 호스트하는 경우 성능이 가장 약한 가상 머신은 전체 검색 아키텍처의 성능을 결정합니다.
일반 저장소
각 호스트 서버에 Windows Server 운영 체제 및 SharePoint Server 2016 프로그램 파일의 기본 설치를 위한 충분한 디스크 공간이 있는지 확인합니다. 또한 호스트 서버에 진단(예: 로깅, 디버깅 및 메모리 덤프 생성), 일상적인 작업 및 페이지 파일에 사용 가능한 하드 디스크 공간도 필요합니다. 일반적으로 80GB의 디스크 공간은 Windows Server 운영 체제 및 SharePoint Server 2016 프로그램 파일에 충분합니다.
각 데이터베이스 서버에 대해 SQL 로그 공간으로 사용될 저장소를 추가합니다. 데이터베이스를 자주 백업하도록 데이터베이스 서버를 설정하지 않은 경우 SQL 로그 공간이 많은 저장소를 사용합니다. SQL 데이터베이스를 계획하는 방법에 대한 자세한 내용은 스토리지 및 SQL Server 용량 계획 및 구성(SharePoint Server)을 참조하세요.
분석 보고 데이터베이스에 필요한 최소 저장소는 다를 수 있습니다. 스토리지의 양은 사용자가 SharePoint Server 2016과 상호 작용하는 방식에 따라 달라지기 때문입니다. 사용자가 자주 상호 작용할 경우 일반적으로 저장할 이벤트가 더 많아집니다. 현재 검색 아키텍처가 분석 데이터베이스에 대해 사용하는 저장소 양을 확인하고 다시 디자인한 토폴로지에 대해 적어도 이보다 큰 공간을 할당합니다.
인덱스 구성 요소에 대한 최소 리소스
이 리소스는 서버 또는 가상 시스템이 하나의 인덱스 구성 요소를 호스팅하거나 하나의 인덱스 구성 요소와 하나의 쿼리를 호스팅하는 데 필요한 최소 리소스입니다.
| 저장소 | 메모리 | 프로세서 | 네트워크 대역폭 |
| 인덱스에 대해 500GB1 | 32 GB1 | 64비트, 최소 8코어1, 2. | 2Gbps |
1SharePoint Server 2013을 사용하면 최소 리소스 크기는 500GB 스토리지, 16GB RAM 및 4개의 CPU 코어입니다.
2SharePoint Server 2016을 사용하는 경우 4개의 CPU 코어 및 16GB RAM을 사용할 수 있지만 각 인덱스 구성 요소는 최대 1천만 개의 항목을 포함할 수 있습니다(2천만 개 항목 아님).
분석 처리 구성 요소에 대한 최소 리소스
이 리소스는 서버 또는 가상 시스템이 하나의 분석 처리 구성 요소를 호스팅하는 데 필요한 최소 리소스입니다.
| 저장소 | 메모리 | 프로세서 | 네트워크 대역폭 |
| 로컬 분석 처리를 위해 300GB | 8GB | 64비트, 코어 4개 이상, 코어 8개 권장 | 2Gbps |
서버가 하나의 분석 처리 구성 요소와 하나 이상의 일괄 처리 구성 요소를 호스팅하는 경우 메모리를 16GB로 늘립니다.
크롤링, 콘텐츠 처리, 쿼리 처리 및 검색 관리 구성 요소에 대한 최소 리소스
이 리소스는 서버 또는 가상 시스템이 이러한 구성 요소 중 하나를 호스팅하는 데 필요한 최소 리소스입니다.
| 저장소 | 메모리 | 프로세서 | 네트워크 대역폭 |
| 필요 없음 | 8GB | 64비트, 코어 4개 이상, 코어 8개 권장 | 2Gbps |
서버가 이러한 구성 요소의 두 가지 이상을 호스팅하는 경우 메모리를 16GB로 늘립니다.
쿼리 처리 구성 요소에는 적절한 네트워크 대역폭이 필요합니다. 인덱스 파티션의 수와 네트워크 대역폭에 대한 이러한 필요성을 유발하는 쿼리 및 결과의 크기입니다. 예를 들어 쿼리 처리 구성 요소당, 초당 쿼리 수가 20개(20 QPS/QPC)이고 파티션에 인덱스 파티션이 20개 있으면 쿼리 처리 구성 요소를 호스팅하는 서버 또는 가상 시스템에 대해 200Mbps의 들어오는 트래픽과 100Mbps의 나가는 트래픽이 발생합니다.
검색 데이터베이스를 위한 최소 리소스
이 리소스는 서버 또는 가상 시스템이 하나 이상의 검색 데이터베이스를 호스트하는 데 필요한 최소 리소스입니다.
| 저장소 | 메모리 | 프로세서 | 네트워크 대역폭 |
| 분석 보고 데이터베이스에 필요한 저장소는 검색 구성 요소가 분석을 사용하는 방식 및 빈도에 따라 다릅니다. 분석 보고 데이터베이스의 현재 저장소 양을 참조합니다. | 8GB(소규모 배포의 경우) 16GB(중간 규모 배포의 경우) |
64비트, 코어 4개 | 2Gbps |
저장소 성능 계획
저장소의 속도는 검색 성능에 영향을 줍니다. 사용 중인 저장소가 검색 구성 요소 및 데이터베이스의 트래픽을 처리할 수 있을 정도로 충분히 빠른지 확인하세요. 디스크 속도는 IOPS(초당 I/O 작업 수)로 측정됩니다.
검색 구성 요소 및 운영 체제의 데이터를 저장소 내에 배포하는 방식이 검색 성능에 영향을 줍니다. 다음과 같이 수행하는 것이 좋습니다.
일반 성능을 갖는 세 개의 별도 저장소 볼륨 또는 파티션에 Windows Server 운영 체제 파일, SharePoint Server 2016 프로그램 파일 및 진단 로그를 분할합니다.
검색 구성 요소 데이터를 별도의 저장소 볼륨 또는 파티션에 저장합니다. 인덱스 구성 요소의 경우 이 저장소의 성능도 좋아야 합니다.
참고
호스트에 SharePoint Server 2016을 설치할 때 검색 구성 요소 데이터에 대한 사용자 지정 위치를 설정할 수 있습니다. 데이터를 저장해야 하는 호스트의 모든 검색 구성 요소는 데이터를 이 위치에 저장합니다. 나중에 이 위치를 변경하려면 SharePoint Server 2016을 다시 설치해야 합니다.
저장소 유형 선택
스토리지 아키텍처 및 디스크 유형에 대한 개요는 스토리지 및 SQL Server 용량 계획 및 구성(SharePoint Server 2016)을 참조하세요. 인덱스, 분석 처리 및 검색 관리 구성 요소 또는 검색 데이터베이스를 호스팅하는 서버에는 짧은 대기 시간을 유지 관리하면서 충분한 IOPS(초당 I/O 작업 수)를 제공할 수 있는 저장소가 필요합니다. 다음 표에는 이러한 각 검색 구성 요소 및 데이터베이스에 필요한 IOPS가 나와 있습니다.
SAN/NAS와 같은 공유 저장소를 배포할 경우 검색 구성 요소 하나의 최대 디스크 부하는 일반적으로 다른 검색 구성 요소의 최대 디스크 부하와 일치합니다. 공유 저장소에서 검색에 필요한 IOPS를 확보하려면 이러한 각 구성 요소에 대한 IOPS 요구 사항을 추가해야 합니다.
검색 구성 요소 IOPS 요구 사항
| 구성 요소 이름 | 구성 요소 정보 | IOPS 요구 사항 | 별도의 저장소 볼륨/파티션 사용 |
|---|---|---|---|
| 인덱스 구성 요소 | 인덱스를 병합할 때와 쿼리를 처리하고 쿼리에 응답할 때 저장소를 사용합니다. | 64KB 임의 읽기의 경우 300IOPS 256KB 임의 쓰기의 경우 100IOPS 순차적 읽기의 경우 200MB/s 순차적 쓰기의 경우 200MB/s |
예 |
| 분석 구성 요소 | 로컬로 대량 처리되는 데이터를 분석합니다. | 아니요 | 예 |
| 크롤링 구성 요소 | 다운로드한 콘텐츠를 콘텐츠 처리 구성 요소로 보내기 전에 로컬로 저장합니다. 저장소는 네트워크 대역폭에 따라 제한됩니다. | 아니요 | 예 |
검색 데이터베이스 IOPS 요구 사항
| 데이터베이스 이름 | IOPS 요구 사항 | I/O 하위 시스템의 일반적인 부하 |
|---|---|---|
| 크롤링 데이터베이스 | 보통~높은 IOPS | 1 DPS(초당 문서 수)당 10 IOPS의 크롤링 속도 |
| 링크 데이터베이스 | 보통 IOPS | 검색 인덱스의 항목 100만 개당 10 IOPS |
| 검색 관리 데이터베이스 | 낮은 IOPS | 해당 없음 |
| 분석 보고 데이터베이스 | 보통 IOPS | 해당 없음 |
검색 아키텍처에서 고가용성을 지원하는 방식 선택
고가용성 전략에 익숙하지 않은 경우 SharePoint Server에 대한 고가용성 아키텍처 및 전략 만들기를 시작하는 문서를 참조하세요. 별도의 장애 도메인에서 중복 검색 구성 요소 및 데이터베이스를 호스트하는 경우 팜의 한 부분에서 중단이 전체 서비스를 중단하지 않습니다. 그러나 검색 구성 요소가 더 이상 부하를 공유할 수 없으므로 검색 성능이 저하됩니다. 단일 서버 손실 가능성을 줄이려면 로컬 중복성을 개선하는 것이 좋습니다. 검색 아키텍처의 각 호스트 서버에 대해 다음을 수행합니다.
각 서버에서 RAID 저장소를 사용합니다.
각 서버에 여러 개의 중복 네트워크 연결을 설치합니다.
각 서버에 대해 독립된 배선 또는 UPS(무정전 전원 공급 장치)가 있는 여러 개의 중복 전원 공급 장치를 설치합니다.
모든 샘플 검색 아키텍처는 독립된 서버에 중복 검색 구성 요소를 호스팅합니다. 샘플 검색 아키텍처에서 각 호스트 쌍의 맨 오른쪽에 있는 호스트는 중복 호스트입니다. 개요가 있는 중복 호스트가 있는 대규모 검색 아키텍처는 다음과 같습니다.
