OAB 다운로드 시간이 오래 걸리는 문제 해결

  • Articolo

최초 문서 게시일: 2012년 2월 20일 월요일

최근의 Exchange 2010 서비스 팩 2용 업데이트 롤업 1 공개 공지에 따라 다수의 픽스가 공개되었습니다. 이 블로그에서는 그 중 하나에 대해 설명하고 픽스 적용 대상 문제가 발생하는 상황에 대한 배경 정보와 해당 문제를 해결하는 방법에 대해 살펴보겠습니다.

여기서 설명하고자 하는 픽스의 현재 번호는 2556113(영문일 수 있음)이고 제목은 Exchange Server 2010 조직의 사용자가 OAB를 다운로드하는 데 시간이 오래 걸림 입니다.

제목만 보면 Microsoft에서 단순히 OAB를 '더 빠르게' 다운로드하는 방법을 찾아냈으며, 이를 위해 OAB에서 일부 사용자(예: 다른 부서에서 근무하는 잘 모르는 사용자)를 임의로 삭제한다고 생각하실 수 있을 것입니다. 또는 단순히 성, 사무실 위치, 전화 번호 등의 불필요한 정보를 제거하여 OAB에 포함되었던 세부 정보를 줄이거나, 인터넷 속도를 높이는 등의 쉬운 방법을 사용하면 되지 않느냐고 생각하시는 분도 계시겠지요.

물론 저희 팀에서도 인터넷 검색을 통해 어떤 '쉬운' 방법이 있는지를 찾아 보기는 했지만, 이 픽스에서는 위와 같은 방법을 사용하지 않았습니다. 대신 Outlook에서 가장 가까운 CAS로부터 OAB를 다운로드하도록 하는 논리를 추가했습니다.

이러한 방식을 사용한 이유를 물으신다면, KB에 나와 있는 것처럼 다음과 같은 시나리오를 가정해 보시기 바랍니다.

  • Microsoft Exchange Server 2010 조직의 속도가 느린 네트워크에 Active Directory 사이트가 두 개 있습니다.
  • Active Directory 사이트 하나에 Exchange Server 2010 클라이언트 액세스 서버와 Exchange Server 2010 사서함 서버가 있습니다.
  • Exchange Server 2010 클라이언트 액세스 서버가 있는 상태에서 다른 Active Directory 사이트에 Office Outlook 사용자를 추가합니다.
  • 사서함이 다른 Active Directory 사이트에 있는 사용자가 Exchange OAB(오프라인 주소록) 다운로드를 시도합니다.

이러한 시나리오에서는 OAB를 다운로드하는 데 시간이 오래 걸립니다.

실제로 OAB가 큰 경우에는 시간이 매우 오래 걸립니다. 여러분이 알아 두셔야 할 정보가 있으니 위의 시나리오를 약간 확대해 볼까요? 대부분의 사용자에게 있어서 AD 사이트에 CAS만 포함하는 것은 적절하지 않을 것입니다.

그러므로 다음과 같은 보다 자세한 시나리오를 가정해 보겠습니다.

  • 중앙 집중식 배포를 수행했으며 모든 사서함은 단일 중앙 위치에 있습니다.
  • 사용자는 다수의 소규모 위치에 연결하여 작업을 수행합니다.
  • 이러한 위치는 중앙 사이트에 연결되어 있지만 네트워크 상태는 우수하지 못합니다. 위성, ISDN, PSTN, 대류권 산란(영문일 수 있음)(예전에 이러한 네트워크를 사용하는 고객이 있었는데 평소에는 문제가 없지만 천재지변이 발생하는 등의 경우에는 네트워크를 전혀 사용할 수 없게 됩니다), 저속 통신 등이 사용됩니다.
  • OAB의 크기가 매우 큽니다.
  • Outlook 클라이언트가 OAB 다운로드를 시도하여 중앙 데이터 센터에서 OAB를 가져옵니다. 그런데 다른 여러 동료들도 같은 저속 통신을 통해 Outlook 클라이언트를 사용하여 모두 같은 OAB를 다운로드하고 있어서 속도가 매우 느립니다 .

이러한 경우 여러 사용자가 작업을 수행하면서 같은 대역폭에 대해 경합 중임을 확인할 수 있는 경우도 있습니다. OAB 다운로드에 사용되는 BITS 클라이언트 기술은 효율적이기는 하지만 이러한 상황에서는 큰 도움이 되지 않습니다.

속도 개선을 위해 https://technet.microsoft.com/ko-kr/library/bb232155.aspx의 다이어그램에 상세하게 나와 있는 것처럼 각 원격 위치에 CAS를 추가할 수 있습니다. 이 경우 클라이언트 컴퓨터가 필요한 OAB를 로컬 CAS에서 다운로드한다고 가정하는데요, Exchange는 이러한 방식으로 작동하지 않습니다. 아래에서 2010 SP2 RU1 이전의 Exchange 작동 방식에 대해 설명하겠습니다.

이전의 Exchange 작동 방식 및 TechNet의 부적절한 정보

먼저 이전의 Exchange 작동 방식에 대해 살펴보자면, 클라이언트가 OAB를 다운로드하는 데 사용하는 URL은 자동 검색 서비스를 통해 클라이언트에게 제공되었습니다. 그리고 자동 검색 코드는 다운로드해야 하는 OAB의 URL을 항상 클라이언트 컴퓨터가 있는 AD 사이트가 아닌 사용자 의 사서함이 있는 AD 사이트에서 선택했습니다.

다음으로, TechNet의 부적절한 정보에 대해 언급하겠는데, 그 전에 먼저 'TechNet의 정보는 각 작성자들이 심혈을 기울여 작성하는 것으로 절대 틀리지는 않다'는 점을 강조하고 싶습니다. 정보 자체가 틀리다기보다는, 특정 견해에서 보면 '적합하지 않다'는 것입니다. TechNet의 설명에 따르면, 위에서 설명한 방식이 2007 버전을 디자인할 당시의 원래 PM 사양에 포함되어 있었던 것은 사실이지만 완성은 되지 않은 상태였습니다. 코드가 2천만 줄이 넘고 자주 바뀌는 소프트웨어 제품에서는 이러한 현상이 빈번하게 발생합니다. 다시 한 번 말씀드리지만, TechNet의 정보 자체가 잘못되었던 것은 아닙니다.

다시 Exchange의 작동 방식으로 돌아가 구체적인 예를 살펴보겠습니다. OAB가 1GB이고 사용자가 있는 원격 및 원거리 AD 사이트의 CAS에 이 OAB의 복제본을 추가한다고 가정해 보겠습니다. 그러나 사용자는 이러한 OAB를 전혀 사용하지 않습니다. 사용자의 사서함도 같은 AD 사이트에 있는 경우는 예외이지만 이러한 경우는 이 시나리오에 포함되지 않습니다. 아래 다이어그램에서도 확인할 수 있지만 이는 꽤 번거로운 방식입니다.

이미지

Outlook은 클라이언트의 자동 검색 요청에 대해 클라이언트 컴퓨터와 가장 가까운 CAS를 사용하며 반드시 이 CAS를 사용해야 합니다(여기에 대해서는 아래에서 다시 설명함). 그러나 Outlook이 전달하는 OAB URL은 사서함과 같은 AD 사이트에 있는 CAS의 URL입니다 . 따라서 OAB를 AD 사이트 B에 복제해도 클라이언트는 AD 사이트 A에서 OAB를 가져옵니다 .

따라서 소규모 사이트가 많고 OAB가 매우 큰 대기업 고객의 경우 이러한 방식을 사용할 수 없으며, 보유한 WAN 대역폭에 관계없이 다운로드 시간이 너무 오래 걸린다는 불만을 토로하곤 합니다. 그러면 이러한 문제를 해결하는 방법은 없을까요? 다음과 같은 몇 가지 해결 방법이 있습니다. 저희 팀에서는 그러한 방법을 찾아내 사용자를 위해 관련 정보를 제공하는 작업을 집중적으로 수행하고 있습니다.

  1. OAB 크기를 줄이거나 WAN 속도를 높이거나 원격 사무실을 더 가까운 위치로 이동하는 등의 방법을 사용할 수 있습니다. 실제로 이러한 해결 방법을 사용할 수 있는 고객은 없었지만 저희 팀은 가능한지 여부를 문의하기는 했습니다.
  2. 같은 콘텐츠를 포함하는 OAB를 많이 만들고, 사용자가 다운로드해야 하는 OAB를 사용자 수준 또는 데이터베이스 수준별로 지정한 후에 해당 OAB만 원격 위치에서 제공하는 방법도 있습니다. 그러면 자동 검색에서는 원격 위치에 있는 OAB의 URL(검색 가능한 유일한 URL)을 제공합니다. 이 방식은 적절하기는 하지만 사용자가 사이트 간을 이동하는 경우에는 사용하기가 어려우며 다운로드 시에 저속 네트워크 홉이 두 배로 증가하므로 실용적이지 못합니다.
  3. 사서함을 원격 위치로 이동할 수 있습니다. 그러나 사서함 역시 여러 위치로 옮겨질 수 있으며 이 방식을 사용하는 경우 관리 및 고가용성 관련 작업이 매우 복잡해져 결과적으로는 비용이 증가합니다.
  4. AD 사이트 매핑에 대해 역방향 IP 주소를 사용할 수 있습니다. 예전에는 원래 이 방식으로 문제를 해결했었는데, 이 방법은 사용하기가 꽤 어렵습니다. 클라이언트가 포함될 수 있는 모든 서브넷이 AD 사이트 및 서비스에 있는지 확인하고, 사용자가 있는 AD 사이트를 리버스 엔지니어링한 다음 사이트 링크 비용을 확인하는 등의 여러 과정을 거쳐야 하기 때문입니다. 즉, 이 방식은 복잡하고 NAT보다 효율적이지 못하며, 관리자가 AD 사이트 및 서비스에서 사용 가능한 모든 서브넷 목록을 제공하지 않는 경우에는 사용할 수 없습니다.
  5. DNS 또는 자동 검색 XML을 통한 '간섭'을 통해 클라이언트가 실제로는 로컬 IIS 인스턴스와 통신하지만 중앙 위치와 통신하는 것으로 인식하도록 할 수 있습니다. 그러나 이 방법 역시 어렵고 구현 및 지원하기가 까다로우며 효율적이지 못합니다.
  6. 다른 방법을 사용할 수 있습니다. 위의 모든 방법은 매우 어려워 보이므로 여기서는 이 방법에 대해 설명하겠습니다.

앞 단락에서 "Outlook은 클라이언트의 자동 검색 요청에 대해 클라이언트 컴퓨터와 가장 가까운 CAS를 사용한다"고 언급하고 아래에서 다시 설명하겠다고 말씀드렸었는데요, 여기서 AutoDiscoverServiceSiteScope라는 항목에 대해 설명하겠습니다.

AutoDiscoverServiceSiteScope는 Outlook 클라이언트가 자동 검색 요청에 대해 클라이언트와 가장 가까운 CAS를 찾을 목적으로 AD 사이트를 CAS에 매핑할 수 있도록 하는 CAS 설정입니다. 이를 위해 AutoDiscoverServiceSiteScope는 자동 검색 서비스에 대한 포인터인 SCP(서비스 연결 지점)를 찾습니다.

그러면 AutoDiscoverServiceSiteScope의 작동 방식에 대해 설명하겠습니다. Outlook 클라이언트는 시작 시에 먼저 'AD'를 검색하여 Exchange 설정에 따라 모든 SCP를 찾습니다. 이 과정에서 여러 SCP가 검색되며, 각 SCP에는 Keywords 특성이 있습니다. 이 특성은 Set-ClientAccessServer –AutoDiscoverServiceSiteScope를 사용하여 설정 및 변경되며 가끔 혼란을 주는 경우도 있습니다(ADSiteNameA, ADSiteNameB 등). Keywords 특성은 해당 CAS가 자동 검색 요청에 대해 검색해야 하는 AD 사이트를 지정하는 데 사용됩니다.

Outlook 클라이언트는 SCP를 두 개 이상 찾으면 Keywords 특성에 저장된 값과 자체 AD 사이트의 값을 비교하여 사용 가능한 SCP 목록을 작성합니다. Outlook 클라이언트의 자체 AD 사이트 값은 클라이언트가 시작되거나 IP 주소가 변경될 때 로컬 Netlogon 서비스를 통해 동적으로 업데이트됩니다.

그런 다음 클라이언트는 목록을 하나 작성하는데, 이 목록에는 자체 AD 사이트와 일치하는 모든 SCP(Keywords특성 = 클라이언트 AD 사이트)가 포함되거나, 그러한 SCP가 없는 경우 모든 SCP가 포함됩니다. 클라이언트는 이러한 서버를 자동 검색 요청에 대해 사용할 수 있습니다.

다음으로 클라이언트는 목록 맨 위에서부터(목록은 항상 설치 날짜순으로 동일하게 정렬됨) ServiceBindingInformation 특성에 포함된 URI에 대해 연결을 시도합니다. 이 URI는 자동 검색 서비스 자체의 위치입니다. 그런 후에 클라이언트는 XML을 게시하고 응답을 가져오는 등의 작업을 수행합니다. 이와 같은 정상적인 자동 검색 작업에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

이 방식이 왜 효율적이냐고요? AutoDiscoverServiceSiteScope를 사용하는 경우, 관리자가 사이트 범위를 올바르게 설정했다고 가정할 때(Microsoft에서는 올바른 범위 설정 방법 관련 정보를 관리자에게 제공함) Outlook이 클라이언트 위치에 가장 가까운 CAS를 찾을 수 있습니다. 따라서 요청이 CAS에 도착할 때는 이미 클라이언트에 가장 가까운 CAS가 확인된 상태이므로 요청을 받은 후 이를 다시 확인할 필요가 없습니다.

요청이 CAS에 도착하면 클라이언트로 반환할 설정을 확인합니다. 그런데 사용자에게 필요한 OAB가 요청을 실행 중인 CAS의 로컬에 있을 수도 있는데 원격 CAS에 있는 OAB의 URL이 사용자에게 제공되는 경우가 있어서, 이 문제도 수정이 필요했습니다.

위의 설명을 참고하면 이 문제를 해결하는 방법은 이론상 매우 간단하며, 이미 위에서 설명한 방식으로 클라이언트에 가장 가까운 CAS는 확인된 상태이므로 이를 위해 새로운 방식을 개발할 필요는 없습니다.

관리자가 AutoDiscoverServiceSiteScope를 올바르게 설정했다고 가정할 때 클라이언트가 자동 검색을 위해 연결하는 CAS는 클라이언트에 가장 가까운 CAS입니다. 이 가정이 성립하는 경우 자동 검색 XML에서 반환할 내용을 파악할 때 CAS는 사용자가 사용해야 하는 OAB 사본을 포함하고 있는지만 확인하면 됩니다. 해당 사본이 포함되어 있으면 CAS는 자체 OAB URL을 제공하면 됩니다. 단, 사용자의 사서함이 있는 AD 사이트에 포함된 CAS의 경우는 예외입니다. 물론 이 CAS가 사용자에게 필요한 OAB 사본을 포함하고 있지 않으면 이전 동작이 계속 사용되어 CAS가 사서함 AD 사이트에 있는 CAS의 OAB URL을 반환합니다.

이래에 이 방식을 보여 주는 그림이 나와 있습니다.

이미지

이 방법은 WAN을 사용하는 것보다 훨씬 간편합니다. 즉, 단일 복사본이 WAN을 통해 복제되며 해당 위치의 모든 클라이언트는 로컬 CAS의 OAB를 가져오게 됩니다.

이 새로운 동작을 적용하려면 두 가지 조건만 충족되면 됩니다. 그 중 하나는 CAS에 SP2 RU1을 배포하는 것이고, 다른 하나는 AutoDiscoverServiceSiteScope 매개 변수가 올바르게 설정되어 있는지 확인하는 것입니다.

이 문서의 내용이 도움이 되었기를 바라며, 위에서 설명한 방법을 통해 WAN 연결의 속도를 개선(영문일 수 있음)해 보시기 바랍니다.

Greg Taylor
주임 프로그램 관리자
Exchange Customer Experience

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 It Takes a Long Time…을 참조하십시오.